第28章 多Agent协作：多个智能体怎么分工配合？

28.1 为什么需要多Agent？

单个Agent已经很强大了，能调用工具、能记住信息、能完成复杂任务。但在某些场景下，单个Agent会遇到瓶颈：

单Agent的局限性：

• 能力单一：一个Agent很难同时精通多个领域（如既懂市场分析又懂代码编写又懂设计），每个领域都需要专门的知识和工具
• 上下文过载：复杂任务涉及大量信息，单个Agent的上下文窗口装不下所有内容（市场数据+代码+设计稿+测试结果）
• 角色冲突：有些任务需要不同角色互相制衡（如写代码的和审代码的不能是同一个，否则发现不了问题）
• 效率低下：单个Agent只能串行执行，多个独立的子任务不能并行处理
• 质量不稳定：单个Agent的输出质量波动大，没有交叉验证和审核机制

多Agent协作的优势：

• 专业化分工：每个Agent专注一个领域（市场分析师、程序员、设计师、测试工程师），专业能力更强
• 并行处理：独立的子任务可以同时执行，大幅提升效率
• 交叉验证：不同Agent从不同角度审查结果，发现单Agent发现不了的问题
• 角色制衡：编写和审核分离，执行和监督分离，提升结果质量和安全性
• 复杂任务拆解：把大任务拆成小任务，每个Agent负责一部分，降低单个Agent的复杂度
• 可扩展性：需要新能力时增加新Agent，不需要修改现有Agent

28.2 多Agent协作的核心模式

多Agent协作有多种组织模式，不同模式适用于不同场景。理解这些模式是设计多Agent系统的基础。

28.2.1 主从模式（Master-Worker / Orchestrator-Worker）

结构：一个"主控Agent"（Orchestrator/Master）负责理解任务、分解任务、分配子任务给"工作Agent"（Worker）、整合结果。工作Agent只负责完成分配的具体子任务，不做全局决策。

工作流程：

用户输入任务
    ↓
主控Agent理解任务，分解成子任务
    ↓
主控Agent把子任务分配给对应的工作Agent
    ↓
工作Agent执行子任务，返回结果给主控Agent
    ↓
主控Agent整合所有结果，生成最终输出

示例：旅行规划Agent

• 主控Agent：旅行规划师，理解用户需求，分解任务
• 工作Agent1：航班查询Agent，负责查机票
• 工作Agent2：酒店查询Agent，负责查酒店
• 工作Agent3：景点推荐Agent，负责推荐景点
• 主控Agent整合机票、酒店、景点，生成完整行程

优点：

• 结构清晰，主控统一调度，容易控制
• 工作Agent职责单一，实现简单
• 结果由主控整合，一致性好

缺点：

• 主控Agent是瓶颈，能力决定整个系统的上限
• 主控分解任务的质量直接影响结果
• 工作Agent之间不能直接通信，必须通过主控中转
• 主控出错会影响整个任务

适用场景：任务可以清晰分解、子任务相对独立、需要统一整合结果的场景。是最常用、最容易实现的多Agent模式。

28.2.2 流水线模式（Pipeline / Sequential）

结构：多个Agent按固定顺序排列，前一个Agent的输出是后一个Agent的输入，像流水线一样依次处理。

工作流程：

原始输入
    ↓
Agent1处理（如：需求分析）
    ↓ 输出1
Agent2处理（如：方案设计）
    ↓ 输出2
Agent3处理（如：编码实现）
    ↓ 输出3
Agent4处理（如：测试审核）
    ↓
最终输出

示例：内容创作流水线

• Agent1：选题策划，根据主题生成文章大纲
• Agent2：内容写作，根据大纲撰写正文
• Agent3：编辑润色，优化语言、调整结构
• Agent4：审核校对，检查事实、错别字、合规性
• 最终输出：一篇经过完整流程的高质量文章

优点：

• 流程固定，每个Agent职责明确，实现简单
• 质量可控，每个环节都有专门的Agent处理
• 容易监控和调试，知道哪个环节出了问题
• 适合标准化的流程化任务

缺点：

• 只能串行，不能并行，效率受最慢的环节限制
• 流程固定，不灵活，无法根据情况调整顺序
• 前一个环节的错误会传递到后面，误差累积
• 没有反馈循环，后面的Agent不能影响前面的决策

适用场景：有明确标准流程、环节顺序固定、每个环节职责清晰的场景，如内容创作、软件开发、数据处理。

28.2.3 对等模式（Peer-to-Peer / Collaborative）

结构：多个Agent地位平等，没有主控，通过消息传递直接通信，共同讨论、协作完成任务。

工作流程：

用户输入任务
    ↓
所有Agent同时理解任务
    ↓
Agent之间互相讨论、交换信息、提出方案
    ↓
通过讨论达成共识或投票决定
    ↓
分工执行，互相反馈
    ↓
共同完成任务

示例：技术方案评审

• Agent1：架构师，关注系统可扩展性
• Agent2：安全专家，关注安全风险
• Agent3：性能专家，关注性能瓶颈
• Agent4：产品经理，关注用户需求和成本
• 四个Agent平等讨论，从各自角度提出意见，最终形成综合方案

优点：

• 没有单点瓶颈，每个Agent都能贡献专业意见
• 多角度思考，结果更全面、更有创意
• Agent之间直接通信，效率高
• 灵活性强，可以根据情况动态调整

缺点：

• 容易陷入讨论，难以达成共识，效率不稳定
• 没有统一调度，可能出现重复工作或遗漏
• 通信复杂，Agent之间的消息管理困难
• 结果质量不稳定，取决于讨论质量
• 实现难度大，需要设计通信协议和共识机制

适用场景：需要多角度思考、创意发散、专家评审的场景，如方案评审、头脑风暴、复杂问题分析。

28.2.4 委员会模式（Committee / Debate）

结构：多个Agent从不同角度独立分析同一个问题，然后由一个"裁判Agent"或投票机制整合各方意见，做出最终决策。

工作流程：

用户输入问题
    ↓
多个Agent从不同角度独立分析（并行）
    ↓
每个Agent给出自己的结论和理由
    ↓
裁判Agent整合各方意见，或投票决定
    ↓
最终结论

示例：投资决策

• Agent1：基本面分析师，分析公司财务和行业
• Agent2：技术分析师，分析股价走势和技术指标
• Agent3：风险分析师，分析潜在风险和下行空间
• Agent4：市场情绪分析师，分析市场情绪和资金流向
• 裁判Agent：综合四个分析师的意见，给出投资建议（买入/持有/卖出）

优点：

• 多角度独立分析，避免单一视角的偏见
• 可以并行分析，效率高
• 通过裁判或投票整合，结果更客观
• 每个Agent的分析过程透明，可追溯

缺点：

• 多个Agent独立分析，成本高（token消耗是单Agent的N倍）
• 裁判Agent的整合能力决定最终质量
• 各方意见冲突时，裁判难以抉择
• 不适合需要深度协作的任务，只适合分析决策类任务

适用场景：需要多角度分析、决策支持、风险评估的场景，如投资决策、医疗诊断、政策评估、风险审查。

28.2.5 模式选择指南

28.3 角色设计：怎么定义Agent的角色和职责

多Agent协作的核心是"专业化分工"，每个Agent扮演一个角色。角色设计的质量直接决定了多Agent系统的效果。

28.3.1 角色设计的原则

1. 单一职责（Single Responsibility）
每个Agent只负责一个明确的职责，不要让一个Agent做太多事情。职责越单一，Agent越专业，输出质量越高。
错误示例：一个Agent既写代码又做测试又写文档（什么都做但什么都不精）
正确示例：程序员Agent写代码，测试Agent做测试，文档Agent写文档

2. 职责清晰、边界明确
每个Agent的职责范围要清晰定义，避免职责重叠（两个Agent做同一件事）或职责空白（没人做某件事）。
要明确：这个Agent负责什么？不负责什么？和其他Agent的边界在哪里？

3. 专业能力匹配
每个Agent的角色要和它的能力匹配。给Agent配备它擅长的工具、知识、Prompt，让它在自己的领域做到专业。
例如：市场分析师Agent配备市场数据查询工具、行业报告知识库；程序员Agent配备代码执行工具、API文档、代码库。

4. 角色之间有协作接口
定义清楚每个Agent的输入和输出格式，让Agent之间能顺畅协作。前一个Agent的输出要能被后一个Agent直接使用，不需要人工转换。
例如：需求分析师Agent输出结构化的PRD（JSON格式），程序员Agent能直接读取PRD开始编码。

5. 避免角色冲突
有利益冲突或需要制衡的角��要分开，不能由同一个Agent担任。
例如：写代码的和审代码的要分开；做决策的和监督执行的要分开；运动员和裁判员不能是同一个。

28.3.2 角色定义的要素

每个Agent的角色定义应该包含以下要素：

{
  "角色名称": "市场分析师",
  "角色描述": "你是一位资深市场分析师，擅长行业研究、竞品分析、市场趋势预测。你会基于数据和事实给出客观的分析结论。",
  "职责范围": [
    "收集和整理市场数据、行业报告",
    "分析市场规模、增长率、竞争格局",
    "识别市场机会和风险",
    "输出市场分析报告"
  ],
  "不负责": [
    "产品功能设计（由产品经理负责）",
    "技术方案设计（由架构师负责）",
    "最终决策（由主控/裁判负责）"
  ],
  "可用工具": [
    "市场数据查询API",
    "行业报告知识库",
    "竞品信息检索",
    "数据分析工具"
  ],
  "输入格式": "市场分析需求（JSON：目标市场、时间范围、分析维度）",
  "输出格式": "市场分析报告（JSON：市场规模、增长率、竞争格局、机会风险、建议）",
  "工作原则": [
    "基于数据和事实，不主观臆断",
    "明确区分事实和推断",
    "给出结论的同时说明依据和置信度",
    "发现数据不足时明确指出，不编造"
  ]
}

28.3.3 常见的角色组合

内容创作团队：

• 选题策划：确定主题、角度、大纲
• 内容写作：撰写正文
• 编辑润色：优化语言、调整结构
• 审核校对：检查事实、错别字、合规性
• 视觉设计：配图、排版（可选）

软件开发团队：

• 产品经理：需求分析、PRD撰写
• 架构师：技术方案设计、API设计
• 项目经理：任务分解、排期、协调
• 前端工程师：前端代码编写
• 后端工程师：后端代码编写
• 测试工程师：测试用例编写、执行测试、Bug反馈
• 运维工程师：部署、监控（可选）

咨询顾问团队：

• 行业分析师：行业研究、趋势分析
• 业务顾问：业务流程分析、优化建议
• 技术顾问：技术方案评估、选型建议
• 数据分析师：数据分析、指标解读
• 项目经理：项目管理、进度控制

投资研究团队：

• 基本面分析师：财务分析、估值
• 行业分析师：行业研究、竞争格局
• 技术分析师：股价走势、技术指标
• 风险分析师：风险评估、下行分析
• 投资经理：综合判断、投资决策

28.4 通信机制：Agent之间怎么交流

多Agent协作需要Agent之间交换信息。通信机制的设计决定了协作的效率和可靠性。

28.4.1 消息传递（Message Passing）

原理：Agent之间通过发送消息直接通信，消息包含发送者、接收者、内容、时间戳等。

消息格式：

{
  "message_id": "msg_001",
  "from": "orchestrator",
  "to": "market_analyst",
  "type": "task_assignment",  // 任务分配 / 结果返回 / 问题询问 / 意见反馈
  "content": {
    "task": "分析2024年中国新能源汽车市场",
    "requirements": ["市场规模", "增长率", "主要玩家", "趋势预测"],
    "deadline": "2024-10-20"
  },
  "timestamp": "2024-10-15T10:30:00",
  "context": {
    "project_id": "proj_001",
    "conversation_id": "conv_001"
  }
}

优点：

• 直接、高效，Agent之间可以实时交流
• 消息格式结构化，容易处理和追踪
• 支持点对点、广播、组播等多种通信方式
• 消息历史可以记录和回溯

缺点：

• 需要设计消息协议和路由机制
• Agent数量多时，消息管理复杂
• 需要处理消息丢失、重复、乱序等问题

适用场景：主从模式、对等模式，Agent之间需要频繁交互的场景。

28.4.2 共享内存（Shared Memory / Blackboard）

原理：所有Agent共享一个"黑板"（共享存储区域），Agent把自己的输出写到黑板上，其他Agent可以从黑板上读取需要的信息。Agent之间不直接通信，通过黑板间接交换信息。

工作流程：

主控Agent把任务需求写到黑板上
    ↓
市场分析师Agent从黑板读取需求，完成分析后把结果写到黑板
    ↓
产品经理Agent从黑板读取市场分析结果，结合需求写PRD，写到黑板
    ↓
程序员Agent从黑板读取PRD，编写代码，把代码写到黑板
    ↓
测试Agent从黑板读取代码，执行测试，把测试结果写到黑板
    ↓
主控Agent从黑板读取所有结果，整合输出

黑板数据结构：

{
  "project_id": "proj_001",
  "task": "开发一个待办事项APP",
  "status": "in_progress",
  "artifacts": {
    "market_analysis": {...},      // 市场分析师写入
    "prd": {...},                   // 产品经理写入
    "architecture": {...},          // 架构师写入
    "code": {...},                  // 程序员写入
    "test_report": {...}            // 测试工程师写入
  },
  "messages": [
    {"from": "orchestrator", "content": "任务开始", "time": "..."},
    {"from": "market_analyst", "content": "市场分析已完成", "time": "..."}
  ],
  "updated_at": "2024-10-15T10:30:00"
}

优点：

• 解耦，Agent之间不需要知道对方的存在，只需要读写黑板
• 信息集中管理，容易监控和调试
• 支持异步协作，Agent可以在不同时间工作
• 新Agent加入时，只需要能读写黑板，不需要修改通信协议

缺点：

• 黑板是单点，可能成为性能瓶颈
• 并发写入需要处理冲突（多个Agent同时写同一个字段）
• Agent需要知道什么时候该读、什么时候该写（需要触发机制）
• 不适合需要实时交互的场景

适用场景：流水线模式、主从模式，任务可以分解为独立的产出物，Agent之间通过产出物协作。

28.4.3 通信机制选择

28.5 任务分解与分配

多Agent协作的第一步是把大任务分解成小任务，然后分配给合适的Agent。任务分解和分配的质量直接影响最终结果。

28.5.1 任务分解的原则

1. 高内聚、低耦合
每个子任务内部要高度相关（高内聚），子任务之间尽量独立（低耦合）。耦合度越低，越容易并行执行，越不容易互相影响。

2. 粒度适中
子任务不能太大（一个Agent做不完，或者需要多种能力），也不能太小（ overhead太大，管理成本高）。
通常一个子任务对应一个Agent的一次完整工作（如"写一篇市场分析报告"、"实现用户登录模块"）。

3. 依赖关系清晰
明确子任务之间的依赖关系：哪些可以并行，哪些必须串行，哪些需要等待其他任务完成。
用DAG（有向无环图）表示任务依赖关系，方便调度。

4. 可验证
每个子任务完成后有明确的验收标准，能判断是否完成、质量如何。

28.5.2 任务分解的方法

方法1：按阶段分解
按任务的执行阶段分解，适用于有明确流程的任务。
示例：软件开发 → 需求分析 → 架构设计 → 编码 → 测试 → 部署

方法2：按专业领域分解
按不同的专业领域分解，适用于需要多种专业能力的任务。
示例：市场进入策略 → 市场分析（市场分析师）+ 竞品分析（竞品研究员）+ 用户调研（用户研究员）+ 财务测算（财务分析师）

方法3：按产出物分解
按最终需要的产出物分解，每个子任务负责一个产出物。
示例：商业计划书 → 执行摘要 + 市场分析 + 产品方案 + 运营计划 + 财务预测 + 风险分析

方法4：按问题维度分解
按需要分析的不同维度分解，适用于分析决策类任务。
示例：投资决策 → 基本面分析 + 技术面分析 + 风险分析 + 市场情绪分析

28.5.3 任务分配策略

1. 能力匹配
把子任务分配给最擅长的Agent。根据Agent的专业能力、历史表现、可用工具来匹配。
例如：市场分析任务分配给市场分析师Agent，编码任务分配给程序员Agent。

2. 负载均衡
避免某个Agent任务过多，其他Agent空闲。合理分配任务，充分利用所有Agent的能力。

3. 依赖调度
根据任务依赖关系调度：没有依赖的任务先执行（并行），有依赖的任务等前置任务完成后再执行。
用DAG调度器自动管理任务执行顺序。

4. 动态调整
执行过程中根据情况动态调整：某个Agent失败了，把任务重新分配给其他Agent；某个任务比预期复杂，增加资源或拆分。

28.6 结果整合与冲突解决

多个Agent各自完成子任务后，需要把结果整合成最终输出。如果Agent之间有冲突（意见不一致、结果矛盾），还需要解决冲突。

28.6.1 结果整合的方法

方法1：模板整合
预定义最终输出的模板，每个Agent的结果填入模板的对应位置。
示例：商业计划书模板有固定的章节（执行摘要、市场分析、产品方案...），每个Agent负责一个章节，最后按模板组装。
优点：结构清晰、一致性好。
缺点：灵活性差，不适合非结构化输出。

方法2：主控整合
由主控Agent读取所有子任务结果，理解后重新组织、提炼、生成最终输出。
优点：灵活，能处理复杂的整合需求，能发现和解决冲突。
缺点：主控Agent的能力决定整合质量，可能遗漏重要信息。
这是最常用的整合方法。

方法3：投票整合
多个Agent对同一个问题给出答案，通过投票决定最终结果（多数票获胜）。
适用于：选择题、分类任务、有明确标准答案的场景。
优点：简单客观，减少单一Agent的偏见。
缺点：不适合开放性问题，多数不一定对。

方法4：加权整合
给不同Agent的结果赋予不同权重（根据专业能力、历史表现、置信度），加权计算最终结果。
示例：投资决策中，基本面分析师权重0.4，技术分析师权重0.2，风险分析师权重0.3，市场情绪分析师权重0.1。
优点：更合理，专家意见权重更高。
缺点：权重设定主观，需要验证。

28.6.2 冲突解决策略

冲突类型：

• 意见冲突：不同Agent对同一个问题有不同看法（如A说应该做，B说不应该做）
• 数据冲突：不同Agent给出的数据不一致（如A说市场规模100亿，B说200亿）
• 优先级冲突：不同Agent对任务优先级有不同判断
• 资源冲突：多个Agent同时需要同一个资源（如同时写黑板的同一个字段）

解决策略：

策略1：讨论协商
让有冲突的Agent互相说明理由，通过讨论达成共识。
适用于：意见冲突，需要深入分析的场景。
优点：能深入理解各方理由，结果质量高。
缺点：耗时，可能讨论不出结果。

策略2：裁判裁决
由一个中立的裁判Agent（或主控Agent）听取各方意见后做出裁决。
适用于：需要快速决策、讨论无法达成共识的场景。
优点：高效，有最终决策者。
缺点：裁判的能力决定裁决质量，可能有偏见。

策略3：投票决定
所有相关Agent投票，多数票获胜。
适用于：有明确选项、需要民主决策的场景。
优点：简单、公平、客观。
缺点：多数不一定对，不适合复杂问题。

策略4：数据验证
对于数据冲突，通过查询权威数据源、重新计算来验证，用事实说话。
适用于：数据冲突、事实性争议。
优点：客观、准确。
缺点：需要可验证的数据源，有些问题无法验证。

策略5：分场景处理
如果各方意见在不同场景下都有道理，把不同场景分开，分别给出建议。
示例：A说"应该用方案X"，B说"应该用方案Y"。最终结论："如果预算充足用方案X，如果预算有限用方案Y"。
优点：灵活，兼顾各方意见。
缺点：结论不够明确，用户需要自己判断。

28.7 主流多Agent框架对比

选型建议：

• 软件开发类任务 → MetaGPT（SOP驱动，角色化，结构化输出）
• 需要灵活对话和人类介入 → AutoGen（微软，对话式，人类在环）
• 中小规模、快速原型 → CrewAI（轻量，学习成本低）
• 复杂流程、需要精细控制 → LangGraph（图状编排，状态管理）
• 已有LangChain技术栈 → LangGraph（和LangChain生态集成好）

28.8 A2A协议：跨框架跨厂商的Agent协作标准

28.8.1 为什么需要A2A协议

前面我们学习的多Agent协作模式（顺序、并行、层级、辩论等），大多是在同一个框架、同一个应用内部实现的。但在真实的企业环境中，Agent可能来自不同厂商、不同框架、不同组织——市场部用CrewAI开发了内容创作Agent，技术部��LangGraph开发了代码审查Agent，外部咨询公司用AutoGen开发了行业研究Agent。这些Agent之间如何协作？

在A2A协议出现之前，答案是：很难。每个Agent都有自己的API接口、数据格式、认证方式，要让它们互相通信，需要大量定制化开发，而且维护成本极高。这就像互联网出现之前，每台计算机都要单独建专线连接一样。

2025年4月，Google发布了A2A（Agent2Agent Protocol）协议，彻底改变了这一局面。A2A就像Agent世界的"HTTP协议"——HTTP不管你后端是Rails还是Go，它只定义"请求-响应"的标准格式；A2A不管你的Agent是用LangGraph还是CrewAI开发的，它只定义Agent之间"发现对方、商量事情、把活派出去、把结果拿回来"的标准格式。

28.8.2 A2A的核心架构

A2A的核心结构包括：

1. Agent Card（智能体名片）：JSON格式的元数据文档，发布在/.well-known/agent.json，描述Agent的身份、能力、技能、端点、认证要求。其他Agent通过Agent Card发现和了解这个Agent能做什么。就像每个人的名片，上面写着姓名、职位、联系方式、擅长领域。
2. Task（任务）：Agent间协作的基本单位，一个Agent向另一个Agent发送Task请求，对方执行后返回结果。支持多轮状态编排，Task可以有状态（pending、working、completed、failed等）。
3. Push Notifications（推送通知）：支持实时推送，Agent可以主动向其他Agent推送状态更新和结果通知，不需要轮询。就像微信消息推送，而不是不停地刷新邮箱。
4. Artifacts（产物）：Agent执行任务产生的输出结果，可以是文本、文件、结构化数据等。

A2A的通信模式：

• 请求-响应模式：一个Agent发送Task请求，另一个Agent同步返回结果。适合简单、快速的任务。
• 异步任务模式：一个Agent发送Task请求，对方返回Task ID，发起方可以后续查询Task状态或接收推送通知。适合耗时较长的复杂任务。
• 流式输出模式：支持流式传输，Agent可以边执行边返回中间结果。适合需要实时反馈的场景。

28.8.3 A2A vs 内部多Agent协作

28.8.4 A2A的产品设计意义

对AI产品经理来说，A2A的出现开启了"Agent经济"的新篇章，具有深远的产品设计意义：

1. 能力市场化：企业可以将自己的专业能力封装为A2A Agent，对外提供服务，形成新的商业模式。例如：法律事务所提供合同审查Agent、会计师事务所提供财务分析Agent、咨询公司提供行业研究Agent。你的Agent能力可以像SaaS产品一样对外售卖。
2. 组合创新：产品经理可以像搭积木一样，组合不同专业领域的Agent，创造全新的产品和服务。例如：市场研究Agent+数据分析Agent+报告生成Agent=智能咨询产品。不需要自己开发所有能力，通过A2A组合就能创新。
3. 跨组织协作：企业间的Agent可以通过A2A安全协作，不需要暴露内部系统和数据。例如：品牌方的营销Agent可以直接调用代理商的投放Agent，实现跨组织的自动化营销。供应链上下游的Agent可以自动协同。
4. 专业化分工：就像人类社会有专业分工一样，Agent世界也会形成专业化分工——有的Agent擅长法律、有的擅长财务、有的擅长编程，通过A2A协作完成复杂任务。产品经理不需要做"全能Agent"，而是做"专业Agent+协作网络"。
5. 安全可信：A2A v1.2引入了加密签名的Agent Card（JWS签名文档），确保Agent身份可信，防止伪造和钓鱼。企业可以建立可信Agent目录，只与经过认证的Agent协作。

28.8.5 MCP + A2A：Agent的完整技术栈

MCP和A2A不是竞争关系，而是互补关系，共同构成了Agent的完整技术栈：

• MCP：解决"单个Agent如何调用外部工具和数据"的问题，是Agent的"手"
• A2A：解决"多个Agent之间如何通信和协作"的问题，是Agent的"同事"

一个典型的企业级Agent架构是：Agent通过MCP协议调用企业内部的工具和数据源（ERP、CRM、数据库等），同时通过A2A协议与其他Agent（内部其他部门的Agent、外部合作伙伴的Agent、第三方专业服务Agent）协作。MCP负责纵向的工具接入，A2A负责横向的Agent协作，两者结合构成了完整的Agent互联生态。

28.9 实战：设计一个内容创作多Agent团队

让我们通过一个完整的实战案例，看看如何设计和实现一个内容创作多Agent团队。

28.8.1 场景定义

目标：设计一个AI内容创作团队，能根据用户给定的主题，自动完成从选题到成稿的完整内容创作流程，输出高质量的公众号文章。

核心需求：

• 输入：文章主题、目标读者、风格要求
• 输出：一篇完整的、高质量的公众号文章（标题+正文+配图建议）
• 流程：选题策划 → 大纲撰写 → 内容写作 → 编辑润色 → 审核校对
• 质量要求：逻辑清晰、内容扎实、语言流畅、无错别字、符合平台规范

28.8.2 角色设计

角色1：选题策划师（Planner）

• 职责：根据主题确定文章角度、核心观点、目标读者痛点，撰写详细大纲
• 输入：主题、目标读者、风格要求
• 输出：文章大纲（JSON：标题建议、核心观点、章节结构、每节要点、参考资料方向）
• 工具：热点趋势查询、竞品文章检索、关键词分析

角色2：内容写作师（Writer）

• 职责：根据大纲撰写正文，确保内容扎实、逻辑清晰、有深度
• 输入：文章大纲、参考资料
• 输出：文章正文（Markdown格式）
• 工具：知识库检索、数据查询、案例库
• 原则：每个观点有论据，每个结论有依据，不编造事实

角色3：编辑润色师（Editor）

• 职责：优化文章结构、语言表达、阅读体验，调整风格，增加吸引力
• 输入：文章初稿
• 输出：润色后的文章
• 工作内容：优化标题、调整段落结构、简化长句、增加过渡、优化开头结尾、控制字数

角色4：审核校对师（Reviewer）

• 职责：检查事实准确性、错别字、语法错误、合规性、平台规范
• 输入：润色后的文章
• 输出：审核报告（问题列表+修改建议）+ 最终定稿
• 检查项：事实核查、错别字、语法、敏感词、版权、引用规范、字数达标

角色5：主控协调师（Orchestrator）

• 职责：理解用户需求，协调各角色工作，整合结果，处理异常
• 工作流程：接收需求 → 分配给策划师 → 把大纲给写作师 → 把初稿给编辑 → 把润色稿给审核 → 整合最终输出
• 异常处理：某个角色失败时重新分配或调整策略；审核不通过时返回修改

28.8.3 协作流程设计

模式选择：流水线模式 + 主控协调（主从）
原因：内容创作有明确的标准流程，每个环节职责清晰，适合流水线；同时需要主控协调进度和处理异常。

详细流程：

第0步：用户输入
用户："写一篇关于'AI产品经理需要掌握哪些技术'的公众号文章，目标读者是想转行做AI产品经理的人，风格通俗易懂，字数3000字左右"

第1步：选题策划（Planner）
- 理解主题和目标读者
- 分析目标读者痛点：想转行但不知道学什么、担心技术门槛高、不知道从哪开始
- 确定文章角度：从"不需要掌握底层技术，但要理解技术原理和边界"切入，降低焦虑
- 撰写大纲：
  - 标题建议：《AI产品经理需要懂技术吗？这5个技术概念你必须懂》
  - 核心观点：AI产品经理不需要会写代码，但必须理解技术原理、能力边界和应用场景
  - 章节结构：
    1. 开头：AI产品经理要不要懂技术？（破题，引发共鸣）
    2. 大模型基础：原理、能力、局限（核心概念1）
    3. Prompt工程：怎么和大模型高效沟通（核心概念2）
    4. RAG知识库：怎么让大模型用你的数据（核心概念3）
    5. Agent与工具调用：怎么让大模型做事（核心概念4）
    6. 评估与优化：怎么判断AI产品好不好（核心概念5）
    7. 结尾：学习路径和资源推荐（行动指引）
- 输出：结构化大纲JSON

第2步：内容写作（Writer）
- 读取大纲，理解文章结构和核心观点
- 逐节撰写正文：
  - 每节开头有引入，中间有论点+论据+案例，结尾有小结
  - 用通俗易懂的语言解释技术概念，配真实案例
  - 每个技术概念讲清楚：是什么、为什么重要、产品经理需要懂到什么程度、实际应用场景
- 控制字数在3000字左右
- 输出：Markdown格式的初稿

第3步：编辑润色（Editor）
- 读取初稿，整体把握
- 优化标题：更吸引人、有数字、有痛点
- 优化开头：3秒抓住读者，引发共鸣
- 调整结构：段落长短适中，逻辑过渡自然
- 优化语言：简化长句，用读者听得懂的话，增加金句
- 优化结尾：总结要点，给出行动建议，引导互动
- 检查字数：确保在要求范围内
- 输出：润色后的文章

第4步：审核校对（Reviewer）
- 事实核查：技术概念是否准确，案例是否真实，数据是否有来源
- 错别字检查：逐字检查错别字、标点错误
- 语法检查：语句通顺，没有语法错误
- 合规检查：没有敏感词、没有侵权内容、引用规范
- 平台规范：符合公众号文章规范（标题长度、正文格式、配图建议）
- 输出审核报告：
  - 发现的问题：如"第3节'大模型参数'表述不准确，应为'模型规模'"
  - 修改建议：具体的修改方案
  - 审核结论：通过/需修改
- 如果需修改，返回给编辑或写作修改，然后重新审核
- 输出：最终定稿

第5步：主控整合（Orchestrator）
- 收集最终定稿
- 添加配图建议（每节配什么图）
- 添加文章元信息（标题、摘要、标签、分类）
- 输出最终成果给用户

28.8.4 通信与状态管理

用黑板（共享内存）管理产出物：

{
  "article_id": "art_001",
  "topic": "AI产品经理需要掌握哪些技术",
  "target_audience": "想转行做AI产品经理的人",
  "style": "通俗易懂",
  "word_count_target": 3000,
  "status": "reviewing",
  "artifacts": {
    "outline": {...},           // Planner写入
    "draft": "...",             // Writer写入
    "polished": "...",          // Editor写入
    "review_report": {...},     // Reviewer写入
    "final": "..."              // 最终定稿
  },
  "current_step": "review",
  "history": [
    {"step": "planning", "status": "completed", "time": "..."},
    {"step": "writing", "status": "completed", "time": "..."},
    {"step": "editing", "status": "completed", "time": "..."},
    {"step": "reviewing", "status": "in_progress", "time": "..."}
  ]
}

用消息传递做通知和协调：

• Planner完成大纲后，发消息给Orchestrator："大纲已完成，请分配给Writer"
• Orchestrator发消息给Writer："请根据大纲撰写正文"
• Reviewer审核不通过时，发消息给Editor："发现3个问题，请修改后重新提交"

28.8.5 质量控制机制

1. 每步验收
每个Agent完成后，主控检查产出物是否达标（如大纲是否完整、初稿字数是否达标、审核是否通过），不达标则返回修改。

2. 审核闭环
审核不通过的文章必须修改后重新审核，直到通过才能输出。审核报告要具体（哪个位置、什么问题、怎么改），不能只说"有问题"。

3. 人工兜底
重要文章或AI无法���断的问题，引入人工审核。用户可以在任何环节介入，修改或调整。

4. 效果反馈
文章发布后收集数据（阅读量、点赞、转发、评论），反馈给系统，持续优化各Agent的Prompt和策略。

28.10 多Agent的成本、延迟、可靠性权衡

多Agent虽然强大，但也有代价。设计多Agent系统时需要在成本、延迟、可靠性之间做权衡。

28.9.1 成本

多Agent的成本是单Agent的N倍（N是Agent数量和调用次数）。

成本构成：

• 大模型调用费用：每个Agent都要调用大模型，Agent越多、对话轮次越多，费用越高
• 工具调用费用：每个Agent可能调用不同的工具（搜索API、数据库、第三方服务）
• 基础设施费用：向量数据库、消息队列、存储、计算资源
• 运维成本：多Agent系统更复杂，需要更多的监控、调试、维护

成本优化策略：

• 用更小更便宜的模型做简单任务（如用GPT-4o-mini做格式整理，用GPT-4o做核心分析）
• 减少不必要的Agent和对话轮次，能一个Agent做的不要拆成多个
• 缓存常用结果，减少重复计算
• 设置最大调用次数上限，避免无限循环
• 批量处理，减少API调用次数

28.9.2 延迟

多Agent的延迟通常比单Agent高，因为多个Agent串行或并行执行，还有通信和整合的开销。

延迟构成：

• 计算延迟：每个Agent调用大模型的时间（通常2-10秒/次）
• 通信延迟：Agent之间传递消息、读写共享存储的时间
• 等待延迟：有依赖关系的任务需要等待前置任务完成
• 整合延迟：主控整合多个Agent结果的时间

延迟优化策略：

• 并行执行无依赖的子任务，减少总时间
• 用更快的模型（如GPT-4o比GPT-4快）
• 减少Agent之间的通信轮次，批量传递信息
• 流水线设计，前一个Agent输出部分结果后，后一个Agent就可以开始处理（不需要等全部完成）
• 给用户展示进度（"正在分析市场...正在撰写初稿..."），提升等待体验
• 设置超时机制，避免某个Agent卡住导致整个任务超时

28.9.3 可靠性

多Agent的可靠性是个挑战：任何一个Agent出错都可能影响最终结果，Agent越多，出错概率越高（可靠性是乘法关系）。

常见故障：

• 某个Agent调用大模型失败（API错误、超时、限流）
• 某个Agent输出格式错误，后续Agent无法解析
• Agent之间理解不一致，导致结果矛盾
• 任务分解不合理，遗漏重要部分
• 整合时丢失重要信息
• 陷入死循环或讨论不出结果

可靠性提升策略：

• 重试机制：Agent调用失败时自动重试（有上限），换模型或换参数
• 降级处理：某个Agent不可用时，用简化方案或跳过该环节（标注质量可能受影响）
• 格式校验：每个Agent的输出都做格式校验，不符合要求则重新生成
• 检查点：每个关键环节完成后做检查，不达标则返回修改，避免错误传递到后面
• 冗余设计：关键任务由多个Agent独立完成，取最优或投票结果
• 超时控制：每个Agent和整个任务都设置超时，超时则终止并返回部分结果
• 人工兜底：重要场景引入人工审核和干预
• 监控告警：实时监控每个Agent的状态，发现异常及时告警和处理

28.9.4 权衡决策

28.11 产品经理视角：什么时候用多Agent

1. 不要为了用多Agent而用多Agent
很多产品经理觉得多Agent很酷，什么任务都想用多Agent。其实多Agent是有代价的（成本高、延迟高、复杂度高、可靠性挑战）。只有当单Agent确实无法满足需求时，才考虑多Agent。

2. 判断是否需要多Agent的标准
问自己以下问题，如果有多个"是"，就考虑多Agent：

• 任务是否需要多种完全不同的专业能力？（如既需要市场分析又需要代码编写）
• 任务是否可以清晰分解为独立的子任务？
• 是否有角色制衡的需求？（如编写和审核必须分离）
• 单Agent的上下文窗口是否装不下所有信息？
• 是否需要并行处理以提升效率？
• 是否需要多角度分析以提升结果质量？

3. 从单Agent开始，逐步演进到多Agent
建议的演进路径：

• 第一阶段：单Agent，验证核心需求和产品价值
• 第二阶段：单Agent+工具+记忆，提升能力
• 第三阶段：简单多Agent（主从模式，2-3个Agent），解决单Agent的瓶颈
• 第四阶段：复杂多Agent（流水线/委员会，多个专业Agent），处理复杂任务

4. 多Agent的产品设计要点

• 透明化：让用户看到多Agent的工作过程（"市场分析师正在分析...程序员正在编码..."），提升信任感
• 可干预：用户可以在任何环节介入，修改某个Agent的输出，调整方向
• 可追溯：每个产出物都能追溯到是哪个Agent、在什么时间、基于什么输入生成的
• 质量可控：有关键环节的审核机制，有质量标准，有问题能发现和修正
• 成本可控：用户知道大概的成本和时间，有预算控制，不会出现"天价账单"

5. 评估多Agent系统的效果

• 质量指标：和单Agent对比，结果质量提升了多少？（人工评分、用户满意度、错误率）
• 效率指标：完成任务的时间？并行处理提升了多少效率？
• 成本指标：单次任务的成本？和质量提升相比是否值得？
• 可靠性指标：任务成功率？故障率？平均故障恢复时间？
• 用户体验：用户是否理解多Agent的工作方式？是否觉得有价值？是否愿意付费？

28.12 本章小结

多Agent协作是Agent能力的重要延伸，让多个专业Agent分工配合，完成单Agent无法完成的复杂任务。

核心模式：

• 主从模式：主控分解分配，工作Agent各司其职，最常用最容易实现
• 流水线模式：按固定流程依次处理，质量可控，适合标准化任务
• 对等模式：平等讨论协作，多角度思考，适合创意发散
• 委员会模式：多专家独立分析+裁判整合，适合决策支持

关键设计要素：

• 角色设计：单一职责、边界明确、专业匹配、协作接口、避免冲突
• 通信机制：消息传递（直接实时）、共享内存/黑板（解耦异步）、混合模式
• 任务分解：高内聚低耦合、粒度适中、依赖清晰、可验证
• 结果整合：模板整合、主控整合、投票、加权
• 冲突解决：讨论协商、裁判裁决、投票、数据验证、分场景处理

权衡与注意：

• 多Agent有代价：成本高（N倍）、延迟高、复杂度高、可靠性挑战
• 不要为了用多Agent而用，单Agent能搞定的就用单Agent
• 从单Agent开始，逐步演进到多Agent
• 产品设计要透明化、可干预、可追溯、质量可控、成本可控
• 用数据评估多Agent的效果，确保增加的复杂度带来了足够的价值

多Agent是AI产品经理设计复杂AI系统的重要能力。理解协作模式、角色设计、通信机制、权衡取舍，能帮助你在合适的场景用合适的方式设计多Agent系统，而不是盲目追求"酷"。下一章我们会讲Agent评估体系——Agent上线后怎么知道好不好，怎么监控和持续优化。

📝 本章练习（9题）

答案与解析请在 互动学习看板 中作答查看。

📚 AI产品经理实战训练营 课程目录（44 章）

1. 第1章 AI产品经理是做什么的？和传统PM有什么区别？
2. 第2章 2026年AI产品经理就业市场：哪些行业在招？薪资多少？
3. 第3章 零经验转行AI产品经理的3条路径
4. 第4章 AI产品全景图：从聊天机器人到Agent，一文搞懂
5. 第5章 AI产品经理能力模型：你需要掌握哪些技能？
6. 第6章 实战：拆解3个你每天在用的AI产品
7. 第7章 大模型是什么？用大白话讲清楚
8. 第8章 主流大模型对比：GPT-4o、Claude、DeepSeek、豆包、Kimi怎么选？
9. 第9章 Prompt入门：写好提示词的5个原则
10. 第10章 Prompt进阶：System Prompt、COT思维链、Few-shot示例
11. 第11章 结构化输出：让大模型返回JSON、表格、代码
12. 第12章 Prompt优化实战：从垃圾Prompt到高质量Prompt
13. 第13章 大模型的"幻觉"问题：产品经理怎么应对？
14. 第14章 实战：为一个智能客服设计完整Prompt体系
15. 第15章 RAG是什么？为什么企业都在做知识库？
16. 第16章 RAG工作原理：文档→分块→向量→检索→生成
17. 第17章 向量数据库选型：Milvus、Pinecone、Chroma、pgvector怎么选？
18. 第18章 Embedding模型选型：OpenAI、BGE、M3E、GTE对比
19. 第19章 Reranker重排序：让检索结果更精准
20. 第20章 查询改写与混合检索：提升召回率的实战技巧
21. 第21章 知识库运营：文档治理、更新机制、效果监控
22. 第22章 实战：从零搭建一个企业知识库（完整流程）
23. 第23章 Agent是什么？和聊天机器人有什么区别？
24. 第24章 Agent核心能力：感知、规划、工具调用、记忆
25. 第25章 主流Agent框架与协议：Agent Harness、MCP、A2A全解析
26. 第26章 工具调用（Function Calling）原理与实战
27. 第27章 Agent记忆系统：短期记忆、长期记忆、向量记忆
28. 第28章 多Agent协作：多个智能体怎么分工配合？
29. 第29章 Agent评估体系：成功率、成本、延迟怎么监控？
30. 第30章 实战：设计一个制造业生产异常处理Agent
31. 第31章 AI产品需求分析：怎么识别真需求还是伪需求？
32. 第32章 AI产品竞品分析：怎么调研和拆解竞品？
33. 第33章 AI产品PRD撰写：技术可行性、数据需求、评估指标
34. 第34章 AI产品原型设计：对话流、状态机、异常处理
35. 第35章 AI产品数据指标体系：从DAU到模型准确率，全面监控
36. 第36章 AI项目管理：从需求到上线的全流程管控
37. 第37章 实战项目1：从零搭建制造业AI智能质检系统
38. 第38章 实战项目2：从零搭建企业级AI知识库（RAG系统）
39. 第39章 AI产品经理简历优化：让HR一眼看中你
40. 第40章 项目经验包装：把普通项目讲成亮眼案例
41. 第41章 AI产品经理面试常见问题：提前准备，从容应对
42. 第42章 案例分析面试：用结构化思维征服面试官
43. 第43章 薪资谈判：拿到你应得的报酬
44. 第44章 入职前3个月：快速站稳脚跟，建立信任