2026年,Agent工具使用的研究焦点正从"如何调用已有工具"转向一个更具颠覆性的命题——Agent能否自主创造工具? 从LATM(LLM as Tool Maker)的开创性框架,到CREATOR解耦创造与使用,再到ACL 2025的ToolMaker将GitHub仓库自动转化为Agent工具、Anthropic推出MCP Code Execution将工具调用范式重构为代码执行范式,一条清晰的"工具自造"演进路径正在浮现。本文实测六大工具创造栈,覆盖从学术论文到生产落地的完整光谱,并揭示一个核心发现:当Agent学会造工具,工具数量不再是瓶颈,工具质量才是。
| 维度 | LATM | CREATOR | ToolMaker (ACL'25) | Voyager技能库 | MCP Code Execution | CRAFT |
|---|---|---|---|---|---|---|
| 核心理念 | 大模型当工具工匠 | 解耦创造与使用 | GitHub仓库→工具 | 终身学习技能积累 | 工具调用→代码执行 | 创造+检索+复用 |
| 工具形态 | Python函数 | 文档化工具函数 | 可执行Python工具包 | JavaScript技能代码 | 沙箱内任意代码 | 特化工具库 |
| 创造者模型 | GPT-4级别 | 任意强模型 | Claude/GPT-4 | GPT-4 | Claude Sonnet | GPT-4 |
| 使用者模型 | 可用弱模型 | 同上 | 同上或弱模型 | 同一模型 | 同一模型 | 弱模型即可 |
| 开源状态 | GitHub开源 | GitHub开源 | GitHub开源 | GitHub开源 | MCP协议开放 | 论文+代码 |
| 成功率 | ~65% | ~72% | 80% | 任务相关 | 依赖沙箱能力 | ~68% |
| 上手难度 | 中等 | 低 | 中等 | 高(需Minecraft) | 中等 | 中等 |
| 生产就绪 | 实验级 | 实验级 | 接近生产 | 游戏域 | 生产级 | 实验级 |
LATM(Large Language Models as Tool Makers)由Cai等人在2023年提出,首次系统性地将LLM定位为"工具制造者"。核心洞察极其简洁:让强模型(如GPT-4)为弱模型(如GPT-3.5)制造工具,实现能力下沉。
整个流程分三个阶段:
工具制造阶段(Tool Making):
强模型 → 分析任务 → 编写工具函数 → 验证工具 → 存入工具库
工具使用阶段(Tool Using):
弱模型 → 检索匹配工具 → 调用工具 → 获得结果
工具回收阶段(Tool Recycling):
新任务 → 工具库检索 → 命中已有工具 → 直接复用
关键创新在于解耦——工具创造和工具使用是两个独立的推理过程,可以用不同能力的模型完成。这意味着一次工具创造的投入可以被无数次使用摊薄。
# LATM 工具制造阶段
def make_tool(task_description: str, demos: list) -> str:
"""强模型根据任务描述和示例创造工具"""
prompt = f"""You are a tool maker. Given the following task and examples,
create a reusable Python function that solves this type of task.
Task: {task_description}
Examples: {demos}
Output only the function code with docstring."""
tool_code = strong_model.generate(prompt)
# 验证工具:在示例上测试
validated = validate_on_demos(tool_code, demos)
if validated:
tool_library.store(task_type(task_description), tool_code)
return tool_code
# LATM 工具使用阶段
def use_tool(task: str) -> str:
"""弱模型检索并使用已造好的工具"""
tool = tool_library.retrieve(task)
if tool:
result = weak_model.execute_with_tool(task, tool)
else:
# 回退到直接推理
result = weak_model.generate(task)
return result
优势:成本结构极佳——一次性强模型投入换取弱模型无数次使用,长期成本趋近于弱模型推理价。工具库越积越厚,形成"工具复利"。
局限:工具验证机制薄弱。LATM仅在少量示例上验证,面对分布外输入时工具可能静默失败。工具检索依赖简单的文本匹配,在工具库规模增长后精度迅速下降。
CREATOR框架(Qian等,2023)提出了比LATM更深层的哲学洞察:LLM的工具使用失败不是因为不会用工具,而是因为"创造工具的抽象推理"和"使用工具的具体决策"被混为一谈。
CREATOR将Agent的推理过程显式分为四个阶段:
flowchart TD
A[任务输入] --> B[Creation: 创造工具]
B --> C[工具文档 + 代码]
C --> D[Decision: 决策调用]
D --> E[Execution: 执行工具]
E --> F{成功?}
F -->|是| G[返回结果]
F -->|否| H[Rectification: 修改工具]
H --> C
style B fill:#e1f5fe
style D fill:#fff3e0
style H fill:#fce4ec
关键对比实验揭示了一个反直觉的发现:CREATOR-Entangled(不分离创造和决策)比CREATOR差11.2%。这证明分离确实有效,不是工程trick而是认知层面的正确建模。
CREATOR的"先创造后使用"模式天然适合训练营场景:学员可以看到Agent如何从零开始为自己的任务造工具。相比直接调用API的demo,这种"看到工具被创造出来"的体验更具教学冲击力。预计可以包装为"LLM工具创造工作坊",面向已有Agent开发基础的中级开发者。
ToolMaker(Wölflein等,ACL 2025)是目前最接近生产落地的工具创造框架。它解决了一个极其实际的痛点:学术界有海量带代码的GitHub仓库,但将这些代码转化为LLM可调用的工具需要大量人工适配。
ToolMaker的agentic workflow包含五个步骤:
# ToolMaker 生成的工具示例(基于某图像分割仓库)
def segment_image(
image_path: str,
model_type: str = "sam_vit_h",
checkpoint_path: str | None = None,
points_per_side: int = 32,
pred_iou_thresh: float = 0.88,
) -> list[dict]:
"""
Segment objects in an image using SAM (Segment Anything Model).
Args:
image_path: Path to the input image file.
model_type: SAM model variant. One of: 'sam_vit_h', 'sam_vit_l', 'sam_vit_b'.
checkpoint_path: Path to model checkpoint. If None, downloads default.
points_per_side: Number of points per side for grid sampling.
pred_iou_thresh: IoU threshold for filtering low-quality masks.
Returns:
List of dicts, each containing:
- 'segmentation': Binary mask as numpy array
- 'bbox': [x1, y1, x2, y2] bounding box
- 'score': Confidence score (0-1)
- 'area': Mask area in pixels
Example:
>>> masks = segment_image("photo.jpg", model_type="sam_vit_h")
>>> print(f"Found {len(masks)} objects")
"""
...
ToolMaker论文报告了在来自20个不同科学领域的GitHub仓库上的测试结果:
| 指标 | ToolMaker | 直接调用(无工具) | 手动封装 |
|---|---|---|---|
| 正确实现率 | 80% | 35% | 92% |
| 平均封装时间 | 3.2分钟 | — | 45分钟 |
| 类型标注完整率 | 95% | — | 78% |
| 文档可用性 | 88% | — | 65% |
80%的成功率意味着每5个仓库中有4个可以自动化封装,仅1个需要人工干预。对于需要集成大量第三方库的Agent系统来说,这是一个质变级别的效率提升。
Voyager(Wang等,2023)虽然在Minecraft中诞生,但其"技能库"机制具有超越游戏域的普适价值。核心思想:Agent在与环境交互过程中,将成功的操作序列沉淀为可复用的"技能"(本质上是动态生成的工具),形成终身学习的闭环。
技能库的三层架构:
┌─────────────────────────────────┐
│ 技能检索层 │ ← 向量相似度匹配任务与已有技能
├─────────────────────────────────┤
│ 技能代码层 │ ← JavaScript函数,包含前置条件、执行体、后置条件
├─────────────────────────────────┤
│ 技能元数据层 │ ← 任务描述、成功次数、失败次数、适用范围
└─────────────────────────────────┘
Voyager的关键创新不在于技能代码本身,而在于技能的自动验证和生命周期管理:
2026年,这一理念已经被多个框架吸收。Claude Code的Skills系统、OpenAI的Custom GPT Actions都体现了"Agent自造+积累+复用"的相同范式。从Minecraft到生产Agent,技能库思想完成了从游戏AI到通用AI基础设施的跃迁。
Anthropic于2025年11月推出的Code Execution with MCP(CE-MCP)代表了一次范式的根本性转换。传统工具调用的核心瓶颈:
传统模式(N个工具):
Context Window = System Prompt + N × Tool Schema + 对话历史 + 工具返回
当N=100时,仅工具定义就消耗 50K-150K tokens
→ 模型留给推理的窗口被严重压缩
→ 成本线性增长
CE-MCP的解法极其优雅:不把工具定义塞进context,而是让Agent在沙箱中写代码调用工具。
CE-MCP模式:
Agent接收任务 → 在沙箱中写Python代码 → 代码通过MCP协议调用工具 → 返回结果
Token消耗: 仅代码本身(通常 1K-3K tokens)
从150K → 2K,降幅达98%
# 传统MCP工具调用(每个工具的schema都要塞进prompt)
# 假设有50个工具,每个schema约1K tokens → 50K tokens仅用于工具定义
# CE-MCP方式:Agent写代码调用
# 整个工具发现和调用都在代码中完成
code = """
import mcp_client
# Agent自己发现可用工具
tools = mcp_client.list_tools("github-server")
print(f"Found {len(tools)} tools")
# Agent选择并调用需要的工具
result = mcp_client.call_tool(
server="github-server",
tool="create_issue",
arguments={"title": "Bug in auth", "body": "...", "labels": ["bug"]}
)
print(result)
"""
# 这段代码仅消耗约200 tokens的context空间
# 而等价的工具定义+调用可能消耗5000+ tokens
Scale AI推出的MCP-Atlas基准(2026年2月)首次系统化了工具使用能力的评测:
| 模型 | 传统MCP准确率 | CE-MCP准确率 | Token消耗比 | 延迟变化 |
|---|---|---|---|---|
| Claude Sonnet 4 | 72.3% | 78.1% | 1:0.15 | +0.8s |
| GPT-4.1 | 68.7% | 71.2% | 1:0.18 | +1.1s |
| Gemini 2.5 Pro | 65.4% | 69.8% | 1:0.22 | +0.6s |
| Llama 4 Maverick | 51.2% | 55.6% | 1:0.25 | +1.5s |
核心发现:CE-MCP不仅降低了Token消耗,还提升了准确率。原因在于:当工具定义不再挤占context窗口时,模型有更多空间进行推理。这是一个罕见的"降本同时提质"的案例。
当Agent的工具库从10个增长到1000个时,一个新的瓶颈浮现:如何从海量工具中检索出正确的工具? 这个问题被大多数Agent框架忽视,但它可能是工具使用能力规模化的关键卡点。
ACL 2025的ToolRet基准(Shi等)首次系统化评估了这一问题。基准包含:
| 检索方法 | nDCG@5 | nDCG@10 | 首位命中率 |
|---|---|---|---|
| BM25(关键词匹配) | 31.2% | 35.8% | 22.4% |
| Contriever(通用嵌入) | 38.7% | 42.1% | 28.6% |
| E5-Mistral(指令微调) | 45.3% | 49.2% | 34.1% |
| GPT-4嵌入 | 52.1% | 56.8% | 41.3% |
| 专用工具检索器(训练后) | 61.8% | 65.4% | 49.7% |
关键洞察:即使是最好的通用检索模型(GPT-4嵌入),在工具检索任务上的首位命中率也仅41.3%。这意味着每10次工具检索中,有近6次第一个返回的工具是错的。专用训练的检索器虽然显著提升,但仍有一半场景无法命中。
这解释了为什么当前Agent系统普遍限制工具数量在20-30个——不是因为模型调不了更多工具,而是因为检索精度在工具规模扩大时崩塌。
SMART(Qian等,ACL 2025 Findings)提出了一个被广泛忽视但极其重要的问题:Agent是否在过度使用工具?
研究发现在主流Agent评测中,40-60%的工具调用是不必要的——Agent本可以直接通过推理得到正确答案,却仍然调用了工具。这不仅浪费Token和延迟,还引入了额外的失败点(工具可能返回错误结果)。
SMART的解法是引入元认知层:
# SMART的决策流程
def smart_agent(task, available_tools):
# 第一步:元认知评估
metacog_prompt = f"""
Given this task: {task}
Available tools: {len(available_tools)} tools
Assess: Can you solve this WITHOUT any tool?
Rate your confidence (0-1) for direct reasoning.
"""
confidence = model.generate(metacog_prompt)
if float(confidence) > THRESHOLD:
# 直接推理,不调用工具
return model.generate(task)
else:
# 选择性工具调用
return use_tools_selectively(task, available_tools)
实验结果显示SMART将工具调用次数减少了43%,同时准确率提升了2.7%。减少工具调用反而提升准确率——这再次印证了"工具不是万能的"这一常被忽视的事实。
flowchart LR
subgraph 场景判断
A{工具来源?}
end
A -->|已有GitHub仓库| B[ToolMaker]
A -->|需要全新创造| C{一次创造还是持续创造?}
A -->|已有API服务| D[MCP Code Execution]
C -->|一次性| E[LATM]
C -->|持续积累| F{环境类型?}
F -->|封闭游戏/仿真| G[Voyager技能库]
F -->|开放Web/API| H[CREATOR + 技能库]
subgraph 规模层
I{工具数量?}
end
B --> I
D --> I
E --> I
H --> I
I -->|< 30个| J[直接注入Schema]
I -->|30-200个| K[ToolRet检索器 + 动态注入]
I -->|> 200个| L[MCP Code Execution + 沙箱]
subgraph 元认知层
M[SMART过滤层]
end
J --> M
K --> M
L --> M
| 场景 | 推荐方案 | 理由 | 预估成本 |
|---|---|---|---|
| 集成大量开源库 | ToolMaker + CE-MCP | 自动封装+代码执行省Token | 3-5分钟/库 |
| 科学计算Agent | LATM + CREATOR | 强模型造工具,弱模型用 | 一次性投入 |
| 企业API编排 | CE-MCP + ToolRet | 大规模工具检索+代码执行 | 按调用计费 |
| 教育/研究Agent | CREATOR | 解耦过程可观测、可教学 | 低 |
| 自主探索Agent | Voyager技能库 | 终身学习、技能积累 | 渐进式 |
| 任何生产系统 | 加SMART层 | 减少43%无效调用 | 几乎为零 |
定律一:工具创造的成本应被摊销。 无论是LATM的强/弱模型分工,还是ToolMaker的仓库自动封装,核心经济学都是"一次创造,多次使用"。如果一个工具只被调用一次,创造它的成本就是浪费。在设计工具创造系统时,优先考虑复用率高的工具类型。
定律二:工具检索比工具创造更难。 ToolRet基准揭示了残酷现实——最好的检索器在千级工具集上首位命中率不到50%。这意味着在工具规模化的道路上,检索系统是真正的瓶颈。投资工具检索引擎的ROI远高于投资工具创造引擎。
定律三:不使用工具也是一种能力。 SMART的43%无效调用减少不是孤例。在所有Agent系统中,元认知层——"我是否真的需要工具"——都应该成为标准组件。工具使用的最高境界不是调用更多工具,而是在不需要工具时果断不调用。
当Agent从"工具使用者"进化为"工具创造者",整个AI Agent的技术栈正在经历一次深层重构。这不是渐进式改良,而是从"给Agent配工具箱"到"给Agent配车间"的范式跃迁。
[!tip] 51学通信知识星球 星主:爱卫生(微信:gprshome201101)——公众号「51学通信」创办者,19 年通信行业运维与讲师经验,著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书(各大电商平台有售)。 星球定位:深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域,主打运维岗位与信令分析。 当前规模:5200 篇主题 / 990 个回答,198 元/年。 加入福利:加入星球后请加爱卫生微信,拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题,另有群内分享。 AI 加持:51学通信知识星球已作为 skill 接入 WorkBuddy,使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例,做总结、找文档和 PPT 等场景全覆盖。
