多 Agent 协作1. 本章核心多个 Agent 为什么值得协作多 Agent 的价值取决于分工是否有效、是否引入新证据以及质量和速度的收益能否覆盖额外成本。第五章关注单个 Agent 如何“生成—执行—验证”第十章把这个闭环扩展为多个角色之间的协作新增的问题是任务怎样拆、信息怎样传、谁来验收、冲突怎样处理、什么时候结束。三个重要判断多个实例不自动意味着多种思路。同一模型、相似提示词和相同证据可能产生相同错误。审核者的价值往往来自执行测试、查看截图、查证资料等新增证据。并行可以缩短等待时间但通常会增加总 token 和协调开销。1.1 什么时候值得拆分场景可能的收益需要核对的条件生成者写代码审核者运行测试发现生成阶段未知的错误测试是否可靠、是否覆盖需求生成者写 PPT审核者看渲染截图发现溢出、拥挤等视觉问题是否真正渲染了当前版本多个 Agent 搜索不同资料源扩大覆盖面、降低等待时间来源是否互补、结果能否验证各自处理独立章节或模块控制上下文规模、并行工作接口和全局约定是否清楚同一批 Agent 反复讨论同一文本可能补充分析角度应与等预算单 Agent 对照原文把“新信息”作为核心判断框架。学习时还应区分提高推理正确率、缩短延迟、隔离权限、控制上下文是不同收益不能用一个指标替代全部评价。单 Agent 也能使用外部反馈因此“反馈有效”本身不能证明“必须多 Agent”。2. 两个独立的架构维度2.1 维度一上下文是否共享比较项共享上下文独立上下文历史信息继承前序轨迹只接收明确传递的信息主要优势保留细节交接方便职责专注、上下文可控、便于隔离主要代价上下文膨胀、角色惯性信息遗漏、状态同步、接口设计适合场景紧密衔接的阶段转换并行任务、独立审核、专业分工独立上下文不等于完全不共享信息。Agent 仍可通过工具参数、文件和消息交换任务、证据与产物。2.2 维度二协作拓扑拓扑控制权如何流动典型任务主要风险对等协作少数角色按约定互相反馈起草与审核、方案讨论同质错误、反复争论管理者模式Manager 拆分、派发、验收和整合书籍翻译、并行检索规划瓶颈、中心故障去中心化各 Agent 自主移交或响应消息动态协作、开放角色网络路由成环、责任不清这两个维度不能混为一谈共享对话记录也可以由中心调度独立上下文也可以由一个 Manager 统一管理。去中心化移交Agent AAgent BAgent C管理者模式Manager子 Agent 1子 Agent 2对等协作提议者审核者最后一种图中的环路表示可能的控制流实际运行需要访问链、预算和终止条件不能任由任务空转。2.3 角色切换与 Skill原文对比了两种方式替换系统提示词和工具集角色职责及工具可见性随阶段改变但变化后的请求前缀通常需要重新处理。保持前缀稳定、按需加载 Skill角色规程作为后续内容进入轨迹有利于复用已有前缀但行为指令不能替代硬权限。记忆方法知识、流程、风格的差异可以通过加载规程表达权限差异必须由运行时实际限制。仅隐藏工具名称也不能代替后端授权校验。3. 协作基础设施数据平面与控制平面3.1 数据平面产物放在哪里区域用途权限和生命周期私有工作区 Scratchpad草稿、调试日志、中间结果单个 Agent 使用通常随实例结束清理共享工作区代码、术语表、报告等协作产物协作成员按授权访问需持久化和并发控制外部挂载资源云盘或业务系统的数据遵循外部系统的授权和生命周期系统内置资源模板、工具说明、公共规程稳定、只读共享文件用于承载大内容消息传递文件引用与摘要避免每次交接都重复塞入完整产物。工程补充路径只有在接收方能解析且有权访问时才有效。跨机器、跨组织传递时往往需要可授权访问的产物标识或地址本地路径字符串本身不提供互操作能力。3.2 三种通信方式方式适合的内容特点工具调用参数明确的子任务与结构化输入接口直接便于参数校验共享文件大型产物、长期进度可持久化但要管理并发写入消息总线异步进度、事件和终止通知生产者与消费者解耦消息总线解决传输和路由不能自动解决语义误解、重复消息或权限问题。3.3 控制平面谁在做什么什么时候停四项职责消息传递任务分配、进度、结果、错误与终止通知。状态管理执行中、等待输入、完成、失败、取消等状态。执行终止优先发送取消信号等待安全点清理资源超时后强制终止。资源调度限制总预算、并发数和派生深度根据进展调整资源。轻量进度文件适合日常协调完整轨迹适合诊断。长时间无更新是“可能卡住”的信号还需结合心跳、工具运行状态和预期耗时判断。父 Agent 取消时默认沿创建关系取消子 Agent避免遗留无人管理的任务。需要长期后台运行的任务应显式建立独立生命周期。3.4 与操作系统的类比操作系统概念Agent 系统对应物程序系统提示词与工具定义进程内存轨迹和状态CPULLM 推理服务内核Agent 运行时系统调用工具调用创建、终止、列出进程创建、取消、发现 Agent共享内存与消息通信共享文件与结构化消息类比的作用是借用隔离、调度和容错经验。上下文独立不代表没有资源竞争Agent 仍可能争抢同一文件、浏览器、GPU 或 API 配额。4. Loop 工程由证据决定是否完成原文列出三种过早结束假完成只完成部分任务就宣布全部结束。过早放弃一条路径失败就放弃整个目标。假成功把中间信号误当最终结果例如口头同意退款但实际流程尚未完成。Loop 工程将“寻找下一步—执行—验证—记录”变成显式循环。关键原则是模型可以提出完成但完成状态要有独立证据支持。原文框架重点应学习的机制LoopX跨轮次的持久控制面目标、门禁、进度、证据与配额分离LongHorizon-HarnessManage–Execute–Audit规划有界任务、执行、只读审计再更新可信状态已核实状态帮助系统跨上下文继续工作但环境或需求变化后旧证据也可能失效。验证失败应形成下一轮的具体输入而不是被丢掉后重新盲试。5. 三段核心伪代码解读5.1 提议者—审核者循环原文逻辑可以简化为生成候选结果 → 执行或渲染采集真实证据 → 独立审核 → 不通过且有预算按缺陷修复再执行、再审核 → 明确通过交付 → 未通过或预算耗尽拒绝、移交或报告未完成关键变量变量或函数含义candidate当前候选产物execute_or_render运行测试、渲染页面或读取真实状态evidence本轮产物对应的验证证据review.findings可定位、可修复的缺陷清单budget_remaining是否还有继续修复的资源每次修改后都重新采集证据旧版本测试通过不能证明新版本通过。审核者也不能自行降低门槛或修改测试来批准结果。代码阅读提醒原文的review.pass使用了 Python 保留字pass不是合法的 Python 属性访问写法实现时可改为review.passed或review[pass]。其余函数、审核对象和预算更新也需要自行实现因此该片段应按伪代码理解。工程补充用passed / failed / inconclusive等明确状态比两组可能互相矛盾的布尔值更容易管理。执行异常、审核异常及证据缺失均不应默认为通过。5.2 并行任务“第一个已验证成功”结算原文管理器的顺序是启动多个独立 Worker → 收到结果事件 → verify 验证结果 → settle_once 原子占用结算权 → 取消其余 Worker → 等待取消确认或超时 → 汇总并返回为什么先验证再取消第一个报告成功的 Agent 可能找错了目标若立即停止其他搜索就失去了正确结果的机会。为什么需要settle_once两个结果可能几乎同时到达。锁、事务或原子状态转换保证只有一个结果触发结算幂等机制保证重复事件不会再次产生副作用。为什么还要等待确认发出取消通知不代表子任务已停止。子任务需要关闭浏览器、释放资源并返回确认。适用边界此模式适用于“任意一个合格结果即可完成任务”。如果要求汇总全部学院、完整覆盖资料或找出最优方案不能找到第一个结果就全员停止。工程补充原文按workers.any_running控制循环真实实现还应处理“最后一个 Worker 已结束但结果仍在队列中”的情况结束判定需要兼顾终态和未消费事件。还需处理重复消息、迟到结果、验证超时和取消失败。搜索结果也应区分“已完整检查且未找到”和“网站无法访问、尚未完成检查”不能把执行失败当作目标不存在的证据。5.3 去中心化 handoff结构化移交移交包至少包含字段用途task_id、发送者、接收者识别任务和路由goal、constraints说明目标、边界和验收要求accepted_facts已确认事实及必要来源artifact_refs产物引用按需读取remaining_budget约束剩余资源visited_agents记录访问链辅助循环检测原文规则是接收者已经出现在访问链中则拒绝预算耗尽则停止否则加入访问链并继续执行。代码阅读提醒原文{task_id, sender, ...}在 Python 中会被解释为集合表达式不是带字段名的字典实际实现要写成{task_id: task_id, ...}。handoff.visited_agents则需要对象类型支持普通字典应使用键访问。工程补充禁止回访是一种简单而严格的防环方式也会禁止合理的“开发 → 审核 → 开发”修复。更细的设计可以记录任务阶段、版本和移交次数允许有新证据的返工拒绝没有进展的循环。预算与访问记录应由运行时保护。6. 管理者如何真正减轻上下文负担6.1 书籍翻译案例Manager 制定计划 → 术语 Agent 生成统一术语表 → 多个翻译 Agent 各处理一个章节 → 审校 Agent 检查术语、内容和风格 → Manager 按问题单派发修订 → 验收整合Manager 主要保留计划、进度、摘要和文件索引完整章节放在共享文件中。每个翻译 Agent 接收当前章节、术语表和风格要求。分工不会消除全书一致性问题只是把它显式交给共享规范和审校机制。术语表也可能需要版本管理和增量更新。6.2 电话与电脑协作案例Phone Agent 收集并校验字段Computer Agent 填写网页二者通过info_collected、fill_error等事件协调。真正的并行是“填写上一个字段”与“询问下一个字段”时间重叠。一个业务 Agent 可以兼任编排者不必为了管理者模式额外增加一个 Manager 进程。6.3 生成工作流代码原文 JavaScript 示例用pipeline、parallel、agent表达“分方向调研 → 分条核实 → 汇总”。这些是依赖特定运行时的编排接口不能当作 JavaScript 内置函数。核心思想是把稳定的依赖关系写成代码由确定性运行时调度。这样 Manager 不必为每次节点转换都重新推理但运行时仍需处理失败、重试、取消与部分结果。7. 去中心化、消息解耦与跨组织协作7.1 不要只凭产品名称判断架构按本章案例的分析口径案例主要机制需要区分的事实MetaGPTSOP 流水线、结构化产物、消息池订阅通信解耦不等于控制流去中心化AutoGen 群聊公共对话记录、发言者选择器共享讨论仍可有中心调度handoff 网络Agent 自主移交控制权没有 Manager 仍需运行时治理大规模 orchestrator-worker主 Agent 创建许多 Worker“Swarm”名称不代表无中心移交包应说明任务、验收标准、事实、约束和产物引用。共享多少历史是架构选择不能仅根据 handoff 或某个框架名称推断其默认行为。7.2 A2A 与 MCP协议定位重点MCPAgent 与工具、资源之间的互操作A2AAgent 之间的能力发现、任务生命周期和产物交换本章强调 A2A 的三个概念能力名片 Agent Card、带状态的 Task以及无需暴露内部实现的 Artifact 交付。标准协议解决接口一致性不能自动证明对方可靠也不能代替身份认证、授权与结果验收。8. 六类失败模式及防护失败模式表现防护思路并发冲突后写覆盖先写、跨文件引用失效版本检查、隔离工作副本、合并后集成验证错误级联上游错误被下游重复引用保留原始证据独立核查结论同质趋同多个 Agent 产生相同错误或资源名称差异化证据与职责、独立判断、命名空间互相扯皮责任推诿、目标冲突、反复退回明确所有权、验收标准、优先级和裁决路径循环失控无限修订或递归派生 Agent总预算、最大轮数、并发数、派生深度和取消机制理解债与认知投降人无法理解和审查系统产物保留设计说明、验证证据和必要的人工理解8.1 乐观锁保护什么读取文件记录版本 v1 → 计算修改 → 写入时原子检查当前版本仍为 v1 → 一致提交并更新版本 → 不一致拒绝重新读取并处理冲突检查与写入必须是原子操作否则检查后仍可能被另一写入抢先修改。乐观锁解决同一对象上的竞争写入不同文件之间的接口不一致、编号失效等语义冲突需要引用检查、集成测试或统一协调。worktree 隔离把冲突推迟到合并处并不会自动消除冲突。8.2 多数意见为什么不一定可靠Agent 可能持续给出看似可信的错误结果不能只检测它是否在线。多个同源模型的意见也可能高度相关。原文借用了拜占庭故障的类比普通多数投票并不等于具有严格保证的拜占庭容错协议。实际质量依赖证据独立性、审核能力和权限隔离。9. 预算与评估怎样证明协作有效小预算下先完成核心路径和必要验证大预算下可增加独立探索、测试覆盖与审核临近预算上限时转向收敛和交付。预算应由运行时持续计量包含失败调用、审核和重试的实际消耗。单独使用 API key 有助于统计与隔离但只有配额或限额机制才能强制控制开销。比较单 Agent 与多 Agent 时至少记录任务成功率与证据质量。总 token、实际费用和端到端耗时。重复劳动、修复轮数和无效调用。取消响应时间及资源清理结果。人工接管次数和未完成事项。区分“相同总预算下谁更好”和“追加预算能换来多少收益”。原文的研究数字和实验目标都有具体条件不能直接推广成任何任务都有效的结论。10. Agent 社会从统一任务到多方目标案例本章借它观察什么Smallville记忆、反思、计划如何支持信息扩散和社交协调Agentopia长期模拟、文件记忆与环境评价如何形成学习轨迹Moltbook开放交互中的群体现象与传播Vending-Bench Arena竞争、定价和协作激励Agent 任务市场通过价格和交易匹配执行者狼人杀信息不对称、角色策略和权限控制需要掌握的架构机制比案例名称更重要记忆保存过去经历反思形成更一般的认识计划与反应连接长期目标和当前环境。多方目标可能冲突单体能力更强并不自动带来群体协调。奖励、资源所有权和争议裁决会影响群体行为。模拟中生成的轨迹要经过评价、筛选和迁移验证才能作为能力改进的证据。狼人杀的关键设计是代码法官保存全局真值只把各席位有权知道的信息传给对应 Agent。不能把全部秘密放进每个角色的上下文再依赖一句“不要泄露”。案例中的涌现行为或模拟收益也不能单独证明 Agent 拥有意识、已实现通用群体智能或能无条件迁移到真实社会。11. 实验索引实验主题学习重点10-1系统提示词切换与 Skill 对照角色规程、缓存与工具权限10-2多 Agent 翻译书籍术语一致性、上下文隔离、文件交接10-3电话 电脑双 Agent双向事件、真实并发、异常清理10-4多网站并行搜索验证后结算、竞态控制、级联取消10-5AI 小镇记忆、反思、计划及消融观察10-6语音狼人杀中心状态机、席位权限、语音交互