训练大语言模型去写工具，而且写出来的工具希望被别的模型、别的系统、甚至完全超出自己能力边界的东西拿来直接用——这个目标听起来就比单纯“让模型生成一段代码”高一个台阶。过去一年里我做过好几轮相关实验，最深的感受是：很多团队都能让模型生成能运行的程序，却很难让这段程序被另一个Agent安全复用。问题通常不在代码本身，而在训练目标——大多数模型只学会了“对自己的情境负责”，没学会“对工具的接口契约负责”。
举个例子说明这个区别。让模型写一个“解析日志”的工具，它往往能写得非常顺，因为调用它的人和写它的人共享同一个任务上下文，参数含义、返回结构全都心照不宣。可一旦把这个工具扔给另一个任务，另一个Agent看到函数名、参数、返回值的瞬间就开始困惑：这工具到底要怎么调？边界条件是什么？错误怎么处理？这时候模型在原始任务上的优雅，到了外部环境就变成了一次无法复用的巧妙。这篇文章不打算讲大而全的理论，而是围绕我在实践里真正用到的数据构造、训练策略、评估陷阱和失败模式展开，适合正在做LLM工具生成、Agent内部工具库自动构建的工程师和研究员参考。
1. 先分清“自用工具”和“通用工具”差在哪里
1.1 两条路线的本质差异
先给两个定义。自用工具，是指LLM在解决某个具体问题时顺手生成的代码片段或函数，它的服务对象就是当前这个对话上下文。通用工具，则是指模型被要求产出一个独立、自包含、可被外部调用方理解的模块，它的服务对象是用户或其他Agent。
这两条路线对工具质量的要求完全不同。自用工具可以没有文档，参数名可以随意，甚至可以硬编码答案，因为调用方和实现方共享同一段上下文，上下文本身就是最好的接口说明。通用工具则要求模型在“看不见原始问题背景”的情况下，仍然把一个工具的接口做得足够清晰：函数名与语义一致，参数有类型提示和默认值，返回值结构稳定，文档说明使用场景和边界约束。没有这些约束，工具写出来往往只是“自己能用”，谈不上泛化。
我在项目里见过不少团队在这上面栽跟头：训练数据里全是“基于某个具体问题生成的代码片段”，然后要求模型写出通用工具，结果模型的输出经常是一个封装得又好又坏的函数——好的地方是逻辑正确，坏的地方是参数含义完全依赖问题里的私人命名。这就是典型的训练目标与使用场景不匹配。
1.2 接口契约才是泛化的真正单元
如果只把工具生成当作“生成正确代码”，训练起来会很顺利，泛化却很差。原因是代码正确性测试只能验证一段代码在给定输入下是否输出预期结果，而泛化任务里真正起作用的是一层看不见摸不着的接口契约。
我习惯把这个契约拆成七个点：函数名、参数名、参数类型、默认值、错误处理、返回结构、示例调用。从大量评估结果看，LLM对函数名和参数名相对敏感，对错误处理和示例调用最不敏感。换句话说，模型从训练数据里很容易学会“起个好名字”，却很难自动学会“处理输入异常”和“给出调用示例”。但是同样面对跨上下文调用场景，这两项的权重恰恰最高——外部调用者第一次拿到工具时，最需要的信息就是“应该怎么调”以及“什么时候不该调”。
可以类比成写一个公开库和写一个私人脚本的关系。私人脚本只有你自己维护，编译器不会检查别人怎么用；公开发布的库则要提供文档、用例和稳定的API，否则使用方根本不敢接。想让模型写后者，就必须在训练阶段把“接口意识”变成一个显式优化的对象，而不是指望它在生成代码时顺带领悟。
2. 训练数据从哪来：构造工具生成任务的关键技巧
2.1 难度阶梯：让模型一步步面向调用者写代码
公开语料里很难直接找到“任务描述+工具实现+工具文档+调用测试”这种完整三元组，因此合成数据几乎是必经之路。但合成不能一上来就要求模型生成一个跨任务可用的工具，那样训练信号太稀疏，模型根本不知道从哪学起。我采用的做法是布置三层难度阶梯。
第一层L1：模型拿到函数签名加任务描述，只需要补全函数实现。这阶段学的是“把逻辑写对”。第二层L2：只给任务描述和目标输入输出样例，模型必须自主决定函数名、参数结构和返回格式。这阶段开始介入接口设计。第三层L3：模型生成工具之后，训练流程会把它丢进一个完全没见过的调用场景，由另一个任务上下文去执行调用测试。这阶段才算真正训练“跨任务泛化”。
具体任务举例，比如“计算两个时间范围的重叠时长”。L1版本已经把日期换算逻辑写得很溜；L2版本则需要模型自己决定是接收字符串时间还是时间戳、返回秒数还是结构化对象；L3版本从训练数据里撒一批相近但不相同的任务，比如“计算会议冲突时长”“排班重叠检查”，测试时要求模型之前生成的工具能被这些新任务正确调用。这样一个阶梯下来，模型才有机会意识到：写代码和写接口，是两回事。
2.2 数据筛选比数据数量重要得多
面对合成出来的训练集，一开始我犯过错误：把重采样的候选工具直接丢进训练集，结果模型学了大量“实现正确但不适合被调用”的工具。后来改成四层筛选，效果才明显。
第一层是静态检查，用AST解析和类型检查筛掉语法错误。第二层是动态执行，把候选工具编译运行，用一批固定测试输入验证逻辑。第三层是跨场景震荡测试，把能通过前两层筛选的工具随机放进多个调用上下文，只有多个上下文都能成功调用的才进入候选池。第四层是用一个较强的评估模型，对候选工具从“可调用性、命名一致性、参数简洁度、错误处理”四个维度打分，每个难度级别保留相当比例的正负例混合样本。
这里有一个反直觉的关键点：不能只保留高分正例。只喂正例会引导模型写出平庸、同质化的工具，缺少对“为什么这个接口更好”的认识。负例的价值是让模型看到候选之间的质量差异，理解糟糕的命名、混乱的返回结构、缺失的异常处理各自会带来什么后果。我们的一个实验里，引入负例之后，模型在跨任务调用上的成功率比只用正例时高了七八个百分点，这个差距随后还在继续拉开。
2.3 文档描述要当成一等训练目标
很多工具生成项目最大的疏忽，是只把“函数体正确性”放进目标函数，把docstring和描述信息当成轮旁逸出的附赠品。但在真实的Agent环境中，下一个调用者通常先看到的是“工具名、一句话描述、参数列表”，而不是函数内部的实现。如果描述写得含糊，工具即使写得天衣无缝也没人知道该用它。
我做过一个控制变量实验：同一批训练任务，一个版本细化docstring和函数注释的评分信号，另一个版本把它们直接扔掉。去掉描述相关权重后，工具在跨任务上下文里的复用率几乎腰斩。这个结果让我把所有工具的docstring升格为一等训练目标。具体实现并不复杂：在数据构造阶段，就把每个工具的描述文本提炼成“一句话用途概述+详细边界说明+示例调用”三块结构；在训练阶段，这三块内容必须出现在函数定义之前，并且参与损失计算时的权重不该低于函数体本身。
3. 训练策略：从监督微调到执行反馈
3.1 监督微调阶段容易被忽略的细节
很多团队做工具生成时，第一反应是把代码数据dump进SFT，然后观察loss下降。问题在于，常规SFT的交叉熵损失会把所有token一视同仁，模型训练一段时间之后，很容易被高频词和函数体内部的具体实现吸引，从而忽略更基础的接口结构。我后来做了一件很简单但有效的事：把函数生成格式固定为“先签名，再描述，再实现”的顺序，然后在损失计算时对签名和描述部分的token施加更高的梯度权重。
这种处理方式相当于告诉模型：接口信息比实现细节更重要。同等训练资源下，我们用这种加权方式获得的模型，在同分布代码生成准确率上并不比常规SFT差，但在跨上下文调用成功率上高出一截。所以训练工具生成模型时，别只盯着总loss曲线，最好是拆开观察“签名+描述部分loss”和“函数体部分loss”两条曲线，前者不降的模型，几乎一定有接口意识缺失的问题。
3.2 用执行反馈重写奖励：让“能跑”变成可优化信号
SFT做完，模型已经能生成结构不错的工具，但它仍然缺少一个关键能力：根据真实调用结果自我修正。这时候需要引入执行反馈，把它变成强化学习里最核心的奖励信号。
我设计的奖励函数有三个分量：编译或语法通过，记奖励；一组固定测试用例的执行通过比例，记奖励；跨任务隐藏测试的通过情况，记奖励。第三项是最关键的，因为跨任务测试直接度量了“通用性”而非“正确性”。经验数据显示，把三个分量的权重粗设为0.2、0.4、0.4效果就比较好。如果跨任务隐藏测试的权重被忽略，模型会走捷径——专门针对训练时可见的测试用例过拟合，表面上测试通过率很高，实际上一点泛化能力都没学到。
实现上，规则型奖励最大可得，执行环境提前把每个任务的调用测试和脚手架代码准备好，模型生成的工具会被放入一个隔离进程运行，输出结果按既定格式解析。这种方式比让大模型做裁判更稳定，也更容易审计。当然，纯粹的执行反馈也有覆盖不到的地方，比如生成的功能与任务描述不匹配这类语义问题，这时可以让一个评估模型参与偏好排序，再配合迭代优化。
3.3 课程式安排的顺序与比例
执行反馈阶段的训练顺序同样重要。把三种难度任务混在一起随机训练，效果远不如按难度做课程。我用的顺序是：先用L1任务把模型的基础生成能力稳住，再用L2任务强化接口设计意识，最后用L3任务训练跨任务泛化。为了不让模型遗忘简单语法的表达能力，每轮训练里保留一定比例的简单样例作为记忆锚点，比例大概两到三成即可。
比较值得注意的是，L3任务的比例不能一直过低。有人在训练后期把L3任务的比例恒定在10%，结果跨任务评测分数始终上不去；把L3比例逐步提高到30%-40%以后，迁移效果明显变好。这个规律不难解释：跨任务泛化是一种容易被其他目标稀释的能力，如果训练数据中这种样本太少，模型会在优化纯生成准确率的过程中把泛化能力慢慢挤掉。
4. 评估：别被单任务正确率骗了
4.1 三层评估：正确性、可选择性、可调用性
单任务测试通过率是最常见也是最容易误导人的评估指标。我见过一个模型，在“给定任务，生成对应工具”的测试集上成绩很好，但在一个真实的多Agent系统里完全抬不起头。后来把评估拆成三层才算看明白问题出在哪。
第一层工具正确性：工具在给定输入下输出是否符合预期。这是最底层的能力。第二层可选择性：把一批工具放进工具池，给定一个任务描述，另一个选择模型能否挑中应该使用的那一个。这一层考察的是工具之间是否具有可区分性，名字和描述不清晰的工具在这一关会大量被淘汰。第三层可调用性：给完全陌生的调用方只看工具名、描述和参数列表，它能否零样本、准确地调用这个工具。这层是最贴近实际使用环境的评估。
三层的落差通常能反映训练短板。如果第一层高而第二层低，说明模型生成的工具实现正确但区分度不够；如果第一层高而第三层低，说明接口意识训练不足。下一轮训练到底该往哪个方向调整，就根据落差点去补。
4.2 一张适合写进研发报告的泛化检查表
泛化这个词听起来玄，落到评估上其实可以做成一张可操作的表。我在内部项目里常用下面四个维度来检查模型产出工具的泛化程度。
- 语义泛化：把同一个任务换一个说法重新描述，工具实现是否仍然能对应。如果模型一换措辞就生成完全不同结构的东西，说明它只是在存储表面模式。
- 跨库泛化：同一功能从某个库的实现风格迁移到另一个生态的表现。比如在Python里写日期处理时用的是datetime，切换到另一个同义库时模型是否能维持相同的接口习惯。
- 多工具组合：多个工具需要按照特定顺序一起使用时，模型是否能保持输出之间的兼容性。有些模型单工具生成满分，组合调用时却经常产生参数对不上的低级错误。
- 长尾输入：对边界值、异常值和超大输入的处理。所有刻意设计过的输入都容易过拟合，真正的泛化能力要看模型怎么应对没见过的边界条件。
这四个维度不能代替完整的测试集，但它们能被快速跑起来，并且能够在训练迭代过程中持续观察变化。跑完这些检查之后，工具接口契约的应用阶段是否顺畅就会清晰很多。
4.3 除了准确率，还要看“安静率”
一个反直觉的发现是：模型不生成工具，有时比生成一个错误工具更有价值。在工具生成模型里，我额外记录了“过调用率”和“拒绝率”两个辅助指标。
过调用率是指模型在任务与工具能力不匹配时，仍然强行生成一个工具的频率。这种模型求胜心切，逻辑看着很完整，实际上是在用一个看似华丽的空壳糊弄调用方。拒绝率则指模型判断当前任务不适用于已有能力，于是选择不生成工具或者明确给出无法处理的答复。训练后期，前者的下降和后者的小幅上升往往同行而来，这正是模型学会了判断边界而不是一味迎合任务的表现。
建议每个团队在评估报表里都加上这两列。它们不需要额外标注，从日志里稍微做一下规则匹配就能统计出来，但能挽救很多被单任务准确率掩盖的灾难现场。
5. 常见失败模式、边界条件与工程体会
5.1 三个高发失败模式及对策
第一个是硬编码。模型为了让生成的工具通过测试，把输入处理的逻辑直接写死成测试里出现过的常量，测试全过，但换一个输入就必然出错。应对方式是在训练数据里刻意加入对抗样本，要求模型“不假设输入范围”，同时用随机参数扰动再次跑测试，把那些对输入做过度的工具直接排除。
第二个是对单一语言或库的过拟合。训练集里如果Python占比太高，模型一被提示切换到另外的语言，生成的工具质量立刻下降。对策不是在Python上继续堆积数量，而是按比例混合多语言数据，让模型在生成时意识到“当前任务要求的语言风格变了，工具的接口表达也得跟着变”。
第三个是工具名重复或撞车。模型在生成新工具时不检查已有工具池，经常生成功能相同但名称冲突的实现，导致外部系统不知道该调用哪一个。训练时会前把“已有工具池”作为上下文拼接进输入，让模型先生成查重判断再决定是新增还是复用，这一个小改变就能大幅降低工具池的重复度。
5.2 边界条件：输出表示最好用跨环境可解析的格式
工具能跑通只是开始，它的输出如果设计得不可解析，外部调用者依然会敬而远之。比如返回一个“2025-03-01今天下午三点到四点”这种自然语言混合文本，对当前调用者一眼能看懂，对另一个Agent完全无法结构化消费。
跨函数边界的通用工具，输出统一采用结构化的机器可解析格式才是正道。时间数据用ISO时间戳，字段统一用JSON Lines或键值对，错误直接用标准错误码而不是纯文本描述。工具把运行结果和错误信息分开输出，别在一个大字符串里混一堆信息。数据层面上这种格式几乎对所有使用方都友好，调用方的解析器也更稳定。
这个建议听起来像常识，但我在实验里做过统计，返回格式结构化的工具，跨任务调用成功率比返回松散自然语言的工具明显更高，差距大到足以影响排名。通用工具首先要考虑的是“调用方和实现方分成两个进程，各活各的”，而不是“在同一份代码里摸着变量直接对话”。
5.3 一些不一定写进论文的工程体会
这一节分享三条不一定写进论文、但实际很管用的工程体会。
第一，小模型不是不能用，关键是数据设计是否严格。同样的跨任务测试，数据筛选严格的小模型往往能打败数据质量粗糙的大模型。别一上来就把预算砸在参数规模上，先检查训练数据里是否有足够的“跨上下文可用”信号。
第二，接入真实执行环境的强化学习，是泛化能力提升中性价比最高的一步。相比单纯增加模型参数，把执行反馈、跨任务测试和接口评分接入训练循环，能在相同训练成本下带来更持续的迁移收益。
第三，不要迷信模型的“热情”。训练数据里如果全是必答题型，模型遇到能力外的问题也会强行生成答案。很多工具生成事故不是技术能力不足，而是模型缺少“说明白自己不会”的训练目标。数据里要留出合理的“拒绝”样本，模型才不会在边界问题上盲目出手。
这套方法跑下来，我对“训练LLM写工具”的理解已经慢慢从“生成代码”转成“生成可被广泛消费的接口资产”。工具生成的难点从来不只是实现逻辑，而是让实现本身能在脱离创作上下文之后依然被顺畅理解、安全调用。如果你也想让模型产出真正的通用工具，从数据里的跨任务调用测试开始改，通常比换更大的模型效果更直接。
