一个Agent干所有事等于一个人干所有事——七大编排模式+六大框架打通多智能体Agent协作（上篇）

2601_96614951

667人浏览 · 2026-08-18 14:02:53

2601_96614951 · 2026-08-18 14:02:53 发布

一个Agent干所有事等于一个人干所有事：七大编排模式+六大框架打通多智能体Agent协作（上篇）

本文基于 2026 年 8 月最新生态梳理：LangGraph 0.3+、CrewAI 0.80+（44.7K Stars）、AutoGen v0.4 / MAF 1.0（2026-04 GA）、MetaGPT 0.8+、OpenAI Agents SDK（Swarm 升级版）、Semantic Kernel / MAF 1.0。

说明：文中代码示例以「可直接运行的片段」与「逻辑示意 / 伪代码」混合呈现，伪代码处已显式标注，复制运行前请注意区分；版本号、Stars 数、GA 日期均为当时生态快照，技术迭代很快，请以各项目官方最新文档为准。

导读（建议先读）

适合谁：已经会用某个单一 Agent 框架写过基础 Agent，想进一步理解「多个 Agent 怎么协同」的开发者。如果还不会写单 Agent，建议先补基础。

你能得到什么：七大经典编排模式（各自适用场景与风险）、六大主流框架（LangGraph / CrewAI / AutoGen / MetaGPT / OpenAI Agents SDK / MAF）的横向对比、通信机制、状态管理、四个实战案例，以及选型决策树与最佳实践清单。

怎么读：本文分上下两篇，上篇讲原理与框架，下篇讲状态管理、实战与选型；可收藏分次阅读；含多张横向对比表格，桌面端阅读体验更佳。关键术语首次出现处已加英文括号，完整术语表见下篇第十节。

一个 Agent 干所有事，等于一个人干所有事

你写了一个 AI Agent，让它同时负责需求分析、搜索资料、写代码、测试、写文档。听起来很全能，但实际跑起来：

上下文爆炸。100 步的深度研究任务把单一上下文撑到接近百万 token，注意力质量随长度衰减，中间信息被"Lost in the Middle"。
角色混乱。同一个 Agent 既写代码又审查代码，自己写的东西自己审，等于让厨师自己查食品安全。系统提示词逐渐变成一堆互相矛盾的指令。
错误雪崩。Agent 第 3 步推理错了，第 4 步基于错误写代码，第 5 步执行报错，第 6 步试图修复——每一步都在错误基础上叠加错误。没有"叫停"机制。
无法并行。3 个独立子任务只能串行处理。明明可以同时干的活，硬是排成一条长队。单 Agent 的本质是顺序执行，wall-clock time 线性累积。

2026 年 6 月 Anthropic 发布的技术报告《Scaling Intelligence through Multi-Agent Collaboration》用数据证明了这一点（报告全称与出处见文末参考文献 [1]）：在 SWE-bench 上，5 个专业 Agent 组成的协作团队任务完成率达到 78.4%，而同参数量的单体 Agent 仅为 41.2%——差了将近一倍。

说明：上述数字为该报告在特定实验设定下的观测值，会因任务、模型与评测方式不同而变化，请勿当作通用基准；引用时请以官方最新报告为准。

根本原因：你把一个复杂任务压在一个 Agent 身上，让它既当规划者又当执行者还当审查者。 就像让一个人同时当项目经理、程序员和测试员——不是干不好，是上下文切换的成本太高，角色之间的冲突太严重。

解法：把一个超级 Agent 拆成多个专精 Agent，让它们通过编排模式协作。 就像把一个全能选手拆成一个团队——有人负责规划，有人负责搜索，有人负责写代码，有人负责审查。每个 Agent 只关心自己的领域，上下文干净，角色清晰。

但问题来了：多个 Agent 怎么协作？谁先干谁后干？谁听谁的？ 这就是多智能体编排（Multi-Agent Orchestration）要解决的核心问题。

一、多智能体系统基础

1.1 什么是多智能体系统

多智能体系统（Multi-Agent System, MAS）是指由多个 AI Agent 组成、通过某种编排模式协作完成复杂任务的系统。每个 Agent 有自己的角色、工具、记忆和目标，它们通过消息传递、共享状态或工具调用进行通信。

核心公式：MAS = N 个专精 Agent + 1 套编排模式 + 通信机制

与单 Agent 的本质区别不在于"Agent 数量多了"，而在于引入了协调层——用协调（coordination）换计算（computation），把一个超长上下文的推理问题拆解为多个短上下文的协作问题。

1.2 为什么需要多智能体

单 Agent 瓶颈	多 Agent 解法
上下文窗口竞争：多任务共享一个上下文，有效信息被稀释	上下文隔离：每个 Agent 只持有自己领域的上下文
角色冲突：同时扮演编码者和审查者，模型自我妥协	角色专精：每个 Agent 只干一件事，提示词无冲突
专业深度不足：一个模型很难同时精通多个领域	领域专家：每个 Agent 可以用不同模型、不同 system prompt
错误累积：一步错步步错，没有制衡机制	错误隔离：单个 Agent 失败不影响全局，有审查机制
无法并行：线性执行，耗时 = 各步骤之和	并行执行：独立子任务同时处理，耗时 = 最慢的子任务
可解释性差：一个 Agent 的决策黑盒	独立审计：每个 Agent 的输入输出可独立监控

1.3 核心挑战

多智能体不是银弹，它引入了新的复杂度：

协调开销。Agent 之间的通信、任务分配、结果聚合都需要额外成本。在「每轮每个 Agent 都各自调用 LLM」的串行设定下，3 个 Agent 跑 10 轮约为 30 次 LLM 调用；若采用并行或批量调度，实际调用次数会明显低于这种线性乘积。
一致性保证。多个 Agent 可能产生矛盾的结果，需要冲突消解机制。
死循环风险。Agent A 把任务交给 B，B 交给 C，C 又交回 A——没有终止条件就无限循环。
调试困难。多个 Agent 的交互链路复杂，出问题时定位根因比单 Agent 难得多。
成本控制。多 Agent = 多次 LLM 调用，Token 消耗是单 Agent 的 N 倍。

二、七大编排模式

编排模式决定了"谁什么时候干什么"。几乎所有多智能体系统都可以归结为以下七种模式，或它们的组合。

七大编排模式速览（思维导图，ASCII 呈现，规避部分平台 Mermaid 兼容问题）

┌─ Supervisor 中央调度，任务分解 / 分配 / 聚合

编排模式 ─────┼─ Hierarchical 多层委派，树形逐层上报

（Orchestration) ├─ Collaborative 自由对话，涌现协作（无固定流程）

├─ Sequential 线性流水线，上游输出 = 下游输入

├─ Event-Driven 事件触发，异步发布 / 订阅

├─ Debate/Voting 对抗审查，多轮辩论后投票决策

└─ Routing/Triage 动态路由，意图分诊按需分配

2.1 监督者模式 Supervisor

一个中央 Supervisor Agent 接收任务，分解为子任务，分配给各专家 Agent，收集结果后综合输出。只有 Supervisor 看到全局。

适用场景：子任务边界清晰的复杂任务（客服系统、内容生成流水线、代码审查工作流）。

关键设计：Supervisor 通常运行在更强的模型上（GPT-4o / Claude Sonnet），专家 Agent 可以用更便宜的模型（GPT-4o-mini / Claude Haiku），因为它们的任务范围窄得多。

风险：Supervisor 本身容易成为瓶颈。任务分解一旦出错，下游每个 Agent 都会拿到错误指令。

2.2 层级模式 Hierarchical

Supervisor 模式的多层扩展——Supervisor 把子任务委派给中间 Manager，Manager 再分配给底层 Worker，形成树形结构。

适用场景：任务可以按组织架构自然分层（软件开发团队、项目管理、多层审批流程）。

关键设计：每层 Manager 只负责自己管辖的 Worker，不需要了解全局。结果逐层上报聚合。

2.3 协作模式 Collaborative

多个 Agent 自由对话，没有固定的流程和发言顺序。协作模式通过"涌现"产生——谁该发言、什么时候结束，由对话本身决定。

适用场景：开放性任务（头脑风暴、创意生成、多角度分析、研究讨论）。

关键设计：需要 Selector（LLM 充当主持人）决定下一个发言者，或者用 RoundRobin 轮询。必须有终止条件防止无限对话。

风险：流程不可控，调试困难。Agent 可能聊偏、重复、陷入循环。

2.4 流水线模式 Sequential

Agent 按固定顺序串联成线性链路，每个节点接收上游输出，处理后传递给下游。就像工厂流水线——原料经过一道道工序变成成品。

适用场景：有明确先后依赖的任务（需求分析 -> 设计 -> 编码 -> 测试），每步输入是上步输出。

优势：逻辑清晰，易于调试，流程可预测。

劣势：无法并行，总耗时 = 各 Agent 耗时之和。一个节点卡住整个流水线都卡住。

2.5 事件驱动模式 Event-Driven

Agent 不按固定顺序执行，而是监听事件、异步响应。当某个条件满足时触发对应的 Agent。类似消息队列的发布/订阅模式。

适用场景：需要异步响应、事件触发的场景（实时数据处理、监控系统、IoT 设备管理）。

关键设计：需要一个事件总线（Event Bus）负责消息路由。Agent 之间不直接调用，而是通过发布/订阅解耦。

2.6 辩论投票模式 Debate/Voting

多个 Agent 从不同角度分析同一个问题，通过多轮辩论互相质疑，最终投票得出结论。

适用场景：高精度要求的场景（代码审查、医疗诊断、投资决策、法律分析）。

关键设计：在高风险决策场景中，让多个 Agent 扮演「对立辩论者」（Team of Rivals）相互质疑，是提升结论可靠性的有效手段。公开研究与行业实践（见文末参考文献 [3]）显示，这种对立辩论模式在金融对账、医疗诊断等任务上，任务成功率可由约 60% 提升至 90% 以上——具体数值取决于任务与评测设定，请勿当作通用基准。

劣势：多轮往返，Token 消耗大，耗时较长。

2.7 路由分诊模式 Routing/Triage

一个 Router Agent 根据输入类型动态决定调用哪个专家 Agent。类似医院分诊台——根据症状把你分到不同科室。

适用场景：输入类型多样、需要灵活调度的场景（客服系统、多领域问答、工单分类）。

关键设计：Router 可以是 LLM（用 prompt 做意图分类），也可以是传统分类模型。路由逻辑的准确率直接决定系统效果。

2.8 模式对比与选型

模式	控制度	并行度	复杂度	Token 成本	适用场景
Supervisor	高	中	中	中	子任务边界清晰的复杂任务
Hierarchical	高	中	高	高	多层组织架构、大型项目
Collaborative	低	低	低	高	开放讨论、创意生成
Sequential	最高	无	低	低	固定流程、流水线作业
Event-Driven	中	高	高	中	异步响应、实时处理
Debate/Voting	中	低	中	最高	高精度决策、对抗审查
Routing/Triage	高	高	低	低	意图分类、客服路由

选型原则：

需要确定性？Sequential > Supervisor > Routing
需要并行？Event-Driven > Routing > Supervisor
需要高精度？Debate/Voting
需要灵活性？Collaborative > Hierarchical
快速原型？Routing > Sequential > Supervisor

小结（七大模式）：七种模式本质是「控制度 × 并行度 × 成本」的不同取舍——Supervisor / Hierarchical 控制强但中心化，Sequential 最可控却无法并行，Event-Driven / Routing 并行度最高，Collaborative 灵活但难调试，Debate/Voting 质量最高但最贵。选型没有银弹：先按任务是否「确定、并行、高精度、灵活」四问缩窄范围，再结合团队熟悉度决定。

三、通信机制

Agent 之间怎么"说话"决定了系统的效率和可靠性。

3.1 消息传递

最基础的通信方式——Agent 通过发送和接收消息交互。每条消息包含发送者、接收者、内容和元数据。

# AutoGen 风格的消息传递
from autogen_agentchat.messages import TextMessage

message = TextMessage(
    source="researcher",       # 发送者
    content="找到 3 篇相关论文",  # 内容
)
# Receiver 收到后处理

优势：松耦合，Agent 之间不需要知道彼此的内部实现。
劣势：消息可能丢失、乱序。需要额外的消息队列和状态管理。

3.2 共享状态

所有 Agent 读写同一个全局状态对象。不是"发消息"而是"改状态"——下一个 Agent 看到状态变化后自动响应。

# LangGraph 风格的共享状态
from typing import TypedDict, Annotated
from langgraph.graph import add_messages

class AgentState(TypedDict):
    messages: Annotated[list, add_messages]  # 消息历史（追加语义）
    current_task: str                         # 当前任务
    research_data: list                       # 研究数据
    final_answer: str | None                  # 最终答案

优势：状态一致性强，可检查点（checkpoint），可回滚。
劣势：并发写入需要锁机制。状态对象可能膨胀。

3.3 工具调用

Agent A 调用 Agent B 暴露的工具函数。本质上是一种 RPC（远程过程调用）。

# Agent A 把 Agent B 当工具用
@tool
def ask_reviewer(code: str) -> str:
    """让审查员检查代码"""
    return reviewer_agent.run(task=f"审查这段代码：{code}")

优势：调用关系明确，易于追踪。
劣势：紧耦合。被调用的 Agent 变成"函数"，失去自主性。

3.4 人类介入

Human-in-the-Loop（HITL）——在关键决策点暂停 Agent 执行，等待人类确认。

# LangGraph 的 human-in-the-loop
from langgraph.graph import StateGraph

graph = StateGraph(AgentState)
# 此处省略节点内部实现，仅演示图的编排逻辑
graph.add_node("generate", generate_code)
graph.add_node("human_review", human_review_node)  # 人工审查节点
graph.add_node("execute", execute_code)

# 在 generate 之后、execute 之前插入人工审查
graph.add_edge("generate", "human_review")
graph.add_conditional_edges(
    "human_review",
    lambda state: "execute" if state["approved"] else "generate"
)

适用场景：金融审批、医疗诊断、高风险操作前的确认。

四、主流框架详解

4.1 LangGraph

核心架构：把 Agent 执行流程建模为有向图（State Graph），每个节点是处理步骤，边定义流转逻辑。支持循环、条件分支、检查点和人工介入。

指标	数值
开发团队	LangChain Team
GitHub Stars	13K+
核心理念	确定性工作流 > 灵活协商
核心隐喻	状态机 / 有向图
适用场景	金融审批、医疗诊断、合规检查

核心概念：

概念	说明
State	全局状态对象，所有节点共享读写
Node	处理函数，接收 State 返回 State 更新
Edge	节点间的连接，支持固定边和条件边
Reducer	定义 State 字段如何合并（追加 vs 覆盖）
Checkpoint	状态快照，支持中断恢复
Interrupt	任意节点暂停，等待人工输入

代码示例 — Supervisor 模式实现：

from typing import TypedDict, Annotated, Literal
from langgraph.graph import StateGraph, START, END, add_messages
from langchain_openai import ChatOpenAI

llm = ChatOpenAI(model="gpt-4o", temperature=0)

# 1. 定义共享状态
class AgentState(TypedDict):
    messages: Annotated[list, add_messages]  # 注意：必须是 add_messages 函数对象，而不是字符串 "add_messages"
    next_agent: str
    research_results: str
    code_output: str
    review_status: str

# 2. Supervisor 节点：决定下一个该谁干
def supervisor_node(state: AgentState) -> dict:
    response = llm.invoke(
        f"""你是项目协调者。根据当前状态决定下一步：
        研究结果: {state.get("research_results", "无")}
        代码输出: {state.get("code_output", "无")}
        审查状态: {state.get("review_status", "无")}

        可选: "researcher" / "coder" / "reviewer" / "FINISH"
        只返回一个单词。"""
    )
    next_agent = response.content.strip()
    return {"next_agent": next_agent}

# 3. 专家节点
def researcher_node(state: AgentState) -> dict:
    result = llm.invoke(f"研究以下主题: {state['messages'][-1].content}")
    return {"research_results": result.content, "next_agent": "supervisor"}

def coder_node(state: AgentState) -> dict:
    code = llm.invoke(f"根据研究结果写代码: {state['research_results']}")
    return {"code_output": code.content, "next_agent": "supervisor"}

def reviewer_node(state: AgentState) -> dict:
    review = llm.invoke(f"审查代码: {state['code_output']}")
    status = "PASSED" if "通过" in review.content else "FAILED"
    return {"review_status": status, "next_agent": "FINISH" if status == "PASSED" else "supervisor"}

# 4. 构建图
graph = StateGraph(AgentState)
graph.add_node("supervisor", supervisor_node)
graph.add_node("researcher", researcher_node)
graph.add_node("coder", coder_node)
graph.add_node("reviewer", reviewer_node)

graph.add_edge(START, "supervisor")
graph.add_conditional_edges(
    "supervisor",
    lambda state: state["next_agent"],
    {
        "researcher": "researcher",
        "coder": "coder",
        "reviewer": "reviewer",
        "FINISH": END,
    },
)
for node in ["researcher", "coder", "reviewer"]:
    graph.add_edge(node, "supervisor")

app = graph.compile()
result = app.invoke({"messages": [{"role": "user", "content": "写一个 Flask TODO API"}]})

4.2 CrewAI

核心架构：把 Agent 当成团队成员。Agent + Task + Crew + Process 四个概念组织工作流。

指标	数值
GitHub Stars	44.7K+
PyPI 月下载	500K+
财富 500 强使用率	60%
2026 Q1 融资	2.5 亿美元 B 轮
核心理念	角色扮演 + 任务驱动
核心隐喻	剧组 / 项目团队

注：上表「财富 500 强使用率 60%」「2026 Q1 融资 2.5 亿美元 B 轮」等数据来自 CrewAI 厂商公开对外披露，引用时请以官方最新公告为准。

Agent 定义：

from crewai import Agent, Task, Crew, Process

researcher = Agent(
    role="Research Analyst",
    goal="收集关于 {topic} 的深度信息",
    backstory="你是一位资深研究员，擅长挖掘关键信息",
    # 注：search_tool 需自行初始化，例如 SerpAPIWrapper 或 CrewAI 内置工具；
    # 下方为示意，运行前请先定义该变量（详见文末「示例依赖说明」）。
    tools=[search_tool],
    llm="gpt-4o",
    verbose=True,
)

writer = Agent(
    role="Content Writer",
    goal="将研究内容转化为高质量文章",
    backstory="你是专业科技写手，文笔简洁有力",
    llm="gpt-4o",
)

reviewer = Agent(
    role="Quality Reviewer",
    goal="确保文章质量符合标准",
    backstory="你是资深编辑，严谨认真",
    llm="gpt-4o",
)

三种编排模式：

# 模式 1: Sequential（顺序流水线）
crew = Crew(
    agents=[researcher, writer, reviewer],
    tasks=[research_task, writing_task, review_task],
    process=Process.sequential,
)

# 模式 2: Hierarchical（层级管理，自动委派）
crew = Crew(
    agents=[researcher, writer, reviewer],
    tasks=[research_task, writing_task, review_task],
    process=Process.hierarchical,
    manager_llm="gpt-4o",  # 经理 Agent 的模型
)

result = crew.kickoff(inputs={"topic": "MCP 协议"})

Flow 工作流（事件驱动）：

from crewai.flow.flow import Flow, listen, start, or_, and_

class ContentFlow(Flow):
    @start()
    def research(self):
        return researcher.execute("研究 AI Agent 趋势")

    @listen(research)
    def write(self, research_data):
        return writer.execute(f"基于以下研究写文章: {research_data}")

    @listen(write)
    def review(self, article):
        return reviewer.execute(f"审查文章: {article}")

    @listen(review)
    def publish(self, review_result):
        if "APPROVED" in review_result:
            return "发布"
        else:
            return "打回重写"

flow = ContentFlow()
result = flow.kickoff()

4.3 AutoGen

核心架构：三层体系——autogen-core（事件驱动运行时）+ autogen-agentchat（高层 API）+ autogen-ext（可插拔扩展）。

指标	数值
开发团队	微软研究院
GitHub Stars	45K+
当前状态	演进整合中：AutoGen v0.4 仍持续维护可用；微软正将其能力并入下一代统一框架 MAF（Microsoft Agent Framework），属演进合并而非废弃旧项目
核心理念	对话驱动，涌现智能
核心隐喻	专家研讨会

代码示例：

import asyncio
from autogen_agentchat.agents import AssistantAgent
from autogen_agentchat.teams import RoundRobinGroupChat, SelectorGroupChat
from autogen_agentchat.conditions import TextMentionTermination, MaxMessageTermination
from autogen_agentchat.ui import Console
from autogen_ext.models.openai import OpenAIChatCompletionClient

async def main():
    model_client = OpenAIChatCompletionClient(model="gpt-4o")

    coder = AssistantAgent(
        name="coder",
        model_client=model_client,
        system_message="你是 Python 程序员。写完代码后说 REVIEW。",
    )

    reviewer = AssistantAgent(
        name="reviewer",
        model_client=model_client,
        system_message="你是代码审查者。通过后说 APPROVED。",
    )

    # 轮询团队（顺序模式）
    team = RoundRobinGroupChat(
        participants=[coder, reviewer],
        termination_condition=TextMentionTermination("APPROVED") | MaxMessageTermination(10),
    )

    # 选择性团队（协作模式）
    # team = SelectorGroupChat(
    #     participants=[coder, reviewer],
    #     model_client=model_client,
    #     termination_condition=MaxMessageTermination(15),
    # )

    await Console(team.run_stream(task="写一个二分查找函数"))
    await model_client.close()

asyncio.run(main())

4.4 MetaGPT

核心架构：核心理念是 Code = SOP(Team)——把人类软件团队的标准操作流程（SOP）编码到多 Agent 系统中。每个 Agent 通过结构化文档（而非自由对话）通信。

指标	数值
学术发表	ICLR 2024 口头报告（Top 1.2%）
代码生成准确率	85.9%（HumanEval pass@1，出自 MetaGPT ICLR 2024 论文，见参考文献 [2]）
核心理念	Code = SOP(Team)
核心隐喻	软件公司
通信方式	结构化文档（PRD、设计文档）

角色系统：

与 AutoGen/CrewAI 的根本区别：MetaGPT 的 Agent 之间不"聊天"，而是"交接结构化文档"。 产品经理输出 PRD，架构师读 PRD 输出设计文档，工程师读设计文档输出代码——每一步的输入输出都是标准化的。

代码示例：

import asyncio
from metagpt.roles import ProductManager, Architect, ProjectManager, Engineer, QAEngineer
from metagpt.team import Team
from metagpt.actions import UserRequirement

async def startup(idea: str):
    team = Team()
    team.hire([
        ProductManager(),
        Architect(),
        ProjectManager(),
        Engineer(),
        QAEngineer(),
    ])
    team.invest(investment=5.0)  # 美元预算
    team.run_project(idea=UserRequirement(content=idea))
    await team.run(n_round=5)

asyncio.run(startup("写一个命令行 TODO List 应用，支持增删改查和优先级"))

4.5 OpenAI Swarm / Agents SDK

核心概念：只有两个原语——Agent 和 Handoff（交接）。Agent 干完自己的活，返回另一个 Agent 对象，框架自动换人，对话历史无缝带走。

指标	数值
发布时间	2024-10（Swarm 实验版）/ 2025-03（Agents SDK 正式版）
核心理念	极简，两个概念跑通
核心隐喻	函数路由
状态管理	无状态（客户端管理）

Swarm 是实验性框架，Agents SDK 是其企业级升级版，增加了 Guardrails（护栏）、MCP 支持、Tracing（追踪）等能力。

代码示例：

from agents import Agent, Runner, handoff

# 定义 Agent
billing_agent = Agent(
    name="Billing Agent",
    instructions="你只处理账单相关问题。",
)

tech_agent = Agent(
    name="Tech Agent",
    instructions="你只处理技术问题。账单问题交接给 Billing Agent。",
    handoffs=[billing_agent],  # 可以交接给 billing_agent
)

triage_agent = Agent(
    name="Triage Agent",
    instructions="""你是分诊路由。根据用户问题类型交接：
    - 账单问题 -> Billing Agent
    - 技术问题 -> Tech Agent""",
    handoffs=[billing_agent, tech_agent],
)

# 运行
result = Runner.run_sync(
    triage_agent,
    "我的账单多扣了钱，而且 App 打不开",
)
print(result.final_output)

4.6 Semantic Kernel / MAF

Agent 类型：MAF 1.0 提供统一的 AIAgent 抽象，支持多种 Agent 类型。

指标	数值
MAF 1.0 GA	2026 年 4 月（本文撰写时为 GA 版本；技术迭代快，请以官方最新发布为准）
前身	Semantic Kernel + AutoGen（75K+ 合计 Stars）
语言支持	.NET + Python
核心理念	企业级、生产就绪
BUILD 2026	Agent Harness + Hosted Agents

MAF 五层架构：

层级	组件	职责
L5	Orchestration & Workflow	图结构工作流引擎，可检查点的多智能体编排
L4	Agent Layer (AIAgent)	统一智能体抽象，管理指令、工具、会话状态
L3	Kernel Layer (Semantic Kernel)	基础能力：LLM 调用、记忆、插件
L2	Connectors	模型连接器（OpenAI、Anthropic、Ollama）
L1	Models	模型抽象层

编排模式：MAF 的 L5 层提供与 LangGraph 类似的图结构编排，支持检查点、条件分支和人工审批。

// .NET 示例（片段：researcherAgent / writerAgent / reviewerAgent 需提前初始化，
// 此处省略初始化与项目引用，仅展示编排 API 用法）
using Microsoft.AgentFramework;
using Microsoft.AgentFramework.Orchestration;

var workflow = new AgentWorkflow()
    .AddAgent("researcher", researcherAgent)
    .AddAgent("writer", writerAgent)
    .AddAgent("reviewer", reviewerAgent)
    .AddEdge("researcher", "writer")
    .AddEdge("writer", "reviewer")
    .AddConditionalEdge("reviewer", state =>
        state.Get<string>("status") == "approved" ? "end" : "writer")
    .Build();

var result = await workflow.RunAsync("写一篇关于 AI Agent 的技术报告");

4.7 框架横向对比

维度	LangGraph	CrewAI	AutoGen	MetaGPT	OpenAI Agents SDK	Semantic Kernel / MAF
设计哲学	确定性 > 灵活性	分工 > 自由协商	涌现 > 预设	SOP > 对话	极简 > 复杂	企业级 > 轻量
核心隐喻	状态机	剧组	研讨会	软件公司	函数路由	企业中间件
编排方式	有向图	角色+任务	对话+轮询	SOP流水线	Handoff	图工作流
状态管理	显式 StateGraph	隐式任务队列	对话历史	结构化文档	客户端管理	L5 图引擎
检查点	内置	无	有（v0.4）	无	无	内置
人工介入	原生支持	有限	有	无	有	原生支持
异步执行	支持	部分	完全异步	部分	支持	支持
分布式	不支持	不支持	gRPC	不支持	不支持	支持
MCP 支持	有	有	有	无	有	有
语言	Python	Python	Python	Python	Python	.NET + Python
学习曲线	中高	低	中	中	最低	高
GitHub Stars	13K+	44.7K+	45K+	43K+	21K+	75K+（合计）
适用场景	生产级可控流程	快速原型/内容	研究探索	软件开发	简单路由	企业级 .NET

一句话总结：

需要确定性和可控性？LangGraph
需要快速原型和角色协作？CrewAI
需要自由探索和动态协作？AutoGen
需要软件开发和SOP 流程？MetaGPT
需要极简上手和OpenAI 生态？Agents SDK
需要企业级 .NET和生产就绪？MAF

小结（六大框架）：框架之争本质是「确定性 vs 灵活性」的哲学差异——LangGraph 把流程变成可检查点的图，适合生产级可控流程；CrewAI 用角色扮演快速跑通原型；AutoGen 偏研究探索与涌现协作；MetaGPT 用 SOP + 结构化文档规范软件开发；OpenAI Agents SDK 极简上手、Handoff 天然路由；MAF 面向企业级 .NET 与生产就绪。先想清楚要「可控」还是「好上手」再选，别被 Stars 数带节奏。

下篇预告

上篇我们梳理了「为什么要多 Agent」、七大编排模式、通信机制，以及六大框架的横向对比。下篇将进入工程落地：状态管理与检查点、Map-Reduce 等高级模式、四个实战案例、选型决策树与最佳实践，并附完整术语表与参考文献。

👉 下篇传送门：一个Agent干所有事等于一个人干所有事：七大编排模式+六大框架打通多智能体Agent协作（下篇）

参考文献与延伸阅读

以下为文中关键数据与结论的可溯源出处，引用时请以官方最新版本为准。

[1] Anthropic. Scaling Intelligence through Multi-Agent Collaboration（技术报告，2026-06）. 官方研究主页：https://www.anthropic.com/research
[2] Sirui Hong 等. MetaGPT: Meta Programming for A Multi-Agent Collaborative Framework（ICLR 2024）. arXiv：https://arxiv.org/abs/2308.00352（文中 85.9% 为 HumanEval pass@1 指标）
[3] 多方公开研究与工业落地实践表明，对立辩论模式可以提升复杂任务的可靠性；文中数值来自部分金融、医疗场景的行业实践，并非通用论文基准。
[4] 各框架官方文档（版本与 API 以官方最新为准）：
- LangGraph：https://langchain-ai.github.io/langgraph/
- CrewAI：https://docs.crewai.com/
- AutoGen：https://microsoft.github.io/autogen/
- MetaGPT：https://github.com/geekan/MetaGPT
- OpenAI Agents SDK：https://openai.github.io/openai-agents-python/
- Microsoft Agent Framework (MAF)：https://github.com/microsoft/agent-framework

智能体开发者社区

中国智能体开发者社区，聚焦智能体与大模型开发，提供前沿资讯、实用工具链、开源项目及行业案例。通过技术沙龙、开发者大赛等活动，促进经验交流与协作，助力开发者快速构建创新智能应用。

更多推荐

MCP协议开发实战：从零搭建AI Agent工具链

创建静态资源（如项目 README 文件）。创建动态资源（如实时系统状态）。在 Client 中请求并利用资源上下文。回顾 MCP 协议如何降低 AI Agent 开发门槛。当前生态的局限与未来的演进方向。鼓励读者基于此大纲进行实践，并参与开源贡献。

智能体开发者社区

AI Agent可观测性：破解多步推理黑盒

随着AI Agent在复杂任务中承担越来越多的决策角色，其内部的多步推理过程往往如同一个“黑盒”，难以理解、调试和信任。本文旨在探讨AI Agent可观测性（Observability）的核心概念、技术挑战与实践方案，为开发者提供一套系统的方法论和工具链，以“照亮”Agent的推理黑盒，实现对其行为、决策逻辑与内部状态的全面洞察。构建AI Agent的可观测性体系不再是“锦上添花”，而是保障其在大