Agent 可信度的基础不是确认消息，而是可重放的证据链

很多 agent 系统最容易给人的安全感，来自一句简洁的确认：“已完成”。再配上正常退出的进程状态、看起来完整的摘要和顺滑的解释，似乎这件事就可以翻篇了。

但在真实工程里，这种安全感往往不够硬。exit code 只能说明进程没有以异常方式结束，不能说明交付物正确；自然语言确认只能说明模型认为自己完成了，不能说明外部世界真的发生了对应变化；摘要可以帮助人快速理解，却不能替代原始的工具输入输出、状态回读和结果凭据。

可靠 agent 的信任基础，不是它更会说“我做完了”，而是每一次关键动作之后，都能留下可寻址、可重放、可验证的证据链。

真正的问题

这类问题表面上分散在 eval、日志、委派、外部动作确认和状态检查里：一次发布有没有真的成功，一个子任务是否真的完成，某个配置是否已经写入，某条消息是否已经发送，某个文件是否真的生成。

底层缺口其实是同一个：系统没有清晰的证据模型。

没有证据模型时，agent 可以生成看起来合理的结论，也可以返回成功状态，却说不清几个关键问题：

成功依据是什么

结果对象在哪里

后续能不能重新定位

下一次运行能不能复核

如果出错，能不能还原当时的现场

这些问题平时不显眼，因为人可以暂时相信一段摘要。但一旦进入调试、handoff、评测或失败恢复，缺失的证据就会变成成本。团队不得不重新猜测现场，重新翻找上下文，甚至重新执行一遍可能已经产生外部副作用的动作。

确认消息不是交付证据

一个常见误区，是把过程信号当成交付证据。

exit 0 是过程信号。它说明命令正常退出，但不说明生成的页面内容正确、数据库记录字段完整、远端服务状态符合预期。

“发布成功”也是过程信号。它可能来自工具返回，也可能来自 agent 对结果的理解，但如果没有页面 URL、记录 ID、状态快照或回读结果，就很难证明这个成功是可定位、可复核的。

漂亮摘要同样不是证据。摘要可以解释“发生了什么”，但不能替代“到哪里检查”和“如何重放”。越是能把结果包装得流畅的系统，越需要防止流畅表达制造虚假的确定性。

真正能支撑信任的，是稳定的结果标识符和机器可读的状态：文件路径、对象 ID、URL、版本号、tool I/O、状态断言、readback 结果，以及当时的假设和不确定性边界。

证据链应该包含什么

可靠日志不应只记录“调用了某个工具”。这类记录对审计和恢复帮助有限，因为它没有回答调用的对象、输入、输出和结果状态。

更有用的证据链，至少应该覆盖几类信息：

做了什么：关键动作、工具名称、操作类型和时间

对谁做的：目标对象、文件、页面、记录、服务或外部资源的稳定标识符

输入是什么：必要参数、上下文假设、版本信息和权限边界

输出是什么：工具返回、错误信息、生成物位置和状态变化

如何确认：readback、状态断言、健康检查或外部系统回查

还有什么不确定：未验证部分、失败分支、跳过原因和后续复核入口

这不是为了把日志做得臃肿，而是为了让证据最小但足够硬。一个未来接手的人，或者另一个 agent，不应该只收到一句“完成了”，而应该拿到能继续定位、判断和复核的凭据。

外部动作尤其需要 readback

只要动作跨出了当前进程，就不能只相信调用返回。

发布文章、写数据库、更新配置、发送消息、创建任务、调整权限，这些动作都涉及外部系统。外部系统可能接受请求但异步失败，可能返回成功但字段被部分丢弃，也可能因为权限、格式或状态冲突产生不完整结果。

所以关键外部动作之后，需要 readback 或状态断言：

发布后读取页面 URL 或记录 ID

写库后确认关键字段值

更新配置后确认生效版本

启动服务后确认健康检查和路由可用

子任务完成后返回可定位的 receipt

readback 的价值不只是“再查一次”。它把“我认为完成了”变成“外部世界以某种可检查方式确认了”。这一步是 agent 从文本协作走向可靠自动化的分界线。

Handoff 里的 receipt

多 agent 系统里，证据链还承担另一层职责：让委派结果可接手。

上游 agent 不应该只收到“子任务完成”。它还需要知道子任务产出了什么、结果在哪里、哪些动作已经对外部世界生效、哪些假设仍然存在、失败时该从哪里恢复。

这就是 receipt 的意义。它不是一段礼貌性的完成说明，而是跨 agent、跨工具、跨运行时传递的最小凭据。没有 receipt，handoff 很容易退化成新的自然语言确认；有 receipt，后续流程才能在同一条证据链上继续推进。

Eval 也应该评过程证据

如果 eval 只看最终答案是否像对的，就很难评出 agent 是否真的可靠。

一个答案可能写得很好，但过程里没有关键工具调用；一个发布结果可能看起来成功，但没有记录页面 ID；一个修复说明可能条理清楚，但没有测试输出、状态回读或失败分支记录。这样的系统在演示里表现不错，在长期运行中却很难维护。

更完整的 eval 对象应该包括过程证据：工具输入输出是否可追溯，外部动作是否有 readback，关键状态是否有断言，委派链是否传递 receipt，失败时是否留下足够恢复的信息。

换句话说，eval 不只是在问“最终回答对不对”，也在问“这条路径是否值得信任”。

最后

agent 的可信度，不能只建立在谨慎措辞、专家口吻或成功提示上。真正可靠的 agent，即使失败，也应该能把失败留成可定位、可恢复、可改进的工程事实。

更好的设计取向，是把 receipt、trace、readback、状态断言和稳定标识符视为同一套机制。每次跨工具、跨 agent、跨运行时，都留下最小但足够硬的证据：做了什么，对哪个对象做的，外部世界如何确认，还有哪些不确定性，后续如何重放或接手。

别只问 agent 是否看起来可信。先问它的行动能不能被重新定位、重放和验证。