Agent 开发指南:Kimi K3 动态加载工具,降低 30% Token 消耗

Agent 开发指南:Kimi K3 动态加载工具,降低 30% Token 消耗
做 Agent 的人都希望模型什么都能干:读文件、改代码、跑命令、搜网页、查 GitHub、操作日历……于是工具列表越挂越长。但主流的接入方式有一个隐蔽的假设:所有工具的声明,从第一轮对话起就全部躺在上下文里。每个请求的tools字段都原样带上全部工具的名称、描述和参数 schema,哪怕用户只是问了一句「今天天气怎么样」。
这笔开销有两部分。明面上的部分是 token 成本:一个带嵌套参数的工具轻松几百 token,五十个工具就是几十 k,还要乘以每一次请求、每一个用户。更麻烦的是第二部分——它还影响准确率:候选工具越多,模型越容易选错工具、编错参数,尤其是当工具名字长得像的时候。工具定义膨胀不只是费钱,它在持续拉低调用成功率。
Kimi 自己的 Agent 产品就是一个典型例子:挂着大量工具,流量又大,这两个成本都被放得很大。
动态加载工具:降低 30% token 消耗
当 Kimi K3 发布时带了动态加载工具这个新 API 特性,Kimi 第一方 Agent 产品也在第一时间完成了适配。效果显著:ToolCall 相关 token 下降了约 70%,输入 token 整体消耗下降了约 30%。
Agent 开发指南:Kimi K3 动态加载工具,降低 30% Token 消耗
◐基本用法:工具不该「常驻」上下文,应随用随取
动态加载工具的核心动作只有一个:在对话过程中,把工具声明作为一条 system 消息插进 messages,而不是一次性全堆在请求顶层的 tools 字段里。
消息插在哪个位置,工具就从哪个位置开始对模型可见;它和顶层 tools 的全局工具并存;声明格式与顶层完全一致,只是必须完整。对话开始只挂三五个核心工具,其余的等真正用到时再注入——上下文里永远只有真正相关的少量工具,模型的选择题从 50 选 1 变成 5 选 1
进阶用法:搭 tool search 循环,让模型自己找工具
动态加载工具真正发挥价值的用法,是搭一个 tool search 循环:顶层只放一个由你后端实现的 search_tools,模型需要能力时先搜,你的应用把命中工具的完整声明注入 messages,模型下一轮直接调用。
Agent 开发指南:Kimi K3 动态加载工具,降低 30% Token 消耗
这样无论工具总量多大,每一轮请求里实际存在的工具声明都只有几个。API 层面没有现成的 tool search 接口——这是有意为之,检索策略和业务强相关,自己实现几行代码比迁就通用接口效果好得多。
顺带说一个和 Anthropic 同类方案的区别:他们的 Tool Search Tool 要求改造既有工具定义、为每个工具增加  defer_loading  字段;Kimi 的方案不需要改动任何既有工具定义——把同一份 schema 原样放进一条消息里即可。更干净,迁移成本也几乎为零。
另外需要注意的是,动态加载工具目前仅 kimi-k3 支持。如果你的工具定义加起来超过约 10k token、或者模型开始在几十上百个工具里选错,就值得一试;工具不到十个且定义精简的话,不用折腾。
进一步了解:
  • 完整请求示例(curl / Python)、缓存行为和错误处理见文档:使用动态加载工具
  • 了解动态加载工具如何与 tool_choice、推理强度组合见文档:K3 工具调用最佳实践
One more thing:按需设定「推理强度」
Agent 开发指南:Kimi K3 动态加载工具,降低 30% Token 消耗
Kimi K3 模型 API 支持 lowhigh 和 max 三挡推理强度(reasoning_effort)设定,分别意味着:最快的响应速度、性能与响应速度的平衡和最强的性能
推理强度越高,模型思考越充分,token 消耗也越大,建议根据 Agent 任务的难度和对速度的要求,设定合理的推理强度,同样可以节省 token 消耗。
关于 K3 模型思考强度的说明,请参考文档:模型能力之推理强度
了解模型局限性
我们在模型发布文章中写了 Kimi K3 的两个已知的局限性:
  1. 对历史思考内容敏感: Kimi K3 在后训练过程中全程使用思考历史保留模式,如果 agent 框架未按要求回传全部历史思考内容,或从其他模型正在进行的会话中切换到 Kimi K3,则有可能引发上下文干扰,导致内容生成质量不稳定。建议使用 Kimi Code 等经过兼容性验证的 Agent 框架,并避免在会话中途切换到 Kimi K3。
  2.  过于主动:Kimi K3 的训练重点优化了长程、高难任务。因此,在任务执行过程中遇到小问题或用户意图模糊时,它可能会替用户做出非预期的决定。如果你的应用希望 agent 更有边界感、不要过于自由发挥,请在 system prompt 或 AGENTS.md 中对 Kimi K3 施加更明确的行为约束。
了解模型的这些局限性,有助于 API 开发者为模型打造更合适的 Harness,让 Kimi K3 发挥出更好的性能。
本文作者【Kimi API】,微信公众号:【Kimi开放平台】
原文链接:https://mp.weixin.qq.com/s/XbnFbgKL-mjNOoJ1ZIk3uA
行业动态

腾讯WorkBuddy实践:如何把Agent做成可用产品

2026-7-27 9:36:00

行业动态

本地部署 GLM-5.2 要花多少钱?我认真算了一笔账

2026-7-27 10:11:13

0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧