Tool-Genesis: A Task-Driven Tool Creation Benchmark for Self-Evolving Language Agent

本文提出了名为 Tool-Genesis 的诊断基准，旨在量化语言智能体仅凭抽象需求自主创建工具的能力，并揭示了当前最先进模型在一次性生成中因接口与逻辑的微小缺陷而导致下游任务性能急剧下降的问题。

要点

这篇论文介绍了一个名为 Tool-Genesis（工具创世纪） 的新项目。为了让你轻松理解，我们可以把现在的 AI 智能体（Agent）想象成一个刚入职的超级实习生，而这篇论文就是为这个实习生设计的一套**“从零开始造工具”的终极考核**。

1. 现在的困境：只会“点菜”，不会“做饭”

以前的情况：
想象一下，你让 AI 去订一张去北京的火车票。

• 旧模式： 就像你手里已经有一张印好的菜单（API 文档），上面写着“火车票查询”、“订票”、“改签”三个选项。AI 只需要照着菜单点菜，填好参数（比如日期、车次），然后告诉服务员（调用接口）就行。
• 问题： 如果菜单丢了、菜单上的菜名写错了、或者服务员突然换了个新系统，AI 就彻底懵了。它只会“点菜”，不会“做饭”。

现在的挑战：
现实世界很复杂，很多时候没有现成的菜单。我们需要 AI 具备**“自进化”**的能力：

• 你只给它一个模糊的需求：“我想查一下从上海到北京的 G1234 次列车，然后买票，如果没票就改签下一趟。”
• AI 必须自己发明一套“火车票工具”（写代码、定接口、做逻辑），然后才能去完成任务。

2. 现有的考试太“黑盒”了

以前的考试（Benchmark）主要看结果：

• 考官问： “你买到票了吗？”
• AI 答： “买到了！”（或者“没买到”）
• 问题： 如果 AI 没买到票，我们不知道是因为它工具造错了（比如把“改签”写成了“退票”），还是因为它使用工具的方法不对（比如填错了日期）。这就叫“黑盒”，我们看不清它到底在哪一步摔了跟头。

3. Tool-Genesis：一场“全流程”的体检

这篇论文提出了 Tool-Genesis，它不再只看结果，而是给 AI 做了一次全方位的体检。它把造工具的过程拆解成了四个关卡，就像盖房子一样：

• 第一关：图纸合规（L1 - 表面合规）

  • 比喻： 你让 AI 画一张“火车票系统”的图纸。这张图纸必须符合建筑规范（JSON Schema），不能是乱画的涂鸦。
  • 考核： 图纸能不能被机器读懂？能不能挂到服务器上运行？

• 第二关：图纸精准度（L2 - 语义保真）

  • 比喻： 你的图纸上写的“改签”功能，是不是真的包含了改签需要的逻辑？还是说它其实画的是“退票”？
  • 考核： 对比 AI 画的图和标准答案，看名字对不对、参数全不全。

• 第三关：功能测试（L3 - 功能正确性）

  • 比喻： 拿着图纸去盖房子，然后进行压力测试。
    • 普通测试： 正常买票，通不通？
    • 极限测试（负向测试）： 故意输入错误的日期、不存在的车次，系统会不会崩溃？会不会乱报错？
  • 考核： 只有通过了所有“找茬”测试，才算合格。

• 第四关：实战演练（L4 - 下游效用）

  • 比喻： 最后，让另一个 AI（代理）拿着这套新造的工具，去真正完成“买票”的任务。
  • 考核： 任务成功了吗？如果成功了，是因为工具好，还是因为运气好？

4. 惊人的发现：天才也会“翻车”

论文作者测试了目前世界上最强的 AI 模型（包括 GPT-4o, Claude, Qwen3 等），发现了一个残酷的真相：

• 一锤定音很难： 即使是最聪明的 AI，如果只给它一次机会（One-shot），让它直接造工具，它几乎都会犯小错误。
  • 比如：把参数类型搞错（把数字当成了文字），或者漏掉了一个必填项。
• 蝴蝶效应： 这些微小的初始错误，就像多米诺骨牌的第一张。
  • 图纸画错一点点 -> 代码跑不通 -> 任务彻底失败。
  • 结果就是：AI 在“造工具”这一步就崩了，导致后面再努力也没用，任务成功率断崖式下跌。

5. 解决方案：像“修 bug"一样迭代

论文发现，如果给 AI 一个**“闭环修复”**的机会（Code-Agent 模式）：

• 流程： AI 造工具 -> 运行报错 -> AI 看到错误 -> AI 自己修改代码 -> 再运行。
• 效果： 这种“试错 - 修正”的过程，能让 AI 的表现突飞猛进。
  • 原本只有 10% 的成功率，经过几轮自我修复后，能提升到 60% 甚至更高。
  • 这说明 AI 不是不会造工具，而是缺乏自我检查和修正的能力。

6. 总结与意义

Tool-Genesis 就像是一个**“工具制造工厂”的质检中心**。

• 以前： 我们只关心产品（任务结果）卖没卖出去。
• 现在： 我们开始关心生产线（造工具的过程）哪里出了问题。

它的核心贡献是：

1. 不再依赖现成菜单： 逼迫 AI 学会从模糊需求中“无中生有”地创造工具。
2. 拒绝黑盒： 把失败原因拆解清楚，是图纸错了？还是代码写错了？
3. 推动进化： 告诉未来的 AI 研究者，要想让 AI 真正像人类一样工作，不能只教它“怎么用工具”，更要教它**“怎么造工具”以及“怎么修工具”**。

一句话总结：
这篇论文给 AI 出了一道新考题：“别只当个只会点菜的顾客，给我造一套能自动点菜的厨房系统，并且要经得起折腾！” 而测试发现，现在的 AI 虽然聪明，但在这个“从无到有”的创造过程中，还很容易因为一点小失误而全盘皆输，需要学会“边做边改”才能真正进化。

技术摘要

Tool-Genesis 技术总结

1. 研究背景与问题定义 (Problem)

随着自进化语言智能体（Self-Evolving Language Agents）的发展，研究重心正从单纯的工具调用转向工具的创建、适应与维护。然而，现有的评估基准存在以下三个主要缺陷，限制了真实场景下的自主进化能力评估：

1. 过度依赖预设规范 (Spec-first)：大多数基准假设工具接口或模式（Schema）是预先定义好的，仅评估模型在已知契约下的调用能力，而忽略了从抽象需求中推断接口契约并生成机器可检查模式的能力。
2. 缺乏场景闭环的工具集构建：现有工作多关注工具集合的规模或多样性，而非针对特定真实场景构建可维护、可复用的工具集（Toolset）。
3. “黑盒”评估困境：评估信号通常仅关注最终答案或粗略的调用检查。即使使用单元测试，也缺乏细粒度的归因分析，难以区分失败是源于工具构建缺陷（如 Schema 错误、逻辑 Bug）还是工具使用策略不当。

核心问题：如何构建一个诊断性基准，能够量化智能体在缺乏预设规范的情况下，从抽象需求中推断接口、生成可执行逻辑，并构建可复用工具集的能力，同时能够精确归因失败原因？

2. 方法论 (Methodology)

2.1 任务形式化

Tool-Genesis 将工具创建形式化为基于模型上下文协议（MCP）接口的条件生成问题。任务被分解为两个耦合阶段：

1. 工具接口预测 (Tool Interface Prediction)：根据自然语言需求 $x$，预测结构化的工具签名（Schema）$\hat{s}$。
2. 工具实体化 (Tool Materialization)：基于预测的 Schema（或真实 Schema），生成可执行的服务器实现代码 $\hat{e}$。

评估分为两种设置：

• Oracle Materialization：使用真实 Schema 作为输入，隔离评估工程实现能力。
• Cascaded Materialization：使用预测的 Schema 作为输入，评估端到端性能（反映真实场景）。

2.2 数据集构建 (Dataset Construction)

数据集构建流程包含四个阶段（如图 2 所示）：

1. 合规 MCP 服务器收集：从 Web 源（如 Smithery, GitHub）爬取 MCP 服务器，经过结构验证、可执行性验证、去重聚类及 LLM 语义验证，最终保留 86 个高质量服务器。
2. 高质量任务与轨迹生成：利用 LLM 基于工具 Schema 生成多样化任务（覆盖广度与深度），并通过拒绝采样和 LLM 裁判筛选，确保任务的可解性和真实性。
3. 综合单元测试生成：从执行轨迹中提取测试用例，并结合 LLM 合成边界/负向测试，确保覆盖率和鲁棒性。
4. 人工质量检查：由人工标注员进行多轮检查，确保任务可解、Schema 一致、轨迹连贯且测试用例无泄露。

数据规模：86 个 MCP 服务器，508 个工具，24 个领域类别，2150 个任务，9441 个单元测试。

2.3 评估协议 (Evaluation Protocol)

提出了一套全生命周期、四层递进的诊断评估指标：

• Level 1 (表面合规性)：合规率（Compliance Rate）和服务器执行率（Server Execution Rate）。
• Level 2 (语义接口保真度)：Schema-F1，通过二分图匹配量化预测接口与参考接口的相似度。
• Level 3 (功能正确性)：UTsoft（宽松标准）和 UThard（严格/边界/负向标准），衡量通过单元测试的比例。
• Level 4 (下游任务效用)：使用固定代理（Qwen3-14B）利用生成的工具解决任务，计算Oracle 归一化成功率 (Oracle-Normalized SR)，量化生成工具与真实工具之间的效用差距。

3. 关键贡献 (Key Contributions)

1. 首个任务驱动的工具创建基准 (Tool-Genesis)：

   • 摒弃了“规范优先”的设定，要求智能体从抽象需求推断接口并生成可复用资产。
   • 强调工具集的可维护性和场景闭环，而非一次性脚本。

2. 诊断性评估协议：

   • 解耦了工具生成与工具利用，通过多层信号（合规性、Schema 保真度、显式负向/边界测试）精确归因失败原因，解决了“黑盒”评估问题。
   • 引入了Oracle 归一化上限，量化生成工具与理想工具的效用差距。

3. 实证发现：

   • 即使是 SOTA 模型，在单步（One-shot）设置下也难以构建精确的接口或可执行逻辑。
   • 初始微小缺陷的级联放大：接口或逻辑的微小错误会在下游管道中被放大，导致下游指标急剧下降。
   • 闭环修复的价值：引入“思考 - 行动 - 观察”的 Code-Agent 循环（利用执行反馈进行修复）能显著提升功能正确性和任务成功率，且这种提升具有规模依赖性。

4. 实验结果 (Results)

在 86 个 MCP 服务器和 2150 个任务上的实验涵盖了 OpenAI、Anthropic、Google、Qwen、DeepSeek 等主流模型：

• 闭环修复的显著增益：

  • 采用 Code-Agent 策略（ReAct 风格循环）后，模型性能大幅提升。例如，Gemini-3-Flash 的执行率从 0.140 提升至 0.977，Schema-F1 从 0.116 提升至 0.912，任务成功率（SR）从 0.103 跃升至 0.581。
  • 这表明执行反馈能有效转化为可验证的正确性。

• 高合规性不等于高效用：

  • 许多模型在 Level 1/2（合规性/Schema 保真度）表现良好，但在 Level 3/4（功能/效用）表现不佳。这揭示了从“看似正确”到“真正可用”之间存在效用转换瓶颈，主要源于实现鲁棒性、边界处理和状态管理的缺失。

• 规模效应与模型排序变化：

  • 在 Code-Agent 设置下，更大参数的模型（如 Qwen3-235B）表现出更强的下游效用。
  • 模型排序在不同策略下会发生翻转（例如 Qwen3-32B 在 Direct 模式下优于 235B，但在 Code-Agent 模式下 235B 反超），说明利用执行反馈进行针对性修复是一种独立于单次生成的关键能力。

• 微调的有效性：

  • 在 Tool-Genesis 数据集上进行微调，能显著提升模型在 Direct 模式下的单步生成质量，以及在 Code-Agent 模式下的 Bug 定位和修复能力，证明该基准可作为有效的训练信号。

5. 意义与影响 (Significance)

• 推动范式转变：Tool-Genesis 引导社区从“一次性脚本”的 Ad-hoc 工具使用，转向构建持久、通用、可维护的工具资产，这是实现真正自进化语言智能体的核心机制。
• 提供诊断工具：通过多层级评估和归因分析，帮助研究者识别模型在工具创建链路中的具体短板（是接口推断不准，还是代码实现有 Bug，亦或是边界处理不当）。
• 指导未来研究：强调了在执行反馈驱动下的闭环修复（Closed-loop Repair）和微调（Finetuning）对于提升工具创建能力的重要性，为构建能够应对真实世界复杂挑战的自主智能体提供了明确的研究路径。

项目地址：https://tool-genesis.github.io