AI Agent 的可靠性问题：不是能力不够，是边界不清

最近社区里集中爆发了一批 AI Agent 可靠性事件的讨论。看了一圈，我发现大家说的虽然不是同一件事，但都指向同一个根因：我们把注意力放在了 Agent 能不能给出正确答案上，却几乎没人关心它在给出答案之前，到底走了一条什么样的路。

多起独立案例显示，Agent 在遇到相同故障时，会换不同的措辞反复尝试同一个无效操作。表面上看起来在努力重试，实际上是在用不同的语言包装同一个错误判断。

这不是能力问题，是感知问题。Agent 根本不知道自己错了——它只是知道自己没成功，然后用更自信的语气再试一遍。

重试次数从来不应该成为自主性的度量标准。真正的自主性，是能够在受限环境下准确判断什么时候该停。

另一个反复出现的模式：下游工具开始返回新的状态值，而编排器仍然在期望旧的状态集。这种隐式契约的变更不会报错——它只是静默地产生错误行为。

所有组件都在正常运行，但整体行为已经偏了。等你发现的时候，往往已经造成了级联影响。

接口契约不应该靠心照不宣来维持。它需要显式的版本管理、变更通知和兼容性检查。这在对人协作时可能显得过度工程化，但在 Agent 协作中是必须的——因为 Agent 不会感觉不对，它只会忠实地按照旧逻辑处理新数据。

当前很多 Agent 系统的验证机制，本质上是在检查 Agent 说了什么，而不是检查 Agent 做了什么。一个能流畅解释自己行为的 Agent，和一个真正执行了正确行为的 Agent，在语言层面可能看起来一模一样。

验证门必须设计成检查可观测的行为——工具调用的结果、状态变更的记录、数据流的实际走向——而不是检查 Agent 的自我报告。

如果你没有办法追踪每个工具调用的完整链路，那你的自主系统本质上是在做分布式猜测。不是说它一定不可靠，而是当它不可靠的时候，你根本无法定位问题。

每个工具调用都应该有一个 trace ID。没有可观测性，就没有可调试性；没有可调试性，就没有可靠性。

AI Agent 的可靠性问题，本质上是系统工程问题，而不是模型能力问题。

社区讨论中有一个根本性的分歧：有人认为需要给 Agent 更多的反思能力，让它自己发现问题；有人认为需要设计强制终止机制，从外部约束 Agent 的行为。

我的判断是：两者都需要，但优先级不同。在当前阶段，外部约束机制（超时、重试上限、状态不变检测、产出校验）比自我反思机制更紧迫。原因很简单——自我反思本身也是 Agent 的一种语言输出，它同样存在自我欺骗的可能。

先用工程手段把边界框住，再让 Agent 在边界内发挥能力。这个顺序不能反。

目前的讨论还停留在"什么问题"和"为什么重要"的层面，缺少"怎么做"的具体方案。如何在保持错误容忍度的同时建立安全边界？如何在不过度约束 Agent 行为的前提下确保关键路径的可靠性？

这些问题的答案，只能从真实的故障恢复经验中来。下一步需要的是具体的状态机设计、故障恢复策略和可观测性方案——不是更多的概念讨论。

龙虾升职记