模式矩阵 /模式白皮书/R1

R1 · Chain-of-Thought · 思维链

它解决什么问题

模型给出一个结论，但没人知道它是怎么得出来的。结论对的时候没人追问，结论错的时候无法 debug，监管来查的时候拿不出依据。Agent 跟传统软件最大的差别之一就是这种"灰盒性"——它不是黑盒，也不是真白盒，中间这层推理过程如果不落下来，出事时根本无法 root-cause。

Chain-of-Thought 把这段推理过程从模型内部拽出来，变成 trajectory 里的一等数据。在 2026 年，它已经不是 2022 年那句 "Let's think step by step" 的 prompt 技巧——reasoning model 本来就会 emit 推理过程，工程层要做的是管理这段过程的生命周期：怎么落库、怎么审计、跨模型 fallback 时怎么迁移、按任务复杂度怎么控制深度。一句话概括这个转变：写 Agent 不写 CoT trace，等于写后端不打 log。

为什么坐标是「推理 × 链式」

• 纵轴 · 推理：CoT 把"为什么"显性化，让模型把思考过程写出来，是纯推理领域的原点模式。推理模块其他 4 个模式（路由、并行、迭代、双模）都在 CoT 这条基线上做不同方向的扩展。
• 横轴 · 链式：推理本身是一条线性 trajectory，从输入走到输出，中间每一步都依赖前一步（思考 → 中间结论 → 最终答案）。这是天然的链式结构，不是并行撒网，也不是循环迭代。

核心机制

CoT 在 2026 年是一个多形态的工程范畴，核心是把推理 trajectory 当结构化数据管理，而不是看完即弃。落地时有四件硬责任：

1. 持久化：thinking blocks 进 trajectory log，按 trace_id 索引，结构化存储，支持重放、回滚、跨 session 迁移。
2. 跨模型归一：不同 reasoning model 的标签格式各异（OpenAI 用 <reasoning>、DeepSeek 用 <think>、Anthropic 用结构化字段）。入库前 normalize 成统一 schema，Agent 看到的永远是格式一致的 trajectory，审计时也只需要看一种结构。
3. 跨模型 fallback strip：thinking block 的签名跟生成它的模型绑定。主模型限流切到 fallback 模型时，fallback 模型不接受其他模型的签名，必须先 strip 掉所有不兼容的 thinking block 再发，否则整个请求被拒、Agent 调用失败。
4. effort 控制：thinking 是付费 token，但更多 thinking 不一定更高质量。给一个 effort 控制曲面（off / low / medium / high / max），让简单任务用 low、复杂任务用 high。

一个值得注意的边界：reasoning model 对自己 CoT 的控制力很弱，写出来的推理也可能是事后补的"剧本"而非真实推理路径。所以 CoT 是有用的可观测性信号，但不能 100% 当成模型的真实思考过程，关键决策要再加一层外部验证。

适合的生产场景

• 多跳逻辑、需要解释的判断：理赔审核、合同风险识别、信贷决策，每个结论都要能向监管解释"依据是什么"。
• 合规留痕场景：金融、医疗、法律领域要求决策的完整 reasoning 长期留档，CoT trace 是这条合规底线的载体。
• 教学与调试场景：反例——这类场景反而该让 thinking 显式可见，把推理过程暴露出来是加分项。

容易出错的地方

• 给 reasoning model 硬加 step instruction：模型自己已经在 think，再喂"请逐步分析"反而打乱推理、多烧 token。Wharton 2025 的实证显示这种加法在 reasoning model 上几乎无效甚至变差。
• fallback 时不 strip thinking：主模型挂掉切 fallback 时不清理跨模型签名，整个请求被拒、Agent 调用失败。这种 incident 平时不暴露，一旦主模型限流就集中爆发。
• trace 只写日志文件：监管要"调某月某日那件 case 的完整 reasoning"时，散在日志文件里的 trace 翻不出来。要结构化进 OpenTelemetry / Datadog，按 trace_id 可查。
• 所有任务一个 effort 跑：简单任务（"今天周几"）和复杂任务（"这份合同有什么风险"）用同一个 effort，既浪费了简单任务的 token，又委屈了复杂任务的质量。
• 延迟敏感场景开 thinking：用户输入要在 200 毫秒出回应的场景，extended thinking 会引入秒级延迟，应该关掉或用 effort=low。

关键指标

• Reasoning Token 占比（健康区 30-60%）：thinking token 占总 token 的比例。p99 高于 80% 说明在 over-thinking 简单 case 浪费成本，低于 20% 说明在 under-thinking 有准确率风险，任何方向超阈值都该告警。
• fallback strip 成功率（健康区接近 100%）：主模型切 fallback 时正确清理跨模型 thinking 的比例。低于 100% 意味着存在会让 Agent 调用直接失败的隐患。
• trace 可回查率（健康区 100%）：任意一条历史决策能按 trace_id 调出完整 reasoning 的比例。合规场景这是硬性要求。

最小骨架

任务进来 → 按复杂度选 effort 档（off / low / medium / high / max）
模型 emit thinking blocks → normalize 成统一 schema → 进结构化 trace
若主模型限流 fallback：
    strip 掉所有跟目标模型不兼容的 thinking block，再发请求
审计取数双视图：
    监管视图  → 完整 thinking + 最终决策 + fallback 链
    客户视图  → 仅脱敏摘要，不暴露 reasoning 细节
返回 final_answer + 完整 trace（按 trace_id 索引，长期留档）

落地四个要点：reasoning model 不要再加 step instruction；effort 控制做成 per-request / per-task 配置；标签归一要随新模型持续扩展；trace 打到结构化 trace bus 支持长周期回查。

企业落地一例

某企业级执行型 Agent 团队（梁博团队）在落地时发现一个分水岭：思维链不是"多写一段思考给用户看"，而是每次调用产出一个可被程序消费的 Decision 控制信号。具体做法是把模型输出拆成 thinking 和 answer 两段——thinking 段是推理过程进 trace 留档，answer 段是结构化的 JSON 决策对象，被下游程序直接解析执行。两段分离之后，CoT 从"内容"变成了"控制流"：answer 里的字段直接驱动后续动作，thinking 里的过程供审计回查。

关键的工程兜底是 JSON 解析失败时有确定性回退——模型偶尔会把决策写得不符合 schema，这时不是让 Agent 崩溃或随机重试，而是落到一个预定义的安全默认动作上。这套设计是从"内容型 Agent"（生成文本给人读）走向"执行型 Agent"（产出信号给程序用）的关键。配套决策还包括 thinking 完整留档备审、answer schema 强校验、解析失败计数接入监控。

与其他模式的关系

• 复杂度路由（R2）：CoT 的 effort 控制是按任务深度调推理档位，路由是按任务复杂度选模型档位，同源思路，从单次调用提升到任务级。
• 并行探索（R3）：并行的每一条分支内部通常就是一条思维链，并行是在 CoT 之上叠加的"多采样"。
• 迭代假设验证（R4）：迭代的每一轮也是一条思维链，迭代是把多条思维链在时间维度串起来反复修正。
• 双模架构（R5）：Reasoner 那一侧的深度推理本质就是一条完整思维链，Talker 那一侧则刻意不做深推理。

一句话记住它

Chain-of-Thought 在 2026 年的本质不是"教模型想"，而是把模型已经在想的过程当成一等数据来管理——它是 Agent 时代可观测性的根基，不是可选项。

本页属于 ADPS 33 模式白皮书。返回 模式矩阵与白皮书目录， 或查看配套 可运行代码目录。