Agent用工具不稀奇，稀奇的是Agent自己造工具。2026年，当BFCL这类"用工具"评测基准已跑马圈地完毕，研究重心的暗流正转向一个更根本的问题：LLM能否从需求出发，自主设计、实现、验证可复用的工具？Tool-Genesis、ToolMaker、SEA-Eval、AutoAgent、Hermes Tool Search——五套截然不同的评测与工程方案，从学术基准到生产系统，拼出了一张Agent"工具创造能力"的全景断层图。核心发现：工具使用Top-1准确率已逼近90%，但工具创造成功率在最佳模型上也仅勉强过半——两者之间存在一道尚未跨越的鸿沟。
| 维度 | 工具使用（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（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等模型进行了系统评测，揭示了三个关键断层：
接口设计断层：模型擅长生成函数体，但30%的失败源于接口设计不当——参数类型选择错误、缺少必要的可选参数、返回值结构不一致。
边界条件盲区：在单任务测试中通过率约65%的工具，在跨任务验证中骤降至38%。模型倾向于针对描述中的具体样例"硬编码"，而非抽象通用逻辑。
文档-实现不一致：约22%的生成工具存在文档描述与实际行为不符的问题——文档声称处理空输入，实现却直接崩溃。
# 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（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（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轮连续任务测试中：
# 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（HKUDS, 2025）不是基准，而是一个工程框架——用自然语言指令自动生成Agent所需的一切：工具、工作流、甚至其他Agent。它在GitHub上获得了显著关注，代表了"自造工具"理念的生产化尝试。
AutoAgent的核心创新是Self-Play Agent Customization：
这个过程的关键在于：工具不是预先定义的，而是在Self-Play过程中按需生成的。如果Agent发现需要RSS解析能力，它会自动创建一个RSS解析工具并加入工具集。
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原生版本，估值空间可观。
前面四个方案聚焦于"创造工具"，但生产环境中还有一个同等重要的挑战：当工具数量膨胀到数百个时，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个百分点）
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）：
这个三步设计确保了：Agent不需要一次性理解所有工具的完整接口，而是先做粗筛再做精选——降低了认知负载，提高了决策质量。
# 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网关产品的核心差异化功能。
2025年9月，Anthropic发布了一篇工程博客《Writing Effective Tools for AI Agents》，这是为数不多的从工具设计者视角的系统性总结。结合2026年的最新实践，可以提炼出七个关键反模式：
# 反模式
{"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%。建议：使用动词+领域的命名约定，确保全局唯一。
将所有参数设为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。每新增一个工具前，对照检查描述清晰度、参数数量、错误反馈、副作用标注等。
graph LR
subgraph 工具使用能力
A1[单工具调用<br/>准确率~92%] --> A2[多工具选择<br/>准确率~85%]
A2 --> A3[并行调用<br/>准确率~78%]
end
subgraph 工具创造能力
B1[接口设计<br/>成功率~60%] --> B2[实现编码<br/>成功率~55%]
B2 --> B3[跨任务验证<br/>成功率~38%]
end
subgraph 工具治理能力
C1[工具发现<br/>成熟度★★★★] --> C2[工具淘汰<br/>成熟度★★]
C2 --> C3[工具进化<br/>成熟度★]
end
A3 -.->|30-40%<br/>能力缺口| 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揭示的创造能力缺口在模型迭代中被逐步收窄。
[!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 等场景全覆盖。