出处说明：本文译自 Anthropic 官方博客《Seeing like an agent: how we design tools in Claude Code》，作者 Thariq Shihipar（Claude Code 团队工程师）。原文于发布当日上线。为便于国内读者理解，以下在不改变核心信息的前提下对原文进行了重写与编排。

把自己“调到”模型视角：工具要贴合能力

在构建 Agent 时，最难啃的骨头之一是“工具设计”。Claude 的行为完全通过工具调用完成，而在 Claude API 中，工具可以用 bash、skills、代码执行等原语拼装出来。那么，该给 Agent 一把“通用瑞士军刀”（如 bash/代码执行），还是塞给它一箩筐细分工具？

一个好用的思考框架是：换位到模型角度。就像解一道难题——只给纸笔能做，但慢；有计算器更快，但要会用高级功能；电脑最强，但前提是会写并运行代码。给 Agent 的工具，应该与它的能力“形状”契合。

怎么判断模型的能力边界？观察、阅读输出、反复实验，学会“像 Agent 一样看”。如果你也在做 Agent，你会遇到同样的问题：何时加工具、何时撤工具、如何分辨二者。下面是我们打造 Claude Code 的亲身实践（包含走过的弯路）。

案例一：用 AskUserQuestion，系统化提升提问（elicitation）

目标很明确：提升 Claude 向用户提问的质量与效率。如果只用纯文本提问，用户答复常常感觉“费劲”。

我们尝试过三种方案：

尝试 1：在 ExitPlanTool 上“叠加参数”

我们给 ExitPlanTool 增加了一个问题数组参数，让它在生成计划的同时列出要问的问题。这是最省事的改法，却立刻引发混乱：计划与问题共存时，若用户回答与计划冲突怎么办？是否需要二次调用？这条路走不通。

尝试 2：规定输出格式（特制 Markdown）

我们把输出指令改成“结构化问询格式”，例如用项目符号列问题，选项放在方括号里，前端再解析成 UI。Claude 大多数时候能遵守，但并不稳定：偶尔多加句子、漏掉选项，甚至完全丢弃格式。

尝试 3：独立工具 AskUserQuestion

最终我们做了一个独立工具，让 Claude 可在任意时刻调用（尤其在规划阶段会被特别引导）。工具触发后，前端弹出模态框展示问题，并暂停 Agent 循环直至用户答复。

• 优点 1：可稳态地产出结构化问题，并引导提供多个选项。
• 优点 2：具备可组合性，可在 Agent SDK 或 Skills 中复用。
• 关键点：Claude“愿意且会用”。设计再妙，模型不理解调用方式也白搭。

这是否是 Claude Code 中 elicitation 的终局形态？未必。随着 Claude 能力增强，服务它的工具也必须迭代。下一节就是一个“曾经有用、后来碍手碍脚”的例子。

案例二：能力进化倒逼工具重构——从 Todos 到 Tasks

Claude Code 刚上线时，模型需要一个“待办清单”来保持专注。我们用 TodoWrite 写/改 Todos，并展示给用户。即便如此，Claude 仍常忘目标，我们只好每 5 轮插入一次系统提醒。

随着模型进步，“Todo 思维”开始桎梏模型：系统提醒让 Claude 误以为必须墨守清单，不敢机动调整路线。同时，Opus 4.5 擅长使用子 Agent，但多个子 Agent 如何共享同一 Todo 清单？

于是我们把 TodoWrite 升级为 Task 工具：从“盯住一条线性清单”变为“服务多 Agent 的协作任务图”。Tasks 支持依赖关系、跨子 Agent 同步状态，并允许动态修改或删除。

方法论上的启示是：模型能力上台阶后，过去“必需”的工具可能变成掣肘。要定期回溯：这些工具是否仍然必要？同时，尽量聚焦少数能力相近的模型，便于统一工具设计。

案例三：把“找上下文”的权力还给模型——从 RAG 到 Grep，再到渐进式披露

内测版 Claude Code 最初采用 RAG：用向量数据库预索引代码库，每次回复前检索相关片段塞给 Claude。RAG 又快又强，但依赖索引与环境配置，且最根本的问题是：上下文是“喂给”模型的。

如果 Claude 能搜网页，为什么不能搜代码库？我们加了一个 Grep 工具，让它自己搜索文件、自己拼上下文。随着 Claude 变聪明，“自建上下文”的效果也越来越好。

引入 Agent Skills 后，我们把这个思路正规化为“渐进式披露”（progressive disclosure）：通过可递归的 Skill 文件，让模型探索并逐步发现关联上下文。常见用法是用 Skills 增配“搜索能力”，比如说明如何调用某 API、查询某数据库。

在过去一年里，Claude 从几乎不会自建上下文，进化到可以跨多层文件做嵌套搜索，精准定位所需信息。如今，渐进式披露已成为我们“在不增加新工具的前提下加功能”的常用手段。

案例四：用子 Agent 做渐进披露——Claude Code Guide

Claude Code 目前大约有 20 个工具。我们经常复盘是否真的“每一个都不可或缺”。添加新工具的门槛很高，因为每多一个工具，就多一个分支要思考。

例如，我们发现 Claude 对“Claude Code 自身”了解不够：问它怎么加 MCP、某个斜杠命令做什么，常答不上来。把所有说明塞进系统提示？用户其实不常问这类问题，强塞只会让上下文“腐蚀”，干扰它写代码的主业。

我们先试了渐进式披露：给一条文档链接，让 Claude 需要时自查。能用，但它经常把整段文档拉进上下文，只为回答一个一句话就能解决的问题。

最终方案是“Claude Code Guide”子 Agent：用户一问 Claude Code 自身的事，主 Agent 就把请求转给子 Agent。子 Agent 在自己的上下文里检索文档、按既定策略搜索与提取，只把答案回传，主 Agent 的上下文保持干净。

这仍非完美（例如在自我配置上仍可能混淆），但我们在不新增工具的前提下，把行动空间扩展开了。

方法论：像 Agent 一样看，是门手艺

给模型设计工具，既是科学，也是手艺。它高度依赖所用模型、Agent 目标与运行环境。我们的经验之谈：

• 多做实验，勤读输出，勇于尝试新思路。
• 工具要与模型能力匹配，既不过度“通用”，也不无谓“细分”。
• 能力进化要同步工具升级，必要时果断“减法”。
• 优先用渐进式披露与子 Agent 扩展能力，减少工具数量与上下文污染。

最重要的是，学会“像 Agent 一样看”。

原文：https://claude.com/blog/seeing-like-an-agent

作者：Thariq Shihipar，Anthropic 工程师，Claude Code 团队

文中涉及工具与名词：AskUserQuestion、ExitPlanTool、TodoWrite、Task、Grep、Agent Skills、Claude Code Guide、MCP、Opus 4.5 等。