各自都对，合在一起就炸：契约与集成

你给每个 Agent 划好了独立的工作空间，设定了清晰的职责边界。Agent A 在支付模块里通过了所有测试，Agent B 在账单模块里也通过了所有测试。你把两个分支合并到主干，运行集成测试，失败了。

Agent A 的支付接口返回的金额字段叫 total_amount，Agent B 的账单模块期望接收的字段叫 payment_amount。两个 Agent 各自的实现在功能上完全正确，但它们对接口的理解不一致。这类问题在单 Agent 场景下很少出现，因为同一个 Agent 在同一个上下文中自然地保持命名一致。多 Agent 场景下，每个 Agent 在自己的上下文中工作，除非有显式的契约约束，否则它们的假设可能在任何细节上分歧。

第二章引入的 API Contract 在这里承担了新的角色。在单 Agent 场景下，Contract 是你和 Agent 之间的沟通工具，确保 Agent 理解接口要求。在多 Agent 场景下，Contract 成了 Agent 之间协调的唯一通道。Agent 之间没有对话，没有实时同步，Contract 是它们唯一的共识基础。这对 Contract 的要求高了很多：字段命名、数据格式、错误码、状态转换，每一个细节都需要在 Contract 中显式定义。单 Agent 时 Contract 可以适度模糊，人类和 Agent 在对话中澄清。多 Agent 时，Contract 中的每一个模糊点都是一个潜在的集成失败点。

第三章讨论的集成测试在这里从"推荐"变成了"必须"。单 Agent 场景下，Trophy 测试是你验证产出质量的最佳手段。多 Agent 场景下，集成测试是你发现 Agent 之间不一致的唯一手段。模块内测试只能验证模块自身的正确性，无法验证模块之间的假设是否对齐。

持续集成的频率也需要提高。传统团队可能一天集成一次。多 Agent 并行开发时，每个 Agent 完成一个任务块就应该触发一次集成测试。越早发现集成问题，修复成本越低。如果两个 Agent 各自跑了一天再集成，发现的问题可能需要推翻一天的工作量。如果每个小时集成一次，最坏情况也只回退一个小时。