从 ReAct 到 MCP：一文看懂主流 Agent 框架的演化与差异

如果说 2023 年是大模型元年，那 2024–2026 这三年就是 Agent 框架的寒武纪大爆发。

短短三年里，从一篇论文里的 ReAct，到 AutoGPT 把自主性拉到极限，再到 LangChain / LangGraph / LlamaIndex 这一批"基础设施型"框架成熟，再到 AutoGen / CrewAI / MetaGPT 把多智能体协作搬上舞台，最后是 OpenAI、Anthropic、Microsoft 三大巨头各自下场推 SDK，加上 MCP / A2A 协议把整个生态串起来——Agent 框架的形态、抽象层次、设计哲学都在剧烈演化。

对开发者来说，问题已经不是"要不要做 Agent"，而是：

这么多框架，到底有什么区别？我该用哪个？它们的设计思路又是怎么演化过来的？

这篇文章试图把主流 Agent 框架按照一条清晰的演化主线串起来，对比它们的核心抽象、适用场景，最后给出一套可以照着用的选型原则。

---

一、思想原点：ReAct，让 LLM 学会"边想边做"

故事要从 2022 年 10 月那篇被引爆的论文 ReAct: Synergizing Reasoning and Acting in Language Models 说起。

在 ReAct 之前，让大模型解决复杂任务有两条路：要么纯靠 Chain-of-Thought 推理（不会动手），要么纯靠工具调用（不会思考）。ReAct 的洞察非常简单——让推理和行动交错进行：

Thought: 我需要先查一下今天的汇率
Action: search("USD to CNY today")
Observation: 1 USD = 7.18 CNY
Thought: 拿到了，下一步算总价...
Action: calculate(100 * 7.18)
Observation: 718
Thought: 我可以回答用户了
Final Answer: 100 美元约等于 718 人民币

这个 Thought → Action → Observation 的循环，就是后来几乎所有 Agent 框架的"最小核"。LangChain 里的 AgentExecutor、LlamaIndex 里的 ReActAgent、OpenAI Function Calling 的内层循环、Claude 的 Tool Use……骨子里都是 ReAct。

ReAct 没有一个独立的"框架"工程，但它确立了 Agent 的思维范式：Agent 不是一次性输出答案的函数，而是一个带状态的迭代循环。理解了这一点，后面所有框架的设计思路都可以顺着这条主线读下去。

---

二、自主任务分解：AutoGPT / BabyAGI 的激进实验

ReAct 解决了"单步推理 + 单步行动"的协同，但它本质上还是被一个 prompt 驱动的。2023 年 3–4 月，AutoGPT 和 BabyAGI 把这件事推到了极端：给我一个目标，让 Agent 自己拆任务、自己执行、自己迭代。

AutoGPT 的循环比 ReAct 多了两层：

• Planning 层：把大目标拆成子任务列表
• Execution 层：对每个子任务跑一遍 ReAct 循环
• Self-criticism 层：Agent 反过来评价自己刚才做得怎么样，决定要不要回炉重造

这套思路在演示视频里看着很酷——“让它自己写一份市场调研报告”，看着 Agent 啪啪啪地浏览网页、写代码、自我反思——但真正动手用过的人都知道：它非常烧钱、非常容易跑偏、非常难调试。

AutoGPT 的历史价值在于它第一次把 Agent 的自主性推到极限，让所有人意识到：完全自主和完全可控是 Agent 设计的两端，中间需要一个工程化的折中方案。这个折中方案，就是 LangChain 接下来要做的事。

---

三、把 LLM 应用做成乐高：LangChain 与"链"的抽象

LangChain 是大多数开发者第一个接触的 Agent 框架，它的核心抽象只有一个字：链（Chain）。

一个典型的 LangChain 应用长这样：

chain = (
    PromptTemplate.from_template("把下面内容翻译成中文：{text}")
    | ChatOpenAI(model="gpt-4o-mini")
    | StrOutputParser()
)
chain.invoke({"text": "Hello world"})

那个 | 管道符（LCEL，LangChain Expression Language）就是 LangChain 的灵魂——把一切都变成"输入 → 处理 → 输出"的 Runnable，然后用管道连起来。Prompt 模板是一段 Runnable、LLM 调用是一段 Runnable、Output Parser 是一段 Runnable、RAG 检索器是一段 Runnable、甚至 Agent 也是一段 Runnable。

这种"一切皆可拼装"的设计带来了两个巨大的好处：第一，生态爆炸，LangChain 内置了几百个集成（向量库、模型、工具、Loader），随用随接；第二，抽象统一，同步、异步、流式、批处理，全都用同一套接口表达。

但 LangChain 从 2023 年下半年开始也饱受争议，最大的吐槽是"封装太深、调试困难"。当一个链路里嵌套了 5 层 Chain、3 个 Agent、2 个 Memory，出错了你根本不知道是哪一层的 prompt 被偷偷改了。

更深层的问题是：链是单向的。但 Agent 天生需要"循环、回退、人工介入、多分支"——这些用链来表达就非常别扭。于是 LangChain 团队自己做了下一代框架：LangGraph。

---

四、专精 RAG 的另一条路：LlamaIndex

跟 LangChain 几乎同一时间起步，但走了截然不同路线的，是 LlamaIndex（前身 GPT Index）。

如果说 LangChain 想做"LLM 应用的瑞士军刀"，LlamaIndex 一开始的目标就非常聚焦：把私有数据接到 LLM 上。它的核心抽象不是链，而是 Index（索引）+ Query Engine（查询引擎）+ Retriever（检索器）：

documents = SimpleDirectoryReader("data/").load_data()
index     = VectorStoreIndex.from_documents(documents)
query_engine = index.as_query_engine()
print(query_engine.query("我们公司去年的营收是多少?"))

LlamaIndex 在 RAG 这件事上做得非常深：

• 多种索引结构：向量索引、关键词索引、树索引、知识图谱索引、SQL 索引……
• 进阶检索：HyDE、Sub-question、Recursive Retrieval、Auto-merging Retriever
• 数据连接器（LlamaHub）：上百种数据源（Notion、Slack、Jira、PDF、SQL……）开箱即用

到 2024 年，LlamaIndex 也补齐了 Agent 能力（llama-index-agent），但它最强的护城河仍然在 RAG。一句话总结两者关系：LangChain 是大而全的工具箱，LlamaIndex 是 RAG 优化的专家。如果你的核心场景是"让 LLM 读懂大量私有文档"，先看 LlamaIndex；如果是"复杂 Agent 编排 + 多种集成"，再看 LangChain / LangGraph。

---

五、从"链"到"图"：LangGraph 的状态机思维

LangGraph 是 LangChain 团队 2024 年推出的"面向 Agent 的编排框架"。它把 LangChain 那套"链"的抽象升级成了"图"：

• 每个**节点（Node）**是一个函数（可以调用 LLM、调用工具、做任何事）
• 每条**边（Edge）**决定下一步去哪个节点（可以是固定的，也可以由 LLM 动态决策）
• 整个图共享一个状态（State），每次节点执行都是对状态的一次更新

from langgraph.graph import StateGraph

graph = StateGraph(AgentState)
graph.add_node("plan", planner)
graph.add_node("execute", executor)
graph.add_node("reflect", reflector)
graph.add_edge("plan", "execute")
graph.add_conditional_edges(
    "execute",
    should_continue,  # 由 LLM 判断是继续还是结束
    {"continue": "reflect", "end": END}
)
graph.add_edge("reflect", "execute")

这种**状态图（State Machine）**的抽象一下子解决了链结构搞不定的几件事：

• 循环：execute → reflect → execute 天然就是个环
• 分支：add_conditional_edges 让 LLM 当路由
• 断点续跑：状态可以序列化、持久化（LangGraph Checkpointer），Agent 跑一半挂了可以从上一个检查点继续
• Human-in-the-loop：在某个节点暂停，等待用户确认再继续
• Time-travel：可以回到任意历史状态重新分支跑

LangGraph 现在是 LangChain 团队主推的方向，复杂 Agent（Deep Research、Coding Agent、Workflow Agent）几乎都迁移到 LangGraph 上来。它的设计哲学也回答了 AutoGPT 留下的难题：自主性不应该是 prompt 里的暗示，而应该是图结构里的显式编排。

---

六、多智能体协作：从单兵到军团

ReAct 解决了"一个 Agent 怎么做事"，但很多真实问题是一个 Agent 搞不定的——你需要一个写代码的、一个做测试的、一个 Code Review 的、一个写文档的，他们各司其职、互相协作。

这就是多智能体（Multi-Agent）框架登场的舞台。这个赛道的主流玩家有四家，思路各不相同。

AutoGen（Microsoft Research）：会话即编排

AutoGen 把 Agent 协作建模成对话。每个 Agent 是一个会说话的角色，开发者定义"谁可以和谁说话"、“什么时候停”，剩下的交给 LLM。

user_proxy = UserProxyAgent("user")
coder = AssistantAgent("coder", system_message="你是一名 Python 工程师")
reviewer = AssistantAgent("reviewer", system_message="你是代码审查员")

groupchat = GroupChat([user_proxy, coder, reviewer], messages=[])
manager = GroupChatManager(groupchat)
user_proxy.initiate_chat(manager, message="实现一个快排")

AutoGen 的优势是灵活、研究友好——非常适合做 Agent 协作模式的实验。最新的 AutoGen v0.4 已经把抽象重写成了事件驱动的分布式架构（actor model），往生产级走了一大步；同时官方也明确把"工程化升级版"交棒给了下文要讲的 Microsoft Agent Framework。

CrewAI：角色 + 任务 + 流程

CrewAI 的抽象更贴近"真实公司"：你定义一群 Agent（角色）、一组 Task（任务），然后选一个 Process（流程）——顺序执行还是层级管理。

researcher = Agent(role="研究员", goal="...", tools=[search])
writer    = Agent(role="作家",   goal="...")

task1 = Task(description="调研 X", agent=researcher)
task2 = Task(description="基于调研写文章", agent=writer)

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

CrewAI 上手极快，配置式的 API 对非资深开发者很友好。它的定位非常清晰：给业务团队搭可解释的多 Agent 流水线。但灵活性不如 AutoGen 和 LangGraph，复杂场景容易撞墙。

MetaGPT：把 SOP 写进框架

MetaGPT 是把"软件公司 SOP"直接编码成框架的一次激进尝试——一句需求进，一份 PRD、设计文档、代码、测试用例出。

它内置了产品经理、架构师、工程师、QA 等角色，每个角色按照固定的 SOP 输出标准化的工作产物（PRD → 系统设计 → API 设计 → 代码）。这种强工艺约束让生成结果稳定可复用，但代价是领域绑死——MetaGPT 适合做软件开发类任务，换一个场景就要重写大半。

Swarm：极简 Handoff

OpenAI Swarm 是 OpenAI 早期开源的实验性多 Agent 框架，核心抽象只有两个：Agent 和 Handoff。Agent 之间通过返回另一个 Agent 实例来"交棒"，没有中央 Manager、没有 GroupChat，越简单越好。Swarm 后来演化成了官方支持的 OpenAI Agents SDK（见下一节），把 Handoff 思想做成了生产级。

---

七、巨头下场：原厂 SDK 时代

到 2024 年下半年，三大模型厂商几乎同时意识到一件事：与其让生态各自卷框架，不如自己出一套官方 SDK。这是 Agent 框架最近一年最重要的趋势。

OpenAI Agents SDK：轻量、原生、链路可观测

OpenAI Agents SDK 是 Swarm 的"生产级继承者"，核心原语只有几个：Agents（角色）、Tools（工具）、Handoffs（交接）、Guardrails（安全护栏）。它最大的优势是和 OpenAI Responses API / Tracing 深度绑定——你写完一个 Agent，直接在 OpenAI 后台就能看到完整的执行轨迹、tool call、token 消耗。

agent = Agent(
    name="Assistant",
    instructions="You are a helpful assistant",
    tools=[search_tool],
    handoffs=[escalation_agent],
)
result = await Runner.run(agent, "帮我查一下今天天气")

适合的场景：确定要用 OpenAI 模型、想最快把 Agent 跑起来、需要一流的可观测性。代价是供应商锁定——切到别的模型要做适配。

Claude Agent SDK：把 Claude Code 的能力开放给开发者

Claude Agent SDK（2025 年由 Claude Code SDK 改名而来）是 Anthropic 的官方 SDK。它最特别的地方是把驱动 Claude Code 的整套基础设施暴露给开发者：

• Subagents：用 query() 调用隔离的子 Agent，主上下文不污染
• Sessions：通过 session_id 持久化会话状态
• 自动上下文压缩：长对话自动 compact，不用手动管 token
• 沙箱执行：内置文件系统/Bash 的隔离执行环境（Claude 在自家产品里就这么用）
• MCP 原生支持：天然能挂载任意 MCP Server

它的取舍非常清晰：牺牲模型自由度，换 Claude 生态里最丝滑的 Agent 体验——尤其适合做 Coding Agent、长任务 Agent。延伸阅读：Anthropic 工程博客 · How we contain Claude。

Microsoft Agent Framework（MAF）：企业级正规军

Microsoft Agent Framework（2025 年发布）是微软把 AutoGen + Semantic Kernel 合二为一的产物。一句话定位：把 Agent 从原型推到生产。

核心特性：

• 双语言一等公民：Python 和 C#/.NET 同一套 API，企业 .NET 栈终于不再被 LangChain 卡脖子
• 图编排：sequential / concurrent / handoff / group 四种内置 pattern
• 企业级能力：OpenTelemetry 追踪、checkpointing、time-travel、human-in-the-loop、Azure Functions / Durable Task 托管
• 声明式 Agent：YAML 定义，运维友好
• 官方迁移指南：从 AutoGen 和 Semantic Kernel 都有平滑迁移路径

适合的场景：企业级 Agent 上线——要合规、要可观测、要可恢复、要跨语言、要进 Azure 体系。这条路 LangGraph 也能走，但 MAF 在企业场景下的"开箱齐全度"明显更高。延伸阅读：Introducing Microsoft Agent Framework。

---

八、协议时代：MCP 与 A2A

到 2024 年，Agent 生态遇到了一个新瓶颈：集成爆炸。每接一个工具（数据库、Slack、Jira、文件系统、浏览器……），就要在每个框架里写一套适配；每个框架又有自己的工具协议，互不兼容。这件事像极了 USB 出现之前的世界——每个外设一根专属线。

Anthropic 在 2024 年 11 月推出 MCP（Model Context Protocol），目标就是"Agent 工具调用的 USB-C"：

• 一次实现，处处可用：MCP Server 写一遍，所有 MCP 客户端（Claude、Cursor、Windsurf、QoderWork 等）都能用
• 三类标准化能力：Resources（资源）、Tools（工具）、Prompts（提示词模板）
• 基于 JSON-RPC over stdio/SSE：传输层简单，可在本地或云端跑

MCP 在 2025 年迅速被各大主流 IDE 和 Agent 平台支持，目前已经有上千个开源的 MCP Server。

与此同时，Google 等公司提出了 A2A（Agent-to-Agent Protocol），关注的是另一个层面：Agent 之间怎么互相发现、互相委托任务。MCP 解决"Agent 怎么用工具"，A2A 解决"Agent 怎么用 Agent"——这两个协议正在共同把 Agent 生态从孤岛推向网络。

协议层的成熟，标志着 Agent 框架开始从"框架内卷"走向"框架解耦"：你完全可以用 LangGraph 编排核心逻辑，调用一堆 MCP Server 提供的工具，跨 Agent 协作走 A2A——框架不再是大一统，而是可拼装的层。

---

九、横向对比：到底该选哪个？

下面这张表把目前主流的 11+ 个框架/SDK 按统一维度排开。核心抽象回答"它把世界建模成什么"，自主程度和控制粒度反映自主性—可控性的权衡。

框架	出品方	核心抽象	自主	控制粒度	单/多	上手	模型自由度	典型场景
ReAct	论文/范式	TAO 循环	中	细	单	★★	任意	所有工具型 Agent 的内核
AutoGPT / BabyAGI	社区	目标驱动循环	极高	粗	单	★	任意	演示、自动化探索
LangChain	LangChain	Runnable 链	中	中	单	★★	任意	RAG、Prompt 管道
LlamaIndex	LlamaIndex	Index + Retriever	中	中	单	★★	任意	数据密集 RAG
LangGraph	LangChain	状态图	中→高	极细	单/多	★★★★	任意	复杂可控 Agent
AutoGen	MS Research	会话式协作	高	中	多	★★★	任意	多 Agent 研究
CrewAI	CrewAI	Role+Task+Process	中	中	多	★★	任意	业务流水线
MetaGPT	DeepWisdom	SOP 驱动	中	细（领域内）	多	★★★	任意	软件开发自动化
OpenAI Agents SDK	OpenAI	Agent + Handoff	中	细	多	★★	仅 OpenAI	OpenAI 生态、强可观测
Claude Agent SDK	Anthropic	Subagents + Sessions	中→高	细	多	★★	仅 Claude	Coding/长任务 Agent
MAF	Microsoft	图编排 + 中间件	中→高	极细	多	★★★	多供应商	企业级生产 Agent
MCP / A2A	Anthropic / Google	协议	—	—	—	★★	—	工具/Agent 互联标准

---

十、选型原则：先定坐标，再选框架

看着上面这张表，估计你和我第一次看的时候反应差不多：“全是优点，到底选哪个?”

我自己摸索出的一套选型原则，按重要性从高到低排：

原则一：从场景出发，不从框架出发

• 数据密集 RAG 优先 → LlamaIndex（专业对口，别用 LangChain 硬凑）
• 单 Agent 工具调用 → OpenAI SDK / Claude SDK（原厂最顺手）
• 复杂可控的长流程 Agent → LangGraph / MAF（状态图天生为此而生）
• 多角色业务协作（市场分析、报告生成） → CrewAI（配置即编排）
• 企业级生产、要合规可观测 → MAF（开箱齐全）
• 研究多 Agent 协作模式 → AutoGen（最灵活、社区最活跃）
• 端到端软件开发自动化 → MetaGPT 或基于 LangGraph 自研

原则二：模型策略决定框架自由度

• 已锁定 OpenAI → OpenAI Agents SDK，原生 Tracing 一步到位
• 已锁定 Claude → Claude Agent SDK，Subagents + Session + 沙箱直接吃
• 多模型/未来要切换 → LangGraph / MAF / AutoGen，避免供应商绑定
• 完全本地化（Ollama / vLLM）→ LangChain / LangGraph 生态最齐全

原则三：技术栈对齐

• 纯 Python 团队 → 选项最多，全部主流框架都能用
• .NET / C# 团队 → MAF（Semantic Kernel 嫡系，几乎是唯一一等公民选择）
• 前端 / Node.js 团队 → LangChain.js + Vercel AI SDK
• 业务团队（非资深开发） → CrewAI 或低代码（Langflow / Dify）

原则四：协议先行，框架可换

最近半年最重要的认知转变是：别把核心能力绑死在某一个框架上。把工具层走 MCP、把跨 Agent 调度走 A2A，框架本身就成了可替换的"编排层"。今天用 LangGraph，明天 MAF 更香了切过去——业务代码改动会小很多。

原则五：从最小可用开始，别一上来就上重武器

LangChain 团队自己也建议过：新项目直接从 LangGraph 开始，反而比从 LangChain 起步再迁移更顺。同理，如果一个简单的 ReAct loop + Function Calling 就能搞定，先别请 CrewAI / MetaGPT 这种"重型框架"出场。

一句话总结：场景定方向 → 模型定边界 → 技术栈定细节 → 协议留后路 → 最小可用先上。

十一、设计哲学的演化主线

把这些框架放在一起回看，可以总结出一条清晰的演化主线：

第一阶段（思想期，2022–2023）：核心是回答"Agent 是什么"。ReAct 给出了答案——Agent 是带状态的"思考-行动-观察"循环。

第二阶段（链与索引，2023）：核心是回答"LLM 应用怎么写"。LangChain 用链做通用拼装，LlamaIndex 用索引深耕 RAG，两条赛道并行。

第三阶段（图与状态，2024）：核心是回答"复杂 Agent 怎么控制"。LangGraph 用状态图取代链，把循环、分支、人工介入显式化。

第四阶段（多智能体，2024）：核心是回答"Agent 怎么协作"。AutoGen 选会话、CrewAI 选角色、MetaGPT 选 SOP、Swarm 选极简 Handoff——四种思路，对应四种业务形态。

第五阶段（原厂 SDK，2025）：核心是回答"模型厂自己怎么定义 Agent"。OpenAI Agents SDK / Claude Agent SDK / Microsoft Agent Framework 三足鼎立，各自把"自家最优解"沉淀成框架。

第六阶段（协议化，2024–2026）：核心是回答"生态怎么互通"。MCP 和 A2A 把工具调用和 Agent 协作从框架内嵌升级成跨框架协议，让生态从孤岛走向网络。

每一步演化都不是凭空出现的，而是被前一阶段暴露出的痛点逼出来的。理解这条主线，比记住每个框架的 API 重要得多——因为框架还会迭代，但**“让 Agent 越来越可控、越来越可组合、越来越能协作”**这个方向，短期内不会变。

---

写在最后

如果你只能记住一句话，那就是：Agent 框架的本质，是在"自主性"和"可控性"之间找平衡。

ReAct 给了循环，AutoGPT 把自主拉满，LangChain / LlamaIndex 把可控拉满（但灵活度下降），LangGraph 找到了"显式编排 + 局部自主"的甜点，多智能体框架把这套思路扩展到团队协作，原厂 SDK 把厂内最佳实践直接打包，MCP 和 A2A 让所有人共享同一个工具/协作底座。

下一阶段会发生什么？大概率是 Agent 操作系统的出现——更轻的运行时、更标准的协议、更强的安全沙箱、跨设备跨云的 Agent 调度。但无论怎么演化，今天我们梳理的这条主线，都会是理解未来 Agent 世界的一把钥匙。

框架来来去去，思想代代相传。
选框架的时候，别只看 GitHub Star，多想一想：它解决了上一代框架的哪个痛点？

如果这篇对你有帮助，欢迎点个"在看"，也欢迎在评论区聊聊你正在用哪个 Agent 框架，踩过哪些坑。下次我们可以挑一两个框架做更深入的源码拆解。

参考资料

• Bright Data · Best AI Agent Frameworks (2026)
• AgentGuide · frameworks.md
• r/LangChain · Comprehensive Comparison of Every AI Agent Framework
• Microsoft Azure Blog · Introducing Microsoft Agent Framework
• Anthropic Engineering · How we contain Claude