不做训练时如何让 Agent 知道工具及其调用格式？

核心回答

通常不需要为每个新工具重新训练模型，而是在推理请求中提供工具定义，让已有工具调用能力的模型根据当前任务选择并填写参数。

工具定义主要包括名称、用途描述、参数Schema及必要示例。例如天气工具说明“用于查询城市天气”，参数里声明 city 是必填字符串，并说明城市名称格式。模型据此返回结构化调用，程序再校验参数、找到真实工具执行，把结果交回模型。

这里的“不做训练”指应用接入新工具时不额外微调模型，并不是基础模型从未学过工具调用。模型是否支持相应协议和格式仍是前提；名称和Schema也不能保证每次都选对工具、填对业务值。

展开说明

1. 模型在运行时看到的是工具说明和格式约束

应用先在执行端注册工具，并把当前可用工具的名称、说明和参数规则随请求提供给模型。原生工具调用接口通常有专门的 tools 等字段，具体结构依提供方而定，不必把所有定义手写进用户消息。

Schema可以声明字段类型、必填、枚举、范围、单位和示例；描述则补充何时使用、何时不用、需要什么前置信息。例如订单查询与创建订单要有明确边界，不能只用两个含糊的函数名让模型猜。

框架可以从函数签名、类型注解和docstring生成这份定义，也可显式指定Schema。通常不需要把函数体交给模型；模型理解业务用途主要依靠对外描述，真正的函数实现仍在程序端。

2. 用天气工具串起定义、请求和执行

以教程的天气工具为参考，程序先注册 get_weather，再通过 bind_tools 将定义提供给支持工具调用的模型。用户问北京天气时，模型可根据用途和参数说明提出天气调用，并将城市转换成工具接受的形式。

这时只是产生了调用请求，天气接口尚未因此自动执行。执行层读取工具标识和参数，找到注册的实现，校验后取得实际结果，再把结果按所用消息协议交回模型，模型才能基于它回答。

bind_tools 是框架用法，不是训练步骤，也不等于执行函数。原生API的字段、工具请求与结果类型可能不同；跨模型接入时要由适配层处理，不能只改字段名就假定格式完全相同。托管内置工具则由提供方执行，仍需看具体服务的契约。

3. 提供格式以后，仍要处理选错、缺参和参数错误

模型可能选错工具、遗漏参数，或给出格式合法但业务不成立的值。执行前应检查工具是否可用，参数能否解析并符合规则，当前用户是否有权操作相应资源。

缺少关键输入时，明确反馈缺什么，让Agent澄清或补充；类型、日期、枚举等错误可以返回具体原因，允许有限修正。不要把错误参数直接交给任意函数执行，更不能用 eval 运行模型输出。

支持严格工具参数约束或相应受限生成的服务，可以降低结构错误，但有各自的模型和Schema支持范围。即使结构完全正确，也不证明订单归属、库存状态或操作授权正确；这些仍由业务程序判断。

4. 不支持原生工具调用时，可以做较轻的替代

可以在提示中列出工具，约定输出一个带工具名和参数的JSON结构，配合少量示例，由程序解析和验证。这仍然是运行时提供信息，不是训练。

但仅靠提示要求“返回JSON”，可靠性通常不等同于已支持的原生工具协议或约束生成。应严格限制可调用名称、验证参数、处理拒答和截断，并设置修正与总调用预算；能力不足时选择更合适模型或改为确定性流程，不能无限重试。

工具很多时，先按任务和权限筛出相关候选，再提供完整定义。筛选后仍需保留发现其他能力的路径，不能因为上下文里没有某个工具，就让模型虚构一个名字。

常见追问

新工具没出现在训练数据里，模型怎么会调用？

它可以利用已有语言理解和结构化输出能力，阅读本次请求里的新名称、描述和参数定义，再生成对应调用。这类似按接口说明填参数，是否可靠需要通过任务样例验证，不表示模型理解了实现代码的全部行为。

MCP是怎么告诉模型工具格式的？

MCP Server通过工具发现返回名称、描述和 inputSchema 等定义；Client取得后，由Host适配到所用模型的工具输入。模型通常不是直接消费MCP网络报文。MCP提供发现和调用协议，也不要求针对每个工具训练模型。

工具定义只提供一次就永久记住了吗？

不能这样假定。后续推理仍需要能访问当前可用的定义，可能由应用重复提供，也可能由服务端按会话和缓存机制管理。工具版本或权限变化时应同步，不能依赖模型凭过去印象调用已失效接口。

对应教程

参考资料