多 Agent 协作

共享上下文：下一个 Agent 继承前一个的完整轨迹，只换系统提示词和工具集，就像接手的开发者既拿到需求文档，也能看到分析师和用户的全部沟通。不共享上下文：每个 Agent 有自己的对话历史，互相看不到“思考过程”，像不同部门靠共享文档和会议纪要协作。

共享上下文不丢信息，但上下文膨胀很快；隔离上下文模块化、易扩展、能并行，代价是信息同步变复杂。

隔离之后靠什么传信息：IPC 的两大范式

操作系统里，进程间通信只有两种：共享内存，或者消息传递。Agent 间的三种常见机制也落在这两类里。Go 有句话：“不要通过共享内存来通信，而要通过通信来共享内存。”

维度二：协作拓扑

控制权和信息按什么结构流动。三种典型形态都可以看成“Graph 工程”里的执行图：节点是 Agent、普通程序或人工决策，边是依赖、条件路由和失败去向。

学术研究常说多 Agent 不提升能力上限，工程实践里多 Agent 却确实更好。两边说的不是一回事：研究比较的多是“几个 Agent 对着同一段上下文讨论”，有效的工程系统往往带外部反馈环路（代码执行、视觉渲染、工具调用）。

核心判据只有一条：协作过程是否引入了单个 Agent 在生成时拿不到的新信息。

每个阶段都是一个有自己提示词和工具集的 Agent，但继承前面所有轨迹。一套静态提示词要么太笼统，要么把所有阶段的指导塞在一起太冗长，所以按阶段切换“身份”。难点在于让当前 Agent 专注自己的职责，不被继承来的大量历史干扰。

切换角色有两种载体：替换 system prompt（transfer_to_agent），或加载 Skill。行为可以一样，缓存成本和约束强度完全不同。

真正的多 Agent 协作里，每个 Agent 有自己的上下文、轨迹和状态，协作完全依赖工具参数、共享文件和消息总线。顺着“通信即 IPC”往下走，多 Agent 系统和操作系统几乎一一对应。私有状态、异步消息、能创建新成员，正是 1970 年代 Actor 模型的设定，多 Agent 系统可以看作它的 LLM 版本。

两套与拓扑无关的基础设施：共享文件系统是数据平面，负责交换产物；通信与控制机制是控制平面，负责消息、状态、终止和调度。

10.4.1 Agent 眼中的文件系统

Agent 访问的是一个虚拟文件系统：来源、生命周期、权限各不相同的存储挂在同一棵目录树下，统一用 read_file / write_file / list_dir 访问。这棵树相当于 Agent 的地址空间，四类区域是权限各异的内存段。不少并发冲突和信息泄露，都来自把本该隔离的区域混在一起。

统一目录树的价值在于“文件路径是通用接口”：Agent 之间传产物、主 Agent 给子 Agent 交接输入、跨组织 A2A 交换产物，传的都是轻量的路径字符串，不是把内容塞进上下文窗口。

10.4.2 控制平面：消息、状态、终止、调度

四个工具原语对应进程世界的四个操作：spawn_subagent = fork，send_message_to_subagent = 消息，cancel_subagent = kill，list_agents = ps。

{ "sender": "agent_3",
  "target": "manager",        // 或广播
  "type": "status_update",    // task_assigned / result / terminate
  "payload": { ... } }

2–3 个身份平等的 Agent 多轮互相反馈，实现复杂度最低：定义好两个角色、通信机制和迭代终止条件就能跑。价值在于独立视角，但“多个实例”不等于“多种思路”：模型、上下文、脚手架高度相似时，不同 Agent 往往做出同样的选择，局部错误会变成系统性故障。

要得到真正的多样性，就主动区分模型、上下文、工具、可见证据或职责，并让各 Agent 先独立判断、再汇总。

Loop 工程：解决“活干一半就停”

验证之前，“完成”只是模型的一句宣称，不是证明。Loop 工程（Addy Osmani，2026 年 6 月）就是设计一个持续运转的循环：发现下一件事、执行、验证、记录进度，由验证器而不是模型来决定能不能停。共识是：循环的瓶颈在验证器，不在模型。Boris Cherny 的说法：“我已经不再直接 prompt Claude 了，我的工作是写 loop。”

提议者-审核者：最经典的对等范式

Proposer 生成代码，Reviewer 渲染或执行结果，再用 Vision LLM 打分、给结构化改进建议，循环到达标。同样适用于安全审查、内容审核、代码审核。

candidate = proposer(task, constraints)
evidence  = execute_or_render(candidate)      # tests, state, screenshot, facts
review    = independent_reviewer(candidate, evidence)
while review.veto and budget_remaining:
    candidate = proposer.repair(candidate, review.findings)
    evidence  = execute_or_render(candidate)
    review    = independent_reviewer(candidate, evidence)
if review.pass: publish(candidate, evidence, review)
else:           escalate_or_reject(review)

辩论、头脑风暴、专家小组

子任务多、要动态调度、依赖复杂时，对等协作就不够了。Manager 像项目经理：理解任务、拆解、选 Agent、跟进度、处理异常（重试、换 Agent、改计划）、整合结果。实现上把每个专门 Agent 注册成 Manager 的一个工具：调用 Agent 和调用普通工具没有本质区别。加能力只需注册新工具，不同 Agent 可以用不同模型、提示词、工具集甚至硬件。

Manager 是单点瓶颈。Plan-and-Act（2025）发现弱规划者是整个系统最关键的短板，在 WebArena-Lite 上取得 54% 成功率，靠的是改进 Planner 而非 Executor。最强的模型和最用心的提示词应该给 Manager。

workers = launch_independent_workers(subtasks)
while workers.any_running:
    event = next_event()
    if event.type == RESULT:
        if verify(event.artifact, hidden_checks):     # 第一个“已验证”成功，不是第一个“声称”成功
            if not settle_once(event): continue       # 原子地认领赢家，必须幂等
            broadcast_cancel(to = workers - {event.worker_id})
            await_all_ack_or_timeout()
            return assemble(event.artifact, evidence = event.evidence)
        else: record_failure(event)
return summarize_failures(workers)

const results = await pipeline(
  DIMENSIONS,                                         // 七个待核实的方向
  d => agent(research(d), { schema: FINDINGS }),      // 阶段一：调研
  r => parallel(r.findings.map(f => () =>             // 阶段二：逐条独立核实
         agent(verify(f), { schema: VERDICT })))
)
await agent(writeProvenance(results.flat()))          // 汇总：等齐所有结果

去掉中心控制者，是为了模仿人类组织：职责对等的角色分工制衡，各自决定何时找谁，可能是移交（“我做完了，交给你”）、请求反馈（“技术上可行吗？”）或报告问题（“需求有矛盾”）。它也缓解稳定性问题：Agent 可能停止响应、工具调用失败、陷入死循环，而管理者一崩就是最大的单点故障。微服务里两者叫编排（orchestration）和编舞（choreography）。

三个案例是递进的：MetaGPT 控制流其实是固定流水线，只在通信上解耦；AutoGen 群聊是共享对话 + 中心化调度的混合；OpenAI Swarm 才在控制流上真正对等。

10.4.6 A2A：跨组织的 Agent 互操作

同一团队内部，参数、文件、总线就够了。要调另一家公司的 Agent，就需要标准协议：Google 2025 年发布 A2A（后捐给 Linux 基金会）。A2A 之于 Agent，就像网络协议之于进程。MCP 管 Agent 与工具的互操作，A2A 管 Agent 与 Agent 的互操作。

《Why Do Multi-Agent LLM Systems Fail?》（2025）在 MetaGPT、ChatDev、AG2、Magentic-One 等 7 个框架上收集轨迹，人工逐条分析约 150 条，归纳出 14 种失败模式、三大类。简单修补效果有限，研究者认为这是架构层面的根本缺陷。

Agent 的故障天生是拜占庭式的：它很少直接停下（崩溃故障），而是继续给出看似可信的错误结论，错误不会自己声明。交叉验证、多数表决正是拜占庭容错的经典手段。

失败模式一：共享文件系统的并发冲突

前面讲的都是目标明确的任务协作。当 Agent 从几个扩展到成百上千、交互足够自由时，会出现无法从单个个体规则预测的集体行为。

常见误区