AI Agent 框架大乱斗：2025 年主流选择指南（万字拆解）

weixin_56622231

44人浏览 · 2026-07-16 18:30:07

weixin_56622231 · 2026-07-16 18:30:07 发布

写在前面：现在到底有多少种 Agent 框架？

先说个段子。

2023 年的时候，你跟别人说“我在搞 AI Agent”，对方大概率会问：“Agent 是啥？”

到了 2025 年，你再这么说，对方会问：“你用哪个框架？”

这变化也就一年多。AI Agent 从一个学术概念变成了“人均一个 Agent”的局面，而背后撑起这波浪潮的，是层出不穷的 Agent 开发框架。

但问题来了——框架太多了。

LangChain、LlamaIndex、Semantic Kernel、CrewAI、AutoGen、Dify、Coze、Agno、Agents SDK、Anthropic MCP……光把这些名字念完就要喘口气。

很多开发者（尤其是刚入坑的）会陷入一种**“框架 FOMO”**：生怕自己选错了、学亏了，于是每个都去看一眼，结果每个都没深入，最后啥也没做成。

这篇文章的目的很简单——帮你搞清楚这些框架到底是什么、适合什么人、它们的 Github 仓库在哪，以及最重要的：你到底该选哪个。

我不会搞那种“优劣势对比表”的八股文，咱们就像朋友聊天一样，把这些框架一个个扒清楚。

1. 先搞清楚：Agent 框架到底在解决什么问题？

在聊具体框架之前，得先把一个问题说清楚——没有框架能不能写 Agent？

答案是可以，而且不难。

你直接调 OpenAI 的 API，给模型一个 system prompt，告诉它“你可以调用这些工具”，然后写个 while 循环让模型自己决定什么时候停——这就是一个最原始的 Agent。

# 极简版 Agent（不到 30 行）
import openai

def simple_agent(user_query):
    messages = [{"role": "system", "content": "You can use these tools: search, calculate..."},
                {"role": "user", "content": user_query}]
    
    while True:
        response = openai.chat.completions.create(
            model="gpt-4",
            messages=messages,
            tools=[...]  # 工具定义
        )
        msg = response.choices[0].message
        
        if msg.tool_calls:
            # 执行工具调用，结果塞回对话
            for tc in msg.tool_calls:
                result = execute_tool(tc.function.name, tc.function.arguments)
                messages.append({"role": "tool", "content": result, ...})
        else:
            return msg.content  # 模型觉得可以停了

那为什么还需要框架？因为上面的代码在你做第二个 Agent 的时候就会变成一坨屎山。

框架真正解决的问题是这些：

你遇到的问题	框架给的方案
工具调用逻辑越写越复杂	统一的 Tool 抽象和注册机制
上下文窗口不够用	内置记忆管理、摘要压缩
要连数据库、向量库、API……	现成的集成组件，拿来就用
Agent 间的协作和编排	多 Agent 调度、工作流编排
调试 Agent 行为像解谜	可视化 Trace、日志、Playground
部署到生产环境	服务化、监控、权限管理

说白了，框架就是把老手踩过的坑填平了，让后来的人不用再踩一遍。

2. 框架全景图：一张图看懂生态位

在开始逐个深扒之前，先用一张图看清这些框架各自站在什么位置。

这张图可能会让人觉得 LangChain 像个“水电煤”一样无处不在，但它的生态位确实如此——大量上层框架都在它上面搭建。

不过到了 2025 年，很多框架开始“去 LangChain 化”（比如 CrewAI 的底层已经在逐步替换），这是后话。

3. 基础框架：搭 Agent 的积木

这层框架不直接帮你做“多 Agent 协作”，它们解决的是更底层的问题——怎么让 LLM 调用工具、管理记忆、处理 RAG、连接外部数据。

3.1 LangChain：生态之王，也是“被喷之王”

Github： https://github.com/langchain-ai/langchain

一句话总结： 它是 AI 应用开发框架里的“瑞士军刀”，什么都能干，但也因为啥都能干所以显得臃肿。

LangChain 的江湖地位比较有意思——用的人最多、骂的人也最多。

为什么骂？几个经典槽点：

抽象地狱： 你想改一个 prompt 模板，要穿越 3 层继承链才能找到真正传参的地方。
版本狂魔： 0.1 → 0.2 → 0.3 的升级经常 breaking change，你半年前写的代码现在跑不起来了。
过度封装： 明明 5 行 requests 能搞定的事，它给你搞出个 LLMChain + PromptTemplate + OutputParser 的组合拳。

但为什么大家还在用？因为它生态实在是太强了：

几百个集成组件，从数据库到向量库到各种 LLM 提供商，基本你能想到的它都有。
LangSmith 做调试和追踪体验不错。
LangGraph（后面会细讲）在 Agent 编排这块很能打。
社区庞大，遇到问题搜一下基本有答案。

适合谁：

快速原型开发，依赖生态多的时候
团队里有用过的人，能帮你避开那些坑
需要连接各种五花八门的数据源和工具

不适合谁：

追求极简和可控的开发者（你会被气到）
生产环境对性能敏感的场景（它的调用链开销不小）

一个小建议：如果你决定用 LangChain，直接从 LCEL（LangChain Expression Language）入手，别去看那些 Chain 的老教程了，那是弯路。

仓库地址（注意是 monorepo）：

主库：https://github.com/langchain-ai/langchain
LangGraph：https://github.com/langchain-ai/langgraph
LangSmith（官方调试平台）：https://smith.langchain.com

3.2 LlamaIndex：数据 Agent 的正解

Github： https://github.com/run-llama/llama_index

一句话总结： 如果你的 Agent 重度依赖检索和数据处理，LlamaIndex 比 LangChain 香多了。

很多人的误区是把 LlamaIndex 当成“另一个 LangChain”，但实际上它们的出发点完全不一样：

LangChain 的基因是“链式调用”：把 LLM 调用和工具调用串成链条。
LlamaIndex 的基因是“数据索引”：怎么把各种数据（文档、数据库、API）高效地索引和检索。

这个基因差异导致了一个有意思的结果：如果你的 Agent 需要大量“先查资料再回答”的逻辑，LlamaIndex 的体验远好于 LangChain。

它的核心概念：

Ingestion（摄入）： 把 PDF、网页、数据库记录等加载进来
Indexing（索引）： 构建向量索引、知识图谱索引等
Querying（查询）： 基于索引做问答、摘要、Agent 式查询

到 2025 年，LlamaIndex 也发展出了自己的 Agent 体系，而且思路比 LangChain 更“数据优先”——它会先规划需要检索什么数据，再去执行。

# LlamaIndex 的 Agent 示例（简洁得像假代码）
from llama_index.core.agent import FunctionCallingAgent
from llama_index.core.tools import QueryEngineTool

# 把你的数据查询引擎包装成工具
tool = QueryEngineTool.from_defaults(
    query_engine=your_index.as_query_engine(),
    name="company_docs",
    description="查询公司内部文档"
)

agent = FunctionCallingAgent.from_tools([tool])
response = agent.chat("我们公司今年的 KPI 完成情况如何？")

适合谁：

Agent 的核心任务是“从一堆数据里找答案”
需要构建 RAG 类应用
对数据索引和检索质量有较高要求

仓库： https://github.com/run-llama/llama_index

3.3 Semantic Kernel：微软的亲儿子，.NET 生态的首选

Github： https://github.com/microsoft/semantic-kernel

一句话总结： 如果你在微软技术栈（C#/.NET/Azure）里，这个框架是首选，不用纠结。

Semantic Kernel（简称 SK）是微软推出的 AI 编排框架。它的定位和 LangChain 有些重叠，但设计哲学不太一样：

Kernel 模式： 把 AI 能力当成操作系统的“内核”，插件是“驱动”。
Planner 概念： 让 LLM 自己规划怎么组合插件完成复杂任务。
多语言支持： C#、Python、Java 都有 SDK。

SK 有一个设计我挺喜欢的——它把“连接外部服务”和“定义 AI 行为”分得很开。 你定义一个 Plugin，它既可以给 AI 调用，也可以给传统代码调用，不用绑死在 LLM 链路上。

// C# 示例：定义一个插件
public class TimePlugin
{
    [KernelFunction("get_current_time")]
    [Description("获取当前时间")]
    public string GetCurrentTime() => DateTime.Now.ToString();
}

// 注册到 Kernel
var kernel = Kernel.CreateBuilder()
    .AddAzureOpenAIChatCompletion(deploymentName, endpoint, apiKey)
    .Build();
kernel.Plugins.AddFromType<TimePlugin>();

适合谁：

.NET / Azure 技术栈的团队
企业级应用，需要和微软生态深度集成
想要那个“企业级支持”的安全感

仓库： https://github.com/microsoft/semantic-kernel

3.4 OpenAI Agents SDK：官方的“反框架”框架

Github： https://github.com/openai/openai-agents-python

一句话总结： 如果你只用 OpenAI 的模型，这个官方 SDK 是最轻量的选择，没有之一。

OpenAI 在 2025 年初发布的 Agents SDK，本质上是对他们 API 能力的封装。它的设计理念是“我不管你们框架怎么搞，反正你要调我 API 的话就用这个最方便。”

这个 SDK 有几个特点：

极简： 没有抽象的抽象，基本就是把你手写的 while 循环包装了一下。
Tracing 内置： 调试 Agent 执行链路非常直观。
Swarm 模式： 可以轻松做多 Agent 的 handoff（交接），A Agent 干不下去了把对话交给 B Agent。

# Agents SDK 示例
from agents import Agent, Runner, WebSearchTool

agent = Agent(
    name="Research Agent",
    instructions="你是一个研究助手，帮助用户查找信息。",
    tools=[WebSearchTool()],
)

result = Runner.run_sync(agent, "查一下 LangChain 最新版本是多少")
print(result.final_output)

适合谁：

深度绑定 OpenAI 生态的团队
想要极致简洁、不想被框架绑架的开发者
快速做 Agent 原型验证

不适合谁：

需要兼容多个 LLM 提供商的场景
需要复杂的工具集成生态

仓库： https://github.com/openai/openai-agents-python

4. 编排框架：让多个 Agent 协作的指挥部

前面那些框架解决的是“一个 Agent 怎么工作”的问题。但当你的需求变成了“三个 Agent 分工协作完成一个任务”时，就需要编排层了。

这就好比搭积木——基础框架是“单个积木块”，编排框架是“图纸”，告诉你怎么把这些积木拼成一座城堡。

4.1 LangGraph：把 Agent 画成流程图

Github： https://github.com/langchain-ai/langgraph

一句话总结： 如果你喜欢“一切皆图”的思维，LangGraph 是目前最灵活的编排方案。

LangGraph 是 LangChain 团队在发现“Chain 模式不够灵活”之后推出的方案。它把 Agent 的执行流程建模成一个有向图（DAG 甚至循环图）：

Nodes（节点）： 执行具体操作的步骤（调 LLM、调工具、判断条件）。
Edges（边）： 节点之间的流转规则。
State（状态）： 在整个图中共享的数据。

这个模型的好处是极其灵活——你可以设计任意复杂的 Agent 逻辑：

循环执行直到满足条件
多路并行然后汇聚
根据中间结果动态决定下一步

# LangGraph 的一个简单 Agent 图
from langgraph.graph import StateGraph, END

# 定义状态
class AgentState(TypedDict):
    messages: list
    next_step: str

# 定义节点
def call_model(state):
    response = model.invoke(state["messages"])
    return {"messages": state["messages"] + [response]}

def should_continue(state):
    last_message = state["messages"][-1]
    if last_message.tool_calls:
        return "call_tools"
    return "end"

# 构建图
workflow = StateGraph(AgentState)
workflow.add_node("agent", call_model)
workflow.add_node("tools", execute_tools)
workflow.set_entry_point("agent")
workflow.add_conditional_edges("agent", should_continue, {
    "call_tools": "tools",
    "end": END
})
workflow.add_edge("tools", "agent")

app = workflow.compile()

适合谁：

需要精确控制 Agent 执行流程的开发者
复杂多步骤任务的编排
已经入了 LangChain 生态的团队

仓库： https://github.com/langchain-ai/langgraph

4.2 CrewAI：给 Agent 分配“角色”，让它们自己开会

Github： https://github.com/crewAIInc/crewAI

一句话总结： 多 Agent 协作里最“产品化”的方案，定义角色→分配任务→执行，开箱即用。

CrewAI 的理念特别像一个项目团队：

你定义几个 Agent，每个人有自己的角色（研究员、写手、审核员）
你给每个 Agent 分配 Task（任务）
你把 Agent 和 Task 打包成一个 Crew（团队）
然后 crew.kickoff() 一键启动，它们自己协作

from crewai import Agent, Task, Crew

# 定义角色
researcher = Agent(
    role="市场研究员",
    goal="收集和分析最新市场数据",
    backstory="你是一个有10年经验的市场研究员，善于从海量数据中提炼洞察。"
)

writer = Agent(
    role="内容写手",
    goal="基于研究数据撰写引人入胜的报告",
    backstory="你是一个擅长把枯燥数据变成有趣故事的专业写手。"
)

# 定义任务
research_task = Task(description="调研2025年AI Agent框架的市场趋势", agent=researcher)
writing_task = Task(description="基于调研结果写一篇行业分析报告", agent=writer)

# 组建团队
crew = Crew(agents=[researcher, writer], tasks=[research_task, writing_task])
result = crew.kickoff()

CrewAI 的一个强项是它把 Agent 协作这件事产品化得很好——你不用去纠结图怎么画、状态怎么传递，只要把“谁干什么”定义清楚就行。

适合谁：

想要快速落地多 Agent 协作的团队
偏好“角色扮演”模式的任务分解
不想在编排上花太多时间的开发者

仓库： https://github.com/crewAIInc/crewAI

4.3 AutoGen（微软）：多 Agent 对话的鼻祖级方案

Github： https://github.com/microsoft/autogen

一句话总结： 微软出品，多 Agent 对话模式的先驱，学术感强但功能强大。

AutoGen 是微软研究院搞出来的框架，它的核心思路是 “让 Agent 通过对话来协作”：

多个 Agent 在一个群聊里，互相发消息
一个“协调员”决定谁下一个发言
Agent 可以执行代码、调用工具、互相提问

AutoGen 在 2025 年经历了一次大版本重构（0.4），API 变得更加模块化。它对新模型的适配速度很快，而且代码执行能力（让 Agent 自己写代码跑代码）是它的一大亮点。

from autogen_agentchat.agents import AssistantAgent
from autogen_agentchat.teams import RoundRobinGroupChat
from autogen_ext.models.openai import OpenAIChatCompletionClient

# 创建 Agent
assistant = AssistantAgent(
    "assistant",
    model_client=OpenAIChatCompletionClient(model="gpt-4"),
)

# 创建对话团队
team = RoundRobinGroupChat([assistant])

适合谁：

需要复杂的多 Agent 对话流程
有代码生成和自动执行需求的场景
研究导向的团队

仓库： https://github.com/microsoft/autogen

4.4 Agno（原 Phidata）：极简高性能的黑马

Github： https://github.com/agno-agi/agno

一句话总结： 如果你想找一个“不废话、跑得快”的 Agent 框架，Agno 值得狠狠关注。

Agno 的前身是 Phidata，2025 年改名后迅速崛起。它的设计哲学和 LangChain 几乎完全相反——能少写一行代码就少写一行，能不抽象就不抽象。

from agno.agent import Agent
from agno.tools.duckduckgo import DuckDuckGoTools

agent = Agent(
    model="gpt-4o",
    tools=[DuckDuckGoTools()],
    markdown=True,
)

agent.print_response("查一下 Agno 和 LangChain 的性能对比")

性能上 Agno 确实很猛——官方 benchmark 显示它在创建 Agent、调用工具等环节比 LangChain 快 2-50 倍（具体倍数取决于场景，但这个量级是可以感受到的差异）。

而且 Agno 自带一个漂亮的 Web UI，调试体验不错。

适合谁：

追求性能和简洁的开发者
快速原型和中小型项目
受够了 LangChain 抽象地狱的人（懂的都懂）

仓库： https://github.com/agno-agi/agno

5. 应用层平台：不想写代码？拖拖拽拽也能搞 Agent

不是每个人都是开发者。或者说，就算是开发者，有时候也想偷懒。

这层框架/平台的目标是让不懂代码的人也能搭 Agent，或者让懂代码的人 5 分钟搞定一个 Demo。

5.1 Dify：国内最成熟的开源 LLM 应用平台

Github： https://github.com/langgenius/dify

一句话总结： 如果你需要一个可视化的 AI 应用搭建平台，Dify 是目前开源方案里的最优解。

Dify 提供了一个完整的 Web 界面，让你可以：

可视化编排工作流（拖拽节点，连线）
管理知识库（上传文档自动向量化）
定义工具和插件
监控和日志

它的核心优势是开箱即用——Docker 一键部署，浏览器打开就能开始搭 Agent。

2025 年的 Dify 已经支持了比较复杂的 Agent 模式（ReAct、Function Calling），而且它的插件市场在逐渐丰富。

适合谁：

想要低代码搭建 AI 应用的团队
需要快速给客户做 Demo
内部工具型 Agent 的构建

仓库： https://github.com/langgenius/dify

5.2 Coze / 扣子：字节跳动的“App Store 式”Agent 平台

官网： https://www.coze.com / https://www.coze.cn

一句话总结： 国内最“消费级”的 Agent 平台，门槛低到几乎为零，分发能力强。

Coze（扣子）是字节跳动推出的 AI Bot 开发平台。它的思路和 Dify 类似但也有关键差异：

更偏 C 端： 你可以把做好的 Bot 发布到豆包、飞书、微信等渠道
插件生态： 字节系的产品集成天然好（飞书文档、火山引擎等）
免费额度大方： 对个人开发者很友好

美中不足的是 Coze 目前商业化程度比较高，部分高级功能和企业定制需要付费。

适合谁：

想做 C 端 AI 应用分发的团队
字节生态内的企业
想要零门槛入门的个人开发者

5.3 FastGPT / Flowise

还有两个值得一提的：

FastGPT（https://github.com/labring/FastGPT）：专注知识库问答，在 RAG 场景做得非常深。
Flowise（https://github.com/FlowiseAI/Flowise）：Node-RED 风格的拖拽式 AI 工作流，视觉效果很直观。

6. 协议层：Agent 之间怎么“打电话”？

2025 年出现了一个很有趣的趋势——Agent 之间需要互相通信的标准协议。

以前 Agent 之间的通信基本都是“各搞各的”，你要让一个 Dify 上的 Agent 调用一个 AutoGen 上的 Agent，基本要写一大堆胶水代码。

于是两个最重要的协议出现了：

6.1 MCP（Model Context Protocol）—— Anthropic 的“AI 版 USB”

Github： https://github.com/modelcontextprotocol

MCP 是 Anthropic 在 2024 年底提出的协议，核心想法很简单：让 LLM 和外部工具/数据源之间有一个统一的连接标准。

打个比方：以前你给 Agent 接一个数据库，每个框架的接法都不一样。有了 MCP 之后，只要数据库提供一个 MCP Server，所有支持 MCP 的 Agent 框架都能直接连。

到 2025 年中，MCP 已经被大量框架支持，包括 Claude Desktop、Cursor、Continue 等开发工具也内置了 MCP。

仓库： https://github.com/modelcontextprotocol

6.2 A2A（Agent-to-Agent）—— Google 的“Agent 间通信协议”

Github： https://github.com/google/A2A

如果说 MCP 解决的是“Agent 怎么连工具”，那 A2A 解决的就是“Agent 之间怎么聊天”。

Google 在 2025 年推出的 A2A 协议定义了一套 Agent 间的标准通信格式，包括：

如何发现对方的能力（Agent Card）
如何发起任务请求
如何传递多模态内容

目前 A2A 还比较早期，但因为 Google 的推动力很强，势头值得关注。

7. 选择困难症终结指南：一张表格帮你决策

说了这么多，你到底该选哪个？

没有标准答案——选框架要看场景，就像买菜要看做什么菜。

不过我可以给一个速查表：

你的情况	推荐选择	理由
我刚入门，想快速跑通一个 Demo	Dify 或 Agno	前者不用写代码，后者代码最少
我要做企业级 RAG 应用	Dify + LlamaIndex	前者管平台，后者管检索质量
我在微软技术栈（C#/.NET）	Semantic Kernel	原生支持，不用折腾
我想做复杂多 Agent 协作	LangGraph 或 CrewAI	前者灵活，后者上手快
我追求极简和性能	Agno 或 OpenAI Agents SDK	两个都是“去你妈的抽象”风格
我要给老板/客户演示	Dify 或 Coze	拖拖拽拽就能出活
我要做学术研究	AutoGen	学术圈用得最多，论文好引用
我深度绑定 OpenAI	OpenAI Agents SDK	官方亲儿子，支持最快

8. 最后的最后：框架不是最重要的

写了这么多，最后想说一个可能“劝退”的观点：

框架只是工具，真正重要的是你对问题的理解和你对 Agent 行为的把控能力。

我见过用 LangChain 写得一塌糊涂的团队，也见过不用任何框架、纯手写代码把 Agent 做到飞起的团队。

框架的价值是帮你省时间，不是替你思考。

所以如果现在你还在纠结“到底学哪个”，我的建议是：

先想清楚你要做什么（场景第一）
挑一个最顺眼的框架用起来（决策速度 > 决策精度）
用着不爽就换（不要心疼沉没成本）

2025 年的 AI Agent 框架生态，就像 2015 年的前端框架生态——百花齐放、快速迭代、没有永远的王者。

但这也意味着：你任何时候入场都不晚，因为整个行业都还在摸索。

附：所有框架仓库速览（一键 Star 列表）

LangChain：https://github.com/langchain-ai/langchain

LangGraph：https://github.com/langchain-ai/langgraph

LlamaIndex：https://github.com/run-llama/llama_index

Semantic Kernel：https://github.com/microsoft/semantic-kernel

OpenAI Agents SDK：https://github.com/openai/openai-agents-python

CrewAI：https://github.com/crewAIInc/crewAI

AutoGen：https://github.com/microsoft/autogen

Agno：https://github.com/agno-agi/agno

Dify：https://github.com/langgenius/dify

MCP：https://github.com/modelcontextprotocol

A2A：https://github.com/google/A2A

FastGPT：https://github.com/labring/FastGPT

Flowise：https://github.com/FlowiseAI/Flowise

AI Agent技术社区

Agent 垂直技术社区，欢迎活跃、内容共建。

更多推荐

Hermes Agent Windows 桌面端部署全指南

AI Agent技术社区

云边端协同下的AI Agent实践：记忆机制、工具调用与推理优化

本文探讨了2026年大模型应用落地的关键趋势——AIAgent从"云端大脑"向"云边端协同"分布式架构的演进。文章分析了三层架构的分工：云端负责知识存储与宏观推理，边缘侧处理实时调度，端侧执行具体操作。重点从三个维度展开：1）云端任务规划机制，通过结构化任务树实现意图拆解；2）分层记忆管理，包括本地会话记忆和云端长期记忆；3）工具调用与推理优化技术，使Age