Agent 工具设计：Anthropic 工程师的一手经验
你给 Agent 加了 50 个工具，它反而更蠢了。
这不是段子。Claude Code 团队在构建过程中反复遇到这个问题。工具不是越多越好，关键是要匹配模型的能力。
Anthropic 工程师 Thariq 最近分享了他们的踩坑经验，标题叫"Lessons from Building Claude Code: Seeing like an Agent"。我读完觉得挺有料，结合自己做 OpenClaw 的实践，整理成这篇。
工具设计的核心原则
Thariq 用了一个很形象的类比：
想象你要解一道难题。你希望有什么工具？
答案取决于你自己的能力：
- 只会基础运算 → 纸笔就够了
- 会用计算器 → 给你计算器效率更高
- 会写代码 → 给你电脑最快
同样的任务，不同能力的人需要不同的工具。Agent 也一样。
核心原则：工具要匹配模型的能力，而不是任务的复杂度。
这就是 Thariq 说的"See like an agent"——你得学会用模型的眼睛看问题。
案例一：AskUserQuestion 工具的三次迭代
Claude Code 需要一个让模型问用户问题的功能。听起来简单，但他们迭代了三次。
第一次：在 ExitPlanTool 里加参数
最省事的方案——在现有工具里加一个 questions 数组。
结果：Claude 搞混了。它不知道是先出计划还是先问问题，用户回答后计划又要改。
第二次：改输出格式
让 Claude 用特定的 Markdown 格式输出问题，然后解析成 UI。
结果：不稳定。Claude 经常多加一句话，或者格式跑偏。
第三次：独立的 AskUserQuestion 工具
专门做一个工具，调用时弹窗阻塞，等用户回答。
结果：成功。Claude 很喜欢调这个工具，输出也稳定。
教训：工具的边界要清晰。一个工具干一件事，模型才不会困惑。
案例二：Todo 变成了枷锁
早期 Claude Code 需要 Todo 列表来保持专注。团队甚至每 5 轮插入一条系统提醒：“别忘了你的 Todo。”
但模型变强之后，这套机制反而成了问题。
Claude 开始死守 Todo 列表，不敢改。系统提醒让它觉得"列表是铁律"，即使发现更好的方案也不敢调整。
更麻烦的是 subagent 场景。多个 agent 怎么共享一个 Todo 列表？谁能改？改了别人怎么知道？
解决方案：用 Task 替代 Todo。
Task 工具的设计完全不同：
- 支持依赖关系（A 完成后才能做 B）
- 跨 subagent 共享状态
- 可以随时修改和删除
教训：模型能力在进化，工具也要跟着进化。曾经的脚手架，可能变成今天的枷锁。
案例三：搜索能力的演进
这个案例最能说明"渐进式披露"的威力。
早期：RAG 喂上下文
Claude Code 最初用向量数据库做 RAG，把相关代码片段喂给模型。
问题：
- 需要预先索引，环境依赖重
- 上下文是"被动接收"的，模型没有主动权
中期：Grep 自己找
既然 Claude 能在网上搜索，为什么不能在代码库里搜？
给它一个 Grep 工具，让它自己决定搜什么、怎么搜。效果立刻变好。
现在：渐进式披露
Agent Skills 引入了一个关键概念：文件可以引用其他文件。
Claude 读一个 skill 文件，里面提到"详见 xxx.md"，它就去读。读完发现还有引用，继续读。
一层层递归下去，模型自己构建出完整的上下文。
教训：与其一次性喂大量信息，不如让模型自己探索。它比你更知道自己需要什么。
不加工具也能扩展能力
Claude Code 目前有大约 20 个工具。团队对加新工具非常谨慎——每多一个选项，模型就多一分困惑。
但用户会问：“Claude Code 怎么加 MCP？”“这个斜杠命令是干嘛的？”
怎么办？把所有文档塞进 system prompt？那会造成"上下文腐烂"，干扰模型的主要任务（写代码）。
他们的方案：Claude Code Guide subagent。
当用户问关于 Claude Code 本身的问题时，主 agent 会调用一个专门的 subagent。这个 subagent 有详细的文档搜索指令，知道怎么找答案。
不需要加新工具，通过 subagent 委派就解决了。
这就是渐进式披露的另一种形式：能力可以通过组合现有工具来扩展，而不是无限堆砌新工具。
我的实践补充
在做 OpenClaw 的过程中，我也有类似的体会。
Goal-Driven 模式的前提是模型能力
很多人说"给 Agent 目标，让它自己拆解"。这话没错，但有个隐含前提：模型得足够强。
弱模型需要你把步骤拆好，一步步喂。强模型才能接受模糊目标，自己规划路径。
同样的 Agent 框架，换个模型可能完全不 work。不是框架的问题，是工具设计没有匹配模型能力。
Skill 文件就是渐进式披露
OpenClaw 的 skill 机制和 Claude Code 的 Agent Skills 思路一致：
- 主 prompt 只告诉模型"有这些 skill 可用"
- 模型根据任务判断要不要读
- 读了 skill 文件，里面可能引用更多文件
- 按需加载，不污染主上下文
这比把所有指令塞进 system prompt 高效得多。
总结
Thariq 在文章结尾说：
“Designing the tools for your models is as much an art as it is a science.”
工具设计是艺术，不是科学。没有放之四海皆准的规则。
但有一个方法论是确定的：
多读模型的输出，多实验，学会用模型的眼睛看问题。
See like an agent。
参考链接：