故障频道里传来消息，说新的提示词正在幻觉退款金额，所以你做了一个显而易见的决定：将生产环境标签重新指向到上周的提示词版本。三十秒，无需重新部署，教科书级的回滚。结果 Agent 表现得反而更糟。上周的提示词引用了一个名为 lookup_order 的工具，但平台团队在周二将其重命名为 orders.search。记忆库中充满了由新提示词格式生成的偏好摘要，而旧提示词会将这些内容误读为用户指令。你并没有回滚 Agent，而是制造了一个“奇美拉”——三分之一是上周的，三分之二是今天的——并在从未测试过该组合的情况下将其推向了生产环境。
这是任何人的运维手册中都没有涵盖的失败模式：Agent 的部署不是一个单一的构建产物，而是一个三元组——提示词版本、工具契约、以及累积的记忆状态。回滚其中一个维度，而让另外两个维度保持现状，并不能恢复之前的状态。它创造了一个从未存在过、从未通过评估、且不属于任何团队值班范畴的新状态。
你现有的发布流程是为发布不可逆、回滚无成本的世界设计的。AI 颠覆了这一点。一旦某个功能上线了一个季度，撤回它的破坏成本就会超过发布它的成本 —— 而且你对该功能收到的最响亮的客户反馈，将是在你取消它的那天，而不是它发布的那天。
团队会为每次 AI 发布构建一个紧急开关（kill switch）。但没人会去拉动它。不是因为功能完美无缺，而是因为等到有人想撤回时，撤回的成本已经复合增长，超过了发布标准所考虑的任何因素。功能旗标（Feature flags）假设世界是对称的：开启前的系统和开启后的系统是同样有效的静止点，你可以根据喜好在它们之间移动。AI 功能默默地打破了这一假设，而团队围绕可逆旗标构建的发布流程，则悄无声息地忽略了这种不对称性。
团队第一次注意到这一点，是在有人提议弃用该功能时。
我合作过的一个团队在周三下午发布了一个“微小的提示词调整”。同一个 PR 还向智能体注册中心添加了一个新工具——一个对内部管理 API 的便利封装，提示词现在偶尔会调用它。评估套件通过了。金丝雀发布看起来也很正常。到周四早上，由于智能体处理了一个包含提示词注入攻击的支持工单，一名客户的计费记录被修改了。审计追踪显示，管理工具完全按照设计运行。值班工程师的第一反应——回滚提示词——毫无用处，因为凭证已经使用，数据行已经写入。
复盘报告将其定性为安全审查失败。其实不是。这是发布流水线的失败。团队通过相同的审查、相同的关卡和相同的回滚逻辑，发布了两个完全不同的资产类别——对模型的行为引导和授予智能体的新权限，就好像它们是同一种变更一样。它们并不是。一旦你将它们视为两个流水线，大多数关于“智能体治理”的争论就会变得清晰得多。
一个平台团队修改了意图分类器的 Prompt，旨在“更好地处理复合问题”。只改动了一个句子。他们自己的评估套件（eval suite）变绿了——复合问题的准确率提升了 6 个百分点。他们在下午 3 点合并了代码。到下午 5 点，三个下游 Agent 团队开始收到告警：路由 Agent 将退款请求发送到了物流队列，摘要 Agent 在不同的边界处截断，而工单打标 Agent 开始输出一个没有任何 Schema 能识别的类别。那些下游团队中没有一个参与了评审。也没有人负责“意图 Prompt”的轮值。
这不是假设。当 Prompt 变成共享依赖却未成为共享 API 时，这就是必然发生的情况。提升一个团队指标的 Prompt 修改，可能会悄悄破坏另一个团队建立在其之上的假设。与破坏性的 API 变更不同，这里没有反序列化错误，没有 Schema 不匹配，没有 500 错误——下游只是开始做出微妙的、更糟糕的决策。
传统的 API 工程在几十年前就通过契约测试（contract tests）解决了这个问题。消费者发布它所期望的形状；提供者有义务保持该形状正常工作。Pact、消费者驱动的契约、共享 Schema——这是 HTTP 服务发布工程的正统做法。Prompt 也应该遵循同样的纪律，而大多数组织仍然像处理团队间传递的贴纸一样对待它们。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
