10d - Agent 通信模式
本文是《AI Agent 实战手册》第 10 章第 4 节。 上一节:10c-A2A协议详解 | 下一节:10e-多Agent实战案例
概述
当多个 Agent 需要协作完成复杂任务时,它们之间如何传递信息、分配工作、汇总结果,决定了整个系统的效率和可靠性。本节系统讲解五种核心 Agent 通信模式——顺序交接、并行扇出/扇入、层级委托、共识投票、辩论/对抗——每种模式配有架构图示、适用场景、代码示例和优劣分析,帮助你根据实际需求选择最合适的协作架构。
1. 顺序交接(Sequential Handoff)
概念说明
顺序交接是最直观的通信模式,类似于工厂流水线:Agent A 完成任务后将结果传递给 Agent B,Agent B 处理后再传递给 Agent C,依此类推。每个 Agent 只需关注自己的专业领域,通过共享状态完成接力。
OpenAI Swarm 框架将这一模式作为核心设计理念——Agent 通过 handoff 函数将控制权和对话历史传递给下一个 Agent,接收方根据自身的系统提示和工具集推断上下文并继续执行。
架构图示
┌─────────┐ 状态传递 ┌─────────┐ 状态传递 ┌─────────┐
│ Agent A │──────────────▶│ Agent B │──────────────▶│ Agent C │
│ (采集) │ │ (分析) │ │ (生成) │
└─────────┘ └─────────┘ └─────────┘
│ │ │
▼ ▼ ▼
┌─────────────────────────────────────────────────────────────┐
│ 共享状态存储 │
│ (对话历史 / 中间结果 / 元数据) │
└─────────────────────────────────────────────────────────────┘适用场景
- 流程步骤有明确的先后依赖关系(如:数据采集 → 清洗 → 分析 → 报告)
- 每个步骤的输入严格依赖上一步的输出
- 客服工单流转(分类 → 处理 → 回复 → 归档)
- 内容生产管线(调研 → 撰写 → 审校 → 发布)
代码示例(LangGraph)
from langgraph.graph import StateGraph, END
from typing import TypedDict
class PipelineState(TypedDict):
raw_data: str
cleaned_data: str
analysis: str
report: str
def collect_agent(state: PipelineState) -> PipelineState:
"""Agent A:数据采集"""
# 调用 LLM 或工具采集原始数据
return {**state, "raw_data": "采集到的原始数据..."}
def clean_agent(state: PipelineState) -> PipelineState:
"""Agent B:数据清洗"""
return {**state, "cleaned_data": f"清洗后: {state['raw_data']}"}
def analyze_agent(state: PipelineState) -> PipelineState:
"""Agent C:数据分析"""
return {**state, "analysis": f"分析结果: {state['cleaned_data']}"}
def report_agent(state: PipelineState) -> PipelineState:
"""Agent D:报告生成"""
return {**state, "report": f"最终报告: {state['analysis']}"}
# 构建顺序图
graph = StateGraph(PipelineState)
graph.add_node("collect", collect_agent)
graph.add_node("clean", clean_agent)
graph.add_node("analyze", analyze_agent)
graph.add_node("report", report_agent)
graph.set_entry_point("collect")
graph.add_edge("collect", "clean")
graph.add_edge("clean", "analyze")
graph.add_edge("analyze", "report")
graph.add_edge("report", END)
pipeline = graph.compile()
result = pipeline.invoke({"raw_data": "", "cleaned_data": "", "analysis": "", "report": ""})优缺点
| 维度 | 说明 |
|---|---|
| ✅ 简单可预测 | 执行路径固定,易于调试和监控 |
| ✅ 职责清晰 | 每个 Agent 专注单一任务,提示词精准 |
| ✅ 状态可追溯 | 每步的输入输出都有记录 |
| ❌ 延迟累积 | 总耗时 = 所有步骤耗时之和,无法并行 |
| ❌ 单点故障 | 任一 Agent 失败会阻塞整条链路 |
| ❌ 灵活性低 | 难以处理需要回退或跳步的场景 |
2. 并行扇出/扇入(Fan-out / Fan-in)
概念说明
扇出/扇入模式将一个复杂任务拆分为多个独立子任务,同时分发给多个专业化 Agent 并行处理(扇出),然后由一个聚合 Agent 收集所有结果并合并为最终输出(扇入)。这是缩短端到端延迟的最有效模式——总耗时取决于最慢的子任务,而非所有子任务之和。
OpenAI Agents SDK 的 Cookbook 中专门介绍了这一模式:通过同时派发多个专业 Agent,再由一个”元 Agent”汇总输出,可以将延迟降低 50-70%。
架构图示
┌──────────────┐
│ 分发器 │
│ (Dispatcher) │
└──────┬───────┘
┌───────────┼───────────┐
▼ ▼ ▼
┌──────────┐┌──────────┐┌──────────┐
│ Agent A ││ Agent B ││ Agent C │
│ (竞品) ││ (用户) ││ (趋势) │
└────┬─────┘└────┬─────┘└────┬─────┘
│ │ │
▼ ▼ ▼
┌─────────────────────────────────┐
│ 聚合器 │
│ (Aggregator Agent) │
│ 合并 + 去重 + 综合分析 │
└─────────────────────────────────┘
│
▼
┌──────────────┐
│ 最终报告 │
└──────────────┘适用场景
- 子任务之间相互独立,无数据依赖(如:多维度市场调研)
- 需要多角度分析同一问题(如:安全审计的不同检查项)
- 批量处理同类任务(如:同时分析多份简历)
- 对延迟敏感的实时系统
代码示例(OpenAI Agents SDK)
import asyncio
from agents import Agent, Runner
# 定义专业化子 Agent
competitor_agent = Agent(
name="竞品分析师",
instructions="你是竞品分析专家。分析给定行业的主要竞争对手,输出结构化报告。"
)
user_research_agent = Agent(
name="用户研究员",
instructions="你是用户研究专家。分析目标用户群体的需求、痛点和行为模式。"
)
trend_agent = Agent(
name="趋势分析师",
instructions="你是市场趋势专家。分析行业发展趋势和技术演进方向。"
)
# 聚合 Agent
synthesizer = Agent(
name="综合分析师",
instructions="""你是市场综合分析师。
根据竞品分析、用户研究和趋势分析的结果,生成一份综合市场报告。
要求:去除重复信息,识别交叉洞察,给出可执行建议。"""
)
async def fan_out_fan_in(query: str):
"""并行扇出 → 聚合扇入"""
# 扇出:并行执行三个子任务
results = await asyncio.gather(
Runner.run(competitor_agent, query),
Runner.run(user_research_agent, query),
Runner.run(trend_agent, query),
)
# 扇入:聚合所有结果
combined_input = f"""
## 竞品分析结果
{results[0].final_output}
## 用户研究结果
{results[1].final_output}
## 趋势分析结果
{results[2].final_output}
请综合以上三份报告,生成最终市场分析。
"""
final = await Runner.run(synthesizer, combined_input)
return final.final_output
# 执行
report = asyncio.run(fan_out_fan_in("分析 2026 年 AI 编码助手市场"))优缺点
| 维度 | 说明 |
|---|---|
| ✅ 大幅降低延迟 | 总耗时 ≈ 最慢子任务耗时,而非总和 |
| ✅ 多角度覆盖 | 不同专业 Agent 提供互补视角 |
| ✅ 易于扩展 | 新增分析维度只需添加一个子 Agent |
| ❌ 聚合复杂度 | 合并多源结果需要精心设计聚合逻辑 |
| ❌ 资源消耗高 | 并行调用多个 LLM,token 成本成倍增加 |
| ❌ 一致性挑战 | 不同 Agent 可能产生矛盾结论,需要冲突解决机制 |
3. 层级委托(Hierarchical Delegation)
概念说明
层级委托模式模拟企业组织架构:一个顶层”主管 Agent”接收复杂任务,将其分解为子任务,委托给中层”经理 Agent”,经理再进一步分解并委托给底层”执行 Agent”。每一层只需关注自己的管理范围,通过逐级汇报完成信息聚合。
这种模式特别适合处理大规模、多层次的复杂任务——就像一个 CTO 不会直接写代码,而是将需求分解给技术总监,再由总监分配给各团队 lead,最终由开发者执行。
架构图示
┌─────────────────────┐
│ 总监 Agent │
│ (Director/CEO) │
│ 任务分解 + 最终汇总 │
└──────────┬──────────┘
┌─────────────┼─────────────┐
▼ ▼ ▼
┌────────────┐┌────────────┐┌────────────┐
│ 经理 A ││ 经理 B ││ 经理 C │
│ (前端组) ││ (后端组) ││ (测试组) │
└──────┬─────┘└──────┬─────┘└──────┬─────┘
┌────┴────┐ ┌────┴────┐ ┌────┴────┐
▼ ▼ ▼ ▼ ▼ ▼
┌──────┐ ┌──────┐┌──────┐┌──────┐┌──────┐┌──────┐
│执行者││执行者 ││执行者││执行者 ││执行者││执行者 │
│ UI ││ 样式 ││ API ││ DB ││ 单元 ││ E2E │
└──────┘ └──────┘└──────┘└──────┘└──────┘└──────┘
─────────────────────────────────────────────────
信息流:任务自上而下分解,结果自下而上汇报适用场景
- 大型项目需要多层次分解(如:全栈应用开发)
- 不同子系统需要不同的管理策略
- 需要在不同抽象层级做决策(战略层 vs 执行层)
- 企业级工作流自动化(审计、合规检查)
代码示例(CrewAI)
from crewai import Agent, Task, Crew, Process
# 顶层:项目总监
director = Agent(
role="项目总监",
goal="协调前端、后端、测试团队完成产品开发",
backstory="你是一位经验丰富的技术总监,擅长任务分解和团队协调。",
allow_delegation=True
)
# 中层:团队经理
frontend_lead = Agent(
role="前端负责人",
goal="负责所有前端开发任务的分配和质量把控",
backstory="你是资深前端架构师,精通 React 和设计系统。",
allow_delegation=True
)
backend_lead = Agent(
role="后端负责人",
goal="负责 API 设计、数据库和服务端逻辑",
backstory="你是后端架构师,精通微服务和数据库优化。",
allow_delegation=True
)
qa_lead = Agent(
role="测试负责人",
goal="制定测试策略并确保产品质量",
backstory="你是 QA 专家,精通自动化测试和质量保证。",
allow_delegation=True
)
# 定义层级任务
planning_task = Task(
description="分析产品需求,制定开发计划,分配给各团队负责人",
agent=director,
expected_output="包含前端、后端、测试三个模块的详细开发计划"
)
frontend_task = Task(
description="根据开发计划完成前端组件开发",
agent=frontend_lead,
expected_output="前端组件代码和文档"
)
backend_task = Task(
description="根据开发计划完成 API 和数据库开发",
agent=backend_lead,
expected_output="API 接口和数据库 schema"
)
qa_task = Task(
description="根据开发计划制定并执行测试方案",
agent=qa_lead,
expected_output="测试报告和质量评估"
)
# 使用层级流程
crew = Crew(
agents=[director, frontend_lead, backend_lead, qa_lead],
tasks=[planning_task, frontend_task, backend_task, qa_task],
process=Process.hierarchical, # 关键:启用层级委托
manager_agent=director
)
result = crew.kickoff()优缺点
| 维度 | 说明 |
|---|---|
| ✅ 可扩展性强 | 通过增加层级和节点轻松扩展系统规模 |
| ✅ 关注点分离 | 每层只需关注自己的抽象级别 |
| ✅ 符合直觉 | 映射真实组织架构,易于理解和设计 |
| ❌ 通信开销 | 多层传递增加延迟和信息损耗 |
| ❌ 瓶颈风险 | 上层 Agent 可能成为性能瓶颈 |
| ❌ 调试困难 | 多层嵌套时问题定位复杂 |
4. 共识投票(Consensus Voting)
概念说明
共识投票模式让多个 Agent 独立处理同一个问题,然后通过投票机制选出最佳答案。这种模式的核心价值在于交叉验证——单个 LLM 可能产生幻觉或偏差,但多个独立 Agent 同时犯同样错误的概率远低于单个 Agent。
研究表明,投票协议在推理任务上可提升约 13.2% 的性能,而共识协议在知识任务上可提升约 2.8% 的性能。增加 Agent 数量通常能提升表现,但过多的讨论轮次反而可能降低投票效果。
架构图示
┌──────────────────┐
│ 同一问题输入 │
└────────┬─────────┘
┌─────────────┼─────────────┐
▼ ▼ ▼
┌────────────┐┌────────────┐┌────────────┐
│ Agent A ││ Agent B ││ Agent C │
│ (视角 1) ││ (视角 2) ││ (视角 3) │
│ ││ ││ │
│ 独立推理 ││ 独立推理 ││ 独立推理 │
│ 生成答案 ││ 生成答案 ││ 生成答案 │
└──────┬─────┘└──────┬─────┘└──────┬─────┘
│ │ │
▼ ▼ ▼
┌─────────────────────────────────────────┐
│ 投票 / 评分机制 │
│ │
│ 策略 1: 多数投票 (Majority Vote) │
│ 策略 2: 加权投票 (Weighted Vote) │
│ 策略 3: 排名聚合 (Rank Aggregation) │
│ 策略 4: 裁判 Agent (Judge Agent) │
└─────────────────────┬───────────────────┘
▼
┌──────────────────┐
│ 最终共识结果 │
└──────────────────┘适用场景
- 高风险决策需要多重验证(如:医疗诊断辅助、金融风控)
- 需要降低 LLM 幻觉率的关键场景
- 代码审查(多个 Agent 从不同角度审查同一段代码)
- 内容审核(多个 Agent 独立判断内容是否合规)
代码示例(Python 通用实现)
import asyncio
from dataclasses import dataclass
from collections import Counter
@dataclass
class VoteResult:
agent_name: str
answer: str
confidence: float
reasoning: str
async def agent_vote(agent_name: str, prompt: str, perspective: str) -> VoteResult:
"""单个 Agent 独立投票"""
system_prompt = f"你是{perspective}。请独立分析以下问题,给出你的判断。"
# 调用 LLM API
response = await call_llm(system_prompt, prompt)
return VoteResult(
agent_name=agent_name,
answer=response["answer"],
confidence=response["confidence"],
reasoning=response["reasoning"]
)
async def consensus_vote(question: str) -> dict:
"""共识投票主流程"""
# 扇出:多个 Agent 独立投票
votes = await asyncio.gather(
agent_vote("安全专家", question, "资深安全工程师,关注漏洞和攻击面"),
agent_vote("架构师", question, "系统架构师,关注可扩展性和性能"),
agent_vote("业务分析师", question, "业务分析师,关注用户需求和商业价值"),
)
# 策略 1:简单多数投票
answer_counts = Counter(v.answer for v in votes)
majority_answer = answer_counts.most_common(1)[0][0]
# 策略 2:加权投票(按置信度加权)
weighted_scores = {}
for v in votes:
weighted_scores[v.answer] = weighted_scores.get(v.answer, 0) + v.confidence
weighted_answer = max(weighted_scores, key=weighted_scores.get)
return {
"majority_vote": majority_answer,
"weighted_vote": weighted_answer,
"individual_votes": [
{"agent": v.agent_name, "answer": v.answer,
"confidence": v.confidence, "reasoning": v.reasoning}
for v in votes
],
"consensus_reached": len(set(v.answer for v in votes)) == 1
}投票策略对比
| 策略 | 原理 | 适用场景 | 复杂度 |
|---|---|---|---|
| 多数投票 | 选择出现次数最多的答案 | 分类任务、是/否判断 | 低 |
| 加权投票 | 按 Agent 置信度或历史准确率加权 | 专业领域决策 | 中 |
| 排名聚合 | 综合多个 Agent 的排名偏好 | 推荐排序、优先级决策 | 中 |
| 裁判 Agent | 由专门的裁判 Agent 评估所有答案 | 开放式问题、创意任务 | 高 |
优缺点
| 维度 | 说明 |
|---|---|
| ✅ 降低幻觉率 | 多重独立验证大幅减少错误 |
| ✅ 提升可靠性 | 单个 Agent 失败不影响最终结果 |
| ✅ 可解释性强 | 每个 Agent 的推理过程都有记录 |
| ❌ 成本高昂 | 同一问题需要多次 LLM 调用 |
| ❌ 速度受限 | 需要等待所有 Agent 完成才能投票 |
| ❌ 群体思维风险 | 如果 Agent 使用相同模型,可能产生相似偏差 |
5. 辩论/对抗(Debate / Adversarial)
概念说明
辩论/对抗模式是最具创新性的通信模式:多个 Agent 被分配对立立场,通过结构化辩论来暴露盲点、挑战偏见,最终由裁判 Agent 或通过收敛机制得出更高质量的结论。
与共识投票不同,辩论模式刻意制造分歧——Agent 不是独立给出答案,而是互相质疑、反驳、迭代改进。三菱电机研发的 DebateNet 系统证明,通过让 Agent 假设对立观点并互相暴露盲点,可以迭代优化答案直到达成高置信度共识。
核心流程是”辩论-反思”循环:(1) Agent 提出并捍卫各自立场;(2) 通过反馈或自我批评进行反思修正;(3) 在门控或共识标准下重复迭代,直到收敛。
架构图示
┌──────────────────┐
│ 辩题 / 问题 │
└────────┬─────────┘
│
┌────────▼─────────┐
│ 主持人 Agent │
│ (Moderator) │
│ 设定规则+判定 │
└────────┬─────────┘
│
┌──────────────┼──────────────┐
▼ ▼
┌─────────────┐ ┌─────────────┐
│ 正方 Agent │◄────辩论────▶│ 反方 Agent │
│ (Proponent) │ 第 1 轮 │ (Opponent) │
└──────┬──────┘ └──────┬──────┘
│ │
▼ ▼
┌─────────────┐ ┌─────────────┐
│ 反思 & 修正 │ │ 反思 & 修正 │
└──────┬──────┘ └──────┬──────┘
│ │
▼ ▼
┌─────────────┐ ┌─────────────┐
│ 正方 Agent │◄────辩论────▶│ 反方 Agent │
│ (更新论点) │ 第 2 轮 │ (更新论点) │
└──────┬──────┘ └──────┬──────┘
│ │
└──────────────┬─────────────┘
▼
┌──────────────────┐
│ 裁判 Agent │
│ 综合评估 + 裁决 │
└──────────────────┘
│
▼
┌──────────────────┐
│ 最终结论 │
│ (附完整辩论记录) │
└──────────────────┘适用场景
- 技术方案选型(如:微服务 vs 单体架构)
- 风险评估需要”魔鬼代言人”视角
- 代码审查中发现深层问题
- 策略制定需要考虑正反两面
- 学术论文评审和事实核查
代码示例(LangGraph 辩论循环)
from langgraph.graph import StateGraph, END
from typing import TypedDict, List
class DebateState(TypedDict):
topic: str
round: int
max_rounds: int
proponent_args: List[str]
opponent_args: List[str]
moderator_notes: List[str]
final_verdict: str
def proponent_argue(state: DebateState) -> DebateState:
"""正方 Agent:提出或强化论点"""
context = f"""
辩题:{state['topic']}
当前第 {state['round']} 轮。
反方上轮论点:{state['opponent_args'][-1] if state['opponent_args'] else '无'}
请提出你的论点,回应反方质疑,强化你的立场。
"""
# 调用 LLM
argument = call_llm("你是正方辩手,坚定支持该方案。", context)
return {
**state,
"proponent_args": state["proponent_args"] + [argument]
}
def opponent_argue(state: DebateState) -> DebateState:
"""反方 Agent:质疑和反驳"""
context = f"""
辩题:{state['topic']}
当前第 {state['round']} 轮。
正方本轮论点:{state['proponent_args'][-1]}
请质疑正方论点中的薄弱环节,提出反面论据。
"""
argument = call_llm("你是反方辩手,坚定反对该方案。寻找漏洞和风险。", context)
return {
**state,
"opponent_args": state["opponent_args"] + [argument]
}
def moderator_evaluate(state: DebateState) -> DebateState:
"""主持人:评估是否继续辩论"""
return {**state, "round": state["round"] + 1}
def should_continue(state: DebateState) -> str:
"""判断是否继续辩论"""
if state["round"] >= state["max_rounds"]:
return "judge"
return "proponent"
def judge_verdict(state: DebateState) -> DebateState:
"""裁判 Agent:综合评估并裁决"""
all_arguments = ""
for i in range(len(state["proponent_args"])):
all_arguments += f"\n--- 第 {i+1} 轮 ---\n"
all_arguments += f"正方:{state['proponent_args'][i]}\n"
if i < len(state["opponent_args"]):
all_arguments += f"反方:{state['opponent_args'][i]}\n"
verdict = call_llm(
"你是公正的裁判。综合正反双方论点,给出最终裁决和建议。",
f"辩题:{state['topic']}\n\n辩论记录:{all_arguments}"
)
return {**state, "final_verdict": verdict}
# 构建辩论图
graph = StateGraph(DebateState)
graph.add_node("proponent", proponent_argue)
graph.add_node("opponent", opponent_argue)
graph.add_node("moderator", moderator_evaluate)
graph.add_node("judge", judge_verdict)
graph.set_entry_point("proponent")
graph.add_edge("proponent", "opponent")
graph.add_edge("opponent", "moderator")
graph.add_conditional_edges("moderator", should_continue)
graph.add_edge("judge", END)
debate = graph.compile()
result = debate.invoke({
"topic": "是否应该将单体应用拆分为微服务架构?",
"round": 0, "max_rounds": 3,
"proponent_args": [], "opponent_args": [],
"moderator_notes": [], "final_verdict": ""
})辩论模式变体
| 变体 | 机制 | 适用场景 |
|---|---|---|
| 经典对抗 | 正方 vs 反方 + 裁判 | 二选一决策 |
| 多方辩论 | 3+ 个 Agent 各持不同立场 | 多方案比选 |
| 辩论-反思循环 | 辩论后各方自我反思再辩论 | 需要深度分析的复杂问题 |
| 红队/蓝队 | 攻击方 vs 防御方 | 安全审计、漏洞发现 |
| AI 委员会 | 多专家圆桌讨论 + 投票 | 综合性战略决策 |
优缺点
| 维度 | 说明 |
|---|---|
| ✅ 暴露盲点 | 对抗性质疑能发现单一视角遗漏的问题 |
| ✅ 降低偏见 | 强制考虑反面论据,减少确认偏误 |
| ✅ 决策质量高 | 经过多轮辩论的结论更加全面和稳健 |
| ❌ 耗时最长 | 多轮辩论需要大量 LLM 调用 |
| ❌ 收敛困难 | 可能陷入无限循环,需要设置终止条件 |
| ❌ 设计复杂 | 需要精心设计角色、规则和评判标准 |
工具推荐
| 工具 | 用途 | 价格 | 适用通信模式 |
|---|---|---|---|
| LangGraph | 基于状态图的 Agent 编排,精细控制流程 | 免费(开源),LangSmith 付费 $39/月起 | 顺序交接、扇出/扇入、辩论 |
| CrewAI | 基于角色的团队协作框架 | 免费(开源),Enterprise 版按需定价 | 层级委托、顺序交接 |
| AutoGen | 基于对话的多 Agent 协作 | 免费(开源) | 辩论/对抗、共识投票 |
| OpenAI Agents SDK | 轻量级 Agent 编排,内置 handoff | 免费(开源),API 调用按量计费 | 顺序交接、扇出/扇入、层级委托 |
| Semantic Kernel | 微软企业级 AI 编排框架 | 免费(开源) | 层级委托、顺序交接 |
| Google ADK | A2A 协议参考实现,跨框架 Agent 通信 | 免费(开源) | 所有模式(跨框架场景) |
五种模式综合对比
| 维度 | 顺序交接 | 扇出/扇入 | 层级委托 | 共识投票 | 辩论/对抗 |
|---|---|---|---|---|---|
| 控制方式 | 分布式链式 | 集中式分发 | 多层集中式 | 分布式独立 | 结构化对抗 |
| 延迟 | 高(串行累加) | 低(并行执行) | 中(多层传递) | 中(并行+投票) | 最高(多轮迭代) |
| 成本 | 低(N 次调用) | 中(N 次并行) | 中-高(多层调用) | 高(N×同一问题) | 最高(N×M 轮) |
| 复杂度 | ⭐ | ⭐⭐ | ⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐ |
| 可靠性 | 低(单点故障) | 中 | 中-高 | 高(冗余验证) | 高(对抗验证) |
| 最佳场景 | 线性流水线 | 独立并行任务 | 大型复杂项目 | 高风险决策 | 方案选型/审计 |
| 典型框架 | Swarm, LangGraph | OpenAI SDK, LangGraph | CrewAI, LangGraph | 自定义实现 | AutoGen, LangGraph |
模式选择决策树
你的任务是什么类型?
│
├─ 步骤有严格先后依赖 ──────────────▶ 顺序交接
│
├─ 子任务相互独立 ──────────────────▶ 扇出/扇入
│
├─ 任务需要多层分解 ────────────────▶ 层级委托
│
├─ 需要高可靠性/降低幻觉 ──────────▶ 共识投票
│
└─ 需要深度分析正反面 ─────────────▶ 辩论/对抗
提示:实际项目中常常组合使用多种模式。
例如:层级委托 + 扇出/扇入(总监分解任务,各组并行执行)
顺序交接 + 共识投票(流水线中关键步骤加入投票验证)实战案例:AI 驱动的技术方案评审系统
以下案例展示如何组合多种通信模式构建一个完整的技术方案评审系统:
需求:评审一个"是否迁移到微服务架构"的技术方案
┌─────────────────────────────────────────────────────────┐
│ 第 1 阶段:并行调研(扇出/扇入) │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │成本分析 │ │性能评估 │ │团队评估 │ │风险分析 │ │
│ │Agent │ │Agent │ │Agent │ │Agent │ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
│ └─────────────┴────────────┴─────────────┘ │
│ │ 汇总 │
└─────────────────────────┼───────────────────────────────┘
▼
┌─────────────────────────────────────────────────────────┐
│ 第 2 阶段:对抗辩论(辩论/对抗) │
│ │
│ 正方(支持迁移)◄──── 3 轮辩论 ────▶ 反方(反对迁移) │
│ 基于调研数据展开论证 │
└─────────────────────────┼───────────────────────────────┘
▼
┌─────────────────────────────────────────────────────────┐
│ 第 3 阶段:专家投票(共识投票) │
│ │
│ 架构师 Agent + 运维 Agent + 业务 Agent │
│ 各自基于辩论记录独立投票 → 加权汇总 │
└─────────────────────────┼───────────────────────────────┘
▼
┌──────────────────┐
│ 最终评审报告 │
│ 含:建议、风险、 │
│ 实施路线图 │
└──────────────────┘案例分析
这个案例的关键设计决策:
- 第 1 阶段用扇出/扇入:四个维度的调研相互独立,并行执行可将调研时间缩短 75%
- 第 2 阶段用辩论/对抗:技术方案选型最怕”一边倒”,对抗辩论能暴露隐藏风险
- 第 3 阶段用共识投票:最终决策由多位”专家”独立投票,避免单一视角偏差
- 三阶段串联用顺序交接:每个阶段的输出是下一阶段的输入,保证信息逐步深化
避坑指南
❌ 常见错误
-
所有场景都用顺序交接
- 问题:当子任务相互独立时,串行执行浪费大量时间
- 正确做法:分析任务依赖关系,独立子任务用扇出/扇入并行处理
-
忽略聚合器的设计
- 问题:扇出/扇入模式中,多个 Agent 的输出可能格式不一致、信息重叠甚至矛盾
- 正确做法:为聚合 Agent 编写详细的合并规则,包括去重、冲突解决和优先级策略
-
辩论模式不设终止条件
- 问题:Agent 可能无限辩论下去,消耗大量 token 却无法收敛
- 正确做法:设置最大轮次(通常 2-3 轮即可),并定义明确的收敛标准
-
共识投票使用相同模型和提示词
- 问题:相同的模型和提示词容易产生相似偏差,投票失去意义
- 正确做法:使用不同的系统提示词赋予不同视角,或混合使用不同 LLM 模型
-
层级委托层数过深
- 问题:超过 3 层的委托链会导致严重的信息损耗和延迟
- 正确做法:控制在 2-3 层以内,必要时用扇出/扇入替代深层嵌套
✅ 最佳实践
- 先画通信拓扑图再写代码:在实现之前,用 ASCII 或 Mermaid 画出 Agent 之间的通信关系,明确数据流向
- 从简单模式开始:先用顺序交接验证业务逻辑,确认可行后再引入并行或辩论模式
- 为每个 Agent 定义清晰的输入/输出契约:使用结构化输出(JSON Schema)确保 Agent 间数据格式一致
- 实现优雅降级:当某个 Agent 失败时,系统应能回退到更简单的模式继续运行
- 监控每个 Agent 的 token 消耗:特别是辩论和投票模式,成本可能快速膨胀
- 组合使用多种模式:实际项目中很少只用单一模式,根据不同阶段的需求灵活组合
相关资源与延伸阅读
- OpenAI Agents SDK - Parallel Agents Cookbook — 官方扇出/扇入模式教程
- OpenAI - Orchestrating Agents: Routines and Handoffs — 顺序交接模式的权威指南
- LangGraph Multi-Agent Swarm — LangGraph 的 Swarm 风格多 Agent 实现
- CrewAI Documentation - Hierarchical Process — CrewAI 层级委托模式官方文档
- Multi-Agent Deliberation: When Agreement Is the Bug — 辩论+投票模式的深度实践案例
- Azure Architecture Center - AI Agent Design Patterns — 微软官方 Agent 编排模式参考
- 11 Multi-Agent Orchestration Patterns — 11 种编排模式的完整指南
- 5 Production Patterns That Scale — 生产环境验证的 5 种编排模式
参考来源
- OpenAI Agents SDK - Parallel Agents (2025 年)
- Multi-Agent Orchestration: 5 Production Patterns That Scale (2025 年)
- 11 Multi-Agent Orchestration Patterns: Complete Guide (2026 年)
- Voting or Consensus? Decision-Making in Multi-Agent Debate (2025 年)
- Multi-Agent Debate Frameworks (2025 年)
- Minimizing Hallucinations: Adversarial Debate and Voting Mechanisms (2025 年)
- Azure Architecture Center - AI Agent Design Patterns (2025 年)
- Design Patterns for Agentic AI (2025 年)
- Mastering Agent Orchestration Patterns (2026 年)
📖 返回 总览与导航 | 上一节:10c-A2A协议详解 | 下一节:10e-多Agent实战案例