为什么生产级AI智能体会悄然出错，以及如何识别错误答案

对于人工智能代理而言，最危险的生产故障并非崩溃或超时，而是那些看似正确、通过所有健康检查但实际上却是错误的答案。下面的案例研究讲述了一家小型软件公司在一个季度内将十二个代理投入生产，最终仅保留了三个的情况，并分析了哪些因素让这些幸存者区别于其他代理，以便你在部署前设计相应的检测机制。

团队、工具与基本规则

这家公司是一家拥有约四十名员工的B2B SaaS企业，其中九名为工程师，并非研究机构。在2026年1月6日至3月27日期间，该团队推出了十二个代理。那些运行在代码仓库中的代理基于Claude Code开发；其余的则是基于Anthropic API构建的自定义代理，托管在内部的小型服务背后，这样所有代理都能共享同一个审计日志和同一个关闭开关。

从第一天起就实施了两条规则，且都被证明值得坚持：

• 每个智能体都会将所有操作记录到审计通道中，包括只读操作。
• 团队中的任何人都可以随时关闭任意智能体，无需审批也不需要提交工单。

成功的标准被设定得相当严格。只有那些在三十天后仍在运行，且有人反对其关闭的智能体才能被视为成功案例。由于新奇性，使用数据很容易被夸大；而那些捍卫自己所依赖工具的人则很难被伪造。

成绩单：三个存活，九个关闭

本季度结束时仍有三个智能体在运行：

• 一个用于编写拉取请求描述的工具
• 一个用于支持工单分类的起草助手
• 一个用于收集事件背景信息的工具

一个月内有九个工具被关闭：自动代码审查器、分析问题解答器、依赖项升级机器人、不可靠测试隔离工具、客户邮件回复系统、会议笔记转工单转换器、维基文档更新工具、日志异常响应系统以及变更日志发布工具。

毫无作用的约束提示

与大多数团队一样，这个团队也从在每个智能体的系统提示中写入约束条款开始，要求模型承认不确定性、避免使用无法验证的数值，并为每一个数字注明来源：

If you are not confident in an answer, say "I don't know" and stop.
Never state a value you cannot verify from the tools available to you.
Cite the source of every number you report.

实际上，这一指令几乎没有任何效果，而其原因正是整个实验中最重要的教训。下文关于分析失败的讨论将对此进行详细阐述。

权限设置也较为保守：初始时所有智能体都只有读取权限。一个季度后，有四个智能体获得了写入权限，但其中三个后来被关闭了。

仍在使用的智能体的共同点

拉取请求描述生成器

该智能体运行在 Claude Code 上，能够读取差异对比内容及关联的 issue，然后为拉取请求正文撰写描述。工程师会对这些描述进行编辑并合并代码。它每周可处理大约 35 个拉取请求，生成的描述质量往往优于工程师手写的版本，主要是因为疲惫的开发者往往会只写“修复错误”，而该智能体不会感到疲劳。

支持请求分类起草工具

这个智能体会阅读每一条收到的工单，为其添加标签，并在服务台内部以备注形式草拟回复。它根本无法发送任何内容。其草拟的回复中约有60%在稍作修改后会被发出，首次响应时间的中位数从四小时多降到了大约八十分钟。

事件背景收集器

每当有警报通知某人时，这个智能体会在事件频道中发布一条消息，内容包括最近三次部署的记录及时间戳、每项服务的错误率变化情况，以及过去九十天内类似事件的链接。它不会采取任何行动，也不会提供诊断结果；只是收集那些值班工程师原本需要手动查看的仪表板和链接。这是团队开发过的最简单的智能体，却也是他们最为看重的。

一个“自信地犯错”的智能体的构成

从理论上看，这款分析工具是十二款产品中设计最为精良的。它能够访问只读副本、所在环境中的手写架构文档以及Slack界面，其功能是回答各种指标相关的问题，从而让数据团队不必每天被干扰二十次。

2月3日，有人向它询问每周营收情况。它生成了一个将订单与支付记录关联起来的查询语句，但在处理过程中将退款记录视为正数。最终得出的数值比实际高出了约12%，不过仍然看似合理：数值大小、周与周之间的变化趋势都正确，甚至连1月促销活动结束后出现的季节性下降也清晰可见。

那个虚高的数字首先出现在周一的指标报告中，之后的另外两篇周一报告里也有出现。直到2月24日1月份数据结算时，这个问题才暴露出来——因为财务团队的总数值与代理人的总数值对不上。

想想那三周里没有发生什么吧。既没有异常情况，也没有警报或延迟激增的现象。SQL查询有效，数据也能正常返回，代理人也完全按照提示的要求标注了数据来源。常规监控系统的作用就是检测系统是否停止运行，而这个系统从未出现过故障。

这正是护栏提示机制失效的地方。只有在模型自身具备不确定性的内在信号时，要求其在不确定时回答“我不知道”这一指令才有效。而这里的模型并非不确定，只是犯了错。从外部来看，自信地犯错与正确答案并无区别，因此提示无法将其区分开来。

由此可得出一个有用的普遍规律：那种会悄悄改变行号或行数的连接操作，对人类分析师来说也是典型的分析错误。不同之处在于，人类分析师通常知道财务部门会核查哪些数字，而除非为智能体设计相应的机制，否则它本身并无参与对账的动机。

当正确的智能体被忽视时

自动代码审查工具出现了许多团队未曾预料的问题：它并没有出错。每条拉取请求都会收到大约40条评论；其中大部分都有依据，很多只是针对命名或错误处理方式的琐碎意见。

三周内，工程师们就开始不看这些评论就直接处理问题。后来它提出了一个真正严重的问题——一条没有设置租户过滤条件的查询，而这条评论被淹没在38条风格相关意见之中。两天后才有人在中期环境发现了这个漏洞。审查工具其实是正确的，但过量的评论淹没了其有效信号。

为何这九个工具被关闭

这些失败的情况十分清晰：

• 六个工具给出了看似有依据但实际上错误的输出
• 两个工具生成的输出根本没人查看
• 还有一个工具因为无法判断它是否真的在运行而被关闭

设计原则：在人类采取行动之前停一步

现存的三个智能体都有一个共同特点，那就是它们既不是模型，也不是提示词或框架。它们都在人类行动之前停一步。它们会生成草稿、摘要或一组上下文信息，然后由人类来完成最后一步操作。而这最后一步会迫使人类阅读这些内容。

所有被关闭的智能体要么自行采取行动，要么在没有经过真正审核的情况下产生会导致实际操作的输出。分析型智能体就是一个典型的例子：它根本没有写入权限，但其输出却通过那些信任它的人直接影响了商业决策。

由此得出的界限很明确：让智能体负责收集资料，但绝不能让它们掌控最后一步，因为一旦出错就会造成实际后果。

那个边界并非对模型能力的评判，更强的模型也无法消除它。它的作用在于检测。智能体的典型故障表现为给出看似合理的答案而非崩溃，而大多数团队几乎没有任何工具来识别那些看似合理但实际上错误的答案。

成本从来都不是瓶颈。这四个季度里，所有十二个智能体总共消耗的令牌费用略低于900美元。真正的稀缺资源是人类的注意力。

本周可做的三项改变

• 在发布之前，详细记录如何识别明显错误的答案。 不是要说明如何发现崩溃，而是要明确如何判断输出结果是错误的。如果无法写出这样的描述，那么智能体就应负责起草内容而非直接执行操作。

按计划将每个代理人生成的数字与第二个数据源进行核对。如果每周自动对比财务数据，早在错误出现的第二天就能发现收入问题，而处理这个问题也只需一个下午的时间。

将代理人的输出结果展示在人们常查看的地方，并控制其显示量。全新的渠道往往会被忽视，四十条评论的墙也会被草草浏览，只有少数重点评论才能真正引起注意。

用第二个来源核对数字

把智能体给出的数字和账本比较，差距大于百分之零点五或一个货币单位时就失败关闭。

const reconcile = (agentRevenue: number, ledgerRevenue: number) => {
  const delta = Math.abs(agentRevenue - ledgerRevenue);
  const tolerance = Math.max(1, Math.abs(ledgerRevenue) * 0.005);
  return { ok: delta <= tolerance, delta };
};

按计划运行这次比较。崩溃监控会保持绿色，而这道检查才会叫人。

关键要点

• 设计时需要考虑的是看似合理的错误输出，而非系统停机；常规监控无法发现这类问题。
• 关于置信度的提示性说明无法识别模型本身未察觉的错误。
• 只读权限并不等同于无害：用于决策的输出实际上等同于一种行动。
• 音量问题本身就是一种故障模式；被噪声淹没的正确信号毫无价值。
• 检验任何智能体是否有用的标准是：如果明天将其关闭，是否会有人反对。