AI Agent Framework 怎么选：LangGraph、CrewAI、OpenAI Agents SDK、Google ADK 和 Mastra 该看什么
现在的问题已经不是“要不要用 Agent Framework”，而是你到底该用哪一种。过去很多团队只是把一个模型接上工具，再写一点 prompt，就叫 agent。到了 2026 年，这个说法越来越不够用了。真实项目里你会遇到状态、工具调用、审批、失败恢复、可观测性、部署、评测、多人协作、长任务和成本控制。框架选错了，最开始 demo 可能很快，后面每一步都会变重。
这篇不做泛泛的“十大 Agent 框架推荐”。我们只看几个开发者现在真的会遇到的代表：LangGraph、CrewAI、OpenAI Agents SDK、Google ADK、Mastra，再顺带看 Microsoft Agent Framework 和 LlamaIndex Workflows 应该放在哪个位置。目标不是替你宣布冠军，而是给一张选型表：什么任务该看什么框架，什么时候不该上多 agent，什么时候自己写 loop 反而更清楚。
先给结论：按任务形状选，不按热度选
我会先把框架放进这张表：
| 框架 / 工具 | 最适合的任务形状 | 第一眼看什么 | 不适合什么 |
|---|---|---|---|
| LangGraph | 状态明确、流程复杂、需要可恢复的长任务 | durable execution、graph、human-in-the-loop、trace | 只做一次性简单工具调用 |
| CrewAI | 角色分工明显的多 agent 协作 | crews、flows、memory、knowledge、observability | 为了炫技硬拆 5 个角色 |
| OpenAI Agents SDK | OpenAI 生态内轻量 agent 编排 | tools、handoffs、guardrails、sessions | 你想完全自管 runtime loop |
| Google ADK | Gemini / Google Cloud / 企业 agent | build、debug、deploy、多 agent、云端部署 | 非 Google 栈且不想引入云平台 |
| Mastra | TypeScript 产品应用里的 agent | agents、workflows、memory、MCP、logging、evals | 纯 Python 研究型实验 |
| Microsoft Agent Framework | .NET / Python / Azure / enterprise | state、telemetry、type safety、AutoGen/Semantic Kernel 继承 | 不在 Microsoft 生态且不需要企业集成 |
| LlamaIndex Workflows | 数据、文档、RAG 强相关 agent | retrieval、index、workflow、source grounding | 主要问题不是知识和数据时 |
这张表比“哪个框架最好”更有用。因为 agent 框架的差异不是只在 API 好不好看，而在它默认鼓励你怎么组织工作。
LangGraph：适合需要控制感的复杂流程
LangGraph 的关键词是控制、状态和可恢复。它不是最轻的选择，但当你的任务需要多个节点、条件分支、状态保存、人工介入、流式输出、失败恢复时，它会比“一个 while loop 加几个 tool call”更清楚。
适合 LangGraph 的任务通常长这样：
- 客服工单分流，要查用户、查订单、判断类型、必要时交给人
- 研究任务要拆成搜索、阅读、摘要、复核、输出
- coding agent 要在计划、修改、测试、review 之间循环
- 内部运营流程有审批节点，不允许 agent 一路自动跑到底
如果你的任务有清楚状态，LangGraph 值得认真看。如果你的任务只是“问模型一个问题，调一次工具，返回结果”，那 LangGraph 可能太重。
CrewAI：适合角色协作，但不要为了多 agent 而多 agent
CrewAI 的优势是角色感很强。你可以把任务拆成 researcher、writer、reviewer、analyst、operator，也可以通过 crews 和 flows 管理协作。这对研究、内容、运营自动化、商业分析、资料整理这类任务很自然。
但 CrewAI 也最容易被误用。很多人一上来就设计 5 个 agent，每个 agent 都有很长角色设定，最后系统看起来热闹，实际更难 debug。判断 CrewAI 是否适合时，我会问：
- 这些角色是不是人类团队里本来就存在？
- 每个角色有没有不同输入、不同责任、不同验收标准？
- 如果去掉其中一个角色，结果是否明显变差？
- 失败时能不能看出是哪一环出错？
如果这些问题答不上来，多 agent 只是装饰。
OpenAI Agents SDK：适合想用官方轻量编排的人
OpenAI Agents SDK 适合一种很常见的情况：你已经在用 OpenAI 模型和工具，想把 agent、tools、handoffs、guardrails、sessions 这些东西组织得更像工程，而不是每个项目都自己写一套 glue code。
它的重点不是“替代所有框架”，而是给 OpenAI 生态里的 agent 应用一个更顺手的编排层。适合它的场景包括：
- 一个主 agent 调几个工具
- 几个专家 agent 之间有 handoff
- 需要 guardrails 和 session 管理
- 不想一开始就上很复杂的 graph runtime
但如果你想完全掌控每一步模型调用、工具执行、状态持久化和调度，直接用 Responses API 或自己写 runtime 可能更清楚。
Google ADK：适合看重部署和云端 agent 生命周期的人
Google ADK 的强项在于它不是只讲本地 demo，而是强调 build、debug、deploy，尤其适合已经在 Google / Gemini / Cloud 生态里的团队。它适合想把 agent 从原型推进到企业工作流的人。
你应该重点看：
- 本地开发体验是否顺
- 多 agent 支持是否贴合你的任务
- 调试和 trace 能不能看清工具调用
- 部署到云端是否真的省事
- 权限、观测、评测是否和现有平台配合
如果你的团队不在 Google 生态，ADK 仍然值得研究，但未必是第一选择。生态贴合度在 agent 框架里很重要，因为 agent 不是孤立函数，它会接模型、工具、数据、权限和部署环境。
Mastra：TypeScript 产品团队要认真看
Mastra 值得单独放进表里，是因为很多 AI 产品团队不是 Python infra 团队，而是 TypeScript / Node / Next.js / React 团队。它们要的不是研究框架，而是能放进产品里的 agent、workflow、memory、logging、tracing、evals 和 MCP 支持。
如果你的 agent 是产品功能的一部分，比如：
- SaaS 里的工作流助手
- 文档产品里的研究助手
- CRM / support 里的操作助手
- 内部工具里的自动化入口
那 TypeScript-first 的框架会省很多集成成本。选 Mastra 这类框架时，不要只看 agent API，要看它和应用栈、部署、日志、前端交互、后台任务是否顺。
一个 30 分钟选型测试
不要只看文档首页。选一个真实小任务，用候选框架各跑一遍：
| 测试项 | 要看什么 |
|---|---|
| 状态 | 能不能清楚记录当前步骤、历史输出、失败原因 |
| 工具调用 | 工具 schema、错误处理、重试是否清楚 |
| 人工介入 | 能不能在关键步骤停下来确认 |
| Trace | 出错后能不能复盘每一步 |
| 部署 | 本地跑通后，部署路径是否明确 |
| 维护 | 一个月后新人能不能看懂流程 |
如果某个框架 demo 很快，但 trace 看不清、失败难恢复、部署绕，那它不一定适合你的团队。如果另一个框架前期多写一点代码，但流程更可控，长期反而更省。
最后怎么选
我的建议很直接：
- 需要复杂状态和流程控制，先看 LangGraph
- 任务天然是角色协作，试 CrewAI
- OpenAI 生态里做轻量编排，看 OpenAI Agents SDK
- Google Cloud / Gemini / 企业 agent，看 Google ADK
- TypeScript 产品团队，看 Mastra
- Microsoft / Azure / .NET / Python 企业团队，看 Microsoft Agent Framework
- 数据、RAG、文档知识流重，看 LlamaIndex Workflows
最重要的是，不要为了“agent framework”而上框架。先写清任务形状，再选工具。Agent 框架选型的核心，不是哪个名字最热，而是谁能让你的任务更可控、更可复盘、更容易上线。
一个容易被忽略的问题：你到底要框架，还是只要模式
很多团队看到 LangGraph、CrewAI、ADK、Agents SDK、Mastra 这些名字，会默认自己必须选一个框架。其实不一定。你可能真正需要的是一种模式，而不是完整框架。
我会先分三档：
| 需求 | 更适合什么 | 例子 |
|---|---|---|
| 轻量工具调用 | 自己写 loop 或用官方 SDK | 一个客服助手查订单、查政策、返回答案 |
| 可恢复工作流 | LangGraph / Workflows 类框架 | 长任务、分支、人工审批、失败恢复 |
| 产品级 agent 功能 | Mastra / ADK / Microsoft Agent Framework | 要接产品、权限、日志、部署和评测 |
这张表能防止一上来就框架化。Agent 系统最常见的浪费，是任务还没复杂到需要框架，但团队已经开始讨论 runtime、graph、memory、multi-agent 和部署平台。反过来，也有团队明明已经需要状态恢复和人审节点，却还在用一堆脚本拼。选型前先判断复杂度，比选具体品牌更重要。
我会要求每个候选框架回答 7 个问题
在真正采用前，我会把候选框架放进这张问答表：
| 问题 | 为什么重要 |
|---|---|
| 状态存在哪里？ | 长任务失败后能不能恢复 |
| 工具调用怎么记录？ | 出错后能不能复盘 |
| 人工审批怎么插入？ | 高风险动作不能一路自动跑 |
| 是否支持流式和中间结果？ | 产品体验和调试都需要 |
| 评测怎么接？ | agent 不能只靠 demo 判断 |
| 部署路径是什么？ | 本地跑通不等于线上能用 |
| 一个月后谁维护？ | 框架复杂度最后会落到人身上 |
如果一个框架在这些问题上说不清，即使它 demo 很酷，也不适合作为团队默认方案。真正值得选的框架，应该让复杂性显性化，而不是把复杂性藏到黑盒里。
一个保守但好用的落地建议
如果你还没做过生产 agent，我不建议一上来就做大系统。先选一个可以被清楚验收的小任务，比如：
- 每天整理 10 条产品更新，输出来源和动作建议
- 处理一类固定客服问题，必要时交给人
- 根据 issue 修改一个小页面，并跑本地验证
- 对一批文档做结构化摘要和交叉检查
用这个任务测试 2 个候选框架就够了。不要同时试 7 个。每个框架都要记录：写了多少 glue code、失败时能不能看懂、部署是否顺、下次改需求是否容易。最后选的不是“最强”，而是团队愿意维护的那个。