第二个 Agent 带来了什么信息？
实现者声称最大值函数已经修复，审核者只读这份摘要，也可能认定完成。若审核者拿到原始约定并执行输入 [-5, -2]，就能看到从零初始化的实现返回 0，而正确预期是 -2。这里真正增加的检查依据，是原始用例和执行结果。
让审核者换一个角色名称，并不会自动带来这种证据。相同资料上的不同推理可能发现问题，但不能将一致意见当作独立验证。应明确审核者能看到哪些原件、能运行哪些工具，以及哪些约束由程序检查。
上下文分开了，文件也分开了吗？
两个 Agent 可以各有一份对话，却同时读写同一个目录。实现者与审核者的记忆没有自动同步，共享文件却可能立即影响对方。需要隔离修改时，应明确文件所有权，或使用独立工作区；需要共同编辑时，应增加读取版本与提交校验。
交接包至少写明任务编号、目标、输入引用及版本、允许修改的范围、预算、截止条件和预期产物。返回时保留结论、输出版本、验证证据与未解决问题。共享路径只是定位信息，不能替代“对方已经读取了哪个版本”的确认。
写入冲突与并行收益，都要实际核对
示例中两份工作都从文件 v1 出发。A 提交后，当前文件变成 v2；B 如果直接提交基于 v1 的完整副本，就会覆盖 A 的修改。对照读取版本可以拒绝 B 的陈旧写入，接下来仍要重新读取、合并和复验。版本号或内容哈希负责发现变化，不负责理解两份修改的含义。
| 边界 | 需要确认的事实 |
|---|---|
| 任务分派 | 子任务是否可独立完成，输出是否有明确责任人 |
| 审核交接 | 原始约定、测试依据与当前版本是否齐全 |
| 共享写入 | 读取版本是否仍是当前版本，冲突由谁合并 |
| 结果汇总 | 结论能否对应来源，分歧和失败是否保留 |
| 停止条件 | 预算是否到限，阻塞时向谁返回什么证据 |
为什么增加并行仍可能更慢？
对可独立执行的两个子任务，串行工时可以写为 A+B，并行工时近似为 max(A,B)+交接、合并与复验。例如两个分支分别用 8 分钟和 6 分钟，协调用 4 分钟，总耗时从 14 分钟降为 12 分钟；若协调用 10 分钟，则变为 18 分钟。这只是给定工时的计算，不是模型加速实测。
审核通常要等候待审核产物，不能把“实现与验收”直接当成完全独立的并行分支。调用量也不等于墙钟时间：重复输入上下文、额外工具执行和来回讨论，都可能增加总成本。先保持任务与验收标准一致，再比较单 Agent 和协作方案。
交付结果，也交付还没解决的问题
每轮交接都应该改变可检查的任务状态，例如带回新证据、消除一项分歧或完成一项验证。如果只是在角色之间反复转交同一段摘要，预算仍会消耗，任务却没有推进。达到轮次或调用预算后，应停止并返回阻塞原因、已有证据与下一步责任人。
蝶形装置把任务分派放在入口，上下分支分别展示实现和审核，中央是共享版本联锁，出口保留成果夹与阻塞回执。独立的工时表比较可并行子任务，三轮预算盘展示停止规则。页面运行确定性用例和本地状态对象，没有启动真实 Agent，也不提供自动语义合并。
如果工作无法清楚拆分、第二个角色没有额外证据来源，或交接成本超过节省的工作，可以保留单 Agent 流程。需要协作时，先补齐任务契约、证据链和共享状态规则，再通过相同任务集比较正确性、耗时、调用量与约束违规。