在智能体（AI Agent）的开发浪潮中，人们总把目光聚焦在模型本身的智商上，却往往忽略了一个决定成败的关键——工具。构建一个高效的智能体框架，最难啃的骨头往往不是提示词工程，而是工具的设计。
换句话说，你究竟给了你的 AI 一双什么样的“手”和“脚”去改变世界？
面对 bash、skills、代码执行这些五花八门的原始能力，到底该如何组合？是给智能体一套全能工具，还是为每个场景量身打造一件专用工具？当工具数量从 1 个增长到 50 个时，复杂度又会怎样变化？
Anthropic团队在开发Claude Code时，也遇到了同样的难题。他们从一次次尝试中总结出一套思路，不是死板的规则，而是一种独特的视角转换——学会像智能体一样看世界（Seeing like an Agent）。
从“给什么用什么”到“用什么给什么”
如果要解决一道复杂的数学题，你会想要什么工具？
纸笔是基础，但受限于手动计算的效率
计算器能提高效率，但需要掌握高级功能的使用方法
电脑是最强大的工具，但需要具备编程能力
工具的价值不取决于其功能的强大，而取决于使用者是否有能力驾驭它，也就是说工具必须与模型的能力相匹配。如果工具超出了模型的理解范围，再强大的功能也是累赘；如果工具过于简陋，则限制了模型的发挥。
在构建 Claude Code 的过程中，Anthropic团队通过具体的演进故事，诠释了这一核心理念。
一. 学会提问
Claude Code的开发者们很早就意识到，智能体需要能够主动向用户提问。比如，当它不确定该用什么方案时，如果能问一句“你更倾向A还是B？”，就能避免后面走错方向。
但问题来了，怎么让提问这件事变得高效？
尝试一：修改 ExitPlanTool
一开始，他们尝试在某个已有的工具（ExitPlanTool）里加一个提问功能。这个工具本来是用来提交执行计划的，现在让它同时带上几个问题。结果智能体犯晕了，它搞不清自己到底是在提交计划还是在问问题，用户回答后该怎么衔接也不明确。这条路显然走不通。
这个方案暴露了一个关键问题：在一个工具中塞入太多职责，会让模型难以理解调用时机和逻辑。
尝试二：修改输出格式
第二次尝试，他们试着直接改输出格式。让智能体在回复时，按某种固定格式写出问题，然后由界面解析出来呈现给用户。这个想法很灵活，但智能体并不总是听话，有时会多写几句无关的话，有时会漏掉某个选项，有时干脆换了格式。
依赖模型自发遵守一种特定格式，本质上是一种赌博。结果不稳定，也不行。
尝试三：AskUserQuestion 工具
最后，他们专门做了一个叫“AskUserQuestion”的工具。这个工具干一件事：提问。智能体可以在任何时刻调用它，尤其是在计划模式下，会专门提示它使用这个工具。工具触发时，系统会弹出一个专门的窗口，列出问题并暂停运行，等用户回答完才继续。
这个设计好在哪？它给了智能体一个清晰的结构，问题要列清楚，选项要给明白。更重要的是，智能体“喜欢”调用它。当一个工具符合模型的思维直觉时，它的表现才会最出色。
这也说明，工具好不好，不是看它功能多强，而是看智能体能不能用对、用顺手。
二、工具也要与时俱进
Claude Code刚上线的时候，团队发现一个现象：智能体做着做着就容易跑偏，忘了自己原本要干什么。
于是他们给智能体加了一个待办清单工具（TodoWrite）。让它一开始就列好清单，做完一项勾一项。但即使这样，Claude 仍会忘记目标。于是又额外加了一个提醒机制：每 5 轮对话插入一次系统提醒。
这套方案在初期管用。但随着智能体模型版本的升级（从Claude 3.5到Opus 4.5），开发者们发现情况变了。
新版本的智能体更聪明了，不再需要频繁提醒。更关键的是，那些提醒反而成了束缚，它会让智能体觉得必须死守清单，不敢根据实际情况灵活调整。同时，当智能体学会调用子智能体（多个小助手协同工作）时，待办清单这种单线程的工具也不够用了。多个子智能体怎么共享一个清单？谁负责更新？谁来协调？
曾经帮助模型的工具，现在反而成为了束缚。
于是他们把待办清单换成了任务工具（Task Tool）。与专注于让模型保持正轨的待办清单不同，任务工具更关注帮助子代理之间相互通信，可以跨子智能体同步状态，智能体也可以随时修改或删除任务。
智能体的能力在进步，过去必需的“拐杖”，今天可能就成了“镣铐”。 工具设计不是一劳永逸的，需要跟着模型一起成长。
三、从喂到嘴边到自主觅食
早期版本的Claude Code，用了一种叫RAG的技术来帮智能体获取代码库信息。简单说，就是把代码库提前做好索引，智能体需要什么，就从索引里把相关内容喂给它。
虽然 RAG 强大快速，但需要索引和配置，在不同环境中容易出问题。更重要的是，整个过程中，智能体是被投喂的，而不是自己去找的。它并不真正理解怎么在代码库里定位信息，也学不会自己去探索。
后来他们换了个思路，如果智能体能上网搜索，为什么不能让它搜索自己的代码库？于是他们给智能体加了一个Grep工具，让它能用关键词在代码库里搜索文件、查找内容。
这一改，效果完全不同了。智能体开始自己尝试搜索关键词、筛选结果、定位相关文件……在这个过程中，它越来越擅长自己构建上下文。
再后来，团队引入了技能（Skill）的概念，进一步把这种能力系统化了。每个技能本质上是一个说明书，智能体可以读取说明书，说明书里又可能指向其他文件，智能体可以一层层往下找。就像一个会查资料的人，先翻目录，再翻章节，最后找到需要的那一段。
今天，Claude Code已经能够跨多层文件递归搜索，精准找到自己需要的信息。而这一切，只是因为它被赋予了自己去找的能力，而不是只等着被投喂。
这种设计思路，后来被他们总结为渐进式披露，不让智能体一开始就面对海量信息，而是给它一个入口，让它一步步探索出自己真正需要的内容。
四、渐进式披露：不加工具，也能扩展能力
Claude Code目前有大约20个工具。团队对加新工具这件事非常谨慎，因为每多一个工具，智能体在做选择时就要多考虑一个选项，选项太多，反而容易出错。
有一次，他们发现Claude Code对自身功能不够了解。用户问“怎么配置MCP”或“某个快捷命令是什么意思”，智能体答不上来。
按理说，最简单的办法是把所有功能说明都塞进系统提示里。但这么做有两个问题：一是大部分用户根本不会问这些问题，塞进去纯属浪费上下文；二是系统提示里塞了太多无关信息，反而会影响智能体在写代码这个主要任务上的表现。
那怎么办？他们又用上了渐进式披露的思路。
他们先给智能体一个指向官方文档的链接，让它自己去查，但效果不太理想。智能体经常一口气加载好几页文档进上下文，就为了找一个几句话就能说清的答案。
于是他们专门做了一个“Claude Code Guide”子智能体。当用户问到关于Claude Code自身的问题时，主智能体就把这件事交给这个子智能体去处理。子智能体有专门的指令，教它如何高效地查文档、如何筛选信息、如何简洁地回复。
虽然还不够完美（Claude 仍然会在自我配置问题上感到困惑），但已经比过去好多了。关键是在不增加工具的前提下，扩展了 Claude 的行动空间。
小结
工具设计这件事，很大程度上取决于你在用哪个模型、想让智能体做什么事、它在什么环境里运行。不同模型的理解能力不一样，同一个工具在这个模型上表现很好，换个模型可能就水土不服。
开发者们能做的，就是不断尝试、仔细观察、反复调整。看智能体的输出，看它怎么使用工具，看它在哪里卡住，然后一点一点优化。
说到底，设计智能体的工具，与其说是一门科学，不如说是一门手艺。手艺的精进，靠的不是背诵规则，而是反复练习、用心观察。
