第 4 章 推理与多步骤任务

学习目标

• 说明推理模型、推理 token、推理强度对质量、成本和延迟的影响。
• 根据任务类型与延迟要求选择推理强度，并用评估确认选择。
• 根据推理模型特点调整指令层次，要求可验证的依据，而非思考过程。
• 将多步骤任务拆成分步提示词，设计步骤之间的输入输出契约和关卡。
• 识别拆分反而不利的情况，区分并行与顺序执行。

引言

一家营销代理公司在生成广告文案的提示词中，加入了“逐步仔细思考”，并将推理强度设为最高。结果略有改善，但每次回答都要花几十秒，账单金额也变成了原来的三倍。另一方面，合同审查功能为了追求速度，采用低强度一次性处理，却常常在三个或更多条件相互交织的条款上判断出错。广告团队等着模型回答，结果错过了截止时间；合同审查团队相信了错误的判断，便放过了一条有风险的条款。两个团队看似走向相反，却犯了同一个错误：没有让思考所花的成本与任务的性质相匹配。

本章先从模型“思考”究竟意味着什么，以及思考的成本从哪里产生讲起。随后依次讨论推理模型与普通模型的区别、推理强度这个调节旋钮及其调节步骤、输出上限与推理 token 的关系、适合推理模型的提示词，以及为什么不应该要求模型将思考过程写进输出。后半部分介绍如何拆分任务，包括工作流模式、步骤之间的输入输出契约、如何将自我审查转化为具体检查，以及并行、顺序执行和子智能体。深入阅读部分则讨论过度拆分的成本，以及跨越多个上下文窗口的任务。

核心概念

推理就是草稿纸

数学考试时，在草稿纸上写出解题过程的学生，比心算的学生更擅长解难题，但花的时间也更多。推理模型同样会在作答之前，在“草稿纸”上思考。Anthropic 文档解释，开启思考后，模型会重新梳理问题、尝试多种方法、检查中间结果，并放弃走不通的路线。

这张草稿纸并非免费。两家公司的文档都说明了相同的结构。

因此，决定何时使用推理、用多少，本身就是设计的一部分。还要记住：推理只是更深入地思考现有信息，不能创造上下文中没有的新事实。

推理模型与普通模型

OpenAI 指南将推理模型比作“资深同事”，将普通 GPT 模型比作“新同事”：前者只需宏观指导就能工作，后者需要明确指令。推理最佳实践又将推理模型比作规划复杂多步骤问题的“策划者”，将 GPT 模型比作快速、低成本完成明确定义任务的“执行者”，并指出多数工作流会结合二者。

Anthropic 在最新模型中使用自适应思考（adaptive thinking）。模型根据请求复杂度和推理强度设置，自行决定是否思考、思考多少；简单问题会不经思考直接回答。部分最新模型始终开启思考，无法关闭。过去扩展思考（extended thinking）使用的 budget_tokens，在 Claude Opus 4.6 和 Sonnet 4.6 中仍可使用，但已计划停止支持；在 Claude 4.7 及之后的模型中会返回 400 错误。现在，推理强度是主要调节手段。

推理强度这个旋钮

两家公司都表示，低强度有利于速度和成本，高强度有利于彻底的推理。Anthropic 文档说明，强度不仅影响思考，也影响解释文本和工具调用等所有 token；低强度下，工具调用会更少、更短。“行为信号”意味着，即使强度低，足够困难的问题仍会让模型思考，只是比高强度时想得少。需要准确上限时，应使用 max_tokens，而非强度。

还要注意，推理强度并非控制可见回复长度的旋钮。Anthropic 文档指出，部分模型中，改变强度并不能可靠地改变可见回复长度，因此长度应通过指令规定。

让推理强度匹配成本与延迟的步骤

推理强度应通过测量来选择，不能凭感觉决定。Anthropic 文档提出的最佳实践是：明确设置推理强度，对简单任务或速度重要的任务使用较低强度，在自己的任务上进行测试，并根据任务的复杂程度采用不同强度。将这些建议转化为工作步骤，就是下面的流程。

1. 按任务类型分类。 即使在同一项功能中，简单查询、固定格式的信息提取和多条件判断，也属于不同类型的任务。
2. 为每种类型规定可接受的延迟与质量下限。 要用数字写明，例如“2 秒内，准确率至少 95%”。
3. 逐一改变强度，用同一评估集运行测试（扫描）。 分别记录每个强度下的准确率、平均和最长响应时间，以及输出 token 数。
4. 选择超过质量下限的最低强度。 如果这一强度仍无法满足延迟要求，就重新审视所选模型或任务结构。
5. 如果低强度下只有特定类型的任务思考不够深入，就增加针对性指令。 Anthropic 文档举例说，当延迟要求使你必须维持低强度时，可以加入“这项任务需要多步推理，请在回答之前仔细思考”这样的针对性指令。
6. 每当更换模型，就重新进行强度扫描。 即使强度的名称相同，各个模型实际思考的量也不一样。

输出上限与推理 token

输出上限也包含推理 token。OpenAI 的 max_output_tokens 是所有生成 token 的上限，包括推理 token、可见输出和不可见的格式 token。如果设置过低，可能在推理中途截断，回复状态为 incomplete，甚至没有可见答案。OpenAI 建议初次测试推理模型时，至少为推理和输出合计预留 25,000 token，再观察用量调整。Anthropic 同样说明，max_tokens 是思考与回复文本总输出的严格上限，高强度时应留足空间。

例：输出上限设为 4,000 token，模型却用 3,600 token 进行思考。
→ 可见答案最多剩 400 token 的空间，可能写到一半就截断，甚至完全没有答案。
→ 费用按实际使用的 token 收取。

答案长度应通过指令控制，而非上限。上限用作防止思考过程无限延长的防护机制。

推理模型的提示词

面向推理模型，应提供目标，而不是详细规定思考步骤。OpenAI 文档建议，给出明确的目标、严格的约束和清楚规定的输出格式，但不要替模型安排每一步。其推理最佳实践进一步解释，推理会在模型内部发生，因此“逐步思考”之类的措辞没有必要，有时甚至会降低性能。Anthropic 文档同样指出，“充分思考”这样的一般性指令，在许多情况下反而比人手写出的分步计划带来更好的推理。

OpenAI 文档强调，对于智能体任务或调查任务，应明确什么才算“完成”，以及模型应如何验证自己的结果。Anthropic 文档也建议，为调查任务设定清楚的成功标准，并要求模型通过多个来源核实信息。任务的范围越开放，就越需要在提示词里写明结束的条件。

不要求在输出中书写思考过程

在模型尚未具备内置思考功能时，“先写思考再给答案”是一种常见技巧。Anthropic 文档指出，即使现在，思考关闭时仍可将其作为替代方法；但开启思考的最新模型情况不同。要求在回复文本中重现内部推理，可能得到 stop_reason 为 refusal、类别为 reasoning_extraction 的响应。官方文档列出的常见诱因如下。

• 要求回答前先填写的 <thinking>、<reasoning> 或草稿区。
• JSON 输出或工具输入中的 reasoning、thinking、trace 字段。
• 要求模型持续记录私人笔记或推理记录的指令。
• 要求原样或完整写出推理。

这些措辞不仅可能在系统提示词中，也可能藏在工具说明中。此类拒绝错误没有推荐的备用模型，因此应修改提示词，而非重试。不过，仍然可以获取依据：要求简短解释、支持结果的证据，或已执行工作的摘要即可。想了解模型如何推理，可将 display 设为 summarized，阅读思考块摘要。审核者需要确认的是支持结论的依据、采用的假设和可核对的计算，而非思考痕迹。

任务分解与工作流模式

将长任务拆解为多次连续调用，而非让模型一次完成，这种模式称为提示词链。Anthropic 的智能体设计文章建议从最简单的解法开始，仅在必要时增加复杂度，并归纳了以下常见模式。

自适应思考与子智能体协调，已经让大部分多步推理可在模型内部完成，因此并不总需要链式调用。Anthropic 文档指出，显式链式调用仍适用于需要检查中间结果，或必须强制特定流水线结构时。拆成独立调用，可以逐步记录、评估和分支，也能插入人工审批等关卡。

分步输入输出契约

拆分后，应像约定契约一样，确定步骤之间传递什么。没有契约，前一步稍改格式，后一步就可能崩溃，依据也可能在中途丢失。

原则有三条。第一，只传递下一步所需内容，但依据位置（文档号、段落号）要保留到最后。第二，关卡尽可能通过代码检查。第三，每步标明第 1 章的任务类型，避免在提取步骤中发生润色。契约尤其能防止错误传播。提取时读错一个数字，后续步骤会基于该数字构建流畅的逻辑，只看最终文档的审核者难以发现错误。每步留下附原文位置的中间产物，结果出错后，就能从错误开始的步骤重新执行，不必全部重跑。

将自我审查变成具体检查

最常见的链式调用模式是自我审查。Anthropic 文档建议，将生成草稿、对照标准审查、按审查结果修改三个步骤，各自拆成独立调用。

调用 1：用包含检查清单的指令生成草稿
调用 2：按同一检查清单逐项审查草稿（通过/失败及位置）
调用 3：只修正失败项目，生成修订稿

“再检查一下”这种笼统请求效果较弱。应写明需求遗漏、数值与原文是否一致、例外条件和反例，以及“哪些情况不需要改”。若缺少最后一项约束，审查阶段甚至会误改原本正确的内容。如果只能一次调用完成，可补充“结束前按 [测试标准] 检查答案”。但 Anthropic 文档也警告，部分模型无需指令就能很好地验证自身工作，旧模型用的验证指令可能造成过度验证。应规定修改次数上限，达到上限后标明剩余问题并交给人工。

并行、顺序与子智能体

互不依赖的任务可以同时处理，必须使用前一步结果的任务则要依次处理。Anthropic 文档解释，最新模型会并行执行相互独立的工具调用，这种行为也可以通过指令来调节。文档给出的示例指令要求：不存在依赖关系的调用全部同时执行；如果某次调用的参数要由前一次调用的结果决定，则依次执行，不能猜测缺失的参数，也不能用占位符把它们填上。并行执行可以减少延迟，顺序执行则保障准确性。区分二者的标准，就是是否存在依赖关系。

子智能体是更大单位的并行处理。子智能体在干净的上下文中专注于一项任务，只返回摘要，因此擅长范围广的调查，但成本也高。Anthropic 关于多智能体调查系统的文章报告，智能体的 token 用量约为聊天的 4 倍，多智能体系统则约为 15 倍；文章还解释，他们为简单的事实核查设立了规则，使一个智能体加上 3～10 次工具调用就足以完成任务。Anthropic 文档也提醒，部分模型会创建过多的子智能体，并提供了这样的示例指令：只将可以并行执行或需要隔离上下文的独立任务交给子智能体，简单任务和必须依次完成的任务应由模型直接处理。

深入阅读

过度拆分的调用链成本

认为只要拆分就会改善结果，是一种危险的想法。每个步骤都会产生往返延迟，步骤之间会切断部分上下文，需要管理的提示词数量也会增加。OpenAI 的延迟优化指南解释，将原本依次执行的步骤合并成一次提示词请求和一次响应，可以消除这些往返延迟。不过，指南也指出，如果大部分工作都可以交给小模型，拆分方案也可能胜出，因此建议用实际运行中的样本，同时测试这两种方式。同一份指南还说明，与减少输入 token 相比，减少生成的 token 对延迟的影响要大得多。

判断是否拆分，可问以下问题。

跨多个上下文窗口的长任务

跨越好几天的工作，无法全部容纳在一个上下文窗口中。Anthropic 文档建议，在第一个窗口中建立框架，例如测试和准备脚本，然后在后续窗口中反复执行待办列表。测试等结构化状态，用 JSON 等格式固定的文件记录；进度笔记，用自由文本记录；工作历史，则用 git 留存。每个新窗口都从先读取这些记录的流程开始。有些情况下，与其压缩上下文，不如在新窗口中通过文件恢复工作状态。文档还建议，从一开始就清楚写明：不得通过删除或修改测试，制造测试通过的结果。

工作场景

坚实金属：分步完成报价比较报告

精密零件制造商“坚实金属”的采购团队，正在使用一项功能：比较原材料供应商的报价单，并起草采购请示。不同供应商使用不同的报价单格式，每笔采购会收到四五份报价单。目前，团队将所有报价单放在一起，以高推理强度，一次性要求模型“进行比较并撰写请示”。请示中的文字虽然流畅，上个月却有两次将单位为 kg 的报价与单位为吨的报价，按同一个单位进行比较，推荐了错误的供应商。团队负责人只看采购请示，没有察觉到错误。

采购团队的郑主管将这项工作拆成三个步骤，并为各步制定了输入输出契约。

1. 提取（低强度）。 对每份报价单，使用结构化输出提取供应商、商品、单价、单位、交期和有效期。每个项目同时保留它在报价单中的页码。单位按原文的写法保留。
2. 关卡（代码）。 用代码按照换算表转换并统一单位；对于缺少必需项目的报价单，退回经办人处理。如果出现换算表中没有的单位，就停止。
3. 比较与撰写（高强度）。 输入统一后的表格，以及公司内部采购标准（价格、交期、交易历史各自的权重），先获取对每家供应商的判定及其依据页码，再撰写采购请示草稿。

最后，再增加一次自我审查调用，使用同一份检查清单。清单的内容是：“推荐供应商的单价是否是表格中的最低价；如果不是，给出的理由是否在标准表中”“所有数值是否都有页码”“是否推荐了已超过有效期的报价”。他还写明，对于不需要修改的项目，不要改动。

郑主管放弃了两个方案。第一个仍是一次性处理，只是用粗体加入“注意单位”。这一方案没有改变提取错误被最终文字掩盖的结构，所以没有采纳。另一个方案是进一步细分成五步，但这样会出现无人查看中间结果的步骤，只增加延迟，因此他将步骤数停在三个。各步骤的强度也分别决定。提取属于固定格式的任务，在评估集上，低强度的准确率与高强度相同；比较涉及多个相互交织的标准，只有在高强度下才能超过质量下限。

用过去三个月的 40 组报价进行比较测试后，所有单位混淆都在关卡处被检出，每笔采购的处理成本反而减少了。这是因为提取步骤变得更便宜。采购请示附上页码后，团队负责人的审核时间也减少了。

佳岚市青年就业中心：不同问题，不同思考量

“佳岚市青年就业中心”运营着一个咨询机器人，回答青年求职者的问题。这些问题大致分为三类：营业时间、位置之类的简单说明，培训项目日程查询，以及补助资格判断。资格判断涉及年龄、居住时间、收入、是否与其他补助重复等相互交织的条件。最初，所有问题都以最高推理强度处理，结果连询问营业时间的问题都回答得很慢，许多用户因此关闭了窗口。

负责此事的河专员决定对问题进行路由。先通过一次轻量的分类调用确定问题类型，再将问题发送到各类型专用的处理路径。简单说明从事先写好的答案列表中选择，尽量减少模型生成。日程查询则调用日程工具，再简短整理返回的结果。资格判断会输入资格标准表和用户填写的条件，获取判定、作为依据的条款，以及缺少的信息清单。

推理强度通过扫描来确定。他为每种类型分别编写了 60 个评估问题，先写下延迟下限与质量下限要求。

在资格判断中，中等强度已经超过准确率下限，但错误集中在四个或更多条件相互交织的问题上。河专员选择提高强度，因为允许的响应时间比较充裕，而且错误的资格说明会使用户错失申请机会。他还删除了旧提示词中残留的“把全部思考过程写入 <思考> 标签”这句话，改成“简短写出判定所依据的标准表条款编号，以及用户的条件”。咨询人员需要核查的是依据，而不是思考留下的痕迹。

审查会上，有人提出：“如果问题类型分错了怎么办？”河专员便设立了一条默认规则：没有把握分类时，发送到资格判断路径。因为与给出错误说明相比，宁可让错误发生在响应较慢的方向。投入使用后，简单说明的回答速度提高到了用户明显能够感受到的程度，资格判断的准确率也保持不变。他还在运行规则中写明，每次更换模型，都要用同一批评估问题重新进行强度扫描。

易错点

• 最高强度始终最佳。 对简单、大批量任务，它只会增加延迟与成本。应按任务选择并通过评估确认。
• 一句“逐步思考”就够了。 对推理模型可能无用甚至有害，也无法满足各类任务的延迟与准确率要求。
• 把思考过程写进正文就能验证。 可见思考只是摘要，最新模型开启思考时，重现推理的请求可能被拒绝。应要求依据、假设和计算。
• 降低输出上限就能缩短回答。 推理模型可能在推理中途截断，返回空答案。长度应通过指令规定。
• 拆得越细，质量越高。 无人查看的中间步骤只增加延迟和维护成本，应与一次处理版本比较。
• 用子智能体总会更快。 它会大幅增加 token 用量，简单查询反而更慢。
• 以为存在依赖关系的工具调用也能通过并行来提速。 需要前一步结果的调用若同时执行，模型就只能猜值。

要点速览

查阅官方文档

• OpenAI — Reasoning models：阅读强度取值、推理 token 计费、max_output_tokens，以及至少预留 25,000 token 的建议。
• OpenAI — Reasoning best practices：阅读推理模型与 GPT 模型的分工及提示词建议。
• Anthropic — Effort：阅读各强度说明、与工具使用的关系及最佳实践。
• Anthropic — Refusals and fallback：阅读 reasoning_extraction 拒绝的原因与替代方法。
• Anthropic — Prompting best practices：阅读 “Thinking and reasoning”“Chain complex prompts”“Subagent orchestration”“Optimize parallel tool calling” 几节。
• Anthropic — Building effective agents：阅读工作流模式及各自适用情境。

自测

4-1. 写出推理 token 对成本和上下文的两项影响，并解释思考块可见文本与原始思考过程的区别。

4-2. 解释 Anthropic 的 effort 是“行为信号，而非严格的 token 预算”意味着什么，并回答需要准确输出上限时应使用什么。

4-3. 将公司文档检索助手的问题分为简单查询与比较分析两类，分别确定推理强度。请按顺序写出选择强度的步骤。

4-4. 推理模型请求把输出上限设得较小，返回的可见答案为空。解释原因，并写出两种应对措施。

4-5. 普通模型的提示词包含“第 1 步读题……第 7 步写答案”的流程及“逐步思考”。迁移到推理模型时，应保留什么、改变什么？

4-6. 有人提出在评估结果 JSON 中设置 thinking 字段，以长文本形式获取判定理由。解释最新模型开启思考时可能出现的问题，并提出一种保留原目的的其他字段设计。

4-7. 新产品发布新闻稿按（甲）从产品规格书提取事实、（乙）与竞品比较、（丙）撰写新闻稿三步制作。请写出分步输入输出契约表，并提出一个放在步骤之间的关卡。

实操练习