Loading…

全景图：agent 生态分 5 层

把 agent 生态画成一张分层图。每层都有自己的主问题，每层都有可替换的代表玩家——理解这张图后，再看任何新框架都能 30 秒定位它在哪。

Reference / Market Watch Level 1 · 生态预读阅读时间 · 24 分钟练习 · 建议做中波动 Last reviewed · 2026-04-22

你将学会什么

理解《全景图：agent 生态分 5 层》在 agent harness / coding agent 学习路径里的核心作用。
能用本页给出的判断法区分“概念、机制、边界、代价”。
知道这页内容之后会在哪一章被复用到源码阅读或动手实践里。

学习前提

建议先读《本章索引》；如果你是跳读，至少先看本章索引与本页 TL;DR。

这页在课程中的位置

生态地图与预读材料，帮助你给后续概念找现实落点。

本页 1 句话结论

把 agent 生态画成一张分层图。每层都有自己的主问题，每层都有可替换的代表玩家——理解这张图后，再看任何新框架都能 30 秒定位它在哪。

带走的判断法

先分层，再看厂商；先看抽象位置，再看 marketing 叙事。

Source Policy

生态预读：优先官方文档，其次稳定实现观察。

TL;DR

不分层就只能列名单。把 agent 生态拆成 5 层，每层各有"主问题"，问题是正交的，因此每层都可以独立选型、独立换。
5 层从下到上：L1 模型 API → L2 工具协议 → L3 循环 / Harness → L4 框架 / 模板 → L5 产品。
真实系统都是跨 5 层的"组合栈"。Claude Code 与 Cursor 的差异，本质是这 5 层的不同选择叠加出来的。
不存在"agent 框架的标准答案"。哪一层适合自己写、哪一层适合买现成的，是每个团队各自的工程权衡，不是技术先进性问题。

1. 为什么要"分层"地看

读 agent 圈的文章时，最让人头大的是这种句子："我们和 LangGraph 不一样，我们更接近 Claude Code 的设计哲学，但又借鉴了 Anthropic 的 SDK 思路。" 一句话里塞了 4 个名字，每个名字都长得像同一个东西。

把它们摆到分层图上，立刻就分得开了：LangGraph 是循环层的图编排引擎；Claude Code 是产品层的端到端 CLI；Anthropic SDK 是模型 API + 工具协议层的官方客户端。它们解决的根本不是同一个层次的问题——所以"不一样"和"借鉴"都很正常。

一个有用的反问

下次有人介绍一个新 agent 框架/产品时，先问自己："它在 5 层里占哪一层？" 如果它声称"全栈打通 5 层"——那就要警惕了，因为这通常意味着它在每一层都做了强假设、可替换性很差，迁移成本会很高。

2. 五层全景图（点点看）

下面这张图是可交互的。三种玩法：

点左侧的层名（如 L3 · 循环 / Harness）——看这一层在解决什么。
点任意一个框架/产品按钮——看它的简介。
点顶部"看一个产品的完整组合栈"里的某个产品——5 层中它用到的部分会高亮，让你一眼看清"它的栈是怎么搭出来的"。

看一个产品的完整组合栈：

L5产品

L4框架 / 模板

L3循环 / Harness

L2工具协议

L1模型 API

默认状态。点击左侧层名 / 任一框架按钮 / 顶部产品胶囊试试。

提示：这张图不追求穷举。每层只列了在中文/英文圈最常被讨论的几个，重点是层之间的关系。

3. 逐层细讲

L1 · 模型 API ——「token 进、token 出」

最底层。它对外只承诺一件事：你给我一个 messages 数组（+ 可选的 tools / response_format），我还你一个 assistant message。没有循环、没有 tool 执行、没有 state 持久化，这些全是上层的事。

代表玩家：OpenAI Chat Completions / Responses API、Anthropic Messages、Google Gemini、xAI Grok，以及通过 vLLM / Ollama / TGI 自托管的开源模型。它们之间最大的差异不在 raw token 生成质量，而在原生支持哪些工具协议（详见 L2）和response 流式 / 缓存语义。

L2 · 工具协议 ——「让模型的'意图'能被解析成'动作'」

L1 只会出 token，但你想让它"调一个工具"。这一层给"工具调用"定下协议：模型按什么格式输出动作意图、runtime 按什么格式回灌结果。

四个主流协议：① OpenAI function calling（最早走通 + 生态最大）；② Anthropic tool_use（设计稍晚、对多 tool 并行更友好）；③ Structured Output / JSON Schema（不是"动作"协议，是"回复格式"协议——常被混淆，详见 00 章 03 节）；④ MCP（不是模型侧协议，是工具侧协议——把工具变成可发现的服务）。

L3 · 循环 / Harness ——「谁来跑 while True」

L1 + L2 完成"一轮对话 + 一次工具调用"。但 agent 是多轮循环：调一次工具 → 看结果 → 再调 → 再看 → ... 直到完成。这一层负责把 L1/L2 跑成一个循环。

选择：手撸 while-loop（最简、最透明，30 行能跑通）；LangGraph（用图节点表达 loop，可中断、可恢复、可分支）；OpenAI Agents SDK 的 Runner（隐藏循环，对外暴露 Runner.run(agent, input)）；Claude Agent SDK（Anthropic 自家的 harness，也支持 hooks/MCP/permission）；Vercel AI SDK（前端首选，流式优秀）；inspect-ai（评测场景的 harness）。

关键差异：循环怎么被中断、怎么被恢复、怎么被观测。这一层选不对，后面 long-horizon agent 的所有"中断 + HITL + checkpoint"都会很难做。

L4 · 框架 / 模板 ——「在 L3 上叠加'高级能力'」

L3 让你能跑一个朴素 ReAct loop。但真实任务里你还想要：planner（write_todos）、虚拟文件系统、subagent、auto summarization、HITL 中断、permission……这些"加法"由 L4 提供。

主流玩家：Deep Agents（LangChain 出品，在 LangGraph 上叠 planner/VFS/subagent 三件套）、AutoGen（微软主推，主打 multi-agent group chat）、CrewAI（"角色化 agent"语义最重）、smolagents（HF 出品，CodeAgent 让模型直接写 Python 当作 action）、Mastra（TypeScript 生态首选）、LlamaIndex Agents（数据 / RAG 友好）、Pydantic AI（强类型、验证友好）。也很多团队选择"自建模板"——直接基于 L3 写自己的封装。

L5 · 产品 ——「面向终端用户的端到端 agent」

L4 是"给开发者用的库"，L5 是"给最终用户用的应用"。Coding agent 是 L5 最成熟的子品类：Claude Code（Anthropic CLI，自家完整栈）、Cursor（IDE，多模型路由 + diff 协议）、Codex CLI（OpenAI 的，命令行 coding agent）、Aider（开源 CLI，对 prompt/patch 协议非常显式）、Devin（Cognition）、Manus、Replit Agent。

L5 的"加法"和 L4 不同：它加的是产品向的东西——多模态 UI、IDE 集成、长 session 状态、用户偏好、计费、协作。技术架构上 L5 内部仍然依赖 L1–L4 的某种组合栈。

4. 层与层之间：谁可以替换谁

分层最大的好处是：每一层可独立替换。但替换成本不一样。

替换	难度	典型理由
换 L1（GPT → Claude → Gemini）	🟢 易	provider 抽象普遍；prompt 微调即可；要注意工具协议差异
换 L2（function calling → MCP）	🟡 中	tool 注册和分发逻辑变；模型侧基本不动
换 L3（手撸 → LangGraph → OAI Runner）	🟠 较难	整个状态结构 / 中断点 / hook 重写；这是迁移成本最大的一层
换 L4（DeepAgents → AutoGen → smolagents）	🟠 较难	planner / subagent / VFS 接口都不同；prompt 模板要重写
换 L5（Cursor → Codex / Claude Code，乃至 → Devin）	🟢→🟡 比想象中轻	好的 L5 产品最后都收敛到"自然语言 + review / approve"这几个通用原语，所以—— 个人 + 同品类（Cursor ↔ Codex CLI ↔ Claude Code）：基本只是 UI / 快捷键差异，几小时 → 🟢；跨品类（IDE 形态 → 异步 SWE 如 Devin / Manus）：是工作流调整（同步盯着改 → 丢任务等回包），不是心智重建，1–2 天 → 🟡；团队 + 深度集成（共享 rules、自建 MCP、CI 接入、HITL 协议、审计 / 计费）：唯一真正贵的子情形，但贵在"组织约定"而非"工具本身" → 🟡

设计直觉：替换成本是 U 型，不是单调的

很多人凭直觉以为"越上层越难换"，其实不对。把替换成本沿 5 层画出来更像一个 U 型：

L1 易换——靠"接口标准化"。各家 API 长得像，provider 抽象普遍。
L3 / L4 最难——既没标准化、又没抽象兜底。状态结构 / 中断点 / planner / VFS 各家都自有一套，迁移就是重写。
L5 也易换——靠"产品抽象"。好的 L5 把所有架构差异藏进了 UX，最终对用户暴露的就是"自然语言 + review / approve"几个通用原语。做得越好的 L5，越显得"换起来无所谓"——这恰恰是产品力的体现，不是反例。

结论：把 L3 想清楚，是 agent 系统设计里收益最高的决策。L1 / L5 都有外部力量（标准 / 产品）替你压低成本，唯独 L3+L4 这段中间地带，没人能替你抽象——它就是真正决定"几年内你的 agent 长什么样"的那一层。

5. 4 个真实组合栈对照

选 4 个差异最大的真实"栈"摆在一起对比。每行是某产品/方案在 5 层各自用什么。粗体的是该方案的"招牌选择"。

	L1 模型	L2 协议	L3 循环	L4 框架	L5 产品
Claude Code	Claude （自家）	Anthropic tool_use + MCP	自家 harness（Claude Agent SDK 同源）	自建（不是任何开源框架）	CLI · 自家产品
Cursor	多供应商路由（OpenAI / Anthropic / 自家）	各家原生协议	自建 harness	自建（IDE 专用 diff/patch 模板）	IDE · 自家产品
DIY · LangGraph + DeepAgents	任意（provider 抽象）	任意（统一在 LangChain message 抽象下）	LangGraph（图编排 + checkpoint）	Deep Agents（planner + VFS + subagent）	— 自己开发
DIY · 手撸 OpenAI loop	OpenAI 系	OpenAI function calling	手撸 while-loop（30 行）	无	— 自己开发

三个观察

头部产品（Claude Code / Cursor）普遍自建 L3 + L4。背后逻辑：L3 + L4 决定了"agent 的灵魂"，外部框架的中断 / 状态语义不一定符合产品级要求。
开源框架（DeepAgents / AutoGen）的甜蜜点是"业务团队 DIY agent"。它们替你解决了 L3 + L4 的脏活，让你专注 L5 想做什么。
"手撸 while-loop"完全不丢人——很多探索期 / 评测场景 / 学习场景，30 行的循环远比 LangGraph 好用。选型不是选高级，是选"和当下任务复杂度匹配"。

6. 在 00 章三轴上的位置

分层与三轴是正交的视角：

分层告诉你"这个软件在生态里负责哪一层的问题"。
三轴告诉你"跑起来后，自由度落在了 LLM 还是代码"。

最强相关的层是 L3 + L4：A 轴（控制流）由 L3 决定（图 / Runner / 手撸 loop 直接对应不同的"谁来 dispatch"），B 轴（动作空间）由 L4 决定（你给了 agent 多少高级能力作为 tool），C 轴（终止）则是 L3 + L4 一起的事。L1 + L2 与三轴几乎无关——同一个 GPT-4o 上能跑出 L0 也能跑出 L6 的系统，关键看 L3+L4 怎么组装。

7. 与其他章节的联系

上游：
- 00 · 01 什么是 Agent —— 三轴框架是本章第 6 节的工具。
- 00 · 03 Tool Calling —— L2 的所有协议都在那一节展开。
- 00 · 04 Agent vs Workflow —— 七档谱系是 L3+L4 选择的具体形态。
下游：
- 01 · 02 代表性 Agent SDK 巡礼 —— 把 L3+L4 的 6 个代表玩家并排对比。
- 03 · 主流 Coding Agent 产品架构 —— 把 L5 的 4 个最强产品展开。
- 04 · 同概念的不同实现 —— 把 L4 各家的 planner / subagent / VFS / HITL 横向对照。

常见误解

常见误解：先选工具，再补抽象。更稳的顺序是先建立分层地图，再决定哪些框架值得投入时间。

最小练习 / 思考题

最小练习：把你正在用的一个工具放进站点的分层地图里，并写下它解决的主问题而不是功能列表。

学完自检

展开 3 个针对本页的检查点

能把 LangChain、Agents SDK、Coding Agent 产品和基础设施放进 5 层地图。
能解释为什么“agent framework”不等于产品、runtime、sandbox 的总和。
能用这张地图避免把 SDK、IDE 产品和托管平台混在一起横评。

下一页为什么值得学

下一页会把这页结论推进到《代表性 Agent SDK 巡礼》，帮助你把知识链条接起来。

章节定位：01 · Frameworks。