夜雨聆风很多人以为，AI Agent最贵的是模型推理。错了，很多时候最先吞你预算的，根本不是回答问题那一下，而是它上班前先把一整本“工具说明书”从头背到尾。你还没打字，账单先开工，这事听着像段子，结果现在已经是开发者日常挨刀现场。Kimi这次干的事，说白了，就是把这笔大家装看不见的“工具税”直接贴到墙上了。
不是模型太贵，是你把整个五金店都塞进上下文了
这事本质上不复杂。大模型要调用工具，前提是先知道工具叫什么、能干嘛、参数怎么传。问题就出在，很多框架默认做法非常豪横：不管这轮用不用，先把所有工具定义一股脑塞进每次请求。工具少的时候，你感觉不出来；工具一多，钱包就开始掉血。Anthropic在官方工程文章里直接点明，工具定义在优化前能吃掉 134K tokens，甚至更早的案例里，工具结果和定义在任务开始前就可能先耗掉 50，000+ tokens。
更扎心的是，这钱花了，还未必换来更好效果。工具越多，模型越容易选错工具、或者把参数拼错。这个逻辑很像你让一个新同事去拧四颗螺丝，结果先给他背来一整箱 30 多种批头，再让他自己挑。忙得挺认真，效率低得很真实。Cloudflare后来甚至直接开喷，说很多人“把 MCP 用错了”，他们的思路不是继续堆 tool，而是干脆把工具转成 TypeScript API，让模型写代码去调。这个思路很激进，但背后的潜台词很明白：别再让模型天天填表了。
Kimi这招像传送门，不背工具箱了，用的时候再拿
Kimi这次给出的办法，名字就很直白：Dynamically Loaded Tools，也就是动态加载工具。逻辑我现在正式宣布，属于那种“早该这样”的设计：开局只放少量核心工具，需要什么，先搜，再把那几个工具定义临时注入对话里。不是提前把整套家伙扛着跑，而是现场开个门，缺哪把拿哪把。
这套玩法已经进了 Kimi K3 的官方能力体系，K3 在 2026 年 7 月 16 日发布，支持 1M token 上下文；Kimi 的帮助文档和代码文档也都在强调，保持稳定前缀有利于命中 context caching，重复内容能拿到缓存折扣。麻烦就在这儿：你要是每轮都把工具声明大改特改，表面像是在省 token，缓存命中掉了，最后账单未必更好看。所以 Kimi给的方向其实挺务实，核心工具固定，业务工具按需追加。不是玄学，是工程账。
大家都在补这个洞，但Kimi是先把功能做成了门面产品
这不是 Kimi 一家突然觉醒，整个行业都在补课。Anthropic已经在官方文章里推 Tool Search Tool，用 defer_loading 把工具延后加载；Mastra 也上了 ToolSearchProcessor，先 search_tools，再 load_tool，思路和 Kimi 高度一致；Cloudflare则更狠，绕开传统 tool 暴露方式，直接走“让模型写代码调用 API”这条路。你品，你细品，路线不同，目标其实一样：别把上下文当仓库。
但这事也不是没有代价。动态加载省 token，往往会多一轮搜索、多一层编排，延迟和命中率都得重新平衡。搜错关键词，白跑；工具描述不清，还是翻车；客户端如果不自己管好多轮请求里的声明，还可能前脚省完、后脚又塞回去。这个操作，我给高分，但不能当万能药。它更像是让 Agent 从“暴力堆料”进入“按需配餐”，终于像个会过日子的系统了。
这笔“隐形税”，厂商早该认账了
让我来翻译一下很多 Agent 框架过去的心路历程：“工具越多越强，先全挂上再说。”结果就是，能力目录直接等于能力全集，模型还没干活，先被说明书埋了。这个决策的问题，不是不能用，而是太不把开发者的 token 当钱。尤其当 Kimi、Anthropic、Mastra、Cloudflare 这几路方案都已经把方向挑明之后，再继续默认全量注入，就多少有点“能省但懒得省”的意思了。严重吗？对轻量场景还好，对重度 MCP 用户，这就是每天都在掉血。能不能忍？单工具、小规模时能忍；一旦工具库上规模，这个洞就必须补。
行了，不开玩笑了，认真说——如果你本来就只接一两个工具，这事和你关系没那么大；但如果你在做多工具 Agent、MCP 编排、长上下文工作流，那动态加载已经不是“高级优化”，而是该进默认配置了。Kimi这次最值得看的，不是喊了个新概念，而是把这个老毛病做成了可落地的产品动作。至于值不值得现在就跟，得看你的工具规模和缓存策略。小团队先学思路，大团队赶紧治病。评论区聊聊，你觉得这是工程进步，还是行业终于承认自己以前太浪费？
温馨提示：文中部分信息整理自公开资料与网络信息，数据存在更新或偏差，欢迎理性交流与指正，具体请以官方最新公布为准。