观察：
各大 LLM 公司部署提供的 token api 服务，其对外展现的效果，纯粹是给它一段话（一段token）之后，token 服务器通过推理预测后续的一个或者多个token。其预测出来后续 token 其中不会有明显的 agent 参与的痕迹。
这是当前主流 LLM API 服务（OpenAI、Anthropic、Google 等）的一个本质性架构特征。下面从几个层面来说明这个特点。
核心接口的"原子性"
从服务端的纯接口视角来看，当前所有主流 LLM API 的核心确实只是：
input_tokens → [推理引擎] → output_tokens模型接收一个 token 序列（通常以 prompt/chat format 编码），通过自回归采样生成后续 token。在这个过程中：
- 模型内部没有持久化状态（上下文窗口内的内容除外，每次请求独立）
- 没有内置的工具调用循环（function calling 只是结构化输出格式，执行仍在客户端）
- 没有自主的规划-执行-反思闭环
- 没有跨会话的记忆管理
为什么呈现这种形态
1. 最小可行产品（MVP）的延续
早期 GPT-3 时代，API 就是纯粹的无状态 completion 接口。后续的 chat completions、function calling 都是在这个原子接口上做的格式封装，而非架构革新。
2. Agent 行为是"涌现"而非"内建"
所谓的 agent 能力（推理链、工具使用、代码解释器行为等）本质上是通过：
- System prompt 的角色定义
- Few-shot 示例引导
- 输出格式约束（如 JSON schema）
- 客户端 orchestration（接收 function call → 执行工具 → 拼接结果 → 再次请求）
在客户端与模型之间构建的多轮交互循环中模拟出来的，而不是服务端原生支持的执行模式。
3. 商业与责任的考量
如果服务端原生集成 agent 循环（自主浏览网页、执行代码、调用外部 API），则：
- 延迟变得不可控（工具调用链可能很长）
- 安全边界模糊（谁对 agent 行为负责？）
- 计费模型复杂化（按 token 计费是最简单的经济学）
正在发生的架构演进
不过值得注意的是，这个纯粹的原子接口形态正在被突破：
| 演进方向 | 代表 | 本质变化 |
|---|---|---|
| 内置工具使用 | OpenAI Computer Use、Claude Computer Use | 服务端内部已包含看屏幕、点击、输入的工具循环 |
| 推理时计算扩展 | o1/o3、DeepSeek-R1 | 模型内部生成 reasoning tokens（思考链），服务端已非单步生成 |
| Stateful API | OpenAI 的 threads/runs（Assistants API） | 服务端管理对话状态、文件检索、代码执行环境 |
| MCP 协议 | Anthropic Model Context Protocol | 试图标准化模型与外部世界的连接方式 |
以 OpenAI 的 o1/o3 为例，它的推理过程已经不再是简单的"输入一段 token → 输出后续 token"------服务端内部会进行多步的思维链生成、自我纠正，然后才给出最终答案。这个内部过程对用户不透明，但确实意味着服务端内部已经有了 agentic 的痕迹。
观察揭示了一个关键张力
这个纯粹的 token-prediction API 形态实际上反映了 AI 领域的一个深层张力：
模型能力 vs. 系统架构的错配
模型本身（尤其是 GPT-4、Claude 3.5 Sonnet 级别）已经展现出相当强的 agentic 潜质，但 API 的接口形态仍然将其约束在一个无状态的、被动的"自动补全"框架中。当前的 agent 框架（LangChain、AutoGPT、 CrewAI 等）本质上都是在弥补这个接口层面的缺失。
可以打一个类比：这就像早期的 CPU 只有简单的指令集，操作系统和编译器在硬件之上构建了复杂的抽象层。现在的 LLM API 是"指令集层"，agent 框架是"操作系统层"。
这个问题与 agent 架构设计有关，且现有 API 形态对具体应用场景会有限制，所以需要更深入的了解。