
tools字段都原样带上全部工具的名称、描述和参数 schema,哪怕用户只是问了一句「今天天气怎么样」。
system 消息插进 messages,而不是一次性全堆在请求顶层的 tools 字段里。tools 的全局工具并存;声明格式与顶层完全一致,只是必须完整。对话开始只挂三五个核心工具,其余的等真正用到时再注入——上下文里永远只有真正相关的少量工具,模型的选择题从 50 选 1 变成 5 选 1。tool search 循环:顶层只放一个由你后端实现的 search_tools,模型需要能力时先搜,你的应用把命中工具的完整声明注入 messages,模型下一轮直接调用。
tool search 接口——这是有意为之,检索策略和业务强相关,自己实现几行代码比迁就通用接口效果好得多。Tool Search Tool 要求改造既有工具定义、为每个工具增加 defer_loading 字段;Kimi 的方案不需要改动任何既有工具定义——把同一份 schema 原样放进一条消息里即可。更干净,迁移成本也几乎为零。kimi-k3 支持。如果你的工具定义加起来超过约 10k token、或者模型开始在几十上百个工具里选错,就值得一试;工具不到十个且定义精简的话,不用折腾。-
完整请求示例(curl / Python)、缓存行为和错误处理见文档:使用动态加载工具 -
了解动态加载工具如何与 tool_choice、推理强度组合见文档:K3 工具调用最佳实践

low、high 和 max 三挡推理强度(reasoning_effort)设定,分别意味着:最快的响应速度、性能与响应速度的平衡和最强的性能。-
对历史思考内容敏感: Kimi K3 在后训练过程中全程使用思考历史保留模式,如果 agent 框架未按要求回传全部历史思考内容,或从其他模型正在进行的会话中切换到 Kimi K3,则有可能引发上下文干扰,导致内容生成质量不稳定。建议使用 Kimi Code 等经过兼容性验证的 Agent 框架,并避免在会话中途切换到 Kimi K3。 -
过于主动:Kimi K3 的训练重点优化了长程、高难任务。因此,在任务执行过程中遇到小问题或用户意图模糊时,它可能会替用户做出非预期的决定。如果你的应用希望 agent 更有边界感、不要过于自由发挥,请在 system prompt 或 AGENTS.md 中对 Kimi K3 施加更明确的行为约束。
本文作者【Kimi API】,微信公众号:【Kimi开放平台】
原文链接:https://mp.weixin.qq.com/s/XbnFbgKL-mjNOoJ1ZIk3uA
