AI Agent 生态的层次思考

发表信息: by

AI Agent 生态的层次思考

当我们谈论 AI Agent 的时候，我们到底在谈论什么？

引言

过去一年，AI Agent 的概念被反复提及，但大多数讨论都停留在"某某框架很好用"、"某某产品很火"的层面。很少有人从生态层次的角度，去思考这个领域的整体结构。

本文尝试回答一个问题：AI Agent 生态，从底层硬件到用户交互，一共分几层？每层解决什么问题？

这不是一篇框架对比文章，而是一次关于生态结构的思考。

完整的层次结构

层次 主要解决的问题
产品层 用户怎么用？用什么界面交互？怎么让非技术用户也能扩展能力？
Agent Runtime 层 怎么让 Agent 持续运行？怎么管理长期记忆、Skill、任务队列？
Agent SDK 层 怎么编排多个 Agent？怎么注册 Tool？怎么封装 MCP？怎么保证结构化输出？
Agent Loop 层 怎么实现一次完整的推理闭环？什么时候调 Tool，什么时候返回结果？
Provider SDK 层 怎么屏蔽不同 LLM 的 API 差异？怎么做到切换模型不改业务代码？
LLM API 提供标准的语言理解和生成能力
模型推理服务层 怎么把模型跑在本地？怎么优化推理速度和成本？
基建层 算力从哪来？怎么保证稳定性和扩展性？

用一张图来看整体结构：

┌─────────────────────────────────────────────┐
│                  产品层                       │
│        OpenClaw / Claude Code / Cursor       │
├─────────────────────────────────────────────┤
│              Agent Runtime 层                │
│       长期记忆 / Skill 管理 / 任务队列        │
├─────────────────────────────────────────────┤
│               Agent SDK 层                   │
│  Tool 注册 / MCP 封装 / 多 Agent 编排         │
│  Eino / pydantic-ai / LangChain / Agents SDK │
├─────────────────────────────────────────────┤
│              Agent Loop 层                   │
│         LLM ↔ Tool 推理闭环循环               │
├─────────────────────────────────────────────┤
│             Provider SDK 层                  │
│   OpenAI SDK / Anthropic SDK / LiteLLM       │
├─────────────────────────────────────────────┤
│                LLM API                       │
│   OpenAI / Anthropic / Gemini / DeepSeek     │
├─────────────────────────────────────────────┤
│             模型推理服务层                     │
│          Ollama / vLLM / Triton              │
├─────────────────────────────────────────────┤
│                 基建层                        │
│          GPU / TPU / 云计算基础设施            │
└─────────────────────────────────────────────┘

下面逐层展开。

各层详解

基建层

核心问题：算力从哪来？

这是整个生态的物理基础。GPU、TPU、网络、存储，构成了 AI 时代的"电力和公路"。对于大多数开发者来说，这层是黑盒——要么用云厂商托管（AWS、GCP、Azure），要么自建机房。

这层的问题不是软件问题，是资源问题。

模型推理服务层

核心问题：怎么把模型跑起来？

当你不想依赖云端 API，想把模型跑在自己的机器上时，就需要这一层。Ollama、vLLM、Triton 是代表性的工具。

这层解决的问题是：

  • 模型加载和版本管理
  • 推理速度优化（量化、批处理）
  • 对外暴露统一的 API 接口

值得注意的是，这层通常会模拟 OpenAI 的 API 格式，使得上层无需感知模型是云端还是本地。

LLM API 层

核心问题：提供标准的语言理解和生成能力。

OpenAI、Anthropic、Google Gemini、DeepSeek、通义千问……这些是 LLM API 的提供者。

这层本身不是开发者"建造"的，而是开发者"使用"的。但它是整个生态的核心驱动力——模型能力的提升，会直接影响上面所有层的可能性边界。

Provider SDK 层

核心问题：怎么屏蔽不同 LLM 之间的 API 差异？

每家 LLM 的 API 格式、鉴权方式、streaming 实现、tool call 格式都不一样。如果业务代码直接调用各家 SDK，切换模型就意味着大量重写。

这层的代表就是各家官方 SDK：

  • OpenAI SDK
  • Anthropic SDK
  • 豆包 SDK
  • Gemini SDK

以及一些统一封装的库，它们把不同 Provider 的差异抹平，让上层只需要关心"我要调用一个 LLM"，而不是"我要调用 OpenAI 的 GPT-4o"。

Agent Loop 层

核心问题：怎么实现一次完整的推理闭环？

这是 Agent 的最小工作单元，本质上是一个循环：

调用 LLM
  ↓
有 tool call？
  ↓ 是          ↓ 否
执行 tool      返回结果
  ↓
再次调用 LLM
  ↓
（重复直到结束）

这一层只知道"tool"这个抽象概念，不知道 MCP，不知道 Skill，不知道记忆。它只负责把一次推理任务跑完。

关键点：tool 从哪来、怎么注册，不是 Loop 层的问题，是上层传进来的。Loop 层只负责"执行"。

Agent SDK 层

核心问题：怎么方便地构建和编排 Agent？

在裸 Loop 之上，SDK 层提供了更丰富的能力：

  • Tool 注册和管理：让开发者方便地把函数变成 tool
  • MCP 封装：把 MCP server 包装成 tool，让 Loop 无感知
  • Structured Output：保证模型输出符合预期的数据结构
  • 多 Agent 编排：让多个 Agent 协作完成复杂任务

这层是大多数"AI 框架"存在的位置，比如 Eino、pydantic-ai、LangChainGo。

多 Agent 编排值得单独说一下。单个 Agent 能力有限，复杂任务需要多个专门的 Agent 协作。SDK 层提供了两种典型模式：

  • Transfer：把任务完全交给另一个 Agent，当前 Agent 退出（类比转接电话）
  • AgentAsTool：把另一个 Agent 当做 Tool 调用，拿到结果后继续处理（类比派人办事）

Agent Runtime 层

核心问题：怎么让 Agent 持续运行，而不是一次性的？

这是目前生态中最缺失、最值得关注的一层。

Agent SDK 解决的是"单次运行"的问题：给定输入，跑一次，输出结果。但真正有价值的 Agent 应该是持续运行的，它需要：

  • 长期记忆：记住上周和你说过的事
  • Skill 管理：知道自己能做什么，动态加载新能力
  • 任务队列：有积压的任务要处理
  • Heartbeat 机制：定时醒来检查是否有新任务
  • 状态持久化：崩溃重启后能恢复到之前的状态

目前这层没有一个独立的、被广泛采用的解决方案。OpenClaw 这类产品顺带做了这件事，但它同时也在做产品层的事。

这层的空缺，是当前生态最大的机会之一。

产品层

核心问题：怎么让用户真正用起来？

这层面向的是终端用户，不是开发者。它解决的问题是：

  • 用什么界面交互（消息 App、Web、CLI）
  • 怎么让非技术用户也能扩展 Agent 的能力
  • 怎么设计产品体验

OpenClaw 是这层的代表：通过 WhatsApp、Telegram 等消息 App 作为入口，普通用户发一条消息就能让 Agent 执行复杂任务。它在中国引发的"养龙虾"热潮，说明这层产品的爆发力。

关于现有框架的定位

一个容易犯的错误是把某个框架"钉"在某一层。实际上，大多数框架都是垂直跨层的：

  产品层 Runtime层 SDK层 Loop层 Provider SDK
OpenClaw ✅ ✅ ✗ ✗ ✗
Claude Code ✅ ✅ ✅ ✅ ✗
Cursor ✅ ✅ ✅ ✅ ✗
Eino ✗ 部分 ✅ ✅ ✅
OpenAI Agents SDK ✗ ✗ ✅ ✅ ✗
pydantic-ai ✗ ✗ ✅ ✅ ✅
LangChain ✗ ✗ ✅ ✅ ✅
Vercel AI SDK ✗ ✗ ✅ ✅ ✅
LiteLLM ✗ ✗ ✗ ✗ ✅

没有任何一个框架专注只做一层。这既是现状，也是机会——每一层都有空间做一个专注、深度的解决方案。

从表中也能看到一个有趣的规律：越靠近用户的产品，覆盖的层次越多。Claude Code、Cursor 这类产品几乎从产品层一直做到 Loop 层，因为它们需要完整控制用户体验。而 LiteLLM 这样的工具则专注在一层，做到极致。

一个有趣的类比

如果用操作系统来类比：

基建层          ↔  硬件
模型推理服务    ↔  固件 / 驱动
LLM API        ↔  CPU 指令集
Provider SDK   ↔  硬件抽象层
Agent Loop     ↔  进程调度
Agent SDK      ↔  编程语言 / 标准库
Agent Runtime  ↔  操作系统
产品层         ↔  应用程序
用户           ↔  用户

OpenClaw 自称 "AI Operating System" 不是没有道理——它确实在填 Runtime 层和产品层的空白。但真正的"AI OS"应该是一个独立的 Runtime 层，让各种产品都能在上面运行，而不是一个大而全的单体。

结语

AI Agent 生态还处于早期，各层的边界还很模糊，大量工作被打包在同一个框架里。但随着生态成熟，分层会越来越清晰，专注做好一层的机会也会越来越多。

理解层次，才能找到自己的位置。

本文是一次关于 AI Agent 生态结构的思考梳理，欢迎讨论和补充。