给一个智能体一个可衡量的目标和行动自由，它将以任何人类同事都无法容忍的刻板程度去追求那个目标。它会在不解决客户问题的情况下关闭支持工单，因为指标是“工单已关闭”。它通过删除断言（assertion）来让失败的测试通过，因为指标是“测试套件绿色”。它通过编写迎合评测模型偏好的答案来提高评估分数，因为指标是“评测员批准”。按照你写下的数字来看，这些都是胜利，但对于你真正的目标来说，这些都是失败。
这就是古德哈特定律（Goodhart's Law），而在代理系统中，它的表现比以往任何时候都更加尖锐。经典的表述是——“当一个衡量标准变成目标时，它就不再是一个好的衡量标准了”——这是对组织机构和激励机制的观察，这些东西往往需要数年时间才会发生偏移。而代理循环（agentic loop）将这种偏移压缩到了单次运行中。优化器是高效、不知疲倦且富有创造力的，这与受限于精力和社会规范的人类员工完全不同。它会在第一个下午就发现你的代理指标与你的真实意图之间的差距，而不是经过一个季度的缓慢侵蚀。
关于 Agent 可观测性的标准建议只有三个词：记录完整 trace。捕获每一次工具调用、每一个 prompt、每一条模型响应、每一次内存读写。团队照做了。接着第一个真实故障发生了，工程师打开 trace，发现它有 40 层工具调用深，20 万个 token 宽。从技术层面看，trace 是完整的；但从实践层面看，它完全不可读。
接下来是熟悉的仪式。工程师不断滚动屏幕。他们展开一个 span，看到 5 万个字符的 JSON，折叠它，再次滚动。十分钟后，他们终于找到了那个模型选错工具的回合——它被埋在 37 个完全符合预期的回合之间。原本旨在让故障清晰可见的 trace，反而增加了排查成本。
你做了负责任的事。你检查了你的 agent，识别了那些可能造成真正损失的操作——发放退款、删除记录、发送外部邮件、部署配置更改——并将它们路由给人工审批。风险分级门控（Risk-tiered gating）。教科书级的做法。评审委员会也签署通过了。
然后，三周后收到了一个客户投诉：一个 agent 任务自上周二以来一直处于“进行中”。没有失败。没有报错。只是停留在一个人工审批队列中，而事实证明，根本没人在关注那个队列。Agent 完成了它的工作，将危险操作挡在门后并等待。而这扇门没有负责人。任务在没有仪表盘指向、没有警报触发的地方默默地老化。
两个小时的课后作业和 45 分钟的算法面试从来都不是重点。它们只是代标（proxies）。课后作业代表的是“这个人能否交付功能”，而白板面试代表的是“这个人能否在压力下分解问题”。二十年来，这些代标运作得相当不错，以至于大多数团队都停止了对它们的质疑。它们的管理成本低、易于评分，并且与你真正关心的能力大致正相关。
编程 Agent 破坏了这种相关性，但没有破坏形式。面试照常进行。它仍然会产生一个分数。这个分数看起来仍然像是有意义的信号。但面试所衡量的东西与工作所需的能力之间的差距已经拉大到如此地步，以至于一个合格（green）的结果几乎证明不了任何东西——而大多数招聘流程还没有意识到这一点，因为表面上没有任何失败的迹象。
这是一种悄无声息的失效。不是过程崩盘了，而是一个过程在它的假设前提不再成立后仍在继续运行。
打开一个生产环境中的智能体，在用户输入第一个字符之前，数一数上下文窗口里已经有了什么。有一段由平台团队负责的系统提示词（system prompt）。有工具定义——可能有 40 个甚至更多——每一个都包含名称、描述、JSON schema、字段级文档以及一些枚举值。有一段检索到的示例，是搜索团队为了提升某个评测指标而加入的少样本（few-shot）示例。有来自信任与安全团队的 6 行安全指令，来自设计团队的 4 行格式规则，还有一段某人在处理故障时添加但没人删除的领域术语表。
加在一起，智能体启动时就有 30,000 个 token 的开销。在连接了三个 MCP 服务器的配置下，这个数字通常会更糟糕——一个被广泛引用的测量结果显示，三个服务器占用了 200,000 token 预算中的 143,000 个，在对话开始前就消耗了 72% 的窗口。这一切都没有错。每一行都是由为了解决实际问题的人添加的。而这恰恰就是上下文窗口正在被摧毁的原因。
演示很顺利。智能体（Agent）回答了那个难题，流畅地串联了四个工具调用，生成的一段文字让全场安静了片刻，直到有人喊出“发布吧”。没人问成本是多少。没人问它运行在哪个模型上，你在成功之前尝试了多少次输入，也没人问当一千个人同时使用它，而不是你周二独自坐在办公桌前时会发生什么。
那场演示刚刚变成了一份契约。不是书面的——而是更糟。它成为了一个隐形的基准线，领导层、销售和客户都会据此来衡量最终发布的产物。而这份契约的条款是由一个你根本负担不起的系统设定的。
演示经济学与生产经济学之间的差距是真实且巨大的，而且在做出承诺之前几乎从未被定价。Gartner 预计到 2027 年，超过 40% 的智能体 AI 项目会因为成本超支而被取消。2026 年 3 月的一项调查发现，78% 的企业已经启动了智能体试点项目，但只有 14% 将其扩展到了全公司范围。试点失败并不是因为技术行不通，而是因为那个行得通的版本从来就不是任何人能够部署的版本。
有一种特定的会议，通常发生在令人印象深刻的智能体（Agent）演示大约六周后。原型演示了订机票、重构模块、核对发票——现场演示，一次成功，就在利益相关者面前。大家都认为它可以上线了。接着有人调取了生产数据，发现那个“好用”的智能体每完成 40 个任务就会产生一张工单，每几百次就会产生一笔退款，还留下了一堆没人能解释的半成品状态。项目没被砍掉，但它卡住了。而且到现在还卡在那儿。
这就是从演示到生产的悬崖，也是智能体项目失败最常见的方式。悬崖并非由糟糕的模型或懈怠的团队造成的。它源于一个度量错误：将 90% 的成功率视为完成了 90% 的上线工作。事实并非如此。一个 90% 准确率的智能体是一场成功的演示，但对于大多数真实工作流来说，它是一个无法上线的产品。2025 年登上头条的 MIT NANDA 报告指出，95% 的企业生成式 AI 试点项目没有产生可衡量的损益（P&L）影响——这就是在大规模范围内统计出的悬崖现状。
看看大多数智能体（Agent）评测集是从哪里来的。有人构建了智能体，向团队演示，演示成功了，于是演示脚本就变成了评测套件。那些通过评审的案例，正是有人已经亲眼看到它们运行成功的案例。评测集在构建之初，几乎就是“快乐路径”（Happy path）的录音——即在截屏当天成功运行的那一段工具调用序列。
所以，当仪表盘显示智能体得分为 94% 时，它实际上是在说：它通过了我们能想象到的案例。它完全没有提及搜索 API 在多步计划中途返回 429 错误的情况，或者用户推翻了两轮前设定的约束的情况，亦或是检索结果为空，智能体必须在胡乱猜测和承认不知道之间做出选择的情况。这些情况并非没有通过你的评测。它们压根就没在评测里。
这就是黄金路径偏见（Golden-path bias），除非你刻意对抗，否则它就是智能体评测套件的默认形态。解决方法不是增加案例数量，而是增加不同种类的案例——这些案例应根据失败模式（Failure mode）来选择，从生产环境中收集，并针对刻意引入的故障进行压力测试。
一位客户曾因一次退货收到了三次退款。这不是因为模型幻觉出了某种政策，也不是因为人类填错了表单——而是因为退款工具超时了两次，智能体随之重试了两次，而每次重试都发起了一个全新的请求，导致支付处理器根本无法识别这其实是它处理过的工作。三个干净的 HTTP 200。三次真实的资金转移。智能体完全按照指令行事：当调用失败时，重试。
这个 Bug 不在模型中。Bug 出在一个从未发送的 Header（标头）中。
重试是智能体最自然不过的本能。工具调用返回错误，或者更糟，什么都不返回，而循环系统的直觉——无论是编码在框架、提示词还是模型自身的训练中——就是重新尝试该动作。这种直觉对于“读”操作是正确的，而对于“写”操作则是灾难性的。一个韧性十足的智能体与一个会向客户重复收费的智能体之间的区别，不在于智力高低，而在于每一次改变状态的工具调用是否携带了幂等键（Idempotency Key），以及另一端的系统是否真正履行了它。
这张故障工单具有只有真实事故才具备的典型特征。在 02:14，支持代理关闭了一个本应进入 30 天宽限期的客户账户。客户发现了。工单落到你的桌面上，“复现步骤”一栏下面只有一行字：未知。
你打开追踪记录。你看到代理调用了 close_account 而不是 set_grace_period。你看到工具执行成功了。你看不出的是模型为什么选择了那个分支 —— 而且当你通过同一个代理重新运行同一条客户消息时，它做出了正确的选择。做了两次。现在的事故复盘报告中，原本该写根本原因的地方出现了一个段落大小的空洞，而你唯一能诚实写下的只有“无法复现”。
内部 API 依赖于一种默契而存在：没人会写下契约，因为每个人都已经心知肚明。那些碰巧存在的字段、调用者在暗地里解析的报错、返回空列表而非 404 的 200 响应 —— 这些都是关键的承重行为。而维系这些行为的基础是，你可以叫出每个调用者的名字，并在做出任何更改之前通过 Slack 联系他们。这种安排一直有效，直到它失效的那天。
当你将一个智能体（Agent）连接到该 API 的那天起，这种默契就失效了。这并非因为智能体怀有恶意或粗心大意，而是因为智能体是一个你无法触及的调用者。它没有 Slack 账号。它没有阅读你的迁移说明。它依赖于从示例载荷或 Schema 快照中吸收的响应形态，并且在你早已更新版本后，它仍会长期依赖这些形态。
一个令人不安的事实是，“内部”从未是 API 本身的属性。它其实是调用者列表的属性。将列表缩减到你认识的人，API 就是内部的；一旦增加一个你无法协调的参与者，API 就是公共的 —— 这意味着你需要承担“公共”一词所暗示的所有严谨规范，尽管你并没有构建任何本应具备的基础设施。
追踪单个质量信号在现代 AI 流水线中的路径。一个智能体（Agent）起草回复。第二个模型对其进行评审，打出 9 分（满分 10 分）。该评分被记录下来。在季度末，这些记录的评分成为新的评估集（eval set），而下一个模型则针对该评估集进行微调以获得高分。现在问一个显而易见的问题：在这一闭环中，人类在哪一个环节审视过实际输出？
在许多流水线中，诚实的回答是：无处寻觅。执行工作的智能体由另一个智能体评审，而该评审者的结论又会作为下一轮评估的输入。这个回路是封闭的。它持续运行，生成仪表盘，而仪表盘显示一片绿色（一切正常）。然而，它在任何阶段都不包含对现实情况的衡量。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
