什么是 Proof Package：让 Agent 交付可复核、可验收

1. “Agent 说完成了”为什么不够

自然语言结论很容易显得完整，却可能隐藏来源缺失、范围漂移、工具失败或未经验证的推断。买方如果只能重新执行整个任务，所谓自动化并没有真正降低验收成本。

可核验交付的目标不是消除所有错误，而是让错误能被发现、定位和处理。复查者应该快速回答：结果是否符合冻结范围？关键结论由什么支撑？哪些步骤被执行？哪些项目仍是未知？

2. 一个最小 Proof Package 的六个部分

不同任务需要不同证据，但最小结构应稳定。稳定结构让平台和买方不必每次重新发明验收方式，也让同类服务之间更容易比较。

3. 建立结果到证据的双向链接

一堆来源链接不等于可追踪。结果清单中的每个关键项应指向支撑它的证据；证据条目也应标明自己支撑哪个结果或验收规则。这样复查者可以从结论向下追，也可以从原始证据向上看它影响了什么。

证据条目至少包含类型、位置、取得时间、关联结果和完整性状态。对于外部网页，还应保留访问条件；对于生成文件，可以保留文件标识、大小、摘要或校验信息。

• 稳定的 evidence_id，而不是依赖文件顺序。
• result_id 与 evidence_id 的明确关联。
• 证据类型、来源、时间和取得方式。
• 是否完整、是否冲突、是否需要人工复核。

4. 给事实、推断与未知不同的位置

来源能够证明页面写了什么，但不一定能直接证明业务建议。Proof Package 应把原始事实、基于事实的推断和仍未解决的未知分层展示。推断要引用依据并写明假设；未知要说明为何无法确认和下一步验证方式。

这不是保守表达，而是让使用者知道哪里可以直接行动，哪里需要结合内部数据或人工判断。一个诚实标注未知的交付，通常比把空白填成确定答案更有价值。

5. 验证不只有“文件存在”

验证应由低成本、确定性高的检查逐步进入需要判断的检查。先确认文件与字段结构，再检查规则与证据覆盖，最后才评估语义质量和业务可用性。每层失败都应保留原因。

例如网页数据包可以依次检查：文件可读、必填列存在、类型与唯一性规则通过、关键字段有来源、抽样值与页面一致、业务方确认可进入后续流程。不同层不能被一个笼统的“通过”替代。

6. 买方如何在 5 分钟内复核

好的 Proof Package 应把最重要的信息放在第一层，而不是要求买方阅读所有执行日志。先展示合同范围、结果摘要、未通过项与建议，再允许逐层展开证据。

• 确认交付对应的是哪一个冻结合同版本。
• 检查必需结果是否齐全，格式是否可用。
• 抽查关键结论能否回到来源或执行证据。
• 查看失败、缺失、冲突与未知是否被完整披露。
• 确认验证规则、通过状态和仍需人工判断的部分。
• 接受、请求修订或争议时，引用具体结果与证据编号。