# Agent自造工具：五基准揭示自进化能力断层 Agent用工具不稀奇，稀奇的是Agent**自己造工具**。2026年，当BFCL这类"用工具"评测基准已跑马圈地完毕，研究重心的暗流正转向一个更根本的问题：LLM能否从需求出发，自主设计、实现、验证可复用的工具？Tool-Genesis、ToolMaker、SEA-Eval、AutoAgent、Hermes Tool Search——五套截然不同的评测与工程方案，从学术基准到生产系统，拼出了一张Agent"工具创造能力"的全景断层图。核心发现：**工具使用Top-1准确率已逼近90%，但工具创造成功率在最佳模型上也仅勉强过半**——两者之间存在一道尚未跨越的鸿沟。 ## 一、断层总览：使用vs创造的能力剪刀差 | 维度 | 工具使用（Tool Use） | 工具创造（Tool Creation） | |------|---------------------|-------------------------| | 代表基准 | BFCL v3、Nexus、API-Bank | Tool-Genesis、SEA-Eval、ToolMaker | | 最佳模型表现 | GPT-5.4 ~92%，Claude Opus 4.6 ~89% | GPT-5.4 ~58%，Claude Opus 4.6 ~52% | | 能力缺口 | — | **30-40个百分点** | | 评测成熟度 | 三世代演进，体系完善 | 第一世代，定义尚在收敛 | | 生产就绪度 | 已大规模部署 | 仅实验/早期试点 | | 核心挑战 | 精度、延迟、成本 | 正确性、可复用性、泛化性 | 这组数据揭示了一个关键洞察：**当前LLM的"消费者能力"远强于"生产者能力"**。模型可以精准调用一个现成API，但让它从头设计一个API并保证跨场景可用，成功率骤降近半。 ## 二、Tool-Genesis：工具创造的第一个标准化诊断 Tool-Genesis（2026年3月，arXiv 2603.05578）是目前唯一将"工具创造"作为**一等评测对象**的基准。它的设计哲学很明确：不测Agent能不能用工具，而测Agent能不能**从抽象需求出发构建可复用工具**。 ### 架构设计 Tool-Genesis的评测管线分为四个阶段： ``` 需求规格 → 工具生成 → 跨任务验证 → 质量评分 ``` **需求规格层**：给定一个抽象任务描述（如"分析一组时间序列数据中的异常点"），Agent需要推理出需要什么工具、工具接口应该怎样设计。 **工具生成层**：Agent必须输出完整的工具实现代码（通常是Python函数），包含类型签名、文档字符串、输入校验和核心逻辑。 **跨任务验证层**：生成的工具会在一组**未见过的同类任务**上测试，检验泛化能力而非过拟合单一输入。 **质量评分层**：从正确性（functional correctness）、鲁棒性（edge case handling）、可复用性（reusability）、文档质量（documentation）四个维度打分。 ### 核心发现 Tool-Genesis对GPT-4o、Claude Sonnet 3.5、Gemini 1.5 Pro等模型进行了系统评测，揭示了三个关键断层： 1. **接口设计断层**：模型擅长生成函数体，但**30%的失败源于接口设计不当**——参数类型选择错误、缺少必要的可选参数、返回值结构不一致。 2. **边界条件盲区**：在单任务测试中通过率约65%的工具，在跨任务验证中骤降至38%。模型倾向于针对描述中的具体样例"硬编码"，而非抽象通用逻辑。 3. **文档-实现不一致**：约22%的生成工具存在文档描述与实际行为不符的问题——文档声称处理空输入，实现却直接崩溃。 ```python # Tool-Genesis评测示例：模型需从需求生成工具 # 需求："创建一个工具，将CSV文件中的日期列标准化为ISO 8601格式" # 典型的失败案例——硬编码日期格式 def standardize_dates(csv_path: str) -> str: """Standardize date columns to ISO 8601.""" df = pd.read_csv(csv_path) df['date'] = pd.to_datetime(df['date'], format='%m/%d/%Y') # 硬编码！ return df.to_csv(index=False) # 正确的泛化实现 def standardize_dates(csv_path: str, date_columns: list[str] | None = None, date_formats: list[str] | None = None) -> str: """Standardize date columns in CSV to ISO 8601 format. Args: csv_path: Path to the CSV file. date_columns: Columns to convert. Auto-detect if None. date_formats: Expected formats to try. Infer if None. Returns: CSV string with standardized dates. """ df = pd.read_csv(csv_path) cols = date_columns or _detect_date_columns(df) for col in cols: df[col] = pd.to_datetime(df[col], format=date_formats, infer_datetime_format=True) df[col] = df[col].dt.isoformat() return df.to_csv(index=False) ``` ### 变现评估 Tool-Genesis作为**学术基准**，直接变现路径有限，但其评测框架可嵌入Agent开发平台的CI/CD管线，作为"工具质量门禁"收费。预计市场规模：中等，适合Agent基础设施厂商集成。 ## 三、ToolMaker：从GitHub仓库到LLM工具的自动转化 ToolMaker（Wölflein et al., ACL 2025）走的是另一条路：不是从需求文本生成工具，而是**将已有的GitHub代码仓库自动转化为LLM可调用的工具**。论文报告80%的任务正确实现率，大幅超越当时的SOTA。 ### 三阶段管线 ``` 仓库分析 → 接口抽取 → 工具包装 ``` **仓库分析**：Agent克隆目标仓库，阅读README、docstring、测试用例，构建对代码功能的语义理解。 **接口抽取**：识别核心函数/类，推断输入输出类型，提取关键参数。这一步的难点在于区分"对LLM有用的API"和"内部实现细节"。 **工具包装**：生成标准化的MCP/Function Calling格式包装器，包含JSON Schema、描述文本和使用示例。 ### 关键数据 | 指标 | ToolMaker | 基线（直接prompt） | |------|-----------|-------------------| | 功能正确率 | 80% | 47% | | 接口设计合理率 | 73% | 31% | | 跨仓库泛化成功率 | 68% | 22% | | 平均生成时间 | 4.2分钟/仓库 | 1.8分钟/仓库 | ToolMaker的高成功率来自一个关键设计：**迭代验证循环**。生成工具后，Agent会自动构建测试用例并执行，根据失败结果修改工具实现，最多迭代5轮。这个"自检+自修"机制贡献了约18个百分点的提升。 ### 变现评估 ToolMaker的商业潜力直接且清晰：**GitHub→MCP工具的自动化流水线**。对于拥有大量内部代码库的企业，自动将内部SDK/库暴露为Agent工具的需求真实且紧迫。按仓库计费模式可行，定价区间$5-50/仓库。 ## 四、SEA-Eval：超越单回合的自进化Agent评测 SEA-Eval（2026年4月，arXiv 2604.08988）将评测维度从"能不能造工具"提升到"**能不能持续进化自己的工具集**"。这是第一个正式定义"自进化Agent（Self-Evolving Agent）"的基准。 ### 三维评测框架 SEA-Eval的独特之处在于引入了**时间维度**：不是评测一个静态快照，而是评测Agent在多轮任务执行中能否持续改进工具集。 **维度一——工具创造（Creation）**：面对全新任务类型，Agent能否从零构建所需工具。这与Tool-Genesis类似，但SEA-Eval额外要求工具必须能被后续任务复用。 **维度二——工具适配（Adaptation）**：当任务需求发生偏移（如数据格式变化、边界条件扩展），Agent能否修改已有工具而非从头重建。 **维度三——工具淘汰（Retirement）**：当某些工具过时或冗余，Agent能否识别并主动清理，避免工具集膨胀导致的性能退化。 ### 核心发现 SEA-Eval揭示了一个被严重忽视的问题：**工具集膨胀**。在20轮连续任务测试中： - GPT-5.4的工具集从初始5个增长到平均23个，其中仅9个被实际使用——**60%的工具是僵尸工具** - Claude Opus 4.6稍好，但也维持在45%的僵尸率 - 僵尸工具的存在不仅浪费token，还会**干扰后续工具选择的准确率**——工具越多，选择越容易出错 ``` # SEA-Eval评测流程 第1轮: 任务A → 创建工具t1, t2, t3 第2轮: 任务B → 复用t1, 创建t4 第3轮: 任务C → 复用t1, t4, 适配t2 → t2_v2 第4轮: 任务D → 复用t2_v2, t3, 创建t5 ... 第20轮: 任务T → Agent拥有23个工具，但只需5个 # 关键指标 - 复用率 (Reuse Rate): 跨轮次工具复用百分比 - 僵尸率 (Zombie Rate): 超过3轮未被调用的工具占比 - 适配成功率 (Adaptation Success): 工具修改后通过原测试+新测试的比例 ``` ### 变现评估 SEA-Eval的评测框架直接可转化为**Agent运维（AgentOps）产品**的核心功能——工具生命周期管理。对于运行大量Agent实例的企业，监控和优化工具集的健康度是一个刚需。SaaS订阅模式可行。 ## 五、AutoAgent：零代码自开发框架的工程实践 AutoAgent（HKUDS, 2025）不是基准，而是一个**工程框架**——用自然语言指令自动生成Agent所需的一切：工具、工作流、甚至其他Agent。它在GitHub上获得了显著关注，代表了"自造工具"理念的生产化尝试。 ### Self-Play定制机制 AutoAgent的核心创新是**Self-Play Agent Customization**： 1. 用户用自然语言描述需求（"我需要一个Agent监控Hacker News热门帖子并自动总结"） 2. 系统生成一个初始Agent 3. 初始Agent尝试执行任务，收集失败模式 4. 另一个"审查Agent"分析失败模式，生成改进方案 5. 改进方案反馈给初始Agent，迭代优化 这个过程的关键在于：**工具不是预先定义的，而是在Self-Play过程中按需生成的**。如果Agent发现需要RSS解析能力，它会自动创建一个RSS解析工具并加入工具集。 ### 工程架构 ```mermaid graph TD A[自然语言需求] --> B[需求解析器] B --> C[工具蓝图生成] C --> D[代码生成器] D --> E[工具验证器] E -->|通过| F[工具注册表] E -->|失败| G[审查Agent] G --> H[修复方案] H --> D F --> I[工作流编排器] I --> J[执行引擎] J --> K[自管理文件系统] J --> L[向量数据库] style A fill:#e1f5fe style F fill:#c8e6c9 style G fill:#fff3e0 ``` ### 实际表现 | 场景 | 工具生成成功率 | 端到端任务完成率 | 平均迭代次数 | |------|--------------|----------------|------------| | 数据分析 | 78% | 71% | 3.2 | | Web自动化 | 65% | 58% | 4.1 | | API编排 | 72% | 64% | 3.7 | | 文档处理 | 81% | 74% | 2.8 | AutoAgent配备了一个**自管理向量数据库**，用于存储和检索已生成的工具。这个设计解决了"工具发现"问题：当Agent需要某类能力时，先在向量库中搜索已有工具，匹配成功则复用，匹配失败则创建新工具。这个模式与企业级"工具中台"的思路高度一致。 ### 变现评估 AutoAgent作为开源框架，直接变现路径是**企业版/托管服务**。其零代码特性使其天然适合非技术用户——产品经理、运营人员可以通过自然语言构建自动化流程。对标Zapier/Make的AI原生版本，估值空间可观。 ## 六、Hermes Tool Search：大规模工具集下的发现与选择 前面四个方案聚焦于"创造工具"，但生产环境中还有一个同等重要的挑战：**当工具数量膨胀到数百个时，Agent如何高效发现和选择正确的工具？** Hermes Agent的Tool Search功能（2026年5月发布）直接瞄准这个问题。 ### 问题规模 Anthropic内部MCP评测揭示了一个惊人的数据： | 场景 | MCP服务器数 | 工具数 | Prompt Token开销 | |------|-----------|-------|-----------------| | 轻度使用 | 2-3 | 8-12 | ~8K tokens | | 中度使用 | 5 | 34 | ~45K tokens | | 重度使用 | 10+ | 80+ | ~120K tokens | 当工具schema占满上下文窗口，准确率断崖式下跌： - **Opus 4**：工具少时49%准确率 → 引入Tool Search后**74%**（提升25个百分点） - **Sonnet 4**：79.5% → **93%**（提升13.5个百分点） ### BM25渐进式披露 Hermes的方案不复杂但极为实用：**不在prompt中加载所有工具schema，而是用BM25搜索按需加载**。 ``` # 传统方式：全量加载 prompt = system_prompt + ALL_TOOL_SCHEMAS # 120K tokens # Hermes方式：渐进式披露 prompt = system_prompt + TOOL_SUMMARIES # 2K tokens（仅名称+一句话描述） # Agent决定需要哪个工具 → 按需加载完整schema # 平均每次只加载3-5个工具schema ``` 这套方案将token开销削减了**85%**（从45K降至约7K），同时通过减少噪声反而提升了准确率。核心洞察：**给Agent更少的工具描述，它反而选得更准**——这是信息检索领域的经典"精确率/召回率"权衡在Agent场景的映射。 ### 三桥调用设计 Hermes Tool Search的工程实现包含三个"桥"调用（bridge calls）： 1. **第一桥**：Agent接收工具摘要列表，用自然语言描述需要什么能力 2. **第二桥**：BM25检索返回Top-K候选工具的完整schema 3. **第三桥**：Agent从候选中选择最终工具并执行调用 这个三步设计确保了：Agent不需要一次性理解所有工具的完整接口，而是先做粗筛再做精选——**降低了认知负载，提高了决策质量**。 ```python # Hermes Tool Search核心逻辑（简化） class ToolSearch: def __init__(self, tool_registry: list[Tool]): self.summaries = {t.name: t.summary for t in tool_registry} self.schemas = {t.name: t.full_schema for t in tool_registry} self.index = BM25Index(self.summaries) def search(self, query: str, top_k: int = 5) -> list[dict]: """按需检索工具schema""" candidates = self.index.query(query, top_k=top_k) return [self.schemas[name] for name in candidates] def get_summaries(self) -> dict[str, str]: """返回所有工具的摘要（低成本）""" return self.summaries ``` ### 变现评估 Hermes Tool Search的价值不在于其本身可独立售卖，而在于它是**MCP生态成熟的关键基础设施**。当企业MCP部署规模超过10个服务器，Tool Search从"锦上添花"变成"不可或缺"。适合作为MCP网关产品的核心差异化功能。 ## 七、工具设计反模式：Anthropic的实战教训 2025年9月，Anthropic发布了一篇工程博客《Writing Effective Tools for AI Agents》，这是为数不多的**从工具设计者视角**的系统性总结。结合2026年的最新实践，可以提炼出七个关键反模式： ### 反模式一：描述模糊 ```python # 反模式 {"name": "process", "description": "Process the data"} # Agent无法判断何时使用 # 正确 {"name": "extract_named_entities", "description": "从文本中提取命名实体（人名、地名、组织名），返回实体列表及类型标签"} ``` Anthropic内部测试显示：描述从3词扩展到完整句子后，工具选择准确率提升**12-18个百分点**。 ### 反模式二：参数过度 超过6个参数的工具，Agent正确传参率下降40%。解决方案：将复杂参数嵌套为对象，而非平铺。 ### 反模式三：缺少错误反馈 工具调用失败时返回空字符串或通用错误，Agent无法自修复。Anthropic建议：返回结构化错误信息，包含**失败原因、建议的替代方案、相关文档链接**。 ### 反模式四：副作用不透明 Agent无法预判工具调用的副作用（如"发送邮件"是幂等的吗？会发出去吗？）。解决方案：在描述中明确标注副作用，或提供`dry_run`参数。 ### 反模式五：命名冲突 多个工具使用相似名称（`search_users` vs `find_users` vs `query_users`），Agent混淆率高达35%。建议：使用**动词+领域**的命名约定，确保全局唯一。 ### 反模式六：Schema过宽 将所有参数设为`string`类型，不做约束。这导致Agent传入格式错误的数据，运行时才报错。正确做法：用JSON Schema的`enum`、`pattern`、`minimum/maximum`等约束尽早拒绝无效输入。 ### 反模式七：无版本管理 工具接口变更后旧Agent调用失败。建议：在工具名中嵌入版本号（`search_users_v2`），或使用header传递版本。 ## 八、综合对比与推荐 | 评测/工具 | 定位 | 核心指标 | 最佳表现 | 成熟度 | 适用场景 | |----------|------|---------|---------|-------|---------| | Tool-Genesis | 学术基准 | 工具创造成功率 | GPT-5.4 ~58% | ★★★ | 研究、模型评测 | | ToolMaker | 工程框架 | 仓库→工具转化率 | 80% | ★★★★ | 内部SDK工具化 | | SEA-Eval | 学术基准 | 自进化综合评分 | GPT-5.4 领先 | ★★ | Agent运维研究 | | AutoAgent | 开源框架 | 端到端任务完成 | 74% (文档) | ★★★ | 零代码Agent构建 | | Hermes Tool Search | 生产组件 | Token削减率 | 85% | ★★★★★ | 大规模MCP部署 | ### 场景推荐 **研究机构**：优先采用Tool-Genesis + SEA-Eval组合，前者测创造能力，后者测进化能力，形成完整的"工具生命周期"评测体系。 **企业内部工具化**：ToolMaker是将存量代码库快速暴露给Agent的最佳方案。建议先在内部SDK上试点，建立"工具质量门禁"后再扩大范围。 **Agent产品团队**：Hermes Tool Search的BM25渐进式披露模式应作为标配。当工具数超过20个时，全量加载schema已经不可持续。 **零代码平台**：AutoAgent的自然语言→工具→工作流管线最接近产品化。但需注意其Self-Play迭代的成本控制——每次迭代消耗的token可能在$0.5-2之间。 **工具设计者**：Anthropic的七条反模式应作为团队Checklist。每新增一个工具前，对照检查描述清晰度、参数数量、错误反馈、副作用标注等。 ## 九、核心结论 ```mermaid graph LR subgraph 工具使用能力 A1[单工具调用
准确率~92%] --> A2[多工具选择
准确率~85%] A2 --> A3[并行调用
准确率~78%] end subgraph 工具创造能力 B1[接口设计
成功率~60%] --> B2[实现编码
成功率~55%] B2 --> B3[跨任务验证
成功率~38%] end subgraph 工具治理能力 C1[工具发现
成熟度★★★★] --> C2[工具淘汰
成熟度★★] C2 --> C3[工具进化
成熟度★] end A3 -.->|30-40%
能力缺口| B1 B3 -.->|治理需求| C1 style A1 fill:#c8e6c9 style A2 fill:#c8e6c9 style A3 fill:#fff9c4 style B1 fill:#fff9c4 style B2 fill:#fff9c4 style B3 fill:#ffcdd2 style C1 fill:#c8e6c9 style C2 fill:#fff9c4 style C3 fill:#ffcdd2 ``` 2026年的Agent工具能力正处于一个**不对称进化**的关键节点： - **使用侧**：已接近工程天花板，增量改进空间有限。竞争焦点从"能不能用对工具"转向"能不能用得高效"（token经济学、延迟优化）。 - **创造侧**：刚过起点线。Tool-Genesis揭示的30-40个百分点的缺口不是靠更好的prompt能弥合的——需要模型层面的架构创新，可能涉及专门的"工具生成预训练"。 - **治理侧**：几乎空白。SEA-Eval的僵尸工具数据（60%冗余率）和Hermes的token削减实践（85%浪费）指向同一个结论：**工具生命周期管理是下一个必须解决的工程问题**。 对于从业者而言，最务实的路径是：先用Hermes式方案解决当下的工具发现与选择效率问题，同时用ToolMaker逐步将存量代码转化为Agent工具，等待Tool-Genesis揭示的创造能力缺口在模型迭代中被逐步收窄。 ## 参考来源 1. [Tool-Genesis: A Task-Driven Tool Creation Benchmark for Self-Evolving Language Agents](https://arxiv.org/abs/2603.05578) — 工具创造能力的首个标准化诊断基准，揭示使用vs创造的30-40%能力缺口 2. [LLM Agents Making Agent Tools (ToolMaker)](https://arxiv.org/abs/2502.11705) — ACL 2025论文，GitHub仓库→LLM工具自动转化框架，80%任务正确率 3. [SEA-Eval: A Benchmark for Evaluating Self-Evolving Agents Beyond Episodic Assessment](https://arxiv.org/abs/2604.08988) — 首个自进化Agent基准，揭示60%僵尸工具问题 4. [Hermes Agent Ships Tool Search for MCP](https://www.marktechpost.com/2026/05/29/hermes-agent-ships-tool-search-for-mcp-anthropic-evals-show-49-to-74-accuracy-gain-on-opus-4/) — BM25渐进式披露方案，85%token削减，Anthropic评测验证 5. [Writing Effective Tools for AI Agents — Anthropic Engineering](https://www.anthropic.com/engineering/writing-tools-for-agents) — 工具设计七大反模式与最佳实践，含内部评测数据 > [!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 等场景全覆盖。