给 Claude Code 挂了几十个工具后我发现“给 AI 减负”是个伪命题我先说结论很多人问我“Claude Code 该配多少个工具”我的答案是——先别急着装你大概率已经装多了。Claude Code 最近在开发圈里热度确实高它把 AI 编程助手的交互方式从“对话框聊代码”变成了“命令行里指挥协作者”。但随之而来的风气也很奇怪大家开始比谁的 MCP 工具列表更长好像挂上五十个工具AI 就能从初级程序员变成架构师。我在这个方向上走了很远前后给 Claude Code 挂过三十多个工具覆盖数据库、浏览器自动化、HTTP 请求、文件系统、各种第三方 API、定时任务、甚至还有控制智能家居的工具。听起来很唬人对吧实际跑起来才发现工具越多AI 越容易“精神分裂”——它会反复思考该调哪个工具会在不合适的场景里强行调用错误的工具还会被大量良莠不齐的工具描述吃光上下文窗口。这篇文章不是什么“卸载教程”也不是让你回到纯命令行裸奔。我想把自己这一路踩出来的经验整理成一套“工具数量与质量平衡”的实操方案讲清楚为什么“给 AI 减负”这个提法本身就是个伪命题——因为问题的关键从来不是 AI 太累而是你的工具配置让它在无效决策上消耗了太多算力和上下文。适合谁看正在给 Claude Code 配 MCP 工具但感觉越配越乱的人以及那些刚接触 Claude Code、想一步到位但又怕走弯路的新手。1. 从“工具越多越好”到“工具越多越乱”我到底经历了什么1.1 最初为什么疯狂装工具——MCP 生态的心智陷阱第一次用 Claude Code 的时候我其实也被震撼到了。它能直接在终端里读写文件、执行命令、跑测试那种“程序员真的要被取代了”的压迫感是实实在在的。但用了一个星期之后我遇到一个很实际的问题它没办法直接查数据库、没办法直接联网拉取最新文档、没办法调用某些内部 API。这时候就有人告诉我装个 MCPModel Context Protocol服务器把外部能力全都接进来。MCP 的原理不复杂你可以把它理解成给 AI 装“外接设备”。原本模型只知道自己脑子里的知识但通过 MCP它就能调用你的文件系统、数据库、浏览器、支付接口、甚至公司内部的运维平台。听起来是不是很像给手机装应用这个类比就是我踩坑的开始——既然装应用就能获得新能力那为什么不把能装的都装上于是我进入了非常典型的“收集癖”节奏。Git 相关的 MCP 装了三个数据库相关的装了四个MySQL、PostgreSQL、SQLite 各一个还有一个通用查询的浏览器自动化的装了两个HTTP 请求工具装了两个再加上文档解析、图片识别、音视频处理、定时任务、环境变量管理……具体数量我没细数但一度达到了三十多个。每装一个新工具我都会在 Claude Code 里看到它对某个请求的处理更“聪明”了那种成就感就像抽卡游戏里又抽到一个 SSR完全停不下来。1.2 工具增益递减曲线从“神器”到“鸡肋”的转折点这种“多多益善”的幻觉大概在第十个工具左右开始出现裂缝。我先说一个很容易被忽略的事实Claude Code 每次和模型通信的时候它会把你配置的所有工具的名称、描述、参数定义全部塞进上下文里让模型知道“我有这些能力可用”。但模型的注意力是有限的它不可能在每一轮对话里对所有工具保持同样高的关注度。工具越多每个工具分到的“关注权重”就越低。我用一个非常典型的现象来说明这个问题。某次我让 Claude Code 帮我分析一个前端项目的依赖关系它明明可以直接用我装的 Git 工具查看提交历史、用文件系统工具读取 package.json结果它先调用了浏览器自动化工具去打开一个本地页面然后又在 HTTP 请求工具里尝试请求 localhost 的调试端口反复折腾了好几次最后才想起来用文件工具。整个过程浪费了大概两分钟而且消耗的 token 数量比直接读文件多了好几倍。这个现象我后来查了一些技术资料才明白模型在决定调用什么工具时本质是在做一个“多选一”的决策。选项越多决策的准确性就越低尤其是在工具描述写得不清晰的情况下。就像你去餐厅点菜菜单只有五道菜的时候你闭着眼都能选对招牌菜但给你一本五百道菜的菜单你反而会在“宫保鸡丁”和“辣子鸡丁”之间纠结半天——AI 也一样。还有一个更隐蔽的问题工具之间的边界感变得模糊了。我装了三个 Git 相关的 MCP分别是 GitHub 官方 MCP、某个第三方 Git 增强工具、还有一个只做代码搜索的工具。功能大量重叠Claude Code 经常搞不清楚该用哪一个。它可能先用第三个工具搜索代码没找到结果又换第一个工具去访问 GitHub API最后才发现其实第二个工具才是处理当前仓库的最佳选择。这种重复试错带来的 token 浪费很多人根本不会注意到因为只要任务最终完成了他们就觉得“AI 真聪明”但实际上如果只留一个工具任务早就完成了。2. 挂了几十个工具后真正卡住 AI 的从来不是“少工具”2.1 上下文预算才是真正的“内存条”——工具描述也在吃掉上下文如果你对 Claude Code 的上下文机制有一定了解就会知道它有个“上下文窗口”的概念。基础版本大概支持 20 万 token某些配置下可以扩展到 100 万级别。听起来很大对吧但你别忘了工具描述、系统提示词、历史对话记录、当前文件内容全都住在同一个窗口里。我的实测经验是一个写得比较详细的外部 MCP 工具描述动辄占 500 到 1500 token如果是那种把每个参数都解释得特别啰嗦的3000 token 也不是没有可能。你算一笔账就知道问题有多严重了。假设你挂了 30 个工具平均每个工具描述 800 token那就是 24000 token占了 20 万窗口的 12%。乍一看好像还能接受但问题是 Claude Code 的对话轮次会把之前的工具调用结果全部保存在上下文里越到会话后期工具调用历史占用的空间越大而留给真正需要推理的内容的空间就越少。这就好比你的电脑有 64GB 内存但后台常驻了 50 个流氓软件每个都吃几百 MB真正能分给 Photoshop 的还剩多少更坑的一点是第三方 MCP 工具的描述质量完全不可控。我自己装过的一个“网页搜索工具”描述里附带了一大段英文的 API 使用文档、错误码表、限流说明加起来两千多 token但实际用的时候它搜出来的结果还不如直接让我手动复制网址给 Claude 看。这种工具不仅没有提升效率反而在每次会话开始时就白白占用了上下文预算。所以我后来养成了一个习惯每装一个新工具先让 Claude Code 把它的完整描述打印出来看一眼凡是超过 1000 token 且内容里有一半是废话的基本可以判定为垃圾工具。2.2 工具噪音多一个入口就多一个决策分叉我在前面提到了菜谱类比这里想再深入聊一下“工具噪音”这个概念。在信息论里噪音指的是干扰有效信息传输的无用信号。放到 Claude Code 的场景里多余的工具就是噪音——它们不会帮助模型更好地完成任务反而会让模型在“该不该用、该用哪个”这件事上浪费更多的推理时间和 token。最典型的场景就是当任务描述比较模糊的时候工具噪音的影响会被无限放大。比如我给 Claude Code 一句话指令“帮我查一下最近提交里改了哪些文件”。在没有工具噪音的情况下它会直接调用 git 工具一步到位。但如果我同时挂着 5 个和代码相关的工具它就开始“独立思考”了会不会 GitHub 工具更合适要不要先搜索一下代码也许应该用文件系统工具去看看 .git 目录这种发散式的决策路径会极大拉低执行效率。我在大量实践中观察到的一个规律是工具数量超过 15 个以后Claude Code 的“首发成功率”即第一次调用工具就选对并且成功拿到结果的概率会明显下降。从 90% 以上掉到 70% 甚至更低。别小看这 20% 的差距一次失败的调用意味着一次完整的工具执行——加载、返回结果、把结果塞进上下文、然后模型再重新分析——这些全都是白花花的 token 和时间。2.3 工具质量参差第三方 MCP 的隐性风险聊到这儿可能有人会问那我多装的是“优质工具”不就行了问题在于优质工具实在太少了。MCP 生态现在就像早期的安卓应用市场谁都可以开发一个 MCP 服务器发布出来但大部分既没有完善的文档也没有稳定的维护。我踩过的坑包括但不限于某个数据库 MCP 在连接字符串里硬编码了超时时间导致我稍微跑个复杂一点的查询就直接 timeout某个浏览器自动化工具每次启动都会弹出一个调试窗口在远程服务器上根本无法使用还有一次更严重一个文件操作类的 MCP 工具竟然在删除目录的时候没有做递归安全检查差点把那个项目的 node_modules 之外的东西也一并清了。所以我在这个阶段最大的一个认知转变是工具的“可用性”比“功能性”重要得多。一个只提供三个简单函数但稳定运行一年的工具远远好过一个功能看起来极其强大但三天两头报错的工具。具体到选择层面我建议优先选择官方出品的 MCP比如 GitHub 官方、Supabase 官方其次是社区里 star 数量高且更新频繁的第三方工具最后才考虑那些个人开发者随手发布的“小玩具”。每个准备接入的工具都要在非关键项目里先试用一周确认稳定可靠再考虑是否把它纳入日常配置。3. 我把 Tools 从 30 个砍到 8 个后实测效果反而变好了3.1 我的精简清单这 8 个工具留下了唠叨了这么多到了该上干货的时候了。在一次大扫除中我把三十多个工具砍到了八个。这里要先声明八个这个数字不是标准答案不同行业的项目、不同使用习惯的人合理数量会有差异。但我在实际测试中发现对于大多数以“写代码、查代码、跑测试、改配置”为主要工作流的开发者来说八到十个工具基本覆盖了九成需求再往上走边际收益真的趋近于零。下面是我的保留清单供你参考工具类型具体工具保留原因代码搜索ripgrep 相关 MCP速度极快秒级搜索大型代码库描述简洁文件读写Claude Code 内置文件工具官方原生稳定性最高无第三方依赖终端命令Claude Code 内置 Bash 工具几乎所有操作的最后兜底必留Git 操作GitHub 官方 MCP覆盖 issue、PR、releaseAPI 设计清晰数据库查询单一 MySQL MCP只留最常用的其余数据库需求走命令HTTP 请求我本地自封装的轻量请求工具控制描述长度只保留最小必要参数文档解析自写的 markdown 转纯文本脚本内部格式可控不会被第三方解析逻辑坑定时任务系统 cron 配合通知脚本不依赖 MCP直接走命令行减少一层损耗可能有读者会问那浏览器自动化呢网页搜索呢我现在的态度是这些工具已经变成了“按需临时安装”而不是“常驻后台”。需要处理网页上的数据我就在那一轮的会话中临时挂上对应的 MCP用完就卸而像数据库这类高频工具虽然保留了但也做了大量参数精简确保描述足够短。3.2 CLAUDE.md 中的工具使用约束配置——让 AI 知道“什么时候别用工具”人少好办事工具少也好管理。但光砍数量还不够你还需要在配置文件里明确告诉 Claude Code哪些场景优先用哪个工具、哪些场景坚决不要用某个工具。Claude Code 支持通过一个叫CLAUDE.md的项目级配置文件也可以用全局配置来约束 AI 的行为这个文件里的指令优先级非常高几乎可以说是在模型开始工作之前就灌入的“岗位职责说明书”。我的CLAUDE.md里有一段专门针对工具调用的规则贴出来给个参考## 工具使用约束 1. 默认情况下优先使用内置的 Bash 工具和文件工具处理任务除非该任务明确需要外部数据。 2. 查询代码时第一选择是 ripgrep 工具不要先打开浏览器或调用 GitHub API。 3. 数据库查询必须使用配置好的 MySQL 工具禁止通过 HTTP 工具连接数据库端口。 4. 除非用户明确要求否则不要使用浏览器自动化工具。需要查看网页时先询问用户是否需要。 5. 所有工具调用前先评估是否存在更轻量的替代方案如直接用 grep 而不是调用代码搜索 MCP。 6. 如果某个工具连续两次调用失败停止调用并向用户报告错误不要尝试第三次。你可能注意到了这些规则的核心目的不是教 AI 怎么用工具而是教 AI “什么时候别用工具”。这个思路是我踩了无数次坑之后总结出来的AI 默认会倾向于把所有能力都用一遍来证明自己很努力但这种努力往往是无效的。通过在CLAUDE.md里明确设置边界相当于给它的行为上了一圈“护栏”让它在决策路径上少走很多弯路。这里有个很容易忽视的细节CLAUDE.md的指令长度和工具描述一样也会占用上下文窗口。所以你没不要写几千字的“编年史”而是把所有规则压缩成短小、硬性的指令能一句话讲清楚的绝不用两句话。同时如果一个规则已经内化到工具的调用习惯里了AI 能在大部分情况下稳定遵守可以把它删掉不要长期占着上下文。我把这称作“规则动态清理”和代码重构里的“删死代码”是一个逻辑。4. 真正给 AI 减负的三个关键方向4.1 减负第一刀压缩工具描述而不是砍工具数量很多人一听到“工具太多了”就直接开始卸载但我认为这只是表面工程。真正有效的手段是“工具描述瘦身”。不知道你有没有注意过官方内置工具的描述通常非常简洁比如 Bash 工具就一句话“Execute a bash command”——它没有长篇大论地解释什么是 bash、有哪些参数、返回格式是什么但模型依然能用好它。为什么因为 Claude 系列的模型本身对命令行非常熟悉你不需要浪费 token 去教它。但第三方 MCP 工具就不一样了。开发者为了让自己写的工具看起来更专业常常在描述里塞大量背景信息比如“这是一个基于 xxx 框架开发的 xxx 服务用于 xxx 场景下的 xxx 操作支持 xxx 功能……”这些对模型来说大部分都是冗余信息。我的做法是每个 MCP 工具的配置文件通常在.mcp.json或 Claude Code 的配置文件里中找到description字段手动覆盖成十几个词的极简描述。比如一个文件上传工具的原始描述可能有 500 字我会直接改成“上传本地文件到当前项目的 /uploads 目录返回 URL”完事。这里的底层逻辑是模型的工具调用能力并不依赖你对工具的“全面介绍”它依赖的是“工具名称 一句话说明 参数结构”的充分性。只要这三个要素清晰模型就知道该在什么时候用它。压缩描述等于把省下来的上下文空间留给对话历史和工作内容这对长会话体验的改善是立竿见影的。4.2 减负第二刀给工具加“语境围栏”“语境围栏”这个词是我自己造的概念。什么意思呢就是说你要明确规定某个工具只能在什么语境下使用不能脱离场景乱来。最典型的例子就是网页搜索工具。如果你不限制AI 会在写代码遇到任何一个不确定的 API 时都想去搜索一下但很多内部 API 或者历史版本的接口在网上根本搜不到有效信息反而把一个本来可以继续推进的任务卡在“搜索—失败—再搜索”的循环里。我在CLAUDE.md里给网页搜索工具专门加了一条规则“当用户处于离线开发环境或任务涉及内部代码时禁止调用网页搜索。只有用户明确要求查找最新外部文档或技术博客时才允许使用。”加了这条规则之后AI 的“乱搜索”行为基本消失了任务的平均完成时间短了不少。这个思路其实还可以扩展到更多场景比如数据库工具只允许在应用配置了数据库连接的项目里使用浏览器自动化工具只允许在需要模拟用户操作的场景下使用HTTP 工具只允许在用户给定了完整端点时使用。标注清楚每个工具的使用边界本质上是在帮模型做“决策剪枝”有效减少发散路径——对于 AI 来说选择越少正确率越高。4.3 减负第三刀让模型自己决定是否调用工具最后这个方向听起来有点抽象但它是我在实践中体会最深的一点。早期我对 Claude Code 的使用方式很“霸道”只要任务稍微复杂一点我就手动列出计划让它必须调用某个工具去完成某个步骤。结果 AI 变得像个提线木偶我自己反而成了真正的大脑它并没有发挥出应有的价值。后来我改变了策略我只描述目标不规定实现路径。举个例子我让它“把项目里所有 TODO 注释汇总成一份报告”我不告诉它要用 grep 还是用文件扫描我只说目标剩下的交给它自己判断。在精简后的工具环境里它通常会首选 ripgrep因为描述里写明了这是一个快速搜索工具如果找不到它才会退而求其次用 Bash 的find或grep组合。这种“让模型自主决策”的模式比我之前事无巨细地安排每一步的效率高了很多而且任务完成质量也更好。这里要补充一个技术细节Claude Code 这种工具型 AI 的“自主决策”能力本质上依赖于上下文中的工具描述质量和历史交互反馈。工具少而精的时候模型就像在一张相对干净的桌子上工作它能分清哪些是自己的工具、哪些是干扰项工具多而杂的时候它就像在堆满杂物的房间里找一把螺丝刀虽然最后也能找到但中间浪费的时间绝对不少。5. 常见问题与排查实录5.1 MCP 连接失败不是每次重启都能解决这个坑几乎每个玩 MCP 的人都遇到过。现象是你明明在配置文件里加好了 MCP 服务器的地址但启动 Claude Code 后却发现工具列表里没有它。我最初的做法是反复重启 Claude Code偶尔能好但下一次还是会断。后来我耐心排查了一遍发现大多数 MCP 连接失败的原因就三个一是本地服务根本没启动尤其是一些需要npx或node临时启动的第三方工具二是配置文件里的路径写错了Windows 和 Linux 的路径写法差异特别容易踩三是 MCP 服务器本身崩溃后没有自动重启机制。排查建议是先手动在终端里跑一下 MCP 服务器的启动命令确认能起来再去检查配置文件里的参数如果确认无误但 Claude Code 仍然找不到工具去看日志。Claude Code 的日志里会明确记录每一个 MCP 服务器的启动状态和报错原因比在配置里瞎猜高效得多。像这类“本地服务没有自动重启”的问题有一个非常实用的兜底方案把 MCP 启动命令包装成 systemd 服务或开机脚本确保它一直在后台运行这样就不会因为一次崩溃导致整个工具消失。5.2 上下文长度报错以 10485 为例的排查思路你可能会在社区里看到有人贴出这样的报错api error: 400 this models maximum context length is 10485。这个数字看起来很奇怪明显不是 Claude 系列模型的标称上下文长度。我第一次看到的时候也很懵我明明用的是 20 万上下文的模型为什么报一个 10485 的限制后来查了很多资料才明白这个报错通常不是模型本身限制而是某个第三方 MCP 工具内部对输入输出做了参数限制或者在调用某个外部服务时那个服务的 API 有自己的最大上下文限制。10485 这个数字一般不是模型报出来的它大概率来自某个被调用的 API 网关或代理配置。排查思路分三步第一步确认报错发生在调用哪个工具的时刻第二步查看该 MCP 服务器的文档找到它的max_context_length之类的配置项第三步如果这个工具是自封装的直接在自己代码里调大限制即可。如果是第三方工具可以考虑换一个不受限的工具或联系维护者。这类问题之所以让很多人一头雾水是因为大家都把注意力放在 Claude Code 的模型选择上忽略了中间那一层工具代理的“二次限制”。5.3 如何判断某个工具是否该卸载最后分享一个“工具自检清单”每当你纠结某个 MCP 工具要不要留的时候就拿这四把尺子量一下这个工具在过去两周内被我主动调用过吗如果没有删。如果这个工具突然消失我的工作流会受影响吗如果不会删。这个工具的描述长度超过了 800 token 吗如果超过先尝试压缩描述压缩后依然不清晰删。这个工具和另一个已保留工具的功能有重叠吗如果有重叠只保留更稳定、描述更短的那一个。这套自检逻辑最核心的一点是工具的价值不在于“它多强大”而在于“它多久被用一次”。一个一年也用不上几次的“万能工具”即使再智能也只是占着上下文、制造噪音的包袱。我从三十几个工具砍到八个中间没有任何一个任务因为工具减少而卡住反而因为调用链路短整体效率提升了一个档次。再补充一个彩蛋如果你关心enable_prompt_caching_1h1这种配置有没有用——我的实测结论是它对降低长会话的成本有正向效果但它在工具选择引起的“无效往返”问题上帮不上忙。也就是说缓存优化不能替代工具精简两个方向最好一起做。先瘦身再缓存效果才会真正叠加。写在最后的一个实战体会回到标题那句话“给 AI 减负”确实是个伪命题不是我打击大家而是因为你越是把它当成一个需要费力“照顾”的对象越容易陷入两难——装一堆工具怕它累着不装又怕它能力不够。我在实际操作中的体会是Claude Code 需要的不是一个“更轻松的 AI”而是一个“更干净的运行环境”。与其想着怎么减轻它的负担不如先把周围那些主动增加的干扰清干净——删掉不用的工具、压缩工具描述、用CLAUDE.md立好边界。做完这四件事你会发现它不仅不累反而能干得比你预期的还要多。如果你现在还处于“工具多但不顺手”的阶段建议下周找个下午按我上面那张自检清单做一次彻底的“断舍离”然后带着精简后的配置跑两周再看结果——我敢说你大概率不会再想挂回那三十多个工具了。 Claude Code 工具配置实战：MCP 不是越多越好，上下文效率为王
给 Claude Code 挂了几十个工具后我发现“给 AI 减负”是个伪命题我先说结论很多人问我“Claude Code 该配多少个工具”我的答案是——先别急着装你大概率已经装多了。Claude Code 最近在开发圈里热度确实高它把 AI 编程助手的交互方式从“对话框聊代码”变成了“命令行里指挥协作者”。但随之而来的风气也很奇怪大家开始比谁的 MCP 工具列表更长好像挂上五十个工具AI 就能从初级程序员变成架构师。我在这个方向上走了很远前后给 Claude Code 挂过三十多个工具覆盖数据库、浏览器自动化、HTTP 请求、文件系统、各种第三方 API、定时任务、甚至还有控制智能家居的工具。听起来很唬人对吧实际跑起来才发现工具越多AI 越容易“精神分裂”——它会反复思考该调哪个工具会在不合适的场景里强行调用错误的工具还会被大量良莠不齐的工具描述吃光上下文窗口。这篇文章不是什么“卸载教程”也不是让你回到纯命令行裸奔。我想把自己这一路踩出来的经验整理成一套“工具数量与质量平衡”的实操方案讲清楚为什么“给 AI 减负”这个提法本身就是个伪命题——因为问题的关键从来不是 AI 太累而是你的工具配置让它在无效决策上消耗了太多算力和上下文。适合谁看正在给 Claude Code 配 MCP 工具但感觉越配越乱的人以及那些刚接触 Claude Code、想一步到位但又怕走弯路的新手。1. 从“工具越多越好”到“工具越多越乱”我到底经历了什么1.1 最初为什么疯狂装工具——MCP 生态的心智陷阱第一次用 Claude Code 的时候我其实也被震撼到了。它能直接在终端里读写文件、执行命令、跑测试那种“程序员真的要被取代了”的压迫感是实实在在的。但用了一个星期之后我遇到一个很实际的问题它没办法直接查数据库、没办法直接联网拉取最新文档、没办法调用某些内部 API。这时候就有人告诉我装个 MCPModel Context Protocol服务器把外部能力全都接进来。MCP 的原理不复杂你可以把它理解成给 AI 装“外接设备”。原本模型只知道自己脑子里的知识但通过 MCP它就能调用你的文件系统、数据库、浏览器、支付接口、甚至公司内部的运维平台。听起来是不是很像给手机装应用这个类比就是我踩坑的开始——既然装应用就能获得新能力那为什么不把能装的都装上于是我进入了非常典型的“收集癖”节奏。Git 相关的 MCP 装了三个数据库相关的装了四个MySQL、PostgreSQL、SQLite 各一个还有一个通用查询的浏览器自动化的装了两个HTTP 请求工具装了两个再加上文档解析、图片识别、音视频处理、定时任务、环境变量管理……具体数量我没细数但一度达到了三十多个。每装一个新工具我都会在 Claude Code 里看到它对某个请求的处理更“聪明”了那种成就感就像抽卡游戏里又抽到一个 SSR完全停不下来。1.2 工具增益递减曲线从“神器”到“鸡肋”的转折点这种“多多益善”的幻觉大概在第十个工具左右开始出现裂缝。我先说一个很容易被忽略的事实Claude Code 每次和模型通信的时候它会把你配置的所有工具的名称、描述、参数定义全部塞进上下文里让模型知道“我有这些能力可用”。但模型的注意力是有限的它不可能在每一轮对话里对所有工具保持同样高的关注度。工具越多每个工具分到的“关注权重”就越低。我用一个非常典型的现象来说明这个问题。某次我让 Claude Code 帮我分析一个前端项目的依赖关系它明明可以直接用我装的 Git 工具查看提交历史、用文件系统工具读取 package.json结果它先调用了浏览器自动化工具去打开一个本地页面然后又在 HTTP 请求工具里尝试请求 localhost 的调试端口反复折腾了好几次最后才想起来用文件工具。整个过程浪费了大概两分钟而且消耗的 token 数量比直接读文件多了好几倍。这个现象我后来查了一些技术资料才明白模型在决定调用什么工具时本质是在做一个“多选一”的决策。选项越多决策的准确性就越低尤其是在工具描述写得不清晰的情况下。就像你去餐厅点菜菜单只有五道菜的时候你闭着眼都能选对招牌菜但给你一本五百道菜的菜单你反而会在“宫保鸡丁”和“辣子鸡丁”之间纠结半天——AI 也一样。还有一个更隐蔽的问题工具之间的边界感变得模糊了。我装了三个 Git 相关的 MCP分别是 GitHub 官方 MCP、某个第三方 Git 增强工具、还有一个只做代码搜索的工具。功能大量重叠Claude Code 经常搞不清楚该用哪一个。它可能先用第三个工具搜索代码没找到结果又换第一个工具去访问 GitHub API最后才发现其实第二个工具才是处理当前仓库的最佳选择。这种重复试错带来的 token 浪费很多人根本不会注意到因为只要任务最终完成了他们就觉得“AI 真聪明”但实际上如果只留一个工具任务早就完成了。2. 挂了几十个工具后真正卡住 AI 的从来不是“少工具”2.1 上下文预算才是真正的“内存条”——工具描述也在吃掉上下文如果你对 Claude Code 的上下文机制有一定了解就会知道它有个“上下文窗口”的概念。基础版本大概支持 20 万 token某些配置下可以扩展到 100 万级别。听起来很大对吧但你别忘了工具描述、系统提示词、历史对话记录、当前文件内容全都住在同一个窗口里。我的实测经验是一个写得比较详细的外部 MCP 工具描述动辄占 500 到 1500 token如果是那种把每个参数都解释得特别啰嗦的3000 token 也不是没有可能。你算一笔账就知道问题有多严重了。假设你挂了 30 个工具平均每个工具描述 800 token那就是 24000 token占了 20 万窗口的 12%。乍一看好像还能接受但问题是 Claude Code 的对话轮次会把之前的工具调用结果全部保存在上下文里越到会话后期工具调用历史占用的空间越大而留给真正需要推理的内容的空间就越少。这就好比你的电脑有 64GB 内存但后台常驻了 50 个流氓软件每个都吃几百 MB真正能分给 Photoshop 的还剩多少更坑的一点是第三方 MCP 工具的描述质量完全不可控。我自己装过的一个“网页搜索工具”描述里附带了一大段英文的 API 使用文档、错误码表、限流说明加起来两千多 token但实际用的时候它搜出来的结果还不如直接让我手动复制网址给 Claude 看。这种工具不仅没有提升效率反而在每次会话开始时就白白占用了上下文预算。所以我后来养成了一个习惯每装一个新工具先让 Claude Code 把它的完整描述打印出来看一眼凡是超过 1000 token 且内容里有一半是废话的基本可以判定为垃圾工具。2.2 工具噪音多一个入口就多一个决策分叉我在前面提到了菜谱类比这里想再深入聊一下“工具噪音”这个概念。在信息论里噪音指的是干扰有效信息传输的无用信号。放到 Claude Code 的场景里多余的工具就是噪音——它们不会帮助模型更好地完成任务反而会让模型在“该不该用、该用哪个”这件事上浪费更多的推理时间和 token。最典型的场景就是当任务描述比较模糊的时候工具噪音的影响会被无限放大。比如我给 Claude Code 一句话指令“帮我查一下最近提交里改了哪些文件”。在没有工具噪音的情况下它会直接调用 git 工具一步到位。但如果我同时挂着 5 个和代码相关的工具它就开始“独立思考”了会不会 GitHub 工具更合适要不要先搜索一下代码也许应该用文件系统工具去看看 .git 目录这种发散式的决策路径会极大拉低执行效率。我在大量实践中观察到的一个规律是工具数量超过 15 个以后Claude Code 的“首发成功率”即第一次调用工具就选对并且成功拿到结果的概率会明显下降。从 90% 以上掉到 70% 甚至更低。别小看这 20% 的差距一次失败的调用意味着一次完整的工具执行——加载、返回结果、把结果塞进上下文、然后模型再重新分析——这些全都是白花花的 token 和时间。2.3 工具质量参差第三方 MCP 的隐性风险聊到这儿可能有人会问那我多装的是“优质工具”不就行了问题在于优质工具实在太少了。MCP 生态现在就像早期的安卓应用市场谁都可以开发一个 MCP 服务器发布出来但大部分既没有完善的文档也没有稳定的维护。我踩过的坑包括但不限于某个数据库 MCP 在连接字符串里硬编码了超时时间导致我稍微跑个复杂一点的查询就直接 timeout某个浏览器自动化工具每次启动都会弹出一个调试窗口在远程服务器上根本无法使用还有一次更严重一个文件操作类的 MCP 工具竟然在删除目录的时候没有做递归安全检查差点把那个项目的 node_modules 之外的东西也一并清了。所以我在这个阶段最大的一个认知转变是工具的“可用性”比“功能性”重要得多。一个只提供三个简单函数但稳定运行一年的工具远远好过一个功能看起来极其强大但三天两头报错的工具。具体到选择层面我建议优先选择官方出品的 MCP比如 GitHub 官方、Supabase 官方其次是社区里 star 数量高且更新频繁的第三方工具最后才考虑那些个人开发者随手发布的“小玩具”。每个准备接入的工具都要在非关键项目里先试用一周确认稳定可靠再考虑是否把它纳入日常配置。3. 我把 Tools 从 30 个砍到 8 个后实测效果反而变好了3.1 我的精简清单这 8 个工具留下了唠叨了这么多到了该上干货的时候了。在一次大扫除中我把三十多个工具砍到了八个。这里要先声明八个这个数字不是标准答案不同行业的项目、不同使用习惯的人合理数量会有差异。但我在实际测试中发现对于大多数以“写代码、查代码、跑测试、改配置”为主要工作流的开发者来说八到十个工具基本覆盖了九成需求再往上走边际收益真的趋近于零。下面是我的保留清单供你参考工具类型具体工具保留原因代码搜索ripgrep 相关 MCP速度极快秒级搜索大型代码库描述简洁文件读写Claude Code 内置文件工具官方原生稳定性最高无第三方依赖终端命令Claude Code 内置 Bash 工具几乎所有操作的最后兜底必留Git 操作GitHub 官方 MCP覆盖 issue、PR、releaseAPI 设计清晰数据库查询单一 MySQL MCP只留最常用的其余数据库需求走命令HTTP 请求我本地自封装的轻量请求工具控制描述长度只保留最小必要参数文档解析自写的 markdown 转纯文本脚本内部格式可控不会被第三方解析逻辑坑定时任务系统 cron 配合通知脚本不依赖 MCP直接走命令行减少一层损耗可能有读者会问那浏览器自动化呢网页搜索呢我现在的态度是这些工具已经变成了“按需临时安装”而不是“常驻后台”。需要处理网页上的数据我就在那一轮的会话中临时挂上对应的 MCP用完就卸而像数据库这类高频工具虽然保留了但也做了大量参数精简确保描述足够短。3.2 CLAUDE.md 中的工具使用约束配置——让 AI 知道“什么时候别用工具”人少好办事工具少也好管理。但光砍数量还不够你还需要在配置文件里明确告诉 Claude Code哪些场景优先用哪个工具、哪些场景坚决不要用某个工具。Claude Code 支持通过一个叫CLAUDE.md的项目级配置文件也可以用全局配置来约束 AI 的行为这个文件里的指令优先级非常高几乎可以说是在模型开始工作之前就灌入的“岗位职责说明书”。我的CLAUDE.md里有一段专门针对工具调用的规则贴出来给个参考## 工具使用约束 1. 默认情况下优先使用内置的 Bash 工具和文件工具处理任务除非该任务明确需要外部数据。 2. 查询代码时第一选择是 ripgrep 工具不要先打开浏览器或调用 GitHub API。 3. 数据库查询必须使用配置好的 MySQL 工具禁止通过 HTTP 工具连接数据库端口。 4. 除非用户明确要求否则不要使用浏览器自动化工具。需要查看网页时先询问用户是否需要。 5. 所有工具调用前先评估是否存在更轻量的替代方案如直接用 grep 而不是调用代码搜索 MCP。 6. 如果某个工具连续两次调用失败停止调用并向用户报告错误不要尝试第三次。你可能注意到了这些规则的核心目的不是教 AI 怎么用工具而是教 AI “什么时候别用工具”。这个思路是我踩了无数次坑之后总结出来的AI 默认会倾向于把所有能力都用一遍来证明自己很努力但这种努力往往是无效的。通过在CLAUDE.md里明确设置边界相当于给它的行为上了一圈“护栏”让它在决策路径上少走很多弯路。这里有个很容易忽视的细节CLAUDE.md的指令长度和工具描述一样也会占用上下文窗口。所以你没不要写几千字的“编年史”而是把所有规则压缩成短小、硬性的指令能一句话讲清楚的绝不用两句话。同时如果一个规则已经内化到工具的调用习惯里了AI 能在大部分情况下稳定遵守可以把它删掉不要长期占着上下文。我把这称作“规则动态清理”和代码重构里的“删死代码”是一个逻辑。4. 真正给 AI 减负的三个关键方向4.1 减负第一刀压缩工具描述而不是砍工具数量很多人一听到“工具太多了”就直接开始卸载但我认为这只是表面工程。真正有效的手段是“工具描述瘦身”。不知道你有没有注意过官方内置工具的描述通常非常简洁比如 Bash 工具就一句话“Execute a bash command”——它没有长篇大论地解释什么是 bash、有哪些参数、返回格式是什么但模型依然能用好它。为什么因为 Claude 系列的模型本身对命令行非常熟悉你不需要浪费 token 去教它。但第三方 MCP 工具就不一样了。开发者为了让自己写的工具看起来更专业常常在描述里塞大量背景信息比如“这是一个基于 xxx 框架开发的 xxx 服务用于 xxx 场景下的 xxx 操作支持 xxx 功能……”这些对模型来说大部分都是冗余信息。我的做法是每个 MCP 工具的配置文件通常在.mcp.json或 Claude Code 的配置文件里中找到description字段手动覆盖成十几个词的极简描述。比如一个文件上传工具的原始描述可能有 500 字我会直接改成“上传本地文件到当前项目的 /uploads 目录返回 URL”完事。这里的底层逻辑是模型的工具调用能力并不依赖你对工具的“全面介绍”它依赖的是“工具名称 一句话说明 参数结构”的充分性。只要这三个要素清晰模型就知道该在什么时候用它。压缩描述等于把省下来的上下文空间留给对话历史和工作内容这对长会话体验的改善是立竿见影的。4.2 减负第二刀给工具加“语境围栏”“语境围栏”这个词是我自己造的概念。什么意思呢就是说你要明确规定某个工具只能在什么语境下使用不能脱离场景乱来。最典型的例子就是网页搜索工具。如果你不限制AI 会在写代码遇到任何一个不确定的 API 时都想去搜索一下但很多内部 API 或者历史版本的接口在网上根本搜不到有效信息反而把一个本来可以继续推进的任务卡在“搜索—失败—再搜索”的循环里。我在CLAUDE.md里给网页搜索工具专门加了一条规则“当用户处于离线开发环境或任务涉及内部代码时禁止调用网页搜索。只有用户明确要求查找最新外部文档或技术博客时才允许使用。”加了这条规则之后AI 的“乱搜索”行为基本消失了任务的平均完成时间短了不少。这个思路其实还可以扩展到更多场景比如数据库工具只允许在应用配置了数据库连接的项目里使用浏览器自动化工具只允许在需要模拟用户操作的场景下使用HTTP 工具只允许在用户给定了完整端点时使用。标注清楚每个工具的使用边界本质上是在帮模型做“决策剪枝”有效减少发散路径——对于 AI 来说选择越少正确率越高。4.3 减负第三刀让模型自己决定是否调用工具最后这个方向听起来有点抽象但它是我在实践中体会最深的一点。早期我对 Claude Code 的使用方式很“霸道”只要任务稍微复杂一点我就手动列出计划让它必须调用某个工具去完成某个步骤。结果 AI 变得像个提线木偶我自己反而成了真正的大脑它并没有发挥出应有的价值。后来我改变了策略我只描述目标不规定实现路径。举个例子我让它“把项目里所有 TODO 注释汇总成一份报告”我不告诉它要用 grep 还是用文件扫描我只说目标剩下的交给它自己判断。在精简后的工具环境里它通常会首选 ripgrep因为描述里写明了这是一个快速搜索工具如果找不到它才会退而求其次用 Bash 的find或grep组合。这种“让模型自主决策”的模式比我之前事无巨细地安排每一步的效率高了很多而且任务完成质量也更好。这里要补充一个技术细节Claude Code 这种工具型 AI 的“自主决策”能力本质上依赖于上下文中的工具描述质量和历史交互反馈。工具少而精的时候模型就像在一张相对干净的桌子上工作它能分清哪些是自己的工具、哪些是干扰项工具多而杂的时候它就像在堆满杂物的房间里找一把螺丝刀虽然最后也能找到但中间浪费的时间绝对不少。5. 常见问题与排查实录5.1 MCP 连接失败不是每次重启都能解决这个坑几乎每个玩 MCP 的人都遇到过。现象是你明明在配置文件里加好了 MCP 服务器的地址但启动 Claude Code 后却发现工具列表里没有它。我最初的做法是反复重启 Claude Code偶尔能好但下一次还是会断。后来我耐心排查了一遍发现大多数 MCP 连接失败的原因就三个一是本地服务根本没启动尤其是一些需要npx或node临时启动的第三方工具二是配置文件里的路径写错了Windows 和 Linux 的路径写法差异特别容易踩三是 MCP 服务器本身崩溃后没有自动重启机制。排查建议是先手动在终端里跑一下 MCP 服务器的启动命令确认能起来再去检查配置文件里的参数如果确认无误但 Claude Code 仍然找不到工具去看日志。Claude Code 的日志里会明确记录每一个 MCP 服务器的启动状态和报错原因比在配置里瞎猜高效得多。像这类“本地服务没有自动重启”的问题有一个非常实用的兜底方案把 MCP 启动命令包装成 systemd 服务或开机脚本确保它一直在后台运行这样就不会因为一次崩溃导致整个工具消失。5.2 上下文长度报错以 10485 为例的排查思路你可能会在社区里看到有人贴出这样的报错api error: 400 this models maximum context length is 10485。这个数字看起来很奇怪明显不是 Claude 系列模型的标称上下文长度。我第一次看到的时候也很懵我明明用的是 20 万上下文的模型为什么报一个 10485 的限制后来查了很多资料才明白这个报错通常不是模型本身限制而是某个第三方 MCP 工具内部对输入输出做了参数限制或者在调用某个外部服务时那个服务的 API 有自己的最大上下文限制。10485 这个数字一般不是模型报出来的它大概率来自某个被调用的 API 网关或代理配置。排查思路分三步第一步确认报错发生在调用哪个工具的时刻第二步查看该 MCP 服务器的文档找到它的max_context_length之类的配置项第三步如果这个工具是自封装的直接在自己代码里调大限制即可。如果是第三方工具可以考虑换一个不受限的工具或联系维护者。这类问题之所以让很多人一头雾水是因为大家都把注意力放在 Claude Code 的模型选择上忽略了中间那一层工具代理的“二次限制”。5.3 如何判断某个工具是否该卸载最后分享一个“工具自检清单”每当你纠结某个 MCP 工具要不要留的时候就拿这四把尺子量一下这个工具在过去两周内被我主动调用过吗如果没有删。如果这个工具突然消失我的工作流会受影响吗如果不会删。这个工具的描述长度超过了 800 token 吗如果超过先尝试压缩描述压缩后依然不清晰删。这个工具和另一个已保留工具的功能有重叠吗如果有重叠只保留更稳定、描述更短的那一个。这套自检逻辑最核心的一点是工具的价值不在于“它多强大”而在于“它多久被用一次”。一个一年也用不上几次的“万能工具”即使再智能也只是占着上下文、制造噪音的包袱。我从三十几个工具砍到八个中间没有任何一个任务因为工具减少而卡住反而因为调用链路短整体效率提升了一个档次。再补充一个彩蛋如果你关心enable_prompt_caching_1h1这种配置有没有用——我的实测结论是它对降低长会话的成本有正向效果但它在工具选择引起的“无效往返”问题上帮不上忙。也就是说缓存优化不能替代工具精简两个方向最好一起做。先瘦身再缓存效果才会真正叠加。写在最后的一个实战体会回到标题那句话“给 AI 减负”确实是个伪命题不是我打击大家而是因为你越是把它当成一个需要费力“照顾”的对象越容易陷入两难——装一堆工具怕它累着不装又怕它能力不够。我在实际操作中的体会是Claude Code 需要的不是一个“更轻松的 AI”而是一个“更干净的运行环境”。与其想着怎么减轻它的负担不如先把周围那些主动增加的干扰清干净——删掉不用的工具、压缩工具描述、用CLAUDE.md立好边界。做完这四件事你会发现它不仅不累反而能干得比你预期的还要多。如果你现在还处于“工具多但不顺手”的阶段建议下周找个下午按我上面那张自检清单做一次彻底的“断舍离”然后带着精简后的配置跑两周再看结果——我敢说你大概率不会再想挂回那三十多个工具了。