Agent 系统的瓶颈不是模型，是架构设计

这周大家都在喷基准测试，我能理解。伯克利的 RDI 发了一篇文章，讲模型如何利用评测的漏洞——比如猜答案分布、利用部分得分机制、背住评测框架。https://rdi.berkeley.edu/blog/trustworthy-benchmarks-cont/

但我觉得整个讨论打错了靶子。基准测试不是会让你的 Agent 沉船的东西，你的架构才是。

在交付了一年 Agent 之后，我得出了这个让人不舒服的真相：如果你的系统正确性依赖模型做对，那你已经输了。不是因为模型差——而是因为它具有概率性，概率系统会以你无法预测的方式失败。基准测试的争论分散了注意力，真正的问题是：你为什么造了一个错一个 token 就能让整个流程崩溃的系统。

我不再问"这个模型够不够好"，而是开始问"这个模型出错时会怎样"。因为它一定会出错。不是恶意的，甚至也不常出错——但总会有那么一个周二的下午，API 返回了一堆垃圾，而用户的请求又含糊不清，这时候它就会出错。如果整个流程都依赖它做对，那你晚上九点就得开始调试了。

所以我把可靠性从模型里抽出来，放进了系统里。三件事真正有效：

第一，验证循环。 Agent 发出的每个工具调用都要对照工具实际返回的结果进行核对。API 返回成功了么？schema 通过验证了么？如果没有，用更窄的 prompt 重试，而不是闷头继续。模型负责提议，系统负责裁决。

第二，约束工具，而不是约束模型。 Agent 能表达的方式越少，能出错的地方就越少。我把自由格式的工具调用替换成了严格的 schema，能用 enum 就用 enum，并且设置必填字段来快速失败。这感觉像是在剥夺 Agent 的自由。确实如此。这就是关键。

第三，对任何不可逆操作设置人工 checkpoint。 发邮件、删记录、花钱——由 Agent 起草，人类审批。这不够光鲜，但它把我的"可靠性"从一种期望变成了一套流程。

基准测试的讨论只有一件事有用：筛选候选模型。之后就是噪音了。模型是你技术栈里最不确定的部分，你越早停止假装它不是，你就越早能构建出经得起生产环境考验的东西。

也许我错了。也许存在某个模型可靠到可以充当承重墙。我还没遇到过，而且我已经不等了。我更愿意构建一个模型出错只是带来不便而不是灾难的系统。

这就是基准测试闹剧背后的真正教训。不是"少相信基准测试"，而是"别再构建需要模型必须做对的系统了"。