AI Day 24
AI Day 24: Agent系统工程化(3)：多Agent协作架构 -- 让AI团队分工合作
多Agent协作架构是让多个专业化AI Agent分工协作完成复杂任务的系统设计方法。单Agent是"全栈工程师"，多Agent是"专业团队"。
2026-04-25
Multi-AgentSupervisorHierarchicalSwarmCrewAIAutoGenLangGraphOrchestrationConflict
日期：2026-04-25
阶段：第二阶段 -- 工程实践 (Day 16-30)
标签：Multi-Agent Supervisor Hierarchical Swarm CrewAI AutoGen LangGraph Orchestration Conflict Resolution
学习路径树
AI/LLM 深度技术学习 50天计划
├── 第一阶段：模型基础 (Day 1-15) ✅
│ ├── Day 1: Transformer架构与LLM基础 ✅
│ ├── Day 2: 模型量化与本地部署 ✅
│ ├── Day 3: 训练过程深度：Pre-training / SFT / RLHF / DPO ✅
│ ├── Day 4: Prompt Engineering与上下文学习(ICL)原理 ✅
│ ├── Day 5: RAG架构：检索增强生成全链路 ✅
│ ├── Day 6: 向量数据库与Embedding模型 ✅
│ ├── Day 7: Fine-tuning实战：LoRA / QLoRA / Adapter ✅
│ ├── Day 8: 推理优化：vLLM / TensorRT-LLM / SGLang ✅
│ ├── Day 9: 长上下文技术：RoPE扩展 / Ring Attention ✅
│ ├── Day 10: 多模态模型：Vision-Language架构 ✅
│ ├── Day 11: Reasoning模型：CoT / o1 / R1 / Extended Thinking ✅
│ ├── Day 12: Agent框架：ReAct / Tool Use / Planning ✅
│ ├── Day 13: MCP协议与Tool生态 ✅
│ ├── Day 14: 模型评估：Benchmark / Arena / 安全评估 ✅
│ └── Day 15: 阶段复习与架构总结 ✅
│
├── 第二阶段：工程实践 (Day 16-30)
│ ├── Day 16: LLM应用架构设计 — API Gateway/路由/缓存 ✅
│ ├── Day 17: LLM安全与Guardrails — 生产环境防护体系 ✅
│ ├── Day 18: LLM可观测性 — 日志/Tracing/指标/告警 ✅
│ ├── Day 19: 生产级RAG(1) — 文档解析与Chunking工程 ✅
│ ├── Day 20: 生产级RAG(2) — Retrieval优化与Reranking ✅
│ ├── Day 21: 生产级RAG(3) — 评估框架与持续迭代 ✅
│ ├── Day 22: Agent系统工程化(1) — 状态管理与错误恢复 ✅
│ ├── Day 23: Agent系统工程化(2) — 成本控制与性能优化 ✅
│ ├── Day 24: Agent系统工程化(3) — 多Agent协作架构 ← 你在这里
│ ├── Day 25: Agent系统工程化(4) — 测试与部署
│ └── Day 26-30: 多模型编排/部署策略/端到端项目
│
├── 第三阶段：金融零售AI应用 (Day 31-42)
│ ├── Day 31-35: 金融AI（风控模型/智能投顾/合规/反欺诈）
│ ├── Day 36-40: 零售AI（推荐系统/智能客服/供应链预测/营销）
│ └── Day 41-42: CeFi x DeFi x AI融合架构
│
└── 第四阶段：面试冲刺 (Day 43-50)
├── Day 43-46: 系统设计面试（LLM平台/RAG/Agent/推荐）
├── Day 47-49: 产品/架构面试模拟
└── Day 50: 总结与作品集
核心概念
多Agent协作架构是让多个专业化AI Agent分工协作完成复杂任务的系统设计方法。单Agent是"全栈工程师"，多Agent是"专业团队"。
金融类比：多Agent = 投行项目团队
投行IPO项目团队: 多Agent系统:
├── 项目总监(Supervisor) ├── Supervisor Agent(分发/汇总)
│ └── 分配任务、协调、最终拍板 │
├── 行业分析师(Researcher) ├── Research Agent(搜索/整理)
├── 财务分析师(Analyst) ├── Analyst Agent(分析/推理)
├── 风控合规(Risk & Compliance) ├── Risk Agent(规则检查/评分)
├── 客户经理(Client Facing) ├── Writer Agent(报告/输出)
│ │
└── 协作: 晨会/邮件/会议室/项目经理 └── 共享内存/消息传递/仲裁/编排
为什么不用一个"全能分析师":
├── 专注: 每个Agent的Prompt更短更精准
├── 并行: 多Agent同时工作缩短总时间
├── 可维护: 改一个Agent不影响其他
└── 可审计: 每个Agent输出独立可追溯
何时从单Agent升级到多Agent
单Agent: 任务简单(问答/翻译)、延迟敏感、成本敏感
多Agent: 多专业领域、需要对抗性检查、可并行分解、单Agent Prompt>4000 tokens
经验法则: 一个人5分钟能完成→单Agent; 需要"开会讨论"→多Agent
多Agent架构模式
模式1: Supervisor(主管模式) -- 最常用
┌──────────────┐
│ Supervisor │ 任务分发/结果汇总
└──────┬───────┘
┌───────────┼───────────┐
▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────┐
│Worker A │ │Worker B │ │Worker C │
│ 研究 │ │ 分析 │ │ 写作 │
└─────────┘ └─────────┘ └─────────┘
流程: 用户→Supervisor分发→Worker执行→Supervisor汇总→输出
优点: 中心控制,流程清晰 缺点: Supervisor是单点
适用: 80%的通用场景
模式2: Hierarchical(层级模式)
┌──────────┐
│ Director │ 总指挥
└────┬─────┘
┌─────────┴─────────┐
▼ ▼
┌──────────┐ ┌──────────┐
│Manager A │ │Manager B │
│ 研究部 │ │ 合规部 │
└────┬─────┘ └────┬─────┘
┌───┼───┐ ┌───┼───┐
▼ ▼ ▼ ▼ ▼ ▼
W1 W2 W3 W4 W5 W6
适用: 极复杂任务(IPO尽调: 财务/法律/业务三大模块)
缺点: 层级多→延迟高→成本高
模式3: Peer-to-Peer(对等模式)
┌─────────┐ ┌─────────┐
│ Agent A │◄───────►│ Agent B │
└────┬────┘ └────┬────┘
│ ┌─────────┐ │
└──►│ Agent C │◄───┘
└─────────┘
Agent之间直接通信,无中心指挥
适用: 辩论式分析(看多Agent vs 看空Agent)
缺点: 易陷入无限对话,Debug困难
模式4: Swarm(群体智能)
┌───┐ ┌───┐ ┌───┐ ┌───┐ ┌───┐
│ A │ │ A │ │ A │ │ A │ │ A │ 多个同质Agent独立工作
└─┬─┘ └─┬─┘ └─┬─┘ └─┬─┘ └─┬─┘
└──────┴──────┴──────┴──────┘
▼ 共享环境 ▼
┌───────────┐
│Aggregator │ 投票/合并
└───────────┘
适用: 多视角验证、大规模并行处理
优点: 容错强(单个失败不影响) 缺点: N倍成本
模式5: Sequential Pipeline(流水线)
┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐
│Agent A │──►│Agent B │──►│Agent C │──►│Agent D │
│数据收集 │ │数据分析 │ │报告生成 │ │合规审核 │
└────────┘ └────────┘ └────────┘ └────────┘
适用: 流程固定、步骤间输入输出明确(贷款审批流水线)
优点: 简单清晰 缺点: 串行延迟高
模式选择速查
┌─────────────┬──────────┬────────┬──────────────┐
│ 模式 │ 延迟 │ 复杂度 │ 推荐场景 │
├─────────────┼──────────┼────────┼──────────────┤
│ Supervisor │ 中 │ 低 │ 通用首选 │
│ Hierarchical│ 高 │ 高 │ 超大任务 │
│ Peer-to-Peer│ 不确定 │ 高 │ 辩论/创意 │
│ Swarm │ 低(并行) │ 中 │ 验证/批量 │
│ Sequential │ 高(串行) │ 低 │ 固定SOP流程 │
└─────────────┴──────────┴────────┴──────────────┘
通信与协调
四种Agent间通信方式
1. 消息传递(Message Passing)
Agent A ──msg──► Agent B (显式、松耦合、可审计)
实现: Redis队列/HTTP/函数调用
2. 共享内存(Shared State)
所有Agent读写同一个State对象
LangGraph StateGraph就是这种模式
风险: 并发写入冲突、状态膨胀
3. 黑板系统(Blackboard)
共享内存+Controller(管控谁可读写哪个区域)
适合复杂协作但设计成本高
4. 事件驱动(Event-Driven)
Agent A发布事件 → 订阅者Agent响应
极度松耦合、天然并行, 但调试困难
Agent接口设计原则
1. 标准化输入输出: 每个Agent有明确的input_schema/output_schema
2. 幂等性: 同一消息发两次结果相同(Day 22核心)
3. 超时设置: Agent A调Agent B必须设timeout
4. 版本兼容: 输出格式变化时向后兼容
5. 全链路Tracing: 每次通信记录who→who/when/what/latency(Day 18)
2025-2026框架对比
┌──────────────┬────────────┬─────────────┬──────────────┬──────────────┐
│ 框架 │ 开发者 │ 核心模式 │ 优势 │ 适用 │
├──────────────┼────────────┼─────────────┼──────────────┼──────────────┤
│ CrewAI │ 社区 │ 角色+任务 │ 10分钟上手 │ 快速原型 │
│ AutoGen AG2 │ Microsoft │ 对话驱动 │ 自然对话协作 │ 研究/辩论 │
│ LangGraph │ LangChain │ StateGraph │ 精确流程控制 │ 生产级编排 │
│ OpenAI Swarm │ OpenAI │ Handoff │ 极简API │ 轻量路由 │
│ Anthropic │ Anthropic │ Orchestrator│ Claude原生 │ Claude生态 │
└──────────────┴────────────┴─────────────┴──────────────┴──────────────┘
选型决策:
├── 快速原型/Demo → CrewAI
├── 研究/辩论/多视角 → AutoGen AG2
├── 生产级/合规审计 → LangGraph (Checkpoint/持久化/HITL)
├── 简单客服路由 → OpenAI Swarm
└── Claude + MCP深度用户 → Anthropic Multi-Agent
实际建议: CrewAI验证idea(1天) → LangGraph重构上线(1周)
Agent编排：LangGraph StateGraph示例
from langgraph.graph import StateGraph, END
from typing import TypedDict, List, Literal
# 1. 共享状态
class ResearchState(TypedDict):
query: str
research_data: dict # Researcher输出
analysis: dict # Analyst输出
risk_assessment: dict # Risk输出
draft_report: str # Writer输出
review_comments: List[str]
iteration: int
# 2. Agent节点(省略内部实现)
def research_node(state): ... # 收集数据
def analysis_node(state): ... # 数据分析
def risk_node(state): ... # 风险评估
def writer_node(state): ... # 生成报告
def review_node(state): ... # 质量审核
# 3. 条件路由
def route_after_review(state) -> Literal["writer", "end"]:
if state["iteration"] >= 3: return "end" # 防无限循环
if all("PASS" in c for c in state["review_comments"]): return "end"
return "writer" # 退回修改
# 4. 构建图
graph = StateGraph(ResearchState)
graph.add_node("research", research_node)
graph.add_node("analysis", analysis_node)
graph.add_node("risk", risk_node)
graph.add_node("writer", writer_node)
graph.add_node("review", review_node)
graph.set_entry_point("research")
graph.add_edge("research", "analysis")
graph.add_edge("research", "risk") # 并行分支
graph.add_edge("analysis", "writer")
graph.add_edge("risk", "writer") # 汇聚
graph.add_edge("writer", "review")
graph.add_conditional_edges("review", route_after_review,
{"writer": "writer", "end": END}) # 审核-修改循环
app = graph.compile(checkpointer=PostgresSaver(...))
执行流程
用户: "分析ETH投资前景"
┌──────────┐
│ research │ 收集数据(~15s)
└────┬─────┘
├─────────────┐ ← 并行
▼ ▼
┌─────────┐ ┌─────────┐
│analysis │ │ risk │ (~10s, 并行后max=10s)
└────┬────┘ └────┬────┘
└──────┬─────┘ ← 汇聚
▼
┌──────────┐
│ writer │ (~20s)
└────┬─────┘
▼
┌──────────┐
│ review │ PASS?→输出 / NO?→退回writer(max 3轮)
└──────────┘
总耗时: ~45s(串行要~65s, 并行省30%)
冲突解决
多Agent意见不一致时的五种策略
策略1: 多数投票(Majority Vote)
3个Agent: 买入/买入/卖出 → 2:1→买入
适用: 主观判断、非关键决策
策略2: 加权投票(Weighted Vote)
Risk Agent(权重3)*0.9=2.7 vs Research(权重2)*0.7=1.4
按专业度/置信度加权
适用: 有明确专业分工
策略3: 仲裁Agent(Arbiter)
冲突双方→Arbiter综合分析→裁决
适用: 需要解释"为什么选这个"
策略4: 人工升级(Human Escalation)
合规/法律判断、金额超阈值、置信度都低 → 人工
适用: 高风险决策
策略5: 保守默认(Conservative Default)
买入vs卖出→观望, 上线vs不上线→不上线, 放行vs拦截→拦截
适用: 金融合规(宁严勿松)
金融合规场景: 一票否决制
大额跨境转账多Agent评估:
AML Agent: PASS | Fraud Agent: WARN | Sanctions Agent: PASS
▼
Decision Engine:
├── 全PASS → 自动放行
├── 任一BLOCK → 自动拦截
├── 有WARN无BLOCK → 人工审核
└── Agent超时 → 默认拦截
→ 金融合规核心: 一票否决 + 宁严勿松
→ 法务说不行，业务再想做也不能做
实战案例: 金融研究多Agent
输入: "分析Ethena Protocol投资价值"
Agent角色:
Researcher → 协议概述/团队/融资(GPT-4o,联网搜索)
Data Analyst → TVL/用户/收入趋势(Claude Sonnet,Dune API)
Tokenomics → ENA分配/解锁/效用(Claude Sonnet,CoinGecko API)
Risk Assessor → 技术/市场/监管风险(Claude Opus,有否决权)
Report Writer → 综合报告(Claude Opus,长文写作)
流程: Researcher+Data+Tokenomics并行 → Risk评估 → Writer撰写
如果Risk发现RED FLAG → 直接输出警告(跳过写报告)
Writer完成后 → Supervisor质量检查 → 不通过退回(max 2轮)
成本: 5个Agent合计 ~10K input + ~5K output ≈ $0.05/次
今日思考
1. 多Agent的Conway定律
设计多Agent时先想: 真人团队怎么分工? 谁先做谁后做? 然后直接映射。投行研究→估值→法务→报告是Pipeline; 交易室多交易员→主管拍板是Supervisor; 合规多维度检查→一票否决是Swarm+Conservative。10年金融团队协作经验可以直接迁移到Agent架构设计。
2. "少即是多" -- Agent数量控制
把每个小功能都做成Agent是常见错误(6个Agent每个只做一件小事,通信开销巨大)。判断标准: 这个Agent独立运行能产出有价值的结果吗? 3-5个Agent是甜蜜点,超过7个要警惕。这就是"两个披萨"原则在Agent世界的体现。
3. 可观测性是多Agent的生命线
单Agent看日志就行。多Agent: 哪个Agent出错? 谁传了错数据? Supervisor为什么选错了? 必须有Agent级Tracing + 通信Tracing + 决策Tracing。金融合规更是硬要求: "为什么建议客户买ETH?" 需要能还原整个协作过程。
面试题
Q1: 什么时候用多Agent? 主要风险? 信号: 多专业领域/对抗性检查/可并行/Prompt过长/需不同模型。风险: 成本N倍、延迟增加、错误传播、无限循环、调试O(N)。缓解: max_iterations + token budget + 全链路Tracing + 升级路径。
Q2: 如何设计金融合规的多Agent系统确保审计可追溯? 每个Agent决策有reasoning字段; 通信全部持久化; 冲突解决过程记录; 合规Agent一票否决; 人工审批节点hardcoded不可跳过; LangGraph+PostgreSQL持久化所有state transition; 审计日志immutable。
Q3: CrewAI vs LangGraph选型? CrewAI: 快速原型/内容生成/团队AI经验浅/流程固定。LangGraph: 生产级/复杂流程控制/金融合规/已有LangChain生态。建议: CrewAI验证idea(1天)→LangGraph重构(1周)。
资源推荐
| 资源 | 说明 | 链接 |
|---|---|---|
| LangGraph Multi-Agent | 官方多Agent教程 | langchain-ai.github.io/langgraph |
| CrewAI文档 | 最易上手的多Agent框架 | docs.crewai.com |
| AutoGen AG2 | 微软新版Agent框架 | github.com/ag2ai/ag2 |
| OpenAI Swarm | 极简多Agent参考实现 | github.com/openai/swarm |
| Andrew Ng Multi-Agent | 多Agent设计模式解析 | deeplearning.ai/the-batch |
明日预告
Day 25: Agent系统工程化(4) -- 测试与部署
预习问题:
1. 如何测试非确定性的LLM Agent? 传统单元测试还适用吗?
2. Agent的CI/CD pipeline和传统应用有什么不同?
3. 如何做Agent A/B测试，衡量"哪个版本更好"?
连接点:
Day 22: 可靠性(状态/错误) → Day 23: 经济性(成本/性能)
Day 24(今天): 协作性(多Agent/通信/冲突)
Day 25(明天): 可交付性(测试/部署/发布)
→ 四天 = Agent系统工程化完整闭环