2026 年怎么选 AI Agent 框架，先分清框架、平台、运行时和工具层
LangGraph、OpenAI Agents SDK、CrewAI、AutoGen、Google ADK、Dify 与 DeepSeek Harness 应该怎么选？本文不按 Star 排名，从控制流、状态恢复、审批、部署和工具边界给出决策路径。
本文索引07
有人在 Google 里输入过这样一串词。
leading ai agent frameworks platforms competitors github features ecosystem roles
这串搜索很长，也很诚实。Agent 生态把框架、平台、运行时、Harness、工作流和工具都放进了相似的产品介绍里。开发者看完一圈，知道每家都支持 Agent、Memory、Tools 和 Multi-Agent，仍然不知道该装哪个。
选型的第一步，可以先把 Star 排名放到一边。
选型要落到几件具体工作上。谁来控制流程，谁来保存状态，失败以后从哪里恢复，危险工具由谁批准，部署与观测又由谁负责。产品名称只是这些决定的外壳。
七个常见选择，解决的是不同层
| 方案 | 官方定位里最重要的部分 | 更适合的任务 | 先确认的代价 |
|---|---|---|---|
| LangGraph | 低层、有状态的编排运行时 | 长任务、显式状态图、恢复与人工介入 | 需要自己设计图、状态和节点边界 |
| OpenAI Agents SDK | 少量原语加内置 Agent Loop | Python 应用、handoff、guardrail 与 tracing | 运行时选择与 OpenAI 生态结合更紧 |
| CrewAI | Crews 加结构化 Flows | 角色协作、事件驱动流程与业务自动化 | 自主协作和确定流程要主动分开 |
| AutoGen AgentChat | 高层多 Agent API，下接事件驱动 Core | 多 Agent 对话、团队模式与研究原型 | 团队模式、终止和状态管理需要明确配置 |
| Google ADK | 多语言 Agent 开发、图工作流、评估与部署 | 需要 Java、Go、TypeScript 或 Google Cloud 的团队 | 平台能力很多，采用范围容易一起变大 |
| Dify | 可视化编排、知识库、发布与监控平台 | 产品、运营和开发共同维护 AI 应用 | 平台接管的运行与数据边界更多 |
| DeepSeek Harness | 连 Agent Loop 也可替换的组合式 Harness | 运行时研究、深度定制与异构子 Agent | 当前是 Developer Preview，配置概念较多 |
这张表没有冠军。它把七个名字放回各自负责的层。
Dify 更接近一套能搭建并发布应用的平台。LangGraph 明确把自己放在低层编排运行时的位置。OpenAI Agents SDK 提供内置循环、handoff、guardrail、session 和 tracing。CrewAI 同时区分较自主的 Crews 与较确定的 Flows。AutoGen AgentChat 给多 Agent 模式一组高层默认值，底下还有更灵活的事件驱动 Core。Google ADK 把图工作流、多语言 SDK、评估与部署放进同一套开发体系。DeepSeek Harness 则把传统运行核心继续拆成可组合插件。
它们看起来都在做 Agent，接管的责任并不相同。
先判断流程要有多确定
最先问的是任务怎样前进。
报销审核、发布审批和数据管道通常有明确顺序。某一步失败以后，系统应该停在具体节点，保留状态，等人处理。LangGraph 的节点和边、CrewAI Flows、Google ADK 的 Graph Workflows 都适合表达这种流程。
开放研究、代码探索和问题排查允许模型决定下一步。OpenAI Agents SDK 的 Agent Loop、CrewAI 的 Crews、AutoGen 的团队模式会给模型更多调度空间。
真实产品经常两种都要。外层用确定流程控制预算、权限和停止条件，内层把某个开放子任务交给 Agent。OpenAI Agents SDK 的官方文档也把编排分成模型决策与代码决策两类，并允许混合使用。
如果团队还说不清哪一段可以自主，先别急着上多 Agent。单 Agent 加一条清晰流程，通常更容易看到失败发生在哪里。
状态恢复比 Memory 功能名更重要
很多框架都写着支持 Memory。选型时需要把这个词拆开。
模型下一轮是否记得上一轮，只是其中一部分。长任务还需要知道节点是否完成、工具是否执行、审批停在哪里，以及进程重启后从哪一步继续。
LangGraph 把 durable execution、persistence 与 human-in-the-loop 放在核心能力里。Google ADK 的文档把 session、state、events、memory、context compression 和恢复运行拆成独立部分。DeepSeek Harness 使用可重放的会话事件推导模型历史。OpenAI Agents SDK 提供 session 层，同时让 Runner 管理 turn、工具和 handoff。
可以拿一个简单故障测试框架。
- 工具执行前杀掉进程，任务恢复后会发生什么？
- 工具已经修改外部状态，但结果没有写回，系统怎样标记？
- 人工审批等待一天以后，旧上下文与权限是否仍然有效？
这三问比「有没有长期记忆」更接近生产环境。
工具支持要继续追问到边界
「支持 MCP」或「支持函数工具」只说明 Agent 能发起调用。
系统行为取决于工具定义怎样进入上下文，权限在哪里检查，结果过大时如何处理，来源与失败是否保留，以及恢复数据会不会再次执行上游动作。
框架常常负责工具调用，搜索、浏览器、数据库和内部系统仍由独立工具层负责。这种分层反而有好处。主框架更换以后，工具合同和证据格式可以保留。
以网页搜索为例，LangGraph、OpenAI Agents SDK、CrewAI 和 ADK 都能接工具，但它们不会替你的项目决定搜索几个来源、何时停止、某个来源失败后怎样报告。LIU/lennney 维护的 Agent Search MCP 把这些选择放在独立搜索层，源代码在 lennney/agent-search-mcp。它可以作为检查工具边界的一个实例，不代表所有项目都需要多来源搜索。
审批和观测要放在真实动作旁边
一套 Agent 会写文件、发消息或修改数据库时，guardrail 这个词还不够具体。
需要确认检查发生在输入、模型输出、每次工具调用，还是最终结果上。OpenAI Agents SDK 的文档明确区分输入、输出和工具 guardrails。工具检查会围绕每次自定义函数调用执行，handoff 后的输入与输出检查则有不同作用范围。
人工介入也有两种用途。一种是流程需要业务判断，另一种是系统准备执行高风险动作。前者可以修改状态再继续，后者需要权限边界拦住调用。只在 system prompt 里写「先询问用户」，不能替代执行层审批。
观测同样要沿真实过程记录。模型请求、工具调用、handoff、审批、状态变化和失败原因需要落在同一条可追踪链上。一个漂亮的最终回答无法证明中间没有重复执行动作。
部署选择经常提前决定框架选择
原型阶段只看 Python API 很容易。上线以后，运行位置会反过来约束选型。
Dify 同时提供云端与自托管社区版，适合希望平台一起承接发布和监控的团队。Google ADK 支持多语言，也把 Agent Runtime、Cloud Run 和 GKE 作为官方部署路径。LangGraph 可以只用开源运行时，也能接 LangSmith 的观测与部署服务。OpenAI Agents SDK 默认使用 OpenAI 模型与 tracing，也允许自定义 provider 和 trace processor。
没有哪一种边界天然更好。团队已经有 Kubernetes、队列、状态库和观测平台时，低层运行时往往更顺手。团队缺少这些基础设施时，完整平台可以少补很多工程缝隙。
选型前把五项内容写进一页纸。
- 数据存在哪里，谁能读取。
- 任务状态由谁持久化。
- 工具在哪个执行环境运行。
- trace 会发送到哪里。
- 框架移除后，哪些数据与合同还能继续使用。
最后一项决定了迁移成本。
一个更实际的选择顺序
需要可视化搭建、知识库与发布能力，可以先看 Dify。
需要显式状态图、长任务恢复和人工介入，可以先看 LangGraph。
Python 应用希望用少量原语获得内置循环、handoff、guardrail 与 tracing，可以先看 OpenAI Agents SDK。
任务的核心是角色协作，可以比较 CrewAI 与 AutoGen，并先写清终止、状态和验证规则。
团队需要多语言 SDK、图工作流与 Google Cloud 路径，可以先看 Google ADK。
你研究的是 Harness 自身怎样替换模型、会话和执行环境，DeepSeek Harness 值得读代码，当前仍应按 Developer Preview 对待。
如果问题只是一次模型调用加两三个工具，直接用模型 API 与普通代码可能已经够了。框架减少的是你确实拥有的复杂度。任务还没有复杂到需要状态恢复、审批和观测时，多一层抽象只会多一层排错。
项目全景可以继续看《2026 AI Agent 生态全景调研》。准备做决定时，先画出自己的流程、状态与权限，再回来看哪个名字刚好接住这些责任。