《2026 Agent 框架图景》读书笔记

1. 主文章在讲什么（30 秒）

一句话主线：2026 年五个主流 agent 框架（LangGraph / OpenAI Agents SDK / Claude Agent SDK / CrewAI / AutoGen）每个只解决五层栈中的 1-2 层。没有一个解决全部。我自己的系统覆盖五层但概念领先、工程标准落后。下一步：B 选项——采用 LangGraph 做 Skill 层，保留我的概念层。

反对什么观点：

• 反对”用 LangGraph 就够了”——只是第 3 层
• 反对”自己造比框架强”——上层概念可以，下层工程标准化是必要的
• 反对”AI 框架百花齐放”——五层栈让你看清每个框架在哪里

如果只能记一句话：

框架是工具不是答案——五层栈是用来定位框架而不是替代框架的地图。

2. 关键概念词典

五层栈定位每个框架

协议层（横切）

三个下一步选项（来自主文）

我推荐 B。C 是更长远的游戏。

3. 完整脉络（主文章每节展开）

为什么”框架对比”通常是错的问题

业界文章常问”LangGraph vs CrewAI vs AutoGen 选哪个”——这是错的问题。

正确的问法：

1. 你解决的是哪一层的问题？
2. 每个框架解决哪一层？
3. 重叠的部分选哪个？不重叠的部分自己做。

如果你的需求是 “Skill 层的状态机” → LangGraph 强。 如果你的需求是 “Persona/Specialist 拆分” → 没框架做，自己加。 如果你的需求是 “Memory 完整架构” → 没框架做，自己设计。

问”哪个框架更好”等于问”哪个工具更好”——脱离任务的答案没意义。

为什么 LangGraph 是 Skill 层而不是 Agent 层

LangGraph 的核心：directed graph + conditional edges + checkpoint。

它让你用图描述确定性骨架——这是 Skill 层（确定性脚本包住非确定性 agent）。

它不主张 persona/specialist 分离——你可以用，也可以不用。这是第 2 层的事。

它不解决 Memory（除了 state checkpoint，那不是语义记忆）。

业界把它当”完整 agent 框架”卖——这是 marketing。它是 Skill 层的最佳工具，不是 agent 系统的全部。

为什么 CrewAI 在生产部署感觉空

CrewAI 的设计：role-based crews，每个 agent 一个 role。

问题：role 不区分”思考还是执行”。一个 researcher 既研究又写综述，一个 writer 既构思又落字——每个 agent 都跨越 Persona/Specialist 边界。

结果：意见浅、代码乱。Demo 看上去多 agent 协作，生产部署时发现每个 agent 都在做两件相反的事。

CrewAI 不是错的，是只解决了第 2 层的一种形态——而且这种形态有结构性问题。

茶会”概念领先、工程落后”具体在哪

领先（业界没有）：

• Persona / Specialist 显式拆分
• 反谄媚规则可配置
• 6 子层 Memory（特别是 episodic + 概念层）
• Rules / Hooks 显式分层

对等（业界有，我也有）：

• Tool use
• MCP 客户端使用
• Sub-agent 调用

落后（业界做得更好）：

• LangSmith / Langfuse 级别的 trace
• LangGraph 级别的 state checkpoint
• OpenAI Handoff 抽象
• 原生 A2A 协议支持
• 跨产品 agent runtime（业界 SDK 都有，我每个产品自己写）
• 生产 benchmark 数据

N/A（不在我的范围内）：

• Computer use（我的目标用户不需要）
• 大规模生产 benchmark（个人系统）

为什么 B 是正确的下一步

A 太保守——错过工业标准件（trace / state / handoff），技术尽调时被抓。

C 太激进——开源框架的真正护城河是社区 + 品牌，不是代码。没有一年以上布道投入做不出。

B 平衡：

• LangGraph 做 Skill 层 → 工程标准件免费拿到
• 保留 Persona / Specialist 分离、反谄媚、Episodic、Rules、Hooks → 概念领先维持
• LangSmith trace 免费
• 渐进迁移：现有 Skill markdown + bash 一个一个换成 LangGraph 节点

风险：LangGraph 抽象不一定能 host 我所有概念层。需要试。但试错成本低——单次替换一个 Skill 即可。

4. 真实代码 / 数据

五层栈定位的实际表

LangGraph 在我的栈里：

┌─────────────────────────────┐
│ Layer 5 · Hooks   [我自己]   │
├─────────────────────────────┤
│ Layer 4 · Rules   [我自己]   │
├─────────────────────────────┤
│ Layer 3 · Skills  [LangGraph]│  ← 让 LangGraph 接管
├─────────────────────────────┤
│ Layer 2 · Agents  [我自己]   │
│  - Persona (markdown)        │
│  - Specialist (yaml)         │
├─────────────────────────────┤
│ Layer 1 · Memory  [我自己]   │
│  + LangSmith trace [外加]    │
└─────────────────────────────┘

茶会六周数据点（真实）

- 圆桌归档：158 场
- 原子事实：324 条
- 情景记录：84 条
- pattern 文件：28 个
- 图谱边（wikilink）：195 条
- skills：8 个
- rules：12 条
- hooks：3 类（SessionStart / Stop / PostToolUse）
- 总账单：< $5/月（绝大部分免费档）

业界数据点（来源见主文 caveat）

LangGraph: 月搜索 ~27,100（Lindy 数据）
LangGraph in Gartner: 1000+ 人公司 ~34% 生产架构（QubitTool 引用）
LangGraph vs CrewAI benchmark: 62% vs 54%（来源不可考）

注意：以上数字都是二手引用，未直接验证 Gartner 报告。

B 选项的迁移路径（伪代码）

# 现状（v0）：bash + markdown
# scripts/sprint.sh
phase_1_decompose() { ... }
phase_2_dispatch_dev() { ... }
phase_3_review() { ... }

# 目标（v1）：LangGraph
from langgraph.graph import StateGraph

class SprintState(TypedDict):
    goal: str
    tasks: list
    artifacts: list

graph = StateGraph(SprintState)
graph.add_node("decompose", decompose_node)
graph.add_node("dispatch_dev", dev_node)
graph.add_node("review", parallel_review_node)
graph.add_edge("decompose", "dispatch_dev")
graph.add_edge("dispatch_dev", "review")
# ...

迁移可以一个 skill 一个 skill做。

5. 架构图

图 1：五层栈 + 框架定位

   Layer 5: Hooks
   ─────────────────────────────────────────
                 [无框架原生支持]
   ─────────────────────────────────────────
   Layer 4: Rules
   ─────────────────────────────────────────
                 [无框架原生支持]
   ─────────────────────────────────────────
   Layer 3: Skills
   ┌─────────────────────────────────────┐
   │             LangGraph              │ ← 这是它的主战场
   └─────────────────────────────────────┘
   ┌─────────────────────────────────────┐
   │  OpenAI Agents SDK (handoff = skill)│
   └─────────────────────────────────────┘
   ─────────────────────────────────────────
   Layer 2: Agents
   ┌─────────────────────────────────────┐
   │          Claude Agent SDK            │ ← 主战场
   └─────────────────────────────────────┘
   ┌────────────────────────┐ ┌──────────┐
   │       CrewAI            │ │ AutoGen  │
   └────────────────────────┘ └──────────┘
   ─────────────────────────────────────────
   Layer 1: Memory
   ┌─────┐                  ┌────────────┐
   │ MCP │←(via Claude SDK) │ LangSmith  │← (via LangGraph)
   └─────┘                  └────────────┘
                            ┌──────────────┐
                            │  Vectorize/  │
                            │  Pinecone/   │
                            │  Weaviate    │← 业界向量库
                            └──────────────┘

图 2：茶会的”领先 / 落后”位置

   Layer 5: Hooks            ← 茶会领先（业界无）
   Layer 4: Rules            ← 茶会领先（业界无）
   Layer 3: Skills           ← 茶会落后（用 markdown+bash，应换 LangGraph）
   Layer 2: Agents
       Persona/Specialist    ← 茶会领先（业界无）
       反谄媚规则             ← 茶会领先（业界无）
       Tool use              ← 茶会对等
       Computer use          ← N/A（不在范围）
   Layer 1: Memory
       6 子层架构             ← 茶会领先（业界只做 1-2 层）
       Trace / 可观测         ← 茶会落后（应加 LangSmith）

   横切：
       MCP                   ← 对等（作为客户端）
       A2A                   ← 落后（应原生支持）
       跨产品 runtime         ← 落后（应统一）
       Production benchmark  ← N/A（个人系统）

图 3：B 选项的混合架构

   ┌─────────────────────────────────────┐
   │    Layer 5 · Hooks (mine)            │
   ├─────────────────────────────────────┤
   │    Layer 4 · Rules (mine)            │
   ├─────────────────────────────────────┤
   │    Layer 3 · Skills (LangGraph)     │ ← 替换为 LangGraph
   │      + LangSmith trace               │ ← 免费拿到
   ├─────────────────────────────────────┤
   │    Layer 2 · Agents (mine)           │
   │      Persona + Specialist + 反谄媚   │
   ├─────────────────────────────────────┤
   │    Layer 1 · Memory (mine)           │
   │      6 子层 + Episodic + Patterns    │
   └─────────────────────────────────────┘
   
   优点：
   - 上层概念领先维持
   - 下层工程标准免费拿到
   - LangSmith trace 免费
   - 渐进迁移，单 skill 替换

6. 我的批注

我和我以前的想法的冲突

以前：我以为框架对比是”哪个最好”。 现在：每个框架是主打不同层——比较脱离任务没意义。问”我解决哪一层 + 每个框架在哪一层”才是正确问法。

以前：我以为自己造的多智能体系统在所有维度都领先（因为我做了五层，业界没做）。 现在：概念领先 ≠ 工程领先。LangSmith 级别的 trace、LangGraph 级别的 checkpoint——这些是工业标准件。我没有它们就是落后。

以前：我觉得”贡献新概念”和”采用工业框架”是对立的。 现在：它们是互补的。B 选项 = LangGraph 做 plumbing + 我的概念层在上面 = 两个世界优点都拿。对立是 false dichotomy。

反复想过的部分

为什么 C 选项有诱惑但风险高——把概念产品化为开源框架听上去很爽：影响力、社区、技术品牌。但开源框架的真正护城河是社区——代码可以被 fork。没一年以上布道投入做不出社区。我现在没那个带宽。

为什么 A 选项也不行——A = “继续推上层，不动下层”。听上去保守安全，但技术尽调时”你的 trace 在哪”答不上来。工业标准件不是可选——是基础。

LangGraph 能 host 我的所有概念吗——不确定。LangGraph 有 state（适合 Episodic 状态）、有 conditional edge（适合 Rules 触发）、但它没有 Persona/Specialist 区分。这一层我需要在 LangGraph 之上加抽象——用 LangGraph 节点的元数据标识 persona vs specialist。没试过，是 next。

下次会改的

• 真的开始 B 选项的迁移——不只是说，要做一个 PoC：把一个 skill 从 markdown+bash 换成 LangGraph，看 LangSmith trace 能不能 host episodic memory 的写入。
• MCP 服务器化——目前我用 MCP 是作为客户端（Claude Code 自带的 MCP plugins）。应该把茶会的 memory 暴露成 MCP server——让其他 agent 系统能消费。这是从”内向”变”外向”的关键。
• A2A 协议原生支持——我已经用了 A2A 的状态值，但没实现完整的 A2A protocol（artifact + message schema）。完整支持让我的任务 API 直接 A2A 兼容。

7. 面试话术（按时长背三档）

30 秒电梯版

2 分钟白板版

10 分钟深入版

8. 可能被问到的 5 个问题 + 回应

问题 1：你既然推 B 选项，为什么不直接用 LangGraph？

回应：

时间和顺序问题。

LangGraph 出来时（2024）我已经在自己实现 Skill 层。再加上我那时不太确定 LangGraph 能 host 我需要的概念。

现在 LangGraph 成熟了，我的概念也清晰了——适合迁移的时机。但迁移本身有成本——每个 skill 重写、每个团队学曲线。所以是渐进做。

没有理由不迁移，只有理由”分阶段”迁移。

问题 2：你说”概念领先”——是不是你的归纳，业界其实有？

回应：

这是个好问题，我应该承认我不能确定。

我的依据：搜了 LangGraph、CrewAI、AutoGen、Anthropic SDK、OpenAI Agents 的文档和社区——没看到”反谄媚规则可配置”或”显式 Persona/Specialist 拆分”。

可能我漏了——业界有研究项目或学术论文我没读到。但作为框架级原语，它们没在主流采用——这是我有信心的。

如果有人在某个框架里把这些做成 first-class，我会很高兴——意味着我的归纳被验证而且有人更进一步。

问题 3：A2A 协议你说”应该原生支持”，但业界很多框架也没有。为什么是 gap？

回应：

业界不支持是新协议（2025 年成熟）的正常状态。我说”落后”不是因为别人都做了我没做，是因为这个协议会成为标准——OpenAgents 已原生支持，CrewAI 已加支持。

早期采用 vs 晚期采用是判断：早期采用的成本是协议变化风险，收益是未来跨系统互操作零成本。

我现在落后是判断没做，不是不应该做。Next quarter 应该补。

问题 4：你的诚实评估听起来很谦虚——是不是低估自己了？

回应：

谢谢。但我觉得没低估——

概念领先是真的（Persona/Specialist 分离 + 反谄媚 + 6 层 Memory 业界确实没人显式做）。

工程落后也是真的（没 trace 是真问题，没 checkpoint 是真问题）。

诚实评估的价值就在它的两边都被认真说——不只是”我哪里好”，也是”我哪里不够”。面试官最在意的是后者——能说出自己 gap 的候选人是少数。

问题 5：如果 LangGraph 收购或挂了怎么办？

回应：

这是真风险。LangGraph 是 LangChain 系，未来商业化路径不完全确定。

我的应对：

1. 抽象层隔离——我的 Skill 接口不直接是 LangGraph API，是我自己定义的 Skill 接口（实现是 LangGraph）。换实现时接口不变。
2. LangGraph 的核心概念是通用的——状态机、conditional edge、reducer——任何 DAG 库都能实现。真要换不是从零。
3. 关键监控——LangChain 商业化进展、社区健康度。坏信号出现时提前迁移。

没有 vendor lock-in 完美避免方案，只有 mitigated lock-in。

9. 相关链接

内部（其他主文章）

• Five Layers of an Agent System — 这一篇是它的应用
• Persona vs Specialist Split — 第 2 层差异化
• Memory as Foundation — 第 1 层差异化
• Anti-Sycophancy Rule — 反谄媚规则的具体实现

外部参考（业界对比文章）

• QubitTool: 2026 AI Agent Framework Comparison
• openagents.org Comparison (2026)
• Lindy: Best AI Agent Frameworks 2026
• LangGraphJS Comparison

外部参考（具体框架）

• LangGraph 官方文档
• OpenAI Agents SDK
• Anthropic Claude Agent SDK
• CrewAI 官方文档
• Microsoft AutoGen

协议参考

• Model Context Protocol
• A2A Protocol — 在 GitHub 搜 “a2a-protocol”