1. 引言

2023 年以来，以 LLM 为核心的 Agent 应用爆发式增长。各大厂商与开源社区纷纷推出自己的 Agent 开发框架（SDK），试图降低构建智能体的门槛。然而，不同 SDK 在架构设计、通信模式、工具调用、记忆管理、多智能体协作等核心维度上存在显著差异。

本文将对当前最主流的八大 Agent SDK 进行深度架构拆解，包括：

1. LangChain / LangGraph
2. AutoGen (Microsoft)
3. CrewAI
4. Semantic Kernel (Microsoft)
5. Dify (开源 LLMOps 平台)
6. Coze (字节跳动)
7. MetaGPT
8. 百度千帆 AppBuilder

我们将从核心抽象、执行流程、状态管理、多智能体通信、工具集成等角度逐一分析，帮助你在技术选型时做出更明智的决策。

2. 架构拆解通用维度

在深入每个 SDK 之前，我们先定义一套统一的拆解框架，后续各节将按此维度展开。

维度	说明
核心抽象	SDK 定义的最基本概念（如 Agent、Chain、Tool、Memory）
执行引擎	如何编排 LLM 调用、工具执行、条件判断
状态管理	对话历史、中间变量、持久化方式
工具集成	如何定义、注册、调用外部工具/API
多智能体	是否支持多 Agent 协作，通信模式是什么
记忆机制	短期记忆（上下文窗口）、长期记忆（向量库/数据库）
可观测性	日志、追踪、调试能力
部署形态	纯 Python 库 / 平台化服务 / 混合

3. LangChain / LangGraph

3.1 核心抽象

LangChain 的核心抽象是 Chain（链）——将 LLM 调用、Prompt 模板、输出解析器串联成有向无环图（DAG）。LangGraph 在此基础上引入 Graph（图），支持循环、分支、条件跳转，更适合 Agent 场景。

3.2 执行引擎

LangChain 采用 Runnable 协议，所有组件（Prompt、LLM、Tool、OutputParser）都实现 invoke / batch / stream 接口。LangGraph 则用 StateGraph 定义节点（Node）和边（Edge），节点执行后更新全局状态。

from langgraph.graph import StateGraph, END

class AgentState(TypedDict):
    messages: list

def call_model(state: AgentState):
    response = llm.invoke(state["messages"])
    return {"messages": [response]}

graph = StateGraph(AgentState)
graph.add_node("agent", call_model)
graph.set_entry_point("agent")
graph.add_edge("agent", END)

3.3 状态管理

LangChain 的 BaseMemory 接口管理对话历史，支持 ConversationBufferMemory、VectorStoreMemory 等。LangGraph 的 StateGraph 自带状态对象，每次节点执行后返回增量更新。

3.4 工具集成

通过 @tool 装饰器或 Tool 类定义工具，自动生成 JSON Schema 供 LLM 调用。支持 ToolNode 在 LangGraph 中统一执行工具。

3.5 多智能体

LangGraph 原生支持多 Agent 图：每个 Agent 是一个子图，通过共享状态或消息队列通信。典型模式是 Supervisor（主管 Agent）调度多个 Worker Agent。

3.6 优缺点

优点	缺点
生态最丰富，社区活跃	学习曲线陡峭
LangGraph 灵活度极高	抽象层次多，调试复杂
支持流式输出	状态管理需手动配置

4. AutoGen (Microsoft)

4.1 核心抽象

AutoGen 的核心是 Agent 和 ConversableAgent。每个 Agent 拥有自己的 LLM 配置、工具集和回复策略。Agent 之间通过异步消息通信。

4.2 执行引擎

AutoGen 采用对话驱动的执行模式。Agent 收到消息后，调用 LLM 生成回复，可选择执行工具，然后将结果作为新消息发出。整个过程由 initiate_chat 触发。

from autogen import AssistantAgent, UserProxyAgent

assistant = AssistantAgent("assistant", llm_config=llm_config)
user_proxy = UserProxyAgent("user_proxy", code_execution_config={"work_dir": "coding"})

user_proxy.initiate_chat(assistant, message="写一个 Python 脚本计算斐波那契数列")

4.3 状态管理

对话历史由每个 Agent 的 chat_history 列表维护。支持 GroupChat 管理多 Agent 会话，消息按顺序广播。

4.4 工具集成

通过 function_map 将 Python 函数注册为工具。AutoGen 还内置了代码执行器（UserProxyAgent），可自动执行生成的代码并返回结果。

4.5 多智能体

AutoGen 的多 Agent 是其核心亮点：

• GroupChat：多个 Agent 加入群聊，由 GroupChatManager 决定发言顺序（轮询、随机或 LLM 选择）。
• 嵌套对话：一个 Agent 可以发起子对话，形成层级结构。

4.6 优缺点

优点	缺点
多 Agent 协作最成熟	调试复杂，消息风暴难追踪
内置代码执行沙箱	单 Agent 场景不如 LangChain 灵活
支持人类介入（Human-in-the-loop）	文档更新滞后于代码

5. CrewAI

5.1 核心抽象

CrewAI 的三大核心概念：Agent（角色）、Task（任务）、Crew（团队）。Agent 有角色、目标、背景故事；Task 有描述、预期输出、分配 Agent；Crew 编排 Agent 按顺序或层级执行 Task。

5.2 执行引擎

CrewAI 采用任务流水线模式。Crew 启动后，按 Task 定义顺序依次执行，每个 Task 由指定 Agent 完成。支持 sequential（顺序）和 hierarchical（层级，由 Manager Agent 分配）两种流程。

from crewai import Agent, Task, Crew

researcher = Agent(role="研究员", goal="收集最新 AI 新闻")
writer = Agent(role="写手", goal="撰写新闻摘要")

task1 = Task(description="搜索 AI 新闻", agent=researcher)
task2 = Task(description="撰写摘要", agent=writer)

crew = Crew(agents=[researcher, writer], tasks=[task1, task2])
result = crew.kickoff()

5.3 状态管理

每个 Task 的输出存储在 Task.output 中，后续 Task 可通过 context 引用前序结果。Crew 本身不维护全局状态，依赖 Task 链传递数据。

5.4 工具集成

通过 @tool 装饰器定义工具，挂载到 Agent 上。Agent 在执行 Task 时可调用其拥有的工具。

5.5 多智能体

CrewAI 的多 Agent 是角色扮演式的：每个 Agent 有明确的角色描述，LLM 根据角色生成行为。协作通过 Task 依赖关系隐式实现，而非显式消息传递。

5.6 优缺点

优点	缺点
概念简单，上手快	复杂流程表达能力有限
角色扮演让 Agent 行为更可控	不支持动态 Agent 创建
内置任务委派机制	状态管理弱，不适合长流程

6. Semantic Kernel (Microsoft)

6.1 核心抽象

Semantic Kernel 的核心是 Kernel（内核），它管理 Plugin（插件）、Memory（记忆）、Planner（规划器）。Plugin 包含 Native Function（C#/Python 函数）和 Semantic Function（Prompt 模板）。

6.2 执行引擎

Semantic Kernel 采用 Planner 驱动的执行模式。Planner 接收用户目标，自动生成执行计划（一系列 Function 调用），然后由 Kernel 按计划执行。支持 SequentialPlanner、StepwisePlanner、FunctionCallingStepwisePlanner。

import semantic_kernel as sk
from semantic_kernel.connectors.ai.open_ai import OpenAIChatCompletion

kernel = sk.Kernel()
kernel.add_chat_service("gpt", OpenAIChatCompletion("gpt-4"))

# 注册插件
kernel.import_skill_from_directory("./skills", "WriterSkill")

# Planner 自动规划
planner = kernel.create_plan_async("写一篇关于 AI 的博客并保存到文件")

6.3 状态管理

Kernel 内置 MemoryStore 接口，支持 VolatileMemoryStore（内存）、AzureAISearchMemoryStore、ChromaMemoryStore 等。记忆以向量形式存储，支持语义检索。

6.4 工具集成

Plugin 是 Semantic Kernel 的工具单元。Native Function 用 @sk_function 装饰，Semantic Function 用 skprompt.txt + config.json 定义。Kernel 自动为 Plugin 生成 OpenAPI 描述。

6.5 多智能体

Semantic Kernel 本身不强调多 Agent 概念，但可通过 Planner 嵌套 或 多 Kernel 实例 实现类似效果。更推荐与 AutoGen 或 LangGraph 结合使用。

6.6 优缺点

优点	缺点
与 Microsoft 生态深度集成（Azure、Copilot）	社区相对较小
Planner 自动规划能力强	学习曲线中等
记忆系统完善	多 Agent 支持弱

7. Dify (开源 LLMOps 平台)

7.1 核心抽象

Dify 的核心是 App（应用），分为三种类型：Chatbot（对话助手）、Agent（智能体）、Workflow（工作流）。Agent 类型下，用户可配置 LLM、工具、Prompt、知识库。

7.2 执行引擎

Dify 的 Agent 采用 ReAct（Reasoning + Acting）循环：LLM 生成思考 → 决定调用工具 → 执行工具 → 观察结果 → 继续推理。Workflow 类型则用 DAG 编排节点（LLM 节点、代码节点、条件分支等）。

7.3 状态管理

对话历史由 Dify 平台自动管理，存储在数据库中。支持变量（Variables）在 Workflow 节点间传递。知识库（Knowledge）通过向量检索提供长期记忆。

7.4 工具集成

Dify 提供内置工具（Google 搜索、计算器、代码执行等），也支持自定义 API 工具（OpenAPI/Swagger 导入）。工具在 Agent 配置中按需启用。

7.5 多智能体

Dify 本身不直接支持多 Agent 协作，但可通过 Workflow 编排多个 LLM 节点模拟多 Agent 流程。例如：一个节点负责分析，另一个节点负责生成。

7.6 优缺点

优点	缺点
可视化编排，零代码可用	灵活度不如代码级 SDK
内置 RAG 知识库	多 Agent 支持弱
支持 API 发布和嵌入	自部署有一定复杂度

8. Coze (字节跳动)

8.1 核心抽象

Coze 的核心是 Bot（机器人）。Bot 由 Persona（人设）、Prompt、Knowledge（知识库）、Plugin（插件）、Workflow（工作流）和 Trigger（触发器）组成。

8.2 执行引擎

Coze 采用对话式执行。用户输入后，Bot 按以下流程处理：

1. 检索知识库（如有）
2. 调用 Plugin 获取外部数据
3. 组装 Prompt 调用 LLM
4. 返回回复

Workflow 节点支持 LLM、代码、条件、循环等，可嵌入 Bot 作为子流程。

8.3 状态管理

对话历史由 Coze 平台管理，支持变量（Variable）在 Workflow 中传递。知识库支持文本、表格、图片等多种格式。

8.4 工具集成

Plugin 是 Coze 的工具单元，支持内置插件（搜索、阅读、图像生成）和自定义插件（通过 OpenAPI 导入）。Workflow 节点也可视为一种工具。

8.5 多智能体

Coze 支持 Bot 市场 和 Bot 调用 Bot。一个 Bot 可以在 Workflow 中调用另一个 Bot 的 API，实现多 Bot 协作。但这不是传统意义上的多 Agent 通信。

8.6 优缺点

优点	缺点
上手极快，拖拽式配置	深度定制受限
插件生态丰富	数据隐私（托管在字节）
支持发布到飞书、微信等渠道	复杂 Agent 逻辑需 Workflow 弥补

9. MetaGPT

9.1 核心抽象

MetaGPT 的核心是 Role（角色）和 Action（行动）。每个 Role 有特定的职责（如产品经理、架构师、工程师），通过 Message 通信。Action 是 Role 执行的具体步骤。

9.2 执行引擎

MetaGPT 采用软件公司模拟模式。给定一个需求，系统自动创建多个 Role，按瀑布流程执行：

1. 产品经理写 PRD
2. 架构师设计系统设计
3. 工程师编写代码
4. QA 测试

from metagpt.roles import ProductManager, Architect, Engineer
from metagpt.team import Team

team = Team()
team.hire([ProductManager(), Architect(), Engineer()])
team.run_project("开发一个待办事项管理 App")

9.3 状态管理

MetaGPT 使用 MessageQueue 管理角色间通信。每个 Role 维护自己的上下文（rc.memory）。全局状态通过 Environment 对象管理。

9.4 工具集成

MetaGPT 的 Action 可以调用外部工具（如代码执行、搜索）。工具通过 Action 子类的 run 方法集成。

9.5 多智能体

MetaGPT 的多 Agent 是其核心特色：结构化角色分工。每个 Role 有明确的 SOP（标准操作流程），通过消息传递协作。支持 Team 管理多个 Role 的并行/串行执行。

9.6 优缺点

优点	缺点
模拟真实团队，适合复杂项目	流程固定，灵活性低
输出结构化文档（PRD、设计文档）	Token 消耗大
代码生成质量较高	不适合简单对话场景

10. 百度千帆 AppBuilder

10.1 核心抽象

百度千帆 AppBuilder 的核心是 应用（App）。App 由 组件（Component）组成，包括 对话组件、知识库组件、API 组件、流程组件等。

10.2 执行引擎

AppBuilder 采用组件编排模式。用户通过拖拽组件构建流程，支持顺序、条件、循环。每个组件封装了特定的 AI 能力（如文心一言调用、文档解析、图像识别）。

10.3 状态管理

对话历史由百度平台管理。支持变量在组件间传递。知识库支持百度搜索、文档上传等。

10.4 工具集成

通过 API 组件 调用外部服务。百度也提供丰富的内置组件（天气查询、股票查询等）。

10.5 多智能体

AppBuilder 不直接支持多 Agent，但可通过 流程分支 模拟多角色协作。例如：一个分支做意图识别，另一个分支做信息检索。

10.6 优缺点

优点	缺点
与百度生态深度集成（文心一言、百度搜索）	平台锁定
零代码可视化编排	灵活度有限
内置大量百度 AI 能力	社区生态不如开源框架

11. 横向对比总结

SDK	核心抽象	执行模式	多 Agent	上手难度	适用场景
LangChain/LangGraph	Chain / Graph	DAG / StateGraph	强（子图）	高	复杂 Agent、研究原型
AutoGen	ConversableAgent	对话驱动	最强（GroupChat）	中	多 Agent 协作、代码生成
CrewAI	Agent / Task / Crew	任务流水线	中（角色扮演）	低	内容生成、自动化流程
Semantic Kernel	Kernel / Plugin / Planner	Planner 规划	弱	中	企业应用、Microsoft 生态
Dify	App / Agent / Workflow	ReAct / DAG	弱（Workflow 模拟）	低	快速搭建、RAG 应用
Coze	Bot / Plugin / Workflow	对话 + 工作流	弱（Bot 调用 Bot）	极低	聊天机器人、营销助手
MetaGPT	Role / Action	软件公司模拟	强（结构化分工）	中	软件开发自动化
百度千帆 AppBuilder	App / 组件	组件编排	弱	极低	百度生态应用

12. 选型建议

12.1 按场景选型

• 研究原型 / 复杂 Agent：LangChain + LangGraph，灵活度最高。
• 多 Agent 协作：AutoGen，GroupChat 模式最成熟。
• 内容生成 / 自动化流程：CrewAI，角色扮演让输出更可控。
• 企业级应用：Semantic Kernel，与 Azure 集成好。
• 快速搭建 MVP：Dify 或 Coze，零代码即可上线。
• 软件开发自动化：MetaGPT，输出结构化文档和代码。
• 百度生态：千帆 AppBuilder。

12.2 按团队能力选型

• AI 研究团队：LangGraph + AutoGen，深度定制。
• 全栈开发团队：Semantic Kernel 或 Dify，兼顾灵活与效率。
• 产品/运营团队：Coze 或 AppBuilder，无需编码。

13. 未来趋势

1. 标准化：MCP（Model Context Protocol）、A2A（Agent-to-Agent Protocol）等标准正在涌现，未来 SDK 可能统一底层通信协议。
2. 可观测性：Agent 调试和追踪工具将越来越重要（如 LangSmith、Arize）。
3. 多模态 Agent：SDK 将原生支持图像、音频、视频理解与生成。
4. 端侧 Agent：轻量级 SDK 支持在手机、IoT 设备上运行 Agent。
5. 安全与对齐：Agent 权限控制、沙箱执行、内容安全将成标配。

14. 结语

八大 Agent SDK 各有千秋，没有绝对的「最好」，只有「最适合」。理解它们的架构设计哲学，能帮助你在实际项目中做出更明智的技术选型。建议根据你的具体场景、团队技术栈和交付周期，选择 1-2 个 SDK 深入实践。

未来 Agent 开发将越来越像今天的 Web 开发——框架会不断进化，但核心的架构思维（状态管理、工具调用、多智能体通信）将长期有效。掌握这些底层原理，比死记硬背某个 SDK 的 API 更有价值。