一、为什么需要认真做 AI Agent 框架选型

2024 年以来，从“聊天机器人”到“能自动调用工具、拆解任务、多角色协作的 Agent”，LLM 应用的形态发生了巨大变化。一个完整的 Agent 通常需要具备以下能力：

• 工具调用（Tool Calling）：调用搜索、数据库、API、代码执行器等外部能力。
• 任务规划（Planning）：把复杂目标拆解为可执行的子任务。
• 状态管理（State）：在多次模型调用之间保存上下文、中间结果和分支状态。
• 多智能体协作（Multi-Agent）：让多个不同角色的 Agent 互相配合。
• 可观测性（Observability）：追踪每一步调用、Token 消耗和错误。

市面上的框架非常多，LangGraph、AutoGen、CrewAI、OpenAI Agents SDK、LlamaIndex、MetaGPT、Semantic Kernel、Dify、Coze……如果一开始选错，轻则后期重构成本高，重则整个系统难以维护和扩展。本文从架构模型、多智能体能力、状态管理、学习曲线、生产成熟度五个维度做系统对比，并给出四套可直接运行的代码实战。

二、AI Agent 的通用架构与核心概念

在深入到具体框架之前，先统一几个概念，否则很容易在选型时被各家宣传语绕晕。

2.1 单 Agent 与多 Agent

• 单 Agent：一个 LLM 循环完成工具调用，典型流程是“用户输入 → LLM 决策 → 调用工具 → 观察结果 → 再次决策 → 输出”。适合明确、边界清晰的单目标任务。
• 多 Agent：多个 Agent 分别承担不同角色，通过消息传递、共享状态或任务交接协作。适合研究、内容生产、复杂业务流程等需要分工的场景。

2.2 编排方式的三种主流模型

• 图/状态机编排：开发者显式定义节点与边，控制流完全确定。代表：LangGraph、LlamaIndex Workflow。
• 对话式编排：Agent 之间自由对话，由 LLM 自行决定“接下来和谁说话”。代表：AutoGen、Agno。
• 角色任务编排：先定义角色，再把任务按顺序或层级分配给不同角色。代表：CrewAI。

理解这三种模型，几乎就能看懂所有框架的底层差异。

三、主流框架全景对比

下面这张表汇总了目前开发者讨论最多的几个框架。需要注意的是，“生产成熟度”会随着版本迭代快速变化，建议把它当作选型起点而非最终结论。

框架	开发方	核心定位	多智能体	状态管理	学习曲线	生产成熟度
LangGraph	LangChain	图状态机工作流	可控、显式	强（显式 State）	中高	高
AutoGen	Microsoft	多智能体自由对话	强	中	中	高
CrewAI	CrewAI	角色分工任务编排	强（角色化）	中	低	中高
OpenAI Agents SDK	OpenAI	轻量工具型 Agent	中（Handoff）	中	低	中
LlamaIndex	LlamaIndex	RAG 与数据工作流	中（Workflow）	中	中	高
MetaGPT	社区	软件公司角色模拟	强（角色 SOP）	中	中高	中
Dify / Coze	社区 / 字节	低代码可视化平台	中（可视化）	可视化	低	高（快速原型）

此外还有 Semantic Kernel（.NET 生态友好）、Agno（轻量高性能）、Langroid（多 Agent 编程）等，它们各有侧重。下面重点展开四个最值得深入学习的框架。

3.1 LangGraph：最像“工程系统”的 Agent 框架

LangGraph 把 Agent 抽象成一张有状态的图。每个节点是一个函数，边定义执行顺序，状态在节点之间传递。它的最大优势是控制流完全确定、容易调试、支持断点和时间旅行，非常适合需要严格流程控制的业务系统，例如客服工单流转、RAG 检索重排序、多步骤审批。

需要注意的是，LangGraph 的灵活性和学习成本成正比。如果需求只是“让模型调个天气 API”，用 LangGraph 会显得偏重。

3.2 AutoGen：对话驱动的多智能体

AutoGen 由微软研究院开源，核心思想是让多个 ConversableAgent 像群聊一样自由对话。它天然支持“用户代理 + 助手代理”双向交互，也支持 GroupChat 多人讨论，适合做研究、辩论、代码审查这类需要“多轮协商”的任务。

AutoGen 的短板在于：自由对话的确定性较差，生产环境中可能出现循环对话、话轮失控等问题，需要额外配置 max_round、终止条件等约束。

3.3 CrewAI：角色和任务最直观

CrewAI 的学习曲线最低。你只需要定义“角色（Role）”“目标（Goal）”“背景（Backstory）”，然后把任务交给 Crew 编排执行。它把“一个团队（Crew）如何协作”这个概念映射得非常自然，适合内容生产、市场调研、报告生成等流水线型任务。

代价是，它牺牲了部分底层控制能力；当需要精细控制状态流转或自定义复杂分支时，会明显感受到框架的边界。

3.4 OpenAI Agents SDK：轻量工具型 Agent

OpenAI Agents SDK 是 OpenAI 官方推出的极简 Agent 框架，从早期 Swarm 演进而来。它把 Agent 定义为“模型 + 指令 + 工具”，通过 Runner.run() 一行代码执行，并支持 Agent Handoff 实现多 Agent 交接。上手成本极低，适合快速验证产品原型。

它的定位是轻量编排，不适合承载复杂的图状态机或大规模多 Agent 协作。

四、选型的六个关键维度

没有“最好的框架”，只有“最匹配当前问题”的框架。建议从以下六个维度打分：

1. 任务复杂度：是单步工具调用，还是多分支、多轮、多角色的复杂流程？
2. 控制流确定性：业务是否要求每一步都可追踪、可回放、可审计？
3. 团队技术栈：团队更熟悉 Python、TypeScript 还是 .NET？是否已有 LangChain / LlamaIndex 沉淀？
4. 生产要求：是否需要可视化调试、监控、缓存、流式输出、断点恢复？
5. 部署形态：自托管服务、无服务器函数，还是低代码平台？
6. 生态与维护：社区活跃度、版本更新频率、与主流模型提供商的兼容性。

一个可操作的决策路径如下：

• 如果任务有清晰的步骤和分支，且需要长期维护 → LangGraph。
• 如果任务是开放讨论型，需要多个 AI 角色协商 → AutoGen。
• 如果任务是团队流水线，角色分工清晰、追求快速交付 → CrewAI。
• 如果任务简单、模型固定、想快速接入工具 → OpenAI Agents SDK。
• 如果核心是 RAG 和数据索引 → LlamaIndex。
• 如果使用者不是开发者，需要可视化编排 → Dify 或 Coze。

五、代码实战一：LangGraph 构建状态化工具调用 Agent

下面的例子构建一个经典的“思考 + 工具调用”循环。模型先决定是否调用天气查询工具，调用后基于结果生成最终回答。整个控制流用图显式表达。

先安装依赖：

pip install langgraph langchain-openai langchain-core

from typing import Annotated, Literal
from typing_extensions import TypedDict
from langchain_core.messages import HumanMessage
from langchain_core.tools import tool
from langchain_openai import ChatOpenAI
from langgraph.graph import StateGraph, START, END
from langgraph.graph.message import add_messages
from langgraph.prebuilt import ToolNode
1. 定义共享状态：所有节点读写同一个 messages 列表
class AgentState(TypedDict):
messages: Annotated[list, add_messages]
2. 定义可被模型调用的工具
@tool
def get_weather(city: str) -> str:
"""查询指定城市的天气"""
weather_db = {"北京": "晴，23℃", "上海": "多云，26℃"}
return weather_db.get(city, "未知城市")
tools = [get_weather]
3. 绑定工具的模型
llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)
llm_with_tools = llm.bind_tools(tools)
4. 定义节点：chatbot 负责推理
def chatbot(state: AgentState):
return {"messages": [llm_with_tools.invoke(state["messages"])]}
5. 定义路由：模型请求工具就走 tools 节点，否则结束
def route_tools(state: AgentState) -> Literal["tools", "end"]:
last_message = state["messages"][-1]
if hasattr(last_message, "tool_calls") and last_message.tool_calls:
return "tools"
return "end"
6. 组装图
graph = StateGraph(AgentState)
graph.add_node("chatbot", chatbot)
graph.add_node("tools", ToolNode(tools))
graph.add_edge(START, "chatbot")
graph.add_conditional_edges("chatbot", route_tools)
graph.add_edge("tools", "chatbot")
app = graph.compile()
7. 运行
result = app.invoke({"messages": [HumanMessage(content="北京今天天气怎么样？")]})
print(result["messages"][-1].content)

这个例子的关键点在于 route_tools：它实现了“模型决定是否调用工具”的循环，而整个循环的边界由图上显式定义的边决定。如果你需要加审核节点、重试逻辑或人工确认，只需要在图上再加节点和边即可，控制流一目了然。

六、代码实战二：AutoGen 多智能体群聊协作

下面用 AutoGen 构建一个“简历优化”群聊，让 HR 专家提问、文案专家改写，用户代理充当真实用户的替身。

先安装依赖：

pip install pyautogen

from autogen import ConversableAgent, GroupChat, GroupChatManager
使用你自己的 API Key，建议通过环境变量管理
config_list = [{"model": "gpt-4o-mini", "api_key": "sk-your-key"}]
llm_config = {"config_list": config_list}
简历专家：负责提问与内容规划
resume_agent = ConversableAgent(
name="简历专家",
system_message="你是一位资深 HR，精通简历撰写，善于通过提问了解候选人的具体项目与量化成果。",
llm_config=llm_config,
human_input_mode="NEVER",
)
文案润色专家：负责把零散信息改写成简历语言
writer_agent = ConversableAgent(
name="文案润色专家",
system_message="你擅长将零散信息改写成有条理、有亮点的简历描述，语言精炼、突出量化结果。",
llm_config=llm_config,
human_input_mode="NEVER",
)
用户代理：代表真实用户发言
user_proxy = ConversableAgent(
name="用户",
llm_config=False,
human_input_mode="ALWAYS",
code_execution_config=False,
)
群聊：三个角色共同参与，最多 10 轮
group_chat = GroupChat(
agents=[user_proxy, resume_agent, writer_agent],
messages=[],
max_round=10,
)
manager = GroupChatManager(groupchat=group_chat, llm_config=llm_config)
user_proxy.initiate_chat(
manager,
message="请帮我优化一段项目经历：我负责过一个数据中台项目，主要做数据清洗和报表开发。",
)

运行后，HR 专家会先追问项目中的数据规模、技术栈、业务价值，文案专家再据此生成简历描述。你可以直观感受到“自由对话式多智能体”的协作特点。生产使用时建议设置更严格的终止条件，避免话轮失控。

七、代码实战三：CrewAI 角色分工生产内容

CrewAI 用“研究员 + 作家”两个角色完成一篇调研报告，是典型的内容生产流水线。

先安装依赖：

pip install crewai crewai-tools

from crewai import Agent, Task, Crew, Process
from crewai_tools import SerperDevTool
search_tool = SerperDevTool()
研究员角色
researcher = Agent(
role="资深技术研究员",
goal="全面调研 {topic} 的行业现状、技术方案与落地案例",
backstory="你曾在多家科技公司担任技术顾问，擅长快速提炼高质量信息。",
tools=[search_tool],
verbose=True,
allow_delegation=False,
)
作家角色
writer = Agent(
role="技术专栏作家",
goal="基于研究材料撰写一篇结构清晰、可读性强的深度报告",
backstory="你是有十年经验的技术媒体主笔，擅长把复杂概念讲得通俗易懂。",
verbose=True,
allow_delegation=False,
)
研究任务
research_task = Task(
description="调研 {topic}，整理核心概念、主流方案、优劣势和典型落地场景。",
expected_output="一份包含关键事实、数据与来源的调研笔记。",
agent=researcher,
)
写作任务
write_task = Task(
description="基于调研笔记，撰写一篇面向开发者的深度报告。",
expected_output="一篇 1500 字左右的 Markdown 格式报告。",
agent=writer,
)
顺序执行两个任务
crew = Crew(
agents=[researcher, writer],
tasks=[research_task, write_task],
process=Process.sequential,
verbose=True,
)
result = crew.kickoff(inputs={"topic": "AI Agent 框架选型"})
print(result)

这个例子的核心体验是：你几乎不用写任何“流程控制代码”，只要把角色、目标、任务描述清楚，CrewAI 就会自动安排协作顺序。对于内容生产、竞品调研、日报周报这类场景，开发效率非常高。

八、代码实战四：OpenAI Agents SDK 构建工具型 Agent

下面是 OpenAI Agents SDK 的最小可运行示例，展示函数工具如何被模型自动调用，以及 Agent Handoff 如何切换专家。

先安装依赖：

pip install openai-agents

import asyncio
from agents import Agent, Runner, function_tool
定义工具函数，docstring 会被模型用来判断何时调用
@function_tool
def calculate(expression: str) -> str:
"""计算数学表达式，例如 "2 + 3 * 4"。"""
try:
result = eval(expression)
return str(result)
except Exception as e:
return f"计算错误: {e}"
数学专家 Agent
math_agent = Agent(
name="数学助手",
instructions="你是一个数学助手。当用户提出计算问题时，调用 calculate 工具，并清晰解释结果。",
tools=[calculate],
)
主 Agent：负责分流，把数学问题交接给数学专家
triage_agent = Agent(
name="总调度",
instructions="根据用户问题判断类型：数学计算类问题交给数学助手；其他问题直接回答。",
handoffs=[math_agent],
)
async def main():
result = await Runner.run(triage_agent, "请帮我计算 (12 + 8) * 3 / 5")
print(result.final_output)
asyncio.run(main())

这个例子里有两个值得注意的设计：@function_tool 装饰器让普通 Python 函数直接变成可调用工具；handoffs 让主 Agent 能把任务移交给专家 Agent。整个模型只有几十行代码，特别适合快速原型验证。

九、实战中的五个常见坑

9.1 把多智能体当成万能解药

多 Agent 会成倍增加 Token 消耗、延迟和不确定性。很多单 Agent 加良好工具设计就能解决的问题，强行上多 Agent 反而更糟糕。建议先用单 Agent 跑通，再根据真实瓶颈决定是否拆分角色。

9.2 忽视终止条件导致死循环

AutoGen 的 GroupChat 和 LangGraph 的自定义循环都容易出现话轮失控。务必设置 max_round、最大迭代次数或明确的终止节点。

9.3 把 API Key 硬编码在代码里

示例代码为了便于阅读直接写了 Key，真实项目中请使用环境变量或密钥管理服务，避免泄露。

9.4 只看 Demo 不看生产约束

很多框架的 Demo 很短、很惊艳，但生产环境还要考虑流式输出、超时、重试、缓存、可观测性、模型降级等。LangGraph 在这些方面相对完善，轻量框架则需要自己补课。

9.5 忽视 Prompt 与结构化输出的价值

框架解决的是“编排”问题，但 Agent 效果的天花板仍然取决于 Prompt 质量、工具描述是否清晰、输出是否结构化。选型之外，打磨好这些细节往往收益更大。

十、选型决策矩阵示例

下面给出一套简单的打分方法。对每个框架按 1-5 分（5 为最优）在四个维度上打分，再根据你的业务侧重计算加权总分。示例权重为：控制流 40%、开发效率 30%、多智能体 20%、生态 10%。

维度（权重）	LangGraph	AutoGen	CrewAI	OpenAI Agents SDK
控制流确定性（40%）	5	2	3	3
开发效率（30%）	3	3	5	5
多智能体协作（20%）	4	5	4	3
生态与监控（10%）	5	4	3	3
加权总分	4.2	3.1	3.8	3.6

这个矩阵只是示意。如果你的业务是开放讨论型，把“多智能体协作”权重调高，AutoGen 的排名就会变化。核心是用这套方法把自己的优先级显式化。

十一、总结与最终建议

AI Agent 框架正在快速演进，没有哪个框架能通吃所有场景。一个务实的选型策略是：

• 先用最小场景验证：用 OpenAI Agents SDK 或 CrewAI 快速跑通原型。
• 再根据生产需要收敛：当流程复杂、需要审计和可观测性时，迁移到 LangGraph。
• 按团队能力而非热度选型：团队会什么、线上稳定运行需要什么，比框架的新功能更重要。

最后强调：框架只是“骨架”，真正决定 Agent 效果的，是你对业务的理解、工具设计的质量、Prompt 的打磨以及对失败场景的处理。建议把四个实战例子都跑一遍，再结合自己的业务写一个最小可验收的 Agent，用真实数据验证效果，选型结论自然就会清晰。