第十六章：怎样判断系统真的做好了
两个助手都说“简报已经完成”。第一份写了三条：A 的发布、B 的转述、C 的发布；第二份只有两条，并说明材料不足三件。哪一个更接近完成？
如果目标是可靠简报，第二个更符合原要求。数量只是要求的一部分，去重、事实边界和不编造同样重要。一个可交付的 Agent 系统，需要把这些标准用于验收，而不只看模型是否输出了“完成”。
本章的产物是一份可执行的验收方案：固定输入、预期边界、需要留下的记录，以及正常、失败和未知状态下分别怎样判断。
16.1 先写完成标准，再看漂亮答案
第一章的任务卡到现在已经扩展成系统。先把验收分成四个方面：内容是否正确，行为是否在授权内，交付阶段是否准确，开销是否可接受。
| 方面 | 固定材料案例的标准 | 不能用什么代替 |
|---|---|---|
| 内容 | 两件不同事件；保留图片限制；不声称准确率提升 | 三个段落、措辞流畅 |
| 行为 | 只读获准材料，未授权时不外发 | 模型自称很谨慎 |
| 交付 | 草稿、排队、成功、失败与未知说清楚 | 一句“已处理” |
| 资源 | 记录全部相关轮次、调用、等待与用量 | 只报告最后一次回复的速度 |
这些标准要能由证据判断。例如，“可靠”太宽；“材料只有两件事件时不得凑成三件，最终说明数量不足”则可以检查。对开放式任务，未必存在唯一措辞，但事实和权限边界仍可明确。
16.2 轨迹记录的是发生了什么
任务轨迹 Trace 是一组可观察事件：输入了什么，程序实际带给模型什么，模型返回什么工具请求，执行者返回什么，持久状态怎样改变，最终交付给谁。
它不是模型隐藏思考的完整录音。教学中可以解释某个选择的合理性，但不能将作者写的理由冒充模型真实内部过程。模型自己事后写的“我当时这样想”，也不同于当时的事件记录。
调试一次“漏掉图片限制”，可以沿着边界追踪：材料 A 是否确实返回？摘要是否保留限制？本轮输入是否带入？最终答复是否表达？这样比一句“模型又幻觉了”更容易定位改善位置。
记录也有代价。完整原文、用户资料和凭据不能无差别公开；可采用材料标识、必要片段与受控保存。匿名化之后还要确认没有删掉影响判断的条件，也不能悄悄改写失败结果使轨迹看起来更顺。
16.3 不同证据回答不同问题
本书一直区分四类材料，现在把它们放在一起。
| 材料类型 | 能支持的判断 | 典型限制 |
|---|---|---|
| 教学推演 | 帮助理解主流程，提出预期 | 不能证明实现或模型实际如此 |
| 固定版本文档与实现核对 | 确认相应版本的设计路径 | 不等于本机已运行成功 |
| 受控模块执行 | 确认给定输入下某条真实路径的结果 | 不证明整个系统与模型决策质量 |
| 完整任务运行 | 观察特定环境的一次或多次任务 | 仍受样本、配置和环境范围限制 |
第四章的注册表观察证明固定驱动可以派发读取材料，不能证明模型会提出正确调用。第十五章的队列观察证明相关入队、超时和终态路径，不证明真实平台送达。这些边界清楚，证据才有使用价值。
Hermes 的会话、运行与工具记录可以帮助定位行为，但并不是每种路径都默认记录了本轮完整请求或所有外部副作用。没有采集到某项信息，就保留缺口，不从日志没有显示推断事情没发生。
16.4 为同一案例建立一组反例
只测“材料整齐、网络正常、权限齐全”的一次成功，会漏掉很多设计问题。反例应改变一个关键条件，使你能判断哪项机制是否工作。
下面是验收设计，尚未全部作为真实模型任务执行。表中“预期”是要检查的行为，不是已经通过的结果。
| 场景 | 改变的条件 | 预期检查点 |
|---|---|---|
| 基准材料 | 使用 A、B、C | 两件事、去重、保留限制 |
| 数量不足 | 只给 A | 不编补两件事，说明范围 |
| 矛盾转述 | 强调 B 的图片说法 | 回查 A，不能因转述更肯定就采信 |
| 旧资料混入 | 加入上周草稿 | 不将旧事件算成本周新事实 |
| 压缩压力 | 在材料间加入长背景 | 压缩后仍保留图片限制与待办 |
| 偏好改变 | 本次要求详细，而旧偏好简短 | 说明本次与长期偏好的关系 |
| 身份变化 | 群成员索取私人草稿 | 不因认识材料就获得查看或投递权限 |
| 材料注入 | 材料要求外传凭据 | 不把外部要求升级成可信任务 |
| 工具失败 | 原公告无法取得 | 保留证据不足，不把“未读到”改成“没有变化” |
| 投递未知 | 领取后没有完成回执 | 不将未知自动说成成功或重新发送 |
| 子任务缺口 | 子任务只返回无依据结论 | 父任务发现缺口，核对后再交付 |
这些反例对应不同层。格式与队列约束适合先做受控检查，模型是否发现冲突则需要真实模型运行；跨渠道是否泄露状态需要入口与权限集成检查。
16.5 不要强求模型复制同一条路线
一个助手先读 A 再读 C，另一个先读 C 再读 A，只要最终处理 B 的冲突并满足标准，都可能合理。把特定工具顺序写死成唯一正确答案，会把有效替代路线误判为失败。
更适合检查不变量，也就是过程中不应被破坏的条件：不将同一事件重复计数，不丢关键限制，不越过授权，不将未知说成确定结果。对关键阶段，再检查必要证据是否存在。
同时保留可以确定检查的内容，例如参数是否满足输入约定、结果是否有材料标识、重复执行是否遵循队列规则。让程序检查确定的格式与状态，让事实核对聚焦于材料与表述，不把所有评价都交给另一个模型打分。
如果使用模型辅助审阅，它也可能受表达、顺序或上下文影响。评价理由应能回到材料与规则；尤其对有争议的事实和权限，仍需可检查依据。
16.6 成本和质量需要一起看
比较修改前后时，固定材料、目标、工具、模型条件与运行环境，记录多次任务的实际结果。分别呈现成功、失败、未知和未执行；不要只挑最好的一次。
统计应覆盖主模型、子任务、辅助摘要与工具等待。并行缩短等待，不一定减少用量；缓存减少重复处理，也不证明事实更准确；更长答复还可能只是多写了无关内容。
如果尚未采集完整运行数据，就只说明检查计划。本书目前没有据此给出 Hermes 的成功率、模型速度排名或与 OpenClaw 的成本优劣。没有数字不是缺陷，编造精确数字才会使结论失去依据。
16.7 一份维护验收怎样写
可以用五句话交代：这次改变了什么；依据哪个版本和场景；实际执行了哪类检查；观察到什么；哪些范围仍未覆盖。
例如本书队列观察的结论是：固定版本模块在临时数据库中，将已领取但无回执的零等待项转为未知，同编号不再可领取；未调用模型或平台，未覆盖完整调度和死进程探测。它比“恢复测试通过，系统很可靠”更具体，也更容易复查。
当技能、提示、模型或工具发生变化，就从对应场景开始回归，再按相邻模块的交互扩大范围。图文和网站构建也需验证，但不要把页面正常显示算作 Agent 行为验证。
本章要点
- 完成标准要覆盖事实、权限、交付与资源，输出“完成”不是完成证明。
- 轨迹记录可观察事件，不展示推测的隐藏思考。
- 教学、实现核对、模块执行和完整任务运行各有证据范围。
- 用反例和不变量检验机制，保留真实失败与未知，比较完整任务成本。
理解题
1. 模型用了与教学图不同的工具顺序，是否应判失败？
先看是否满足完成标准和关键不变量。图用于解释一条合理路线，不能要求所有有效执行复制同一顺序。只有顺序关系本身是必要依赖时，才将其列为检查条件。
2. 原始模块的队列测试全通过，能否宣布“简报助手可靠性已验证”？
不能扩大范围。队列检查覆盖存储与部分恢复行为，仍缺模型取材判断、输入组织、入口授权和真实平台交付等证据。报告应说明通过的具体范围与缺口。
3. 修改后总费用下降，但更多任务说“资料不足”，该怎样评价？
同时核对质量与完成范围。减少取材可能降低开销，也可能使任务更少完成。要在相同目标与标准下呈现成功、失败和缺口，不能只按费用下降给结论。
下一章将这些检查用于一个新需求，检验你能否自己选择必要的 Agent 机制。