通过构建相同的智能体对六种Python AI智能体框架进行比较。
在LangGraph、CrewAI、PydanticAI、OpenAI Agents SDK、Smolagents和Google ADK中构建相同的研究智能体，包含行数、标记数、调试分数以及选择指南。
如果你问一群人该使用哪种智能体框架，会得到十几种自以为有理却又相互矛盾的答案。有一派认为LangGraph设计过于复杂；另一派则称其是唯一可行的选择；还有一派主张完全不用框架，直接调用模型API。由于客户项目会让这类争论带来高昂成本，实际可行的办法就是停止争论并开展实验。
这里的实验很简单：在同一个周末内，使用六种不同的Python框架构建功能完全相同的智能体，任务、模型、工具以及评分标准都保持一致。该项目在2026年的语境下相当于一个文档分析流程，即从PDF中提取数据、与数据库进行交叉比对、撰写摘要并发送结果。实验结果对那些观点激烈的派别都没有起到任何偏袒作用。
最终构建了什么以及评分标准
该测试代理会接收公司名称，从网上查找最新新闻，提取关键的财务数据，将其与本地的SQLite数据库进行比对，最终返回结构化的JSON摘要。也就是说，这里有三个工具：一个代理和一个输出格式。
故意设计得比较简单。几乎没人会将自主编程代理作为首个投入生产的系统。大多数实际的代理应用其实都是带有简单推理功能的API协调器，而任何框架都应该能够轻松处理这类任务。在框架允许的情况下，GPT-4o被用作统一模型。
评估了五项指标：
- 所需代码行数
- 每次运行所需的token数，取10次运行的平均值
- 平均延迟时间
- 从零到可运行的原型所需的小时数
- “凌晨2点调试得分”，即在深夜流程出错时判断问题所在的能力
最后一个指标的重要性超乎想象。东西总是会出故障。
LangGraph：适合喜欢掌控感的人
约210行代码。构建一个可用的智能体需要三小时。每次运行处理2,847个标记。
LangGraph给人的感觉就像是分布式系统工程师设计的。你需要声明状态、定义节点、在节点间绘制边，然后编译结果。这与其说是在构建人工智能智能体，不如说是在设计数据管道，这反倒是一种优点。
第一个小时会比较艰难。看到为构建一个三工具智能体而需要使用StateGraph、add_node和add_conditional_edges这些操作，会觉得手续过于繁琐，让人很想放弃，转而尝试其他方案。
然而一次故障却改变了局面。在第三次测试查询中，该智能体表现极差，而使用LangSmith可以逐步骤展示整个运行过程：哪个节点做出了错误选择、它处于何种状态，以及为何在搜索之前就调用了数据库工具。很少有框架能提供如此直接的诊断功能。
人们很少提及的一个优点：稳定的执行能力。出错的运行可以从上一个检查点继续。在周末进行实验时这当然很方便，但若是在需要整夜处理10,000份文档的流程中，这就决定了你是能继续睡觉还是会在凌晨3点被叫醒。
LangGraph在测试中使用的标记数也是最少的。由于图结构已经明确了控制流程，模型无需再耗费标记来决定下一步该做什么——这些信息早已被提供给了它。
成本问题需要提前考虑。不能只是贴上相关说明然后寄希望于结果。问题定义越清晰，结构设计就越有效；但如果你还在摸索工作流程，那么绘制的图表数量将会超过实际发布的功能数量。
凌晨2点的调试评分：9/10。 LangSmith确实名不虚传，这里的问题诊断速度比其他任何地方都快。
CrewAI：快速原型开发工具
代码行数约340行。45分钟即可生成可用的智能体。每次运行可处理4,216个标记。
从执行pip install crewai到得到正确输出仅用了四十五分钟，这是除Smolagents之外最快的启动速度。
CrewAI是以团队而非单个智能体来思考的。每个成员都有特定的角色、目标与背景故事，任务会被分配给整个团队，由成员们共同决定谁负责什么工作。
researcher = Agent(
role="Financial Research Analyst",
goal="Find and verify recent financial data",
backstory="You're a senior analyst at a hedge fund...",
)
“背景故事”这一字段看起来很花哨，让人不以为然。然而，通过CrewAI代理生成的输出明显比通过原始API调用得到的相同提示的输出更为详细，由此可见角色设定确实会影响模型处理任务的方式。
速度是有代价的。在处理相同任务时，CrewAI消耗的令牌数量比LangGraph多出约48%。其架构要求至少有两到三个代理协同工作，因此即便只是研究人员和写作者这样的组合——本可由一个代理完成的工作——也因为任务分配而产生了额外开销。此外，该系统本质上是同步运行的，要将其集成到异步的FastAPI后端中，就必须用run_in_executor来封装调用。这种情况虽然还能忍受，但确实很烦人。
成本会迅速上升。有公开对比显示，使用CrewAI进行测试的花费为1,088美元，而使用同类PydanticAI方案的花费仅为390美元。如果每天运行该代理数千次，两者之间的差距会越拉越大。
在调试评分体系中，它在凌晨2点的得分仅为5/10。虽然成功案例很令人满意，但失败情况却会消失在如同黑箱般的任务分配链中。有一个漏洞耗费了40分钟才被查明，原来只是两个智能体在互相传递同一项任务。
PydanticAI：默默超越的优等生
代码行数约130行，构建一个可正常工作的智能体需1.5小时，每次运行处理2,912个标记。
如果LangGraph适合那些追求控制的人，CrewAI适合急躁的用户，那么PydanticAI则适合那些希望代码在六个月内就能正常运行的开发者。它由Pydantic团队开发，任何使用过FastAPI的人都已经熟悉其一半的API接口。智能体具有类型定义，输出结果会经过验证，依赖项也会被注入，因此所有能在运行前发现的问题都会被解决。
agent = Agent(
"openai:gpt-4o",
result_type=CompanyAnalysis, # Pydantic model
system_prompt="You are a financial research assistant.",
)
result_type参数的作用远不止表面所见。每个模型生成的回复都会自动与预设的架构进行比对。当模型返回格式错误的JSON数据时——这种情况最终难免会发生——框架会捕获错误并自动重试，无需编写任何手动验证代码。
full-stack-ai-agent-template项目进行了符合此模式的对照测试。同一个聊天应用在PydanticAI中大约需要160行有效代码，在LangGraph中约为280行，在CrewAI中则约为420行。
代码越短并不一定越好，但这项测试衡量了各个版本被理解的快慢。PydanticAI版本的代码可以逐行阅读和理解；LangGraph版本则需要在脑海中构建图表结构；而CrewAI版本则要求理解其任务分配机制。
其局限性在于PydanticAI是一个单智能体框架，没有内置的多智能体协调、任务交接或委托功能，因此三智能体设计意味着需要自行编写协调逻辑。虽然存在pydantic-graph模块，但在处理复杂工作流时仍无法与LangGraph或CrewAI相媲美。
深夜调试的便利性评分为8/10：类型错误能及早被发现，IDE会在程序运行前就标记问题，堆栈跟踪也能精准定位出问题所在行。
OpenAI Agents SDK：黑马之作
代码量约150行，一小时即可构建出可运行的智能体，每次运行消耗2,791个令牌。
由模型供应商提供的框架看似会带来绑定效应，甚至差点被排除在测试之外，但事实证明这种预期是错误的。
该SDK是OpenAI对其早期Swarm实验的正式重构版本，仅包含四种基本组件：Agent、Handoffs、Tools和Guardrails。其中Handoffs最为突出——你可以指定哪些Agent可以将任务传递给其他Agent，框架会负责任务路由。虽然它的灵活性不如LangGraph的图模型，但对于大约80%的多Agent应用场景而言已经足够，且更为简单。
agent = Agent(
name="Researcher",
instructions="You are a financial research assistant.",
tools=[search_tool, db_tool],
handoffs=[summary_agent],
)
它也不再局限于某一家供应商。通过 any-llm 适配器，现已支持超过 100 种大型语言模型，而且无需修改代码即可对 Claude 进行相同测试。
令牌使用效率与 LangGraph 相当，为测试中最低水平。内置的追踪功能表现良好，但略逊于 LangSmith。
其缺点是生态系统较为薄弱。LangGraph 拥有多年积累的社区工具、教程以及经过验证的解决方案，而该产品较为新锐，因此在处理边缘情况时往往只能依靠自身。
凌晨 2 点的调试评分：7/10。 内置的追踪功能实用且有效，错误信息也很清晰，但文档的不足使得人们不得不比预期更频繁地查看源代码。
Smolagents：极简主义者的选择
代码行数约 95 行。30 分钟即可创建出可用的智能体。每次运行消耗 3,340 个令牌。
那些数字并非输入错误。Hugging Face的实现非常注重极简设计，其核心逻辑仅约1,000行Python代码，半天就能读完。而LangGraph则做不到这一点。
差异不仅在于代码规模。这里的其他框架都使用JSON格式来传递指令，即智能体会发送一个数据块，说明要调用哪个函数以及传入哪些参数。而Smolagents的CodeAgent则直接编写真正的Python代码。
agent = CodeAgent(
tools=[search_tool, db_tool],
model=InferenceClientModel(),
)
result = agent.run("Analyze recent financial news for Acme Corp")
编写代码能让智能体以自然的方式组合各种工具，利用循环、条件语句以及JSON调用无法实现的链式操作。基准测试研究也证明了这一点，因为在大多数测试中，基于代码的智能体表现优于基于JSON的智能体。
但这样做会带来安全问题，因为智能体会生成并运行Python代码。虽然可以通过E2B、Docker和Pyodide实现沙箱隔离，但需要用户自行配置。默认的LocalPythonExecutor明确并非安全隔离机制，其文档中也有所说明。
其令牌消耗量高于LangGraph和OpenAI SDK。生成的Python代码相比紧凑的JSON更为冗长，而且每一次导入操作和变量声明都会消耗令牌。
使用 Gemini 或 GPT 时运行正常，但感觉像是用方钉去装圆孔。它在 Hugging Face 的模型与基础设施以及 Hub 集成方面表现出色——后者允许像分享模型一样分享和加载智能体，对于已身处该生态系统的人来说非常实用。
凌晨2点的调试评分：8/10。 读取智能体编写的代码比解析一串 JSON 工具调用更高效，且出错时只会生成普通的 Python 错误追踪信息。
Google ADK：企业领域的黑马
代码行数约180行。耗时两小时即可打造出可用的智能体。每次运行处理3,102个标记。
Google 的智能体开发工具包于2025年悄然出现，许多 Python 开发者尚未尝试过它。这是个亟待填补的空白。
ADK在结构设计上讲究规范性，而在执行方式上则较为灵活，这正是谷歌内部工具的典型特点。智能体是通过模型、名称、指令以及工具来定义的，与OpenAI SDK类似。除此之外还有工作流智能体（顺序型、并行型和循环型），以及用于协调多个智能体的新型AgentTeam API。
from google.adk.agents import Agent
root_agent = Agent(
model="gemini-2.5-flash",
name="financial_analyst",
instruction="You are a financial research assistant.",
tools=[search_tool, db_tool],
)
其独特之处就在于评估框架。测试用例以JSON格式编写，通过adk eval运行，随后会生成结构化的报告，说明实际行为是否符合预期。目前市面上的其他框架都没有如此成熟的评估工具。
只要使用Google Cloud，部署过程也会十分顺畅。Vertex AI Agent Engine负责处理扩展、监控及会话管理，但这一前提条件其实非常重要。
ADK是专为Gemini设计的。其他模型可通过LiteLLM使用，但文档、示例及工具均以Gemini为默认场景。尝试运行GPT-4o时遇到了未被记录的异常情况，花了45分钟才解决。
凌晨2点的调试评分：6/10。 adk web开发界面有一定帮助，但错误信息有时较为晦涩，而且文档采用典型的Google风格，内容详尽却难以查找。
该如何选择
“视情况而定”这种回答让所有人都很沮丧，因此经过六次构建该智能体后，我们得出了以下决策逻辑：
- 需在周五前完成部署：选择CrewAI或Smolagents。CrewAI适合那些不擅长调试Python代码执行的团队；Smolagents则适合那些擅长调试且希望最小化依赖项的团队。
- 需长期稳定运行：选择LangGraph或PydanticAI。LangGraph适用于需要分支逻辑、人工干预步骤以及持久运行的场景；PydanticAI则更适合需要结构化输出、且未来读者能够理解代码的单智能体工作场景。
- 已选定特定技术生态：可选择OpenAI平台上的OpenAI Agents SDK，利用其追踪与评估功能；或选择GCP上的Google ADK，实现与Vertex AI的原生集成及内置评估功能。
令人困扰的是，对于大多数项目而言，框架的重要性远低于提示工程和工具设计。一旦对系统提示和工具描述给予足够重视，这六个方案的输出质量几乎完全一致。不同之处在于开发者体验、调试难度以及运营成本。
最终保留的部署方案是：处理大部分工作的单智能体任务使用 PydanticAI，而当工作流极其复杂时则使用 LangGraph。使用两种框架并无必要道歉。
六个方案并列展示
| Metric | LangGraph | CrewAI | PydanticAI | OpenAI SDK | Smolagents | Google ADK |
| ----------------- | ----------- | --------------- | ------------- | ---------------- | --------------- | --------------- |
| Lines of code | ~210 | ~340 | ~130 | ~150 | ~95 | ~180 |
| Time to prototype | 3 hrs | 45 min | 1.5 hrs | 1 hr | 30 min | 2 hrs |
| Avg tokens/run | 2,847 | 4,216 | 2,912 | 2,791 | 3,340 | 3,102 |
| Multi-agent | Yes (graph) | Yes (teams) | Manual | Yes (handoffs) | Yes (hierarchy) | Yes (AgentTeam) |
| Type safety | TypedDict | Pydantic config | Full generics | Generic context | Minimal | Standard |
| MCP support | Yes | Limited | Native + A2A | Native | Yes | Yes |
| Model-agnostic | Yes | Yes | Yes (20+) | Yes (100+) | Yes (LiteLLM) | Gemini-first |
| Best debugger | LangSmith | Logs | IDE/types | Built-in tracing | Code output | ADK Web UI |
| GitHub stars | ~48K | ~44K | ~15K | ~16K | ~26K | ~23K |
| 2 AM debug | 9/10 | 5/10 | 8/10 | 7/10 | 8/10 | 6/10 |
这些数据都无法完整呈现全貌，但相比大多数对比文章，它们至少提供了一个更诚实的起点。
做好技术快速变化的准备
这些框架的更新速度之快，让人根本来不及记录。在本文撰写期间，LangGraph就已发布了重大更新；CrewAI的企业版在短短一周内就新增了多项集成功能；PydanticAI加入了A2A协议支持，而Google ADK则早在几天前就推出了SkillToolset功能。
任何对比都存在时效性。六个月后，性能差距可能会缩小，缺失的功能也可能被补上，而你当初忽视的框架反而可能成为最佳选择。因此，应选择那种即便在凌晨2点、流程中断且客户仍在等待时，你的团队也能立即进行调试的框架，而非那些GitHub星标最多的框架。
相关阅读
- Agent Plugins 1.0.0：技能与MCP服务器的共享打包格式 — Agent Plugins 1.0.0统一了各客户端中的插件文件夹、plugin.json、skills以及mcp.json文件的结构。本文介绍了该标准的覆盖范围、在安全性方面的考量，以及一个Google Agents CLI的使用示例。
- MCP、A2A与ACP的实际应用：银行如何将工具与智能体相互连接 — 通过一个处理欺诈和贷款业务的银行助手案例，展示了MCP、A2A和ACP在实现模型与工具、智能体之间连接时的分工方式。