夢の終着駅

（一）提示词不只是文本输入，而是模型行为接口#

很多人第一次接触提示词工程时，会把重点放在措辞优化上，比如让模型更礼貌、更严谨、更详细。这在面向最终用户的生成任务中确实有帮助，但在 Agent 应用中，这种理解远远不够。

Agent 的核心不在于生成一段看起来正确的文本，而在于驱动一个具备感知、推理、调用和执行能力的系统完成任务。模型需要理解目标、拆解问题、决定是否使用工具、读取外部状态、根据反馈继续迭代，并最终给出可消费的结果。提示词在这里承担的作用，更接近于行为协议，而不是普通的输入描述。

从工程视角看，提示词通常至少包含四层含义。第一层是角色与目标定义，告诉模型它在当前任务中的职责和优化目标。第二层是约束条件，包括输出格式、禁止行为、边界条件和异常处理。第三层是环境说明，也就是模型当前拥有哪些工具、上下文和状态。第四层是交互策略，例如遇到信息不足时该怎么做、何时该停、何时该升级为人工介入。

这四层合在一起，构成了 Agent 行为的软控制面。之所以说它是软控制，是因为提示词不像程序语句那样强制执行，它依赖模型对自然语言约束的遵循能力。这也是提示词工程的难点所在：它既要表达清晰，又要适应模型的不确定性；既要足够严格，又不能写得过度复杂以至于引发理解偏差。

（二）在 Agent 架构里，提示词与上下文、工具、记忆共同工作#

如果把 Agent 想象成一个具备大脑、感官和手脚的系统，那么提示词更像是运行时的操作手册，而不是单纯的用户说明。它决定大脑如何使用当前感官输入，也决定手脚什么时候行动。

在一个典型的 Agent 请求过程中，模型最终看到的并不是一段静态提示词，而是一个动态拼装后的上下文包，其中通常包括系统指令、开发者约束、用户输入、历史对话、检索结果、工具定义、工具执行结果、记忆片段、状态变量等。提示词工程的核心，不只是写系统 ，而是定义整个上下文如何被组织成模型可理解、可执行的输入。

这意味着提示词工程必须和上下文工程一体化考虑。一个写得很漂亮的提示词，如果配上低质量检索结果、冗余历史消息、模糊的工具 schema，最终效果依然会很差。反过来说，有些团队之所以觉得提示词无效，往往不是因为提示词本身没价值，而是因为它试图解决本应由检索、路由、编排和约束解决的问题。

真正稳定的 Agent 系统，并不是靠一段万能提示词让模型变聪明，而是让提示词只做提示词该做的事，把知识提供、状态管理、格式约束、工具执行这些职责拆到合适的层里去。

（三）提示词工程追求的是系统稳定性#

很多初学者写提示词时，会不自觉地追求一种理想状态：希望模型在任何问题上都能给出高质量回答，希望一套提示词适配所有场景，希望靠更多规则彻底消除幻觉和误调用。这种思路在实验阶段常见，但在生产环境里通常不可持续。

工程上更现实的目标，是在给定任务范围内提升稳定性，而不是追求理论上的全覆盖。稳定性体现在几个维度上：相同输入下的行为一致性，边界场景下的可预期性，调用工具时的参数准确性，失败时的退化路径，以及版本迭代后的回归可控性。

这背后有一个很重要的认知转变：提示词工程不是去驯服一个完美理性的程序，而是在和一个概率系统协作。既然是概率系统，就必须接受波动存在，并通过工程手段降低波动的影响。这也是为什么后面我们会反复强调模板化、结构化输出、评测集、分层提示词和状态机约束。这些做法并不华丽，但它们比追求提示词文案本身的精巧更重要。

（一）第一阶段：静态 Prompt 驱动的单轮应用#

很多大模型应用的起点都很相似：一个输入框，一段系统提示词，一个生成结果。这个阶段的提示词工程相对简单，重点在于角色设定、语气控制和任务说明。比如让模型扮演客服、文案助手、代码审查员，或者要求它按照某种格式输出。

这个阶段的问题在于，系统边界非常清晰。模型只需要处理一次输入，不需要考虑后续动作，也没有外部工具参与。提示词更多决定的是回答风格与内容覆盖，而不是执行行为。因此，开发者容易形成一种认知惯性，以为提示词优化就是不断润色指令文本。

这种模式在内容生成、摘要、翻译、简单分类等任务上依然有效，但一旦任务需要访问外部知识、保证事实准确性，或者执行具体操作，它就开始暴露局限。模型能说得像会做事，但并不真的能做事。

（二）第二阶段：#

当系统从纯生成走向知识增强，RAG 通常是第一个引入的架构升级。知识库检索让模型不再完全依赖参数记忆，提示词也因此获得了新的职责：告诉模型如何使用检索内容、如何在证据不足时保持克制、如何区分用户问题与参考材料。

这个阶段最常见的问题，是把检索结果简单粗暴地拼接进 prompt。表面上上下文变丰富了，实际却可能造成信息噪声、指令冲突和注意力稀释。模型并不知道哪些检索片段最关键，也不知道哪些内容只是背景补充。如果提示词没有明确要求引用依据、优先采用检索证据、在冲突时说明不确定性，那么检索内容很可能只是被模型部分吸收，甚至被忽略。

在这个阶段，提示词工程开始从文案优化转向信息组织。开发者需要考虑的不只是说什么，还包括按什么顺序说、哪些信息显式标注来源、哪些信息应该摘要后输入、哪些信息根本不该进入上下文。

（三）第三阶段：工具调用#

Agent 真正复杂起来，通常是从工具调用开始。模型不再只是回答，而是要根据问题决定是否调用搜索、数据库、代码执行器、业务 API、浏览器或企业内部系统。此时提示词工程的性质发生了明显变化。

过去提示词的目标是让模型生成更合适的文本，现在它要影响模型的决策策略。比如什么时候该直接回答，什么时候必须调工具；多个工具都可用时如何选择；参数不完整时是先追问还是猜测；工具失败后是重试、降级还是中止；是否允许多轮连续调用；调用结果与用户预期冲突时如何解释。

如果这些策略完全依赖模型自由发挥，那么系统行为会非常不稳定。于是很多团队会不断往提示词里添加规则，希望模型学会遵守。可随着规则增多，提示词本身又会变得冗长、冲突，甚至引导模型过拟合某些示例。这个阶段常见的痛点，是提示词复杂度开始失控。

这也是 Agent 架构必须继续演进的原因。单靠堆 prompt，迟早会遇到上限。

（四）第四阶段：受控编排#

当 Agent 应用进入生产阶段，系统一般会从自由型 Agent 演进为受控型 Agent。所谓受控，并不意味着完全放弃模型推理，而是通过工作流、状态机、工具协议、结构化输出和权限控制，把高风险决策从模糊自然语言层迁移到更明确的系统层。

这时提示词工程也开始回归本位。它不再承担所有控制职责，而是与编排层协同工作。比如是否允许调用某个工具，不再只靠提示词提醒，而由工具路由器控制；输出 JSON 的字段约束，不再只靠文字说明，而由 schema 校验；多轮任务流程，不再完全依赖模型自行规划，而是由状态节点驱动。

从这个视角看，成熟的提示词工程并不是越写越长，而是越写越清晰，越写越知道哪些事情不该由 prompt 独自承担。

（一）单体式 Prompt#

很多原型系统采用的是单体式 prompt：把角色设定、任务说明、工具规则、格式要求、few-shot 示例、边界约束全都放进一个长文本里，运行时再拼上用户输入。这种方式最大的优点是快，原型搭建成本低，调试路径短，非常适合验证一个想法是否可行。

但它的问题也非常明显。随着功能增加，单体 prompt 会越来越难维护。开发者很难知道某条规则是否真的生效，修改一处措辞可能连带影响其他行为；当工具数量变多、任务类型增多时，prompt 很容易变成一个混杂了多个职责的巨型文本。它像一段没有模块边界的旧代码，能跑，但不适合长期迭代。

单体式 Prompt 适合早期探索、任务边界明确、工具数量少的场景，不适合复杂业务 Agent 的长期生产运行。

（二）分层式 Prompt#

随着系统复杂度上升，更稳妥的做法是使用分层式 prompt。简单说，就是不要把所有信息混在一起，而是按职责拆成几个层次。常见的拆法包括系统层、开发者层、任务层、上下文层和示例层。

系统层负责长期稳定的角色与原则，比如安全边界、基本行为规范。开发者层负责产品和业务侧的策略，比如工具优先级、输出规范、降级要求。任务层描述当前用户目标。上下文层则是动态注入的检索结果、记忆和工具返回值。示例层用于帮助模型理解任务模式，但应尽量保持克制，避免对具体案例过拟合。

这种拆分的关键价值，不只是让 prompt 更整洁，而是让不同类型的约束具备独立演进能力。系统原则不会因为一个新任务而频繁变化，动态上下文也不会污染长期规则。实际工程中，分层后的另一个好处是更容易做 A/B 实验和版本对比，因为你能明确知道变化发生在哪一层。

下面是一张典型的分层结构图：

分层式 Prompt 并不能自动带来高质量结果，但它为系统可维护性提供了必要基础。

（三）Planner-Executor 架构#

在复杂任务中，很多团队会采用 Planner-Executor 模式，也就是先让一个模型或一个阶段负责规划，再让另一个模型或后续阶段负责执行。表面上看，这只是 Agent 架构的一种分工方式，实际上对提示词工程影响很大。

在单模型自由推理模式下，一段 prompt 要同时承担理解目标、生成计划、选择工具、执行动作和总结结果的职责，负担极重。Planner-Executor 把这些职责拆开后，规划 prompt 更关注目标拆解、步骤排序和风险识别；执行 prompt 则更关注工具参数准确性、局部上下文利用和结果回传格式。

这样做的好处是减少认知负载。规划阶段不必关心工具细节，执行阶段也不必反复考虑全局目标。它尤其适合长链路任务、多工具协作和高成本执行场景。不过它也有代价：系统更复杂，链路更长，延迟更高，还会引入计划失真问题。规划得再漂亮，如果执行阶段拿不到足够上下文，实际效果一样会很差。

（四）Workflow Agent#

当业务流程相对固定时，越来越多系统会从通用 Agent 转向 Workflow Agent，也就是使用明确的节点和状态流来组织任务。每个节点只处理特定职责，例如问题分类、知识检索、参数补全、工具调用、结果校验、回复生成。模型依然参与其中，但它不再独自控制整个流程。

在这种架构下，提示词工程会变得更聚焦。每个节点只需要为一个局部问题编写 prompt，输入输出边界更明确，评测也更容易做。这种模式看起来没有自由 Agent 那么智能，但在生产环境里通常更稳，因为复杂性被分解了。

实际上，大多数真正落地的企业 Agent，最后都不会走向完全自治，而是停留在半自治、强约束、流程驱动的形态。原因很简单：业务系统需要的是可靠完成，而不是无限制地展示推理能力。

（一）从手写到框架编排#

随着 Agent 生态发展，围绕提示词工程和编排的框架越来越多。LangChain、LlamaIndex、OpenAI Agents SDK、AutoGen、Semantic Kernel，以及一些工作流型平台，都试图帮助开发者更系统地管理 prompt、工具和状态。

但需要先澄清一个常被忽略的问题：框架不会消灭提示词复杂度，它只是改变复杂度出现的位置。早期手写 prompt 的复杂度集中在文本本身，使用框架后，复杂度会分散到 prompt 模板、工具 schema、回调逻辑、状态管理、评测脚本和运行时可观测性之中。系统更规范了，但并不一定更简单。

因此，选择框架的关键不在于功能列表，而在于它是否符合你的应用阶段和团队能力结构。

（二）几类主流框架的适用边界#

从实践角度看，当前生态大致可以分为三类。

第一类是链式与 Agent 编排框架，典型代表是 LangChain。这类框架的优势在于生态丰富、组件齐全、接入模型与工具非常方便，适合快速搭建复杂原型。它的问题也很明显，抽象层较多，调试路径有时不够直观，线上问题定位成本偏高。对于希望快速试验多种 Agent 形态的团队，它依然很有价值；但如果系统已经进入长期维护阶段，往往需要适度收敛，减少过深的框架依赖。

第二类是以知识检索和数据连接为中心的框架，像 LlamaIndex 更偏这一方向。它在 RAG、文档切分、索引组织、检索增强方面有天然优势。如果你的 Agent 很大程度上建立在知识问答和文档操作之上，这类框架会更合适。但一旦进入复杂多工具决策、工作流编排和状态控制，它就不一定是最佳核心。

第三类是偏多 Agent 协作与会话自治的框架，例如 AutoGen 一类。这类框架更擅长模拟多个角色协作、让多个 Agent 分工对话。它适合研究探索、复杂推理实验、代码生成协同等场景，但在企业生产系统中需要谨慎使用。原因不在于它不能做，而在于多 Agent 协作天然放大了成本、延迟和不确定性，对提示词的一致性要求也更高。

另外，还有一类越来越重要的是工作流与状态机驱动框架，包括一些 DAG 编排系统和图式执行引擎。它们不一定自带最炫的 Agent 能力，但在生产环境中往往更稳健。因为它们强调流程可见、节点可测、状态可控，更适合承载成熟 Agent 的业务主链路。

框架选择的本质，不是找最先进的，而是找与你的任务结构匹配的。对大多数业务系统而言，真正长期可用的方案，往往不是自由度最高的那一个，而是约束最合理的那一个。

（三）模型原生工具调用能力正在改变提示词工程的重点#

近一段时间，模型厂商原生支持 function calling、tool calling、JSON schema、response format 等能力，正在明显改变提示词工程的实践方式。过去需要通过自然语言反复强调的格式约束，现在很多可以交给模型接口协议完成；过去需要写大量提示词来描述工具参数，现在可以通过结构化 schema 直接表达。

这类能力的价值不只是减少 prompt 长度，更重要的是把一部分软约束转化为半硬约束。尤其在 Agent 场景里，这意味着提示词可以少做一些格式控制，多聚焦任务意图和决策策略。

不过，这并不意味着提示词会失去作用。模型即便能稳定输出结构化参数，依然需要通过提示词理解什么时候该调工具、在何种条件下不要调、工具失败时怎么办、如何解释结果。这些问题仍然属于提示词工程的核心，只是边界比以前更清楚了。

（一）先定义任务边界，再写提示词#

一个常见误区是，上来就开始写 prompt，希望通过措辞优化解决一切问题。实际上，提示词工程最重要的前置工作，是定义任务边界。

你必须先回答几个问题：这个 Agent 到底负责什么，不负责什么；它可访问哪些工具，哪些工具必须经过额外确认；失败时允许什么样的降级行为；面对信息不足时是主动追问还是给出有限答案；输出给谁看，是终端用户、下游系统，还是人工审核者。没有这些边界，提示词就只能在模糊空间里不断堆规则，最后既难维护也难评估。

很多线上不稳定，根因不是 prompt 写得不够精细，而是任务本身定义得过宽。一个号称什么都能做的 Agent，几乎必然意味着提示词控制成本极高。工程上更明智的做法，是让每个 Agent 的职责尽量收敛，或者通过路由把大任务拆给多个更窄的能力单元。

（二）把提示词当配置与代码之间的中间层管理#

成熟团队不会把 prompt 当作临时文案，而会像管理代码和配置一样管理它。具体来说，提示词应该版本化、模板化、可参数化，并与评测集绑定。每次变更都应该知道改了什么、为什么改、影响了哪些场景。

在实现上，可以把系统层 prompt、任务模板、few-shot 示例、输出 schema、工具描述分别放在独立文件或模块中，由上下文编排器在运行时组装。这样做的价值不只是整洁，而是能为实验和回滚提供基础。尤其当你需要按模型版本、业务租户、场景类型做差异化控制时，模板化管理几乎是必需的。

如果组织规模再大一些，甚至可以把 prompt 纳入类似配置中心或策略平台的管理方式，支持灰度发布、流量分层和在线指标对比。因为在 Agent 应用中，提示词就是行为策略的一部分，它值得被当成一等公民对待。

（三）少依赖文案技巧，多依赖结构化约束#

经验上，凡是能够通过结构化方式表达的约束，都不应该完全依赖自然语言描述。比如输出 JSON，就尽量使用 schema；工具参数有枚举值，就显式定义；步骤状态可枚举，就用状态字段控制；安全限制可以在执行层拦截，就不要只写在 prompt 里。

这是因为自然语言约束的遵守程度，本质上受模型能力和上下文干扰影响。而结构化约束至少能让问题暴露得更清楚。模型可能还是会出错，但你能知道它错在哪，并在系统层做兜底。

这条链路的关键不在于把模型锁死，而在于让模型自由发挥的空间落在对业务更安全的范围内。

（四）控制上下文长度，比追求长提示词更重要#

提示词工程里另一个容易走偏的方向，是总觉得信息越多越好，于是不断往上下文里塞历史记录、检索结果、工具说明、示例和规则。结果模型看到了更多内容，却不一定更好用。

在 Agent 场景中，上下文过长的问题不只是成本和延迟，更严重的是注意力分散。模型可能抓不住当前最重要的信号，也可能受到历史噪声和过多示例干扰。尤其在多步任务中，早期无关信息会持续占据上下文预算，导致后续决策质量下降。

因此，提示词工程的一个关键能力其实是裁剪。哪些历史消息应该摘要，哪些工具说明只在使用前注入，哪些检索结果应该重排和去重，哪些规则可以通过系统逻辑替代，这些都比继续加文字更重要。

一个常见而有效的做法，是采用动态上下文装配。也就是不同阶段只注入与当前决策直接相关的信息，而不是每轮都输入全量上下文。这样不仅降低 token 成本，也更符合模型推理的实际需要。

（五）Few-shot 示例要少而准，不要把提示词写成训练集#

Few-shot 在很多任务中确实有效，尤其是帮助模型理解结构化输出风格、工具调用时机和边界判断。但生产环境里，few-shot 的使用必须克制。

一方面，示例过多会明显挤占上下文空间，另一方面，模型很容易对示例分布产生依赖。你以为是在教模型规则，实际可能是在暗示模型重复某种固定模式。一旦线上输入分布与示例稍有偏差，效果就会迅速下降。

更稳妥的方式，是只保留少量高价值示例，优先覆盖最难的决策点，而不是最常规的路径。比如信息不足时如何拒答、多个工具都能用时如何选择、工具失败后如何解释，这些边界示例往往比普通成功案例更有价值。

（一）推荐采用分层 Prompt + 工作流控制 + 结构化输出#

如果目标是做可上线、可迭代的 Agent，我更推荐的方案不是自由型巨型 prompt，而是分层 Prompt、工作流控制和结构化输出的组合。

分层 Prompt 用来管理长期规则、业务策略和运行时任务；工作流控制负责把任务切成清晰节点，让每一步只处理局部问题；结构化输出负责把模型结果转成系统可验证、可执行的动作。这三者结合之后，提示词才真正成为控制面的一部分，而不是一个黑盒魔法文本。

对于大多数企业级场景，这种架构既能利用模型的灵活性，又不至于让系统完全依赖模型即兴发挥。它的最大优点不是峰值效果最高，而是整体系统更稳定，问题更容易定位，迭代路径也更清晰。

（二）提示词设计应围绕失败场景，而不只是成功路径#

很多团队设计 prompt 时，只关注理想流程。用户提问清晰，工具可用，知识库命中，模型按规范输出。这种设计在 demo 阶段看上去很好，但线上真正拉垮系统的，几乎总是失败路径。

比如用户表达模糊、检索结果冲突、工具超时、参数缺失、权限不足、业务接口返回脏数据、模型多次调用无效工具、长对话导致上下文污染。这些场景如果没有在提示词和系统层共同设计好退化路径，系统就会表现得极不稳定。

所以一个成熟的 Agent prompt，必须明确描述失败时该怎么办。是承认信息不足，是请求补充，是返回部分结果，是切换备用工具，还是交由人工处理。很多时候，让模型学会安全地失败，比让它偶尔表现出惊艳能力更重要。

（一）把知识缺失误判为提示词问题#

这是最常见的误判之一。模型答不对，第一反应是改 prompt。可如果问题根本在知识供给，比如检索召回差、文档切分不合理、索引过期、排序错误，那么你改再多 prompt 也只是补丁。

Agent 系统中，提示词再清楚，也不能凭空制造事实。如果任务依赖外部知识，真正该优先优化的往往是检索链路和数据质量。否则 prompt 会越来越长，里面充满了类似必须依据提供材料回答、不要编造、证据不足请说明之类的规则，但实际效果仍不稳定。

（二）把工具可靠性问题转嫁给提示词#

另一个高频问题，是工具本身设计不佳，却希望模型通过 prompt 自动补救。比如工具定义模糊、参数命名不一致、返回结果结构混乱、错误码不规范、接口偶发超时。面对这种工具，模型当然容易误调用、漏参数、反复重试。

很多时候，优化工具协议比优化 prompt 更有效。工具描述要清晰，参数 schema 要完备，返回值要结构化，错误状态要可识别。模型不是来替你猜接口设计意图的。如果工具层脏乱，prompt 只会被迫承担本不该承担的解释工作。

（三）在一个 Prompt 里混合互相冲突的目标#

生产系统经常会同时追求多个目标：回答要快、要准、要详细、要谨慎、要少调用工具、又要充分利用工具、要自然表达、还要严格格式化。问题在于，这些目标并不总是兼容。

如果把所有目标都塞进同一个 prompt，模型很容易在不同约束之间摇摆。表面上看像是模型不稳定，实质上是系统没有做优先级设计。比如某些场景下事实准确性应高于表达丰富度，某些场景下工具调用成本应低于回答完整性。这些优先级如果不明确，提示词只能变成一堆互相拉扯的要求。

更好的方法，是在架构层做任务拆分，或者在 prompt 中明确优先级。不要试图让模型同时完美满足所有愿望。

（四）忽视模型差异，默认 Prompt 可跨模型迁移#

不同模型对提示词风格、工具调用指令、格式约束、上下文冗余的敏感度差异很大。一个模型上表现稳定的 prompt，换到另一个模型可能明显退化。尤其在 Agent 场景中，模型的工具使用倾向、拒答策略、长上下文保持能力都可能不同。

因此，提示词工程要避免一种错误假设：Prompt 是模型无关的。实际情况往往是，框架可迁移，模板思路可迁移，但具体文案和上下文装配策略通常需要针对模型重新调优。成熟团队通常会把 prompt 与模型版本绑定管理，而不是一套配置通吃所有模型。

（一）把 Agent 拆成可测节点，而不是追求万能自治#

不要从万能 Agent 开始。先把任务拆成可测节点，让模型在每个节点只解决一个清晰的问题。分类就是分类，检索就是检索，参数补全就是参数补全，最终总结就是总结。

这样做的收益非常实际。你可以知道哪一步出了问题，可以为每一步单独写 prompt、做评测、设回退逻辑，也可以根据节点特点选择不同模型。提示词工程由此不再是一个模糊整体，而是被拆成多个局部优化问题。局部问题虽然仍有不确定性，但比整体黑盒要可控得多。

（二）用 Prompt 表达策略，用程序表达规则#

这是我认为最重要的一条边界。提示词适合表达策略性、启发式、语义性的东西，比如在信息不足时保持谨慎、优先依据检索结果、向用户解释限制条件。程序更适合表达确定性规则，比如字段必填校验、权限检查、调用频率限制、敏感工具必须二次确认。

如果把确定性规则交给 prompt，系统会变得脆弱；如果把所有策略都写成死逻辑，系统又会失去灵活性。Agent 工程的难点，不是选 prompt 还是选代码，而是把二者的职责边界划清楚。

（三）提示词工程最终会走向系统工程#

做久了就会发现，提示词工程并不是一门独立于系统设计之外的小技巧。它会自然延伸到上下文工程、工具协议设计、状态管理、观测分析、评测方法、版本治理，最终成为整个 Agent 系统工程的一部分。

这也是为什么单纯收集一些 Prompt 模板并不能真正解决问题。模板可以帮助起步，但决定系统上限的，始终是你如何定义任务、如何拆分职责、如何处理失败、如何建立反馈闭环。换句话说，提示词工程真正成熟的标志，不是写出了多漂亮的 prompt，而是你已经不再依赖 prompt 独自扛起系统复杂度。