Claude Code团队重建工具3次后总结的4条设计原则

减少工具后，AI反而表现更好了。构建Agent时，最自然的本能是”功能不够就再加个工具”。Anthropic团队在开发Claude Code的一年里发现了相反的规律：每多一个工具，AI就多一分”该不该调用”的犹豫成本，而这种成本会不断累积。

我在自己构建Agent时也掉进了同样的陷阱，所以Claude Code团队开发者Thariq分享的这段经历让我深有感触。以下是他们增删和重新设计工具的完整过程。

一个工具塞两个职责，AI就会卡住

这是Claude Code团队遇到的第一个问题。他们需要向用户提问的功能，就把提问功能塞进了”制定计划”工具里。实现速度很快，但AI在制定计划的同时又要生成问题，当用户的回答与计划冲突时，AI无法自行判断。

第二次尝试是让AI用Markdown格式输出问题，结果AI随意更改格式或添加多余的文字。第三次，他们终于把提问功能拆分成专用工具AskUserQuestion，这才开始稳定运行。一个工具一个职责——原则很简单，但只有亲身经历过才能真正体会。

• 计划+提问合体 — AI错误地两次调用同一工具
• Markdown格式输出 — AI擅自添加句子或忽略格式
• 专用工具分离 — 结构化响应终于稳定输出
• 设计再好，如果AI不愿意调用，就没有意义

好用的工具某天会变成枷锁

把工具分离好并不是终点。我把这叫做”工具过期（tool decay）“——曾经不可或缺的工具在模型升级后反而拖后腿的现象。

早期的Claude Code有一个待办事项工具，系统每5轮就发送提醒：“别忘了你的任务清单。“模型变强之后，这些提醒反而产生了反效果。AI在应该调整清单的时候仍然固执地坚持原计划。当Opus 4.5实现子Agent协作后，现有的Todo结构根本无法在Agent之间共享任务。

最终他们用Task Tool进行了全面替换。

• TodoWrite替换为Task Tool — 实现了Agent间的依赖关系共享
• “这个工具还有效吗？“需要定期审视，与添加新工具同样重要
• 支持的模型数量越少，这种判断速度越快
• 工具的形态比数量更重要 — 要匹配模型的能力

把上下文喂给AI，反而会让它变差

在增删工具的过程中，Claude Code团队发现了一个更根本的规律：让AI自己去找信息，比直接注入信息效果更好。

一开始他们用RAG向量数据库预加载上下文。速度快、功能强，但在不同环境下索引会出问题，AI也变得被动——只依赖被提供的信息。换成给AI一个Grep工具让它直接搜索代码库后，上下文质量提升了。再加上Skills文件，构建了AI能递归探索文件中引用的其他文件的结构。

这就是渐进式上下文发现（progressive disclosure）——不是一次性灌入所有信息，而是让AI按需自主发现。

• RAG — 环境依赖性高，AI被动消费上下文
• Grep + Skills — AI主动探索多层文件
• 一年内从”找不到上下文的AI”变成”自己找上下文的AI”
• 无需添加工具，仅通过Skills文件就能扩展功能

不增加工具也能扩展AI的能力

渐进式上下文发现模式还有一个经典案例。用户问Claude Code的使用方法时，它答不上来。可以把所有使用说明塞进系统提示词，但这类问题并不常见。不常用的信息长期占据上下文窗口，会降低代码编写这一核心任务的性能。这就是上下文噪音（context rot）。

解决方案是专用子Agent。只有当使用方法的问题出现时，引导Agent才会搜索文档并只返回答案。工具数量不变，但AI能做的事情变多了。

• 系统提示词塞入所有信息 — 上下文噪音导致代码质量下降
• 只提供文档链接 — AI把太多结果加载到上下文中
• 专用子Agent + 搜索指令 — 只返回所需答案，干净利落
• 通过改变结构而非增加工具来解决问题

没有标准答案

增加、删除、重新设计工具——这个过程没有标准公式。模型变了，工具就得跟着变；昨天正确的架构，明天可能成为瓶颈。

Anthropic团队一年来反复做的一件事是：阅读AI的输出，实验，再修正。归根结底，能做出优秀Agent的人，是能够站在AI角度思考的人。