tools 字段,会遇到 工具定义膨胀(Tool Definition Bloat) 问题:每个请求都要携带全部工具的描述和参数 schema,token 消耗高;候选工具越多,模型也越容易选错工具、构造出错误的调用参数。
动态加载工具(Dynamically Loaded Tools)允许你在对话过程中 按需注入工具:先只挂载少量核心工具,当对话进展到需要某个工具时,再把它动态插入 messages 中,从而同时降低 token 消耗、提升工具选择的准确性。关于这一设计背后的思路(Lazy-Load、工具目录)与组合实践,见 Kimi K3 API 工具调用最佳实践。

在 messages 中注入工具声明
在messages 中插入一条 role 为 system 的消息,并通过该消息的 tools 字段声明要加载的工具。声明格式与请求顶层 tools 字段的格式完全一致,且需要提供工具的 完整信息(name、description、parameters):
- 携带
tools的system消息与普通的 input messages 地位相同:它出现在messages列表的哪个位置,工具就从哪个位置开始对模型可见; - 动态加载的工具与请求顶层
tools字段声明的全局工具 并存,模型可以同时看到两类工具; - 动态注入的工具声明必须是 完整 的工具定义,不能只传工具名或引用全局已声明的工具。
- curl
- python
用动态加载实现 Tool Search
API 层面没有专门的 tool search 接口。如果你的工具数量很多,可以组合「自定义 search 工具 + 动态加载工具」来自行实现 tool search:- 在请求顶层
tools中只声明一个search_tools工具,由你的后端实现,按关键词返回匹配的工具名称和简介; - 在 system prompt 中声明可被搜索的关键词(例如工具目录、领域标签),引导模型在需要工具时先调用
search_tools; - 根据
search_tools返回的结果,由你的应用把对应工具的 完整声明 通过一条携带tools的system消息动态插入messages; - 模型即可在后续生成中直接调用这些新加载的工具。
注意事项
- 动态工具声明按请求生效,不会被服务端记住。下一轮请求是否继续携带,由接入方自行决定:
- 继续携带:工具仍然可用,也有利于命中前缀缓存;
- 不再携带:该工具声明失效;如果工具未在其他位置声明,模型将无法调用这个工具。同时,由于
messages发生变化,变更位置之后的前缀缓存可能无法命中。
- 动态工具声明与全局
tools声明 格式完全统一,接入方无需维护两套 schema,迁移成本低; - 在
messages末尾追加动态工具声明,不会影响已有前缀的缓存。删除或修改之前的工具声明,可能影响变更位置之后的缓存命中。在请求顶层tools字段声明全局工具同样不影响缓存命中; - 携带
tools的system消息同样会占用上下文长度,请只对当前对话真正需要的工具做动态注入; - 动态加载工具目前仅
kimi-k3支持,在其他模型(如kimi-k2.6)上请求会返回tokenization failed错误; - 携带
tools的system消息不能再携带content字段,否则请求会以 400 报错(cannot be used with content);使用 OpenAI SDK 时可直接在messages中透传tools字段,无需extra_body。
相关阅读
- Kimi K3 API 工具调用最佳实践:动态加载、tool_choice 与思考力度的组合实践
- 工具调用约束:通过
tool_choice约束模型的工具调用行为 - 使用 Kimi API 完成工具调用:工具调用的完整流程与示例
- 模型参数参考:各模型对
tool_choice等参数的支持差异