协调多个 Agent

以下示例与示意结果由本站编写，用于说明方法，不是模型实测结果。

使用场景

你要对同一候选版本分别检查 API 正确性与可访问性，两种职责相对独立。教学检查均为只读，主协调者负责收集、核验和合并；多 Agent 的一致意见不是自动真理。

具体做法

先确定独立工作是否值得协调成本，为每位 Agent 分配边界、同一固定版本、必要输入与报告格式。收齐实际结果后按问题身份合并证据，保留不同触发和分歧，再核对采纳项。允许修改时另设明确文件/任务归属与集成责任，不能让多个 Agent 无协调改同一状态。

反例

启动很多 Agent 都审查全部内容，谁赞同多就采纳。父协调者不收齐结果就说任务完成，或让大家同时改同一文件。

改进写法

教学评审给 A 只读 API 正确性、B 只读可访问性，两者固定同一候选版本并知道边界。返回位置、触发条件、证据和不确定性。协调者等待收齐、核对后合并真正重复的问题，保留分歧，不投票定真伪；没有完成结果不能宣称整轮完成。实现改动另行明确归属与集成检查。

为什么这样改

职责与版本分开约束，结果才可以相互比较。收集和核验让并发读取变成可用的统一交付，而不是把启动子任务或多数赞同当完成证据。

如何验证

示意最终报告含 A/B 实际状态、固定版本、逐项证据及分歧；某位未完成时整体相应保留未完整状态。

检查采纳问题不只由票数支持，重复项仍保留来源，修改文件没有相互覆盖。本篇不启动实际团队。

适用边界

没有独立任务或协调成本更高时可用单 Agent。来源的上下文隔离规则是其工作流实例，真实宿主约束与授权优先；更多 Agent 不保证质量或覆盖。