Chain of Thought (CoT): 思维链

思维链（Chain of Thought，CoT）

CoT 是 Chain of Thought（思维链）的缩写。

思维链是一种让大语言模型在给出最终答案之前，先逐步输出中间推理过程的提示技术，是 ReAct、Tree of Thoughts 等众多 Agent 推理框架的基础。

用一句话概括：思维链就是通过提示词告诉模型"先把推理步骤写出来，再给结论"。

一个直观的比喻：就像项目管理里不直接说"把产品做出来"，而是拆成"需求 → 设计 → 开发 → 测试 → 上线"这几个里程碑节点——CoT 提示词做的就是这件事：告诉模型"达到最终答案之前，先经过哪几个中间节点"。模型拿到这些节点后，自己填充每个节点之间的具体内容，而不是直接跳到终点。里程碑节点越清晰合理，模型走偏的概率就越低。

CoT 是提示词概念还是模型推理概念

CoT 同时横跨两个层面，两者不可分离：

• 提示词层面：在提示词里给出推理结构框架（先分析已知条件、再逐步推理、最后给结论），但不需要也不可能提前写出每一步的具体内容
• 模型推理层面：模型接收到结构约束后，在逐 token 生成 response 的过程中自己填充每一步的具体内容

关键在于：LLM 是逐 token 生成的，每生成一个 token 都会参考前面所有已输出的内容。写出推理步骤不是推理完成后的附加结果，而是推理本身的载体：

写出"步骤 1：..."  →  这段文字进入上下文
       ↓
生成"步骤 2：..."时参考步骤 1  →  推理被约束在正确方向上
       ↓
生成最终结论时参考所有步骤  →  结论更准确

如果不写出步骤，中间推理只存在于模型的隐式状态（注意力权重）里，无法作为显式上下文影响后续生成，更容易偏移。

因此，CoT 的本质是：显式约束 vs 隐式依赖：

• 不用 CoT：完全依赖模型训练出来的内部权重，简单问题通常没问题
• 用 CoT：在上下文层面施加显式约束，对复杂、多步骤任务效果提升明显

CoT 的收益与任务复杂度正相关——越复杂的推理任务，CoT 的价值越显著。

核心思想

传统 LLM 回答问题时往往直接输出结论，而 CoT 的核心是：让模型"展示思考过程"，而非直接给出答案。这模仿了人类解决复杂问题时"打草稿"的思维方式。

发展历程

对比示例

不用 CoT（直接回答）：

问：小明有 5 个苹果，给了小红 2 个，又买了 3 个，现在有几个？
答：6 个

使用 CoT：

问：小明有 5 个苹果，给了小红 2 个，又买了 3 个，现在有几个？
答：
  步骤 1：小明初始有 5 个苹果
  步骤 2：给了小红 2 个，剩下 5 - 2 = 3 个
  步骤 3：又买了 3 个，现在有 3 + 3 = 6 个
  最终答案：6 个

简单问题结果相同，但在多步骤复杂问题上，CoT 可以显著减少推理错误。

为什么有效

1. 分解复杂问题 — 将大问题拆解成一系列小步骤，降低每步的难度
2. 减少遗漏 — 每一步都被显式化，不容易跳过关键中间步骤
3. 自我纠错 — 模型在生成后续 token 时，前面的推理步骤也在上下文中，有助于发现并修正之前的错误
4. 可解释性 — 推理过程透明，便于人工审查和调试

CoT 的价值有两层：

• 对人：推理过程可见，便于审查和调试
• 对模型：显式推理步骤作为上下文，帮助模型自身减少推理偏移

Zero-shot CoT 示例

只需在提示词末尾加上一句话，即可激活模型的逐步推理能力：

def ask_with_cot(question: str) -> str:
    prompt = f"""
{question}

让我们一步一步地思考：
"""
    return llm.call(prompt)

对应的英文版本是广为流传的 "Let's think step by step"，研究表明这一简单技巧可以大幅提升 LLM 在数学推理、逻辑推断等任务上的准确率。

思维链模板（CoT Templates）

思维链是一种让模型逐步推理的技术思想；思维链模板是这一思想的工程落地形式。

两者的关系类似于"设计模式"与"代码模板"：

• 思维链（CoT）= 原理，告诉我们"让模型先推理再回答"能提升效果
• 思维链模板 = 实现，把这个原理固化成可复用的提示词结构，直接套用到具体任务中

换句话说，没有 CoT 就没有模板存在的意义；有了 CoT 但没有模板，每次都要从零写提示词，难以保证质量一致性。思维链模板是将推理结构固化为可复用提示词格式的工程实践，相比临时写一句"让我们一步一步思考"，模板提供了更规范、更可控的推理框架，便于在 Agent 系统中统一使用和维护。

使用思维链模板时，你只需要提供结构骨架（即关键里程碑节点），不需要也不可能提前写出每一步的具体内容——那是模型根据骨架生成 response 时自己填充的。不同任务类型对应不同的模板：

标准推理模板

最通用的结构，适合数学、逻辑、规划等任务：

问题：{question}

分析：
- 已知条件：...
- 需要求解：...

推理过程：
步骤 1：...
步骤 2：...
步骤 N：...

最终答案：...

使用模板时的注意事项：

提示词中只需填入 {question}（具体问题），结构骨架里的 步骤 1：...、步骤 2：... 等占位符是告诉模型"要按这个结构输出"，不需要也不可能由你提前写出具体内容——那是模型生成 response 时自己填充的。

下面是一个模型 response 的示例（即模型实际返回的内容，不是输入给模型的提示词）：

问题：一个团队有 3 名前端、2 名后端、1 名 DBA，每人完成各自模块需要 2 天，
      但后端需要等前端 API 设计完成后才能开始，DBA 可以并行开发。
      整个项目最少需要几天？

分析：
- 已知条件：前端 2 天，后端依赖前端完成后再花 2 天，DBA 并行 2 天
- 需要求解：关键路径长度（最短工期）

推理过程：
步骤 1：前端设计 API，耗时 2 天（第 1-2 天）
步骤 2：后端等前端完成后开始，耗时 2 天（第 3-4 天）
步骤 3：DBA 与前端并行开发，第 1-2 天完成，不在关键路径上
步骤 4：关键路径为 前端 → 后端，共 2 + 2 = 4 天

最终答案：项目最少需要 4 天

Few-shot CoT 模板

在提示词中嵌入若干带完整推理链的示例，引导模型模仿同样的推理风格：

FEW_SHOT_COT_TEMPLATE = """
下面是一些解题示例，请按照相同的推理方式回答最后的问题。

示例 1：
问题：一辆车 2 小时行驶 120 公里，另一辆车 3 小时行驶 180 公里，哪辆更快？
推理：
  - 第一辆：120 ÷ 2 = 60 km/h
  - 第二辆：180 ÷ 3 = 60 km/h
结论：两辆车速度相同。

示例 2：
问题：...
推理：...
结论：...

现在请回答：
问题：{question}
推理：
"""

XML 标签模板

用结构化标签显式分隔思考过程与最终输出，便于程序解析：

XML_COT_TEMPLATE = """
请按以下格式回答问题：

<thinking>
  在这里逐步分析和推理，可以包含中间假设、验证过程等
</thinking>

<answer>
  只写最终结论，简洁明了
</answer>

问题：{question}
"""

# 解析输出
import re

def parse_xml_cot(response: str) -> dict:
    thinking = re.search(r'<thinking>(.*?)</thinking>', response, re.DOTALL)
    answer = re.search(r'<answer>(.*?)</answer>', response, re.DOTALL)
    return {
        "thinking": thinking.group(1).strip() if thinking else "",
        "answer": answer.group(1).strip() if answer else response
    }

这种格式也是 Claude、DeepSeek 等模型内置推理模式的原型——它们的 <think> 标签正是同样的思路。

决策分析模板

适用于需要权衡利弊的复杂决策场景：

请按以下框架分析并给出建议：

【背景理解】
  简述问题背景和约束条件

【方案梳理】
  列出可能的候选方案（不少于 3 个）

【优劣分析】
  对每个方案分析优点和缺点

【综合评估】
  结合实际约束权衡各方案

【最终建议】
  给出推荐方案并说明理由

问题：{question}

代码调试模板

针对代码错误排查场景：

请按以下步骤排查代码问题：

1. 错误定位：描述错误发生在哪里、触发条件是什么
2. 根因分析：解释为什么会出现这个错误
3. 修复方案：给出具体的修改方式
4. 潜在风险：指出修改后是否引入新的问题

代码：
{code}

错误信息：{error}

模板选用原则

CoT 在 Agent 中的应用

在单次 LLM 调用中，CoT 通过提示词约束模型的推理结构。而在 AI Agent 中，CoT 的思想被延伸到了更高层次——Agent 内部通过**规划器（Planner）**来拆解任务，规划器本身也是通过调用 LLM 实现的。

Agent 内部结构：

用户输入
  ↓
┌─────────────────────────────────┐
│           Agent 核心             │
│                                 │
│  Planner（规划器）               │  ← 分解任务、决定用哪些工具、选什么模板
│      ↓                          │
│  Memory（记忆）                  │  ← 提供上下文、历史对话
│      ↓                          │
│  Tool Selector（工具选择）       │  ← 决定调用哪个工具/API
│      ↓                          │
│  LLM Call（模型调用）            │  ← 组装提示词后调用
└─────────────────────────────────┘
  ↓
输出结果

一个用户请求背后，Agent 可能触发多次 LLM 调用：

用户："帮我分析这段代码有没有性能问题，有的话给出优化方案"
  ↓
第 1 次 LLM 调用（规划）
  提示词："把这个任务分解成执行步骤，输出 JSON 格式的计划"
  返回：["读取代码", "识别性能瓶颈", "查阅优化文档", "输出方案"]
  ↓
按计划执行每一步，每步可能再次调用 LLM
  第 2 次：用代码调试模板 → 分析代码
  第 3 次：用决策分析模板 → 评估优化方案
  ↓
第 N 次 LLM 调用（汇总）
  把前面所有结果组装成最终 response
  ↓
返回给用户

用户完全感知不到背后发生了多少次 LLM 调用。这也是 Agent 比单次 LLM 调用更贵、更慢、但能处理更复杂任务的原因。

Human-in-the-loop（人在回路）

对于复杂任务，用户可以主动提供关键节点来帮助规划器生成更准确的计划。这本质上是把你的领域知识注入进去，让规划器少走弯路：

1. 直接在提示词里描述节点：“先检查数据库索引，再看慢查询日志，最后给优化建议”
2. 确认规划结果后再执行：Agent 先输出计划，用户确认或修改后再执行（Cursor、Claude Projects 等产品的常见交互模式）
3. 固化为 System Prompt：把关键节点提前写入 Agent 配置，每次任务都走这个框架

这其实是 CoT 思想在人机协作层面的延伸——你在帮 Agent 做"任务级别的思维链"，“选什么模板处理什么任务"也是需要固化进 Agent 的知识之一。

现代发展：Reasoning Model

以 OpenAI o1/o3、DeepSeek R1、Claude 3.7 Sonnet 为代表的 Reasoning Model，将 CoT 从"提示技术"升级为"训练目标”。模型在训练阶段通过强化学习被引导产生更高质量的推理链，推理过程放在 <think> 标签内（对用户不可见），输出质量显著提升。

这标志着 CoT 从"告诉模型如何思考"演进为"让模型学会如何思考"。

与 CoT 同层次的相关概念

CoT 是最基础的推理原理，其他大多数框架都在它之上构建：

CoT（基础推理原理）
  ↓ 扩展
ReAct / ToT / Self-Consistency（更复杂的推理框架）
  ↓ 结合
RAG + Reflexion（知识增强 + 自我改进）
  ↓ 组合
现代 Agent 架构

推理方式类

• ReAct（Reasoning + Acting）— CoT 的进化版，推理和工具调用交替进行，是目前大多数 Agent 的核心推理模式
• Tree of Thoughts（ToT）— 同时探索多条推理路径，择优继续，适合需要试错的复杂问题
• Self-Consistency — 对同一问题多次采样不同推理路径，投票取多数结论，提升可靠性
• Least-to-Most Prompting — 先把复杂问题拆成子问题，从最简单的开始逐步解决

反思/自我改进类

• Reflexion — 让 Agent 在执行后反思自己的输出，把反思结果写入记忆，下次做得更好
• Self-Ask — 让模型主动生成"为了回答这个问题，我需要先知道什么"，自问自答

知识增强类

• RAG（Retrieval-Augmented Generation）— 推理前先检索外部知识注入上下文，解决模型知识截止问题

相关文章

• AI Agent Development
• Intent Recognition and Slot Filling
• Function Calling
• Tool Calling Patterns
• Output Constraint
• LangChain
• LlamaIndex
• Agent Token Routing

维护记录