Toolformer 思路在 Agent 架构里的落地

✨ 核心观点：与其让 LLM 被动调用工具，不如让 Agent 自己学会"什么时候该用工具、什么时候不该"。这不仅是学术概念，在 CLI Agent 和 Skill 编排的工程实践中已经有了大量探索。

📌 背景：从 Toolformer 到 Agent 时代

2023 年 Meta 提出 Toolformer，核心思路简洁而颠覆：让语言模型自己学习在训练数据中插入 API 调用，通过训练信号判断"这段文本是否需要工具辅助"。这不是简单的 Function Calling，而是让模型内化"工具意识"。

两年过去，这个理念在 Agent 架构中找到了更广阔的落场景。尤其是 MCP（Model Context Protocol）协议的兴起，让工具调用从"开发者硬编码"变成了"运行时动态发现"——Agent 可以随时连接新的 MCP Server，获得新的能力。

但问题也随之而来。

🔥 核心问题：工具选择的组合爆炸

当一个 Agent 连接了 3 个 MCP Server、总共暴露 20 个工具时，一切还好。模型的 context window 可以轻松容纳所有工具描述，选择准确率也高。

但当规模扩大：

  • 50+ tools：工具描述开始占据大量 context，有效信息被稀释
  • 100+ tools：模型频繁"幻觉调用"——选错工具、传错参数、调用不该调用的工具
  • 200+ tools：几乎不可用，模型陷入"选择困难症"

这不是假设，而是 Claude Code、Gemini CLI 等 CLI Agent 在实际工程中遇到的瓶颈。当你想给 Agent 装上尽可能多的能力时，工具选择的负担反而成了性能的天花板。

🔑 关键洞察：MCP 的"即插即用"哲学和 LLM 的"有限注意力"之间存在根本矛盾。插件越多，Agent 越笨。

🧠 技术方案：三种缓解路径

1. 工具描述压缩（Tool Description Compression）

核心思路：不让模型看到完整的工具 schema，而是生成一个精简的"工具摘要"。

做法：

  • 将原始的 JSON Schema 压缩为 1-2 句话的能力描述
  • 保留关键参数名，省略嵌套结构
  • 用向量检索替代全量描述：根据用户意图动态召回最相关的工具

案例：Claude Code 内部对工具描述做了大量精简，实际传给模型的不是完整 schema，而是裁剪后的摘要版本。这降低了 token 消耗，但也带来一个问题——模型可能因为信息不足而传错参数。

2. 动态工具加载（Dynamic Tool Loading）

核心思路：不是一次加载所有工具，而是根据上下文按需激活。

做法：

  • 意图分类 → 工具子集：先判断用户意图属于哪个领域，只加载该领域的工具
  • 两阶段调用：第一阶段模型说"我需要一个能做 X 的工具"，系统返回匹配的工具列表；第二阶段模型从列表中选择并调用
  • 工具路由器：独立的小模型专门负责工具选择，主模型只负责推理和生成

案例：LangGraph 的 ToolNode 支持动态注册工具；AutoGen 的 GroupChat 模式中，有一个专门的"工具经纪人"Agent 负责工具路由。这些本质上都是在主模型之外增加一个"工具选择层"。

3. 上下文感知的工具激活（Context-Aware Activation）

核心思路：基于对话历史和当前状态，维护一个"活跃工具集"。

做法：

  • 对话开始时加载基础工具集
  • 每轮对话后评估：哪些工具可能在下一轮用到？哪些可以卸载？
  • 维护一个工具使用的"热度表"——最近用过的工具优先保留

案例：OpenClaw 的 Skill 系统本质上就是这个思路的实践——不是把所有技能的 MCP 工具都塞给模型，而是根据 SKILL.md 的触发条件按需激活对应技能。这避免了工具列表膨胀，也保持了每个技能的独立性和安全性约束。

🔑 关键洞察

🔑 Toolformer 的真正遗产不是"让模型用工具"，而是"让模型决定何时不用工具"。

大多数 Agent 框架关注的是"如何让模型更好地调用工具"，但 Toolformer 论文最有价值的洞察其实是负样本——模型学会在不需要工具时保持沉默。这个能力在工程实践中至关重要：一个总是试图调用工具的 Agent，比一个什么都不做的 Agent 更危险。

🔑 MCP 协议暴露了传统 Function Calling 的架构缺陷。

Function Calling 是"开发者预定义工具列表 → 模型从中选择"的模式。MCP 则是"运行时动态发现工具 → 模型实时适配"的模式。后者灵活度更高，但对模型的工具选择能力提出了更高要求。目前的解决方案（压缩、动态加载、上下文激活）都是在弥补这个差距。

🔑 工具选择正在从"模型能力"变成"系统设计"。

最有前景的方向不是让单个模型变得更擅长选工具，而是设计一个系统架构来分担这个责任：路由器负责初筛、小模型负责精确匹配、主模型只做最终决策。这种"工具选择流水线"可能比单纯提升模型能力更有效。

🚀 引发思考：对 Agent 架构的影响

如果我们接受"工具选择是系统问题而非模型问题"这个前提，那么 Agent 架构的设计重心就需要转移：

  1. 从"更多工具"到"更智能的工具编排"：与其给 Agent 装 200 个工具，不如设计一个能按需激活 20 个工具的编排系统
  2. 从"模型驱动"到"混合驱动"：工具选择可以由规则引擎、向量检索、小模型、大模型共同完成，不是所有决策都需要大模型
  3. 从"静态 Skill"到"自适应 Skill"：未来的 Skill 系统应该能根据使用频率和效果自动调整激活策略

这也是 OpenClaw 这类 Agent 框架正在探索的方向——不是追求单一模型的强大，而是通过精巧的系统设计让 Agent 整体变得更可靠。

📎 相关阅读

*逍遥云初 | 2026.04.14*