大多数工程团队评估 AI agent 的方式仍然像批改数学作业一样。他们只看最终输出。如果答案是对的，他们就批准发布并继续下一步。这是一个危险的捷径。一个正确的答案可能会掩盖一个深层损坏的系统。
真正的故事隐藏在 agent 到达终点所经过的路径中。这条路径被称为 agent trajectory。它包含了每一次 tool call、每一个 routing decision，以及 agent 停下来重新思考的每一次停顿。你可以把它看作是 agent 留下的面包屑轨迹。如果你只检查目的地，你就会错过沿途散布的所有警告信号。
混乱路径的问题
一个 agent 可能会在表现得像个醉酒司机的情况下得出正确的答案。它在错误的工具间左右摇摆，折返回 router，在冗余的推理中循环往复，最后才偶然撞上正确的答案。用户看到的是一个干净的结果。但在幕后，系统正在消耗大量资源并积累风险。
这种混乱在实践中究竟是什么样子的？
首先是冗余的 tool call。agent 查询了你的客户数据库，获取了结果，但在五秒钟后就忘记了，然后又使用完全相同的参数查询同一条记录。这不是数据问题，而是 trajectory 问题。agent 未能保持状态，因此重复了工作。
其次是“错误工具优先”模式。一个 coding agent 可能会尝试在网上搜索一个已经在本地代码库中存在的函数定义。或者一个支持 agent 在用户的问题明显需要 account settings tool 时，却去调用 billing API。每一次错误的决策都会消耗 token，增加 latency，并增加在真正开始工作之前就触及 context limits 的风险。
Router loops 是另一个危险信号。决策节点无法做出决定。它将任务发送到分支 A，然后改变主意，将其撤回，转发到分支 B，然后无缘无故地通过一个通用 fallback node 进行路由。每一次循环都会增加一次网络跳转，并为最终的调试日志增加一层混乱。
最后是重复分析。agent 在每一步都在重新推导同一个结论，而不是将其视为已定论。这就像一个木匠在每次切割前都要测量十次木板一样。第一次测量已经足够了，接下来的九次都是徒劳。
这些多余的步骤会带来真实的后果。Latency 会不断堆积。在同步聊天界面中，多出的三秒钟感觉就像过了一个世纪。在大规模应用时，这些秒数会转化为数千美元的计算成本。失败风险也会随之上升。每一次不必要的跳转都是外部 API 超时、context window 溢出或 race condition 出现的又一次机会。当系统真的崩溃时，祝你在调试那段看起来像乱麻一样的 trace 时好运吧。你会花好几个小时去重构 agent 为什么要执行第七步，最后才发现第七步根本就不应该存在。
Convergence 究竟意味着什么
如果说 trajectory 是路径，那么 convergence 就是对其效率的衡量。Convergence 告诉你 agent 在用户请求与正确解决方案之间，有多贴近那条最短的可行路径。
这与 accuracy 不同。Accuracy 是一个粗略的指标。它只问最终状态是否正确。而 Convergence 问的是过程是否合理。一个高 accuracy、低 convergence 的 agent 就像是一个披着成功外衣的累赘。而一个高 convergence、中等 accuracy 的 agent 通常更容易修复，因为它的推理逻辑清晰，且错误是局部的。
你可以通过将 agent 实际采取的步骤与你为该任务类别定义的 shortest path 进行比较，来计算一个粗略的 convergence score。如果一个标准的退款查询应该恰好需要三次 tool call，而 agent 使用了九次，那么你的 convergence ratio 就会受损。你可以通过对不同类型的浪费进行加权来优化这一点。根据工具的 latency 和价格，一次错误的 tool call 可能比一次冗余调用成本更高。一个没有任何价值的 router loop 可能会受到最重的惩罚，因为它预示着架构上的