> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# 6个主流Python智能体框架对比
- URL: https://www.hubwiz.com/blog/top6-python-agent-frameworks-comparison/
- Published: 2026-04-14T14:51:51.000Z
- Updated: 2026-04-14T14:51:51.000Z
- Description: 我空出一个周末，安装了所有六个主流框架，在每个框架中构建了相同的Agent。相同的任务。相同的模型。相同的工具。相同的评估标准。
- Author: admin
- Tags: LIBRARY, LANGGRAPH, CREWAI, PYDANTICAI, OPENAI SDK, SMOLAGENTS, GOOGLE ADK, #Import 2026-10-14 14:41

上个月，我的团队需要为一个客户项目选择一个Agent框架。一个文档分析管道——从PDF中提取数据，与数据库交叉引用，生成摘要，通过邮件发送结果。在2026年，这是相当标准的东西。

我在Twitter上问了该用哪个框架，这是一个错误。

一小时内我收到了47条回复，每条都自信地推荐不同的工具。其中一半互相矛盾。有人说LangGraph是"过度设计的垃圾"，有人说它是"唯一严肃的选择"。第三个人说两者都错了，我应该直接使用原始API调用。

于是我做了任何理智的人都会做的事。我空出一个周末，安装了所有六个主流框架，在每个框架中构建了相同的Agent。相同的任务。相同的模型。相同的工具。相同的评估标准。

以下是我发现的——这不是任何一方的狂热粉丝想听到的。

## 0、实验设置：我实际构建了什么

**任务：** 一个研究Agent，接收公司名称，搜索网络获取近期新闻，提取关键财务数据点，与本地SQLite数据库交叉引用，生成结构化的JSON摘要。三个工具，一个Agent，一个输出模式。

**模型：** 在所有六个框架中使用GPT-4o（尽可能使用——稍后详述）。

**测量指标：** 实现所需的代码行数、每次运行的token使用量（10次运行平均）、平均延迟、从零到工作原型所需时间，以及我称之为"凌晨2点调试分数"的东西——当出现问题时，弄清楚出了什么问题的容易程度。因为问题总会发生。

## 1、LangGraph：控制狂的天堂

**代码行数：** \~210  
**首次工作Agent所需时间：** 3小时  
**每次运行平均token数：** 2,847

LangGraph是一群分布式系统工程师构建Agent框架的产物。你定义状态。你定义节点。你在它们之间绘制边。你编译它。这感觉不像是在构建AI Agent，而更像是在设计数据管道。

我这样说是在夸奖。

学习曲线在第一小时就狠狠地打击了我。我盯着*StateGraph、add\_node、add\_conditional\_edges*，心想：\*对于一个三工具的Agent来说，这仪式太多了。\*我几乎放弃并转向下一个框架。

但后来有什么东西点击了。当我的Agent失败时——它确实失败了，在第三个测试查询时惨败——我打开LangSmith，一步步观察整个执行跟踪。我能准确看到哪个节点做出了错误决策，它持有什么状态，以及为什么它选择在搜索工具之前调用数据库工具。

**没人谈论的杀手级特性：** 持久化执行。如果你的Agent在运行中崩溃，它会从上一个检查点恢复。对于一个周末实验，这很好。对于一个通宵处理10,000份文档的生产管道？这是睡觉和凌晨3点被叫醒的区别。

LangGraph在我的测试中token消耗最低。图形结构迫使你明确控制流程，这意味着LLM浪费更少的token来决定下一步做什么——你已经告诉它了。

**缺点：** 你需要预先真正思考你的工作流程。没有"只是抛出指令然后希望"。如果你的问题定义明确，LangGraph会奖励你。如果你还在原型设计阶段，不知道工作流程长什么样，你会花更多时间画图而不是构建功能。

**凌晨2点调试分数：9/10。** LangSmith是真家伙。我在这里诊断问题的速度比任何其他框架都快。

## 2、CrewAI：快速原型机器

**代码行数：** \~340  
**首次工作Agent所需时间：** 45分钟  
**每次运行平均token数：** 4,216

CrewAI是当你告诉AI"嘿，你能不能让这个看起来简单点"时会发生什么的框架。我在45分钟内就有了一个工作Agent。不是勉强能用——是真正工作。带错误处理、工具调用、结构化输出。

语法很简洁。你将Agent定义为带有角色的类，将任务链接在一起，然后调用`kickoff()`。它读起来几乎像自然语言：

```python
researcher = Agent(
    role='Research Analyst',
    goal='Extract financial data from web sources',
    tools=[search_tool, db_tool]
)

task = Task(
    description='Analyze {company} and produce JSON',
    agent=researcher,
    expected_output='Structured financial summary'
)

crew = Crew(agents=[researcher], tasks=[task])
result = crew.kickoff()

```

CrewAI在更高的抽象层次上运行。你没有定义控制流程；框架为你处理。Agent根据提供的上下文决定工具调用顺序。

这既是祝福也是诅咒。当我构建标准"搜索→数据库→总结"管道时，它运行良好。但当我尝试更复杂的决策逻辑——"如果搜索返回少于3个结果，跳过数据库交叉引用"——我卡住了。CrewAI想要我描述*要做什么*，而不是*如何决定做什么*。

**深夜调试现实检查：** 当事情出错时，CrewAI的日志是六个框架中最不透明的。我得到了"Agent无法完成任务"但没有状态跟踪、没有中间输出、没有检查点可见性。我最终添加了`verbose=True`和print语句来重建执行路径。

**凌晨2点调试分数：4/10。** 快速构建，难以调试。

## 3、PydanticAI：结构化输出的王者

**代码行数：** \~165  
**首次工作Agent所需时间：** 2小时  
**每次运行平均token数：** 2,943

PydanticAI感觉像有人拿着OpenAI SDK说"这很好，但如果输出实际上有效呢？"然后围绕它构建了一个框架。

每个工具、每个Agent响应、每个中间结果——都有类型。真正的Python类型，运行时会验证。

```python
class FinancialSummary(BaseModel):
    company: str
    revenue: Optional[float]
    growth_rate: Optional[float]
    confidence_score: float

@agent.tool
async def search_financials(ctx: RunContext[None], company: str) -> FinancialSummary:
    # Tool implementation with typed returns

```

Pydantic验证发生在我甚至看到输出之前。如果LLM返回"N/A"作为收入字段（标记为`Optional[float]`），PydanticAI优雅地处理它。如果它返回"N/A"作为必需字段，我立即得到一个错误，包含确切的验证失败信息。

**实际生产中重要的特性：** PydanticAI与FastAPI和Pydantic生态系统原生集成。如果你已经在使用Pydantic进行数据验证（坦率地说，2026年的Python项目谁不是呢？），这感觉无缝。

权衡是灵活性。PydanticAI对*有明确模式*的工作流程非常固执。当我尝试动态工具发现（Agent根据输入决定使用哪些工具）时，我遇到了Pydantic模型的墙。可以绕过，但感觉像是在框架的设计意图之外工作。

**凌晨2点调试分数：7/10。** 验证错误消息清晰有用。状态可见性中等。

## 4、OpenAI SDK：原始力量

**代码行数：** \~380  
**首次工作Agent所需时间：** 5小时（首个工作版本）  
**每次运行平均token数：** 3,891

OpenAI SDK不是Agent框架。它是其他Agent框架构建的基础。

我选择了这个，因为有人说"所有Agent框架都是不必要的抽象"，我想知道直接针对API构建是否更干净。

它不是。

我花了五小时才得到第一个可靠工作的版本。不是因为我慢——是因为我在重新发明每个框架都提供的轮子。工具调用解析？我得自己写。重试逻辑？自己写。状态管理？自己写。结构化输出？手动JSON解析带错误处理。

```python
# What every framework hides from you
response = client.chat.completions.create(
    model="gpt-4o",
    messages=messages,
    tools=tools
)

# Manual tool call extraction and execution
if response.choices[0].message.tool_calls:
    tool_call = response.choices[0].message.tool_calls[0]
    # Parse arguments, call function, handle errors, build next message
    # Repeat until completion

```

到第三小时，我在写自己的Agent循环包装器。到第四小时，我意识到我是在构建一个糟糕的PydanticAI版本。

**唯一的优势：** 零依赖性。没有抽象泄漏，没有框架错误，没有版本冲突。如果你的团队有严格的依赖性要求，这可能是值得的。但对于大多数项目，你以500行样板代码为代价换取的"控制"是一种错误的节约。

**凌晨2点调试分数：6/10。** 没有魔法意味着没有魔法问题。但也没有魔法帮助。

## 5、Smolagents：极简主义者的梦想

**代码行数：** \~95  
**首次工作Agent所需时间：** 25分钟  
**每次运行平均token数：** 5,124

Smolagents是Hugging Face构建的，感觉像是用200行代码构建Agent的最小可行方法。

它奏效了。它以95行代码奏效了。

```python
from smolagents import CodeAgent, DuckDuckGoSearchTool

agent = CodeAgent(
    tools=[DuckDuckGoSearchTool()],
    model=model
)

result = agent.run("Research {company} and return financial summary")

```

这个Agent可以编写代码、执行代码、调用工具，并根据需要循环。类型提示和文档都很扎实。

但那种极简主义是有代价的。Smolagents对复杂工作流程的信念是"Agent会弄清楚"——在某些情况下这是真的，但当它失败时，调试是一场噩梦。

**关键发现：** Smolagents的token使用量比我测试的任何其他框架都高。其代码生成和执行方法意味着单个Agent运行可能触发5-10个LLM调用，而LangGraph中的结构化方法可能只需要2-3个。

对于低容量原型设计，谁在乎呢？对于生产吞吐量，这加起来很快。

**凌晨2点调试分数：5/10。** 非常紧凑的代码库意味着当出现问题时，你可以阅读整个框架源代码。但当它失败时，通常是因为Agent生成的代码错了，你在调试生成的代码。

## 6、Google ADK：新入局者

**代码行数：** \~290  
**首次工作Agent所需时间：** 4小时  
**每次运行平均token数：** 3,456

Google的Agent Development Kit作为"原生多模态Agent框架"推出。我尝试了。它是……还行。

ADK感觉像是Google在追赶LangGraph和CrewAI。它有状态、有工具、有会话记忆。一切都有效。

但我找不到任何它做得比其他框架更好的地方。持久化执行？LangGraph更好。快速原型设计？CrewAI更好。类型安全？PydanticAI更好。

ADK确实与Google的生态系统（Vertex AI、BigQuery）集成得更好。如果你已经在Google Cloud中，这可能很重要。对于供应商无关的部署，这只是另一个学习曲线。

**凌晨2点调试分数：6/10。** 工作正常，但文档 sparse，社区支持仍在增长。

## 7、最终排名

| 框架         | 代码行数  | 首次工作时间 | 平均Token数 | 调试分数 | 适用场景             |
| ---------- | ----- | ------ | -------- | ---- | ---------------- |
| LangGraph  | \~210 | 3小时    | 2,847    | 9/10 | 生产管道、持久化执行       |
| CrewAI     | \~340 | 45分钟   | 4,216    | 4/10 | 快速原型、标准工作流程      |
| PydanticAI | \~165 | 2小时    | 2,943    | 7/10 | 类型安全关键、FastAPI项目 |
| OpenAI SDK | \~380 | 5小时    | 3,891    | 6/10 | 严格依赖要求           |
| Smolagents | \~95  | 25分钟   | 5,124    | 5/10 | 极简主义原型           |
| Google ADK | \~290 | 4小时    | 3,456    | 6/10 | Google Cloud环境   |

## 8、我的选择

我为客户项目选择了**LangGraph**。不是因为它是最快的，而是因为它在事情出错时给我最多的可见性。当那个管道在凌晨2点失败时，我想知道为什么。

但如果你今天就开始一个周末原型，想要最快的胜利？**CrewAI** 的45分钟到工作Agent很难被击败——只要你的用例保持简单。

---

原文链接: [I Compared 6 Python AI Agent Frameworks So You Don't Have To](https://pub.towardsai.net/i-compared-6-python-ai-agent-frameworks-so-you-dont-have-to-langgraph-vs-crewai-vs-pydanticai-vs-d8a5e6e43262?ref=hubwiz.com)

汇智网翻译整理，转载请标明出处