这篇是应景写的——2026 年年中各家大厂都把 Agent SDK 发了个遍，隔几天就有人来问我选哪个。我不打算逐个罗列框架（那是评测号干的事），只讲我自己的选型方法。文中事实性信息都标了参考来源，数字别全信二手转述。
生态现状：已经不是「选框架」，是「选层」
2026 年年中的 Agent 框架生态，社区共识度较高的一种划分是把工具分成四层，每一层解决不同的问题：
| 层级 | 代表 | 解决什么 |
|---|---|---|
| Runtime（运行时引擎） | LangGraph、自研状态机 | 有状态的流程编排、可精确控制步骤与回退 |
| SDK（开发套件） | OpenAI Agents SDK、Claude Agent SDK | 快速接入某家模型生态的轻量 Agent 开发 |
| 多 Agent 编排层 | CrewAI 等 | 让多个角色化 Agent 分工协作 |
| AI 应用平台（低代码） | Dify 等 | 业务/运营人员也能搭 Agent 应用 |
参考：这一「四层分化」观点在多篇 2026 年社区文章中反复出现（CSDN 番外横评、LearnAgent SDK 年中选型指南）。我认同这个框架，因为它把「选型」从攀比参数变成了先确认自己处在哪一层。
与此同时，各家大厂都出了自己的 SDK（OpenAI Agents SDK、Claude Agent SDK、Google ADK 等）——当工具多到无从比起，「哪个更强」就是伪问题，真正的问法是「我的场景需要哪一层」。
选型方法论：先回答三个问题，再画决策树
Q1：业务形态是「流程型」还是「探索型」？
- 流程型（查库存→开单→通知）：步骤固定、可穷举，需要的是可控的编排与状态管理——对应 Runtime / SDK 层，甚至自写状态机都够。
- 探索型（让 AI 自己决定调什么工具、走几步）：对应需要更强自主性的 SDK 与长上下文管理。
- 我的经验：90% 的企业内场景是流程型，却被做成了探索型——这是 Agent 项目成本失控的第一来源。
Q2：团队规模与语言栈？
- 小团队 / 快速验证：选与主语言生态一致的轻量 SDK，别让「框架学习成本」超过「业务成本」。
- 中大型团队 / 需要长期维护：优先社区活跃、文档齐全、可观测性方案成熟的 Runtime（如 LangGraph），并把状态与图设计纳入评审。
- 没有专职 AI 工程师的企业：直接考虑平台层（Dify 等）或外购方案，自研 Agent 是昂贵的爱好。
Q3：部署与可观测要求？
- 数据出域限制 → 私有化；此时框架是否支持自托管、trace 数据是否本地化，成为一票否决项。
- 生产 Agent 必须有 trace：每次任务的 token、步骤、工具调用、失败点全部留痕（工具见 Langfuse 等）。
决策树（简化版）
业务要不要「自主决定怎么做」？
├─ 不要 → 纯 RAG / 直接调 API / 状态机
└─ 要 → 流程固定吗？
├─ 固定 → Runtime（LangGraph/自研）＋ 强工具 schema
└─ 不固定 → SDK（OpenAI/Claude Agent SDK）＋ 长上下文治理
POC 验收清单（让选型可证伪）
框架评测文章满天飞，但你选的框架必须用你的真实任务验收。拿一个最有代表性的业务任务（不是 hello world），跑通后量四件事：
- 端到端成功率（任务完成率，别只看「答得对不对」）
- 单任务 token 成本与延迟（P50/P95）
- 失败路径行为（工具调用失败、超时、上下文超限时，系统怎么表现）
- 可观测性是否开箱可用（trace 能否定位到「第几步、花了多少 token」）
- 通过标准提前写死，POC 结束写 ADR
踩坑提醒：POC 阶段最容易踩的坑是「只测成功路径」。Agent 系统 80% 的工程投入在失败路径上——验收时专门测「模型犯傻」时的表现，比测它多聪明更重要。
这篇没有给你标准答案，因为 Agent 选型本来就不该有标准答案——你的业务形态、团队和合规要求才是答案本身。我的建议只有一条：别让框架评测文章替你决定，拿自己的任务去做一次 POC，比读十篇横评都有用。
真用起来之后，编排和推理层的工具我在工具栏目里有记录。