13 · 横向对比与选型决策
前置：读过 01 框架分层。前面十一篇没读也能用这一篇，但结论会显得突兀。
本篇回答：我这个项目到底该选哪个，以及选错之后有多难改回来。
前面十一篇把每个框架单独拆完了。真到要做决定的时候，问题会变成很具体的几句话：我们是 Java 团队；这个任务要跑四十分钟；有几步必须人工确认；明年可能要换模型。
这一篇把十一个框架放在同一组维度上排开，再给一条从这些具体条件出发的选型路径。
前面十一个框架一个一个拆完了，这一篇把它们放回同一张表上。
一、总表：11 个框架 × 关键维度
1.1 基础信息
| 框架 | Star | 版本 | 语言 | 层级 | 许可证 |
|---|---|---|---|---|---|
| LangChain | 144.5k | 1.3.15 | Py / TS | Framework | MIT |
| LangGraph | 39.9k | 1.2.11 | Py / TS | Runtime | MIT |
| DeepAgents | 27.9k | 0.7.7 | Py / TS | Harness | MIT |
| Claude Agent SDK | 7.9k | 0.2.139 | Py / TS | Harness | MIT |
| OpenAI Agents SDK | 28.7k | 0.21.1 | Py / TS | Framework | MIT |
| Google ADK | 21.2k | 2.7.1 | Py/TS/Go/Java/Kt | Framework | Apache 2.0 |
| Microsoft AF | 12.9k | 1.14.0 | Py / .NET | Framework | MIT |
| LlamaIndex | 51.7k | 0.14.23 | Py / TS | Framework | MIT |
| Qwen-Agent | 17.0k | —— | Py | Framework | Apache 2.0 |
| Spring AI | 9.3k + 10.6k | 2.0.0 | Java | Framework | Apache 2.0 |
| Eino | 12.7k | v0.9.15 | Go | Framework | Apache 2.0 |
1.2 能力对比
图例：● 强 / ◐ 有但一般 / ○ 弱或没有
| 框架 | 上手 速度 | 拓扑 灵活度 | 持久 执行 | HITL | 上下文 工程 | 多智 能体 | 可观 测性 | 模型 中立 | 生态 规模 |
|---|---|---|---|---|---|---|---|---|---|
| LangChain | ● | ◐ | ● | ● | ◐ | ◐ | ◐ | ● | ● |
| LangGraph | ○ | ● | ● | ● | ○ | ● | ◐ | ● | ● |
| DeepAgents | ● | ◐ | ● | ● | ● | ● | ◐ | ● | ◐ |
| Claude Agent SDK | ● | ○ | ◐ | ◐ | ● | ● | ◐ | ○ | ◐ |
| OpenAI Agents SDK | ● | ○ | ○ | ◐ | ◐ | ◐ | ● | ◐ | ◐ |
| Google ADK | ◐ | ● | ● | ● | ◐ | ● | ● | ◐ | ◐ |
| Microsoft AF | ◐ | ● | ◐ | ● | ◐ | ● | ● | ◐ | ○ |
| LlamaIndex | ◐ | ● | ◐ | ◐ | ◐ | ◐ | ◐ | ● | ● |
| Qwen-Agent | ● | ○ | ○ | ○ | ○ | ○ | ○ | ○ | ○ |
| Spring AI | ● | ○ ◐ | ◐ | ◐ | ◐ | ◐ | ● | ● | ◐ |
| Eino | ◐ | ● | ● | ● | ◐ | ● | ◐ | ● | ○ |
Spring AI 的拓扑灵活度：纯 Spring AI 为 ○，加上 Spring AI Alibaba Graph 为 ◐。
注意「模型中立」这一列 —— 它是最容易在半年后咬你一口的维度，详见本文第五节。
同一份数据画成矩阵，行是能力画像、列是同维度竞争：
1.3 各自最擅长的一件事
| 框架 | 它比所有人都强的那件事 |
|---|---|
| LangChain | 集成数量，以及「同一套概念能从框架下沉到运行时、上升到 Harness」 |
| LangGraph | 长时任务的持久执行、时间旅行、任意拓扑 |
| DeepAgents | 模型可换的开箱即用 Harness（规划 + 文件系统 + 子智能体 + 上下文压缩） |
| Claude Agent SDK | 编码 Agent 的能力上限 |
| OpenAI Agents SDK | 上手速度、Handoff 语义、语音 Agent、开箱即用的 Tracing |
| Google ADK | 多语言、图的编译期校验、内建评测、A2A |
| Microsoft AF | .NET 一等公民 + 企业治理 |
| LlamaIndex | 复杂文档解析与检索链路 |
| Qwen-Agent | Qwen 模型的一手适配知识 + 一行起 WebUI |
| Spring AI | 无缝融入现有 Spring Boot 系统 |
| Eino | Go 里的编译期类型安全编排 |
二、同一个任务，五种写法
任务：给 Agent 一个查天气的工具，问它旧金山天气怎么样。
# LangChain —— 一个工厂函数搞定，入参是「状态」不是字符串
from langchain.agents import create_agent
agent = create_agent(model="openai:gpt-5.5", tools=[get_weather],
system_prompt="You are a helpful assistant")
agent.invoke({"messages": [{"role": "user", "content": "What's the weather in SF?"}]})
# OpenAI Agents SDK —— Agent 是配置，Runner 是执行者，两者分开
from agents import Agent, Runner
agent = Agent(name="Assistant", instructions="You are a helpful assistant", tools=[get_weather])
result = Runner.run_sync(agent, "What's the weather in SF?") # 直接传字符串
# Google ADK —— 只声明，不写启动代码；`adk run` 会自动找名为 root_agent 的变量
from google.adk import Agent
root_agent = Agent(name="assistant", model="gemini-2.5-flash",
instruction="You are a helpful assistant", tools=[get_weather])
// Spring AI —— 链式调用，和 RestClient / WebClient 一个味道，Spring 开发者零学习成本
String answer = chatClient.prompt()
.user("What's the weather in SF?")
.tools(new WeatherTools()) // 对象里 @Tool 注解的方法会被扫成工具
.call()
.content();
// Eino —— Go 的显式风格，配置结构体嵌套较深，但每一层类型都是编译期检查的
agent, _ := adk.NewChatModelAgent(ctx, &adk.ChatModelAgentConfig{
Model: chatModel,
ToolsConfig: adk.ToolsConfig{ToolsNodeConfig: compose.ToolsNodeConfig{
Tools: []tool.BaseTool{weatherTool},
}},
})
在最简单的任务上，所有框架长得都差不多。 这说明一件重要的事：
简单场景下，框架选择几乎不影响结果
差异只在复杂度上来之后才显现 —— 上下文爆了怎么办、跑一半崩了怎么办、要人工审批怎么办、要拆多个 Agent 怎么办。
所以选型的正确方式不是「比谁的 Hello World 更短」，而是「想清楚我半年后会撞上哪些问题，看谁的答案更好」。
三、选型决策树
3.1 先回答这四个问题
| 问题 | 它决定什么 |
|---|---|
| 1. 团队主力语言是什么？ | 这一刀砍掉 80% 的选项，且往往不可谈判 |
| 2. 任务会跑多久？ | 秒级 → 任何框架；分钟到天级 → 必须有持久执行 |
| 3. 出错的代价有多大？ | 代价大 → 必须有工具级审批和完整审计轨迹 |
| 4. 模型会不会换？ | 会 → 中立性优先；不会 → 可以吃原厂框架的红利 |
四、七个反模式
这些是我见过最常见的选型错误。
反模式 1：还没做单 Agent 基线就上多智能体
症状：直接上 CrewAI 搭五个角色，成本涨 5 倍，效果盲测赢不过一个提示词写好的单 Agent。
正确做法：先做「一个 Agent + 好工具」的基线，测出效果和成本，再论证多智能体的增量。真正需要多智能体的只有两种情况：上下文必须隔离、能力/权限必须分离。
反模式 2：拿 Dify 和 LangGraph 比
症状：「Dify 15 万星，LangGraph 才 4 万，用 Dify」。
它们不在一层：Dify 是产品，LangGraph 是运行时库。正确的问题是「我要拖拽还是要写代码」，见 01 的分层。
反模式 3：用 star 数代替最近提交时间
症状：选了 AutoGen（60.5k star），三个月后发现它 2026-04 就冻结了。
正确做法：每次评估都跑一遍 —— 最近提交时间、最近 release、issue 响应 速度、背后组织的战略连续性。详见 07 微软阵营 那个案例。
反模式 4：把「支持 100+ 模型」当成模型中立
症状：用了 OpenAI Agents SDK 的 WebSearchTool 和 Tracing，半年后要换模型，发现核心能力全绑死了。
正确做法：把框架能力分成「可迁移」和「不可迁移」两栏，明确知道自己踩了几个不可迁移的。
反模式 5：在原型阶段就上重型运行时
症状：Demo 阶段就搭 LangGraph + Postgres checkpointer + 自定义 reducer，两周还没跑通第一个版本。
正确做法：原型用最薄的框架，撞上真实问题（上下文爆了、要审批了、崩了要恢复）再升级。升级路径的存在比一开始就选最强的更重要。
反模式 6：靠提示词做安全边界
症状：系统提示词里写「不要删除生产数据库」。
正确做法：边界在工具层和沙箱层强制。DeepAgents 官方直说自己是 trust-the-LLM 模型，Claude Agent SDK 用 hooks 做确定性拦截 —— 两家都在说同一件事：模型不会自律，代码才会。
反模式 7：没有评测就换框架
症状：「换成 X 框架之后感觉好多了」。
正确做法：先有回归评测集，再动架构。Google ADK 的 adk eval 是本专题里少数把评测做进核心的，其余都要自己搭 —— 见 EvalHub。
五、迁移成本：换框架到底有多贵
好消息：Agent 应用里真正值钱的三样东西，框架无关。
| 资产 | 迁移成本 |
|---|---|
| 工具实现（业务逻辑） | 低 —— 换个装饰器/接口的事 |
| 提示词 | 低 —— 纯文本 |
| 评测集 | 低 —— 数据 |
| 编排拓扑 | 中到高 |
| 状态 / 检查点格式 | 高 |
| 托管部署路径 | 高 |
| 可观测性接入 | 中 |
结论：把业务逻辑写在工具里，把编排写得薄，你的迁移成本就低。 反过来，把大量业务逻辑写进框架特有的图节点、状态 reducer、生命周期钩子里，你就被锁住了。
一个实用的护栏：
六、评估一个新框架的 checklist
拿到任何一个新框架，按这个顺序查，十分钟能得出结论：
# 十秒钟拿到一个框架的三个关键事实：多少星、最近一次提交、什么许可证。
# pushed_at 比 stars 更能说明这个项目还活不活着
gh api repos/OWNER/REPO --jq '{stars: .stargazers_count, pushed: .pushed_at, license: .license.spdx_id}'
| # | 检查项 | 不合格的信号 |
|---|---|---|
| 1 | 最近提交时间 | 超过 3 个月 |
| 2 | 版本号 | 还在 0.x 且要上生产 |
| 3 | 背后组织 | 同一家公司有两套竞争方案 |
| 4 | 破坏性变更历史 | 一年内两次大重写 |
| 5 | 它在哪一层 | 你分不清它是 Runtime / Framework / Harness |
| 6 | 持久执行 | 没有 checkpoint 却要跑长任务 |
| 7 | HITL 强度 | 只有回调式，进程必须一直活着 |
| 8 | 可观测性出口 | 只能发到它自家 SaaS |
| 9 | 不可迁移的能力 | 你打算用的核心能力全在这一栏 |
| 10 | 逃生舱 | 能不能只用它的一部分 |
第 10 条最容易被忽略但最有用：LlamaIndex 的 Workflows 可以单独装、LangGraph 可以不 带 LangChain 用、LlamaIndex 的检索可以当工具接进任何框架。能被局部使用的框架，风险比全家桶低得多。
七、三条我会给出的实际建议
1. 大多数团队应该从「薄」开始
OpenAI Agents SDK、LangChain create_agent、Spring AI、Eino ChatModelAgent —— 先跑通，撞上具体问题再升级。「先选最强的框架」是一种前置优化。
2. 混搭是常态，不是妥协
生产系统里最常见的组合：
框架不是宗教。 用每个框架最强的那部分，避开它最弱的那部分。
3. 投资在框架无关的地方
工具设计、提示词、评测集 —— 这三样决定你的 Agent 好不好用，而且换框架时全部保留。框架决定的是「工程上有多顺手」，不是「效果有多好」。
关于工具设计，Anthropic 那篇长期运行代理的工具设计 值得反复读 —— 它讲的东西，在本专题的 11 个框架里都成立。
八、回到起点
本专题第一句话是：做 Agent 的第一个问题不是「用哪个模型」，而是「用哪个框架，或者不用框架」。
现在可以补上答案的另一半：
框架解决的是工程问题，不是效果问题。
它替你回答「上下文爆了怎么办、崩了怎么办、要审批怎么办、要拆分怎么办」这四个问题。 你的 Agent 好不好用，取决于工具设计、提示词和评测 —— 那些和框架无关。
所以：选一个能让你少写胶水代码、且留了逃生舱的框架，然后把时间花在别处。
| # | 文章 |
|---|---|
| 00 | 专题索引 |
| 01 | 框架分层与评测坐标系 |
| 02 | LangChain |
| 03 | LangGraph |
| 04 | DeepAgents |
| 05 | Claude Agent SDK |
| 06 | OpenAI Agents SDK |
| 07 | Google ADK |
| 08 | 微软阵营：AutoGen 的死与生 |
| 09 | LlamaIndex |
| 10 | Qwen-Agent |
| 11 | Spring AI（Java） |
| 12 | Eino（Go） |
| 13 | 横向对比与选型决策（本文） |
数据快照：2026-08-19