为企业 AI 代理准备工具调用数据集：本地工作流

大多数企业 AI 代理项目都卡在同一个环节：代理能够正常对话，却无法在恰当的时机、用正确的参数、可靠地调用正确的内部工具。根本原因几乎总是同一个，模型从来没有在反映本组织真实工具的工具调用数据上训练过。

单靠提示词解决不了这个问题。你可以把函数定义和少样本示例一股脑塞进系统提示，但当内部工具超过 40 个、彼此能力还有重叠时，基于提示的做法就会触到天花板：模型会混淆相似的工具，凭空编造参数，或者不管上下文如何都退回到最常用的那个工具。

解决办法很直接：用贴合你自身环境的工具调用数据去微调模型。难点在于，这份数据在你亲手造出来之前并不存在；而对企业来说，整个制作过程还必须完全在本地完成，因为工具定义本身就是敏感信息。

为什么代理需要工具调用训练数据

AI 代理选择并调用工具的能力是学出来的行为，不会自己涌现。基础模型乃至指令微调过的模型都具备通用的工具调用能力，但那是在公开 API 的 schema 上训练出来的，比如天气 API、搜索引擎、计算器函数。企业内部的工具和这些完全是两回事。

一家典型的企业内部会有一整套 API：CRM 数据查询、ERP 事务处理、文档管理、合规检查、审批流，以及几十种特定业务领域的操作。每个工具都有各自的参数格式、必需的鉴权上下文，还有一套关于何时该调用、何时不该调用的业务规则。

用企业自有的工具调用样本做过微调之后，有三件事会出现可测量的改善。第一，在内部基准上，工具选择准确率从仅用提示词时的 60-70% 提升到微调后的 90-95%。第二，参数格式错误减少 80% 以上，因为模型学到了确切的 schema。第三，模型学会了负样本，也就是什么时候不该调用工具，这会减少不必要的 API 调用以及随之而来的成本。

工具调用数据集的格式

不管你微调的是哪一个模型家族，每条工具调用训练样本的结构都一样，由五个部分组成：

系统提示：定义代理的角色和通用指令。各条样本之间保持一致。

函数定义：用 JSON schema 描述可用的工具，包括名称、说明、参数（含类型与约束）以及必填字段。

用户查询：一条应当触发某个特定工具调用的自然语言请求。

预期函数调用：模型应当选中的那个工具名。

预期参数：模型应当传给该工具的确切 JSON 参数。

一条训练样本在实际中长这样：

{
  "messages": [
    {
      "role": "system",
      "content": "You are an enterprise assistant with access to internal tools."
    },
    {
      "role": "user",
      "content": "Pull the Q3 revenue numbers for the EMEA region."
    }
  ],
  "tools": [
    {
      "name": "query_financial_report",
      "description": "Retrieves financial metrics by quarter, region, and metric type.",
      "parameters": {
        "quarter": "string (Q1-Q4)",
        "year": "integer",
        "region": "string",
        "metric": "string"
      }
    }
  ],
  "expected_call": {
    "name": "query_financial_report",
    "arguments": {
      "quarter": "Q3",
      "year": 2026,
      "region": "EMEA",
      "metric": "revenue"
    }
  }
}

要让微调稳定见效，每个工具需要 50-200 条样本。一套 30 个工具的系统，总量就是 1,500-6,000 条。听上去很多，但下面这条准备流水线能把工作量压到可控范围内。

常见的素材文档

企业的工具调用数据集，素材来自大多数组织里本来就有的文档：

API 文档：OpenAPI/Swagger 规范是最富的一处矿，里面有端点定义、参数 schema，往往还带示例请求。内部 API 如果已经有规范，这件事你就已经完成了 40%。

内部 wiki 与运维手册：这些文档用自然语言写清了什么场景该用哪个工具、怎么用。它们是用户查询变体的来源，也就是真实用户描述任务时的说法。

流程定义：BPMN 图、Jira 工作流、审批链。它们记录的是多步的工具调用序列，工具 A 的输出会成为工具 B 的输入。

标准作业程序（SOP）：一步步的操作说明可以直接映射成工具调用链。"先在 CRM 里查到客户，再看他的信用状态，然后创建订单。"每一步都是一次工具调用。

工单与聊天记录：真实用户提出、当初由人工去调工具处理的那些请求。它们是生成逼真查询变体的富矿，因为里面保留了人们实际的措辞，连错别字和缩写都在。

准备流水线

端到端的流水线分五个阶段，每个阶段都能在本地运行，不依赖任何外部服务。

阶段 1：从 API 规范提取工具定义

解析 OpenAPI/Swagger 规范，抽取函数 schema。对每个端点，记录名称、说明、HTTP 方法、路径参数、查询参数、请求体 schema 和响应 schema，再把这些转换成目标模型期望的工具调用 JSON 格式。

假设有 30 个内部 API、平均每个 8 个端点，这一阶段会产出 240 条原始工具定义。其中不少与你的代理无关，需要筛出代理真正该用的那个子集。

阶段 2：生成用户查询变体

给每个工具写 50-200 条应当触发它的自然语言查询。先从 wiki 文档和 SOP 里现成的说法起步，再用一个本地大模型（通过 Ollama 跑 Llama 3 70B 效果不错）扩写变体。

关键在于多样性：正式的问法（"检索账户 ID 44891 的客户账户状态"）、随口的问法（"44891 那个账户什么情况"）、含糊的问法（"看下那个账户"），以及需要推断参数的问法（"把上季度 EMEA 的数拉一下"，模型得自己推出当前是哪一年）。

阶段 3：构造预期调用与响应对

对每一组"查询加工具"的组合，定义预期的函数调用和参数。这是最费人力的一个阶段，也需要领域经验：写样本的人必须知道正确的工具是哪一个，参数又该怎么映射。

领域专家的分量就体现在这里。一个天天用这些 API、已经用了三年的工程师，一天能产出 200 条样本；不熟悉这些 API 的人写出来的错误，会一路传导进微调后的模型里。

阶段 4：校验与去重

跑一遍自动校验：参数是否符合工具的 schema？必填字段有没有齐？枚举值是否合法？然后查重复，措辞相近而预期调用完全相同的查询只会增加噪声，学习信号却没有增加。

负样本同样要校验：数据里要包含那些不该触发任何工具调用的查询。"今天天气怎么样？"不应该去调你的内部 CRM API。模型需要学会克制。

阶段 5：导出为 JSONL

把校验过的样本按微调框架期望的 schema 写成 JSONL。大多数开源模型（Llama、Mistral、Qwen）用的是带工具调用扩展的 ChatML 格式。导出时分成训练集（80%）和验证集（20%）两份。

本地部署的要求

工具调用数据集是企业在数据准备环节产出的最敏感的一类产物。原因如下。

工具定义本身就暴露了内部 API 架构。拿到你工具调用数据集的攻击者，等于掌握了每一个内部端点、每一份参数 schema，以及写在工具说明里的每一条业务规则。这是一张组织运营基础设施的蓝图。

训练样本则暴露使用模式：哪些查询对应哪些工具、哪些参数最常见、各个系统之间如何联通。这类运营情报，对竞争对手或敌意方都很有价值。

在受监管行业，问题更尖锐。一家金融机构的工具调用数据集会清清楚楚地显示交易如何执行、合规检查如何进行、有哪些审批流程。把这类数据送到云端大模型厂商那里做合成扩充，在多数监管框架下都构成违规。

从解析 API 规范、生成合成查询，到导出 JSONL，整条流水线都必须跑在组织自己掌控的基础设施上。

用本地大模型做合成扩充

查询生成这一步，用大模型辅助的收益极大。一个本地模型每分钟能生成 10 条查询变体，彼此措辞的差异足够大，都能带来训练价值。

在自有 GPU 基础设施上用 Ollama 跑一个够强的模型（Llama 3.3 70B 或 Qwen 2.5 72B）。喂给它一份工具定义和 5 条由领域专家手写的种子查询，让它扩出 50 条变体。产出要人工过一遍，质量筛选之后通常能留下 70-80%。

扩充用的提示词很关键。要写明领域、用户画像（初级分析师、资深交易员、客服人员）和语气的正式程度，这样生成的查询才够多样，能覆盖组织里不同角色提出请求时的各种说法。

一份 5,000 条样本的数据集，合成扩充能把领域专家的投入从大约 200 小时压到大约 50 小时。专家的工作变成写种子样本、审阅生成结果，不必每一条都从零写起。

质量校验

有两项质量检查，决定了你的工具调用数据集能否上生产。

覆盖度检查：每个工具的样本量够不够？把每个工具的样本数分布画出来看。如果 5 个工具各有 200 条以上，另外 10 个工具却不到 20 条，模型就会偏向样本充足的那几个。可用的最低覆盖线是每个工具 50 条。

边界情况覆盖：逐个工具确认样本覆盖到这几类：所有必填参数的组合、可选参数的用法、从上下文推断参数（例如根据日期推出"本季度"）、需要连续调用多个工具的查询，以及跟该工具用途相似、却不应触发它的查询。

拿数据集的 20% 跑一次快速的验证性微调。如果模型在留出样本上的工具选择准确率超过 85%，数据质量就够用了。低于 85% 就去找系统性错误，通常大部分错误都出自少数几个定义得不好的工具。

实操注意事项

数据集规模：30 个工具的系统，总量瞄准 3,000-6,000 条。低于 1,500 条，冷门工具上会出现混淆。超过 10,000 条，除非你的工具异常复杂，否则收益会明显递减。

更新频率：内部 API 会变。按季度更新数据集来安排预算，涵盖新增端点、废弃工具、改动过的 schema。数据集一旦过期，模型就会去调用已经不存在的端点。

多轮序列：真实的代理交互往往是一串工具调用。要加入多轮样本：代理先调工具 A，处理返回结果，再调工具 B。这类交互占生产环境用量的 20-30%，而在多数数据集里样本严重不足。

错误处理：有些情况下，正确的反应是反问澄清而不是猜参数，这类样本也要收进来。"更新一下那个账户"太含糊了，模型应当追问是哪个账户、要更新什么，而不是拿编出来的参数去调 API。

在企业 AI 代理项目里，工具调用数据集是杠杆率最高的那一件产物。做对了，代理就能跑起来；做砸了，再多的提示词工程也补不回来。