## 从预置到涌现：Agent工具创造能力全栈拆解 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：大模型当工匠的开创范式 ### 架构原理 LATM（Large Language Models as Tool Makers）由Cai等人在2023年提出，首次系统性地将LLM定位为"工具制造者"。核心洞察极其简洁：**让强模型（如GPT-4）为弱模型（如GPT-3.5）制造工具，实现能力下沉。** 整个流程分三个阶段： ``` 工具制造阶段（Tool Making）: 强模型 → 分析任务 → 编写工具函数 → 验证工具 → 存入工具库 工具使用阶段（Tool Using）: 弱模型 → 检索匹配工具 → 调用工具 → 获得结果 工具回收阶段（Tool Recycling）: 新任务 → 工具库检索 → 命中已有工具 → 直接复用 ``` 关键创新在于**解耦**——工具创造和工具使用是两个独立的推理过程，可以用不同能力的模型完成。这意味着一次工具创造的投入可以被无数次使用摊薄。 ### 代码示例：LATM工具制造核心循环 ```python # 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：解耦抽象与具体的推理革命 ### 架构原理 CREATOR框架（Qian等，2023）提出了比LATM更深层的哲学洞察：**LLM的工具使用失败不是因为不会用工具，而是因为"创造工具的抽象推理"和"使用工具的具体决策"被混为一谈。** CREATOR将Agent的推理过程显式分为四个阶段： 1. **创建（Creation）**：根据任务描述，LLM先写出解决该类问题的工具函数及其文档 2. **决策（Decision）**：LLM阅读工具文档，决定如何调用 3. **执行（Execution）**：运行工具代码获得结果 4. **纠错（Rectification）**：若执行失败，LLM修改工具代码并重试 ```mermaid 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（ACL 2025）：GitHub仓库一键变工具 ### 架构原理 ToolMaker（Wölflein等，ACL 2025）是目前最接近生产落地的工具创造框架。它解决了一个极其实际的痛点：**学术界有海量带代码的GitHub仓库，但将这些代码转化为LLM可调用的工具需要大量人工适配。** ToolMaker的agentic workflow包含五个步骤： 1. **仓库分析**：LLM Agent克隆仓库，阅读README、文档、示例，理解仓库功能 2. **接口提取**：识别核心API，提取函数签名、参数类型、返回值结构 3. **工具封装**：生成标准化的Python工具函数，包含完整的docstring和类型标注 4. **测试验证**：自动生成测试用例，在沙箱中执行验证 5. **文档生成**：生成LLM友好的工具描述，用于后续检索和调用 ```python # 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技能库：从游戏到通用的终身工具积累 ### 架构原理 Voyager（Wang等，2023）虽然在Minecraft中诞生，但其"技能库"机制具有超越游戏域的普适价值。核心思想：**Agent在与环境交互过程中，将成功的操作序列沉淀为可复用的"技能"（本质上是动态生成的工具），形成终身学习的闭环。** 技能库的三层架构： ``` ┌─────────────────────────────────┐ │ 技能检索层 │ ← 向量相似度匹配任务与已有技能 ├─────────────────────────────────┤ │ 技能代码层 │ ← JavaScript函数，包含前置条件、执行体、后置条件 ├─────────────────────────────────┤ │ 技能元数据层 │ ← 任务描述、成功次数、失败次数、适用范围 └─────────────────────────────────┘ ``` Voyager的关键创新不在于技能代码本身，而在于**技能的自动验证和生命周期管理**： - 每个新技能先在安全环境中试运行 - 执行成功的技能按"特异性"排序存入技能库 - 失败的技能不会进入库，但错误信息会反馈给LLM用于改进 - 当相似任务出现时，优先检索已有技能，避免从零推理 2026年，这一理念已经被多个框架吸收。Claude Code的Skills系统、OpenAI的Custom GPT Actions都体现了"Agent自造+积累+复用"的相同范式。从Minecraft到生产Agent，技能库思想完成了从游戏AI到通用AI基础设施的跃迁。 --- ## 六、MCP Code Execution：工具调用范式的重构 ### 架构原理 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% ``` ```python # 传统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 ``` ### MCP-Atlas基准实测 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窗口时，模型有更多空间进行推理。这是一个罕见的"降本同时提质"的案例。 --- ## 七、工具检索的隐藏战场：ToolRet基准揭示的真相 ### 问题本质 当Agent的工具库从10个增长到1000个时，一个新的瓶颈浮现：**如何从海量工具中检索出正确的工具？** 这个问题被大多数Agent框架忽视，但它可能是工具使用能力规模化的关键卡点。 ACL 2025的ToolRet基准（Shi等）首次系统化评估了这一问题。基准包含： - **7,696个多样化检索任务** - **覆盖多领域工具集**：从编程API到科学计算到日常生活服务 - **异构评测维度**：单工具检索、多工具检索、组合工具检索 ### 核心发现 | 检索方法 | 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：知道何时不用工具的元认知 ### 核心洞察 SMART（Qian等，ACL 2025 Findings）提出了一个被广泛忽视但极其重要的问题：**Agent是否在过度使用工具？** 研究发现在主流Agent评测中，**40-60%的工具调用是不必要的**——Agent本可以直接通过推理得到正确答案，却仍然调用了工具。这不仅浪费Token和延迟，还引入了额外的失败点（工具可能返回错误结果）。 SMART的解法是引入**元认知层**： ```python # 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%**。减少工具调用反而提升准确率——这再次印证了"工具不是万能的"这一常被忽视的事实。 --- ## 九、实战推荐：不同场景的工具创造选型 ```mermaid 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配车间"的范式跃迁。 --- ## 参考来源 1. [Large Language Models as Tool Makers (LATM)](https://arxiv.org/abs/2305.17126) — LATM框架原始论文，首次提出LLM作为工具制造者的闭环框架 2. [LLM Agents Making Agent Tools (ACL 2025)](https://arxiv.org/abs/2502.11705) — ToolMaker框架，80%成功率将GitHub仓库自动转化为Agent工具 3. [CREATOR: Tool Creation for Disentangling Abstract and Concrete Reasoning](https://arxiv.org/abs/2305.14318) — 解耦工具创造与使用的开创性框架 4. [Code Execution with MCP: Building More Efficient AI Agents](https://www.anthropic.com/engineering/code-execution-with-mcp) — Anthropic官方MCP Code Execution方案，Token消耗降低98% 5. [From Tool Orchestration to Code Execution: A Study of MCP Design Choices](https://arxiv.org/abs/2602.15945) — MCP-Atlas基准，系统性对比传统MCP与CE-MCP 6. [Retrieval Models Aren't Tool-Savvy (ACL 2025)](https://arxiv.org/abs/2503.01763) — ToolRet基准，揭示工具检索的现实困境 7. [SMART: Self-Aware Agent for Tool Overuse Mitigation (ACL 2025)](https://arxiv.org/abs/2502.11435) — 元认知减少43%无效工具调用 8. [Voyager: An Open-Ended Embodied Agent](https://arxiv.org/abs/2305.16291) — Minecraft中的终身技能库，从游戏到通用的工具积累范式 > [!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 等场景全覆盖。