Agent 框架对比：LangChain、LangGraph、CrewAI、OpenAI Agents SDK、Pydantic AI

为什么要用 Agent 框架？

直接调 LLM API 就能完成简单任务——问答、翻译、摘要。但一旦涉及复杂流程，比如"先搜索资料再写报告，写完后自我检查，发现问题重新写"，就需要 Agent 模式：让模型自主决定调用什么工具、按什么顺序执行、什么时候停止。

Agent 框架解决的核心问题是：如何可靠地管理 LLM 的决策循环。你需要处理工具调用的解析和重试、对话状态的持久化、多步流程的编排、异常情况的回退、人工介入的暂停和恢复——这些如果全部自己写，代码量很快就会失控。

选框架，本质上是在选你想承担多少复杂度。越轻量的框架，你写代码的自由度越高；越重量级的框架，内置能力越全面，但你要学的概念也越多。

下面从五个主流框架中逐一拆解，帮你找到适合你团队的那个。

一、LangChain

2022 年底推出，是最早出圈的 AI 框架。核心思路是把 Prompt 模板、链式调用、工具绑定、记忆管理、文档加载、向量检索等环节封装成独立组件，开发者按需组合。核心抽象是 Runnable，通过 LCEL（LangChain 表达式语言）用 | 操作符串起来，类似 Unix 管道。

• Agent 循环：内置 AgentExecutor，支持 ReAct 等多种模式
• 工具调用：@tool 装饰器或 BaseTool 子类
• 记忆管理：Buffer、Summary、Window、向量检索等多种 Memory 类
• RAG 组件：50+ 文档加载器、30+ 向量数据库集成，生态最全
• 部署：LangServe 包装成 FastAPI 服务
• 调试：依赖 LangSmith 或自定义 Callback

缺点：抽象层太多，API 稳定性差，版本升级经常 breaking change。简单需求要写很多概念。

团队反馈

二、LangGraph

LangChain 官方出品，解决的是 Chain 线性流程的限制。Agent 经常需要循环、分支、回退、并行——LangGraph 用有向图模型来描述这些行为。

• 核心架构：StateGraph（共享状态）+ Nodes（处理函数）+ Edges（流向，支持条件边）
• Agent 循环：通过 StateGraph 的条件边实现 LLM→工具→LLM 循环
• 状态持久化：内置 Checkpoint 系统，支持 SQLite/Postgres/Redis，可暂停、恢复、回滚
• 多 Agent 协作：原生支持 Supervisor、Hierarchical、Swarm 等模式
• Human-in-loop：interrupt_before / interrupt_after 支持人工介入
• 部署：LangGraph Cloud 或自行部署

缺点：学习曲线陡，需要理解图论概念。简单场景用 LangGraph 代码量反而更大。

团队反馈

三、CrewAI

CrewAI 的设计哲学是"多 Agent 团队协作"。每个 Agent 扮演特定角色（研究员、作家、审核员等），组成 Crew（小组）共同完成任务。它的 API 非常直观，适合快速构建多 Agent 流程。

• 核心架构：Agent（角色）→ Task（任务）→ Crew（小组）→ Process（流程）
• 多 Agent 协作：原生支持。Sequential（顺序执行）和 Hierarchical（层级管理）两种流程
• 记忆管理：支持短期记忆（对话历史）和长期记忆（嵌入式向量存储）
• 工具调用：支持 LangChain 工具和自定义工具，也可接入 MCP 工具
• Human-in-loop：支持人工审核和审批节点
• 部署：CrewAI Enterprise（官方托管）或自行部署

缺点：底层基于 LangChain，继承了其部分抽象问题。复杂工作流的控制力不如 LangGraph 精细。社区对"角色扮演"式设计的生产可用性有分歧。

团队反馈

四、OpenAI Agents SDK

OpenAI 官方推出的轻量级 Agent 框架。设计思路很明确：用代码定义 Agent，不用配置文件，不用学新概念。核心概念只有 Agent、Tool、Handoff、Guardrail 几个。

• 核心架构：Agent 对象 + Tools + Handoffs（Agent 间转交）
• Agent 间转交（Handoff）：一个 Agent 可以把控制权转交给另一个 Agent，适合"先分类再分发"的场景
• Guardrails：内置输入/输出审核机制，可以做安全过滤和合规检查
• 追踪：内置 tracing 功能，自动记录每次调用的输入输出和耗时
• 工具调用：Python 函数自动注册为工具，参数从函数签名提取 schema
• 流式输出：支持，可以逐事件接收

缺点：模型锁定 OpenAI，不支持多模型切换。功能相对简单，复杂场景需要自己扩展。

团队反馈

五、Pydantic AI

Pydantic 团队 2024 年 11 月发布。核心卖点是：Agent 开发最大痛点是结构化输出，而结构化输出是 Pydantic 的本职工作。用 Pydantic 模型贯穿整个 Agent 生命周期。

• 核心架构：Agent 对象 + Tools + result_type（Pydantic 模型定义输出格式）
• Agent 循环：内置循环，输出验证失败时自动重试（ModelRetry）
• 工具调用：@agent.tool 装饰器，支持 RunContext 依赖注入
• 结构化输出：result_type 指定 Pydantic 模型，框架自动验证
• 多模型支持：OpenAI、Anthropic、Google、Groq、Mistral、Cohere
• 调试：logfire 集成（Pydantic 自家可观测平台）
• 多 Agent：支持 Sequential、Router、Orchestrator-Workers 模式，但需手动编排，无原生调度引擎

缺点：生态尚不成熟，仅支持 Python。多 Agent 需要手动组合，不如 LangGraph/CrewAI 的原生支持方便。

团队反馈

六、对比矩阵

七、选型建议

• LangChain：需要 RAG（检索增强生成）、团队刚开始做 AI 应用、需要最多的教程和社区支持。不介意多一层抽象
• LangGraph：需要多步循环/分支/回退的复杂流程、需要人工介入暂停恢复、生产环境要求最高控制力
• CrewAI：快速构建多 Agent 团队、角色分工明确、团队对 AI 开发经验不多。适合原型验证和内部工具
• OpenAI Agents SDK：只用 OpenAI、想要最轻量框架、需要内置 Guardrails 做安全审核
• Pydantic AI：项目已在用 Pydantic、重视类型安全和结构化输出、需要多模型切换

实际生产中最常见的组合：Pydantic AI 或 OpenAI Agents SDK 处理单个 Agent 流程，当复杂度超过阈值时引入 LangGraph 来管理工作流。CrewAI 适合快速原型，但生产环境中很多人最终迁移到 LangGraph 以获得更细粒度的控制。LangChain 则在需要 RAG 组件时作为底层依赖被引入。