像 Claude 一样思考：构建智能体工具箱的经验

AI资讯
1

Claude Code 团队分享智能体工具设计经验：工具要匹配模型能力，并随模型进化持续调整。

原文标题：构建Claude Code的经验教训：从智能体的视角观察

原文作者：AI前线

冷月清谈：

文章围绕 Claude Code 的构建实践，讨论了智能体工具设计中的关键取舍。作者认为，工具不是越多越好，也不是一个通用工具就能解决所有问题，而是要匹配模型自身能力、任务目标和使用环境。

文中以 AskUserQuestion 工具为例，说明结构化提问能力需要通过实验逐步打磨：直接在计划工具中加问题会让模型混淆，单靠输出格式约束又不稳定，最终独立工具更适合承载用户交互。

在任务管理上，Claude Code 早期依赖 TodoWrite 和系统提醒帮助模型保持目标，但随着模型能力提升，固定待办事项反而可能限制模型调整计划。因此团队改用更灵活的任务工具，支持依赖关系、子智能体协作和动态更新。

搜索能力方面，文章强调让模型主动构建上下文的重要性。从 RAG 到 Grep，再到技能和渐进式披露，Claude 逐渐具备了自主探索代码库和文档的能力。对于不常用的信息，团队更倾向通过子智能体或文档检索按需提供，而不是塞进系统提示。

作者最后指出，智能体工具设计没有固定公式，需要持续观察模型行为、反复实验，并随着模型能力变化不断修正工具假设。

怜星夜思：

1、给智能体设计工具时，你觉得应该优先“少而强”，还是“多而专”？
2、文章里说模型能力提升后，原来的工具可能会变成限制。你在实际使用 AI 编程工具时有这种感觉吗？
3、让智能体自己搜索代码库，比直接把 RAG 检索结果塞给它更好吗？
4、AskUserQuestion 这种“专门提问”的工具，会不会让智能体变得太依赖用户确认？

原文内容

作者 | Michael Redlich
译者 | 刘雅梦
策划 | 褚杏娟

构建智能体工具带中最困难的部分之一是构建其动作空间。

Claude 通过工具调用来执行操作，但是在 Claude API 中有很多方法可以使用原语，比如 bash、skills 和最近添加的代码执行来构造工具（阅读 @RLanceMartin 的新文章，了解更多关于 Claude API 的编程工具调用）。

考虑到所有这些选项，你如何设计智能体的工具？你是否只需要一个像代码执行或 bash 这样的工具吗？如果你有 50 个工具，每个工具对应一个智能体可能遇到的用例，那会怎么样？

为了将自己置于模型的思维中，我喜欢想象被给予一个困难的数学问题。你想用什么工具来解它？这要看你自己的技术了！

纸张是最基本的，但你将受限于手动计算。计算器会更好，但你需要知道如何操作更高级的选项。最快和最强大的选择是计算机，但你必须知道如何使用它来编写和执行代码。

这是一个设计智能体的有用框架。你想给它提供适合它自身能力的工具。但你怎么知道这些能力是什么呢？你要集中注意力，阅读它的输出，进行实验。你要学着像智能体一样看问题。

以下是我们在构建 Claude Code 时从关注 Claude 中学到的一些经验教训。

改进 Elicitation 和 

AskUserQuestion 工具

在构建 AskUserQuestion 工具时，我们的目标是提高 Claude 提问的能力（通常称为启发）。

虽然 Claude 可以直接问问题，但我们发现回答这些问题似乎花费了不必要的时间。我们怎样才能降低这种摩擦，增加用户和 Claude 之间的交流带宽呢？

尝试 1：编辑 ExitPlanTool

我们首先尝试的是向 ExitPlanTool 添加一个参数，以便在计划旁边放置一系列问题。这是最容易实现的事情，但这让 Claude 感到困惑，因为我们同时要求制定一个计划，并提出一系列关于计划的问题。如果用户的回答与计划内容相冲突怎么办？Claude 需要调用 ExitPlanTool 两次吗？我们需要另一种方法。

（你可以在我们关于提示缓存的文章中阅读更多关于我们为什么 要创建 ExitPlanTool 的信息）

尝试 2：改变输出格式

接下来，我们尝试修改 Claude 的输出指令，以使用稍微修改的 markdown 格式来提问。例如，我们可以要求它输出一个带有括号中替代选项的要点问题列表。然后，我们可以解析该问题并将其格式化为用户的 UI。

虽然这是我们能做的最通用的更改，Claude 甚至似乎能够很好地输出这个，但这并不能保证。Claude 会附加额外的句子，省略选项，或者完全使用不同的格式。

尝试 3：AskUserQuestion 工具

最后，我们决定创建一个 Claude 可以在任何时候调用的工具，但特别提示在计划模式期间这样做。当工具触发时，我们会显示一个模态框来显示问题，并阻止智能体的循环直到用户回答。

这个工具允许我们提示 Claude 进行结构化输出，并帮助我们确保 Claude 给用户提供多个选项。它还为用户提供了组合此功能的方法，例如在代理式 SDK 中调用它或在技能中引用它。

最重要的是，Claude 似乎很喜欢调用这个工具，我们发现它的输出效果很好。即使是最好的设计工具，如果 Claude 不知道如何调用它，也是行不通的。

这是 Claude Code 中启发的最终形式吗？我们不确定。正如你将在下一个例子中看到的，适用于一个模型的方法可能不适用于另一个模型。

更新能力：任务和待办事项

当我们第一次发布 Claude Code 时，我们意识到模型需要一个待办事项列表来保持它的正常运行。可以在开始时编写待办事项，并在模型工作时进行检查。为此，我们给了 Claude TodoWrite 工具，它可以编写或更新待办事项并将其显示给用户。

但即便如此，我们也经常看到 Claude 忘记了它的职责。为了适应这种情况，我们每 5 个回合就会插入系统提醒，提醒 Claude 它的目标。

但随着模型的改进，它们不仅不需要被提醒待办事项列表，而且还会发现它的局限性。收到待办事项清单的提醒使 Claude 认为它必须坚持而不是修改它。我们还看到 Opus 4.5 在使用子智能体方面做得更好，但是子智能体如何在共享的待办事项列表进行协调呢？

看到这一点，我们用任务工具代替了 TodoWrite（阅读更多 关于任务的内容）。待办事项的作用是保持模型的正常运行，而任务的作用更多的是帮助智能体相互沟通。任务可以包括依赖关系，在子智能体之间共享更新，模型可以更改和删除它们。

随着模型功能的增加，你的模型曾经需要的工具现在可能会限制它们。重要的是要不断地回顾之前关于需要什么工具的假设。这也是为什么坚持支持一小组具有相当相似的功能配置文件的模型是有用的。

设计一个搜索界面

对 Claude 来说，一组特别重要的工具是搜索工具，可以用来构建自己的上下文。

当 Claude Code 首次推出时，我们使用了一个 RAG 向量数据库来查找 Claude 的上下文。虽然 RAG 功能强大且速度快，但它需要索引和设置，并且在许多不同的环境中可能很脆弱。更重要的是，Claude 被赋予了这个上下文，而不是自己找到上下文。

但如果 Claude 能在网络上搜索，为什么不搜索你的代码库呢？通过给 Claude 一个 Grep 工具，我们可以让它自己搜索文件和构建上下文。

这是我们看到的一个模式，随着 Claude 变得越来越聪明，如果给它合适的工具，它就会越来越善于构建它的环境。

当我们引入智能体技能时，我们正式定义了渐进式披露的概念，它允许智能体通过探索逐步发现相关的上下文。

Claude 可以读取技能文件，然后这些文件可以引用模型可以递归读取的其他文件。事实上，技能的一个常见用途是为 Claude 添加更多的搜索功能，比如告诉它如何使用 API 或查询数据库。

在一年的时间里，Claude 从不能真正建立自己的上下文，到能够在几层文件中进行嵌套搜索，以找到它所需要的确切上下文。

渐进式披露现在是我们在不添加工具的情况下添加新功能的常用技术。

渐进式披露：Claude Code 指南智能体

Claude Code 目前有大约 20 个工具，我们不断地问自己是否需要所有这些工具。添加新工具的门槛很高，因为这给模型提供了更多的选择。

例如，我们注意到 Claude 对如何使用 Claude Code 了解不够。如果你问它如何添加 MCP 或者斜杠命令的作用，它将无法回答。

我们本可以将所有这些信息放在系统提示中，但考虑到用户很少询问这些信息，这将增加上下文的腐朽并干扰 Claude Code 的主要工作：编写代码。

相反，我们尝试了一种渐进披露的形式。我们给了 Claude 一个文档的链接，他可以下载这个链接来搜索更多的信息。这是有效的，但我们发现 Claude 会把很多结果放到上下文中来找到正确的答案，而你真正需要的只是答案。

因此，我们构建了 Claude Code 指南子智能体，当你询问它自己时，Claude 会被提示调用，子智能体有关于如何很好地搜索文档以及返回什么内容的大量说明。

虽然这不是完美的，Claude 仍然会感到困惑，当你问它如何设置自己，它是比以前好得多！我们能够在不添加工具的情况下向 Claude 的动作空间添加东西。

是艺术，不是科学

如果你希望有一套关于如何构建工具的严格规则，很遗憾，这不是本指南。为模型设计工具既是一门科学，也是一门艺术。这在很大程度上取决于你正在使用的模型，智能体的目标以及它所处的环境。

经常实验，阅读你的成果，尝试新事物。像一个智能体一样看待问题。

原文链接：

https://x.com/trq212/status/2027463795355095314

会议推荐

QCon 全球软件开发大会·2026 北京站将于 4 月 16 日 -18 日正式举办。本届大会以“Agentic AI 时代的软件工程重塑”为主题，聚焦 100+ 重磅议题，汇聚来自阿里、腾讯、字节跳动、小米、百度等一线科技企业与创新团队的技术专家，围绕 AI 工程化、系统架构与研发模式演进展开深入探讨。更多详情可扫码或联系票务经理 18514549229 进行咨询。

今日荐文

图片
你也「在看」吗？👇

2

这个问题问得好！对我来说，科学是地基，艺术是上层建筑。没有坚实的地基，上层建筑再漂亮也白搭。但在地基之上，如何设计上层建筑，那就是艺术的范畴了。具体来说，我会先用科学的方法去了解模型的能力边界、数据的特点等等，然后再用艺术的思维去创造性地解决问题。比如，用一些巧妙的提示工程（prompt engineering）来引导模型更好地使用工具，这就是一种艺术。

3

科学就像是工具的骨架，保证它能正常工作；艺术就像是工具的灵魂，让它用起来顺手、甚至有趣。科学告诉你工具应该怎么做，艺术告诉你工具应该给用户什么样的感觉。好的工具，既要经得起科学的检验，也要经得起用户体验的考验！

4

文章中“像智能体一样看待问题”的核心在于理解模型的能力边界和行为模式。具体实践中，我们可以通过以下几个步骤来模拟智能体的思考方式：

1. 详细阅读文档和API参考：了解模型的所有功能和参数，明确其擅长和不擅长的任务。
2. 大量实验：尝试不同的输入，观察模型的输出，分析其在各种情况下的表现。记录模型的成功和失败案例，总结其行为模式。
3. 分析日志和调试信息：深入了解模型的内部状态，找出潜在的问题和瓶颈。
4. 迭代工具和提示词：根据实验结果，不断调整工具的设计和提示词的编写，以提高模型的性能。

此外，心理学中的一些概念也可以帮助我们更好地理解智能体的思考方式。例如，可以将智能体视为一个具有特定认知偏差和局限性的个体，并尝试从这个角度来分析其行为。

5

我觉得关键在于“所有权”。被动接受的信息，智能体只是“接收者”，缺乏对信息的掌控感和理解深度。而自己构建的上下文，是智能体主动“创造”的，它更明白信息的来源、结构和关联，能够更好地运用这些信息。此外，自己构建上下文也有助于知识的更新和迭代，避免智能体的信息滞后。

6

从智能体的角度来看，RAG像是一个预先准备好的“作弊小抄”，快速但可能不够灵活；Grep则像是赋予了智能体“自主学习”的能力，虽然慢一点，但是能够更深入地理解和构建知识体系。如果目标是快速解决问题，RAG可能更适合；但如果希望智能体能够持续学习和进化，Grep可能更有价值。

7

我觉的可以尝试“压力测试”，故意给模型一些模棱两可或包含错误的信息，看看它会如何处理。这样可以暴露模型的弱点和潜在的偏见，帮助我们更好地理解它的工作方式。类似于软件工程中的“容错性测试”。

8

想象一下，TodoWrite就像一个人的单线程程序，而任务工具就像一个多线程程序。当任务变得越来越复杂时，单线程程序就会变得不堪重负。而多线程程序则可以同时处理多个任务，提高整体效率。对于高级模型来说，任务工具就像一个强大的多线程处理器，可以帮助它们更好地应对各种挑战。

9

这个问题很有意思！说到量化的科学方法，我觉得可以从以下几个方面入手：

1. 数据分析： 分析模型在不同任务下的表现，找出瓶颈和短板。比如，可以通过观察模型在哪些类型的输入上容易出错，来确定需要什么样的工具来辅助。
2. A/B测试： 对不同的工具设计方案进行A/B测试，比较它们对模型性能的影响。比如，可以测试不同的搜索算法，看哪种算法能更快地找到相关信息。
3. 性能指标： 设定一些性能指标，比如任务完成时间、准确率、资源消耗等，来评估工具的效果。比如，可以比较在使用工具前后，任务完成时间的变化。

这些方法可以帮助我们更客观地评估工具的价值，并进行优化。

而说到无法量化的艺术成分，我觉得主要体现在以下几个方面：

1. 直觉： 有时候，我们需要凭借直觉来判断模型需要什么样的工具。这需要对模型的工作原理有深入的理解，以及对未来趋势的敏锐洞察。
2. 创造力： 设计工具需要创造力，需要能够想到一些新颖的思路和方法。比如，如何将不同的工具组合起来，以实现更复杂的功能。
3. 迭代： 工具设计是一个迭代的过程，需要不断地尝试和改进。在这个过程中，我们需要不断地学习和反思，并根据实际情况进行调整。

10

抖个机灵， 我觉得这个“渐进式披露”有点像“盲盒”！

每次完成一个小目标就给AI一个“盲盒”， 里面装着对它完成下一步任务有帮助的信息。 这样既能保持AI的好奇心， 又不会一下子给它太多的压力。

当然，这个“盲盒”的设计要合理， 需要保证里面的信息是与当前任务相关的， 并且难度适中。 如果“盲盒”里面的东西太难或者太没用， AI可能就会失去兴趣。

11

在客服机器人中，可以先提供常见的FAQ，如果用户的问题不在FAQ中，再引导用户提供更详细的信息，或者逐步开放更高级的功能（例如查看订单详情、修改地址等）。这样可以避免一开始就给用户过多的信息，提高用户体验。

12

与其说发展趋势，不如说是螺旋上升吧！一开始，可能需要很多专用工具来辅助智能体完成任务。但随着智能体能力的提升，它可能会自己学习如何使用这些工具，甚至可以自己创造新的工具。这个时候，我们就需要更通用、更底层的工具来支持智能体的创造。

我觉得未来的智能体就像一个创业者，我们提供给它的是启动资金（通用工具），它自己会想办法去创造价值（专用工具）。

13

控制工具数量的关键在于“精简”。每个工具都应该有明确的用途，避免功能重叠。可以借鉴软件设计的“单一职责原则”，确保每个工具只负责一个特定的任务。另外，可以考虑将一些低频使用的工具进行“模块化”，只有在需要时才加载。

14

文章提出的“像一个智能体一样看待问题”确实很有意思。我的理解是，需要站在智能体的角度，思考它需要什么样的信息、什么样的工具，才能更好地完成任务。在实际开发中，这意味着我们需要深入理解模型的特性和局限性，通过实验和观察找到最有效的解决方案。就好比训练宠物，你要了解它的习性才能更好地训练它，而不是强迫它按照你的想法来做。

15

这个问题触及到了AI开发的本质：理解你的Agent。我认为可以从以下几个方面入手：

1. Profiling (画像分析): 仔细分析Claude的输出，观察其在不同任务下的表现，建立一个详细的能力画像。哪些任务完成得好？哪些任务容易出错？出错的原因是什么？
2. Error Analysis (错误分析): 对Claude的失败案例进行深入分析，找出问题的根本原因。是缺乏必要的知识？还是工具使用不当？或者只是简单的逻辑错误？
3. Ablation Studies (消融研究): 逐步移除或修改Claude的工具，观察其对Agent整体性能的影响。这有助于我们理解每个工具的作用和重要性。

最终，我们需要对Claude形成一种直觉，就像了解一位熟悉的老朋友一样。

16

我觉得可以理解为“站在AI的视角思考”。例如，当我们给Claude一个任务时，不是想着“我希望它怎么做”，而是思考“如果我是Claude，我需要哪些信息和工具才能完成这个任务”。这样就能更好地设计智能体可以理解和利用的工具。而且，要允许AI犯错，并从错误中学习和改进。

17

判断工具是否“过时”，我觉得可以从两个方面入手：一是看它的使用频率，如果一个工具越来越少被调用，那可能说明它已经不再适应当前的需求了；二是看它的效果，如果一个工具的输出质量明显下降，或者经常出现错误，那也应该考虑替换它了。

18

我的想法不太一样，安全问题是需要重视，但Grep工具能力之外，是不是也能考虑将向量数据库和Grep结合？向量数据库可以存储代码片段的embedding，用于快速检索相关代码，而Grep可以提供更精确的搜索结果。通过这种方式，可以在一定程度上减少Claude需要访问的文件范围，提高搜索效率和安全性。

19

这确实是个关键问题！权限控制必须做好。一种方法是使用沙箱环境，只允许 Claude 访问特定的、非敏感的代码仓库。还可以考虑使用访问控制列表（ACL）来限制 Claude 对文件的读取权限，确保它只能搜索到允许访问的内容。此外，对Grep搜索的日志进行监控，可以及时发现潜在的违规行为。

20

楼上说的有道理，向量检索+Grep精确定位，思路很棒！不过，如果真要做到万无一失，可能需要在数据层面做一些脱敏处理。比如，对代码中的敏感信息进行替换或加密，只允许Claude访问脱敏后的版本。当然，这样做的前提是不影响Claude的正常工作。