“think”工具:让 Claude 停下来思考
The "think" tool: Enabling Claude to stop and think
Anthropic 介绍 Claude 的 “think” tool:在生成回复后为多步骤 tool use 增加专用思考步骤,区别于 extended thinking。τ-bench 显示其在 airline、retail 客服任务提升 pass^k;SWE-bench 中 Claude 3.7 Sonnet 加入类似 tool 后得分 0.623,平均提升 1.6%。
随着我们持续增强 Claude 的复杂问题解决能力,我们发现了一种特别有效的方法:一个 “think” tool,它在复杂任务中为结构化思考创建专用空间。
这个简单但有效的技巧——如下文所述,它不同于 Claude 新的 “extended thinking” 能力(extended thinking 实现细节见此处)——显著提升了 Claude 的 agentic tool use 能力。这包括遵循政策、做出一致决策,以及处理多步骤问题,而且实现开销很小。
在本文中,我们将探讨如何在不同应用中实现 “think” tool,并基于经过验证的 benchmark 结果,为开发者分享实用建议。
通过 “think” tool,我们让 Claude 能够在得出最终答案的过程中加入一个额外的思考步骤,并拥有自己的专用空间。
它听起来与 extended thinking 类似,但两者是不同的概念。Extended thinking 关注的是 Claude 在开始生成回复之前所做的事。借助 extended thinking,Claude 会在采取行动前深入考虑并迭代其计划。“think” tool 则用于 Claude 开始生成回复之后,增加一个步骤,让它停下来思考自己是否已经拥有继续推进所需的全部信息。在执行较长的 tool call 链,或与用户进行较长的多步骤对话时,这一点尤其有用。
这使得 “think” tool 更适合以下场景:Claude 无法仅凭用户 query 获得构造回复所需的全部信息,并且需要处理外部信息(例如 tool call 结果中的信息)。Claude 使用 “think” tool 进行的推理不如 extended thinking 所能获得的推理全面,而是更聚焦于模型新发现的信息。
我们建议在更简单的 tool use 场景中使用 extended thinking,例如非顺序 tool call 或直接的指令遵循。Extended thinking 也适用于 coding、数学和物理等用例,前提是你不需要 Claude 调用 tools。“think” tool 更适合 Claude 需要调用复杂 tools、在较长的 tool call 链中仔细分析 tool 输出、在包含详细指南且政策要求较多的环境中操作,或做出顺序决策的场景;在这些场景中,每一步都建立在前一步之上,错误代价较高。
下面是一个使用 τ-Bench 标准 tool specification 格式的示例实现:
我们使用 τ-bench(tau-bench)评估了 “think” tool。τ-bench 是一个综合 benchmark,旨在测试模型在真实客户服务场景中使用 tools 的能力,其中 “think” tool 是评估标准环境的一部分。
τ-bench 评估 Claude 的能力包括:
τ-bench 使用的主要评估指标是 pass^k,它衡量的是:对于给定任务,k 次独立任务试验全部成功的概率,并在所有任务上取平均。不同于其他 LLM 评估中常见的 pass@k 指标(衡量 k 次试验中至少一次成功),pass^k 评估的是一致性和可靠性——这对于客户服务应用至关重要,因为在这类应用中,持续遵循政策非常重要。
我们的评估比较了几种不同配置:
结果显示,当 Claude 3.7 在 benchmark 的 “airline” 和 “retail” 客户服务领域中有效使用 “think” tool 时,性能有显著提升:
在 airline 领域,最佳性能来自将 “think” tool 与优化后的 prompt 配对,该 prompt 给出了在分析客户请求时应使用的推理方法示例。下面是优化后 prompt 的一个示例:
特别有意思的是不同方法之间的对比。将 “think” tool 与优化后的 prompt 结合使用,相比 extended thinking mode 取得了显著更好的结果(extended thinking mode 的表现与未加 prompt 的 “think” tool 相近)。单独使用 “think” tool(不加 prompt)相较 baseline 提升了性能,但仍低于优化后的方法。
“think” tool 与优化 prompting 的组合以明显优势取得了最强性能,这很可能是因为 benchmark 中 airline policy 部分复杂度较高,模型从如何进行 “think” 的示例中获益最大。
在 retail 领域,我们也测试了多种配置,以了解每种方法的具体影响。
即使没有额外 prompting,“think” tool 也取得了最高的 pass^1 分数 0.812。与 airline 领域相比,retail policy 明显更容易处理;Claude 仅通过拥有一个思考空间,在没有进一步指导的情况下就能提升表现。
我们的详细分析揭示了几个模式,可以帮助你有效实现 “think” tool:
在评估 Claude 3.7 Sonnet 时,我们也在 SWE-bench 设置中加入了一个类似的 “think” tool,这为其达到 0.623 的 state-of-the-art 分数做出了贡献。改写后的 “think” tool 定义如下:
我们的实验(使用 “think” tool 的样本 n=30,不使用的样本 n=144)显示,单独加入该 tool 的效果平均带来了 1.6% 的性能提升(Welch's t-test: t(38.89) = 6.71, p < .001, d = 1.47)。
基于这些评估结果,我们确定了 Claude 最能从 “think” tool 中受益的具体场景:
为了充分发挥 Claude 中 “think” tool 的作用,我们基于 τ-bench 实验建议采用以下实现实践。
最有效的方法是提供清晰的指令,说明何时以及如何使用 “think” tool,例如 τ-bench airline 领域中使用的指令。提供针对特定用例的示例,可以显著提升模型使用 “think” tool 的效果:
我们发现,当关于 “think” tool 的说明较长和/或较复杂时,将其放入 system prompt 中,比放在 tool description 本身更有效。这种方法提供了更广泛的上下文,并帮助模型更好地将思考过程整合到其整体行为中。
虽然 “think” tool 可以带来显著提升,但它并不适用于所有 tool use 用例,并且会增加 prompt 长度和输出 token。具体而言,我们发现 “think” tool 在以下用例中没有带来任何提升:
“think” tool 是对 Claude 实现的一项直接补充,只需几个步骤就能带来有意义的提升:
最好的一点是,从性能结果来看,添加这个 tool 的负面影响很小。除非 Claude 决定使用它,否则它不会改变外部行为,也不会干扰你现有的 tools 或 workflows。
我们的研究表明,在需要遵循政策并在较长 tool call 链中进行推理的复杂任务上,“think” tool 可以显著提升 Claude 3.7 Sonnet 的性能1。“Think” 不是放之四海而皆准的方案,但在正确的用例中,它能以很低的实现复杂度带来显著收益。
我们期待看到你如何使用 “think” tool,通过 Claude 构建更有能力、更可靠、更透明的 AI 系统。