你好，我是司沐。

在探讨大语言模型（LLM）的落地应用时，Agent（智能体）始终是一个绕不开的核心话题。我们都知道，让 Agent 真正运转起来的关键，是赋予它们使用工具（Tool Calling）的能力。

但这引出了一个非常实际的问题：面对各种各样的基础功能，我们到底该如何为 Agent 设计工具，才能让Agent执行效果更好？

是给它一个极其底层的代码执行器？还是为它可能遇到的 50 种不同场景，量身定制 50 个专属工具？

最近，Claude 团队分享了他们在构建 Claude Code 过程中的一手经验。这篇文章没有空洞的理论，全是烧钱+挨骂中总结出的实战经验。今天，我们就来聊聊，如何学会“像 Agent 一样思考”。

---

1. 如果执行任务的是你，你想要什么样的工具？

在设计工具之前，我们不妨换位思考一下。假设你现在面临一道极其复杂的数学题，你希望手边有什么工具？

答案其实取决于你自己的“能力”：

• 纸和笔是最低配置，但你会被手动计算的速度死死限制。
• 计算器会好很多，前提是你得知道怎么按出那些高级函数。
• 计算机是最快、最强大的，但门槛也最高——你必须得会写代码。

这就是一个非常实用的 Agent 工具设计思路：你提供的工具，必须与模型自身的能力相匹配。

那么，怎么摸清模型的能力底线呢？

这一点没有捷径。我们只能靠多加关注各大模型、阅读不同模型在不同场景下的输出日志，并不断进行实验，积累经验。

2. 实际案例：怎样的提问工具能让人和AI都舒服？

在 Claude Code 中，团队希望提升 Claude 向用户提问的能力，让Claude不要埋头就写，而是在拿不准主意的时候主动向用户提问。

虽然 Claude 本身就可以直接用大段的纯文本向用户发问，但这往往会增加用户的阅读和回复成本。

如何降低这种摩擦？团队经历了三次迭代：

• 第一次尝试：强行附加。 他们尝试在输出计划工具（ExitPlanTool）里加一个参数，让 Claude 在输出计划的同时附带问题。
  结果 Claude 懵了——如果用户的回答和当前的计划冲突了怎么办？这个方案最终没有采纳。
• 第二次尝试：约定格式。 随后，团队转而尝试修改系统提示词，要求 Claude 输出一种特定的 Markdown 格式，比如带括号的备选列表，然后在前端解析。
  看起来这个方式兼容性很好，但 Claude 的实际表现并不稳定，经常会加上多余的废话、漏掉选项，或者干脆自创格式。
• 最终方案：专属的 AskUserQuestion 工具。 团队最终决定为“提问”单独设计一个工具。当 Claude 在计划模式下调用这个工具时，系统会弹出一个模态窗口显示问题，并阻塞 Agent 的运行，直到用户给出回答。

事实证明，Claude 非常喜欢调用这个工具，输出的内容结构化极好。

这也带来了一个重要启示：哪怕工具设计得再精妙，如果模型本身不理解该怎么调用，也是白搭。

并且，适合当前模型的设计，换一个模型未必管用。

3. 实际案例：随着AI能力演化的待办工具

早期版本的 Claude Code 专门设计了一个 TodoWrite 工具来管理 Agent 的待办事项。

为了防止模型“走神”，团队不仅让它列待办事项（Todo list），还每隔 5 轮对话就在提示词中插入一段 “记得更新代办列表” 提醒它。

但随着底层模型的不断迭代升级，有趣的事情发生了：越来越聪明的模型开始觉得 Todo List 是一种束缚。

反复的提醒让 Claude 变得死板，它开始认为自己必须严格遵守那个旧列表，而不敢去修改它。与此同时，像 Opus 4.5 这样的新模型，在调用子Agent（subagents）方面变得更强了，然而之前设计的待办事项系统根本无法支持多个 Agent 之间的协同。

于是，团队大笔一挥，用 Task（任务）工具 替换了 Todo 列表。

Todo 是为了防止模型分心，而 Task 则是为了让 Agent 之间更好地沟通。Task 可以设置依赖关系，可以在子Agent之间共享进度，模型也可以自由地修改和删除它们。

结论很明确：随着模型能力的进化，过去能帮到它的工具，现在可能反而会限制它。 及时审视并淘汰过时的工具设定，是保持 Agent 战斗力的关键。

4. 实际案例：使用渐进式披露扩展Agent能力边界

对于像 Claude Code 这样的代码助手来说，搜索工具是否好用直接决定着它构建出的上下文的质量。

一开始，团队使用的是 RAG（检索增强生成）向量数据库。虽然快，但它需要繁琐的索引设置，而且 Claude 只能“被动”接收上下文。

后来，团队给了它一个更底层的 Grep 工具，让它自己去搜文件——结果发现，只要工具给对，越来越聪明的模型完全有能力自己构建高质量的上下文。

这就引出了一个最近很火的工程理念：渐进式披露（Progressive Disclosure）。

以 Claude Code 的使用指南为例。最初，Claude 连怎么设置自己的参数都不知道。如果把这些长篇大论的说明书全塞进系统提示词（System Prompt）里，不仅会造成上下文腐蚀（context rot），还会严重干扰它“写代码”这个核心主业。

团队的做法是：只给 Claude 一个指向官方文档的链接，让它自己去搜。

一开始 Claude 搜得很粗糙，会把大量无关结果拉进上下文。于是团队又做了一次“渐进式披露”，引入了一个专门的子Agent（Guide subagent）。

当用户问到关于 Claude 自身设置的问题时，它会去调用这个子Agent，由子Agent带着精准的指令去查阅文档并返回答案。

通过这种方式，团队在没有增加任何新工具、也没有让 Prompt 变得臃肿的前提下，成功扩展了 Claude 的行动空间（action space）。

---

存在构建工具的通解吗？

如果你在寻找一套“如何设计 Agent 工具”的通用数学公式或绝对法则，那么可能会失望。

为大语言模型设计工具，既需要严谨的工程科学，也需要对模型性格有深刻的洞察——这本质上是一门艺术。它高度依赖于你所选择的基础模型、Agent 的最终目标，以及它所处的具体环境。

少一些预设，多一些实验；认真阅读它的每一次输出，尝试新的组合。最重要的是：学会像 Agent 一样思考。

---

我是司沐，一名落地过不少企业项目的Agent系统架构师。

• 如果你喜欢看Agent架构相关的实战经验分享/科普文章，可以点个关注，或者翻翻历史文章，可能会有惊喜。

• 如果目前你手里有一些比较苦恼的场景，但不知道如何设计，欢迎在评论区留言。以当前本账号这个粉丝量，还是可以做到有问必答的。

  如果问题需要保密，也可以后台直接留言。

下期见！