夜雨聆风你以为大模型的上下文窗口是留给你的？不，工具定义已经先你一步住进去了，而且是"常驻租户"
想象一个场景：你雇了一位顶级私人管家，能力超群，上知天文下知地文，接得了API、读得了数据库、发得了消息，但每天早上他出门，都要先把家里全部三百件工具背在身上电钻、扳手、螺丝刀、焊枪、甚至鱼竿，一件不落等他气喘吁吁到了工地，才发现今天只是拧五颗螺丝
这幅比喻，画的正是今天不少AI Agent的日常
▲ Kimi官方漫画：左边满头大汗扛着30+批头，右边装完桌子才发现只用了5种
一条推文，撕开了MCP的"隐性账单"
7月19日，Moonshot AI旗下Kimi开发者官方账号在X平台发了一条看似平静的技术帖它没发布新模型，也没喊价格战，只冷静地抛出一个词：
Tool Definition Bloat（工具定义膨胀）
它点出的代价很残酷：当你的应用挂载了大量工具，每次请求都把全部工具的名称、描述、参数Schema一股脑塞进tools字段，Token会被反复推高；候选工具越多，模型越容易选错，甚至构造出根本不合法的调用参数
问题可以概括为：给AI增加能力的同时，也可能给它增加噪声
▲ Kimi Platform官方文档，正式将"动态加载工具"作为推荐架构
13.4万Token，这个数字从何而来？
Kimi的推文里没有写具体数字。但把它点名的问题，放回行业已有的量化观测里，画面立刻变得触目惊心
Anthropic在介绍高级工具使用能力时，白纸黑字写道：
"At Anthropic, we've seen tool definitions consume 134K tokens before optimization."
▲ Anthropic明确写出：优化前，工具定义本身消耗了约13.4万Token
13.4万Token，还没等用户说第一个字，上下文窗口就已经被工具的"自我介绍"吃掉了一大半
社区开发者Björn Büdenbender还做了一个更直观的实测：他在Claude Code上挂了10个MCP服务器、212个工具，测出来的工具定义开销是，
约16.4万Token，占上下文窗口的82%
▲ 实测数据：仅GitLab一个MCP服务器就贡献了约5.8万Token
其中最重的GitLab服务器，78个工具，单独占掉约58,000 Token你的200K上下文窗口，在用户开口之前，就只剩下不到四万Token的"工作记忆"了
AI的大半上下文，竟被工具说明书占满
MCP的"行李超重"难题
稍微退一步，给不熟悉的读者30秒科普
MCP（Model Context Protocol） 是Anthropic推动的开放标准，被类比为"AI的USB-C"，让AI应用以统一方式连接外部数据源与工具GitHub、Slack、数据库、监控系统，统统可以通过MCP服务器"插上"
这个设计极大降低了接入成本。问题是，降得太低了。
开发者们开始"顺手多挂几个服务器"。五个不够？十个！二十个！能力越多越好嘛，直到有一天发现，一些行业估算给出的单个工具定义开销约为100到500个Token，十几个服务器、上百个工具累积起来，轻松冲到数万乃至十几万
而且是每一轮请求都要带一遍。
行业综述还汇总过一组基准观察：工具数从约20个增加到约107个时，模型选工具的准确率从接近满分直接崩塌到基本失败同一综述提到，GitHub Copilot曾把工具从40砍到13，延迟和准确率随之改善
越接越多，越接越废。 MCP也因此背上了"行李超重"的包袱
Kimi的解法：先搜索，再装弹
Kimi随即给出了工程方案：Dynamically Loaded Tools（动态加载工具）
▲ 续帖漫画：通过tool_search"传送门"，只取回需要的5个工具
核心逻辑极其优雅：
第一步，对话开始时，顶层tools只放一个search_tools检索工具，外加极少量每轮必用的核心工具行李箱里只放钥匙和钱包。
第二步，模型根据用户意图，先调用search_tools在后端工具库里检索匹配项
第三步，应用把匹配到的工具的完整定义，以system消息的形式注入到messages中，从这个位置开始，模型才"看见"这些工具
第四步，后续轮次直接调用已加载工具，不再重复搬运整个工具箱
▲ 官方最佳实践：只声明搜索工具，避免一次性列出全部工具
Kimi文档还写明了几个关键细节：动态工具与全局工具可以共存；带tools的system消息不能同时带content（否则直接400）；目前这套能力明确支持kimi-k3，其他型号可能报错
全行业都在"收敛"
这套思路已经在行业内多处出现。
Anthropic早在2025年底就推出了Tool Search Tool，大部分工具标记为延迟加载，初始上下文几乎只见搜索工具，需要时再展开完整定义思路与Kimi几乎同构。
▲ Anthropic的解法：Tool Search Tool + Programmatic Tool Calling
Mastra框架的用户Derek Colley在回帖中直接指出：Mastra的ToolSearchProcessor暴露search_tools和load_tool两个元工具，从大型注册表中按需激活，概念上与Kimi的路径几乎完全一致
▲ 框架用户指出Mastra的ToolSearchProcessor与Kimi方案同构
社区里甚至有更激进的声音。开发者@redchethan直接反问：
"isn't this just skills.md but with extra steps"
，上下文里只放技能摘要，需要时再展开，这不就是懒加载吗？
▲ 有人认为这本质上就是skills.md的升级版
而开发者**@mikeluan123则提出了一个更务实的担忧：动态加载固然省Token，但会增加对话轮次**他建议在搜索工具里直接列出合法关键词，确保一轮就命中，避免"搜空→换词→再搜"的往返损耗
▲ 务实提醒：动态加载省了Token，但可能多花轮次
一条被忽视的因果链
把时间线拉开，你会看到一条清晰的因果链条：
MCP降低了"加能力"的门槛 → 开发者默认全量挂载工具 → 工具元数据吃掉上下文、选工具噪声飙升 → 各家被迫转向"目录可搜索、定义可懒加载"的架构 → Kimi在K3 API里把这套实践产品化
API网关方AIHubMix几乎在第一时间宣布兼容K3的动态工具加载格式生态的响应速度，本身就说明了问题的普遍性
▲ 网关方迅速跟进，侧面印证需求的迫切性
写在最后：你的上下文窗口，到底是谁的？
这个问题值得每一个做Agent的开发者认真想一想
200K的上下文窗口听起来很豪华但当16万Token被工具说明书占据，留给任务推理的空间，可能还不如两年前的GPT-4
这样的智能体，像一个背着全家当跑马拉松的搬运工
动态加载、工具搜索、缩小每个Agent可见工具面、代码态编排、网关层过滤，这些平行出路已经摆在台面上工具定义膨胀已经写进此刻正在燃烧的账单
Kimi用一张漫画把它说透了：装一张桌子，不需要扛着整个五金店上门
