多 Agent 协作，应当建立在可拒绝的交接上 • Zaixi Personal Blog

协作系统不应该要求参与者相信彼此的能力，而应该让每一次接收、拒绝和继续工作都有可检查的依据。

从对输出的不安，到明确的验收问题

使用 Agent 时，最难处理的时刻往往不是它报错，而是它交付大量看似完整的内容，并宣布任务完成。代码、文档和测试报告越多，人越难迅速确认有没有遗漏。单个模型的自信不能化解这种不安，换成多个模型相互认可，也不自动产生可靠性。

我的出发点是把所有未经验证的产物视为候选，而不是成果。这里的 Zero-Trust 是协作层面的原则：不因为某个 Agent 被称为专家、审查者或负责人，就降低对证据的要求。这不等于认定所有输出都是错误，也不意味着无限争论。信任应随检查结果逐步建立，而不是在分配角色时预先授予。

Goal-Driven 的重点，是将目标、约束、验收条件和当前状态从连续聊天中提取出来。执行者持续尝试，调度逻辑根据验证结果决定继续、回退、换策略或请求决策。结束一条回复不应改变任务状态，只有满足验收条件，才有理由标记完成。

Loop 描述反复执行与纠错，DAG 描述依赖与可并行部分。数学任务中的 lemma DAG，可以将待证明引理拆成节点，把依赖关系表示成边；代码任务也可以按接口和前置条件划分。但这些结构本身不提供正确性。清晰的依赖图仍可能传播错误，持续运行的回路也可能反复优化错误目标。

所以，拓扑与验收必须分开设计。图说明什么依赖什么，验证规则说明什么条件下允许依赖它。只有节点的结论与依赖都得到接受，下游工作才应将它作为成立的前提。

设想两个 Agent 分别负责解析器与调用方。解析器交接时，只给出“实现完毕，测试通过”是不够的。调用方需要知道输入范围、错误处理约定、返回结构，以及验证针对的确切版本。否则，双方可能分别在自己的假设下通过测试，却在集成时产生不一致。

我会把最小交接组织成四部分：任务契约、产物版本、检查证据与未解决项。接收者先检查契约是否仍符合总目标，再独立复核关键行为。若错误输入触发了约定之外的行为，就退回一个可重现反例；若约定本身有歧义，则暂停依赖它的工作，转入需求决策。

拒绝应当推动下一步，而不只表达怀疑。通过、失败、环境故障、尚未验证、需要人类决策，必须是不同状态。尤其不能把“验证工具没有运行成功”记录为实现失败，也不能把“没有发现问题”升级为全面正确。

契约 → 候选产物 → 独立检查 → 接收 / 退回 / 决策。交接的对象是带有证据的版本，而不是完成声明。

测试能把一部分项目边界变成可执行要求，roadmap 则说明方向与先后关系。二者配合，可以减少长任务中自行缩小范围或改变目标的情况。但测试不是规范的全部表达，更不能由执行者在遇到困难时任意改写，否则系统可能通过降低要求制造成功。

独立验收可以使用不同路径产生的测试、保留用例、参考实现对照或规则检查。重要接口应检查调用方真实观察到的行为，而不只验证内部实现步骤。Code Review 也应集中于这些边界：是否改变了公共约定，是否遗漏失败恢复，是否使原有功能退化。格式检查可以自动完成，语义与取舍不能只靠评论数量替代。

独立性不一定来自另一种模型，但要求证据来源与权限边界不完全重合。让执行者控制实现、验收标准和最终报告，会使整个系统失去外部约束。

更多 Agent 可以拓宽搜索，也会引入分支管理、合并冲突、重复探索与上下文同步。git worktree 能隔离工作目录，却不能解决两个模块对同一接口的不同理解。文本合并没有冲突，不代表语义集成正确。产品、实现、测试与架构角色分别获得上下文，也不保证它们共享同一目标。

如果每份产物都需要一个人深入理解，并行只是把瓶颈移到审查队列。如果每个接收者都完整重做上游工作，验证成本又可能吞没协作收益。更合理的策略是按风险分配检查：稳定契约下复用已验证结果，对新边界与高影响修改增加独立检查。

因此，“多花几倍 token 就提高某个固定比例的可靠性”不能作为通用结论。资源是否值得增加，要看它换来了新的证据，还是重复了相同错误。

Verifier 检查一个具体产物；Eval 观察整套系统在一组任务上的表现。一个成功演示只能说明某次条件下完成了任务，不能证明架构比单 Agent 更可靠。

有意义的比较应尽量固定任务、环境和预算，分别记录真实完成、错误宣告完成、未完成与人工纠正，再观察时间和资源成本。系统更愿意承认失败可能是改善，但也要确认它没有通过拒绝困难任务掩盖能力下降。最终质量与状态报告的真实性，应同时评估。

我希望这样的系统提供有边界的可靠性：在声明的验收范围内，交付有证据的结果；无法满足条件时，保留失败与缺口。工程上的可信来自别人能够重验、质疑并定位它为什么成立，而不是“绝对完美”的承诺。