
> **研究对象**：ToolAlpaca: Generalized Tool Learning for Language Models with 3000 Simulated Cases
> **作者**：Qiaoyu Tang、Ziliang Deng（中科院软件所 + 中国科学院大学）
> **论文地址**：https://arxiv.org/abs/2306.05301
> **代码 / 数据**：https://github.com/tangqiaoyu/ToolAlpaca
>
> **研究路径**：本文与前面两篇（RestGPT 的 OAS 语义接口、AutoMCP 的 OpenAPI→MCP 编译）同属"LLM × 工具"这一主线，但视角换到了**训练侧**——前面两篇关心"工具怎么被描述、被调用、被部署"，本文关心"小模型怎么学会通用地用工具"。值得注意的是，本文的 Tool Executor 智能体正是以 **OpenAPI 规范**作为可机读接口来模拟工具执行的，等于从另一个角度再次印证了 OAS 作为"语义接口"的地位。

## 0. 一句话结论

**通用工具调用能力不是大模型的专利**：只要给一份"足够多样"的模拟工具使用语料（本文约 3938 条、覆盖 426 个工具 / 50 类），微调 7B/13B 的小模型，就能让它具备**泛化到未见工具**的能力，效果逼近 GPT-3.5——而且只用了约 3000 条训练样本，远少于同类工作的 7 万条。

---

## 1. 研究动机：小模型能不能学会"通用"工具调用？

当时的工具学习有两条路线，且中间存在明显断层：

- **路线 A（大模型零样本）**：GPT-4 这类超大模型靠插件 + 提示，就能零样本用各种工具，泛化性强。
- **路线 B（小模型监督微调）**：把小模型在特定工具集上微调，但它**只能用在训练见过的工具上，泛化不到未见工具**。

论文提出的核心问题：**紧凑（compact）小模型能否在不做工具专属训练的前提下，学会"通用"的工具调用能力？**

直觉依据：既然 Alpaca/Self-Instruct 已经证明，在"多样化指令数据"上微调能赋予小模型通用指令遵循能力，那么同理——在"高度多样化的工具使用实例"上微调，应该也能赋予小模型通用工具调用能力。

但卡在一个前置条件：**这样的多样化语料当时根本不存在**。原因有二：
1. 没有一套能覆盖各种工具场景的可用 API 集合；
2. 真实工具使用往往是"模型—用户—工具"之间复杂的多轮交互，手工标注成本极高。

ToolAlpaca 的贡献就是**自动化造出这份语料**，并用它证明了小模型可行。

---

## 2. ToolAlpaca 框架：三步走

整体结构即论文 Figure 1，分三个阶段：

![figure-1-training.jpg](https://developer.qcloudimg.com/http-save/yehe-11563618/3078dadae6aa0aed5759f51f3b712173.jpg)

### 2.1 工具集构建（Toolset Construction）

目标：从互联网收集工具，并用**统一格式**表示每个工具。

- **工具来源**：从 `public-apis` 仓库（1400+ API、50+ 类）随机挑 500 个，只取它们的 `name` 与 `introduction`（简介往往很简陋、无统一格式）。
- **文档生成**：用 ChatGPT 把简陋简介扩写成结构化文档。
- **OpenAPI 生成**：再用 LLM 为每个工具生成符合 OpenAPI 规范的 specification。

最终每个工具被表示成一个五元组：

```
{ name, introduction, description, function documentation, OpenAPI specification }
```

> **与本系列的连接**：这里的 `OpenAPI specification` 正是前面两篇反复讨论的"语义接口"。ToolAlpaca 让 LLM 自己把非结构化的工具简介"编译"成 OpenAPI——相当于用生成式方法补齐了 AutoMCP 所要求的"高质量契约"这一步。

下面是从论文 Figure 8 直接摘出的**真实 OpenAPI 生成提示词**（节选关键约束），它规定了 LLM 该怎么把函数写进规范：

```text
Please generate API documentation that conforms to the OpenAPI Specification...
3. For each function:
   - Design an endpoint, adhering to its definition and input/output requirements.
   - Use the function's name in the 'operationId' field.
   - For the endpoint's input, provide additional details in the 'parameters' section...
     use 'enum' to specify valid parameter values.
   - Generate a detailed model for each endpoint's response, including status codes
     and structured return values...
   - If an endpoint's input includes fields unknown to the user, like IDs, these fields
     must be included in the responses of relevant 'search', 'list', or similar endpoints.
6. For parameters/schemas with a 'type' of 'object', you must include their properties
   in the specification.
```

注意第 3 条最后一句：**"用户不知道的字段（如 ID）必须出现在 search/list 等端点的响应里"**——这正好呼应 AutoMCP 论文里"写好契约"的主题：工具要可被发现、参数要能自洽流转。

### 2.2 工具使用实例生成（多智能体模拟）

给定工具集，用**三个 LLM 扮演的虚拟智能体**自动生成工具使用实例，无需人工介入：

- **User Agent（用户）**：基于工具文档起草自然语言指令；并在助手追问时补全缺失信息。
- **Assistant Agent（助手）**：接收指令，按 ReAct 的 `(thought, action, observation)` 格式选工具、填参数、总结最终回答。
- **Tool Executor Agent（工具执行器）**：校验请求格式/参数后，**基于 OpenAPI 规范让 LLM 模拟出执行结果**（不真正发网络请求）。

每个实例是一个三元组：

```
{ Instruction, Actions, Response }
```

其中 `Actions` 沿用 ReAct，每个 action 是 `(thought, function name, input, tool response)` 的元组。

下面是从论文 Figure 3 直接摘出的**真实实例**（Public Holidays 工具，"去日本旅游避假期"）：

```text
I'm planning a trip to Japan next year, and I want to avoid any major holidays,
so can you tell me the list of holidays in Japan next year?

Action: chatWithUser
Action Input: {"Question": "Could you please specify the year you are planning your trip for?"}

The year is 2024.

Action: getHolidays
Action Input: {"country": "Japan", "year": 2024}

Status Code: 200
Response: {"holidays":[{"name":"New Year's Day","date":"2024-01-01","type":"National",...}]}

The list of holidays in Japan for 2024 is New Year's Day (January 1st),
Coming of Age Day (January 8th) ...
```

这一实例里出现了**多轮交互（先追问年份，再调用）**与**真实错误/缺失处理**——正是真实工具场景的难点。Tool Executor 之所以能"造假"出 `Status Code: 200` 的真实感响应，靠的就是 2.1 节生成的那份 OpenAPI 规范。

### 2.3 模型训练

把生成的语料拿去微调 Vicuna（7B / 13B），得到 **ToolAlpaca-7B** 与 **ToolAlpaca-13B**。

---

## 3. 语料统计与质量

### 3.1 规模（论文 Table 1）

| 统计量 | 数值 |
| --- | --- |
| 工具类别数 | 50 |
| 工具数 | 426 |
| 实例数 | 3,938 |
| 单函数调用实例 | 2,512 |
| 多函数调用实例 | 1,426 |
| 每工具平均函数数 | 4.85 |
| 平均交互步数 | 1.66 |
| 平均指令长度 | 23.42 |
| 平均输出长度 | 36.19 |

近 1.5k 条实例需要**多次函数调用**才能解决——说明语料不只是"单跳"玩具。

### 3.2 质量（论文 Table 2，人工抽检 100 条）

| 维度 | 通过率 |
| --- | --- |
| 指令可解性 | 88% |
| 工具响应有效性 | 92% |
| 动作序列与最终输出准确性 | 80% |

三个智能体各自能力都 >80%，说明"模拟造数据"这条路是靠谱的。

---

## 4. 实验：小模型也能达到 GPT-3.5 级

### 4.1 设置

- **训练**：Vicuna-7B / 13B，3 epoch、batch 128、lr 2e-5。
- **评测集**：用同一套框架造出两份**训练时未出现**的测试集——
  - 模拟子集：10 个模拟工具、100 条；
  - 真实子集：11 个真实 API、114 条（检验模拟数据与现实数据的差距）。
- **指标**：GPT-4 机器评测 Procedure（过程）/ Response（回答）/ Overall（整体）；另对模拟子集做人工评测。

### 4.2 主结果（论文 Table 3）

| 模型 | 模拟 Proc / Resp / Overall | 真实 Proc / Resp / Overall |
| --- | --- | --- |
| GPT-3.5 | 77 / 85 / 75 | 79 / 75.4 / 72.8 |
| Vicuna-7B（未训练） | 19 / 21 / 17 | 16 / 7.9 / 7.9 |
| **ToolAlpaca-7B** | 63 / 69 / 60 | 73 / 63.2 / 55.3 |
| Vicuna-13B（未训练） | 17 / 31 / 16 | 25 / 13.2 / 12.3 |
| **ToolAlpaca-13B** | 70 / 73 / 70 | 75 / 66.7 / 61.4 |

关键读数：
- 未训练的 Vicuna 几乎不会用工具（真实 Overall 仅 7.9 / 12.3）；
- 训练后提升 **+57（7B）/ +50（13B）**；
- **ToolAlpaca-13B 在模拟集上与 GPT-3.5 持平，真实集上 61.4 已相当接近 GPT-3.5 的 72.8**。

结论：仅用本框架生成的约 3000 条实例，就能把"通用工具调用能力"灌进小模型。

### 4.3 跨数据集泛化：碾压"用 71k 数据训练的同类"

论文还在 **GPT4Tools 测试集**（8 个多模态工具、训练时未见过）上对比：

| 模型 | SRt | SRact | SRargs | SR |
| --- | --- | --- | --- | --- |
| GPT-3.5 | 99.5 | 99.5 | 91.5 | 91.5 |
| Vicuna-13B | 84.4 | 43.7 | 46.7 | 26.2 |
| GPT4Tools（71k 实例训练） | 98.2 | 97.0 | 92.2 | 90.6 |
| **ToolAlpaca-13B（3.9k 实例）** | – | 95.5 | 85.3 | 83.7 |

**ToolAlpaca 只用 3.9k 条样本，就达到用 71k 条同工艺样本训练的 GPT4Tools 的水平**。这强烈暗示：瓶颈不在"数据量"，而在"数据多样性 + LLM 的模拟能力"。

---

## 5. 关键发现：多样性 > 数据量

论文固定实例数量，只改变工具集的多样性（10 / 40 / 100 / 400 个工具），在 Vicuna-13B 上复测：

- 10 个工具 → Overall 仅 **51**；
- 400 个工具（实例数不变） → Overall 升到 **70**。

即**同样的样本量，工具越多样，泛化越好**。这对"如何为通用能力学习造数据集"是直接的方法论启示：**先求广，再求深**。

---

## 6. 与本系列前作的关系

| 论文 | 关注点 | 与 OpenAPI 的关系 | 视角 |
| --- | --- | --- | --- |
| **RestGPT**（2306.06624，北大） | LLM 如何规划/调用真实 API | OAS 作为"语义接口"被抽取、蒸馏进提示词 | 客户端调用 |
| **AutoMCP**（2507.16044） | 把 OpenAPI 自动编译成 MCP 服务器 | OAS 直接编译为可部署服务端 | 服务端基础设施 |
| **ToolAlpaca**（本文） | 训练小模型获得通用工具能力 | 让 LLM 把工具"生成"成 OpenAPI 规范，再驱动模拟执行 | 训练侧数据 |

三条线索其实指向同一件事：**OpenAPI 规范正逐渐成为 LLM 与工具之间的"通用语义契约"**——
- RestGPT 把它当"提示词里的语义来源"；
- AutoMCP 把它当"编译输入"；
- ToolAlpaca 则让它**由 LLM 自动生成**，并作为 Tool Executor 模拟执行的依据。

另外，本文参考文献 [3] 直接引用了前文的 **RestGPT（Song et al., 2023, arXiv:2306.06624）**，并将其归为"用多样化工具集让 LLM 通过提示用工具"的路线之一——三篇论文在文献脉络上彼此咬合。

---

## 7. 结论

ToolAlpaca 证明了一件反直觉的事：**通用工具调用能力可以从"模拟数据"中学到，且小模型也能具备**。要点有三：

1. **框架通用**：多智能体模拟能零人工地造出高质量、多样化的工具使用语料；
2. **小模型可行**：7B/13B 微调后逼近 GPT-3.5，泛化到未见真实/多模态工具；
3. **多样性制胜**：在固定样本量下，工具越多样效果越好——造数据集应"先求广"。

对工程实践的启示：**当你想让一个小模型学会用工具，与其堆数据量，不如先保证工具覆盖面的广度；而 OpenAPI 规范，既是 AutoMCP 的编译输入，也是 ToolAlpaca 模拟执行的底座，值得作为工具描述的统一标准固化下来。**

---

## 附：论文 ↔ 工程要点 速查

| 论文章节 | 要点 | 工程含义 |
| --- | --- | --- |
| §1 动机 | 小模型缺"通用"工具能力 | 别指望裸 Vicuna 直接调 API |
| §3.1 工具集构建 | 五元组 `{name, intro, desc, func_doc, OpenAPI}` | 工具描述统一用 OpenAPI |
| §3.2 多智能体 | User/Assistant/Executor 三角色 | 造训练数据可全 LLM 模拟 |
| §3.2 Tool Executor | 基于 OpenAPI 模拟返回 | 免去真实 API 调用即可造数据 |
| §5 实验 | 3000 条 ≈ GPT-3.5 | 小模型 + 好数据够用 |
| §5 多样性 | 400 工具 > 10 工具 | 数据广度优先于深度 |
| Table 4 | 3.9k 胜 71k | 多样性 > 样本量 |


研究对象：ToolAlpaca: Generalized Tool Learning for Language Models with 3000 Simulated Cases 作者：Qiaoyu Tang、Ziliang Deng（中科院软件所 + 中国科学院大学） 论文地址：https://arxiv.org/abs/2306.05301 代码 / 数据：https://github.com/tangqiaoyu/ToolAlpaca

论文研究：靠 3000 条数据让小模型学会通用工具调用

本文的 Tool Executor 智能体正是以 **OpenAPI 规范**作为可机读接口来模拟工具执行的，等于从另一个角度再次印证了 OAS 作为"语义接口"的地位。

人工智能

算法

ToolAlpaca研究证明小模型通过3000条多样化工具使用实例训练，可掌握通用工具调用能力，效果接近GPT-3.5。该框架利用OpenAPI规范自动生成工具描述，通过多智能体模拟创建训练数据，强调数据多样性优于数量。7B/13B模型经微调后能泛化到未见工具，为小模型工具学习提供高效方案。

代码解释

服务器

智能体

ChatGPT

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

论文研究：靠 3000 条数据让小模型学会通用工具调用-腾讯云开发者社区-腾讯云

论文研究：靠 3000 条数据让小模型学会通用工具调用

论文研究：靠 3000 条数据让小模型学会通用工具调用

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐