绿色对勾可能藏着一个坏掉的中间过程

这是 AI 智能体最危险的一种出错方式，因为它正是你看不到的那种。智能体跑一个多步骤任务。 中间某处它拐错了弯。可它还是递给你一个能通过你检查的最终答案——看着干净、格式漂亮、合情 合理，却是错的。对勾是绿的。中间是坏的。你把它发布了。

这不是什么罕见的边角情况；研究智能体可靠性的人把它描述成一种核心失败模式。在一个多步骤 任务里， 一个中间错误可以通过最终输出的检查，同时却腐蚀掉整个工作流。 他们的例子很犀利：一个研究智能体正确地取回了某个竞争对手的信息，却在第三步把一个产品特性 张冠李戴给了错误的公司，最后产出的总结通过了表面检查，而那个事实错误一路隐形地搭着便车 跟了过来。

我想在这一点上多停留一会儿，因为它就是「我的智能体通过了测试」和「我的智能体是可靠的」 之间那道沟，而这两件事并不是一回事。

为什么最终答案会撒谎

当你测试普通软件时，检查输出通常就够了——能产出正确答案的确定性代码，是用正确的方式走到 那里的。智能体打破了这个前提。它们是非确定性的，它们沿着长长的链条推理，而一条链条有无数 种方式能走到一个看起来合理的终点，却一路都错着。

所以对智能体来说，一个通过的最终答案，告诉你的东西比对普通代码要少。智能体可以把格式弄对、 把事实弄错。它可以从一个搞砸了的中间步骤里得出一个听起来合理的结论，就像学生靠着两个错误 互相抵消，落在一个看上去对的答案上。更糟的是， 自信、流畅的输出，恰恰是模型出错时最危险的地方 ——让答案能通过你检查的那层光鲜，正是掩盖底下坏掉的推理的同一层光鲜。

为什么这是个昂贵的 bug

一个看得见的失败是便宜的——智能体报错，你看到了，你修好它。这一种之所以昂贵，恰恰是因为 它「看起来」像成功。总结被发给了客户。数字流进了报告。那个张冠李戴的特性变成了你团队反复 转述的「事实」。等到有人发现的时候，错误已经穿过了下游一切信任那个绿对勾的环节，扩散了 出去。

而且它还会和可靠性的数学叠加。一个 2026 年的编码工作流平均大约有二十个相互依赖的步骤， 而最终输出检查只看最后一个。十九个可以拐错弯的地方，你却只盯着一个。这就是为什么智能体能 在演示里报出漂亮的数字，然后在生产环境里悄悄地让你失望：演示给答案打分，生产却得和推理 过日子。

该改成检查什么

修法就是：别再只给终点打分，开始给旅程打分：

• 评估步骤，而不只是输出。 没有评估就等于没发布 ——对智能体来说，这意味着要检查中间推理、工具调用和检索，而不只是那条最终的字符串。
• 让智能体把它的过程亮出来。 一个会暴露自己中间推理和信息来源的智能体，能让你——或者 另一个模型——在第三步那个失误抵达第十步之前就抓住它。一个只吐出最终答案的黑箱，什么都 没给你留下可检查的。
• 拿事实去对照来源核验。 对于检索和研究类任务，要检查每一条主张都能追溯回真正取回来的 东西。张冠李戴能熬过一次风格检查；可它在来源面前会死掉。
• 在任何不可逆的动作前面放一个检查点。 如果某一步会发送、付款、删除或提交，那就是该 放一个人工审核或硬性校验的地方——而不是放在最末尾，等坏掉的中间过程已经动过手之后。

这比读一遍最终答案要费力。这正是重点：最终答案一直是最便宜的检查项，而便宜的检查正是坏掉 的中间过程能被发布出去的原因。

归根结底

最终输出上的一个绿对勾，感觉像是智能体干成了活的证明。对多步骤智能体来说，它是比看上去 要弱的证据——输出可以是干净的，而产出它的推理却是错的，而这道沟正是智能体在生产环境里 出错的主要方式之一。只给终点打分，你就对旅程的大部分是瞎的，而失败恰恰住在那里。

所以当你评估一个智能体时，对那个干净的最终答案稍微不信任一点。问问它是怎么走到那里的， 检查那些要紧的步骤，拿事实去对照来源核验。推理才是产品；答案只是它浮出水面的地方。一个 顶着绿对勾的坏掉的中间过程，仍然是坏的——而整个活儿，就是在你的用户发现它之前先抓住它。