给 AI 设计工具这件事,Anthropic 踩过的坑比你想的多-夜雨聆风

给 AI 设计工具这件事,Anthropic 踩过的坑比你想的多

当你给 AI 一个工具的时候，它到底是怎么”理解”这个工具的？

我们聊 AI，关注的多半是模型参数、推理能力、上下文长度。但 Anthropic 的 Claude Code 团队最近聊了一个不太有人提的话题：怎么给 AI 设计工具。一个 Agent 到底需要什么样的工具？给多了它会迷茫，给少了它又干不了活。

他们的回答是：你得学会用 Agent 的眼睛看世界。

一个工具，改了三次才对味

Claude Code 团队举的第一个例子是 AskUserQuestion 工具。问题很简单：Claude 执行任务时需要向用户提问，但纯文本提问太慢，怎么让交互更高效？

第一次，他们在 ExitPlanTool 上加了个问题数组。省事吧？但 Claude 蒙了——你让我同时出一个计划又问对这个计划的问题，到底以哪个为准？用户回答跟计划冲突了怎么办？走不通。

第二次，让 Claude 用特定的 markdown 格式输出问题列表，前端解析成 UI。想法不错，但 Claude 不太靠谱。有时候多输出几句废话，有时候丢选项，有时候干脆不按格式来。没法指望语言模型每次都严守格式规范。

第三次，专门做了 AskUserQuestion 工具。Claude 可以随时调用，触发后弹窗展示问题，阻塞 Agent 循环等用户回答。有意思的是，Claude 不但理解怎么调用，而且很”喜欢”调用它。

我感触挺深。做产品的时候经常犯同一个错——觉得在已有功能上加个参数就够了，而不是认真想交互方式本身是不是有问题。Anthropic 走了两轮弯路才发现，给 Agent 设计工具跟给人设计工具一样，得站在使用者的角度想。

第二个案例更有意思，因为它涉及一个很多人没意识到的事：模型变强了，之前好用的工具可能反而碍事。

Claude Code 刚发布时，模型经常忘事。解决方案是 TodoWrite 工具加上每5轮一次的系统提醒。当时确实管用。

但 Opus 4.5 出来后，模型能力强了很多。问题来了——系统提醒反而让 Claude 觉得自己必须死守 todo 列表，哪怕中途发现需要改方向也不敢动。子 Agent 之间的协作也越来越频繁，一个简单的 todo 列表根本没法支持多 Agent 协调。

他们用 Task 工具替换了 TodoWrite。Task 不只是记录待办，更像 Agent 之间的通信协议——可以设定依赖关系、跨子 Agent 同步状态、动态修改和删除。

这一点我觉得值得注意。很多团队在搭 AI Agent 系统，设计了各种记忆机制、提醒机制。但模型能力在飞速迭代，6个月前设计的”辅助”机制，6个月后可能就是”限制”。定期审视工具集，看看哪些已经不需要了，比一味加新工具更重要。

第三个案例讲搜索能力的演进，我个人觉得这是最有意思的部分。

Claude Code 内部早期用 RAG——向量数据库预先索引代码库，每次响应前检索相关片段塞给 Claude。快是快，但有个根本问题：信息是被动喂给模型的，不是模型主动找到的。

后来他们给了 Claude 一个 Grep 工具，让它自己搜代码库。这跟人类写代码的方式更接近——你不会提前背下整个代码库，而是需要什么搜什么。

再后来 Agent Skills 引入了”渐进式披露”。Claude 可以读技能文件，文件又引用其他文件，模型递归地探索上下文。一年前还不会自己建上下文的 Claude，现在能在好几层文件之间做嵌套搜索，找到它需要的那段代码。

Anthropic 还分享了一个巧妙的做法。

Claude Code 目前有大约20个工具，加新工具的门槛很高，因为多一个工具模型就多一个选择要考虑。

用户问 Claude Code 怎么配置 MCP、slash command 怎么用，Claude 答不上来。把文档全塞进 system prompt？那会污染主上下文，影响写代码的正事。

第一版方案：给 Claude 一个文档链接，需要时自己去读。问题是 Claude 会把大段文档拉进上下文，就为了找一个一句话的答案，太浪费。

最终方案：做了个 Claude Code Guide 子 Agent。用户问到 Claude Code 自身的问题时，主 Agent 调用这个子 Agent，子 Agent 在自己的上下文里搜索文档，只把答案带回来。主 Agent 的上下文保持干净。

这个思路我觉得很妙。做 AI 应用遇到知识不足，第一反应往往是加 context、加 RAG。但换个角度，用子 Agent 隔离搜索过程，既解决了信息获取，又不影响主流程效率。

Anthropic 这篇文章表面讲工具设计，实际在讲一件事：设计 Agent 工具是门手艺，不是套公式。它取决于你用什么模型、目标是什么、运行环境怎么样。

如果你在做 Agent 相关的工作，建议读一下原文。不是因为它给了什么银弹方案，而是它展示了一种思维方式——站在模型的视角看问题，而不是站在开发者的视角。