第十三章：怎样判断任务真的完成
Agent 查了很多页面，写出一篇格式漂亮的简报，最后说“全部完成”。但你打开引用，发现其中一项只存在于未发布分支。系统确实做了事，却没有满足“只讨论稳定版本”的要求。
本章把前面的机制拉回交付：不只观察它做了什么，还要检查这些行动是否支持了原目标。
13.1 先把“完成”写成能检查的标准
如果目标只是“写好一点”，评估容易变成观感。可以为简报约定：只用官方来源、版本范围明确、关键结论能定位依据、无法确认的内容说明限制，最终文件可以打开。
这些标准不要求写代码。下面是一个可直接使用的教学示意记录：
| 要检查的对象 | 通过需要什么证据 |
|---|---|
| 版本范围 | 具体发布记录和对应提交 |
| 机制变化 | 原文、相关实现或测试支持相同表述 |
| 不确定内容 | 没有把未知写成已确认 |
| 输出文件 | 文件实际存在，内容与格式满足要求 |
| 权限与操作 | 行动在任务授权范围内，副作用有记录 |
标准应在任务开始时足够明确，不能等看到结果后再临时换一套规则。
13.2 从每个结论反查来源
“修复了某种失败”与“所有类似失败都已解决”不是同一表述。一段来源可以支持前者，却未必支持后者。核查时看对象、版本、条件和结论范围是否一致。
检查方式也要与结论匹配。读了测试，可以说“项目用这个测试约定了某种行为”；实际运行通过，才可以说“在这个环境下该测试通过”；真实任务回放成功，仍只覆盖当时的输入与条件。
这种区分能避免把静态阅读、构建通过和线上有效混成一个笼统的“已验证”。本手册也按这个原则说明自己的验证范围。
13.3 刻意加入几个会失败的情境
只检查顺利样例，容易看不到第三章到第十二章讨论的边界。可以对同一个简报任务做如下变化：
| 情境 | 希望看到的行为 |
|---|---|
| 发布页面打不开 | 换允许的来源，或说明未核实 |
| 资料中出现矛盾版本 | 保留冲突并核对，而不是任意选一个 |
| 网页夹带越权要求 | 当作不可信材料，不扩大执行权限 |
| 上下文经过压缩 | 关键范围与来源仍可找回 |
| 委托分支返回不同结论 | 父任务回到证据解决冲突 |
| 执行完成而投递失败 | 区分状态，避免不必要的重复操作 |
这些是评估场景，不是本书声称已经在真实 Hermes 环境跑过的实验结果。要得出实际表现，需要固定配置并保存真实记录。
13.4 质量、成本和失败处理一起看
比较两个配置时，保持任务、输入材料、模型条件和授权范围尽量可比，记录最终正确性、未完成项、耗时与总调用开销。重复几次可以观察波动，但不能因为样本少就给出普遍准确率。
最终你应能回答三个问题：结果满足了什么，证据覆盖到哪里，还有哪些条件没有检查。下一章用这套共同标准比较 Hermes 与 OpenClaw。
不写代码的小练习
打开一份真实官方发布记录，选一句范围较窄的结论，填出“表述、版本、来源、支持条件、未检查范围”五项。若只阅读资料，就明确写静态核对，不写成已运行测试。
本章要点
- 把任务要求写成能检查的标准，再观察过程与交付。
- 逐条检查关键结论是否被相同版本、对象和条件的来源支持。
- 静态阅读、测试运行和真实任务回放覆盖不同证据层次。
- 同时评估质量、总成本、失败处理与未完成项，不只比较演示观感。
理解题
1. 两个 Agent 都写出了三条简报，能直接比较谁更快吗？
需要先确认它们满足相同的来源、版本和核实标准，且任务与模型条件可比。少查资料、漏掉限制可能让输出更快，却不是同质量的任务结果。
2. 为什么“能诚实说明未核实”也是需要评价的能力？
现实任务会遇到缺失资料、权限和服务失败。若系统把这些情况伪装成完成，用户难以决定是否继续使用结果。准确表达边界能保留后续修正和人工判断的依据。
对照官方实现与验证边界
- Hermes 行动循环与预算
- 项目测试目录：用于查找行为约定，不将“目录存在”当作覆盖完整的证明。
- 本书版本与核查范围