Think Tool：让 AI 先想后做
在复杂工具链中给 Agent 一个暂停思考的空间，τ-bench 性能提升 54%
本页解决的问题
先给结论「Think Tool：让 AI 先想后做」要解决的关键问题是什么？
在复杂工具链中给 Agent 一个暂停思考的空间，τ-bench 性能提升 54%
让这个结论先证明自己值得留下。 把这一页当成决策工具，而不是需要背下来的定义。把概念连到一个真实任务、一个可观察结果，以及一个能改变你判断的失败上。
写下一个问题：试完这个方法后，你能用什么证据回答它？
结论听起来很完整，却没有检查最关键的假设。
信息在工具链中丢失
Agent 调用了 5 个工具后，早期工具返回的关键信息被后续的大量上下文淹没，模型不再关注它。
策略密集型决策
客服场景有 20 条退款政策、6 种例外情况。Agent 需要同时考虑多条规则才能做出正确判断，但它常常只看到了最近的几条。
串行依赖决策
每一步都基于前一步的结果。Agent 在第 3 步做决策时，需要回忆第 1 步的上下文，但那已经在 2000 个 Token 之前了。
Extended Thinking
Think Tool
Think Tool 的实现简单到令人惊讶：它就是一个只接受一段文字、什么都不做的工具。
在 τ-bench（一个模拟真实客服场景的 Agent 评测基准）上测试 Think Tool 的效果：
点击下方 Tab 切换模式，然后逐步展开 Agent 的处理过程。看看有没有 Think Tool，结果会有多大差异。
适用场景
- 复杂工具链：调用 5+ 个工具，中途需要整理和重新评估
- 策略密集环境：需要同时考虑多条业务规则（如客服政策、审批流程）
- 串行依赖决策：每步决策依赖前一步结果，需要承上启下的思考
- 多轮信息聚合：从多个工具返回中拼凑完整图景
不适用场景
- 简单工具调用：查天气、读文件这类一步到位的操作，Think Tool 是多余的开销
- 非序列任务：各步骤相互独立、不需要前后关联的场景
- 已有 Extended Thinking 的场景：如果模型支持深度思考，简单任务用 Extended Thinking 更直接
- 纯生成任务：写文章、翻译等不涉及工具调用的场景
「问题场景：Agent 为什么会犯错」如何改变一次回答
「Agent 调用了 5 个工具后，早期工具返回的关键信息被后续的大量上下文淹没，模型不再关注它」说明，模型处理的不是我们眼中的“字数”，而是一段段 Token。Token 的切分方式会影响输入长度、上下文能放下多少内容，以及一次请求要花多少计算。
长度、信息量和上下文不是一回事
当「客服场景有 20 条退款政策、6 种例外情况。Agent 需要同时考虑多条规则才能做出正确判断，但它常常只看到了最近的几条」变长时，先要分清三件事：文字被切成多少 Token、哪些内容真正参与当前判断、以及旧内容是否已经超出上下文窗口。删掉重复说明通常比单纯把窗口开得更大更有效。
- 复杂工具链 ：调用 5+ 个工具，中途需要整理和重新评估
- 策略密集环境 ：需要同时考虑多条业务规则（如客服政策、审批流程）
- 串行依赖决策 ：每步决策依赖前一步结果，需要承上启下的思考
先保留会改变判断的内容
可以用「点击下方 Tab 切换模式，然后逐步展开 Agent 的处理过程。看看有没有 Think Tool，结果会有多大差异」做一次对照：保留同样的问题，分别删掉重复背景、压缩格式和移除无关历史，比较答案质量、延迟与 Token 数量。
从「问题场景：Agent 为什么会犯错」走到「什么是 Think Tool」
「问题场景：Agent 为什么会犯错」先把问题落在「Agent 调用了 5 个工具后，早期工具返回的关键信息被后续的大量上下文淹没，模型不再关注它」上；到了「什么是 Think Tool」，讨论继续推进到「一句话： Think Tool 是一个没有副作用的特殊工具。它不会查数据库、不会调 API、不会改任何状态。它唯一的作用是让 Agent 把思考过程写下来 ，强制自己想清楚再行动」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
处理长文本时，先保留会改变结论的内容，再决定如何压缩格式和历史；上下文更长只有在新增信息真正有用时才值得付出代价。
- 「问题场景：Agent 为什么会犯错」：Agent 调用了 5 个工具后，早期工具返回的关键信息被后续的大量上下文淹没，模型不再关注它
- 「什么是 Think Tool」：一句话： Think Tool 是一个没有副作用的特殊工具。它不会查数据库、不会调 API、不会改任何状态。它唯一的作用是让 Agent 把思考过程写下来 ，强制自己想清楚再行动
- 「最后的要点」：简单工具调用 ：查天气、读文件这类一步到位的操作，Think Tool 是多余的开销
最后的「最后的要点」把讨论落到「简单工具调用 ：查天气、读文件这类一步到位的操作，Think Tool 是多余的开销」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。