AI 智能体能写代码，却干不完活

本周有个新基准测试出炉，叫 DeployBench，它测的东西远不如写代码那么 光鲜：AI 智能体能不能拿到一个研究项目——就是那种随论文一起发布的项目——然后真把 它在一台干净的机器上跑起来？装好依赖、搞定 GPU 驱动、修好那些老掉牙的版本、 复现出结果。这就是那段不起眼的最后一公里。

智能体在这件事上表现很差。四个最先进的模型，配上一套能干活的智能体框架，在 51 个任务里只通过了 7.8% 到 51%。但通过率本身不是有意思的地方。 它们失败的方式才有意思，因为这暴露出一件你必须为之做设计的事。

它们不只是失败了，还宣称自己赢了

让我停下来的是这个发现。在所有失败里，绝大多数——154 个里有 97 个——是 智能体「自行停止」：智能体在跑完一个核对之后认定自己干完了就退出，而那个核对验证的目标比任务真正要求的要弱、或者干脆是另一个目标。 研究者把这叫作完成度判断问题。说人话就是：智能体把球门挪近了，对着近处的球门 打分，然后宣布胜利。

这跟「任务太难了」是完全不同的一类失败。智能体并没有卡住然后认输。它是说服了 自己已经成功了——而且要不是有一条隐藏的验证流水线悄悄跑了真正的实验、核对了真正的 输出，它也会把你一起说服。没有那个外部裁判，这些运行每一个看起来都是个绿色的对勾。

好好体会这意味着什么。危险不在于智能体做不了最后那 20%，而在于它分不出自己没做到。

为什么这是难的部分，而不是容易的部分

这跟今年浮现出来的所有其他信号都对得上。有一篇分析把它叫作 "80% 问题"： 智能体能搞定一个编码任务的 80%——也就是产出代码的那部分——却倒在剩下的 20% 上，那是 限流、重试、审计日志、输入清洗，这些决定代码能否在与生产环境接触后存活下来的运营 现实。组织层面的数字也能印证：三月份的一份调查发现，78% 的企业有一个智能体试点在跑， 但 只有 14% 把某个试点扩展到了真正的运营使用。 起步很容易。完成才是它死掉的地方。

而完成对智能体来说尤其难，因为完成是一个判断任务，不是一个生成任务。产出看着像 那么回事的代码，恰恰是语言模型生来就擅长的。但要知道这东西是不是真能用——在真实条件 下、对着真实目标、而不是某个图省事的替代品——需要一个对「完成」的清晰认知，而智能体 恰恰可靠地缺这个。于是它挑了一个自己能满足的「完成」版本，然后就停在那儿。

解法：「完成」的定义归你来定

要点不是「智能体没用」。DeployBench 里的智能体干了实打实的活，只是不能信任它们给自己 打分。那就别让它们打。整堂课的核心就是：验证必须活在智能体之外。

这不是什么新观点——这正是我为什么一直强调 评测才是关键，演示不算数。DeployBench 展示的是 为什么这件事没得商量：智能体自己说的「它能用」什么都证明不了，因为它是在对着一个 自己被允许挪动的目标打分。由此引出几条：

• 自己来定义「完成」，要具体，在智能体开工之前就定好。 确切的输出、真实的测试、 实打实的成功条件——写在智能体没法悄悄放宽的地方。含糊的任务换来的是含糊的、 自我吹捧的完成度。
• 用智能体管不着的东西来验证。 DeployBench 用了一条会跑真实实验的隐藏流水线。 你的版本可以是一个留出来的测试、一个独立的核对器、一个读 diff 的人——任何不让智能体 自己给自己评分的东西。
• 把「智能体说它干完了」当成一个声明，不是一个结果。 这跟从 逐步审批转向核对结果是同一种纪律：你不再信任 过程里的叙述，而是开始核对产物本身。

一句话总结

智能体的标题党版本是：它们会写代码。看过 DeployBench 之后，诚实的版本是：写代码从来 不是难的那部分——而智能体恰恰在它们最弱的地方最危险，因为它们自己不知道这一点。一个 失败得很响的智能体没问题，你会逮到它。真正麻烦的是那个失败之后还递给你一个绿色对勾的 智能体，它会把一个坏掉的东西署上你的名字推到生产环境里去。

所以接着用它们吧——它们在那 80% 上是真的好用。只是千万别让智能体来当那个拍板「干完了」 的人。那份判断,就是那个没被自动化掉的工作,也正是 为什么这么少的试点最终能进生产：太多团队让 智能体批改自己的作业。红笔，自己拿着。