早上打开终端,习惯性敲了个 claude,准备让它帮我写个简单的Python脚本。
突然想起来昨天Claude Code更新了2.1.69版本,说有个叫 Tool Search 的新功能。本着程序员的职业病,我决定先做个“控制变量实验”。
同样一个“hi”,不带任何skills和MCP插件,之前启动要占掉12%的context window,现在只用了3%。

整整4倍的压缩比。
那一刻我的表情:

用过Claude Code的同学都知道,这玩意儿强是真强,能吃也是真能吃。
以前的逻辑是这样的:不管你用不用工具,它把所有可用工具的完整定义一股脑全塞进初始prompt里。几十个工具的schema、参数说明、示例,加起来token数相当可观。
这就好比你去餐厅,服务员不问你要什么,直接给你上一整本菜谱,还附带每道菜的食材清单、烹饪方法、厨师照片。你只想点个宫保鸡丁,却被迫读完一本《随园食单》。
结果是:启动时context window就被占掉一大块,真正留给对话和任务的空间反而少了。
这次更新核心就一句话:按需加载,用的时候再拿。
怎么做的?启动时只注入两个东西:
当agent发现用户意图可能需要某个工具时(比如用户说“帮我发个邮件”),它会先通过ToolSearch按关键词搜索,或者直接按名字选取。这时候,被选中的工具定义才会被动态加载进context。
这就像你去图书馆,不再把整个图书馆的书都搬到自己桌上,而是先查目录,找到需要的书,再去书架上取那一本。
技术圈管这个叫 lazy loading,或者“懒加载”。但在AI agent的上下文管理里,这更像是一种 渐进式披露(progressive disclosure)——只在必要时才暴露细节。
Context window是AI的“工作记忆”,非常宝贵。省下来的空间意味着:
能处理更长的对话历史,agent的记忆力更强
能同时使用更多工具,但不会互相挤占
降低token消耗,省钱(对API用户来说直接和账单挂钩)
启动速度变快,用户体验提升
原文里12%降到3%是在“无任何插件”的纯净环境下测的。如果你的项目里配了几十个skills、MCP服务器,这个优化带来的收益会更明显——从可能直接撑爆context window,变成还能游刃有余。
其实这个思路Anthropic去年11月就在博客里预告过(Advanced tool use),核心思想是让模型自己决定什么时候需要什么工具,而不是开发者替它全盘托出。
类似的设计也出现在Cloudflare最近发布的 Code Mode 里(blog)。它们都在做同一件事:把上下文管理从“静态配置”变成“动态调度”。
看到这个设计,我第一反应是——这不就是操作系统的虚拟内存 + 按需分页吗?
以前全量加载所有工具,相当于进程启动时就把所有代码段和数据段都加载进内存。现在只加载工具名称(类似页目录),真正用到时才通过缺页中断把对应的工具定义(页面)调入。
如果工具数量继续增长(比如社区贡献了几百个skills),未来可能还需要“多级页表”——先按类别索引,再按名称索引,最后才加载具体定义。
AI agent的上下文管理,正在走操作系统内存管理的老路。 只不过管理的不再是物理内存,而是token这个更金贵的资源。
如果你正在用Claude Code开发复杂的agent应用,这个更新意味着:
但也要注意:Tool Search本身也会消耗一些token(搜索过程),不过相比全量加载,收益远大于开销。
Tool Search只是一个小小的更新,但它透露了一个重要趋势:随着AI agent越来越复杂,上下文管理正在成为一门核心学问。
就像操作系统管理内存、CPU调度、I/O一样,未来的AI平台需要一套完整的资源调度机制,来管理token、工具、记忆、任务优先级。
我们可能正站在一个新时代的起点——AI不再是单个模型,而是一个由无数组件构成的智能操作系统。
而Claude Code这次更新,就像操作系统里第一次引入虚拟内存:当时人们觉得内存够用,后来才发现,没有虚拟内存,就没有现代多任务系统。
同样的,没有Tool Search这类机制,我们也无法想象未来的AI agent能同时调用成百上千个工具,处理横跨数周的任务。
如果你也对AI agent的底层技术感兴趣,欢迎在评论区聊聊你的看法。我自己已经在琢磨怎么利用这个特性,给之前做的那个“wrapper”塞进更多技能了——反正现在,启动时只占3%嘛。
更新时间:2026-03-12
本站资料均由网友自行发布提供,仅用于学习交流。如有版权问题,请与我联系,QQ:4156828
© CopyRight All Rights Reserved.
Powered By 61893.com 闽ICP备11008920号
闽公网安备35020302035593号