Loading... # Agents 201：多智能体编排实战指南 # 一、概述 ## 1. 简介 ### A. 是什么 多智能体系统是指由多个专门化的 AI 智能体协同工作，共同完成复杂任务的系统架构。每个智能体专注于特定领域，通过编排模式实现高效协作。 ### B. 为什么学 单智能体系统存在明显限制：上下文窗口有限、决策混乱、调试困难。多智能体系统通过专业化分工解决这些问题，类似于组建一个高效团队。 ### C. 学完能做什么 - 设计并实现多智能体协作系统 - 选择合适的编排模式和通信策略 - 优化生产环境中的性能和成本 - 避免常见的反模式陷阱 ## 2. 前置知识 ### A. 必备技能 - 了解单智能体的基本概念和实现 - 熟悉异步编程和并发处理 - 掌握基本的系统设计原则 ### B. 推荐知识 - 了解 LLM 的 token 消耗机制 - 熟悉事件驱动架构 - 具备生产环境部署经验 # 二、为什么需要多智能体 ## 1. 单智能体的局限性 单智能体系统很快会遇到瓶颈：上下文窗口填满、决策变得混乱、调试变得不可能。这些问题随着任务复杂度增加而放大。 ## 2. 多智能体的优势 ### A. 专业化 每个智能体专精一个领域，而不是在所有事情上都平庸。例如，一个智能体专注代码分析，另一个专注文档生成。 ### B. 并行处理 多个智能体可以同时在独立的子任务上工作。这种并行性显著提升系统效率。 ### C. 可维护性 当系统出现故障时，可以准确定位需要修复的智能体。问题范围被明确隔离。 ### D. 可扩展性 通过添加新的智能体来增加新功能，而不需要重写整个系统。 ## 3. 权衡考量 协调开销是主要代价。智能体需要通信、共享状态、避免相互干扰。如果处理不当，只会构建一个更昂贵的失败模式。 # 三、三种编排模式 ## 1. 监督者模式（集中控制） ### A. 模式描述 一个监督者智能体协调整个工作。它接收任务、分解为子任务、路由到工作智能体、验证输出、综合最终响应。 ### B. 适用场景 - 任务可以清晰分解为子任务 - 需要可审计性和推理透明度 - 质量控制比速度更重要 - 管理 3-8 个工作智能体 ### C. 架构示意 ```mermaid graph TD User[用户请求] --> Supervisor[监督者智能体] Supervisor -->|分解| Decompose[任务分解] Supervisor -->|路由| Route[任务路由] Supervisor -->|监控| Monitor[进度监控] Supervisor -->|验证| Validate[输出验证] Supervisor -->|综合| Synthesize[结果综合] Supervisor --> Worker1[工作智能体 1] Supervisor --> Worker2[工作智能体 2] Supervisor --> Worker3[工作智能体 3] ```  ### D. 实现示例 AI Hedge Fund 示例使用这种模式。四个专门的分析师（基本面、投资组合、风险、技术分析）并行运行，监督者负责协调。 ```typescript // 监督者协调并行分析 const analyses = await Promise.all([ fundamentalAgent.analyze(ticker), portfolioAgent.analyze(ticker), riskAgent.analyze(ticker), technicalAgent.analyze(ticker) ]); // 监督者综合结果 const report = await supervisorAgent.synthesize(analyses); ``` ### E. 潜在问题 监督者成为瓶颈。每个决策都通过一个智能体，这意味着协调步骤需要串行处理，即使工作可以并行进行。token 成本随协调层级增加。 ## 2. 群体模式（点对点） ### A. 模式描述 没有中央控制器。智能体直接通信、交换信息、围绕任务自组织。类似于蚁群而不是组织架构图。 ### B. 适用场景 - 任务需要多个视角 - 没有清晰的串行步骤分解 - 实时响应性很重要 - 智能体需要相互反应 ### C. 架构示意 ```mermaid graph LR A[智能体 A] <--> B[智能体 B] A <--> C[智能体 C] B <--> C B <--> D[智能体 D] C <--> D ```  ### D. 实现示例 SmartTravel 多智能体示例展示了点对点协调。六个智能体（目的地探索、航班搜索、酒店搜索、餐饮、行程、预算）通过共享状态交换信息。 ```typescript // 每个智能体读取和写入共享状态 await destinationAgent.explore(state); await flightAgent.search(state); // 使用前一个智能体的目的地 await hotelAgent.search(state); // 使用目的地和日期 // 智能体更新共享状态 class TravelState { destination: string; flightOptions: Flight[]; hotelOptions: Hotel[]; // ...跨所有智能体共享 } ``` ### E. 潜在问题 突发行为难以预测。没有协调者，智能体可能重复工作、创建无限循环或收敛到次优解。调试非常困难，因为要追踪信息在网格中的流动，而不是树中。 ## 3. 层级模式（多级控制） ### A. 模式描述 监督者模式的递归版本。顶层智能体管理中层智能体，中层智能体管理工作智能体。三层或更多层级。 ### B. 适用场景 - 任务太复杂不适合扁平监督 - 不同领域需要不同的管理策略 - 协调 10+ 个智能体 - 需要战略和战术控制 ### C. 架构示意 ```mermaid graph TD Top[顶层监督者] --> MidA[中层 A] Top --> MidB[中层 B] MidA --> W1[工作智能体 1-3] MidB --> W2[工作智能体 4-6] ```  ### D. 实现示例 NVIDIA 文档生成器示例使用层级分解： ```typescript // 顶层：文档编排器 const topLevel = { analyze: async (repo) => { // 委托给分析团队 const analysis = await analysisTeam.execute(repo); // 委托给文档团队 const docs = await docsTeam.execute(analysis); // 委托给验证团队 return await validationTeam.execute(docs); } }; // 中层：分析团队监督特定分析器 const analysisTeam = { codeAnalyzer: new Agent(), archDiagrammer: new Agent(), testGenerator: new Agent() }; ``` ### E. 潜在问题 token 成本激增。每一层都增加协调开销。三层层级、每层 5 个智能体，协调成本可能轻松超过 50K tokens。只有当扁平模式真正无法处理复杂度时才值得。 # 四、智能体通信策略 ## 1. 共享状态（最常用） ### A. 策略描述 所有智能体从共享状态对象读取和写入。更改对所有人可见。 ### B. 实现方式 ```typescript interface SharedState { task: string; results: Map<string, any>; currentStep: string; } // 智能体 A 写入状态 state.results.set('analysis', analysisResult); // 智能体 B 读取状态 const analysis = state.results.get('analysis'); ``` ### C. 优势 - 实现简单 - 易于调试（只需检查状态） - 无消息传递复杂性 ### D. 劣势 - 智能体同时写入时可能出现竞态条件 - 智能体上下文之间无隔离 - 状态无限制增长，需要定期清理 ### E. 使用建议 从这里开始。大多数智能体系统应该使用共享状态，直到遇到它无法解决的具体问题。 ## 2. 消息传递（事件驱动） ### A. 策略描述 智能体相互发送消息。没有直接状态共享。 ### B. 实现方式 ```typescript // 智能体 A 发布事件 eventBus.publish('analysis.complete', { ticker: 'AAPL', analysis: result }); // 智能体 B 订阅事件 eventBus.subscribe('analysis.complete', async (event) => { await portfolioAgent.process(event.analysis); }); ``` ### C. 优势 - 智能体之间松耦合 - 自然适合异步工作 - 易于添加新智能体而不改变现有智能体 ### D. 劣势 - 更难调试（需要追踪消息流） - 可能出现消息循环 - 需要基础设施（事件总线、队列） ### E. 使用建议 当智能体真正独立且不应该相互了解时使用。或者需要在服务间进行异步处理时。 ## 3. 移交机制（显式控制转移） ### A. 策略描述 一个智能体显式地将控制权移交给另一个智能体，通常携带上下文。 ### B. 实现方式 ```typescript class Agent { async handoff(targetAgent: Agent, context: Context) { // 准备移交上下文 const handoffContext = { previousAgent: this.name, taskContext: context, timestamp: Date.now() }; // 转移控制权 return await targetAgent.execute(handoffContext); } } ``` ### C. 优势 - 清晰的控制流 - 易于审计谁做了什么 - 跨智能体保持上下文 ### D. 劣势 - 智能体之间紧密耦合 - 默认串行处理 - 每次转换都有移交开销 ### E. 使用建议 当任务必须按特定顺序发生且上下文必须流过链时使用。 # 五、多智能体系统的内存架构 ## 1. 会话内存 ### A. 模式描述 每个智能体交互都是一个会话。会话有隔离的状态，在完成时合并回共享内存。 ### B. 实现方式 ```typescript class MemoryManager { async createSession(agentId: string): Session { return { id: generateId(), agentId, localState: {}, sharedSnapshot: this.getSnapshot() }; } async commitSession(session: Session) { // 将本地更改合并回共享状态 this.merge(session.localState); } } ``` ### C. 使用场景 需要读取共享上下文但进行隔离更改的并行智能体。常见于工作智能体独立运行的监督者模式。 ## 2. 窗口内存（对话上下文） ### A. 模式描述 保留所有智能体最近交换的滑动窗口。最旧的条目被压缩或丢弃。 ### B. 实现方式 ```typescript class WindowMemory { private window: Message[] = []; private maxSize = 50; add(message: Message) { this.window.push(message); if (this.window.length > this.maxSize) { // 压缩最旧的三分之一 this.compressOldest(); } } compressOldest() { const toCompress = this.window.slice(0, this.maxSize / 3); const summary = await this.summarize(toCompress); this.window = [summary, ...this.window.slice(this.maxSize / 3)]; } } ``` ### C. 使用场景 上下文重要但不能保留所有内容的长运行智能体对话。RAG 应用使用这种模式。 ## 3. 情景内存（跨智能体学习） ### A. 模式描述 存储特定智能体之间的交互历史。使智能体能够从过去的协调中学习。 ### B. 实现方式 ```typescript interface Episode { agentA: string; agentB: string; interaction: Interaction; outcome: 'success' | 'failure'; learnings: string[]; } // 智能体在协调前查询过去的交互 const pastEpisodes = await memory.query({ agents: ['supervisor', 'riskAnalyst'], outcome: 'success' }); ``` ### C. 使用场景 频繁协作且可以从过去有效的方法中学习的智能体。 # 六、生产环境考虑 ## 1. Token 经济学 ### A. 成本挑战 多智能体系统快速消耗 token。四个智能体协调任务，成本可能比单个智能体高 10 倍。 ### B. 典型监督系统的成本分解 - 监督者分解：1K tokens - 4 个工作智能体：每个 3K tokens（总计 12K） - 监督者综合：2K tokens - 总计：每个任务 15K tokens 相比之下，单个智能体完成相同任务只需 4K tokens。你在为协调付费。 ### C. 优化策略 - 缓存监督者指令：不要每次都重新生成任务分解 - 压缩工作智能体输出：工作智能体不需要返回散文，结构化数据即可 - 并行执行：4 个智能体串行运行的成本与并行相同，但时间长 4 倍 - 延迟智能体激活：只在需要输出时才调用智能体 ## 2. 延迟管理 ### A. 延迟挑战 多个智能体意味着多个 LLM 调用。每次调用增加 2-5 秒。串行处理会破坏用户体验。 ### B. 延迟计算 - 1 个智能体：3 秒 - 4 个智能体（串行）：12 秒 - 4 个智能体（并行）：3-4 秒 ### C. 优化建议 始终并行化独立工作。AI Hedge Fund 示例通过并行运行四个分析师而不是串行，节省了 9 秒。 ## 3. 错误传播 ### A. 失败模式 - 毒药丸：一个智能体返回垃圾数据，破坏下游智能体 - 死锁：智能体在循环依赖中相互等待 - 资源耗尽：并行智能体都尝试使用相同的速率限制 API - 级联故障：监督者失败，所有工作智能体成为孤儿 ### B. 防御策略 - 每层超时：智能体必须在有界时间内完成 - 熔断器：N 次失败后停止调用有问题的智能体 - 优雅降级：系统应该能在部分智能体的情况下工作 - 隔离状态：工作智能体失败不应破坏共享状态 ## 4. 监控和可观察性 ### A. 必需指标 - 每个智能体的成功率：哪些智能体失败？ - 协调开销：多少时间用于协调 vs 实际工作？ - 按智能体的 token 消耗：成本从哪里来？ - 智能体交互模式：哪些智能体与哪些智能体通信？ ### B. 示例实现 ```typescript class ObservableAgent { async execute(task: Task): Result { const span = tracer.startSpan('agent.execute', { agentId: this.id, taskType: task.type }); try { const result = await this.process(task); span.setStatus({ code: SpanStatusCode.OK }); return result; } catch (error) { span.setStatus({ code: SpanStatusCode.ERROR, message: error.message }); throw error; } finally { span.end(); } } } ``` # 七、常见反模式 ## 1. 过度协调 不要让智能体在不需要时协调。如果智能体在独立任务上工作，让它们独立运行。 ## 2. 万能智能体 不要让一个智能体做所有事情。多智能体的全部意义是专业化。 ## 3. 全部同步 不要在必须时阻塞等待智能体。大多数协调可以是异步的。 ## 4. 忽略成本 不要在不跟踪 token 使用的情况下部署多智能体系统。你会收到惊喜账单。 ## 5. 无备用方案 不要假设所有智能体都能工作。构建降级模式。 # 八、模式选择指南 ## 1. 使用监督者模式当 - 需要可审计性 - 任务清晰分解 - 3-8 个专门智能体 - 质量 > 速度 ## 2. 使用群体模式当 - 需要多个视角 - 没有清晰的任务分解 - 实时响应性关键 - 智能体可以自组织 ## 3. 使用层级模式当 - 管理 10+ 个智能体 - 需要多层抽象 - 需要战略和战术控制 - token 成本可接受 ## 4. 使用单智能体当 - 任务足够简单 - 一个专业领域足够 - 最小化成本很重要 - 还不确定 # 九、入门建议 ## 1. 从简单开始 选择可能工作的最简单模式。大多数团队应该从监督者模式开始： - 构建一个有能力的智能体 - 识别它在哪里挣扎（通常是专业化或并行工作） - 将其提取到第二个智能体 - 添加监督者来协调 - 迭代 ## 2. 循序渐进 不要从第一天就构建复杂的多智能体系统。构建一个智能体，看看它在哪里失效，添加另一个智能体。重复。 ## 3. 实践建议 在构建十个智能体的系统之前，先构建一个可靠地使用两个智能体的系统。 *** ## 参考资料 1. [Agents 201: Orchestrating Multiple Agents That Actually Work](https://x.com/ghumare64/status/2012136491133145364?s=09) 2. [motia-examples - Production-ready multi-agent implementations](https://github.com/MotiaDev/motia-examples) 最后修改：2026 年 01 月 17 日 © 允许规范转载 赞 如果觉得我的文章对你有用，请随意赞赏