2026 Agent 框架图景 —— 以及我自己实际站在哪里
五个主流 agent 框架，每个真正解决什么，我自己的多智能体系统在这张地图 里位于哪里，以及"我们走的路对吗？"的诚实答案。
30 秒电梯版
2026 年大多数 agent 框架（LangGraph、OpenAI Agents SDK、Claude Agent SDK、CrewAI、AutoGen）每个都只解决我之前在 《Agent 系统的五层结构》 里讲的五层中的一两层。没有一个框架解决全部五层。我自己的 多智能体系统试图解决全部五层——诚实的答案是 上层概念领先，下层工程 标准落后。这篇文章画出地图，并告诉你我实际站在哪里。
先声明（读其余之前）
我没有在生产中部署过 LangGraph、OpenAI Agents SDK、CrewAI 或 AutoGen。下面的框架描述综合自官方文档、第三方对比文章、小型实验。 我引用的 benchmark 数字和采用率百分比是二手的。请把这一篇当作 做过功课的二手知识，不是生产实证。涉及我自己系统时，那部分是 直接经验。
为什么写这一篇
我已经写了一系列文章描述自己怎么做多智能体系统。读者读完可能会想 这就是该有的做法。这是错的。我的做法只是地图上的一个点。地图本身 重要。
这一篇就是地图。它也强迫我做一件之前几篇文章让我跳过的事：把自己的 工作放在替代方案旁边，诚实地说出哪里领先、哪里落后、哪里只是不同。
五个主流框架
我把 2026 年五个最被采用的生产框架挨个定位到 五层栈： Memory · Agents · Skills · Rules · Hooks。
LangGraph
它实际是什么：用于编排 LLM 调用的有向图状态机，带条件边、 checkpoint、time-travel 调试。
它解决哪一层：主要是 第 3 层（Skills）——它给你一个干净的方式 来表达”非确定性 agent 调用周围的确定性骨架”。相邻：通过 checkpoint 触及第 1 层 Memory，通过让节点是 agent 调用触及第 2 层 Agents，但它 不主张 persona/specialist 分离。
真正重要的强项：通过 LangSmith 提供生产级可观测性——trace、成本 追踪、调试（注：LangSmith 是 LangChain 的付费产品，带免费额度； LangFuse 是可用的开源替代）；reducer 实现的并行 state 合并；time-travel 调试；成熟生态。
一个常被引用的采用率数据（请当二手处理）：一份归属 Gartner 的 2026 Q1 市场分析报告 LangGraph 出现在大公司约 34% 的生产架构文档里。 我没有读过 Gartner 原报告，只看到对比文章里的二手引用。
弱项：它是工具，不是完整的 agent 框架。你仍要自己设计记忆层、决定 召集多少 persona、写自己的 rules 和 hooks。图范式有学习曲线。
最适合：复杂工作流，带并行分支、循环、审批门。如果团队要跑这个 系统几年，这是稳妥的生产选择。
OpenAI Agents SDK
它实际是什么：基于 handoff 的编排框架（前身是 Swarm），现在已经 生产级——带 sandbox 执行、guardrails、tracing、TypeScript 支持。
它解决哪一层：第 2 层（Agents）+ 部分第 3 层（Skills）。Handoff 抽象是核心设计选择——agent 通过显式 handoff 转移控制权，而不是通过 图。
强项：业界最干净的 handoff 模型，轻量，学得快，与 GPT 模型紧密整合， 内置 tracing。
弱项：锁定 OpenAI 模型（无模型可移植性），handoff 模式在超过 8-10 种 agent type 时变得难以管理，复杂流控制不如 LangGraph。
最适合：已经投入 OpenAI 生态、想要最少抽象 + 干净 agent 转移模型的 团队。
Anthropic Claude Agent SDK
它实际是什么：tool-use 优先的 SDK，agent 是配备 tool 的 Claude 模型， 其中 tool 包括”调用其他 agent”。架构刻意简单：agent loop 收到 prompt、 调 tool、返回结构化响应。
它解决哪一层：第 2 层（Agents）+ 早期第 1 层（通过 MCP 的 Memory）。 差异化在 extended thinking（可见的思维链）、computer use（桌面和浏览器 交互）、Model Context Protocol (MCP)。
强项：安全优先、与 Claude 紧密整合、MCP 标准化记忆/工具访问、 computer use 让 agent 能在真实系统上行动。
弱项：编排层比 LangGraph 弱。如果你需要带 state 合并的并行分支， 得自己实现。
最适合：整个 stack 都跑在 Anthropic 上、或需要 computer use / extended thinking 的团队。或想要最简心智模型的团队。
CrewAI
它实际是什么：基于角色的多智能体框架。你定义”crew”（一组带角色的 agent：研究员、写手、审稿人），框架处理它们之间的任务委派。
它解决哪一层：第 2 层（Agents）——但带一个具体的设计选择， 把 persona（视角）和 specialist（执行者）混在一起。每个 agent 都被期望既推理又产出。
强项：业界学习曲线最平缓——你能在一小时内跑起来一个多智能体系统。 社区最大、模型无关（OpenAI、Anthropic、本地通过 Ollama）。已加 A2A 协议支持。
弱项：基于角色的抽象鼓励了我反对的 persona/specialist 混淆。 一个被频繁引用的 benchmark（来源是第三方对比文章，不是我自己测的） 报告 CrewAI 在复杂多步任务上完成率约 54%、LangGraph 约 62%。把这些 数字当方向性参考，不是权威。
最适合：快速原型、demo、内部工具——这些场景多智能体功能更多是 “人体工学”而不是”严格性”。
AutoGen / AG2
它实际是什么：微软的对话式多智能体框架（现在有时叫 AG2）。多 agent 通过 GroupChat 模式协作，agent 轮流发言。
它解决哪一层：第 2 层（Agents）——对话风格。
强项：内置 agent 间对话模式，研究血统成熟。
弱项：GroupChat 塌缩——agent 几轮内收敛到同一个声音——是社区 报告中反复出现的失败模式；我没有亲自在规模上复现过。生产成熟度 不如 LangGraph 或 OpenAI SDK。
最适合：研究、对话仿真、想让 agent “出声推理”的场景。
协议层（横切）
两个协议正在成为跨框架标准：
- MCP（Model Context Protocol）——Anthropic 推。标准化 agent 如何 和记忆、工具、外部资源对话。已超出 Anthropic 范围被采用。
- A2A（Agent2Agent Protocol）——Google 推。标准化 agent 之间 如何对话，特别是跨组织边界。CrewAI 已加原生支持；LangGraph 和 AutoGen 没有（截至 2026 年中）。
如果你今天造 agent 系统，两个都忽略——18 个月后你会回头去补。至少 原生支持其中一个。
我自己的系统实际站在哪里
诚实版本。逐层走，三个标签：领先（我的方法真的比主流好）、 对等（我做得不一样但只是品味之差）、落后（业界标准更好，我应该 采用）。
第 1 层 Memory
| 能力 | 业界标准 | 我的系统 | 判断 |
|---|---|---|---|
| RAG / 语义检索 | 向量库 + 检索 | 同样，加类型标签 | 对等 |
| 带结果的情景记忆 | 罕见（受 Reflexion 启发） | 是，带结构化 result 字段 | 领先 |
| 原子事实 | 罕见 | 是，自动抽取 | 领先 |
| 温度模型 | 罕见 | 是（hot/warm/cool/frozen） | 领先 |
| 知识图谱 | agent 中罕见（RAG 中常见） | 是（基于 wikilink） | 领先 |
| Trace / 可观测性 | LangSmith、Langfuse | 没有独立 trace 层 | 落后 |
| 概念层（用户状态） | 几乎没人做 | 是（behavioral.md, current-state.md） | 领先 |
净评：在记忆丰富度上领先，在可观测性上落后。trace 这个 gap 是 真实的——episodic memory 告诉我发生了什么，但 trace 告诉我 什么调用了什么、用了多少 token、按什么顺序。两个都需要。
第 2 层 Agents
| 能力 | 业界标准 | 我的系统 | 判断 |
|---|---|---|---|
| Persona/specialist 分离 | 没有任何框架显式做 | 是 | 领先 |
| 反谄媚规则 | 没有框架做 | 是（每个 persona 5 行规则） | 领先 |
| Tool use | 所有 SDK 成熟 | 是（通过 Claude Code） | 对等 |
| Computer use | 仅 Anthropic | 没有 | N/A（不在范围内） |
| Sub-agent 调用 | 所有 SDK | 是 | 对等 |
净评：概念设计领先（persona/specialist + 反谄媚），能力特性落后 （没有 computer use）。概念地比能力地更易守——新版本 SDK 在能力上 追赶比在设计上追赶快。
第 3 层 Skills
| 能力 | 业界标准 | 我的系统 | 判断 |
|---|---|---|---|
| 确定性编排 | LangGraph DAG | Markdown + bash pipeline | 落后 |
| 带 state 合并的并行执行 | LangGraph reducer | Bash 并行，无 state 合并 | 落后 |
| Time-travel 调试 | LangGraph checkpoint | 没有 | 落后 |
| 用户可调用复合操作 | OpenAI handoff、斜杠命令 | /sprint、/recall 等 | 对等 |
| 审批门 / 中断 | LangGraph interrupt() | 没有 | 落后 |
净评：明显落后。我的 skill 层是 markdown + bash，而 LangGraph 提供 完整的状态机框架带 checkpoint 和 reducer。这是工程 gap 最大的地方。
第 4 层 Rules
| 能力 | 业界标准 | 我的系统 | 判断 |
|---|---|---|---|
| 路径/事件触发的行为 | 几乎没框架做 | 是（12 条 rule） | 领先 |
| 写入时自动抽取 | 几乎没框架做 | 是 | 领先 |
| 生命周期整合 | 没有 | 是 | 领先 |
净评：领先，因为大多数框架完全忽略这一层。业界把”rules”当应用代码； 我把它当 agent 系统的一部分。可守性：高。
第 5 层 Hooks
| 能力 | 业界标准 | 我的系统 | 判断 |
|---|---|---|---|
| 生命周期 hook（会话开始/结束） | 没有作为一等概念 | 是（通过 Claude Code） | 领先 |
| 工具前后 hook | 没有 | 是 | 领先 |
净评：领先。原因和 rules 一样——业界没把它当作一层。
横切
| 能力 | 业界标准 | 我的系统 | 判断 |
|---|---|---|---|
| MCP 支持 | 采用率上升 | 部分（通过 Claude Code） | 对等 |
| A2A 协议 | CrewAI、OpenAgents | 没有 | 落后 |
| 跨产品 agent runtime | 各 SDK 都有 | 每个产品自己写 | 落后 |
| 生产 benchmark 数字 | 主流框架都有 | 没测 | gap（个人系统，还没进生产） |
| 每日 dogfood | 业界 demo 多 | 是，但规模小：约 6 周高密度个人使用（自 2026-03-24） | 部分领先 |
那么——我们走的路对吗？
概念路径上对。工程路径上不对。
我领先的地方在上层设计：persona/specialist 分离、反谄媚、 情景记忆、原子事实、显式的 Rules 和 Hooks 层。没有任何主流框架有这些。 今天采用任何一个框架、然后试图把我的概念工作加上去——比反过来更难。
我落后的地方在下层工程：没有 LangSmith 级别的 trace、没有 LangGraph 级别的 state checkpoint、没有 OpenAI 级别的 handoff 抽象、 没有原生 MCP/A2A、没有生产 benchmark。这些不是概念，是标准件。 没有它们就是技术尽调时会被抓的那种 gap。
诚实判断，一口气说：我建了一个业界还没建的系统，但建在一个业界 建得比我好的工程底座上。
这意味着下一步
三个选项，野心递增：
选项 A：留在框架层之上。 把我的系统定位为研究底座，不是生产框架。不要重新发明 LangSmith，不要 重新发明 LangGraph 状态机。继续推进上层（记忆丰富度、persona 纪律、 episodic 模式）。 成本：低。对业界的可守性：中（终究他们会在概念层追上来）。
选项 B：采用一个框架做下层引擎。 选 LangGraph（最有可能）做 Skill 层。在它之上保留我自己的 Memory、 Agents、Rules、Hooks 设计。系统变成混合体：LangGraph 是水管，我的 概念层在上面。Trace 通过 LangSmith 免费拿到。 成本：中。可守性：高——两个世界的优点都拿了。
选项 C：做一个可发布的框架。 把我的概念贡献（persona/specialist 分离、可配置的反谄媚层、带结果类型 检索的情景记忆、把 rules+hooks 当一等公民）产品化为一个开源框架，坐 在 LangGraph 或 Anthropic SDK 之上。这是最有野心的路径，也是建立 长期技术品牌的路径。 成本：高。风险：开源框架的护城河本来就弱——品牌和社区才是 护城河，不是代码。只有你准备投入一年以上做布道，才值得做。
我认为 B 是正确的下一步。C 是更长远的游戏。
怎么在面试里用这一篇
如果被问 “你的工作和主流框架比怎么样”——诚实有立场的答案是上面 那个判断：上层概念领先，下层工程标准落后，我清楚地知道要补哪些 gap。
如果被问 “你为什么不直接用 LangGraph”——答案是：LangGraph 解决 第 3 层（我的系统在这层做得不那么严格），但它不解决第 1、2、4、5 层。把它作为 Skill 引擎采用是正确的下一步，但它不能替代我在其他层 上做的工作。
如果被问 “如果重来你会怎么做”——第一天就采用 LangGraph 做 Skill 层。其他保留。加 LangSmith 做 trace。加 MCP 做记忆契约。
这个答案具体、点名了具体 gap、表现出对过去选择的反思。大多数候选人 要么过度防御自己的实现、要么没有可对比的对象。两个都避开。
写这一篇参考的资料（2026 年 5 月）：
- LangGraph 生产数据：Gartner 2026 Q1 架构文档分析（在 QubitTool 的框架对比 中被引用）
- 框架 benchmark 数字：openagents.org 对比
- 架构哲学：Lindy 框架指南、 LangGraphJS 对比
- 协议支持：A2A 和 MCP 采用情况在上述对比文章中有记录
我没有 LangGraph、OpenAI Agents SDK、CrewAI、AutoGen 的直接生产部署 经验。上面的技术描述综合自文档、对比文章、小型实验。请把它们当作 “做过功课的二手知识”，不是”生产实测的一手证言”。