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

但凡做过 Agent 的，谁不是希望模型什么都能干呢？读文件、改代码、跑命令、搜网页、查 GitHub、操作日历……工具列表越挂越长。

但这里有一个隐蔽的假设，很多人在一开始都没意识到：

每个请求的 tools 字段都原样带上全部工具的名称、描述和参数 schema，哪怕用户只是问了一句「今天天气怎么样」。

这笔开销有两部分。

明面上的部分是

：一个带嵌套参数的工具轻松几百 token，五十个工具就是几十 k，还要乘以每一次请求、每一个用户。

更麻烦的是第二部分——

：候选工具越多，模型越容易选错工具、编错参数，尤其是当工具名字长得像的时候。工具定义膨胀，不只是费钱——它在持续拉低调用成功率，而且是实打实的。

Kimi 自己的 Agent 产品就是一个典型例子：挂着大量工具，流量又大，这两个成本都被放得很大。

动态加载工具：降低 30% token 消耗

当 Kimi K3 发布时带了动态加载工具这个新 API 特性，Kimi 第一方 Agent 产品也在第一时间完成了适配。效果相当显著：

• ToolCall 相关 token 下降了约 70%
• 输入 token 整体消耗下降了约 30%

核心思路其实很简单：工具不该「常驻」上下文，应随用随取。

动态加载工具的核心动作只有一个：在对话过程中，把工具声明作为一条 system 消息插进 messages，而不是一次性全堆在请求顶层的 tools 字段里。

消息插在哪个位置，工具就从哪个位置开始对模型可见；它和顶层 tools 的全局工具并存；声明格式与顶层完全一致，只是必须完整。对话开始只挂三五个核心工具，其余的等真正用到时再注入——上下文里永远只有真正相关的少量工具，模型的选择题从 50 选 1 变成 5 选 1。

进阶用法则是搭一个 tool search 循环：顶层只放一个由你后端实现的 search_tools，模型需要能力时先搜，你的应用把命中工具的完整声明注入 messages，模型下一轮直接调用。

这样无论工具总量有多大，每一轮请求里实际存在的工具声明都只有几个。API 层面没有现成的 tool search 接口——这是有意为之，检索策略和业务强相关，自己实现几行代码比迁就通用接口效果好得多。

顺带说一个和 Anthropic 同类方案的区别：他们的 Tool Search Tool 要求改造既有工具定义、为每个工具增加 defer_loading 字段；Kimi 的方案不需要改动任何既有工具定义——把同一份 schema 原样放进一条消息里即可。更干净，迁移成本也几乎为零。

另外需要注意的是，动态加载工具目前仅 kimi-k3 支持。如果你的工具定义加起来超过约 10k token、或者模型开始在几十上百个工具里选错，就值得一试；工具不到十个且定义精简的话，不用折腾。

进一步了解：

• 完整请求示例（curl / Python）、缓存行为和错误处理可见文档「使用动态加载工具」
• 了解动态加载工具如何与 tool_choice、推理强度组合，可见文档「K3 工具调用最佳实践」

One more thing：按需设定「推理强度」

Kimi K3 模型 API 支持 low、high 和 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 发挥出更好的性能。