Claude Code 究竟是如何炼成的？ Anthropic 团队成员 Thariq 最近发文，首次分享了在开发 Claude Code 过程中总结的四条实战经验，这些经验聚焦于一个核心问题：怎么给 Agent 设计工具？
他的观点很直接：给模型设计工具既是科学也是艺术，它没有死板的规则，关键是学会像 Agent 一样思考。
构建 Agent 最难的部分之一，就是设计它的行动空间（action space）。Claude 通过工具调用（Tool Calling）来行动，而在 API 层面，这些工具可以用不同形式构建——比如 bash 命令、skills，还有最近新增的代码执行。
工具这么多，该怎么选？Agent 需要多少个工具？是只用代码执行或 bash 就够了，还是像瑞士军刀一样准备 50 个工具来应对各种场景？
要理解这个问题，不妨把自己代入模型的视角。想象你拿到一道复杂的数学题——你需要什么工具来解它？这完全取决于你自己的能力水平。
纸笔是底线，但手算太慢。计算器更好，但你得会用那些高级功能。最快最强的当然是电脑，但前提是你会写代码、会执行。
用这个框架来设计 Agent 工具很管用：给它的工具要贴合它自身的能力。但你怎么知道它有什么能力？你得观察，读它的输出，做实验。学会像 Agent 一样思考。
下面就是团队在观察 Claude、开发 Claude Code 过程中学到的一些具体经验。
一、要提升向用户提问的能力，去优化信息获取
在设计 AskUserQuestion 工具时，团队的目标是提升 Claude 的提问能力（elicit）。Claude 当然可以直接用文字提问，但他们发现回答这些问题总要多花不少时间。如何降低摩擦、提升用户和 Claude 之间的沟通带宽？
第一次尝试：改 ExitPlanTool
最先试的是在 ExitPlanTool 上加一个参数，让工具同时输出计划和问题列表。实现起来最简单，但把 Claude 搞懵了——他们同时要它给计划，又要它问关于计划的问题。那如果用户的回答和计划冲突怎么办？Claude 要调两次 ExitPlanTool 吗？看来得换个思路。
第二次尝试：改输出格式
接下来团队试着改 Claude 的输出指令，让它用一种变体的 markdown 格式来提问。比如让它输出带选项的 bullet point 问题列表，然后解析格式、渲染成 UI。
这是改动范围最小的方案，Claude 也确实能按格式输出。但问题是不稳定——它总会多 append 几句话、漏掉选项、或者干脆换种格式。
第三次尝试：AskUserQuestion 工具
最后，他们做了一个独立工具。Claude 随时都能调用它，但特别鼓励它在 plan 模式下使用。工具触发时，会弹出一个模态框展示问题，然后阻塞 Agent 循环，等用户回答。
这个工具让他们能要求 Claude 输出结构化内容，确保给用户多个选项。用户也能在 Agent SDK 里调用它，或者在 skills 里引用。
最重要的是，Claude 似乎很喜欢调这个工具，而且输出效果确实好。设计得再好的工具，如果模型不知道怎么用，也是白搭。
这是不是 Claude Code 里信息获取的最终形态？他们不确定。就像下个例子要讲的，适合一个模型的方案，不一定适合另一个。
二、要跟着模型的能力，去进化工具
Claude Code 刚上线时，团队发现模型需要一个 Todo 列表来保持专注。可以在开始时写个 todo，做完一项勾一项。于是他们做了 Claude TodoWrite 工具，让它写或更新 todos 并展示给用户。
但即使这样，还是经常发现 Claude 忘事。为了应对，他们每 5 轮对话就插入一次系统提醒，让 Claude 记住目标。
但随着模型变强，它们不仅不需要被提醒看 todo list，反而会觉得这玩意儿碍事。被提醒看 todo，会让 Claude 觉得自己必须死守列表，而不是灵活修改。他们还发现 Opus 4.5 在用 subagent 上强了很多，但多个 subagent 怎么共享一个 todo list？
看到这些，他们把 TodoWrite 换成了Task 工具。
如果说 Todos 是为了让模型保持专注，那 Tasks 更多是帮 Agent 之间互相协作。Tasks 可以有依赖关系、跨 subagent 同步更新、模型也能修改和删除它们。
模型能力在涨，你曾经给它的工具，现在可能反而成了束缚。 要经常回头看之前的假设是否还成立。这也是为什么要尽量只支持一小批能力相近的模型。
三、要设计搜索交互，让 Agent 自己构建上下文
对 Claude 来说，有一类工具特别重要——搜索工具，用来帮它自己构建上下文。
Claude Code 刚发布时，团队用 RAG 向量数据库（RAG vector database）来找上下文。RAG 又快又强，但需要建索引、做配置，在不同环境下还很脆弱。更重要的是，上下文是我们塞给 Claude 的，不是它自己找的。
但既然 Claude 能搜网页，为什么不能搜代码库？给了 Claude Grep 工具，它就能自己搜文件、自己构建上下文了。
他们观察到一个模式：Claude 越变越聪明，只要给它对的工具，它就越擅长自己构建上下文。
推出 Agent Skills 时，他们把 渐进式披露 正式化了——Agent 可以通过探索，逐步发现相关的上下文。
Claude 能读 skill 文件，这些文件又能引用其他文件，模型可以递归地读下去。实际上，skills 的一个常见用法就是给 Claude 加搜索能力，比如教它怎么用某个 API、怎么查询数据库。
一年时间，Claude 从完全不会自己构建上下文，进化到能跨多层文件做嵌套搜索，精准找到需要的上下文。
渐进式披露现在成了他们添加新功能的常用技巧，不用再加新工具了。
四、要避免工具膨胀，让信息逐步显现
Claude Code 目前有大概 20 个工具，团队一直在问自己：真的需要这么多吗？加新工具的门槛很高——每多一个选项，模型就要多思考一层。
比如，他们发现 Claude 对自己怎么用 Claude Code 了解不够。问它怎么加 MCP、斜杠命令是干嘛的，它答不上来。
可以把这些信息全塞进系统 prompt，但用户很少问这些，只会徒增上下文噪音，干扰 Claude Code 的主业——写代码。
于是他们试了 渐进式披露：给 Claude 一个文档链接，它可以加载并搜索更多信息。这能跑通，但他们发现 Claude 会加载大量结果进上下文，其实用户只想知道答案。
于是他们做了 Claude Code Guide subagent。当用户问关于 Claude Code 自身的问题时，Claude 会被 prompt 去调这个 subagent。Subagent 有详细的指令，教它怎么高效搜文档、该返回什么。
虽然不完美——问 Claude 怎么配置它自己时，它还是会懵——但已经比原来好多了。他们用这种方式扩展了 Claude 的行动空间，却没加新工具。
学会像 Agent 一样思考
如果你在等一套 rigid 的工具设计规则，那这篇文章可能帮不了你。给模型设计工具，既是科学也是艺术。它高度依赖你在用什么模型、Agent 的目标是什么、它运行在什么环境。
多做实验，多读输出，多尝试新东西。学会像 Agent 一样思考。
在人工智能和工具设计的实践中，不断观察和调整是关键。更多关于 Agent 开发与最佳实践的深度讨论，欢迎访问云栈社区的技术论坛进行交流。
发表于 13 小时前
|
查看: 2|
回复: 0
