10.4 智能体间协作

多智能体系统通过将复杂任务分解为可管理的专门化组件，克服了单智能体的能力局限。协作架构可以分为两大类：中心化协调模式和去中心化对等模式。

10.4.1 协调者-执行者架构

这是最常见的多智能体架构。一个中心智能体负责任务分解和调度，多个专门化智能体负责执行子任务。

金融研报生成团队示例

研究主管（Supervisor）：负责理解用户需求、分配任务、协调进度、质量把控
数据分析师（Data Analyst）：收集市场数据、计算财务指标、生成图表
行业研究员（Industry Researcher）：分析行业趋势、竞争格局、政策影响
报告撰写员（Report Writer）：整合信息、撰写分析文本、格式化输出

当用户请求生成某公司 Q3 财报分析报告时：

研究主管将任务拆解为数据收集、行业分析、报告撰写三个子任务
数据分析师获取财务数据并计算关键指标
行业研究员分析宏观环境和竞争态势
报告撰写员整合两方信息形成结构化报告
研究主管审核并返回最终成果

优势： - 控制流程清晰，便于调试和监控 - 任务分配由中心统一决策，避免冲突 - 易于实现质量检查点和人工介入 - 便于审计和复现完整的任务分配日志

适用场景： - 任务结构相对固定，可预先定义分解策略 - 需要严格的质量管控和审批流程 - 子任务间依赖关系明确

10.4.2 对等协作模式

去中心化架构中，智能体地位平等，可以直接相互通信和协商。没有中央控制者，各智能体通过消息传递和协商机制达成协作。

工作原理

     智能体 A ←→ 智能体 B
         ↕  ╳  ↕
     智能体 C ←→ 智能体 D

每个智能体： - 具有自主决策能力 - 可以主动向其他智能体发起请求 - 维护本地状态和任务队列 - 遵循共同的通信协议

协作式投资研究示例

场景设计：三个分析师智能体协作完成股票研究

基本面分析师：关注财务数据、估值模型
技术面分析师：关注价格走势、交易信号
宏观分析师：关注政策环境、市场情绪

协作流程： 1. 基本面分析师发现某股票估值偏低，向其他两位发起讨论 2. 技术面分析师检查图表，发现突破信号，表示认同 3. 宏观分析师评估政策环境，提出需关注的风险点 4. 三方协商达成一致：给出谨慎买入建议

优势： - 更强的灵活性和适应性 - 无单点故障风险 - 更接近真实团队协作模式 - 可处理动态变化的任务

挑战： - 需要明确的通信协议和消息格式 - 可能产生协调冲突 - 缺乏集中质量把控 - 调试和监控较为复杂

10.4.3 协作协议与消息格式

智能体间高效通信依赖于标准化的消息格式。

基础消息格式（JSON）

{
  "msg_id": "uuid-v4",
  "sender": "fundamental_analyst",
  "receiver": "portfolio_manager",
  "msg_type": "task_response",
  "timestamp": 1717036800,
  "content": {
    "task": "分析某公司财务数据",
    "status": "completed",
    "result": {
      "revenue_growth": 12.3,
      "roe": 22.5,
      "recommendation": "buy"
    }
  },
  "metadata": {
    "confidence": 0.85,
    "processing_time": 45
  }
}

字段说明： - msg_id：全局唯一标识，用于追踪和去重 - sender/receiver：发送方和接收方智能体 ID - msg_type：消息类型（task_request/task_response/notification/error） - timestamp：时间戳，用于排序和超时判断 - content：消息主体内容，结构根据类型变化 - metadata：元数据，如置信度、处理时间等

10.4.4 状态同步与结果交接

Handoff 机制

Handoff（交接）是智能体间转移控制权的关键机制。一次完整的交接包含：

触发条件：什么情况下交接（任务完成、专业边界、用户请求）
目标智能体：交接给谁
上下文传递：传递哪些信息
状态更新：如何更新系统状态
确认机制：目标智能体是否成功接收

交接时的状态保存

关键是保存足够的上下文让下游智能体继续工作：

基础上下文（始终传递）：
- conversation_history：对话历史
- original_request：原始请求
- timestamp：时间戳

根据目标智能体补充特定信息：
- 如果交接给分析师：附带 financial_data, data_sources
- 如果交接给撰写员：附带 analysis_results, key_findings

教学提示

可以将 Handoff 类比为接力赛跑的交接棒传递：前一位选手必须把接力棒稳稳交到下一位手中，传递过程要有明确的交接区域。智能体的上下文就是接力棒，协议规范就是交接区域。

序号	知识点	重要度
10.4.1	协调者-执行者架构	★★★
10.4.2	对等协作模式	★★
10.4.3	协作协议与消息格式	★★★
10.4.4	状态同步与结果交接	★★

--- title: "10.4 智能体间协作" --- 多智能体系统通过将复杂任务分解为可管理的专门化组件，克服了单智能体的能力局限。协作架构可以分为两大类：中心化协调模式和去中心化对等模式。 ### 10.4.1 协调者-执行者架构这是最常见的多智能体架构。一个中心智能体负责任务分解和调度，多个专门化智能体负责执行子任务。 ![协调者-执行者架构](images/img_03_coordinator_executor.png) **金融研报生成团队示例** - **研究主管（Supervisor）**：负责理解用户需求、分配任务、协调进度、质量把控 - **数据分析师（Data Analyst）**：收集市场数据、计算财务指标、生成图表 - **行业研究员（Industry Researcher）**：分析行业趋势、竞争格局、政策影响 - **报告撰写员（Report Writer）**：整合信息、撰写分析文本、格式化输出当用户请求生成某公司 Q3 财报分析报告时： 1. 研究主管将任务拆解为数据收集、行业分析、报告撰写三个子任务 2. 数据分析师获取财务数据并计算关键指标 3. 行业研究员分析宏观环境和竞争态势 4. 报告撰写员整合两方信息形成结构化报告 5. 研究主管审核并返回最终成果 **优势**： - 控制流程清晰，便于调试和监控 - 任务分配由中心统一决策，避免冲突 - 易于实现质量检查点和人工介入 - 便于审计和复现完整的任务分配日志 **适用场景**： - 任务结构相对固定，可预先定义分解策略 - 需要严格的质量管控和审批流程 - 子任务间依赖关系明确 ### 10.4.2 对等协作模式去中心化架构中，智能体地位平等，可以直接相互通信和协商。没有中央控制者，各智能体通过消息传递和协商机制达成协作。 **工作原理** ```txt 智能体 A ←→ 智能体 B ↕ ╳ ↕ 智能体 C ←→ 智能体 D ``` 每个智能体： - 具有自主决策能力 - 可以主动向其他智能体发起请求 - 维护本地状态和任务队列 - 遵循共同的通信协议 **协作式投资研究示例** 场景设计：三个分析师智能体协作完成股票研究 - **基本面分析师**：关注财务数据、估值模型 - **技术面分析师**：关注价格走势、交易信号 - **宏观分析师**：关注政策环境、市场情绪协作流程： 1. 基本面分析师发现某股票估值偏低，向其他两位发起讨论 2. 技术面分析师检查图表，发现突破信号，表示认同 3. 宏观分析师评估政策环境，提出需关注的风险点 4. 三方协商达成一致：给出谨慎买入建议 **优势**： - 更强的灵活性和适应性 - 无单点故障风险 - 更接近真实团队协作模式 - 可处理动态变化的任务 **挑战**： - 需要明确的通信协议和消息格式 - 可能产生协调冲突 - 缺乏集中质量把控 - 调试和监控较为复杂 ### 10.4.3 协作协议与消息格式智能体间高效通信依赖于标准化的消息格式。 **基础消息格式（JSON）** ```json { "msg_id": "uuid-v4", "sender": "fundamental_analyst", "receiver": "portfolio_manager", "msg_type": "task_response", "timestamp": 1717036800, "content": { "task": "分析某公司财务数据", "status": "completed", "result": { "revenue_growth": 12.3, "roe": 22.5, "recommendation": "buy" } }, "metadata": { "confidence": 0.85, "processing_time": 45 } } ``` **字段说明**： - msg_id：全局唯一标识，用于追踪和去重 - sender/receiver：发送方和接收方智能体 ID - msg_type：消息类型（task_request/task_response/notification/error） - timestamp：时间戳，用于排序和超时判断 - content：消息主体内容，结构根据类型变化 - metadata：元数据，如置信度、处理时间等 ### 10.4.4 状态同步与结果交接 **Handoff 机制** Handoff（交接）是智能体间转移控制权的关键机制。一次完整的交接包含： 1. **触发条件**：什么情况下交接（任务完成、专业边界、用户请求） 2. **目标智能体**：交接给谁 3. **上下文传递**：传递哪些信息 4. **状态更新**：如何更新系统状态 5. **确认机制**：目标智能体是否成功接收 **交接时的状态保存** 关键是保存足够的上下文让下游智能体继续工作： ```txt 基础上下文（始终传递）： - conversation_history：对话历史 - original_request：原始请求 - timestamp：时间戳根据目标智能体补充特定信息： - 如果交接给分析师：附带 financial_data, data_sources - 如果交接给撰写员：附带 analysis_results, key_findings ``` ::: {.callout-tip} ## 教学提示可以将 Handoff 类比为接力赛跑的交接棒传递：前一位选手必须把接力棒稳稳交到下一位手中，传递过程要有明确的交接区域。智能体的上下文就是接力棒，协议规范就是交接区域。 ::: | 序号 | 知识点 | 重要度 | |:----:|--------|:------:| | 10.4.1 | 协调者-执行者架构 | ★★★ | | 10.4.2 | 对等协作模式 | ★★ | | 10.4.3 | 协作协议与消息格式 | ★★★ | | 10.4.4 | 状态同步与结果交接 | ★★ |