AI Agent 框架选型不踩坑：10 个主流开源方案的真实差异

先给结论：选 Agent 框架，别从 Star 数看起。先问三个问题——任务需不需要显式状态机？要不要多角色协同？团队是什么技术栈？答案基本能锁定两三个候选，剩下的差异靠小规模评测验证，不靠道听途说。

所有 Agent 都是同一套骨架

不管用哪个框架，运行时结构都差不多：感知层理解输入并拆目标，规划层做任务分解与调度，执行层负责工具调用，最后由反思层评估结果、修正错误。框架之间差异只在各层给你多少现成的轮子，以及状态怎么管理。

想明白这一点，选型焦虑能少一半：换框架换的是工程封装，不是能力上限。模型本身不行，什么框架都救不回来。

按场景分组看框架

生态型：LangChain 与 LangGraph

LangChain 的组件和集成最全，适合原型验证和工具串联。但版本问题必须先说：initialize_agent、AgentType 这套旧 Agent API 从 0.2 起标记废弃，LangChain 1.0 里已经移除，官方把 Agent 构建收敛到了 LangGraph 的 create_react_agent。网上大量教程还在教旧写法，跑不通先查版本，pip show langchain 看一眼再动手。

LangGraph 用状态图组织流程：节点即函数，边即流转，支持断点调试和状态回溯。需要条件分支、人工审批这类复杂流转时，它比链式调用稳得多。

from typing import TypedDict
from langgraph.graph import StateGraph, END

class State(TypedDict):
    messages: list

def research(state: State) -> State:
    state["messages"].append("研究完成")
    return state

def review(state: State) -> State:
    state["messages"].append("审核完成")
    return state

g = StateGraph(State)
g.add_node("research", research)
g.add_node("review", review)
g.add_edge("research", "review")
g.add_edge("review", END)
app = g.compile()

自主型：AutoGPT

自动拆解任务、自我迭代的开创者。但现在要重新认识它：项目重心已转向 AutoGPT Platform，把 Agent 做成了低代码搭建平台，早期纯 autonomous 模式不再是主打。想要长周期无人值守任务，先评估平台形态是否符合工程预期，别按老文章的理解直接上。

协作型：CrewAI 与 MetaGPT

CrewAI 按角色定义 Agent，任务之间带依赖，几行代码就能搭出产品经理到开发到测试的流水线，新版本还提供了 Flows 做确定性流程编排，且已经不再依赖 LangChain，依赖树干净了不少。

MetaGPT 的思路是把软件公司的 SOP 固化进框架：输入一句需求，输出 PRD、架构文档、代码和测试用例。文档驱动的输出质量是它的卖点，适合要标准化产出的团队。

from crewai import Agent, Task, Crew

pm = Agent(role="产品经理", goal="输出需求文档",
           backstory="资深产品经理，擅长需求拆解")
dev = Agent(role="开发工程师", goal="按文档实现核心功能",
            backstory="十年后端经验，熟悉主流框架")

t1 = Task(description="分析需求并输出 PRD", expected_output="PRD 文档", agent=pm)
t2 = Task(description="按 PRD 实现核心功能", expected_output="核心代码",
          agent=dev, context=[t1])

Crew(agents=[pm, dev], tasks=[t1, t2]).kickoff()

微软系：AutoGen 与 Semantic Kernel

AutoGen 适合对话式多智能体，支持人类专家中途介入。注意 0.4 版本做了全面重写，改成事件驱动架构，包也拆成 autogen-agentchat 等，0.2 的代码不能平滑迁移，老教程参考价值有限。Semantic Kernel 面向企业级场景，支持 C#、Python、Java，与 Azure OpenAI 集成深，.NET 团队基本没有第二选择。

轻量与研究型：Swarm 与 CAMEL

OpenAI 的 Swarm 是实验项目，代码极少，适合学概念。它已被官方 Agents SDK 接棒，新设计别再压在 Swarm 上。顺带纠一个流传很广的错误写法：官方包名是 swarm，不是 openai_swarm，很多文章的 import 直接抄错。CAMEL 出自 KAUST 的研究团队，主打角色扮演对话与决策可解释性，适合做研究基线，不适合直接上生产。

框架速览：

框架	上手难度	协作能力	典型场景
LangChain	中	中	原型、多工具串联
LangGraph	中高	中	复杂状态流转、可回溯流程
AutoGPT	低	中	平台化低代码搭建
CrewAI	低	强	多角色分工流水线
MetaGPT	中	强	文档驱动的软件开发全流程
AutoGen	中	强	对话式协作、人类介入
Semantic Kernel	中	中	.NET/企业级集成
Swarm	低	中	概念学习（已被 Agents SDK 接棒）
CAMEL	高	中	学术研究基线

依赖与版本的坑，比选型本身更耗时

实测最容易翻车的不是框架对比，是依赖冲突。LangChain 0.0.x 老版本和 pydantic v2 混装，会报 ImportError: cannot import name ‘FieldInfo’ from ‘pydantic.fields’ 一类的错误，不少老项目就卡死在这里。解法二选一：全量升级到 langchain 0.3 以上，或者锁 pydantic<2。另外 API key 没配好时，openai 库直接抛 OpenAIError，报错不会提示该配哪个环境变量，别把时间浪费在排查框架上。

选型前先做小评测

固定 10 个有代表性的任务（覆盖工具调用、多轮修正、失败恢复），每个候选框架跑一遍，记录三件事：任务成功率、token 消耗、人工干预次数。半天的评测比看一周文章管用。动评测前先核环境：pip show langchain langgraph crewai autogen-agentchat，把版本摸清楚再开跑。