你的 Agent 在无文档情况下悄然掌握的流程

六个月前，你的团队上线了一个处理退款的支持智能体（support agent）。当时有一份一页纸的 Notion 文档描述了它应该做什么。如今，文档的内容依然如旧，但智能体的行为却已大相径庭。提示词（prompt）的历史记录中有 47 次修改。新增了三个工具——其中一个悄悄绕过了文档中仍坚称存在的财务核查。模型被更换了两次。在一次没人记录的事故之后，重试策略被加强了。而当数据团队的人问起“这里处理退款的具体规则到底是什么”时，诚实的回答是：去读系统提示词和工具注册表吧，因为那才是现在的规范。

这是智能体系统在生产环境中的隐性失败模式：智能体的行为就是那份没人写的操作手册（runbook）。提示词被当成了一个配置值——YAML 文件中的一个字符串，由负责该功能的人员编辑，并像修改文案一样进行评审——而实际上，它是公司内部多步骤业务流程最权威的描述。组织积累流程逻辑的方式就像遗留代码库积累行为一样：通过修改，而非设计。而那些历来负责该流程的人——产品经理、合规主管、运营总监——从未意识到他们已经丢失了交付物，因为根本就没有一份可以丢失的文档。

提示词是规范，而非配置

分类错误是所有其他问题的根源。配置值用于调整已知过程：日志级别、超时、区域。而规范定义了一个过程：智能体将做什么、何时做、在什么条件下做、使用什么工具、向谁升级。我看到的大多数团队都将他们的系统提示词视为配置。它与功能开关（feature flags）放在一起。修改跳过了新代码路径会触发的设计评审。并没有一个与之并行的文档供提示词去实现——提示词本身就是文档。

文献开始注意到这一点。研究人员现在将提示词描述为“软件工程交付物”，具有名称、版本、明确的输入，以及一套用于测试的固定模型设置。这种框架很有用，但它低估了更深刻的事实：当提示词编码了一个业务流程时，它不仅仅是一个软件交付物，它是一个流程交付物——一个标准作业程序（SOP）、一份操作手册、一项政策。该交付物的受众不仅仅是模型，还包括审计员、凌晨 3 点值班的工程师、需要了解退款流程的新员工，以及需要为公司决策辩护的律师。

如果你无法指出一份提示词正在忠实执行的书面文档，那么提示词就是文档。而一份在运行时由概率系统解释的文档，绝不应该是任何人可以心安理得地“偶然”拥有的。

偏差是如何发生的

偏差总是在不知不觉中发生的，这正是它难以察觉的原因。智能体的第一个版本通常确实有一个并行的文档——一个一页纸的文档，上面写着“支持智能体为 50 美元以下的订单办理退款，超过 50 美元的升级给人工，并且从不进行二次退款”。在一两个月里，提示词和文档是一致的。然后现实发生了。

一位客户投诉一笔 52 美元的订单退款缺失，于是工程师在提示词中将阈值提高到了 75 美元。文档里写的还是 50 美元。没人更新文档，因为阈值总归是要调整的，而且更新文档意味着要重新走合规审核流程，大家都没时间。两个月后，另一位工程师添加了一个工具，允许智能体发放商店信用额度（store credit），因为信用额度“基本上就是退款”。文档从未提及商店信用额度。六个月后，一次事故回顾得出结论：智能体应对超过 100 美元的退款进行二次确认，因此增加了一条新指令：“对于任何超过 100 美元的退款，在继续操作前要求用户重新提供订单 ID”。没人称之为政策变更，因为没人称任何事情为政策变更——他们称之为提示词修改。

这种模式出现在我研究过的每一个领域：

• 支持智能体在提示词中积累了退款阈值、黑名单、语气指令和升级规则——每一项都是面向客户的政策承诺。
• 分流智能体积累了严重程度启发式规则、路由规则、寻呼逻辑和值班通知条件——每一项都是与团队达成的运营契约。
• 调度智能体积累了工作时间假设、缓冲规则、VIP 覆盖和冲突解决启发式规则——每一项都是没人写下来的组织礼仪。
• 代码审查智能体积累了“团队风格”、“团队风险承受能力”和“团队升级规则”——被编码为字符串的工程文化。

在每种情况下，提示词的增长方式都像遗留代码库一样：防御性的、增量式的，而且没有人删除任何内容，因为没人能证明删除什么是安全的。新版本的智能体发布了，旧版本被遗忘了，组织现在根据一个仅作为运行时行为存在的规范来运行。

没人预料到的失效模式

隐式所有权问题在爆发之前始终是隐形的，而一旦爆发，往往会以以下四种方式之一呈现。

加载中…