这两年 AI Agent 框架冒出来很多。
Google 有 ADK，OpenAI 有 Agents SDK，Microsoft 从 AutoGen、Semantic Kernel 走到 Agent Framework，LangChain 推 LangGraph，CrewAI、LlamaIndex、Pydantic AI、Haystack、Mastra、Agno、Strands 也都在各自生态里快速迭代。
如果只看官网介绍，每个框架都很强：都支持工具调用，都能做多 Agent，都有 workflow、memory、observability、eval、MCP。问题是，真正做项目时，你不可能都用。
我看完这些框架后，最明确的判断是：
AI Agent 框架选型的核心，不是哪个最火，而是你希望把多少控制权交给模型，多少控制权留在工程系统里。
很多团队一上来就问“哪个 Agent 框架最好”。这个问题本身就不太对。
更好的问题是：
你要做的是一个工具型助手，还是一个长期运行的业务流程？
你是否需要状态恢复？
是否需要人工审批？
是否需要跨系统调用？
是否需要企业知识库？
是否要在云厂商生态里部署和治理？
失败后能不能重放和定位？
这些问题回答清楚，框架选择会简单很多。
先说一个基本判断：很多场景其实不需要复杂 Agent 框架
如果你的需求只是“用户问一句，模型调用一两个工具，然后返回答案”，不需要急着引入复杂框架。
用模型 API、function calling、结构化输出，再加上你自己的权限、日志、审计和状态管理，通常就够了。
Agent 框架真正开始有价值，是在你遇到这些问题之后：
任务要跑很多步；
中途可能失败，需要恢复；
不同步骤要走不同分支；
某些动作必须人工确认；
需要多工具、多数据源、多角色协作；
线上结果必须可观测、可评估、可回放。
换句话说，框架不是为了让 demo 更炫，而是为了让不确定的 LLM 行为进入可控的工程系统。
“图工作流”为什么会成为核心能力
现在很多 Agent 框架都在强调 graph、workflow、state graph。
这里的“图”不是知识图谱，而是执行流程图。
一个 Agent 不再只是：
模型思考一下，调用工具，再思考一下，再调用工具，最后回答。
而是被拆成一组明确的节点和边：
用户输入进入哪个节点；
什么时候做检索；
什么时候调用工具；
什么时候并行查多个系统；
什么时候让模型判断；
什么时候重试；
什么时候暂停等待人工审批；
什么时候结束。
节点是执行步骤，边是流转规则，状态是贯穿全过程的数据。
这就是 LangGraph、Google ADK、Microsoft Agent Framework 这类框架强调“图”的原因。
Agent 负责局部智能判断，图负责全局流程约束。
这个分工非常重要。完全放任模型自由行动，demo 里看起来很智能，生产里很容易不可控。完全写死流程，又失去了 LLM 的灵活性。图工作流的价值，是把两者结合起来：关键路径由工程师设计，局部判断交给模型。
第一类：复杂流程和生产可控性，优先看 LangGraph、ADK、Microsoft Agent Framework
如果你要做的是可靠的多步业务流程，比如 AI 运维、自动化工单处理、销售线索研究、复杂审批、跨系统调查，这类场景不能只靠一个自由循环的 Agent。
你需要显式状态、分支、重试、checkpoint、human-in-the-loop、trace 和评测。
这时最值得优先看的，是三类框架。
LangGraph 的优势是跨云中立、生态成熟、图式工作流表达能力强。它适合需要明确控制流程、保留状态、做复杂分支和循环的 Agent 系统。缺点也明显：学习曲线比轻量 SDK 高，LangChain 生态历史包袱不少，用不好容易抽象过度。
Google ADK 适合已经在 Gemini、Vertex AI、Google Cloud 上建设 Agent 的团队。它现在已经不只是一个 Python SDK，而是覆盖 Python、TypeScript、Go、Java、Kotlin 的 Agent 开发框架，强调多 Agent、图工作流、评测、可观测性、会话、记忆、MCP/A2A 和云部署。缺点是生态还在快速成熟，非 Google Cloud 团队要评估绑定成本。
Microsoft Agent Framework 是 Microsoft 新一代路线，整合了 AutoGen 和 Semantic Kernel 的方向，支持 Python 和 .NET，强调 session state、type safety、middleware、telemetry、graph workflow、checkpoint 和人工介入。对于 Azure、.NET、企业治理环境，它会是很自然的选择。但它也比较新，老的 AutoGen/Semantic Kernel 用户需要判断迁移节奏。
如果没有强云绑定，我通常会把 LangGraph 放进第一候选。如果你已经明显站在 Google Cloud 或 Azure 生态里，就没有必要假装中立，直接评估 ADK 或 Microsoft Agent Framework 更务实。
第二类：OpenAI 生态内快速落地，优先看 OpenAI Agents SDK
OpenAI Agents SDK 的定位很清楚：轻量、官方、少数核心原语。
它提供 agent loop、handoff、guardrails、tracing、MCP 等能力，和 OpenAI Responses/API、工具调用、沙箱能力衔接得很顺。
如果你的模型主要用 OpenAI，业务主要是工具型助手，流程还没有复杂到需要显式图编排，那它比一上来用重框架更合适。
它的短板也很清楚：跨模型、跨云、中立性不如 LangGraph 或 Pydantic AI；复杂工作流仍然需要你自己设计。它适合快速把 Agent 跑起来，而不是替你解决所有生产编排问题。
我的建议是：OpenAI 生态内的小到中型 Agent，先用 OpenAI Agents SDK。等你真的遇到复杂状态、长任务恢复、多分支审批，再考虑引入 LangGraph 这类编排层。
第三类：RAG 和知识库 Agent，优先看 LlamaIndex、Haystack
很多所谓 Agent 项目，本质上不是“多 Agent 协作”，而是“如何让模型可靠使用企业知识”。
这时通用 Agent 框架不一定是第一选择。你更需要好的文档摄取、切分、索引、检索、rerank、引用、权限过滤和评测。
LlamaIndex 更偏开发者生态和快速构建。它在文档、索引、连接器、RAG、Agentic RAG 上积累很深，也支持 workflows 和 agents。做企业知识库、研究助手、文档问答、报告生成，LlamaIndex 很顺手。
Haystack 更偏企业级 AI pipeline。它的模块化 pipeline、检索、RAG、文档处理、序列化和部署能力更适合生产型知识应用，尤其是私有化、本地化和企业搜索场景。
这里有一个常见组合：LlamaIndex 或 Haystack 负责数据和检索，LangGraph、ADK 或 Microsoft Agent Framework 负责流程编排。
不要把检索逻辑全塞进 prompt，也不要让 Agent 自己临场决定怎么查知识库。RAG 是数据工程，不只是 prompt 工程。
第四类：Python 后端业务系统，Pydantic AI 很值得看
Pydantic AI 是一个容易被低估的框架。
它不像 CrewAI 那样强调多角色，也不像 LangGraph 那样强调图。它更像是“FastAPI 风格的 Agent 框架”：类型安全、依赖注入、结构化输出、工具 schema、测试和评测体验。
如果你的团队本来就是 Python 后端，想把 Agent 当成业务服务的一部分，而不是独立的魔法系统，Pydantic AI 很合适。
它的优势不是让 demo 看起来复杂，而是让 Agent 代码更像正常工程代码。输入输出有类型，依赖可以注入，结果可以校验，评测可以沉淀。
缺点是它不是最强的多 Agent 图编排框架。如果后续流程复杂，可以把 Pydantic AI 的 Agent 放到 LangGraph 节点里使用。
第五类：TypeScript 和 Web 产品团队，看 Mastra 和 Vercel AI SDK
如果你的团队主要是 TypeScript、Node、Next.js，Python 生态再强也未必是最合适的。
Vercel AI SDK 适合聊天 UI、streaming、工具调用、schema 校验和轻量多步调用。它更像 AI 应用 SDK，而不是完整 Agent runtime。做产品里的 AI 助手，它非常顺。
Mastra 更像 TypeScript-first 的 Agent 框架，包含 agents、workflows、RAG、memory、MCP、evals、observability、Studio/Server。对于想在 Web 产品里系统化建设 Agent 能力的团队，Mastra 比 Vercel AI SDK 更完整。
我的判断是：简单 AI 产品交互用 Vercel AI SDK；如果开始需要 memory、workflow、eval 和运行时管理，再看 Mastra。
第六类：多角色协作原型，CrewAI 上手最快，但不要神化“角色”
CrewAI 的心智模型很直观：给不同 Agent 分配角色、任务和协作方式。
研究员、分析师、写作者、审稿人，这类场景用 CrewAI 做原型非常快。它的 Crews 和 Flows 对业务人员也容易理解。
但我要泼一点冷水：角色设定不是可靠性的来源。
你让一个 Agent 叫“资深架构师”，不代表它真的具备架构判断；你让另一个 Agent 叫“审稿人”，也不代表它一定能发现问题。
生产系统里，真正提高可靠性的仍然是评测、trace、权限、状态、重试、审批和明确的流程控制。
所以 CrewAI 适合快速验证多角色协作思路，但如果要进入生产，不要只依赖角色扮演式 prompt。
第七类：云厂商生态，Google 看 ADK，Azure 看 Microsoft，AWS 看 Strands
云厂商正在把 Agent 框架变成平台入口。
Google 的 ADK 连接 Gemini、Vertex AI、Agent Engine、Cloud Run、GKE 等生态。Microsoft 的 Agent Framework 连接 Azure AI Foundry、OpenAI、.NET 和企业遥测治理。AWS 的 Strands Agents 则面向 Bedrock、AgentCore、Lambda、Fargate、EKS 等部署路径。
如果你已经深度绑定某个云，选型不必过度追求“理论中立”。
Agent 的生产化离不开身份权限、网络、日志、审计、部署、密钥、成本和监控。这些东西天然和云平台相关。框架能不能顺着你的云原生治理体系走，往往比它的 demo API 是否优雅更重要。
不建议按 GitHub star 或“多 Agent 能力”选型
Agent 框架现在变化太快，star 只能说明热度，不能说明生产可靠性。
我也不建议因为一个框架能做多 Agent，就默认它更高级。
很多业务流程本质上是确定性工作流，加少量 LLM 判断。比如：
先查用户信息；
再查订单；
再判断是否满足退款规则；
高风险时转人工；
最后写入工单。
这类流程不需要五个 Agent 互相聊天。你需要的是一个清晰的 workflow、一组可靠工具、明确权限和完整审计。
多 Agent 真正有价值的地方，是任务天然需要不同视角、并行调查、互相校验，或者不同能力边界。否则，多 Agent 很容易把简单问题复杂化。
我的默认落地路径
如果今天让我从零开始做一个生产级 Agent 系统，我不会一上来选最重的框架。
第一步，我会先把 agent contract 定义清楚：输入是什么，输出是什么，能调用哪些工具，权限边界在哪里，失败时怎么返回。
第二步，选一个轻量框架跑通 PoC。OpenAI 生态用 OpenAI Agents SDK；Python 后端用 Pydantic AI；TypeScript 产品用 Vercel AI SDK 或 Mastra；角色协作原型用 CrewAI。
第三步，建立最小评测集。不要只测 happy path，要测越权请求、脏数据、工具失败、长上下文、模型不确定时的行为。
第四步，当流程变复杂后，引入显式编排。跨云中立选 LangGraph，Google Cloud 选 ADK，Azure/.NET 选 Microsoft Agent Framework，AWS 选 Strands。
第五步，如果核心是知识库和文档，单独引入 LlamaIndex 或 Haystack 做数据层，不要把 RAG 做成一堆 prompt 拼接。
这条路径的好处是，早期不会被框架绑死，后期也不会在生产可控性上裸奔。
最后的判断
AI Agent 框架的竞争，表面上是 API 设计和生态竞争，底层其实是工程控制权的竞争。
简单 Agent 需要的是低摩擦。复杂 Agent 需要的是可恢复、可观测、可审批、可评估。知识型 Agent 需要的是数据工程。企业级 Agent 需要的是治理和部署体系。
所以选型时不要问“哪个框架最强”。
要问：
我需要控制哪些状态？
哪些步骤必须确定？
哪些判断可以交给模型？
失败后能不能恢复？
输出能不能评估？
危险动作有没有审批？
未来团队能不能维护？
把这些问题问清楚，Agent 框架就不再是一个热闹的清单，而会变成很具体的工程选择。
我的一句话建议是：
轻量助手先选轻框架，复杂流程选图编排，知识库场景选 RAG 框架，云厂商绑定场景顺着云生态走。不要为了“Agent 感”牺牲工程可控性。
