This article has an English version available.

LLM 代理在 2026 年为何会变成如今的样子？

by Yanli 盐粒 in 2026-01-19

1) LLM 代理简史 ​

第一阶段：结构化输出 ​

LLM 就像一个魔法函数：它接收输入并输出结果。这与我们日常写代码的方式相似，但关键区别是——输入和输出都是自然语言。

当我们需要 LLM 行为更确定时，就必须让它输出机器可读的格式，也就是结构化输出。有了结构化输出，这个魔法函数就可以嵌入到普通的程序函数中。

第二阶段：工具调用 ​

工具调用本质上是结构化输出的第一种标准化封装，由 OpenAI API 引入，并逐渐成为 LLM API 的事实标准。

它提出了“工具”的概念，工具接收 JSON 参数。这样一来，魔法函数就能与普通函数衔接起来。不过，这个 API 本身并不会真的执行工具——它只返回参数。从这个意义上说，工具调用仍然是结构化输出，只是接口更明确。

第三阶段：MCP ​

那到底谁来执行工具？MCP 补上了这个缺失的角色：工具运行时。

在它内置的客户端-服务端架构里，MCP 客户端基本就是对工具调用的封装，只是它还会调用 MCP 服务器。真正执行工具的组件是 MCP 服务器。

第四阶段-1：Bash ​

在我看来，MCP 是一种过度工程化的方案，最终没能成为通用解。

从 gpt-3.5-turbo 时代开始，LLM 就展现出强大的编码能力，不仅能写主流语言（如 Python），还包括：

  • JSON（如上所述：结构化输出与工具使用的基础）
  • Bash。Bash 成为代理的“元工具”：可能是代理唯一需要的工具。有了 Bash，代理就能运行 curl、wget、gh（GitHub CLI）等。这让许多 MCP 风格的应用变得多余。

第四阶段-2：文件系统 ​

当我们深入代理开发时，会遇到一些问题：

  • 某些工具输出过大，超过上下文窗口，或生成无法直接返回给 LLM 的产物，比如图片（假设 LLM 不是多模态）。
  • 要处理这些产物，我们需要额外工具，例如：
    1. 用多模态 LLM 总结图片内容，或
    2. 用 zip 压缩它，或
    3. 上传到互联网。
  • 问题在于，这些选项可能都同时有效。那就需要 3 个不同工具：
    • generate_img_and_summarize
    • generate_img_and_zip
    • generate_img_and_send
  • 如果再加入音频生成，就又要增加 3 个工具！随着组合增多，工具数量会呈指数增长。

根因在于：中间产物（图片、音频、长文本）无法在一步内直接返回给 LLM。为了解耦工具组合，我们需要一个地方存放这些中间产物，让代理在后续轮次中再决定下一步该做什么。

这就是文件系统。

第四阶段-3：Bash 和文件系统的运行时是什么？ ​

答案是：操作系统。

2) 下一阶段 ​

Bash 看起来像“一统天下”的超级元工具，但很多任务并不能只靠 Bash 完成。浏览器就是一个很好的例子——它是终极 GUI 程序。GUI 的设计本身就是为了绕过 TTY，因为复杂任务会压垮人的上下文窗口。

同时，LLM 本身也在与代理设计共同演化。随着以下创新出现：

  • 思考与输出分离，
  • 用 RL 改进结构化 JSON 输出与编码，
  • 更长的上下文窗口，

一些工程实践可能会过时。例如：

  • 一旦结构化输出被标准化，ReACT 就不再那么必要。
  • 一旦思考/输出分离在训练阶段就被纳入，CoT 提示词与 CoT 工作流的重要性会下降。

3) 问题 ​

权衡：延迟 vs. 质量 ​

当我使用编码代理时，我总是选用 SOTA 模型，愿意等待更久换取更好结果。但在很多场景下，用户希望响应在可接受的延迟内。

在聊天机器人场景，我认为 TTFT 最多应为 20–30 秒。这也是非代理式 RAG 仍然存在的原因之一。

可复现性 ​

即使用户愿意等待更高质量，他们仍然希望等待时间可预测、输出一致。因此，工作流仍然重要。

权衡：隐私/成本 vs. 质量 ​

在很多情况下，用户会出于隐私或成本考虑选择更小的开源权重模型——甚至是边缘设备级的模型。

多模态代理 ​

除了面向程序员的编码代理之外，很多用户还需要具备浏览器操作、电脑操作或与特定 GUI 交互能力的代理。

4) Agent-Skills 呢？ ​

从技术上说，agent-skills 只是一个动态提示词注入协议（代理决定加载哪些提示词），前提是代理构建在上面描述的第四阶段之上。实际上，它不过是一组文件而已。

但与 MCP 相比，agent-skills 更可能被广泛采用，因为：

  • 它以文件夹形式自包含，易于分发；
  • 它简单，可在不依赖运行时或其他依赖的情况下分发——前提是客户端代理已经运行在第四阶段；
  • 由于它面向 OS 运行，任何在 OS 上可用的东西都能被打包进来——prompt.md、tools.sh、helper.py，甚至 bin/executable、lib/library.so、Minecraft.zip（如果代理足够聪明能玩）、Tutorial: Beat Ender Dragon with HALF A Heart.mp4（如果代理能做到）等。

总之，agent-skills 是一个有前景的协议。一个第四阶段的代理系统可以作为客户端去使用其他提供方的技能，或作为系统向其他代理提供技能。动态提示词注入的理念可以支持良好的系统设计，但这种设计与 agent-skills 协议本身是独立的。

如果一个 OS 发行版可以这样做：pacman -S someprogram someprogram-agent-skill？

参考：