六个月前，你的团队上线了一个处理退款的支持智能体（support agent）。当时有一份一页纸的 Notion 文档描述了它应该做什么。如今，文档的内容依然如旧，但智能体的行为却已大相径庭。提示词（prompt）的历史记录中有 47 次修改。新增了三个工具——其中一个悄悄绕过了文档中仍坚称存在的财务核查。模型被更换了两次。在一次没人记录的事故之后，重试策略被加强了。而当数据团队的人问起“这里处理退款的具体规则到底是什么”时，诚实的回答是：去读系统提示词和工具注册表吧，因为那才是现在的规范。
这是智能体系统在生产环境中的隐性失败模式：智能体的行为就是那份没人写的操作手册（runbook）。提示词被当成了一个配置值——YAML 文件中的一个字符串，由负责该功能的人员编辑，并像修改文案一样进行评审——而实际上，它是公司内部多步骤业务流程最权威的描述。组织积累流程逻辑的方式就像遗留代码库积累行为一样：通过修改，而非设计。而那些历来负责该流程的人——产品经理、合规主管、运营总监——从未意识到他们已经丢失了交付物，因为根本就没有一份可以丢失的文档。
提示词是规范，而非配置
分类错误是所有其他问题的根源。配置值用于调整已知过程：日志级别、超时、区域。而规范定义了一个过程：智能体将做什么、何时做、在什么条件下做、使用什么工具、向谁升级。我看到的大多数团队都将他们的系统提示词视为配置。它与功能开关（feature flags）放在一起。修改跳过了新代码路径会触发的设计评审。并没有一个与之并行的文档供提示词去实现——提示词本身就是文档。
文献开始注意到这一点。研究人员现在将提示词描述为“软件工程交付物”，具有名称、版本、明确的输入，以及一套用于测试的固定模型设置。这种框架很有用，但它低估了更深刻的事实：当提示词编码了一个业务流程时，它不仅仅是一个软件交付物，它是一个流程交付物——一个标准作业程序（SOP）、一份操作手册、一项政策。该交付物的受众不仅仅是模型，还包括审计员、凌晨 3 点值班的工程师、需要了解退款流程的新员工，以及需要为公司决策辩护的律师。
如果你无法指出一份提示词正在忠实执行的书面文档，那么提示词就是文档。而一份在运行时由概率系统解释的文档，绝不应该是任何人可以心安理得地“偶然”拥有的。
偏差是如何发生的
偏差总是在不知不觉中发生的，这正是它难以察觉的原因。智能体的第一个版本通常确实有一个并行的文档——一个一页纸的文档，上面写着“支持智能体为 50 美元以下的订单办理退款，超过 50 美元的升级给人工，并且从不进行二次退款”。在一两个月里，提示词和文档是一致的。然后现实发生了。
一位客户投诉一笔 52 美元的订单退款缺失，于是工程师在提示词中将阈值提高到了 75 美元。文档里写的还是 50 美元。没人更新文档，因为阈值总归是要调整的，而且更新文档意味着要重新走合规审核流程，大家都没时间。两个月后，另一位工程师添加了一个工具，允许智能体发放商店信用额度（store credit），因为信用额度“基本上就是退款”。文档从未提及商店信用额度。六个月后，一次事故回顾得出结论：智能体应对超过 100 美元的退款进行二次确认，因此增加了一条新指令：“对于任何超过 100 美元的退款，在继续操作前要求用户重新提供订单 ID”。没人称之为政策变更，因为没人称任何事情为政策变更——他们称之为提示词修改。
这种模式出现在我研究过的每一个领域：
- 支持智能体在提示词中积累了退款阈值、黑名单、语气指令和升级规则——每一项都是面向客户的政策承诺。
- 分流智能体积累了严重程度启发式规则、路由规则、寻呼逻辑和值班通知条件——每一项都是与团队达成的运营契约。
- 调度智能体积累了工作时间假设、缓冲规则、VIP 覆盖和冲突解决启发式规则——每一项都是没人写下来的组织礼仪。
- 代码审查智能体积累了“团队风格”、“团队风险承受能力”和“团队升级规则”——被编码为字符串的工程文化。
在每种情况下，提示词的增长方式都像遗留代码库一样：防御性的、增量式的，而且没有人删除任何内容，因为没人能证明删除什么是安全的。新版本的智能体发布了，旧版本被遗忘了，组织现在根据一个仅作为运行时行为存在的规范来运行。
没人预料到的失效模式
隐式所有权问题在爆发之前始终是隐形的，而一旦爆发，往往会以以下四种方式之一呈现。
表现不一致的迁移。 一个团队决定在新的框架上重新构建 agent，或者更换底层模型，或者将单个提示词拆分为多 agent 拓扑结构。新版本通过了小规模的 eval 评估集，随后正式上线。在一周内，三位客户抱怨他们以前能做 X，而现在却不行了。团队中没有人能权威地说明 X 是否本应得到支持。旧的提示词提到了 X，那是原本的意图，还是新版本正确地不予实现的未记录扩展？没人知道，因为规范就是提示词，而提示词已经不在了。
没人能回答的审计。 合规部门询问：“请记录你的退款决策逻辑。” 诚实的回答是“阅读提示词和工具”。提示词有 4,000 个 token，其中一半是针对过去事件累积的防御性指令。其中一些指令甚至相互矛盾。合规团队无法推导出一个清晰的决策树，审计只得到了部分答案，公司也因此承担了本不该承担的调查结果，因为底层逻辑其实没问题 —— 只是无法被清晰地表述。
揭示了“空无一物”的交接。 负责 agent 的工程师离职了。接手的人阅读提示词，问道：“为什么这段话会存在？”，得到的回答是：“我不记得了，但我不敢删除它。” 本应在文档中制度化的碎片化知识（Tribal knowledge）被制度化到了一个字符串中，而这个字符串本身并不具备自我解释性。
悄然改变政策的 diff。 提示词的修改只动了一个句子。PR 评审将其视为文案微调。六周后，财务部门指出退款量增加了 30%。那个句子将门槛从“仅在客户提供订单 ID 时退款”放宽到了“在客户提供任何合理的身份识别细节时退款”。评审链上没有人意识到他们批准了一项政策变更，因为 diff 看起来并不像政策变更。
在每种情况下，本应被视为受版本控制、有所有者、经过评审的规范产出物，却被当成了一个普通的字符串。组织为此支付了代价，体现在各类事故、审计发现和知识流失中。
弥补差距
修复方法在概念上很简单，但在操作上很繁琐，这就是为什么大多数团队都会跳过它。你必须将任何编码了业务流程的提示词视为流程产出物，并投入其所暗示的所有纪律。下面的模式并不新鲜 —— 它们借鉴了团队管理 SOP、runbook 和政策文档的既有经验 —— 但必须有意识地将其应用于提示词，因为将提示词视为代码或配置的默认做法，对于这类提示词来说是错误的。
流程提取评审。 定期从运行中的提示词和工具目录中推导出书面规范。阅读提示词，阅读工具。用通俗易懂的语言写下：“这个 agent 在 Y 条件下执行 X，在 Z 情况下升级处理，绝不执行 W。” 将其与原始文档（如果存在）进行对比。这些差异就是你的流程在你没留意时实际变成的样子。这是一项不舒服的工作，但也是回答“这个 agent 到底在做什么”的唯一诚实的答案。
针对契约评审提示词 diff。 提示词的变更应该根据提示词所实现的文档化流程进行评审，而不是仅仅对比提示词的前后版本。“这是否仍然符合规范？如果不符合，我们是否在修改规范？如果是，谁批准了规范的修改？” 规范修改的评审链与提示词编辑的评审链是不一样的。大多数团队将二者混为一谈，他们不该这样做。
为高风险提示词指定流程所有者。 任何涉及金钱、身份、法律地位、外部沟通或任何具有监管风险的提示词，都需要一名指定的非工程师所有者。这并不是因为工程师不应该编辑它，而是因为工程师不应该是唯一知道提示词内容的人。产品经理负责面向客户的政策，合规负责人负责监管承诺，工程团队负责实现。这些人都应该能够阅读提示词，并确认它仍然反映了他们负责的部分。
带有结构化元数据的提示词注册表。 提示词不应只是配置文件中的一个字符串。它应该是一个产出物，拥有名称、版本、所有者、所实现流程的描述、指向底层规范的链接、作为变更门禁的 eval 评估集以及变更日志。一些新兴的框架正以这种方式对提示词建模。这种投入是实实在在的；而不投入的代价同样实实在在。
将 eval 评估集作为契约测试。 没有测试的规范只是一个愿望。针对承载流程的提示词，其 eval 评估集应该编码契约：金额低于 X的退款自动批准，超过X 的需升级处理，注册不足 30 天的账户需要身份验证，等等。当提示词修改导致 eval 失败时，这要么是回归，要么是刻意的规范变更 —— 团队需要能够区分这两者。如果没有这个评估集，每一次提示词修改都是一场豪赌。
实践中的具体表现
做对这些的团队通常不会从上述所有内容开始。他们从一件事开始：一份由 prompt 实现的书面文档，且该文档的归属者并非编写 prompt 的工程师。其他一切都由此演变而来。
做错的团队通常有一个共同的特征：当你问他们“这个智能体是做什么的”时，他们会通过引用 prompt 来回答。而正确的回答应该是“让我给你看文档，然后我们再讨论 prompt 是如何实现它的”。如果唯一能查阅的地方只有 prompt，那么你就是在阅读一份存在于云端的、无人能审计、版本化或交接的运维手册（runbook）——而组织正在依赖一个仅作为运行时行为存在的规范（spec）运行，随着一句句防御性语句的堆砌而逐渐偏离轨道，直到有一天有人需要解释它时，才发现没人能解释清楚。
智能体系统并不会因为使用了更好的模型而变得更可靠。它们的可靠性源于文档化、所有权归属和审核规范——这些是我们早已熟知的、用于处理涉及金钱、身份或承诺的其他任何流程的方法，但出于某种原因，我们却认为这些方法不适用于 prompt 里的字符串。事实并非如此。请像对待规范（spec）一样对待 prompt，因为它在你没留意的时候就已经变成了规范。
会员专享
余下内容仅对会员开放。
会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
- —完整文章，包含未公开存档的部分
- —可落地的工作框架，附带权衡与决策依据
- —新文章抢先看，先于公开发布
随时取消 · 一次订阅，畅读全部
