1. 从“工具越多越强”到“工具越多越乱”的认知反转1.1 一个让我彻底改变看法的下午事情的起因很简单。我在 Claude Code 里陆续挂上了几十个 MCP 工具浏览器自动化、数据库查询、文件系统操作、Git 操作、API 调试、日志分析能想到的基本都配上了。当时的想法很朴素工具越多AI 能做的事情就越多能力边界就越宽。这个逻辑听起来无懈可击直到我让它做一个简单的任务——“帮我查一下项目里那个用户认证模块的接口定义然后生成一份调用示例”。结果它花了整整四轮对话才找到正确的文件。第一轮它去调了数据库查询工具第二轮试了浏览器自动化第三轮才想起来用文件系统搜索。每一轮我都在旁边看着它“思考”那种感觉就像你让一个助手去冰箱拿瓶水他先跑去车库翻了一遍工具箱又去书房查了说明书最后才想起来冰箱在哪。那一刻我意识到一个问题我给 AI 挂了几十个工具本意是让它更强实际上却让它更“犹豫”了。每次面对一个任务它需要在几十个工具里做选择这个选择过程本身就消耗了大量的推理能力和上下文空间。工具越多决策成本越高出错概率越大。1.2 为什么“给 AI 减负”这个说法本身就有问题网上有很多讨论在说“要给 AI 减负”意思是减少上下文、减少工具数量、减少提示词复杂度。这个方向听起来对但我觉得它把问题简单化了。减负不是目的精准匹配才是。一个木匠的工具箱里有几十把工具他不会因为工具多就觉得累因为他清楚每把工具用在什么场景。问题不在于工具的数量而在于工具的组织方式和调用逻辑。Claude Code 的工具体系本质上是一个“能力池”。MCP 协议让它可以连接外部服务Skill 让它具备特定领域的操作能力CLI 让它能执行系统命令Subagent 让它能拆分任务并行处理。这些机制各自解决不同层面的问题但如果只是简单堆叠就会形成一个“什么都有一点什么都不精”的局面。我后来想明白了一件事AI 的“负担”不是来自工具数量而是来自工具之间的边界模糊和调用路径不清晰。当两个工具的功能有重叠当三个工具都能完成同一个操作当工具的描述信息不够精确AI 就不得不在每次调用时做额外的判断。这个判断过程才是真正的负担。1.3 这篇文章适合谁看如果你正在用 Claude Code或者任何支持 MCP 协议的 AI 编程工具并且已经配置了超过十个工具那这篇文章就是写给你的。如果你刚开始接触 Claude Code还在纠结怎么安装、怎么配置第一个 MCP那也可以看因为我会从工具选型的底层逻辑讲起帮你少走弯路。我不会给你一个“最佳工具清单”因为那东西因人而异。我会做的是拆解工具堆叠背后的真实问题给出我实测有效的组织方案分享我在这个过程中踩过的坑和总结出的经验。这些内容你在官方文档里找不到因为它们是实际使用中才能体会到的细节。2. 工具堆叠的隐性成本为什么几十个工具反而让 AI 变笨了2.1 上下文窗口的争夺战Claude Code 的上下文窗口是有限的。每一个挂载的工具它的名称、描述、参数定义、使用示例都会占用上下文空间。我实测过一个数据一个配置完整的 MCP 工具从工具名到参数说明平均占用 200 到 500 个 token。如果你挂了 30 个工具光是工具描述就吃掉了 6000 到 15000 个 token。这个数字意味着什么意味着你还没开始干活上下文窗口已经被工具说明占掉了相当一部分。剩下的空间要装你的项目代码、对话历史、任务描述、中间结果。当上下文快满的时候AI 的表现会明显下降——它开始遗忘之前的对话内容开始重复已经做过的操作开始忽略你明确给出的约束条件。我做过一个对比测试。同一个任务在挂载 8 个工具和挂载 35 个工具的情况下分别执行。8 个工具时任务一次完成输出质量稳定。35 个工具时AI 在第三轮对话后开始出现“幻觉”它声称自己调用了某个工具但实际上没有或者把两个工具的功能搞混了。这不是 AI 变笨了是它的“工作记忆”被工具描述挤占了。注意上下文窗口的占用不是线性的。当工具数量超过某个阈值后AI 的决策质量会急剧下降。这个阈值因模型版本和任务复杂度而异但根据我的经验对于大多数编程任务15 到 20 个工具是一个比较安全的范围。2.2 工具选择困难症AI 也会“选择瘫痪”人类在面对太多选项时会陷入选择困难AI 也一样。当 AI 需要完成一个操作时它会在所有可用工具中搜索匹配项。如果只有一个工具能完成这个操作选择是确定的。如果有三个工具都能完成AI 就需要额外的推理来判断哪个更合适。这个推理过程消耗的是推理能力和时间。更糟糕的是当工具之间的功能边界不清晰时AI 可能会选错。我遇到过好几次这样的情况我配置了一个通用的 HTTP 请求工具和一个专门的 API 调试工具结果 AI 在需要调用内部 API 时选了通用工具导致认证信息没有正确传递请求失败。它不是不知道有专门的工具而是在那一刻两个工具的描述都“看起来可以”它选了一个看起来更简单的。这种错误在单次任务中可能只是多花几秒钟但在复杂的多步骤任务中一次选错可能导致整个流程需要重来。而且这种错误很难排查因为从 AI 的视角看它的选择是“合理”的只是结果不对。2.3 工具之间的“隐形冲突”比选择困难更隐蔽的问题是工具之间的冲突。有些工具会修改相同的资源有些工具会占用相同的端口有些工具会在同一个目录下生成临时文件。当这些工具被同时挂载时它们之间的冲突不会立刻显现而是在特定条件下才爆发。我遇到过一个典型案例我同时挂载了一个文件监听工具和一个代码格式化工具。单独使用都没问题但同时运行时格式化工具修改文件会触发监听工具监听工具触发后又会导致格式化工具再次运行形成了一个无限循环。AI 完全不知道发生了什么它只看到工具调用返回了异常然后尝试用其他工具来“修复”这个问题结果越修越乱。这类问题的根源在于MCP 协议定义了工具如何被调用但没有定义工具之间如何协调。当多个工具操作同一个资源时协调责任落在了使用者身上。如果你只是把工具挂上去不做任何隔离和协调冲突是迟早的事。2.4 启动时间和资源消耗的累积效应每一个 MCP 工具在启动时都需要建立连接、加载配置、初始化状态。挂载 30 个工具意味着每次启动 Claude Code 时这 30 个工具都要完成初始化。我实测过挂载 30 个工具时Claude Code 的启动时间从 3 秒增加到了 12 秒。这还只是启动时间运行时的资源消耗更明显。有些工具是常驻进程会持续占用内存和 CPU。有些工具会在后台保持网络连接。当这些工具数量多了之后你的开发机可能会变得卡顿风扇狂转。更严重的是某些工具在初始化失败时会阻塞整个启动流程导致 Claude Code 无法正常使用。我现在的做法是按需加载而不是全量挂载。对于当前项目不需要的工具直接不配置。对于偶尔用到的工具用的时候再临时启用。这个习惯让我的 Claude Code 启动时间回到了 4 秒以内运行时的卡顿也明显减少。3. 重新理解 MCP、Skill、CLI 和 Subagent 的分工3.1 MCP 的本质标准化接口不是能力本身MCP 的全称是 Model Context Protocol它是一个协议定义了 AI 如何与外部服务通信。很多人把 MCP 理解为“给 AI 加能力”这个理解不够准确。MCP 做的是标准化接口它让 AI 可以用统一的方式调用不同的服务但服务本身的能力是服务提供的不是 MCP 提供的。这个区别很重要。当你挂载一个数据库 MCP 时AI 获得的是“通过标准接口查询数据库”的能力而不是“理解数据库结构”的能力。它知道怎么发查询但不知道你的表结构设计是否合理不知道哪个字段应该加索引不知道查询语句的性能瓶颈在哪里。这些需要你在提示词里告诉它或者通过 Skill 来补充。我见过很多人配置了一堆 MCP然后抱怨 AI “不好用”。问题往往出在他们期望 MCP 解决所有问题但 MCP 只解决了“怎么调用”的问题没有解决“调用什么”和“为什么调用”的问题。3.2 Skill 的价值领域知识的封装Skill 和 MCP 是互补的。MCP 提供接口Skill 提供知识。一个 Skill 本质上是一组指令、示例和约束的集合它告诉 AI 在特定场景下应该怎么做。举个例子。你有一个 MCP 可以操作 Git但 AI 不知道你们的团队规范是“feature 分支从 develop 切出命名格式是 feature/工单号-描述提交信息必须包含工单号”。这些规范可以写在一个 Skill 里当 AI 需要执行 Git 操作时它会先加载这个 Skill然后按照规范执行。Skill 的另一个价值是减少提示词的重复。如果你每次都要在对话里写一遍团队规范那既浪费时间又容易遗漏。把规范封装成 Skill一次编写多次使用。而且 Skill 可以被版本控制可以被团队共享这比散落在各个对话里的提示词要可靠得多。提示Skill 的粒度很重要。太粗的 Skill 会包含太多不相关的信息增加上下文负担。太细的 Skill 会导致数量膨胀增加选择成本。我的经验是一个 Skill 对应一个明确的工作流比如“创建功能分支”、“提交代码”、“发布版本”每个 Skill 的指令控制在 500 字以内。3.3 CLI 的定位系统级操作的入口CLI 是 Claude Code 执行系统命令的通道。通过 CLIAI 可以运行构建脚本、执行测试、管理进程、操作文件系统。CLI 的能力边界取决于你的系统权限理论上你可以让 AI 执行任何命令。但 CLI 也是最危险的工具。一个错误的命令可能删除重要文件可能修改系统配置可能触发不可逆的操作。我强烈建议对 CLI 的使用加上约束。Claude Code 本身提供了一些安全机制比如命令确认、白名单、沙箱执行但这些机制需要你主动配置。我的做法是把 CLI 操作封装成脚本让 AI 调用脚本而不是直接执行命令。脚本里可以加参数校验、日志记录、错误处理。这样即使 AI 选错了脚本影响也是可控的。而且脚本可以被测试可以被审查比让 AI 直接拼命令要安全得多。3.4 Subagent 的正确用法任务拆分不是并行堆砌Subagent 是 Claude Code 比较新的能力它允许 AI 把一个大任务拆分成多个子任务每个子任务由一个独立的 agent 处理。这个机制的本意是好的但很多人用错了。我见过有人把 Subagent 当成“多线程”来用把十个任务同时扔给十个 Subagent然后期望它们并行完成。结果往往是Subagent 之间互相干扰共享资源冲突最终结果需要大量人工整合。这不是 Subagent 的问题是使用方式的问题。Subagent 的正确用法是任务隔离。当一个任务可以被清晰地拆分成几个独立的子任务且子任务之间不需要频繁通信时用 Subagent 是合适的。比如一个 Subagent 负责分析代码结构一个 Subagent 负责生成测试用例一个 Subagent 负责检查文档一致性。它们各自独立工作最后汇总结果。但如果子任务之间有依赖关系或者需要共享中间状态那 Subagent 反而会增加复杂度。这种情况下用一个 agent 顺序执行可能更高效。4. 我的工具组织方案从“全量挂载”到“分层管理”4.1 第一层核心工具始终可用我把工具分成三层。第一层是核心工具这些工具在任何项目中都会用到始终挂载。我的核心工具清单包括文件系统操作、Git 操作、终端命令执行、代码搜索。这四个工具覆盖了日常开发 80% 的操作需求。文件系统操作让我可以读写文件、创建目录、列出文件。Git 操作让我可以查看状态、提交变更、切换分支。终端命令执行让我可以运行构建、测试、安装依赖。代码搜索让我可以快速定位函数定义、变量引用、文件内容。这四个工具我用了半年多几乎没有遇到过需要额外工具才能完成的基础操作。它们的描述信息我做了精简每个工具的描述控制在 100 字以内参数说明只保留最常用的选项。这样四个工具加起来占用的上下文不到 800 个 token。4.2 第二层项目工具按需启用第二层是项目相关的工具。这些工具只在特定项目中使用我通过项目级的配置文件来管理。比如在一个前端项目中我会启用浏览器自动化工具和组件库查询工具。在一个后端项目中我会启用数据库查询工具和 API 调试工具。项目工具的启用逻辑是打开项目时自动加载切换项目时自动卸载。Claude Code 支持项目级配置我把每个项目的工具配置写在项目根目录的配置文件里。这样当我切换到不同项目时工具集会自动调整不需要手动干预。这个方案的关键是配置文件的管理。我建议把配置文件纳入版本控制这样团队成员可以共享同一套工具配置。新成员加入时不需要问“应该装哪些工具”直接拉取代码配置就生效了。4.3 第三层临时工具用完即走第三层是临时工具。这些工具我可能一个月才用一次比如某个特定 API 的调试工具、某个冷门格式的转换工具、某个一次性任务的辅助工具。这些工具我不常驻挂载而是用的时候临时启用用完就关掉。临时工具的启用方式很简单在对话中直接说明需要什么工具Claude Code 会提示你配置。或者你可以预先准备好配置片段需要时复制粘贴到配置文件中重启 Claude Code 即可。这个方案的好处是你的常驻工具集始终保持精简上下文窗口不会被不常用的工具占用。缺点是临时启用需要重启会打断工作流。但对于低频工具来说这个代价是可以接受的。4.4 工具描述的优化技巧工具描述的质量直接影响 AI 的选择准确率。我总结了几条优化技巧第一描述要具体不要抽象。“查询数据库”不如“执行 SQL 查询并返回结果集”具体。“操作文件”不如“读取、写入、追加、删除文件”具体。具体的描述让 AI 更容易判断这个工具是否适合当前任务。第二参数说明要包含示例。对于复杂的参数给出一个示例值比纯文字描述更有效。比如日期格式参数直接写“2024-01-15”比写“ISO 8601 日期格式”更直观。第三明确工具的边界。如果一个工具只能读不能写在描述里写清楚。如果一个工具有速率限制在描述里注明。这些信息帮助 AI 在调用前做出正确判断减少运行时错误。第四避免功能重叠。如果两个工具的功能有重叠考虑合并或明确分工。比如如果你有一个通用 HTTP 工具和一个 API 专用工具在描述里写清楚“通用 HTTP 工具用于外部请求API 专用工具用于内部服务调用”这样 AI 就不会选错。5. 实操从零搭建一套精简高效的工具体系5.1 环境准备与基础配置假设你刚开始使用 Claude Code或者想重新整理现有的工具配置。第一步是清理现有的工具配置把所有非核心工具先移除。然后按照下面的步骤逐步搭建。首先确认 Claude Code 的版本。不同版本对 MCP 和 Skill 的支持程度不同。在终端运行claude --version查看版本号。建议使用最新稳定版因为新版本通常会优化工具加载机制和上下文管理。然后找到配置文件的位置。Claude Code 的配置文件通常在用户目录下的.claude文件夹中项目级配置在项目根目录的.claude文件夹中。如果你不确定位置可以在 Claude Code 中运行/config命令查看当前配置路径。5.2 核心工具的配置示例以下是我使用的核心工具配置片段。这是一个 JSON 格式的配置文件放在项目根目录的.claude/mcp.json中。{ mcpServers: { filesystem: { command: npx, args: [-y, modelcontextprotocol/server-filesystem, ./], description: 文件系统操作读取、写入、列出目录 }, git: { command: npx, args: [-y, modelcontextprotocol/server-git, ./], description: Git 操作状态、提交、分支、日志 }, shell: { command: npx, args: [-y, modelcontextprotocol/server-shell], description: 终端命令执行运行脚本、构建、测试 }, search: { command: npx, args: [-y, modelcontextprotocol/server-search, ./], description: 代码搜索定位函数、变量、文件内容 } } }这个配置只挂了四个工具每个工具的描述都做了精简。实测下来这四个工具覆盖了日常开发的大部分操作。启动时间在 4 秒左右上下文占用不到 1000 个 token。5.3 Skill 的编写与加载Skill 的编写比 MCP 配置简单它本质上是一个 Markdown 文件放在.claude/skills目录下。每个 Skill 文件以# Skill 名称开头下面是具体的指令和示例。以下是我为“创建功能分支”编写的 Skill 示例# 创建功能分支 ## 触发条件 当用户要求创建新的功能分支时使用此 Skill。 ## 执行步骤 1. 确认当前在 develop 分支如果不是先切换 2. 拉取最新代码git pull origin develop 3. 创建分支git checkout -b feature/{工单号}-{简短描述} 4. 推送分支git push -u origin feature/{工单号}-{简短描述} ## 命名规范 - 工单号格式PROJ-数字如 PROJ-123 - 简短描述小写字母和连字符不超过 30 字符 - 示例feature/PROJ-123-user-auth ## 注意事项 - 如果工单号缺失先询问用户 - 如果分支已存在提示用户并询问是否切换这个 Skill 加载后当 AI 需要创建分支时它会按照规范执行不需要我在对话里重复说明。Skill 的加载是按需的只有触发条件满足时才会加载所以不会占用常驻上下文。5.4 Subagent 的任务拆分实践Subagent 的使用需要更谨慎的规划。我的经验是只在以下条件同时满足时才使用 Subagent任务可以清晰拆分成三个以上的独立子任务子任务之间不需要共享中间状态每个子任务的工作量足够大值得单独启动一个 agent。以下是一个实际案例。我需要为一个新模块生成完整的代码、测试和文档。这个任务可以拆分成代码生成、测试用例生成、文档生成。三个子任务相互独立可以并行。在 Claude Code 中我这样描述任务请使用 Subagent 完成以下任务 1. Subagent A根据接口定义生成模块代码输出到 src/modules/new-module/ 2. Subagent B根据接口定义生成测试用例输出到 tests/modules/new-module/ 3. Subagent C根据接口定义生成 API 文档输出到 docs/modules/new-module.md 三个 Subagent 独立工作完成后汇总结果。实测下来这种方式比单个 agent 顺序执行快了大约 40%而且每个子任务的输出质量更稳定因为每个 Subagent 的上下文更专注。5.5 工具切换与项目隔离当你同时维护多个项目时工具切换是一个需要解决的问题。我的方案是使用项目级配置每个项目有自己的.claude/mcp.json和.claude/skills/目录。Claude Code 在启动时会读取当前项目目录下的配置自动加载对应的工具和 Skill。这个方案的关键是配置文件的组织。我建议在项目根目录下创建.claude文件夹把配置文件和 Skill 文件都放在里面。然后在.gitignore中排除个人配置只提交团队共享的配置。这样每个人可以有自己额外的工具但团队规范通过共享配置来保证。如果你需要在不同项目之间快速切换可以写一个简单的脚本自动切换 Claude Code 的工作目录和配置。这个脚本不需要很复杂几行 shell 命令就够了。6. 常见问题与排查技巧实录6.1 工具加载失败怎么办工具加载失败是最常见的问题。表现是 Claude Code 启动时提示某个工具初始化失败或者工具列表里缺少某个工具。排查思路如下首先检查命令是否正确。MCP 工具通常通过npx或uvx启动确认这些命令在你的系统上可用。在终端手动运行配置中的命令看是否能正常启动。如果手动运行失败错误信息会告诉你具体原因。其次检查依赖是否安装。有些 MCP 工具需要额外的依赖比如 Python 环境、Node.js 版本、系统库。查看工具的文档确认依赖是否满足。然后检查权限。有些工具需要访问特定目录或端口确认你的用户有相应权限。在 macOS 和 Linux 上权限问题比较常见。在 Windows 上路径格式和权限模型不同需要特别注意。最后检查端口冲突。如果工具需要监听端口确认端口没有被其他程序占用。用lsof -i :端口号查看端口占用情况。6.2 AI 选错工具怎么排查AI 选错工具的表现是它调用了某个工具但结果不符合预期或者它应该调用工具 A 却调用了工具 B。排查思路如下第一检查工具描述是否有重叠。如果两个工具的描述都包含“查询”这个词AI 可能会混淆。修改描述让每个工具的用途更明确。第二检查工具名称是否相似。如果两个工具的名称只差一个词AI 可能会选错。重命名工具让名称更有区分度。第三在提示词中明确指定工具。如果你知道某个任务应该用哪个工具直接在提示词里写“使用 XX 工具完成这个操作”。这比让 AI 自己选更可靠。第四减少工具数量。如果排查后发现是工具太多导致的选择困难考虑暂时移除不常用的工具看问题是否消失。6.3 上下文窗口不够用的优化策略上下文窗口不够用的表现是AI 开始遗忘之前的对话重复已经做过的操作或者忽略你给出的约束。优化策略如下首先精简工具描述。把每个工具的描述控制在 100 字以内参数说明只保留最常用的选项。这可以释放大量上下文空间。其次使用 Skill 替代长提示词。如果你在对话中反复写同样的指令把它封装成 Skill。Skill 只在触发时加载不占用常驻上下文。然后定期清理对话历史。Claude Code 支持清理对话历史把不需要的中间结果删掉。这可以释放上下文空间让 AI 更专注于当前任务。最后拆分任务。如果一个任务需要的上下文超过了窗口限制把它拆分成多个子任务每个子任务单独执行。Subagent 就是为这个场景设计的。6.4 工具冲突的识别与解决工具冲突的表现是单独使用每个工具都正常但同时使用时出现异常。识别和解决思路如下首先确认冲突的资源。常见的冲突资源包括文件、端口、环境变量、临时目录。查看工具的文档确认它们操作哪些资源。其次隔离冲突资源。如果两个工具操作同一个文件让它们操作不同的文件。如果两个工具占用同一个端口修改其中一个的端口配置。然后调整调用顺序。如果工具 A 的输出是工具 B 的输入确保调用顺序正确。在提示词中明确说明顺序要求。最后如果冲突无法解决考虑只保留其中一个工具。功能重叠的工具保留更稳定的那个移除另一个。6.5 常见问题速查表问题现象可能原因排查方法解决方案工具加载失败命令错误、依赖缺失、权限不足手动运行命令查看错误修正命令、安装依赖、调整权限AI 选错工具描述重叠、名称相似、工具过多检查工具描述和名称优化描述、重命名、减少工具上下文不够用工具描述占用过多、对话历史过长查看 token 使用情况精简描述、使用 Skill、清理历史工具冲突资源竞争、调用顺序错误单独测试每个工具隔离资源、调整顺序、移除重叠工具启动时间过长工具数量过多、初始化阻塞计时启动过程按需加载、异步初始化、移除不常用工具输出质量下降上下文污染、工具干扰对比不同工具集的表现精简工具集、隔离任务、使用 Subagent提示这张表是我在实际使用中总结的覆盖了 90% 以上的常见问题。遇到新问题时先对照这张表排查大部分情况都能找到方向。6.6 几个容易被忽略的细节第一个细节是工具的超时设置。有些工具在执行长时间操作时会超时导致 AI 认为操作失败。检查工具的配置适当调整超时时间。但也不要设得太长否则 AI 会一直等待浪费上下文。第二个细节是工具的日志输出。有些工具会输出大量日志这些日志会占用上下文空间。如果工具支持日志级别配置把日志级别调到 warning 或 error减少不必要的输出。第三个细节是工具的版本兼容性。MCP 协议在演进不同版本的工具可能不兼容。定期更新工具到最新版本但更新前先在测试环境验证避免影响正常工作。第四个细节是工具的认证信息。有些工具需要 API key 或 token这些信息通常放在环境变量或配置文件中。确保认证信息正确配置且不要提交到版本控制。使用.env文件或系统密钥管理工具来存储敏感信息。7. 我现在的工具集与日常使用习惯7.1 当前的工具清单经过几轮调整我现在的常驻工具集稳定在 8 个左右。核心四个是文件系统、Git、终端、代码搜索。项目相关的四个根据当前项目动态调整通常是数据库查询、API 调试、浏览器自动化、日志分析。Skill 方面我维护了大约 15 个 Skill覆盖代码规范、提交规范、分支管理、测试编写、文档生成、部署流程等场景。这些 Skill 按项目加载不同项目共享通用的 Skill项目特有的 Skill 放在项目目录下。Subagent 我用得比较克制只在明确需要并行处理且子任务独立时才使用。大多数情况下单个 agent 顺序执行更简单、更可控。7.2 日常使用中的几个习惯第一个习惯是定期审查工具集。每个月我会花十分钟检查当前挂载的工具移除一个月内没用过的合并功能重叠的更新有问题的。这个习惯让我的工具集始终保持精简。第二个习惯是记录工具使用情况。我在一个简单的文本文件里记录每次使用工具的情况包括任务类型、使用的工具、结果质量。积累一段时间后我能看出哪些工具真正有用哪些只是“看起来有用”。第三个习惯是先写 Skill 再写提示词。当我发现自己在对话中重复写同样的指令时我会停下来把它封装成 Skill。这个习惯减少了重复劳动也让我的指令更规范。第四个习惯是用 Subagent 前先问三个问题任务能拆分成独立子任务吗子任务之间需要通信吗每个子任务的工作量够大吗三个问题都是“是”才用 Subagent否则用单 agent。7.3 一个让我印象深刻的教训最后分享一个教训。我曾经为了“提高效率”一次性挂载了 40 多个工具包括各种冷门的、实验性的、别人推荐但我没用过的。结果那段时间我的 Claude Code 几乎不可用——启动慢、响应慢、经常选错工具、上下文频繁溢出。我花了整整一个周末排查问题最后发现根源就是工具太多。移除到 10 个以内后一切恢复正常。这个教训让我明白工具的价值不在于数量而在于精准匹配。一个恰到好处的工具集比一个庞大的工具库更有用。现在我的原则是新工具先试用确认有用再常驻。试用期至少一周期间观察它是否真的解决了问题是否引入了新的问题。只有通过试用期的工具才会进入常驻清单。这个原则让我的工具集始终保持在一个可控的范围内也让我对每个工具的能力边界有清晰的认识。