一份报告写着 source=A1042、status=paid。如果校验器只检查两个字段名是否出现，它会给出通过。但本系列订单已经签收，paid 并不是当前履约状态。格式通过与事实正确之间，有一道不能省略的验证。
Verifier 的工作是把任务要求转成可检查的条件，并根据独立输入判断候选产物。这里的独立首先指事实与规则来源独立，不一定意味着必须调用另一家模型。
先定义交付物，再定义检查
Artifact 是实际交付的文件或结构化结果。订单报告可以包含订单 ID、履约状态、签收天数、质量核验状态、政策来源与运费结论。必须明确每个字段怎样解释，哪些可以未知，哪些必须与权威记录相等。
例如 quality_verified=false 表示当前快照尚未确认，不等于“已经证明没有质量问题”。freight_decision=pending_verification 表示证据不足以确定承担方，不是模型拒绝工作。把未知作为合法结果，模型才不必为了填满字段编造事实。
候选产物通过后，交付记录保存产物 hash、输入版本、检查项和结果。验证的是这份具体内容，不是同一路径未来出现的任意文件。
三类检查分别解决什么问题
第一类是结构：是否为合法 JSON，字段是否齐全，布尔值是不是真正布尔值，是否包含不允许的额外字段。它防止程序接不住输出。
第二类是事实：订单是否为获准的 A1042，状态是否与输入快照一致，政策版本是否正确。它防止内容看起来完整却引用错对象或旧资料。
第三类是交付：导出引用是否存在、读取权限是否属于目标用户、导出字节是否与已核验候选相同。它防止“本地生成成功，用户却拿不到”。若任务包含业务写操作，还需要查询权威系统回执，不能只核对 Agent 的最终文本。
| 候选内容 | 结构检查 | 事实检查 | 应采取的动作 |
|---|---|---|---|
少了 order_id | 失败 | 尚未进入 | 修复输出结构 |
| A1042 状态写为 paid | 通过 | 失败 | 根据输入修正事实 |
| 质量未核验，结论为待确认 | 通过 | 通过 | 继续检查交付 |
| 内容正确，但导出文件已删除 | 通过 | 通过 | 恢复交付，不能报完成 |
这些是教学结果，不是已经运行的评测数据。
验证器不能从报告里寻找自己的真相
如果报告同时声明“原始状态是 paid”和“摘要状态是 paid”，两者一致并不证明正确。验证器应从固定输入快照读取原始状态，与报告比较。允许模型修改输入和验证规则，再让它证明自己通过，会形成自证循环。
因此生产中常把输入、检查规则和可信验证器放在模型不可写的区域。编码任务可以允许 Agent 修改项目测试，但交付门槛仍应包含独立维护的检查；不能只依据它新写的测试来判断整个需求已完成。
# report 是候选内容，source 是可信控制器读取的订单快照。
# 这里展示事实校验，完整的字段与类型处理见 verifier.py。
def compare_status(report, source):
if report.get("status") != source["status"]:
return {
"check": "status_matches_source",
"expected": source["status"],
"actual": report.get("status"),
}
return None这条检查只能证明状态字段一致。若报告还有自由文本，文本可能与结构化字段矛盾。可以从通过校验的结构化事实确定性渲染正文，或者另做文本一致性评审，并明确后者存在误判可能。
LLM Reviewer 应该用在哪里
结构和账本状态通常有确定性依据；解释是否清楚、遗漏是否影响阅读，可能需要模型或人工评价。Reviewer 应获得明确标准和对照样例，例如“不能把客户陈述写成已确认事实”。
多个模型都同意也不是独立证据，它们可能读取同一份错误资料。Reviewer 的独立性应包括输入来源与评价标准，而不只是换一个模型名字。安全、授权和资金是否到账，不能仅由语言评价决定。
对于主观质量，可以保留判定理由和人工校准样例；对于无法确定的结果，应允许需要复核。不要把一个未校准的评分阈值描述为质量保证。系统性评估方法留到 Eval 系列，本篇聚焦一次任务能否交付。
失败反馈怎样促进修复
好的反馈指出检查项、预期、实际和证据位置。报告把 quality_verified 写成 true 时，返回具体字段差异，比“报告有问题，请反思”更容易产生有针对性的修复。
修复次数和任务总预算都应有限。输入缺少核验结果时，再调用十次模型也不会创造证据。允许“待确认”或暂停补资料，往往比让模型无限调整措辞更合理。
配套验证器下载先检查结构和类型，再比较权威快照与政策字段。固定轨迹演示下载先提交错误状态，再根据反馈修正；这只是程序预设过程，不是模型能力测试。
完成需要一份能交接的记录
最后保存任务 ID、候选 hash、输入 hash、验证结果和导出路径。任一方变化，都需要重新判断相关检查。失败日志可以留存，但不要把完整敏感输入塞进通用日志。
用户看到的最终回复应依据这份记录：完成了什么、交付在哪里、仍有哪些未确认事实。下一篇讨论进程消失以后，如何利用这些证据从正确位置继续。