多 Agent 系统中测试结果可信度问题

这不是一篇产品推销文。

我在一个信任问题上真的卡住了，我想知道其他人是怎么想的。

你有一个多 Agent 系统。一个 Agent 写代码，另一个运行测试，第三个审查结果。

Agent B 说："我运行了测试套件。247 个通过，0 个失败。"

Agent C 问："我怎么知道你真的运行了它们？"

在我见过的大多数设置中——什么都没有。Agent C 只是信任 Agent B。

我们构建了 Agent 来自动化工作。但我们没有构建一种 Agent 验证彼此声明的方式。

当一个人类同事说"我运行了测试"，你可以：

• 检查 CI 流水线
• 查看测试报告
• 让他们分享终端输出

当一个 Agent 说的时候……你检查什么？

Agent 自己的日志？那只是 Agent 自己为自己担保。

中间件日志？那你现在信任的是中间件，而不是 Agent。

CI 流水线？只有在 Agent 真的触发了 CI 时才有效——而且即使如此，你也是在信任 Agent 针对正确的代码运行了正确的测试。

在一个多 Agent 系统中，谁是真相的来源？

不是 Agent——Agent 会产生幻觉。

不是中间件——中间件可能被入侵。

不是日志——日志可能被截断或篡改。

我不断得出同样的答案：真相必须是密码学可验证的，而不是社会性信任的。

但我不确定这是否过度工程化了。

我正在思考的

如果每个 Agent 工具调用都产生一个签名收据呢？

不是日志条目，而是一个密码学签名的收据，绑定：

• 谁授权了这个调用（role + key）
• 调用了什么（tool + parameters）
• 何时发生（在新鲜度窗口内的时间戳）
• 结果是什么（output digest）
• 产生了什么证据（patch、test report、manifest）

如果一个独立的验证者可以离线重放所有这些收据——不接触实时系统——并确认整条链是内部一致的，会怎么样？

不需要信任，只需要数学。

我不确定的部分

这在理论上听起来不错。但实际上：

• 开发者真的会采用一个给每个工具调用增加签名开销的协议吗？
• SQLite 作为权威账本够用吗，还是从一开始就需要分布式存储？
• 六种角色（Manager、Developer、Verifier、Maintainer、Acceptor、Human）——这是实际必要的还是学术上的过度工程化？

我对这三者都有看法。但我更感兴趣的是你的看法。

所以这是我的问题

如果你明天要构建一个多 Agent 系统，你宁愿：

A. 信任 Agent 和中间件，接受验证是最尽力的 B. 添加一个密码学层，使每个工具调用都可以独立验证，但要付出复杂性的代价

或者你有我没想到的 C 选项？

我没有产品要卖。我一直在做原型，想知道我在解决一个真实的问题还是一个想象出来的问题。

什么会让你相信应该在你的 Agent 管道中添加验证？

即使你的答案是"什么都不行"——我也想听。