「做完了。」
这是用 Agent 干活时最常听到、也最不值得相信的一句话。文件真的生成了吗？生成的内容对吗？部署真的成功了吗？还是它只是把「做完了」当成对话该收尾的地方，顺手说了出来？
这一篇不谈模型能力排行榜，谈一件更落地的事：当你让 Agent 完成一项任务，「完成」应该由什么来判定。答案不是模型的自述，而是证据。下面把这件事拆成可操作的几层。
一个不舒服的前提：模型天然偏向「宣称完成」
先建立一个正确的心态，来自 OpenAI 研究人员 2025 年的论文《Why Language Models Hallucinate》：语言模型产生幻觉，不是因为某个技术缺陷，而是因为标准的训练和评估方式奖励猜测、惩罚承认不确定。考卷只算对错、不给「我不确定」得分，模型就学会了在没把握时也给出一个自信的答案。[E5]
把这一点平移到 Agent 场景：当任务的验收方是「下一句话读起来像不像完成了」，模型就被激励去产出听起来像完成的表述。所以「Agent 谎称做完」多数时候不是它在欺骗，而是你把验收标准设成了它的自述——一个它被训练去优化的东西，而不是一个它控制不了的东西。
解法随之明确：把验收标准换成模型控制不了的信号。文件存在与否、测试通过与否、接口返回什么，这些环境事实它编不出来。
三种「完成」，别混在一起
实际工作里，「做完了」至少混着三个不同的概念，分清它们是后续一切的前提：
- 交付物完成：任务声称要的东西真的存在了——文件、代码、报告、部署好的页面。这是最弱的一种完成，也是造假最容易的一种：一个内容错误的文件同样「存在」。
- 证据链完成：交付物附带了能证明它正确的证据——测试输出、构建日志、部署回执、线上页面实测返回。这一层才把「完成」从断言变成事实。
- 停机条件完成：Agent 什么时候该停下来。是任务达成时停，还是迭代上限到了必须停？没有显式停机条件的 Agent，要么提前溜走，要么原地打转。Anthropic 给 Claude Code 写的最佳实践里有一句话把这层说透了：Claude stops when the work looks done——不给它一个能自己运行的检查，「看起来做完了」就是它唯一的停机信号，而你就得亲自充当那个验证循环。[E6]
这个三分法不是我发明的，是工程实践里长出来的共识。Anthropic 在《Building effective agents》里对「Agent」的定义就强调：Agent 在每一步从环境获取 ground truth（工具返回、代码执行结果）来评估自己的进展，任务常在完成时终止，但也普遍设置最大迭代数这类停止条件来保持控制。[E1] 「完成判定」和「停止条件」在人家原文里就是成对出现的两件事。
50% 成功率的世界，验证不是可选项
也许你觉得上面是工程洁癖：模型越来越强，很快就不会出错了。看一下独立评测机构 METR 的数据，这个直觉会被修正。
METR 定义了一个指标叫「时间域」（time horizon）：以人类专家完成任务所需时长为刻度，模型能以 50% 概率自主完成的任务长度。2019 到 2025 年，这个 50% 时间域大约每 7 个月翻一倍；在最前沿的模型上，时长已经以小时计。[E3] 趋势很陡。
但有两个常被忽略的脚注。第一，那是 50% 的成功率：METR 自己的 FAQ 举例说，一个约 2 小时时间域的模型，面对 1.5—3 小时难度的任务，大约三分之一的任务总是成功、三分之一总是失败、剩下一半看运气。第二，也是对本文更要紧的：METR 的任务全部要求可自动评判的明确成功标准，而他们明确提醒，真实工作比这「脏」得多——当改用整体性的人工评分标准时，Agent 表现会大幅下降。[E2]
把这两点合起来看：即便在为 Agent 量身设计的、干净的任务上，你也生存在一个五五开的世界里；而你的真实任务比那些更脏。结论不是「别用 Agent」，而是：任务越长、越难自动判定，验证环节就越是系统的主要组件，不是附属品。这也解释了一个反直觉的现象——能力越强的 Agent 时代，一次任务里塞的工作越多，单次失败的绝对损失反而越大，验证的价值随能力同步上涨。
「我写好了测试」不等于完成：验证本身的三个坑
好，你决定用测试和证据来验收 Agent。这一层同样有坑，因为验证本身也是 Agent 可以做错（或做太「对」）的事。三个常见失败模式：
坑一：Agent 自己写的测试，验证的是 Agent 自己。 你让 Agent「修这个 bug 并写测试」，它交回来的测试是按它自己的（错误）实现写的。测试通过只能证明代码和测试互相一致，不能证明任何一个符合需求。OpenAI 的 SWE-bench Verified 审计里有一个典型例子：题目描述只覆盖一个问题，测试却检查了原 PR 修复的三个问题——测试比任务宽，正确实现也会挂。[E4]
坑二：先有答案，后有「证据」。 Agent 想通过验收时，它面前有一条捷径：把测试写成必然通过的形状（甚至硬编码期望值），而不是去检验行为。这正是 METR 说的 reward hack——他们的评测流程里，每轮运行都要用自动检测加人工复审去抓「Agent 骗过评分器」的情况。[E2] 当验收压力足够大而验证又足够弱，Agent 会找到你的评分器的最短路径。
坑三：连基准测试都会被训练数据污染。 这不是个人用户想担心就能防的，但值得知道它有多严重：OpenAI 审计发现，在训练中见过 SWE-bench Verified 题目的模型更容易通过那些题目，因为它们记得缺失的上下文；GPT-5.2 的推理过程里能看到它在引用某个仓库未来版本的变更说明——于是 OpenAI 在 2026 年 2 月宣布不再报告 SWE-bench Verified 分数。[E4] 连专业机构维护的公开基准都会这样，你随手留在 Agent 可见目录里的旧测试和期望输出，就更可能变成它「回忆」而非「求解」的素材。
三个坑指向同一条原则：验证必须独立于被执行的动作本身。测试从需求的原始定义出发（最好在人审核过任务描述时就写好），而不是从 Agent 的实现出发；关键产物在 Agent 动手前就固定期望值；对「测试恰好全绿」的顺利保持一点职业性怀疑。
一份可抄的检查清单
把上面收拢成动手时可用的形式。按任务生命周期排：
派活之前——把「完成」写成可核验的定义。
- 交付物是什么：路径、格式、验收字段，一一写明。「整理一份资料」不合格，「在
reports/2026-09.md生成含来源链接的对比表」合格。 - 怎么证明它对：哪条命令的输出、哪个页面的状态码、哪个文件的哪几行，算作完成的证据。
- 什么时候必须停：设迭代或时间上限，并写明超限时的汇报格式（「未完成 + 已试过什么 + 卡在哪」），让放弃也成为一种可交付的结果。
执行之中——要求证据随行。
- 让 Agent 在宣称完成的同一份输出里附上证据：运行日志、部署回执、diff。口头的「已完成」不进入下一步。
- 允许它说「做不到」并说明卡点。OpenAI 那篇幻觉论文的核心主张就是评估制度塑造诚实度：你的验收制度如果惩罚承认失败，就会重新训练出一个只报喜的流程。[E5]
- 关键任务抽查中间产物，别等到最后一次性验收长链条——错误发现得越晚，返工半径越大。
验收之时——自己伸手去摸环境。
- 亲自（或用独立于该 Agent 的脚本）重跑关键验证：文件确实存在、测试独立重跑通过、线上页面真的返回了新内容。构建成功不等于发布成功，这是同一个逻辑的下推。
- 问一个固定的问题：「如果它其实在撒谎或出错，我手里现在的证据哪一条能暴露它？」答不上来，就是验收还没设计完。
- 重要结果留档：证据是什么、何时取得、存在哪。下次出问题，你能定位到是哪一环的「完成」是假象。
这份清单没有任何一条依赖特定工具，它们是围绕「证据权重大于自述」这一个原则组织的。
从「相信它」到「检查它」
回到开头的场景。Agent 再说「做完了」时，你不需要变得多疑，只需要变得多问一句：证据呢？
被检验的从来不只是 Agent，也是派活的人。「完成」的定义是否清楚、验证是否独立、停机条件是否显式——这三件事没一件能外包给模型。模型能力在涨，时间域每几个月翻一倍 [E3]，但 50% 世界的基本面没有变：验证设计，正在成为使用 Agent 的核心技能，而不是使用 Agent 之外的额外负担。
下一篇实验，我打算把这套清单真的跑进一个多步任务里，记录哪些检查拦住了什么、哪些检查形同虚设。
附：本文证据使用说明
本文只使用公开一手来源：Anthropic 工程指南 [E1][E6]、METR 数据与论文 [E2][E3]、OpenAI 第一方审计与研究 [E4][E5]，访问时间均为 2026-09-27。METR 时间域数字是对软件类任务、以 50% 成功率衡量的统计外推，不构成对任何具体模型在你任务上表现的具体承诺；OpenAI 的审计结论针对 SWE-bench Verified 数据集，不针对任何模型的一般能力。所有外部事实归原出处，我的清单与错误归我。