Agent 框架怎么选？先看需求、状态与治理能力
内容摘要：框架是工具不是标准。本章给出厂商中立的选型方法，并对主流框架做对比。不把任何框架的抽象当作 Agent 的统一标准，也不声称某框架适用于所有业务。 难度：进阶 | 适用版本：见下表
verified_at: 2026-09-07|前置知识：02 概念、08、09、11
常见误区
选择社区最热门或功能最多的框架，后续自然能覆盖状态、RAG、多 Agent、安全和评测需求。
先给结论
框架选型应从状态持久化、流程可控性、数据能力、工具生态、可观测性、版本稳定性和团队维护成本反推。框架提供抽象，不替代业务边界、安全治理和测试。
带着这三个问题阅读：
- 项目真正需要的是 Agent、Workflow、RAG 框架还是模型 SDK？
- 哪些能力属于框架，哪些仍要由业务系统建设？
- 如何用最小验证项目识别锁定风险与迁移成本？
一、选型方法：先定需求，再选抽象
反模式：先选了热门框架，再把需求塞进它的抽象。正确顺序是先定状态、数据/RAG、工具/权限、评估，再选能自然表达它们的框架。框架可组合（如 LlamaIndex 检索 + LangGraph 编排）。
二、版本核验（写作时）
核验日期 2026-09-07。版本变化快，务必以官方发布说明为准。
| 框架 | 核验结论 | 官方来源 |
|---|---|---|
| LangChain | 1.0（2025-10-22 GA），核心 create_agent + 中间件 | blog.langchain.com |
| LangGraph | 1.0（2025-10-22 GA），langgraph.prebuilt 能力迁入 langchain.agents | changelog.langchain.com |
| LlamaIndex | Workflows 独立包 1.0（2025-06），数据/RAG 强 | docs.llamaindex.ai |
| AutoGen | 0.4.x 最后主线，进入维护模式；后继 Microsoft Agent Framework（AutoGen+Semantic Kernel，2025-10 预览）；社区分叉 AG2 | github.com/microsoft/autogen |
| CrewAI | 1.x 线（角色化多 Agent） | docs.crewai.com |
| OpenAI Agents SDK | 2025-03 发布（handoffs/guardrails/tracing） | openai.github.io |
| Claude Agent SDK | 2025-09 发布（内置工具/权限/子 Agent） | docs.anthropic.com |
重要提示：站内旧文档曾标注 LangChain 0.3.x / LangGraph 0.2.x / AutoGen 0.4.x，均已过时或状态变化。本知识库以上表为准。
三、对比表（按选型维度）
| 框架 | 适用场景 | 核心能力 | 优点 | 限制 | 依赖 | 安全风险 | 运维成本 | 替代方案 |
|---|---|---|---|---|---|---|---|---|
| LangChain 1.0 | 快速搭标准工具型 Agent | create_agent、中间件、大量集成 | 上手快、生态大、provider 中立 | 抽象仍偏多；深度定制需下沉 LangGraph | Python/JS | 注入/工具权限需自管 | 中 | OpenAI Agents SDK |
| LangGraph 1.0 | 需持久状态/循环/审批的长任务 | 状态图、checkpoint、interrupt | 控制力强、可恢复、HITL 一等公民 | 学习曲线陡、偏底层 | Python/JS | 同上 + 状态存储安全 | 中高 | 自建状态机 + 队列 |
| LlamaIndex | 文档/数据检索为核心 | 数据接入、索引、查询引擎、Workflows | RAG 数据处理强 | 编排不如 LangGraph 细 | Python/TS | 检索内容不可信 | 中 | 自建 RAG + 向量库 |
| AutoGen(0.4)/MS Agent Framework | 对话式多 Agent、企业 Azure | 多 Agent 对话、代码执行 | 多 Agent 成熟、企业集成 | AutoGen 维护模式，需评估迁移 | Python/.NET | 代码执行需沙箱 | 中高 | CrewAI / LangGraph |
| CrewAI | 角色化多 Agent 团队 | Agent/Task/Crew、流程编排 | 多 Agent 抽象简洁 | 高抽象、调试难 | Python | Agent 间注入 | 中 | LangGraph 多 Agent |
| OpenAI Agents SDK | OpenAI 生态、轻量多 Agent | agents/handoffs/guardrails/tracing | 轻量、原语少易学 | 偏 OpenAI 生态 | Python/TS | guardrails 需配置 | 低中 | LangChain |
| Claude Agent SDK | 长时自主/编码 Agent | 内置工具、权限框架、子 Agent | 生产级基建、权限细 | 偏 Anthropic 生态 | Python/TS | 权限/沙箱需用好 | 中 | OpenAI Agents SDK |
不要只看 GitHub 星数。星数是营销触达，不是"适合你的问题"。看的是抽象是否贴合你的状态/数据/工具/评估需求、维护是否活跃、协议（MCP）支持与团队熟悉度。
四、常见组合
- RAG 重 + 复杂编排：LlamaIndex（检索）+ LangGraph（有状态编排）。
- 快速起步：LangChain
create_agent或 OpenAI Agents SDK，需要更强控制时把关键流程下沉到 LangGraph。 - 多 Agent：先用 12 的判断确认真的需要，再选 CrewAI / LangGraph / MS Agent Framework。
五、不用框架，可以吗
可以。06 的最小 Agent 证明：一个循环 + 工具校验 + 停止条件，纯标准库即可。框架的价值在于持久化、多 Agent、大量集成、观测等；需求简单时不引入框架更可控、更少依赖风险（14 供应链）。
六、失败路径
- 框架驱动设计：为用某框架而扭曲架构。
- 混用新旧 API：如把
langgraph.prebuilt（旧）与langchain.agents（1.0 新）混用——先确认版本再查对应文档。 - 忽视维护状态：在维护模式框架上启新项目而不评估迁移成本。
七、测试与验证
- POC 对比：用同一评测集（16）在 2 个候选框架上实现最小闭环，比完成率/成本/开发体验。
- 记录框架版本与
verified_at，因为 API 会变。
八、安全与权限
九、性能与成本
- 框架会带来一定开销（抽象层、额外调用）；对延迟/成本敏感的场景要实测（18）。
十、关联章节
面试复述
先定义任务与治理需求，再选最小抽象。不要把框架 API 当成 Agent 原理，也不要仅凭 Demo 体验选型；应验证状态、恢复、评测、观测、安全和版本升级路径。
复述时先给结论，再补机制、适用边界和一个可验证指标；不要只罗列框架名称或产品功能。
迁移练习
选两种候选框架，用同一最小任务验证 Checkpoint、审批暂停、工具校验、Trace 导出和无框架迁移成本，再给出带权重的决策矩阵。
检索关键词
Agent 框架选型 LangChain LangGraph 1.0 LlamaIndex RAG AutoGen 维护模式 Microsoft Agent Framework CrewAI 多 Agent OpenAI Claude Agent SDK
官方来源
- 各框架官方文档与发布说明（见上表）；
verified_at: 2026-09-07，选型前请复核最新版本与维护状态。