10. 多 Agent 协作：何时拆、如何拆、如何不一起崩

单 Agent 受限于窗口与单一角色的工具集；多 Agent 被期待「取长补短」，有时还被叙事推到「组织级智能」。工程上先降温：多 Agent 的 token 消耗可以是普通对话的数倍到一个数量级（公开分享里出现过约 15× 量级的数字，以你自己的 trace 为准）。若收益盖不住成本，一个调校好的单 Agent 往往更划算。

两个设计维度决定架构：上下文是否共享，以及协作拓扑（控制权与信息如何流动）。共享时拓扑常退化成角色切换序列；隔离时才必须显式设计通信与调度。

维度一：上下文是否共享

共享上下文：后一角色继承完整对话与轨迹，只换系统提示与工具集。信息零损耗；上下文膨胀快；并行困难。

不共享上下文：各自独立历史，靠显式通道交换信息：

1. 工具参数——结构化、类型清
2. 共享文件系统——大产物、可持久
3. 消息总线——异步、多对多，发送方不必与接收方同时在线

经验：累计上下文将长期超过窗口一半时倾向隔离；信息零损耗是正确性硬约束时倾向共享；多数系统「前段共享、饱和后 handoff（移交）到隔离」。

两种都是真·多 Agent（身份 = 提示词 + 工具集不同），差别在协调是隐式（读历史）还是显式（文件/消息）。

维度二：拓扑（隔离上下文下）

按复杂度递增：

1. 对等协作（Peer）——2–3 个平等角色迭代改进（提议—审核、辩论、头脑风暴）
2. 管理者（Orchestration）——Manager 拆任务、派子 Agent、汇总；子 Agent 在 Manager 眼里就是工具
3. 去中心化——无运行时中心调度，Agent 点对点或经总线协商、移交

共享上下文下的 transfer_to_agent 本质是链式 handoff，拓扑退化但仍有用。

何时多 Agent 真优于单 Agent

核心判据只有一条：协作是否引入单个 Agent 在生成时无法获得的新信息？

RLEF（用执行反馈做强化学习改进代码）、WebGen-Agent（截图 + 视觉描述反馈）等方向，都把增益锚定在外部反馈环，而不是「多几个面具」。学术上「单 Agent 就够」与工程上「多 Agent 有效」常谈的不是同一对象：前者多是同文互辩，后者多是执行器、渲染器、工具的新信号。

相关：单纯加大步数预算不会自动变强——Agent 缺预算意识时仍会浅层搜索后早停。Manager 应按复杂度分配步数预算，并引导「规划—实现—测试—改进」，而不是只派工不等待策略。

共享上下文：多阶段角色切换

同一会话内换身份，历史不断：

需求分析师（只提问、记需求）
    → complete_requirements_analysis()
软件工程师（读写文件、跑代码）
    → submit_for_review()
代码审查员（linter、测试、批判性检查）
    → approve / request_revision

每阶段工具集收窄，减少「需求分析师直接写生产代码」类越权。回退路径要设计好：审查不通过回到实现阶段，而不是卡死。

跨领域变体：triage 分诊持有 transfer_to_agent，在 research / coding / data_analysis / writing 间移交；整条链共享历史，后任天然知道前任结论。要防循环踢皮球：提示词写清退出条件与最大移交次数。

最小 handoff 工具形状：

def transfer_to_agent(target_role: str, reason: str, state: dict) -> dict:
    """
    共享上下文下的角色切换：保留 messages，替换 system 与 tools。
    state 里可放 role、handoff_count、max_handoffs。
    """
    if state.get("handoff_count", 0) >= state.get("max_handoffs", 8):
        return {"ok": False, "error": "handoff limit reached"}
    state["role"] = target_role
    state["handoff_count"] = state.get("handoff_count", 0) + 1
    state["last_handoff_reason"] = reason
    # 运行时：load_prompt(target_role), load_tools(target_role)
    return {"ok": True, "role": target_role}

隔离上下文：文件系统与控制平面

虚拟文件系统常挂四类区域：

统一 read_file / write_file 接口的价值：Agent 间只传路径字符串，不把大文件塞进上下文——与「文件系统作中枢」一脉相承。

控制平面：消息（点对点或总线，带 envelope：发送者、类型、负载）、状态查询（pull 轮询 / push 上报 + 心跳超时）、执行终止（优雅清理优先，强制杀进程兜底；级联终止要幂等，防双成功竞态）。

子 Agent 回传结构化摘要（结论、路径、问题），全量轨迹留在自己日志——Manager 上下文才能随子任务数近似线性涨。

对等：提议者—审核者

最有用的对等模式。Proposer 生成；Reviewer 不靠「再读一遍同一文本」，而靠渲染、测试、编译、外搜产生新信号，输出结构化问题列表（页码/文件、类型、严重度），迭代直到门槛或轮次上限。

自纠文献结论可记一句：无外部反馈时，模型把对的改错的次数可以多于改对的次数。CRITIC 等实验也显示，拿掉工具验证，提升大半消失。

扩展：

• Debate——制度化对抗，利于暴露反面证据；但若无新信息且总 token 恒定，未必赢单 Agent
• Brainstorm——独立采样再交叉激发，偏探索
• Panel——多领域视角互补，非对抗

对等协作还直接针对过早终止：偷懒式假完成、一条路失败就放弃、口头同意当闭环。Loop 工程的共识是：瓶颈在验证器，不在「再写长一点的 prompt」；人的角色从操作提示词转向设计循环。

管理者模式

子任务 ≥5、依赖复杂、要动态改派时上场。Manager 像项目经理：拆解、选人、跟踪、重试或换 Agent、整合。扩展方式是注册新 Agent 为工具，而不是改 Manager 内核。异构友好：不同模型、提示、硬件。

反模式：Manager 自己做完所有专业活；子 Agent 回传整段思维链导致上下文爆炸；无预算与超时，子任务挂死拖垮全局。

去中心化与 A2A

无中心 Manager 时，协作靠协商与 handoff 协议。适合拓扑动态、参与方跨组织或不想单点调度的场景。代价是调试难、活性（会不会永远协商）与一致性要自建。

A2A（Agent-to-Agent）类协议把任务生命周期（提交、执行中、需输入、完成、失败）、消息信封与 Artifact（产物引用）标准化，便于跨厂商 Agent 互操作。工程落地仍要补：鉴权、配额、不可信对端的输出验证——协议解决的是形状，不是信任。

并行形态补充：多路搜索「一人命中、余人终止」；竞态下只结算一次成功；状态机统一任务态，避免各 Agent 私有字符串状态无法对齐。

失败模式

并发文件系统
共享区无约定时：互相覆盖、半写读取、删除对方中间件。缓解：乐观锁（版本号/etag）、每 Agent worktree 再合并、关键文件单写者、产物写临时名再原子 rename。

错误级联
上游幻觉写进共享 JSON，下游当真理继续放大；或一个子 Agent 安全违规未被否决，污染最终交付。缓解：阶段门禁与 schema 校验、Reviewer 独立验证、敏感步骤人工闸门、失败快速隔离（熔断该分支而非整图重跑无界）。

其他高频

• 循环 handoff / 互相等待死锁
• 成本失控（无任务级 token 与墙钟上限）
• 调试不可见（缺跨 Agent 关联的 trace id）
• 「多角色同文互夸」当质检——无新信息，浪费预算

Agent 社会：仿真与经济（短述）

用多 Agent 仿真市场、组织或舆论，可以做机制研究与压力测试：规则变化时个体策略如何响应。价值在受控实验与生成合成数据，不在默认等于「已涌现文明级智能」。若仿真奖励与真实约束脱节，得到的是第 7 章同款应试策略。生产系统更常见的终点仍是：清晰接口、可验证产物、可关停的预算——而不是无人看管的自交易闭环。

选型检查表

1. 能否用单 Agent + 工具 + 强验证器解决？能则先不拆。
2. 需要的新信息从哪来？测试、UI、人工、其他系统？没有新信息源就别指望多角色辩论。
3. 共享还是隔离？窗口、并行、安全隔离、成本四象限打分。
4. 拓扑：2 人迭代 → 对等；多依赖调度 → Manager；跨组织动态 → 去中心 + 协议。
5. 数据平面（文件分区与锁）与控制平面（消息、状态、终止）是否先于「角色人设」设计？
6. 评估：第 6 章的 Pass^k、成本、trace；多 Agent 必须能回答「这 15× token 买到了哪类错误的下降」。

本篇收束

1. 多 Agent 两轴：上下文共享与否 × 拓扑；共享时常退化为角色切换。
2. 真增益来自新信息与验证环，不是多几张面具。
3. 隔离系统的底座是虚拟文件系统分区 + 消息/状态/终止控制平面。
4. 对等审核、Manager、去中心/A2A 各有成本曲线；默认选能讲清验证器的最简拓扑。
5. 并发写与错误级联是生产杀手；协议与人设之前先做锁、schema 与 trace。

系列收束（第 6–10 章）

回到导读公式：Agent = LLM + 上下文 + 工具，生产再写成 Model + Harness。第 6 章给验证尺子；第 7 章把协议与策略可选地写进参数；第 8 章在权重外沉淀经验与工具；第 9 章把动作空间扩到语音、GUI 与物理；第 10 章在窗口与能力边界处决定是否拆成群体。

原则驱动的迭代顺序可以记成：

先能量化 → 再改 Harness → 必要时后训练
先外部化经验 → 再考虑造工具
先单 Agent + 验证器 → 再多 Agent
实时链路与深度推理解耦 → 各自迭代

模型会继续变强，Harness 的厚度与位置会变，但「可评估、可验证、可纠正」不会过时。把感觉驱动换成原则驱动，靠的不是更长的提示词，而是能说清楚：测什么、奖励是什么、经验存在哪、失败如何不传播。