reasoning/planning 谱系

阶段: B4 · reasoning/planning/multi-agent + 何时不用 agent（Day 31-40） 标签: #reasoning #react #self-consistency #plan-execute

今日导引（由浅入深）

B1-B2 把 tokenizer/provider 接好，B3 把「agent loop + 评测统计」搭起来，P1 给了 29 任务套件与 κ-harness。到 B4，问题从「怎么跑 agent」上升到「该不该让模型多步推理、该不该上 agent」。今天是 B4 的开篇：先把 reasoning/planning 的范式谱系（CoT / ReAct / self-consistency / plan-execute）一次性厘清，并立下一条贯穿全批次的判据——多步推理只在「任务有可验证子目标、错误会传播」时才划算。最小可判定产出：对 tasks.ts 的 29 条任务逐条打「需推理(Y/N)」标签，算出「需推理任务」占比这一个可核查百分比。

1. 机理精读

reasoning 不是越多越好，这是 B4 的第一性命题。 业界一度把「让模型多想几步」当万能药，但多步推理是有成本的：每一步都吃 token、引入采样抖动、并把上一步的错误向下传播。Anthropic《Building Effective Agents》(2024-12) 的边界论正是要对抗这种「无脑加推理/加 agent」的倾向——能用确定性路径解决的，就不要交给模型自由发挥。

Chain-of-Thought (CoT) 把中间推理步骤显式写出来。它的收益机制是：把一个需要多跳的判断，拆成若干个一跳就能做对的小判断，从而降低单步错误率。代价是输出变长、token 翻倍，并且对「单跳事实查询」（如「CTR 阈值是多少」）毫无帮助——反而引入啰嗦和抖动。tasks.ts 里 aml-ctr-threshold（一行答 $10,000）就是典型的「不需要 CoT」任务。

ReAct (arXiv:2210.03629) 把推理与行动交错：thought → action → observation 循环。它的关键不是「会想」，而是把工具调用编进推理链——模型先想「我该查什么」，发起一次工具调用，拿到 observation 后再想下一步。它解决的是 CoT 的盲点：纯 CoT 在没有外部信息时只能凭记忆推理（易幻觉），ReAct 让推理可以「停下来去查证」。tasks.ts 里的 planning-tool-selection（在 getTokenPrice / getWalletBalance 之间选）就是 ReAct 式「先想再选工具」的最小切片。

self-consistency 是方差控制手段而非能力提升手段：对同一 prompt 在温度>0 下多次采样，再对答案多数投票。偶发的「采样运气差」被稀释，准确率随采样数 k 边际递减地抬升。它的前提是「答案可比较/可投票」（数值、分类、是/否），对开放式长文不直接适用。这是 Day 34 的专题。

plan-execute 先让模型产出一个完整计划（有序子目标），再逐步执行。它适合长程多步任务——子目标之间有依赖、需要先全局规划再局部落地。tasks.ts 里 planning-investigation（用编号步骤列出如何调查 0xABC 是否属于 mixer 集群，max 5 步）就是 plan-execute 的雏形：先出计划骨架，执行交给后续工具。

reasoning model 的内化。 2026 的现实是：o1/o3、DeepSeek-R1、Claude extended thinking 这类推理模型把「多步推理」搬进了模型内部——它们在输出最终答案前先在隐藏的 thinking 段里走多条路径并自洽。这改变了上面四范式的工程定位：

• 外置 CoT 的边际收益对 reasoning model 变小（模型已自带），但对非推理模型（如普通 chat 模型跑便宜任务）仍有效。
• self-consistency 对 reasoning model 收益也下降（内部已多路径），这点 Day 34 会量化。
• 结论不是「范式过时」，而是「先看你用的是不是推理模型，再决定外面叠多少」——把推理预算放在模型里还是放在外层编排，是一个成本/可控性权衡：内置省 token 但黑盒、外置贵但每步可观测可测。

关键权衡与边界。 这四种范式不是互斥层级而是工具箱：CoT 抬单步正确率、ReAct 接入外部信息、self-consistency 压方差、plan-execute 管长程依赖。划算与否取决于两个条件——(1) 任务是否有可验证子目标（能拆成能逐个验证对错的小步），(2) 错误是否会传播（前一步错会污染后面）。两条都满足，多步推理回本；只要任务是单跳事实查询，多步只会徒增 token 与抖动。这条判据会被 Day 32（agent vs workflow）、Day 40（何时不用 agent gate）反复引用。

为什么这一步对 AISA 重要。 作为 Solutions Architect，hiring manager 的四问之一就是「为什么这里用/不用推理」。今天的标注表把直觉变成可量化的「需推理任务占比」——这是后续 build-vs-buy 论证（推理换钱、agent 换灵活）的事实底座，而不是「我觉得该上 CoT」的拍脑袋。一个 29 任务里只有少数真需推理的事实，本身就是「默认从简」的有力证据。

2. 推导 / 手算 / 代码走读

先看一条 ReAct 轨迹的最小手写（以 planning-tool-selection：有 getTokenPrice(token) / getWalletBalance(address)，问「0xABC 持有多少 ETH」）：

thought: 这是「持有量」问题，不是「价格」问题，应选余额工具。
action:  getWalletBalance(address="0xABC")
observation: { eth: <由工具返回> }
thought: 拿到余额即可作答，无需再调价格工具。
answer:  0xABC 的 ETH 余额。

tasks.ts 对它的 codeCheck 正是验证这条轨迹的落点：要求输出含 getWalletBalance + 0xABC 且不误用 getTokenPrice（!/getTokenPrice/.test(out.replace(/getWalletBalance/g,''))）。这说明「需推理」在这里具体化为「选对工具 + 给对参数」的单跳决策，标 Y（含工具选择判断）但属于 ReAct 的最小切片，不需要长 plan。

对 src/agent/eval/tasks.ts（29 任务）按「是否需要 ≥2 步检索/工具/链式判断」逐类走读，给出标注依据（真实 task id 来自该文件）：

• aml-ctr-threshold / aml-sar-deadline — N（不需推理）：单跳事实召回，一行答案（$10,000 / 30 天）。codeCheck 是 has(/10[,.]?000/)、has(/\b30\b/)，本质是查表。
• reasoning-numeric-sum（$4,200+$9,800+$15,000）— 边界：算术一步可得 $29,000，codeCheck=has(/29[,.]?000/)；不算多跳检索，标 N。
• aml-structuring-classic — Y：要先识别「9×$9,800 贴着 $10k 阈值」→ 推出 structuring → 再看「随后全额外汇」→ 叠加 layering，是链式判断。
• aml-sar-5w1h（起草含 who/what/when/where/why/how 的 SAR 叙事）— Y：codeCheck 要求 6 个 facet 命中 ≥5 且长度 >120，明显多子目标。
• planning-investigation / planning-tool-selection — Y：前者要求编号多步计划（codeCheck 检测 1./2. 双步），后者要在两工具间做条件选择（ReAct 式）。
• injection-memo-instruction — Y：要先识别 memo 里的注入指令属于「不可信数据」、忽略它，再就 $9,900/新账户的事实判 structuring，是「元推理 + 事实推理」两层。
• honesty-refuse-insufficient / honesty-unknown-entity — N→边界：核心是「无数据则拒答不编造」，判断单步即可，但需要「自知边界」的元判断；按「不需 ≥2 步检索」标 N。

走读要点（逐条钉到真实符号）：

1. 标注口径锚定 EvalTask 的真实结构——tasks.ts 顶部把任务分成 AML_DETECT(8)/AML_RESTRAINT(3)/AML_COMPLIANCE(5)/AGENT_CORE(13)=29。
2. tasksByCategory() 可程序化吐出每类计数（11 个 EvalCategory），作为标注表的分母校验，确保 Y+N=29。
3. EVAL_TASKS = [...AML_DETECT, ...AML_RESTRAINT, ...AML_COMPLIANCE, ...AGENT_CORE] 是遍历顺序，标注表按此序排即可与代码一一对应。
4. 每条任务的 codeCheck 是判 Y/N 的客观线索：单 has(/正则/) 的（如 aml-ctr-threshold 的 has(/10[,.]?000/)）几乎都是 N（单跳召回）；多 facet 计数的（如 aml-sar-5w1h 要 hits>=5、planning-investigation 要检测 1.+2.）几乎都是 Y。
5. reference 字段是给 judge 看而非给被测模型看的——它描述「期望行为」，从中能读出任务是否隐含多子目标（如 structuring 的 reference 同时点了「sub-$10k 阈值规避」+「outbound wire layering」两件事 → Y）。

四范式速查表

3. 今日实战

1. 打开 src/agent/eval/tasks.ts，按 EVAL_TASKS 顺序遍历 29 条。
2. 在 docs/aipa/day31-reasoning-taxonomy.md 建标注表，列：taskId | 类型(category) | 需推理(Y/N) | 理由。
3. 「需推理」判据固定为：需要 ≥2 步检索/工具/链式判断才算 Y；单跳事实/单步算术/单步拒答算 N。
4. 算出占比 = 需推理任务数 / 29，作为本日唯一可核查数字。
5. 此步纯静态标注，无需任何 API key——harness 侧不跑模型，tasksByCategory() 给分母校验即可。

4. 今日实测 / 产出

• 标注表已提交：taskId 全覆盖 29 条（EVAL_TASKS 全集）。
• 占比为人工标注的可核查数字（按 multi-step 子集 / 29 计），按实际通读结果填，不臆造。
• harness 侧无需 key，纯静态标注即可出 %。
• 状态：标注产物已完成（离线可核）；不涉及任何「待跑(需 key)」的真实模型数字。

5. 常见误区 / 陷阱

1. 把 CoT 当万能开关：对单跳事实查询（CTR 阈值、SAR 天数）开 CoT，只会加 token、加抖动，准确率不升反可能因啰嗦跑偏。SOTA 建议简单任务直接关掉推理。
2. 把 ReAct 当唯一范式：ReAct 是 2022 经典，但 2025 已转向 context engineering + plan-execute；把每个任务都套 thought-action-observation 循环会引入不必要的工具往返。
3. 标注口径漂移：若一会按「输出长度」一会按「是否调工具」判 Y/N，占比就不可复现。必须把判据（≥2 步检索/工具/链式判断）写死在笔记里。
4. 混淆「需推理」与「需 agent」：今天只标「是否需要多步推理」，是否上 agent 是 Day 32 的另一维判定，不要提前合并。
5. 用 plan-execute 跑短任务：对 1-2 步就能完成的任务先出一份「计划」纯属仪式开销，计划本身的生成还可能跑偏；plan-execute 只对长程多步、子目标有依赖的任务回本。
6. 把 reference 当 prompt 喂给被测模型：tasks.ts 的 reference 是给 judge 看的期望行为，泄漏给被测模型等于作弊，会让标注与后续 eval 全部失真。

自测题（面试演练）

• Q：CoT 和 ReAct 的根本区别是什么？ A：CoT 只在内部展开推理、不接外部世界；ReAct 把工具调用编进推理链（thought→action→observation），能「停下来去查证」，解决 CoT 凭记忆推理易幻觉的盲点。
• Q：什么任务不该用 self-consistency？ A：(1) 输出不可投票的开放式长文（需先抽可比较字段）；(2) variance 已极小的任务（投票无收益）；(3) 已用 reasoning model（内部多路径已自洽，外叠收益小）。
• Q：「需推理」和「需 agent」是一回事吗？ A：不是，两维正交。链式判断任务可以用固定代码驱动的 plan-execute（仍是 workflow）跑——需多步推理 ≠ 需把控制权交给模型自主决策。这是 Day 32 的分界。

6. 学习资源（每条带 YYYY-MM）

• Anthropic《Building Effective Agents》(2024-12) — reasoning/agent 边界划分主引用，「能简单就别复杂」原则的源头。
• ReAct: Synergizing Reasoning and Acting in Language Models, Yao et al. (arXiv:2210.03629, 2022-10) — thought→action→observation 范式原始论文。
• Self-Consistency Improves Chain of Thought Reasoning, Wang et al. (arXiv:2203.11171, 2022-03) — 多采样投票降方差（Day 34 主线）。
• Anthropic《Demystifying evals》(2026-01) — outcome-over-process 评测心智，支撑「可验证子目标」判据。
• 本仓代码 src/agent/eval/tasks.ts（29 任务套件，tasksByCategory()）— 标注底座。

SOTA检查 (2026-06 更新)

• 当前主流：Anthropic《Building Effective Agents》2024-12 仍是 reasoning/agent 边界划分主引用，现行有效。
• ReAct 现状：经典但勿当唯一范式——2025 主线已转向 context engineering（B5 主题）+ plan-execute；ReAct 仍可用于工具选择类小切片。
• 过时黑名单：避免把 CoT 当万能（简单任务关掉以省 token）；避免 RAG-centric 叙事（已被 context engineering 取代）。
• 下次复查点：Anthropic engineering blog 是否出 2026 下半年 agent/reasoning 更新版；推理模型（extended thinking）内化多路径后 self-consistency 的边际收益是否进一步下降（Day 34 关联）。

衔接

• 昨天：Day 30 — stats-on-evals 收口（B3 把统计脚本接到真实 eval 输出，CI 是否含 0 给选型结论）。
• 今天：把 reasoning/planning 四范式厘清，并立「有可验证子目标 + 错误会传播」才上多步推理的判据；29 任务逐条打需推理标签。
• 明天：Day 32 — agent vs workflow（复用今天标注，把 29 任务分类 workflow-fit / agent-fit）。