reasoning_strategy进阶约 85 分钟

推理不是越长越好：为任务选择正确的思考方式

参考：来源 F · 第 17、22 章

学完你能做到

区分直接回答、分解、ReAct、计划执行、反思与多路径搜索
知道什么时候增加推理时间，什么时候应直接调用工具
设计可审计的决策记录，而不是要求模型公开私有思维过程

同一个问题可以有不同的求解方式。查日期只需一次检索；写研究报告要先拆题、找证据、比较冲突信息，再检查结论。Agent 工程真正要做的不是永远让模型“多想一会儿”，而是建立一套按任务难度选择推理策略的规则。

策略	适合什么任务	主要代价	必须留下什么证据
直接回答	低风险、答案稳定、一步可完成	最低	最终答案或数据来源
问题分解	问题包含多个子问题或依赖	上下文与调用次数增加	子问题清单、完成状态
	下一步取决于工具返回结果	可能循环或跑偏	工具名、参数、观察结果
计划后执行	目标清楚但步骤较长	计划可能过时	计划版本、当前步骤、重规划原因
反思/评估循环	有明确质量标准，可反复改稿	延迟和费用增加	评分标准、缺陷、修改记录
多路径搜索	答案空间大、错误代价高	费用最高	候选方案、淘汰理由、最终验证

策略不是能力排行榜。复杂方法只在它能降低错误时才值得使用。

先按任务复杂度和风险选策略，再决定投入多少推理、工具调用与验证预算。

一个可实现的策略路由器

if risk == low and steps == 1:
  answer_directly()
elif evidence_needed:
  retrieve_then_answer()
elif outcome_depends_on_tool_result:
  run_react_loop(max_steps=6)
else:
  plan_execute_verify(budget)
log(decisions, tool_calls, evidence, stop_reason)

策略分诊练习

15 分钟

给“查今天北京天气”“分析三篇论文的共同缺陷”“删除过期订单”分别选策略。
为每项任务写出最大步骤数、必须验证的证据、何时停下来问人。
解释为什么最高风险任务不一定要使用最长提示词。

查看参考答案

天气适合检索后直答；论文比较适合分解、检索、综合和评估；删除订单必须先确定范围、预览影响并进入人工确认。

案例推演：什么时候多想有用，什么时候只是更贵

判断发票字段是否齐全只需短检查；规划一次数据库迁移却包含依赖、回滚和风险权衡。两者若使用同样的长推理策略，会浪费成本或漏掉关键步骤。

本节追问：如何根据任务难度、风险和可验证性分配推理预算？ 先不要急着看结论。沿着下面四步，逐项区分输入、决策、证据和失败信号。

四步案例推演。手机上可左右滑动查看；每个箭头都代表一次需要证据支撑的状态转换。

阶段	本步要做的决定	什么算证据	最常见的失败
任务分型	判断是直接识别、分解、搜索还是约束规划	有可描述的复杂度与风险信号	所有问题都要求“深入思考”
选择策略	简单任务直接答，复杂任务分解或搜索	策略与任务结构匹配	用自洽投票处理确定性计算
设置预算	限定候选数、深度、时间和 token	预算耗尽时有降级结果	只设总 token 不设过程边界
独立验证	用测试、规则或第二方法检查结论	验证器不依赖同一错误假设	让原模型重复说一遍当验证

阅读方式：先遮住后两列自己回答，再用“证据”和“失败”两列检查理解。

常见误解

把更长的推理文本当成更强推理

实际上

可观察症状：输出冗长但没有探索替代方案或验证。

更可靠的修复：观察任务结构，用分解、搜索和外部验证器衡量推理是否产生新信息。

案例工作坊 · 建议真正动手完成

25 分钟

把五类任务按推理预算从低到高排序。
为数据库迁移设计两个候选方案和一个验证器。
定义何时提前停止思考。

查看参考答案

推理是一种受预算约束的计算策略。应根据任务结构决定是否分解、搜索、自洽或调用验证器，而不是统一要求模型写更长的过程。

迁移检查：换一个场景还会不会

“字段是否为空”这类可确定检查最适合？

检查一下

什么情况最适合增加反思循环？

可审计日志最应该记录什么？