夜雨聆风
跟我学 AI Agent : 第 9 课 — Multi-Agent:团队协作的编排艺术
模块: 模块三：高级编排与规划 | 难度: ⭐⭐⭐ | 预计时长: 3.0 小时参考: Agentic Design Patterns: A Hands-On Guide to Building Intelligent Systemspi-mono API: Agent
🤝 “一个人可以走得很快，但一群人可以走得很远。”— 非洲谚语
开篇故事：全能超人 vs 专业团队
想象你是一家出版社的老板，需要出一本关于 AI 趋势的书。
方案A：找一个”全能作家”，让他自己调研、写作、编辑、排版、设计封面。他可能什么都会一点，但每样都不精，而且一个人做需要6个月。
方案B：组建团队：
-
• 研究员（擅长挖掘数据和趋势） -
• 作家（擅长把复杂概念写得通俗易懂） -
• 编辑（擅长逻辑审查和语言润色） -
• 设计师（擅长视觉呈现）
团队协作，3个月出书，质量更高。
这就是 Multi-Agent Collaboration（多 Agent 协作） 模式的核心思想：面对复杂、多领域的任务时，一组专业化的 Agent 协同工作，比一个”全能”单体 Agent 更高效、更可靠。
核心概念
什么是 Multi-Agent 模式？
Multi-Agent 模式将一个复杂目标分解为多个子问题，每个子问题分配给一个拥有特定工具、数据访问权限或推理能力的专业 Agent。
关键不只是”分工”，更在于 Agent 之间的通信协议和协作机制。
分布式架构的三大优势
多 Agent 系统相比单体 Agent 有以下核心优势：
-
1. 模块化（Modularity）：每个 Agent 职责清晰，可以独立开发、测试和替换 -
2. 可扩展性（Scalability）：需要新能力时，添加新 Agent 而非改造现有 Agent -
3. 健壮性（Robustness）：单个 Agent 失败不会导致整个系统崩溃
多 Agent 系统的力量在于：集体的表现超越任何一个单独成员的能力上限（synergistic outcome）。
六种协作模式
下面详细描述六种 Agent 协作模式，每种适用于不同场景：
1. 顺序交接（Sequential Handoffs）
一个 Agent 完成任务后，将输出传给下一个 Agent，形成流水线。
Researcher → Writer → Editor → Publisher 调研报告 草稿 润色稿 最终版适用场景：流程明确、步骤有序的任务（如内容创作流水线）
2. 并行处理（Parallel Processing）
多个 Agent 同时处理问题的不同部分，最后合并结果。
┌▶ Agent A（市场数据）──┐用户请求 ─┤ ├▶ 合并 → 最终报告 └▶ Agent B（用户评价）──┘适用场景：子任务间相互独立、可以同时进行
3. 辩论与共识（Debate and Consensus）
多个 Agent 持有不同视角或信息源，通过讨论评估选项，最终达成共识。
Agent A（乐观派）──┐ ├──▶ 辩论 ──▶ 共识/更优决策Agent B（保守派）──┘适用场景：需要多角度评估的决策（投资分析、战略规划）
4. 层级结构（Hierarchical）
管理者 Agent 动态分配任务给下属 Agent，并综合其结果。
[Manager Agent] / | \ Agent X Agent Y Agent Z (工具组1) (工具组2) (工具组3)适用场景：复杂任务需要灵活调度、每个 Agent 负责一组相关工具
5. 专家团队（Expert Teams）
不同领域的专家 Agent（研究员、作家、编辑）协作产出复杂内容。
Researcher ──▶ Writer ──▶ Editor 调研资料 初稿 终稿与顺序交接的区别：每个 Agent 具有真正的领域专长，而非简单的步骤分工
6. 评论-审查（Critic-Reviewer）
一组 Agent 生成初版输出（计划、草稿、代码），另一组 Agent 审查其是否符合策略、安全、质量和准确性要求。
Creator Agent ──▶ Reviewer Agent ──▶ 修订版 生成初稿 审查反馈 ▲ │ └──────── 根据反馈修改 ──────────┘适用场景：代码生成、研究写作、逻辑检查、伦理对齐——特别有效于减少幻觉和错误
六种模式速查表
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
六种通信结构
多 Agent 系统的通信结构决定了信息如何流动、控制权如何分配。我们可以把 Agent 想象成一个团队中的成员，通信结构就是他们的汇报关系和协作契约。
复杂度递增 ─────────────────────────────────────────────▶Single Agent → Network → Supervisor → Supervisor as Tool → Hierarchical → Custom (独立) (点对点) (中心调度) (资源提供者) (多层管理) (自定义拓扑)1. Single Agent（单体结构）
定义：只有一个 Agent 独立完成任务，没有其他 Agent 与之交互。虽然技术上算不上“多 Agent 系统”，但它是所有复杂结构的起点——任何多 Agent 系统中的每个个体都可以被看作一个 Single Agent。
工作方式：Agent 接收用户输入，调用工具，生成输出。所有推理、记忆、工具调用都在一个上下文窗口内完成。
用户 ──▶ [ Agent ] ──▶ 结果优劣势：
-
• ✅ 实现简单，无通信开销 -
• ✅ 调试容易，上下文连续 -
• ❌ 处理复杂、多领域任务时容易发生“认知过载” -
• ❌ 单点故障，无容错
适用场景：工具数量有限、任务步骤清晰、不需要专业分工的单一目标。
与协作模式的关系：任何协作模式中的单个参与者都可以视为 Single Agent。
2. Network（网络结构）
定义：Agent 之间完全去中心化，直接进行点对点通信。没有固定的管理者，每个 Agent 可以主动向任何其他 Agent 发送消息或请求帮助。
工作方式：Agent 通过广播、订阅或直接寻址的方式交换信息。系统通过某种共识机制（如投票、讨论）收敛到最终决策。
Agent A ◀────────▶ Agent B │ │ └───────▶ Agent C ◀──┘优劣势：
-
• ✅ 极高的容错性：单个 Agent 失效不中断整个网络 -
• ✅ 适合动态、不确定的环境 -
• ❌ 通信开销大，N 个 Agent 最多产生 N×(N-1) 条通道 -
• ❌ 决策一致性难保证，可能出现死循环或不收敛 -
• ❌ 调试困难，信息流追溯复杂
适用场景：需要多方博弈、自组织的场景，如多智能体模拟（Generative Agents 小镇）、开放协作平台。
与协作模式的关系：常与 辩论与共识 模式结合，网络结构为辩论提供了底层通信基础。
实现提示：在 pi-mono 等框架中，网络结构通常需要自己管理事件总线或消息队列，每个 Agent 实例监听特定事件并做出响应。对于简单场景，可以退化为“多个 Agent 并行生成后，由一个合成 Agent 汇总”的变体（类似 Parallel Processing），但这只是弱化的网络。
3. Supervisor（管理者结构）
定义：一个中心化的“管理者”Agent 负责调度所有其他 Agent。它接收任务，决定何时调用哪个 Agent，并综合它们的结果。
工作方式：管理者通常通过 函数调用（Function Calling） 或 工具抽象 来触发下属 Agent——每个下属 Agent 被包装成一个工具，管理者可以在上下文中调用它们。
[Supervisor Agent] / | \ Agent A Agent B Agent C (工具组1) (工具组2) (工具组3)优劣势：
-
• ✅ 控制流清晰，易于理解和调试 -
• ✅ 管理者可以动态决定调用顺序 -
• ❌ 管理者成为单点故障和性能瓶颈 -
• ❌ 随着下属 Agent 数量增加，管理者的上下文压力增大
适用场景：任务需要灵活调度但整体规模可控（3-5 个专业 Agent），如客户支持系统（分类 → 路由到专业 Agent → 整理回复）。
与协作模式的关系：完美支撑 层级结构 和 顺序交接，也可以管理 并行处理。
实现提示：这是 pi-mono 中 Agent as a Tool 模式的直接实现。管理者 Agent 的 system prompt 需要清晰描述“在何时使用哪个下属工具”。
4. Supervisor as Tool（管理者即工具）
定义：将管理者抽象成一个工具或服务，不再直接指挥其他 Agent，而是按需为其他 Agent 提供分析、决策或资源支持。管理者从“老板”变成“顾问”。
工作方式：主执行 Agent 在需要时调用“管理者工具”（如“分析任务复杂度”、“建议执行步骤”），然后自己执行具体操作。
[执行 Agent] ──▶ 调用“管理者”工具 ──▶ 获得建议/资源 │ （不是命令） ▼ 直接操作其他 Agent 或工具优劣势：
-
• ✅ 消除中心化瓶颈，执行 Agent 保持自主性 -
• ✅ 管理者可以多实例部署，提升可用性 -
• ❌ 管理者只能被动提供建议，无法强制执行流程 -
• ❌ 增加了设计复杂度，需要明确定义“咨询”的粒度
适用场景：希望逐步去中心化，或管理者本身可能成为瓶颈但又不希望完全放弃其分析能力时。典型例子：一个代码生成 Agent 在遇到不确定时调用“代码审查”工具（实际是一个 Agent）而非强制先审查后生成。
与协作模式的关系：可作为 评论-审查 模式的低侵入实现——审查者不是强制拦截，而是提供可选建议。
5. Hierarchical（层级结构）
定义：多层管理者结构。高层管理者分解任务分发给中层管理者，中层再进一步分发到具体执行 Agent，形成树状命令链。
工作方式：
[高层 Manager] | [中层 Manager A] [中层 Manager B] / \ / \Agent1 Agent2 Agent3 Agent4优劣势：
-
• ✅ 极强的扩展性，可处理超复杂任务 -
• ✅ 每层管理者只需关注一个粒度的子问题 -
• ❌ 设计复杂，容易产生“深度层次过多而导致信息失真” -
• ❌ 延迟随层数线性增加 -
• ❌ 单点故障影响整棵子树
适用场景：大型复杂项目分解，如软件开发全流程（需求分析 → 架构设计 → 模块实现 → 测试），每一层都可以对应一个 Agent 团队。
与协作模式的关系：自然地融合了 层级结构 和 顺序交接，高层管理者通常按阶段触发，中层则可能并行处理。
实现提示：在代码层面，层级结构是 Supervisor 模式的递归应用——一个管理者 Agent 可以调用另一个管理者作为“工具”，后者再调用具体的执行 Agent。
6. Custom（自定义拓扑）
定义：根据具体业务需求混合上述所有结构，形成独一无二的信息流拓扑。现实中的多 Agent 系统极少是纯理论结构，几乎都是混合体。
工作方式：例如，先有一个 Network 结构的头脑风暴团队，其输出交给一个 Supervisor 进行综合，然后在执行阶段变成 Sequential 流水线，其中某个步骤又内部使用 Hierarchical 分解。
优劣势：
-
• ✅ 高度灵活，可以针对具体痛点优化 -
• ✅ 复用成熟的子结构 -
• ❌ 设计复杂度最高，需要深入理解每种结构的边界条件 -
• ❌ 维护成本高，新成员难以理解整体流程
适用场景：企业级应用，长流程自动化，需要同时满足性能、容错、可解释性等多维要求。
与协作模式的关系：任何模式组合都可以通过自定义拓扑实现。
如何选择通信结构？
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
与协作模式的关系
通信结构是“骨架”，协作模式是“肌肉”。同一协作模式可以架设在不同的通信结构上，但有些组合更自然：
-
• 顺序交接 → 最常用 Supervisor 或 Hierarchical -
• 并行处理 → Supervisor（派发后汇总）或 Network（自发协作） -
• 辩论与共识 → Network（天然匹配） -
• 层级结构 → Hierarchical（本身就是树状） -
• 专家团队 → Supervisor 或 Hierarchical -
• 评论-审查 → Supervisor as Tool 或 Supervisor（循环调用）
理解这一层关系，我们就能根据具体任务的特性，自如地搭建自己的 Multi-Agent 系统了。
代码实战：pi-mono 实现 Multi-Agent
最小可运行版本：顺序交接
import { getModel } from"@mariozechner/pi-ai";import { Agent } from"@mariozechner/pi-agent-core";const model = getModel("minimax-cn", "MiniMax-M2.7");// Agent 1：研究员const researcher = newAgent({ model,systemPrompt: `你是一位资深研究分析师。任务：对给定主题进行调研，列出 3-5 个核心发现。输出格式：每个发现用编号列表，附简要说明。`,});// Agent 2：作家const writer = newAgent({ model,systemPrompt: `你是一位技术内容作家。任务：基于研究资料撰写一篇 500 字博客文章。要求：通俗易懂、结构清晰、有吸引力。`,});// 顺序交接：研究员的输出 → 作家的输入asyncfunctionsequentialHandoff(topic: string) {console.log("📖 Step 1: 研究阶段...");const research = await researcher.prompt(`调研主题: ${topic}` );console.log("研究发现:", research.text);console.log("\n✍️ Step 2: 写作阶段...");const article = await writer.prompt(`基于以下研究资料写一篇博客：\n${research.text}` );console.log("\n📝 最终文章:\n", article.text);}awaitsequentialHandoff("2026年 AI Agent 技术趋势");增强版本：带 Supervisor 的层级协作
import { getModel } from"@mariozechner/pi-ai";import { Agent, AgentTool } from"@mariozechner/pi-agent-core";import { Type } from"@mariozechner/typebox";// 工具：模拟搜索const searchTool = newAgentTool({name: "web_search",description: "搜索互联网",schema: Type.Object({ query: Type.String() }),execute: async ({ query }) => `搜索结果: ${query} 的相关信息...`,});// 工具：模拟数据分析const analyzeTool = newAgentTool({name: "data_analyzer",description: "分析数据并生成统计报告",schema: Type.Object({data: Type.String({ description: "待分析的数据描述" }), }),execute: async ({ data }) => `分析报告: ${data} 的统计摘要...`,});// 专家 Agentconst researcher = newAgent({model: getModel("minimax-cn", "MiniMax-M2.7"),systemPrompt: "你是研究专家，擅长收集和整理信息。",tools: [searchTool],});const analyst = newAgent({model: getModel("minimax-cn", "MiniMax-M2.7"),systemPrompt: "你是数据分析专家，擅长从数据中提取洞察。",tools: [analyzeTool],});const writer = newAgent({model: getModel("minimax-cn", "MiniMax-M2.7"),systemPrompt: "你是技术写作专家，擅长将复杂分析转化为清晰的文章。",});// Supervisor Agent — 决定任务分配const supervisor = newAgent({model: getModel("minimax-cn", "MiniMax-M2.7"),systemPrompt: `你是团队管理者。你有三个专家：- 研究员：负责信息收集- 分析师：负责数据分析- 作家：负责内容撰写根据任务性质，按顺序安排他们工作。先让研究员调研，再让分析师分析，最后让作家写报告。每步完成后，把结果传给下一步。`,});// 使用工具的方式让 Supervisor 调度各专家asyncfunctionsupervisedWorkflow(task: string) {// Step 1: 研究员调研const researchResult = await researcher.prompt(`调研任务: ${task}` );// Step 2: 分析师分析const analysisResult = await analyst.prompt(`基于以下调研数据进行分析:\n${researchResult.text}` );// Step 3: 作家写报告const report = await writer.prompt(`基于以下分析和调研，撰写结构化报告:\n` +`调研: ${researchResult.text}\n` +`分析: ${analysisResult.text}` );return report.text;}const report = awaitsupervisedWorkflow("分析 pi-mono 框架在 Agent 编排领域的竞争力");console.log(report);生产级版本：并行处理 + 结果聚合
import { getModel } from"@mariozechner/pi-ai";import { Agent } from"@mariozechner/pi-agent-core";// 创建多个专家 AgentfunctioncreateExpert(role: string, specialty: string) {returnnewAgent({model: getModel("minimax-cn", "MiniMax-M2.7"),systemPrompt: `你是一位${role}。专长：${specialty}。给出专业、具体的分析。`, });}// 并行 + 聚合asyncfunctionparallelExpertReview(topic: string) {const experts = {market: createExpert("市场分析师", "市场趋势和竞争格局"),tech: createExpert("技术架构师", "技术选型和系统设计"),user: createExpert("用户体验专家", "用户需求和体验设计"), };// 并行调用多个专家console.log("🔄 并行收集专家意见...");const [marketView, techView, userView] = awaitPromise.all([ experts.market.prompt(`从市场角度分析: ${topic}`), experts.tech.prompt(`从技术角度分析: ${topic}`), experts.user.prompt(`从用户体验角度分析: ${topic}`), ]);// 聚合 Agent：综合所有专家意见const synthesizer = newAgent({model: getModel("minimax-cn", "MiniMax-M2.7"),systemPrompt: `你是决策顾问。综合多位专家的意见，给出：1. 共识点（专家们一致认同的）2. 分歧点（专家们意见不同的）3. 最终建议（你的综合判断）`, });const finalReport = await synthesizer.prompt(`综合以下专家意见给出决策建议：\n\n` +`## 市场分析师意见\n${marketView.text}\n\n` +`## 技术架构师意见\n${techView.text}\n\n` +`## 用户体验专家意见\n${userView.text}` );console.log("📊 综合决策报告:\n", finalReport.text);}awaitparallelExpertReview("是否应该将产品从 REST API 迁移到 GraphQL？");架构图：pi-mono 中的 Multi-Agent 模式
模式1: 顺序交接 Researcher → Writer → Editor 模式2: 并行 + 聚合 ┌→ Expert A ──┐ │ │ prompt() → prompt() → prompt() ├→ Expert B ──┤→ Synthesizer │ │ └→ Expert C ──┘模式3: 层级 Supervisor [Supervisor] / | \ Agent X Agent Y Agent Z (工具A) (工具B) (工具C)pi-mono 关键机制：• 多 Agent 实例 → 各自独立的 systemPrompt + tools• Promise.all → 并行执行• 手动传递上下文 → 前一个 Agent 的输出注入后一个的 prompt• 事件流 → 监控每个 Agent 的执行状态Agent as a Tool：一个高级技巧
Google ADK 有一种”Agent as a Tool”模式——将一个 Agent 包装成另一个 Agent 可调用的工具。这在 pi-mono 中同样可以实现：
import { Agent, AgentTool } from"@mariozechner/pi-agent-core";import { Type } from"@mariozechner/typebox";// 子 Agent：图像生成专家const imageAgent = newAgent({model: getModel("minimax-cn", "MiniMax-M2.7"),systemPrompt: "你是图像提示词专家。将用户需求转化为详细的图像生成提示词。",tools: [newAgentTool({name: "generate_image",description: "根据提示词生成图像",schema: Type.Object({ prompt: Type.String() }),execute: async ({ prompt }) => `已生成图像: ${prompt}`, }), ],});// 将子 Agent 包装成工具const imageAsTool = newAgentTool({name: "image_generator",description: "生成图像。输入是图像描述，输出是生成的图像。",schema: Type.Object({description: Type.String({ description: "想要生成的图像描述" }), }),execute: async ({ description }) => {// 调用子 Agentconst result = await imageAgent.prompt(description);return result.text; },});// 父 Agent：创意艺术家const artist = newAgent({model: getModel("minimax-cn", "MiniMax-M2.7"),systemPrompt:"你是创意艺术家。先构思一个创意描述，然后用 image_generator 工具生成图像。",tools: [imageAsTool],});const result = await artist.prompt("画一只戴帽子的猫");console.log(result.text);这种模式的妙处：父 Agent 不需要知道子 Agent 的内部实现，只需要知道”这个工具能做什么”。实现了关注点分离。
真实世界案例
案例一：软件开发的 Agent 团队
来看一个软件开发场景：
-
• 需求分析师 Agent：理解用户需求，输出需求文档 -
• 代码生成 Agent：根据需求编写代码 -
• 测试 Agent：编写和运行测试用例 -
• 文档写作 Agent：生成 API 文档
需求分析师 → 代码生成 → 测试 → 文档写作 │ │ └── 需求变更时重入 ──────┘案例二：客户支持升级路径
frontline Agent（处理常见问题） │ │ 复杂问题升级 ▼ technical Agent（技术专家） │ │ 账单/权限问题升级 ▼ billing Agent（账单专家）每个 Agent 只处理自己擅长的问题，超出范围时传递给下一个专家。
案例三：金融分析系统
多个 Agent 协作分析金融市场：
-
• Agent 1：获取股票数据 -
• Agent 2：分析新闻情感 -
• Agent 3：技术分析（K线、趋势线） -
• Agent 4：综合各方数据，生成投资建议
要点总结
-
1. 分工而非全能：Multi-Agent 的核心是让每个 Agent 专注于自己最擅长的领域，通过协作实现 1+1>2 的效果 -
2. 六种协作模式：顺序交接、并行处理、辩论共识、层级结构、专家团队、评论审查——根据任务特点选择 -
3. 通信结构很关键：从简单的 Supervisor 到复杂的自定义拓扑，选择合适的通信结构决定了系统的效率和可靠性 -
4. Agent as a Tool：将 Agent 包装成工具是一个强大的抽象——父 Agent 无需了解子 Agent 的内部实现 -
5. 健壮性来自隔离：单个 Agent 的失败不会导致整个系统崩溃，这是分布式架构的天然优势 -
6. 何时用 Multi-Agent：任务太复杂（一个 Agent 搞不定）、需要多种专业技能、或者需要并行加速时 -
7. 避免过度设计：如果任务简单到 1-2 步就能完成，单体 Agent 更高效——Multi-Agent 增加了通信和编排的开销
本文主要是对 Multi-Agent 设计中的一些基础原则进行了分析，限于篇幅，对于工程中的一些细节，如状态、错误处理、反馈等等等等没有深入探讨，下面这张图是一个较完整版本的结构，供参考：
动手练习
练习一：两步顺序交接（难度 ⭐）
实现一个简单的 Researcher → Writer 流水线：
-
• Researcher 调研给定主题 -
• Writer 基于 Researcher 的输出写一篇短文
提示：两个 Agent 实例，第一个的输出作为第二个 prompt 的一部分。
练习二：并行专家 + 聚合（难度 ⭐⭐）
创建 3 个专家 Agent（市场、技术、用户体验），并行分析同一个问题，然后用第 4 个 Agent 综合意见。
要求：
-
• 使用 Promise.all 实现并行 -
• 聚合 Agent 要指出共识点和分歧点
练习三：Supervisor 动态调度（难度 ⭐⭐⭐）
实现一个 Supervisor Agent，根据任务内容动态决定调用哪些专家 Agent：
-
• 如果任务涉及”市场”→ 调用市场分析师 -
• 如果任务涉及”技术”→ 调用技术架构师 -
• 如果任务涉及”写作”→ 调用内容作家 -
• Supervisor 可以同时调用多个专家
提示：Supervisor 可以通过 AgentTool 包装每个子 Agent，或者用代码层 if/switch 实现路由。
延伸阅读
-
• Multi-Agent Collaboration Mechanisms: arxiv.org/abs/2501.06322 -
• pi-mono 事件流: github.com/nicepkg/pi-mono — 多 Agent 实例的事件监控 -
• Google ADK 多 Agent 模式: Hierarchical / Sequential / Parallel Agent -
• Debate & Consensus: 多 Agent 辩论在决策优化中的前沿研究