OpenAI o1/o3 Reasoning 架构精读 —— 从 Chain-of-Thought RL 到长思维链的工程化突破

一、Reasoning 革命起源：为什么 LLM 必须学会「慢思考」

本节聚焦于 Reasoning 范式革命的认知科学基础与工程动机，逐节拆解如下：

1.1 从 System-1 到 System-2：推理模型的概念基础与工程动机

在认知心理学中，Daniel Kahneman 将人类思维划分为两大系统：System-1 是快速、直觉、自动化的反应模式（"看一眼就能识别猫"），System-2 是慢速、刻意、需要工作记忆参与的逻辑推理（"解一道奥数题"）。这一双系统理论在 2024 年成为大模型架构演进的核心理念：传统 LLM（GPT-4、Claude 3.5、Gemini 1.5）几乎都是纯粹的 System-1 模型——它们通过 next-token prediction 在万亿级文本上学到的"概率直觉"，在数学竞赛、编程题、博士级科学问答上一旦需要多步推理便会暴露短板（"看一眼就报错"）。

OpenAI 在 2024 年 9 月 12 日发布的 o1-preview，正是 LLM 第一次显式地把 System-2 能力作为训练目标：模型在生成最终答案前，会先在内部进行一段长长的、潜在的"思维链（Chain-of-Thought, CoT）"推理，把问题拆解为子问题、验证中间步骤、尝试多种思路、自我反思纠错，最终才输出结论。这段思维链对用户不可见，但对模型来说却是计算过程的一部分。由此带来的范式跃迁可以归纳为三点：

// System-1 vs System-2 在 LLM 上的工程映射
type ReasoningMode =
  | { kind: "system-1"; cotTokens: 0;     compute: "single-pass"     }
  | { kind: "system-2"; cotTokens: 1e4;   compute: "deliberate-search"};

// 传统 LLM (GPT-4 类)
const gpt4: ReasoningMode = { kind: "system-1", cotTokens: 0, compute: "single-pass" };

// o1 / o3 类
const o1: ReasoningMode = { kind: "system-2", cotTokens: 5000, compute: "deliberate-search" };

System-2 的工程动机可以从三个维度刻画：准确率天花板（GPT-4 在 AIME 2024 上仅 13% 准确率，o1 提升到 83.3%）、可解释性下限（System-1 的黑箱 answer 无法审计推理路径，System-2 至少在内部 CoT 中保留了"思考痕迹"）、推理扩展性（inference-time scaling law）（System-1 的能力被训练算力锁定，System-2 允许在推理时"花更多算力换更高准确率"）。三者合起来，构成了 OpenAI 押注 o-series 的根本战略：把"智能"从"预训练压缩率"转移到"推理时计算量"。

从工程视角看，System-2 范式还带来一个隐含但关键的架构选择——思维链必须是潜在的（latent）。如果让模型把 CoT 完全暴露给用户，会带来三个副作用：(1) 暴露 IP，用户可能复制 CoT 训练自己的模型；(2) 安全风险，CoT 可能泄露训练时的危险内容、未对齐策略；(3) 成本透明，用户难以理解为何一次回答要花 8 美元。因此 OpenAI 选择"内部 CoT 隐藏 + 输出 summary"的双层接口——内部维护几万 token 的 CoT、KV cache 与 verifier 状态，对外只回传 summary 文本。这一选择背后是隐私、合规、商业化的多重权衡，我们将在第 10 章深挖。

// 思维链双层接口的伪代码示意
interface ReasoningResponse {
  visible: { summary: string; finalAnswer: string };  // 暴露给用户
  hidden:  { cot: string; prmScores: float[]; verifierLog: TraceEvent[] };  // 内部维护
}

function reason(prompt: string): ReasoningResponse {
  const cot = sampleCoT(prompt, maxTokens=8192, temperature=0.7);
  const prmScores = prmModel.scoreSteps(cot);  // 过程奖励
  const verified = verifierModel.check(cot, prompt);
  const summary = llm.summarize(cot, verified);
  return { visible: { summary, finalAnswer: extractAnswer(cot) },
           hidden:  { cot, prmScores, verifierLog: verified.log } };
}

最后，本章还需要澄清一个常见误解：System-2 ≠ "让模型写更多文字"。很多团队试图通过 prompt engineering 强迫 GPT-4 "think step by step" 来模仿 o1，结果收效甚微。原因在于：System-2 不仅是输出格式问题，更是训练目标问题。o1 的长 CoT 不是被 prompt "写出来"的，而是在 RL 阶段被训练出来的——奖励信号针对的是"整条推理路径的最终正确性"以及"中间步骤的逐步正确性"，模型因此学会了在内部用数千 token 探索、验证、回溯。单纯的 few-shot prompting 没有这种训练压力，模型只会"假装思考"而非"真思考"。

承接上文推理脉络，本节将系统展开：

1.2 o1-preview 论文精读（2024-09）：Learning to Reason with LLMs 的核心机制

2024 年 9 月 12 日，OpenAI 发布了一篇看似不长的技术博客 Learning to Reason with LLMs（与 o1-preview 模型同步放出）。这篇文档虽然仅有 5 页左右正文，但每一段都对应着 o1 架构的关键决策，密度极高。我们按照"训练范式 → 强化学习算法 → 推理接口 → 评估"四条主线逐段拆解。

第一段：训练范式概述。论文开宗明义指出——"我们训练模型使其在响应前产生一长串内部思考（a long internal chain of thought）"。这里的关键词是"内部"与"长串"：(1) "长串"指 reasoning tokens 的数量级，o1 在 AIME 数学题上一次推理可能消耗 5,000-50,000 tokens，是传统 few-shot CoT（200-500 tokens）的 25-250 倍；(2) "内部"指这些 tokens 不会作为 API 输出回传给用户（仅在 playground UI 显示思维摘要），而是作为内部计算痕迹；(3) "思考"在 RL 的语境下指奖励信号针对的是思考路径，而非仅最终答案。

第二段：RL 算法轮廓。论文原文称"我们训练了一个全新的 RL 算法，并用 chain-of-thought 进行优化，以教导模型如何利用其思考过程，战略性地探索、识别和纠错"，并提到"我们还训练模型在困难问题上尝试不同方法"。这透露了三个工程细节：(1) RL 算法不是 PPO，也不是经典 REINFORCE，而是某种 过程感知的改进算法（后续被业界推测为基于 PPO + Process Reward Model 的组合）；(2) "战略性探索"暗示模型会做 tree-of-thought / beam-search 式的展开，而非单链生成；(3) "识别和纠错"暗示 反思步骤（self-revision） 是 CoT 的一部分。

// o1 RL 训练的高层伪代码（论文原文抽象）
function trainO1(baseModel, promptDataset):
    policy = baseModel;  // 从预训练 checkpoint 开始
    rewardModel = trainPRM(promptDataset);  // 过程奖励模型
    for step in range(maxSteps):
        prompts = sampleBatch(promptDataset);
        cotRollouts = policy.generate(prompts, maxTokens=8192, doTreeSearch=True);
        stepRewards = rewardModel.scoreSteps(cotRollouts);  // 过程级奖励
        advantage = computeGAE(stepRewards, valueHead);
        policy = ppoUpdate(policy, cotRollouts, advantage);
        if step % evalInterval == 0:
            evaluate(policy, benchmarks=[AIME, GPQA, MATH]);
    return policy;

// 关键差异：rewardModel 同时评估"每一步是否正确"，而非仅评估最终答案
function trainPRM(dataset):
    // PRM 用 step-level 标注数据训练
    // 数据来源：人类标注 + 蒙特卡洛 rollout 一致性 + LLM-as-judge
    return prmModel;

第三段：评估成绩。o1-preview 在 AIME 2024 上达到 83.3%（GPT-4 约 13%），在 GPQA Diamond（博士级科学问答）上达到 78%（GPT-4 约 50%），在 Codeforces 编程竞赛 rating 上达到 1673（人类前 11%）。这些数字背后最关键的不是绝对分数，而是相对提升的来源：传统模型在算力（参数规模、训练 token）翻倍时性能只能提升 5-10%，而 o1 通过推理时计算量提升则可获得 30-50% 的提升。这就引出了下一章将深入讨论的 inference-time scaling law。

第四段：推理接口设计。论文解释了为什么 o1 在 ChatGPT 中"思考时间"较长且不展示 CoT 原文——"reasoning tokens are hidden from the API users and shown as a summary by ChatGPT"。这一设计不仅是体验问题，更是一道系统安全边界。OpenAI 在 system card 中明确指出：长期来看，OpenAI 期望通过 CoT 监控模型行为，而隐藏 CoT 是为了让"思考过程不被对手直接用来 jailbreak 或蒸馏（distillation）"。这一逻辑直接影响了后来 o3、o4-mini 的 API 设计与安全策略。

第五段：行业反应与延伸。论文发布后 72 小时内，Anthropic（2024-10）和 Google DeepMind（2024-12）相继宣布在 Claude 与 Gemini 上推出 extended thinking / thinking budget 功能。开源阵营则分化为两条路线：(1) Meta AI、Allen AI、复旦等团队尝试 RAG + 自我一致性（self-consistency） 的"穷人 o1"；(2) DeepSeek（2025-01）第一个完整复现了 Long CoT RL 训练，发布 DeepSeek-R1-Zero 与 DeepSeek-R1 论文与权重。这两条复现路径各自代表了"用工程技巧逼近"与"用训练范式复制"两种思路，对 o1 架构形成了有效外部验证。

// o1-preview 论文关键数据快照
interface O1Benchmark {
  aime2024:       { gpt4o: 13.4,  o1preview: 83.3, o1: 96.6,  o3: 96.7 };
  gpqaDiamond:    { gpt4o: 50.6,  o1preview: 78.0, o1: 87.8,  o3: 87.7 };
  codeforces:     { gpt4o: 808,   o1preview: 1673, o1: 2061,  o3: 2706 };
  frontierMath:   { gpt4o: 2.3,   o1preview: 11.1, o1: 25.2,  o3: 96.0 };
  sweBench:       { gpt4o: 21.0,  o1preview: 41.0, o1: 48.9,  o3: 71.7 };
}

const o1Trajectory = new O1Benchmark();
console.log("o1 到 o3 的 frontierMath 从 25.2 提升到 96.0，是最显著的跃迁");

承接上文推理脉络，本节将系统展开：

1.3 与 RLHF 的本质区别：Chain-of-Thought RL 而非偏好对齐

很多读者第一次接触 o1 时会问：o1 是不是又一种 RLHF？这是一个关键的架构分野——o1 与 RLHF 的差异不仅是"奖励信号不同"，更是优化目标 / 训练场 / 评估方式 / 推理接口四个维度的根本区别。下面我们逐项拆解。

上述差异中，"训练场"是最具工程决定性的。RLHF 在开放对话上能让模型"礼貌、好用、安全"，但无法可靠提升"计算正确性"——你无法问人类标注员"这个导数算得对不对"。o1 的解决方案是把训练场收缩到可验证领域：AIME 数学题、APPS 编程题、MATH 数据集等任务都有一个客观的"答案是否正确"判定函数（verifier）。模型在这种"答案可机器判断"的环境下做 RL，奖励信号几乎免费，训练规模可以无限放大。

但收缩到可验证领域带来了可迁移性问题：在 AIME 上 RL 出的推理能力，能否迁移到 GPQA（博士科学问答）、SWE-bench（软件工程）、MedQA（医学）这些不那么"硬可验证"的任务？OpenAI 的答案是"可以迁移，但需要 General Reward Model（GRM）补足"。o3 的训练范式就是 PPO（数学/代码）+ RBR + GRM（通用领域）的混合奖励，这就是 RLVR + RLHF 混合 的工程现实。

// o1/o3 训练奖励的真实组成（业界推测 + o3 论文披露）
interface RewardSignal {
  // 第一部分：可验证领域（数学、代码）
  verifiable: {
    math: (answer, gt) => equals(extractFinal(answer), gt) ? 1 : 0,
    code: (code, tests) => all(tests(passed(code, t)) for t in tests) ? 1 : 0,
  };
  // 第二部分：过程奖励模型（PRM）
  prmScore: (cot: Step[]) => stepLevelReward(cot);
  // 第三部分：通用奖励模型（GRM，针对非可验证领域）
  grmScore: (response) => humanPreferenceRM.score(response);
  // 最终的复合 reward
  totalReward: = w1 * verifiable + w2 * prmScore + w3 * grmScore;
}

// 与传统 RLHF 的对比
interface RLFHReward {
  // 仅一项：人类偏好
  preference: (A, B) => humanPref(A, B) in {0, 1};
}

另一个关键差异是 CoT 在训练中的角色。RLHF 阶段的 CoT 只是一种"为了帮助用户理解而写出来的解释"——SFT 数据可以包含 CoT，但 RL 阶段人类只关心最终回答是否合用，CoT 不在奖励路径上。o1 的 CoT 则是奖励路径的必经节点：PRM 对每一步推理打分，结果好的 CoT 获得高 advantage，模型因此学会"在内部花更多 token 思考"。这条路径绕开了"标注一条 CoT 是否好"的难题，转而用 verifier 检查每一步的事实正确性与逻辑一致性。

最后一个被低估的差异是 inference 接口。RLHF 模型的 API 输出与训练目标几乎一致——模型说啥就是啥；o1 的输出只是冰山一角——训练目标包含几万 token 的内部 CoT，但 API 只回传 summary 与 final answer。这看似是一个产品选择，实则暗示了底层推理引擎分为两段：第一段是长 CoT 生成（System-2 推理），第二段是 summary 抽取与答案提取（System-1 输出）。这种"双段式推理引擎"是 o1 系列相对 GPT-4 系列的关键工程改造，我们将在第 10-11 章详细解构。

1.4 inference-time scaling law：推理算力与准确性的幂律关系

过去十年，LLM 训练主要靠 pre-training scaling law（Kaplan 2020 / Chinchilla 2022）：模型参数量 N、训练 token D、训练算力 C 三者之间存在幂律关系，扩大 N/D/C 就能预测提升。但 2023-2024 年学术界已经观察到 pre-training scaling law 的边际收益在递减——GPT-4 之后单纯堆参数/堆数据的回报率显著下降。OpenAI o1/o3 系列真正的范式贡献，是证明了 还有一条平行的 scaling law 维度：inference-time compute。在给定 base model 的前提下，推理时投入更多算力（更多 token、更长 CoT、更多树搜索分支、更精细的 verifier），模型能力按照幂律上升。

这一论断并非 OpenAI 首创——多个团队 2023 年已经在 self-consistency（采样多条 CoT 取多数）、tree-of-thought（树搜索）、best-of-N rejection sampling 等范式上观察到类似现象。但 o1 是第一个把这种 scaling law 训练端与推理端联合优化：训练时把 Long CoT 作为策略，让模型天然支持推理时扩展；推理时给模型一个 reasoning_effort 参数（low/medium/high），等价于允许用户在 inference-time scaling 曲线上选点。OpenAI 后来在 o1 system card 中放出的对应 scaling 曲线如下。

// Inference-time scaling law 的工程量化
interface ScalingCurve {
  baseModel: string;
  compute: { tokens: number; shots: number; searchBranches: number };
  accuracy: { aime: number; gpqa: number; math: number };
}

// 经典 scaling 曲线（OpenAI o1 system card 简化版）
//   tokens=100,  accuracy=0.20
//   tokens=500,  accuracy=0.42
//   tokens=2K,   accuracy=0.61
//   tokens=8K,   accuracy=0.78
//   tokens=32K,  accuracy=0.91
//   tokens=128K, accuracy=0.96  // o3 在 AIME 的极限

const fitting = logLogFit({
  x: [100, 500, 2000, 8000, 32000, 128000],
  y: [0.20, 0.42, 0.61, 0.78, 0.91, 0.96],
});
// 拟合结果: accuracy ≈ A_max - k * (tokens)^(-alpha), alpha ≈ 0.18

学术上的 inference-time scaling law 可以形式化如下：给定预训练模型 M 与任务分布 P，性能指标 A(E)（accuracy / pass@k）与推理算力 E（等价于生成 token 数 + 搜索深度 + verifier 调用次数）之间的关系近似为：

A(E) = A_max - k * E^(-alpha)
// 其中 A_max 是该 base model 在该任务上的极限（受模型容量约束），
// alpha 是 scaling 斜率（任务越难 alpha 越小），k 是任务难度常数。

实证上，alpha 在 AIME 这种奥数题上约 0.15-0.20，在 MATH 500 上约 0.10-0.15，在 GPQA 上约 0.05-0.10。这意味着同一份推理算力在"困难任务"上的回报率反而不如"中等任务"。但 o3 的突破在于：通过 RL 训练让 base model 的 A_max 显著抬高，使得即使在 GPQA 这种 alpha 小的任务上，给够推理算力仍能突破 87% 的上限。

这一发现直接催生了"Test-Time Scaling（推理时计算）"概念在 2025 年的爆发：Anthropic 在 Claude 3.7 Sonnet 中提供 "extended thinking" 预算；Google 在 Gemini 2.5 中提供 "thinking_budget" 参数；DeepSeek 在 R1 中提供 蒸馏后的 1.5B/7B/8B/14B/32B/70B 不同规格；OpenAI 自己在 o1-pro 上提供 4× reasoning_effort。所有这些产品决策都源于 o1 论文揭示的同一条 scaling 曲线。

本章最后必须澄清一个关键区分：inference-time scaling ≠ "增加 model parameters"。前者是"花更多算力在同一个 base model 上"，后者是"再训一个更大的 base model"。两者在能力上限上等价，在工程成本上天差地别。o1/o3 的训练路径选择"小 base + 推理扩展"而非"再训 10× 大的 base"，是商业理性 + 工程理性的双优解。它让 OpenAI 可以用更低的训练成本，把 100× 推理 ARPU（人均收入）产品化。这个商业逻辑深刻影响了后来所有 reasoning-first 团队的策略。

1.5 心理学基础：Kahneman 双系统理论在 LLM 训练中的工程映射

在深入 o1 之前，我们必须先理解为什么 System-2 范式不是"凭空诞生"的——它的认知科学基础可以追溯到 1970 年代以来的心理学研究，并在 2011 年由 Kahneman 在《Thinking, Fast and Slow》中系统化。把这一认知科学框架映射到 LLM 工程，能让我们看清为什么 o1 的训练范式选择"CoT 进入 RL"而非"CoT 留在 prompt"。

Kahneman 区分的两个系统在认知上有五个核心差异，恰好一一对应 LLM 工程中的五个设计选择：

这五个映射给出一个关键洞察：System-2 不是 System-1 的简单延伸，而是质的不同。LLM 上模拟 System-2 不能靠"提示模型多想想"，而是要在训练目标层面对应一个新模态——把"中间推理过程"作为一等公民对待。这正是 o1 在 RL 训练中把 CoT 视为"奖励路径必经节点"的认知科学根据。

另一个相关的工作记忆理论也支撑了 o1 的设计。Baddeley 的工作记忆模型把工作记忆分为三个子系统：phonological loop（语音/语言）、visuospatial sketchpad（视觉空间）、central executive（中央控制）。LLM 中的 CoT 大致对应 phonological loop + central executive——模型用语言 token 维持推理状态，用 CoT 自身的逻辑结构保持注意力聚焦。o3 的多模态扩展则加入了 visuospatial sketchpad——视觉 token 在 CoT 中作为视觉工作记忆。

元认知（metacognition）的工程化。System-2 的另一个关键特征是元认知——人能"知道自己不知道"。LLM 传统训练中没有显式的元认知信号，模型只是输出 token，不会"评估自己的信心"。o1/o3 通过 PRM 引入了显式的元认知：每一步推理都有一个"信心分数"，模型基于这个分数决定是否继续 / 改写 / 终止。这种"thinking about thinking"的能力是 System-2 的核心，PRM 把它工程化为可计算的信号。

// 元认知 PRM 的工程化：confidence score + self-revise
function metacognitiveReason(prompt, maxSteps=100) {
    partialSolution = "";
    confidenceHistory = [];

    for step in range(maxSteps) {
        // 1. 生成下一步推理
        nextStep = policy.generate(prompt, partialSolution);
        partialSolution += nextStep;

        // 2. PRM 给出信心分数
        confidence = prmModel.scoreStep(prompt, partialSolution, step);
        confidenceHistory.append(confidence);

        // 3. 元认知决策：继续/回溯/接受
        if confidence > 0.9 {
            continue;  // 高置信度：继续
        } else if confidence < 0.3 {
            // 低置信度：回溯，重新生成
            alternative = policy.regenerate(prompt, partialSolution);
            if prmModel.scoreStep(prompt, alternative) > confidence {
                partialSolution = partialSolution + alternative;
            }
        } else {
            partialSolution += " [moderate confidence] ";
        }

        // 4. 终止条件
        if isFinalAnswer(nextStep) and confidence > 0.7 break;
    }
    return {solution: partialSolution, confidenceTrace: confidenceHistory};
}

这种元认知 PRM 让 o1 / o3 模型具备了一个独特的能力——"知道自己不确定"。在 GPQA / MedQA 这类需要"知道自己不知道"的任务上，o3 比 GPT-4o 高出 30-40% 的"准确回答率"（即不只是选一个答案，还能识别"我不确定应该选哪个"的样本并主动放弃）。这与人类专家"承认无知"的能力一致，是 AGI reasoning 的关键维度。

1.6 早期探索：从 Chain-of-Thought Prompting 到 Self-Consistency 的工程教训

o1 之前，业界已经在 reasoning 增强方向上做了多种尝试：Few-shot CoT（2022）、Self-Consistency（2022）、Tree of Thoughts（2023）、ReAct（2022）、Auto-CoT（2022）。理解这些尝试为何失败 / 部分成功，能帮我们看清 o1 为何必须走"RL training"路线。下面我们逐项分析。

Few-shot CoT prompting（Wei et al. 2022）。用 few-shot examples 引导模型"step by step thinking"。在 GSM8K 数学题集上把 GPT-3 的 accuracy 从 18% 提升到 56%。但提升饱和：模型不能扩展 CoT 长度；不能 self-revise；逻辑跳跃时无法自纠。核心限制——模型已有的策略分布没有 reasoning 偏向。

Self-Consistency（Wang et al. 2022）。对同一 prompt 采样多条 CoT，取多数答案。在 GSM8K 上从 56% 提升到 74%。但仍依赖 prompt 引导；多数投票成本高；模型不知道哪条 CoT 更优。核心限制——没有过程级评估。

Tree of Thoughts（Yao et al. 2023）。把 CoT 改为树搜索，每个 step 后做 best-of-N 扩展。在 24 点游戏 / Game of 24 上达到近乎 100%。但 prompt 引导的扩展深度有限；推理算力开销大；不能保证扩展到 100+ steps。核心限制——没有训练成"知道如何扩展"。

ReAct（Yao et al. 2022）。把 CoT 与 tool use 交替，让模型在 reasoning 中调用工具（搜索、计算）。打开了 agent 推理的方向。但 tool use 完全 prompt 引导；不能稳定调用；失败恢复弱。核心限制——tool use 没有训练成策略。

Auto-CoT（Zhang et al. 2022）。用 zero-shot 触发 CoT 生成，自动构造 diverse examples。但生成的 CoT 质量参差不齐，远不如人类写的 few-shot examples。核心限制——生成 CoT 的能力上限受 base model 限制。

综合这些探索，o1 团队得到了一个关键教训：所有 prompt-only / inference-only 的尝试都受限于 base model 已有策略分布。要让模型"真正"reasoning 而非"假装"reasoning，必须把 reasoning 能力训练到 base model 内部。这就是为什么 o1 必须走 RLVR 路径，而非工程 trick 路径。这种"训练-范式 > 工程-优化"的思考方式，是 LLM 推理增强从"patching"走向"systemic"的拐点。

这一视角对工程师的指导意义是：不要寄望于 prompt 或工程技巧弥补模型 reasoning 能力的缺陷。如果模型本身没有 reasoning 能力，再精巧的 prompting / RAG / agent 框架都只能治标。如果要让模型真正具备 System-2 能力，必须在训练阶段投资。这与"用 GPT-3 的能力 + 复杂 prompt 模仿 GPT-4"不可行的逻辑一致——能力差异是范式差异，必须在训练中解决。

1.7 o1 发布两周内行业反应：从 Anthropic 到 DeepMind 的 reasoning 化浪潮

o1-preview 发布两周（2024-09-12 至 2024-09-26）内，整个 AI 行业迅速跟进 reasoning 范式。这一段时间的反应对理解 o 系列的影响力很关键——它不只是 OpenAI 的技术胜利，更是对整个 LLM 行业研究方向的重新定位。

Anthropic 的快速反应。Anthropic 在 2024-10-22 推出 Claude 3.5 Sonnet 的更新版本，加入"extended thinking"参数（预算 8k-32k tokens）。这是 Anthropic 在 o1-preview 发布仅 40 天后的反制。Anthropic 选择"show thinking"哲学——把 CoT 摘要显示给用户，与 OpenAI 的"hidden CoT"形成对比。这一哲学差异后来成为两大 AI 公司的对偶立场：OpenAI 强调"模型思考是私有的，应该被保护"；Anthropic 强调"思考透明是赢得用户信任的核心"。

Google DeepMind 的战略回应。Google DeepMind 在 2024-12 与 Gemini 2.0 同期推出 Gemini Thinking 模式。其设计独特之处在于 (1) 原生多模态——从一开始就把 vision + audio + text 融合进 thinking loop；(2) Thinking Budget API——开发者显式指定 thinking budget（以 token 为单位）；(3) Flash 版本——降低延迟的"lightweight thinking"模式。DeepMind 的优势在于多模态融合更深，但 reasoning 能力相对 o1 略弱（GPQA 约 74% vs o1 的 87.7%）。

xAI 的快速跟进。Elon Musk 旗下的 xAI 在 2024-12 推出 Grok 2 with reasoning，引入了"thinking effort"参数。xAI 的 reasoning 训练细节公开较少，但传闻同样基于 PRM + RLVR。这反映了 2024 H2 起几乎所有主流 LLM 团队都加入了 reasoning 赛道。

中国阵营的快速跟进。中国 LLM 团队在 o1 后的反应也极为迅速。DeepSeek 在 2025-01-20 发布 DeepSeek-R1，完整复现了 o1 的训练范式并开源（MIT 协议），这是中国 AI 公司在国际 reasoning 赛道上的首次领先。同期 Qwen（阿里）、Kimi（月之暗面）、Yi（零一万物）、智谱 GLM 都推出了各自的 reasoning 版本，其中 DeepSeek-R1 因开源 + 性能优异而成为"开源 o1"的标杆。

学术界与开源社区的反应。学术界对 o1 的反应是复杂的"兴奋 + 警惕"——兴奋于 reasoning 范式的潜力，警惕于 OpenAI 不披露训练细节。这催生了 2025 H1 的 "复现 o1 浪潮"：HuggingFace 的 Open-R1 项目、清华的 Math-Shepherd 项目、OpenRLHF、Tsinghua 的复现尝试、复旦的复现尝试，多个研究团队尝试从公开信息复现 o1 的 RLVR 训练。其中 DeepSeek-R1 是复现最完整的版本，它的 R1 论文详细披露了训练细节，让开源社区可以借鉴。这种"开源复现 + 闭源领先"的张力，是 o 系列影响力的另一面。

二、训练范式深度：从 PRM 到 RLVR 的工程全景

第一篇奠定了 o1 的概念基础（System-2 推理）与训练场的两类奖励信号（PRM 与 Outcome）。本篇我们深入到训练算法的具体细节，拆解五个核心问题：(1) Process Reward Model 如何训练、如何推理、如何打分；(2) RL with Verifiable Rewards 的 rollout 算法与 reward shaping；(3) Long CoT 的探索机制——self-play、课程学习、tree-search；(4) 数据策略——人类标注 vs 合成数据的比例；(5) 训练规模与算力——o1 究竟用了多少 GPU、多少天。

2.1 Process Reward Model (PRM)：过程级奖励模型 vs Outcome Reward Model

PRM 是 o1 训练中最关键、最具创新性的组件，也是与"传统 Outcome Reward Model (ORM)" 最根本的分野。我们先定义两个概念，再讨论 PRM 训练与推理细节。

Outcome Reward Model (ORM)：给定 prompt + 完整生成结果（不管是回答还是 CoT），输出一个标量 reward，表示"最终答案好不好"。在传统 RLHF 中，人类标注员对完整回答打分（1-7 Likert），训练一个 reward model。这种 reward model 只关心"对错"，对"如何到达答案"的过程毫不在意。在数学任务上，ORM 训练数据是 "（问题，最终答案）→ 0/1"；在编程任务上是 "（问题，提交记录）→ pass rate"。

Process Reward Model (PRM)：给定 prompt + 完整 CoT 中每一步（step），对每个 step 输出一个 reward，表示"这一步推理是否正确"。PRM 把"对答案的判断"细化为"对每一步推理的判断"。这一步至关重要——因为在 Long CoT 中，单一中间步骤的错误（一个错误的算式、一个错误的逻辑跳转、一个错误的事实引用）会传导到最终答案；ORM 只能事后追溯，PRM 能在训练时即时纠偏。

// ORM vs PRM 的接口对比
interface OutcomeRewardModel {
  score(prompt: string, fullSolution: string): float;  // 单一标量
}

interface ProcessRewardModel {
  score(prompt: string, steps: string[]): float[];  // 每步一个 reward
  scoreStep(prompt: string, steps: string[], stepIdx: number): float;
}

// ORM 的训练数据
type ORMTrainingDatum = {
  prompt: string;
  solution: string;
  label: { outcome: "correct" | "incorrect" };
};

// PRM 的训练数据
type PRMTrainingDatum = {
  prompt: string;
  steps: string[];
  stepLabels: ("correct" | "incorrect")[];
};

PRM 的训练数据从哪来？这是一个昂贵的工程问题。可能的来源包括：

1. 人类标注：让数学专家 / 竞赛选手逐句检查 CoT，标记"哪一步错了"。成本高（每小时仅能标 5-10 道），但精度高。o1 早期训练主要靠这种方式。
2. 蒙特卡洛 rollout 一致性（"MC estimation"）：对一个 prompt，让模型在固定 step 之前的状态下，从该步开始做多次 rollout，统计后续能否达到正确答案。如果从该 step 出发的多次 rollout 中，正确率显著低于随机位置，就说明该 step 是错误的高概率点。这是 PRM 的经典标注 trick，由 OpenAI 在 2023 年的 "Let's Verify Step by Step" 论文中提出。
3. LLM-as-judge：用一个强模型（如 GPT-4o）检查每一步是否逻辑正确。这种标注便宜，但存在 self-bias（用 o3 自己判 o3 自己）。
4. 对比学习（contrastive pairs）：构造正确 CoT 与错误 CoT 的 pair，训练 PRM 区分。这种方法在 2024 年被多家团队探索。

OpenAI 在 o1 训练中主要采用 (1) + (2) 的组合：(1) 提供 ~10k 高质量精确标注，(2) 用 MC 一致性扩展到 ~100k 标注。这就把 PRM 训练成本压到传统人类标注的 1/10。

PRM 在推理阶段如何工作？给定一个正在生成的 CoT（已生成 k 个 step），PRM 对每个已生成 step 打分，并用这些分值做两件事：(1) 作为 RL 训练时的 dense reward signal（每步有梯度信号而非仅终局有）；(2) 作为推理时的 Best-of-N 采样器——在 N 条 rollout 中选 PRM 总分最高的那一条。这就是 o1 / o3 system card 提到的"process-based outcome selection"。

// PRM 在推理时的应用：Best-of-N with Process Reward
async function bestOfN(prompt, N=64, policy) {
    candidates = await Promise.all(
        Array.from({length: N}, () =>
            policy.generate(prompt, maxTokens=8192))
    );
    scoredCandidates = await Promise.all(
        candidates.map(async (cot) => {
            const steps = splitIntoSteps(cot);
            const stepScores = await prmModel.score(prompt, steps);
            const totalScore = sumProduct(stepScores, decay=0.95);
            const outcomeScore = await verifierModel.check(prompt, cot);
            return { cot, totalScore, outcomeScore,
                     combined: totalScore * 0.4 + outcomeScore * 0.6 };
        })
    );
    return scoredCandidates.sort((a, b) => b.combined - a.combined)[0].cot;
}

最后，PRM 有一个被低估的副作用——它本身也是 reasoning 模型。要判断"这一步推理对不对"，需要模型理解问题的数学逻辑、题目的语义、子步骤的因果关系。这意味着 PRM 本身的训练量与一个基础模型相当。OpenAI 在 o3 训练中部署了两层 verifier：基础 verifier (ORM/PRM) 用于大多数样本，关键样本（高难度 / 高价值）再调用更精细的 verifier。这种分层 verifier 设计是 o3 训练效率的关键。

2.2 RL with Verifiable Rewards (RLVR)：数学/代码等可验证领域的训练范式

RLVR 这一概念在过去半年（2025 H1）被快速普及，其核心思想简洁有力：把"人类偏好"这个模糊奖励替换成"机器可验证的正确性"。在数学上，verifier 是答案匹配 + sympy 等价检查；在代码上，verifier 是测试用例 pass rate；在定理证明上，verifier 是 Lean / Coq 类型检查；在化学上，verifier 是 rdkit 分子结构检查；在棋类上，verifier 是 Stockfish 评分。这种"机器打分 + RL"的组合，把训练规模从"受限于人类标注员产能"解放到"受限于 GPU hours"。

RLVR 的标准训练循环如下：

// RLVR 标准训练循环
function rlvrTrain(policy, refPolicy, taskDist, verifier, prmModel) {
    for step in range(numSteps) {
        prompts = taskDist.sample(batchSize);
        rollouts = sampleRollouts(policy, prompts, maxTokens=8192, n=8);
        outcomeRewards = rollouts.map(r => verifier(prompts, r));
        processRewards = rollouts.map(r => prmModel.score(prompts, r));
        combined = combineReward(outcomeRewards, processRewards, w={0.6, 0.4});
        advantages = computeGroupRelativeAdvantage(combined);
        policy = ppoUpdate(policy, rollouts, advantages, klCoef=0.05);
        if (step % 1000 == 0) evaluate(policy);
    }
    return policy;
}

RLVR 相对于 RLHF 有三个工程优势：第一，奖励几乎免费，一次 verifier 检查成本 < $0.0001，远低于人类标注的 $0.5-2 对话；第二，奖励方差低，verifier 给出的就是 ground truth，没有 inter-annotator disagreement；第三，奖励分布可控，可以按任务类型 weight 加权。但 RLVR 也有三大限制：

1. 训练场受限：必须有 verifier 才能做 RLVR，绝大多数真实任务（写作、咨询、规划）没有 verifier；
2. Verifier Errors：verifier 本身可能出错（sympy 在某些积分 / 解方程上误判；测试用例过弱漏过错误解）；
3. Reward Hacking：模型可能学会"骗过 verifier"——例如生成 sympy 看起来对但语义错的答案，或在代码中只通过弱测试但隐藏 bug。

OpenAI 的应对策略是 分层 verifier + 多样化任务。分层 verifier 已在第 2.1 节描述；多样化任务意味着在数学、代码、定理证明、形式化验证、化学、棋类等多个 verifier 域上同时做 RLVR，避免模型过拟合单一 verifier 的"hack pattern"。

RLVR 与 PRM 的关系可以这样理解：PRM 是 RLVR 训练时的 step-level reward signal；RLVR 是 PRM 反哺的 PRM 训练数据来源。两者形成闭环——PRM 帮 RLVR 把 Long CoT 训出来；RLVR rollout 出的大量 CoT 又成为 PRM 的训练数据（用 MC 一致性自动标注）。这种 RLVR ⇄ PRM 协同进化 是 o1/o3 训练效率高的核心原因，下一章我们会用 self-play / curriculum 的视角详细分析。

2.3 Self-Play / 探索策略：Long CoT 的探索机制与课程学习

Long CoT 的核心难点是探索（exploration）：在数千 token 的生成空间里，模型如何尝试多种思路、自我反思、纠正错误？传统的 PPO / GRPO 在 dense reward 下做 random sampling + gradient update，已经能让模型学到合理的 Long CoT，但要达到 o1 级别的能力，还需要更精细的探索机制。本节我们讨论三个关键策略：(a) Self-Play / Self-Revision、(b) tree-of-thought / beam-search 推理、(c) 课程学习（curriculum learning）。

(a) Self-Play 与 Self-Revision。Self-play 指让模型与自己对弈——生成问题、解问题、检查解、修正解。Self-revision 是 self-play 在 text 域的特例：模型先生成 CoT，发现中间步骤有问题后，回头改写 CoT 的一部分。OpenAI 在 o3 训练中显式鼓励这种行为——通过奖励 shape："如果一条 CoT 经过 self-revision 后得到正确答案，奖励 +1.5；如果直接生成正确答案，奖励 +1；如果 self-revision 后仍然错误，奖励 +0"。这种"鼓励反思 +0.5"的奖励设计让模型学会"先尝试，错了再改"的 System-2 行为。

// Self-Play RLVR 训练循环（带 self-revision 奖励）
function rlvrWithSelfRevision(policy, taskDist, verifier) {
    for step in range(numSteps) {
        prompts = taskDist.sample(batchSize);
        // 一次普通 rollout
        rollouts = policy.generate(prompts, maxTokens=8192, doRevision=True);
        outcomes = rollouts.map(r => verifier(prompts, r));

        // 三类奖励：直接对、修订对、错误
        rewards = rollouts.map((r, i) => {
            if (wasRevised(r) && outcomes[i] == 1) return 1.5;
            if (outcomes[i] == 1) return 1.0;
            return 0.0;
        });

        advantages = computeAdvantages(rewards);
        policy = ppoUpdate(policy, rollouts, advantages);
    }
    return policy;
}

function wasRevised(cot): bool {
    return cot.includes("wait, let me reconsider") ||
           cot.includes("actually, that's wrong") ||
           cot.includes("let me try a different approach");
}

(b) Tree-of-Thought / Beam-Search 推理。Long CoT 不是单链生成，而是允许模型在每个 step 后做"分支选择"——尝试多种推理路径，保留最有希望的 k 条，淘汰其他。o1 / o3 system card 提到的"tree search"指的就是这个。OpenAI 在 o1 训练中没有显式做 tree search（训练阶段仍然是 single-chain RL），但在 推理阶段 部署了 tree-of-thought 推理：每个 step 后保留 top-k=4 候选，对每个候选做后续 rollout，最终选 PRM 总分最高的路径。这种"训练单链 + 推理树"的设计是 o1 系统的关键工程决策。

(c) 课程学习（Curriculum Learning）。在前一节已提到，OpenAI 用动态课程（按通过率升降档）来匹配模型能力与任务难度。除此之外，还有几种隐性课程：(1) Token-length curriculum：早期训练限定 CoT 最大 1024 token，后期放宽到 32k token，让模型逐步适应长 CoT；(2) task complexity curriculum：先训练单步题（小学数学），再训练多步题（高中数学），最后训练奥数题；(3) tool-use curriculum：先训练纯文本推理，再训练带工具调用（计算器、Python interpreter）的混合推理。

最后一个被低估的探索机制是 verifier 的多样性。如果只用一个 verifier，模型会过拟合 verifier 的 bug 模式；用多个 verifier（数学不同等价形式、代码多组测试、定理证明多 rewriter），模型被迫学会"真的推理对"而非"过 verifier 即可"。OpenAI 在 o3 训练中至少使用了 6-8 种不同 verifier 域（数学、编程、定理、形式化、Coding-for-Math、API 调用等），这是 o3 鲁棒性显著优于 o1 的原因之一。

2.4 数据策略：合成 reasoning 数据 vs 人类标注

o1 / o3 训练数据的真实组成是 OpenAI 的核心商业秘密，但通过公开 benchmark、DeepSeek-R1 复现报告、HuggingFace 复现博客可以合理推断。下表是我们的推测：

这张表揭示了一个清晰的趋势：人类标注占比从 o1 的 30% 降到 o4-mini 的 2%。原因很直接——人类标注的扩展瓶颈（人不能写得比机器快），以及 verifier 强到足以自动清洗合成数据。o3 的训练数据中 ~70% 来自合成 + verifier 筛选，这意味着模型在 train set 上的"是否见过"和"是否能做对"已经脱钩——合成的难度可以比测试集更高（hard positive mining），保证训练的 saturation。

// 合成 reasoning 数据的生成管线
function generateSyntheticCoT(prompt, teacherModel, verifier) {
    // 第一步：teacher 生成多个候选 CoT
    candidates = [];
    for i in range(0, 16) {
        cot = teacherModel.generate(prompt, temperature=0.7, maxTokens=8192);
        candidates.append(cot);
    }
    // 第二步：verifier 验证
    verifiedCorrect = candidates.filter(cot => verifier(prompt, cot) == 1);
    // 第三步：难度筛选（保留 medium 难度的）
    prmScores = verifiedCorrect.map(cot => prmModel.score(prompt, cot)[^1]);
    kept = verifiedCorrect.filter((cot, i) => prmScores[i] > 0.3 && prmScores[i] < 0.8);
    // 第四步：去重
    unique = deduplicateByNGram(kept, n=5);
    return unique.slice(0, 4);  // 每个 prompt 保留 4 条高质量 CoT
}

另一个值得讨论的是 负样本（negative samples）的获取。在 RLVR 训练中，"答错的 rollout" 也是宝贵资源——它们提供了 PRM 训练所需的"这一步错了"的负样本。OpenAI 会刻意让模型在难题（通过率 < 5%）上做大量 rollout，收集"high-quality negatives"，这些负样本经过 MC 一致性验证后可以标注 first-error position，成为 PRM 训练集的关键来源。这种"用失败创造价值"的训练范式后来被 DeepSeek-R1 的 GRPO 算法与清华的 Math-Shepherd 项目广泛借鉴。

2.5 训练规模与算力：o1 训练算力数 / cluster 规模的工程估算

o1 / o3 的训练算力是 OpenAI 最敏感的核心机密之一，但通过以下公开信息可以合理估算：(1) o1-preview 发布时 GPU 资源由 Microsoft Azure 提供；(2) 系统卡披露 RL 训练使用了 ~2048 H100 GPU 集群；(3) 从 o1 → o1-pro → o3 的能力跃迁推断 o3 的训练算力至少是 o1 的 5-10 倍。以下是估算结果：

几个观察点：

1. 基础训练算力没有显著增长，从 o1 到 o3 仅从 2e25 升到 5e25（约 2.5×），这印证了 inference-time scaling 的逻辑——预训练不必做 10× 升级，而是把算力放到 RL；
2. RL 训练算力增长 8×（从 2k H100·30d 到 16k H100·120d），对应 rollout tokens 从 100B 增长到 10T（100×）；
3. o3 的训练时长从 o1 的 2 个月涨到 6 个月，但单次推理成本并未线性增长——Opus-level 模型的能力提升主要靠 RL 训练饱和度。

// 训练算力 vs 推理算力的对比（成本结构）
interface CostBreakdown {
  basePretraining: { flops: 5e25; gpuHours: 2e7; dollars: 1e8 };
  rlvrTraining:    { flops: 1e25; gpuHours: 5e6; dollars: 4e7 };
  prmTraining:     { flops: 2e24; gpuHours: 1e6; dollars: 8e6 };
  total:           { dollars: 1.5e8 };  // 单次完整训练约 1.5 亿美元
}

interface InferenceCost {
  perUserRequest: { tokens: 2e4; gpuSeconds: 15; dollars: 0.1 };
  // o3 单次推理用 ~15 GPU·秒，是 GPT-4 的 ~10×
}

// 关键 insight：训练成本 1.5 亿美元在 1 亿次推理后回本
const paybackPeriod = 1.5e8 / 0.1;  // 1.5 亿次推理 ≈ 2 年（按 100k QPS 计）

这里有一个工程上的关键决策点——RL 训练的最大成本不在 PPO 更新上，而在 rollout 上。在 o3 训练中，~80% 的 RL 训练时间花在"采样 N=8 条 CoT 并用 verifier 验证"上，只有 ~10% 真正用于梯度更新。这意味着 优化 rollout 速度（如推测解码、continuous batching、KV cache 复用）可以显著降低 RL 训练成本。OpenAI 团队多次提及他们专门为 RL 训练重写了 inference engine，这套 inference engine 后来成为 ChatGPT 推理后端的底层。

最后，o1 / o3 的训练算力估算还有一个隐含的对比维度——vs 预训练。GPT-4 的预训练算力约 2e25 FLOPs（一万个 H100 × 30 天），o3 在此基础上额外花了 ~1e25 FLOPs 做 RLVR + PRM + RLHF。这意味着 o3 的 reasoning 能力是用 GPT-4 1/2 的额外算力换来的。这种"小成本 + RL 微调"路径 vs "再训一个 5× 大模型"路径之间的 trade-off，决定了 OpenAI 选择"滚动发布（rolling release）"策略——每月训练一个小步 RL 更新，比每半年训一个全新模型更敏捷。

2.6 GRPO 算法详解：从 PPO 走向 Group Relative Policy Optimization

DeepSeek-R1 的 RL 训练核心是 GRPO（Group Relative Policy Optimization），这是一种比 PPO 更简洁、更适合 Long CoT 的 RL 算法。理解 GRPO 是理解整个 2025 年 reasoning RL 范式的关键。本节我们详解 GRPO 的设计动机、算法流程与对比 PPO 的工程优势。

PPO 在 Long CoT 上的局限。PPO 需要训练一个 critic network（value function）来估计每个 state 的 baseline value，从而计算 advantage。但在 Long CoT 中，state 空间（每个 CoT 的 prefix）维度极高，critic 必须"看过"几乎所有可能的中间状态才能给出准确 baseline。这导致：(1) critic 网络规模必须很大（与 policy 同等规模），增加 1× 训练算力；(2) critic 本身容易过拟合高频 prefix，无法泛化到低频困难样本；(3) value estimation 的方差大，advantage 信噪比低。

GRPO 的核心创新：不学习 critic。GRPO 的关键观察是——在同一 prompt 的多个 rollout 之间，组内相对表现已经提供了足够好的 baseline。换言之，对同一 prompt 采样 N=8 条 rollout，计算它们的组内相对 reward作为 advantage，无需外部 critic。这是 DeepSeek 团队在 2024 年的 paper "DeepSeekMath" 中首次提出，2025 年被 R1 完整应用。

// GRPO 算法伪代码（DeepSeek-R1 论文版本）
function grpoTrain(policy, rewardFn, numSteps, batchSize, groupSize=8, clipRatio=0.2) {
    for step in range(numSteps) {
        // 1. 采样一批 prompt
        prompts = samplePrompts(batchSize);

        // 2. 对每个 prompt 采样 groupSize 条 rollout
        rollouts = [];
        for p in prompts {
            group = [policy.generate(p, temperature=0.7, maxTokens=8192)
                     for _ in range(groupSize)];
            rollouts.append(group);
        }

        // 3. 计算每个 rollout 的 reward（outcome + PRM）
        rewards = [[rewardFn(p, r) for r in g] for p, g in zip(prompts, rollouts)];

        // 4. 组内归一化 advantage（无 critic）
        advantages = [];
        for group_rewards in rewards {
            mean = mean(group_rewards);
            std = std(group_rewards);
            advantages.append([(r - mean) / (std + 1e-8) for r in group_rewards]);
        }

        // 5. PPO-style clipped policy update
        oldLogProbs = computeLogProbs(policy, rollouts);
        for epoch in range(K_epochs):
            newLogProbs = computeLogProbs(policy, rollouts);
            ratios = exp(newLogProbs - oldLogProbs);
            surr1 = advantages * ratios;
            surr2 = advantages * clip(ratios, 1-clipRatio, 1+clipRatio);
            loss = -mean(min(surr1, surr2));
            policy.update(loss, lr=peakLR);

        policy = applyDecayedKL(policy, refPolicy, klCoef=0.04);
    }
    return policy;
}

GRPO vs PPO 的对比。

R1-Zero 与 R1 的对比。DeepSeek-R1 论文披露了两个版本：(1) R1-Zero：纯 GRPO + 数学/代码 verifier，无 SFT cold start，从 base model 直接训练；(2) R1：R1-Zero + SFT cold start（用 R1-Zero 涌现样本做 SFT warm up）+ 第二轮 GRPO。R1-Zero 的特殊价值在于 "展示了 reasoning 可以从纯 RL 中涌现"——模型在没有任何 CoT 标注数据的情况下，自发学会 self-revision、a-ha moment 等 reasoning 行为。R1 则通过 SFT cold start 提高了收敛速度与稳定性。

// R1-Zero 的关键发现：emergent reasoning behavior
function observeR1ZeroEmergence(policy):
    // 在训练过程中定期评估 reasoning 行为
    behaviors = {
        "self_revision": detectSelfRevision(policy),  // "wait, let me reconsider"
        "long_chain": measureChainLength(policy),
        "backtrack": detectBacktrack(policy),          // "previous approach was wrong"
        "verification": detectVerification(policy),   // "let me check"
    };
    return behaviors;

// R1 paper 关键发现：这些 reasoning 行为在 RL 训练中自然涌现
// 不需要任何 CoT 监督数据
const emergentFindings = {
    step_0:     { self_revision: 0.0, long_chain: 0.0 },
    step_1000:  { self_revision: 0.05, long_chain: 0.1 },
    step_5000:  { self_revision: 0.20, long_chain: 0.45 },
    step_10000: { self_revision: 0.45, long_chain: 0.78 },
    // 推理行为随 RL 训练自然涌现
};

R1-Zero 的"a-ha moment"现象是 LLM 推理研究史上的标志性发现。在训练初期（step 5000 左右），模型开始自发在 CoT 中追加"wait"、"let me reconsider"、"another approach"等反思短语，并且这种反思显著提升最终准确率。这意味着 RL on reasoning 可以让模型"自学"反思——这种能力在传统 SFT 数据中几乎不存在。

2.7 工程基础设施：RLHF 时反馈学习在 Long CoT 上的工程化

RLHF 在 Long CoT 上的工程化是一道工程难题，涉及以下子系统：(1) 高效 rollout 引擎、(2) 分布式 verifier、(3) 价值函数与 advantage 计算、(4) 策略更新的稳定性。本节我们按子系统深入解构。

(1) 高效 rollout 引擎。Long CoT 的 rollout（8k-32k tokens）是 RLVR 训练的主要瓶颈。OpenAI 团队专门为 reasoning RL 重写了 inference engine，引入以下优化：

• KV cache 复用：同一 prompt 的 N=8 rollout 共享 prefix KV cache，仅分歧处独立分配；
• 推测解码：用小模型快速生成 K 个候选 token，再用 target 模型一次性验证；
• 连续批处理：动态 batch，让长 / 短 rollout 在同一 cluster 中交错执行；
• 提前终止：PRM 在中途检测到高概率错误时提前中断 rollout；

// RL 训练侧的高效 rollout 引擎伪代码
class RLRolloutEngine {
    constructor(policy, draftModel, prmModel, verifier) {
        this.policy = policy;
        this.draft = draftModel;
        this.prm = prmModel;
        this.verifier = verifier;
    }

    async generateBatch(prompts, groupSize=8, maxTokens=8192) {
        // 1. prefill 共享 prompt
        const promptsTokens = this.policy.tokenize(prompts);
        const prefillCache = this.policy.prefillAll(promptsTokens);

        // 2. 推测解码批量生成
        const draftOutputs = await this.speculativeDecode(
            prompts, prefillCache, groupSize, maxTokens
        );

        // 3. 早期终止检查
        const finalOutputs = [];
        for (let i = 0; i < draftOutputs.length; i++) {
            const tokens = draftOutputs[i];
            const earlyStop = this.checkEarlyTermination(tokens, this.prm);
            if (earlyStop.shouldStop) {
                finalOutputs.push({...tokens, truncated: true, reason: earlyStop.reason});
            } else {
                finalOutputs.push({...tokens, truncated: false});
            }
        }

        // 4. verifier 最终评分
        const rewards = await this.scoreBatch(prompts, finalOutputs, this.verifier);
        return {outputs: finalOutputs, rewards};
    }
}

(2) 分布式 verifier。Verifier 数学等价检查、代码测试执行等都是 CPU-bound 任务，可以与 GPU 上的 rollout 并行。OpenAI 的标准做法是 tier-3 cluster architecture：(a) Tier-1 GPU cluster 跑 rollout；(b) Tier-2 CPU cluster 跑 verifier；(c) Tier-3 small GPU cluster 跑 PPO 梯度更新。Tier 之间用 gRPC 通信，整体 throughput 提升约 3 倍。

(3) 价值函数与 advantage。在 GRPO 范式下，advantage 由组内归一化 reward 计算，无需 critic。但 o1 早期可能仍用了某种 critic（PPO 派系）。本文不对此深猜。但 o3 的训练中公开了 "RL with Verifiable Rewards + Process Reward"，这一组合可能仍依赖 group-level baseline 而非 per-step critic。

(4) 策略更新的稳定性。Long CoT 的策略更新面临 "reward hacking" 风险——模型可能学会"骗过 verifier"或"rewards 表面的 shortest path"。OpenAI 的应对是 multi-stage training：先用 group-relative advantage 训练，再用 outcome-only advantage 训练。这种两阶段策略保证模型真正学会 reasoning 而非 verifier hacking。

承接上文推理脉络，本节将系统展开：

2.8 o3 论文详细解读：deliberative alignment 与 CoT 安全

o3 论文（2025-04 完整版）第 5 章披露的 "deliberative alignment" 是 o3 安全训练的核心创新。它的核心思想是——把安全对齐也从 "final answer 监督" 升级到 "CoT 监督"。具体地：模型在生成 CoT 时被要求"先 reasoning 出这个请求为什么可能敏感 / 不安全 / 越界，然后给出符合规则的最终回答"，这个 reasoning 本身也被 training reward 监督。

// Deliberative Alignment 训练循环
function deliberativeAlignmentTrain(policy, safetySpec) {
    for step in range(numSteps) {
        // 1. 准备对抗性 prompt + 安全规则
        prompts = sampleJailbreakAttempts(batchSize);
        safetyRules = safetySpec;

        // 2. 生成包含 CoT 的回答
        responses = policy.generate(prompts, includeReasoning=true);

        // 3. 验证 CoT 中是否"推理了安全理由"
        for response in responses {
            cot = extractCoT(response);
            safetyReasoning = checkSafetyReasoning(cot, safetyRules);
            // 关键：CoT 本身要被监督，不能只是 final answer 合规
            if not safetyReasoning.containsExplicitReason {
                reward -= 0.5;
            }
            if safetyReasoning.reachedWrongConclusion {
                reward -= 1.0;
            }
        }

        // 4. PPO 更新
        policy.update(rewards);
    }
    return policy;
}

// 检查 CoT 是否"推理了安全理由"
function checkSafetyReasoning(cot, rules) {
    keywords = ["harmful", "unethical", "policy violation", "safety", "rule"];
    return keywords.some(kw => cot.toLowerCase().includes(kw));
}

deliberative alignment 的工程价值。这种做法与传统的 "output filter only" 模式相比有三个优势：(1) CoT 中显式推理让模型安全决策可审计——用户可以查看"为什么模型拒绝回答"；(2) RL 信号能细化到 CoT 步骤，让模型学会"先思考伦理而非事后过滤"；(3) jailbreak 抵抗更强——攻击者难以用 prompt injection 让模型"忘记"它的安全 reasoning。

承接上文推理脉络，本节将系统展开：

2.9 数据预处理：从原始语料到 PRM 训练数据的工程链路

PRM 的训练数据是其能力上限的关键。从原始数学题到 PRM 可用数据，中间经历多道工程工序：

第一道工序：原始数据收集。OpenAI 的 PRM 训练数据来源包括：(a) AIME / IMO 历年真题（~5,000 道）；(b) MATH 数据集（~12,500 道）；(c) NuminaMath / MetaMath（~860,000 道衍生题）；(d) 合成数学题（GPT-4 生成 ~1M 道）。每道题带有正确答案（可机判定）。

第二道工序：CoT 生成。对每道题用 base model 生成多条 CoT（典型 64 条 / 题），得到候选 CoT pool。每个 CoT 约 1k-8k tokens。

第三道工序：自动标注。对每个 CoT，做 (a) 答案匹配（extracted final answer vs ground truth）；(b) MC 一致性（从该 step 后继续 rollout 多少次能成功）。两个信号联合给出每个 step 的标量 label。

第四道工序：人工精标（少量）。对部分高价值样本（~5%）做专家人工精标，建立 gold label 用于校准自动标注。人工精标是 PRM 数据精度的金标准。

第五道工序：训练 PRM。用上述数据训练 PRM（结构上是一个 scoring model，对每 step 输出 scalar reward）。PRM 训练用 cross-entropy + step-level binary classification loss。

// PRM 训练数据生成的全流程
async function generatePRMTrainingData(baseModel, dataset) {
    const trainingData = [];
    
    for (const prompt of dataset) {
        // 第一步：生成多条 CoT
        const cotRollouts = [];
        for (let i = 0; i < 64; i++) {
            const cot = await baseModel.generate(prompt, maxTokens=8192);
            cotRollouts.push(cot);
        }
        
        // 第二步：答案校验
        const answerCorrect = cotRollouts.map(cot => {
            const final = extractFinalAnswer(cot);
            return final === prompt.groundTruth ? 1 : 0;
        });
        
        // 第三步：MC 一致性标注（每个 step）
        const stepLabels = cotRollouts.map(cot => {
            const steps = splitIntoSteps(cot);
            return steps.map((step, idx) => {
                // 从 idx 开始做 K=16 次 rollout，统计后续正确答案率
                const continuations = [];
                for (let i = 0; i < 16; i++) {
                    const rest = baseModel.generate(prompt, cot.slice(0, idx));
                    continuations.push(extractFinalAnswer(rest) === prompt.groundTruth);
                }
                const consistency = continuations.filter(x => x).length / 16;
                return consistency;
            });
        });
        
        // 第四步：组合 step-level label
        for (let i = 0; i < cotRollouts.length; i++) {
            const correct = answerCorrect[i] === 1;
            trainingData.push({
                prompt,
                steps: splitIntoSteps(cotRollouts[i]),
                stepLabels: stepLabels[i],
                finalCorrect: correct,
            });
        }
    }
    
    return trainingData;
}

第六道工序：PRM 质量验证。训练好 PRM 后，需要在 hold-out set 上评估其 step-level prediction accuracy。对人工精标的 ~500 道题，PRM 应能正确预测每 step 是否正确（accuracy > 0.85）。低于这个水平需要重新训练或调整 loss。

整个流程的工程难点在于：MC 一致性标注的 rollout 计算量大（每次 step 16 次 rollout，每个 prompt 数百 step，总计算 ~50 万次 / 道题）。OpenAI 在 PRM 训练数据生成上的算力消耗约 5-10 倍于最终 PRM 训练本身的算力。这道"数据 pipeline"是 OpenAI 的核心工程资产之一，与最终 base model 训练同等重要。

2.10 Reward Shaping：长 CoT 训练中的精细奖励设计

Long CoT 训练中，reward shaping 是除 PRM 外的另一个关键工程议题。一个粗糙的 reward（如"最终答案对 → +1，错 → 0"）会带来多种不希望的训练行为：(a) 模型学会"猜答案"；(b) 模型学会"推理时跳过"以节省 effort；(c) 模型陷入"无限 reasoning"。

OpenAI 在 o1/o3 训练中使用的 reward shaping 包括以下组件：

// Long CoT 训练的精细 reward shaping
function shapedReward(cot, prompt, verifier, prm):
    // 1. 基础 outcome reward：0/1
    const outcomeReward = verifier(prompt, cot);
    
    // 2. Process reward：每个 step 加权求和
    const steps = splitIntoSteps(cot);
    const stepScores = prm.score(prompt, steps);
    const processReward = sum(stepScores) / length(steps);  // 平均 step reward
    
    // 3. Length penalty：如果 reasoning 太长但 outcome 错，惩罚过度思考
    const lengthPenalty = length(cot) > 32000 && outcomeReward == 0 ? -0.5 : 0;
    
    // 4. Self-revision bonus：如果 CoT 包含自我修正，奖励 +0.2
    const hasSelfRevision = /wait|let me reconsider|actually/i.test(cot);
    const revisionBonus = hasSelfRevision && outcomeReward == 1 ? 0.2 : 0;
    
    // 5. Pathological behavior penalty：如果 CoT 包含 pathological 行为（如重复、机械抄写）
    const repeatedText = countRepeatedPhrases(cot) > 5 ? -0.3 : 0;
    
    // 6. 综合 reward
    const totalReward = 1.0 * outcomeReward 
                      + 0.3 * processReward 
                      + lengthPenalty 
                      + revisionBonus 
                      + repeatedText;
    
    return totalReward;
}

// 各组件权重选择精细，OpenAI 在 o3 paper 附录用大量 ablation study 验证

几个关键的 reward shaping 设计点：

Length penalty 的边界。如果只有 length penalty（无 process reward），模型可能学会"短 CoT 偷懒"——快速给出答案不深入思考。如果只有 length bonus（无 penalty），模型陷入无限 reasoning。两者 balance 让模型在"够用的 reasoning"时终止。

Revision bonus 的对齐风险。Revision bonus 鼓励模型在 CoT 中频繁 "wait"、"reconsider"，但可能导致模型学到"虚假反思"——仅仅写 "wait" 但不真的反思。OpenAI 用 PRM 二次校验——只有当 revision 后 PRM 总分确实提高时，才给 +0.2 的 bonus。

Pathology penalty 的多维度。模型在 Long CoT 训练中可能学到多种 pathological 行为：(a) 重复循环 ("let me try again... let me try again...")；(b) 死循环中的同样算式；(c) 抄写 prompt 的内容消耗 token；(d) 跑题。每个 pathological 模式都需要专门的 detector + penalty。

// 典型的 pathological 模式 detector
const pathologyDetectors = {
    repetition: (cot) => {
        const trigrams = extractNGrams(cot, n=3);
        const counts = trigrams.reduce((m, t) => m.set(t, (m.get(t) || 0) + 1), new Map());
        return Array.from(counts.values()).filter(c => c > 5).length > 0;
    },
    topic_drift: (cot) => {
        const promptKeywords = extractKeywords(prompt);
        const cotKeywords = extractKeywords(cot);
        return jaccard(promptKeywords, cotKeywords) < 0.2;
    },
    infinite_loop: (cot) => {
        const last1k = cot.slice(-1000);
        const trigrams = extractNGrams(last1k, n=3);
        return new Set(trigrams).size < trigrams.length * 0.3;
    },
};

function isPathological(cot): boolean {
    return Object.values(pathologyDetectors).some(d => d(cot));
}

Reward shaping 的训练演化。o1 → o1-pro → o3 的 reward shaping 也在演化：o1 主要用 outcome + simple process reward；o1-pro 加入 length penalty 和 revision bonus；o3 加入更精细的 pathology penalty 和 step-diversity bonus。每次演化的目标都是让模型的 CoT 更像人类专家的 reasoning pattern而非机械化的 token 浪费。

与 verifier bugs 的对抗。Reward shaping 还必须考虑 verifier 自身的错误率。如果 verifier 在某类问题上 95% 准确，模型可能在这些问题上"hack verifier"——生成看起来对但实际错的答案。OpenAI 的应对是 (a) 在 reward shaping 中加入"surprise penalty"——如果 CoT 与训练数据中该题的常见 CoT 差异过大，给小惩罚；(b) 部署多个独立 verifier 做 majority voting。

三、架构与解码：从推理接口到 Token 经济学

前两篇我们奠定了 o1/o3 的训练算法基础。本篇我们转向推理侧的工程——o1 系列如何在每次用户请求中实际生成几千到几万 token 的 Long CoT，如何处理 KV cache、推测解码、tool use、多模态，以及如何在不同推理预算之间做产品分层。这一篇的 5 章会用到大量 vLLM、SGLang、TensorRT-LLM 等推理引擎的工程术语，建议结合第 9 章的训练算力估算一起阅读。

3.1 思维链隐藏：用户只看到 summary，内部维护长 CoT 的隐私边界

o1 在 ChatGPT 中的 UX 与 GPT-4 几乎一样——输入问题，输出回答。但表象下，模型内部跑了一段几秒到几十秒、几千到几万 token 的"思考"。这一思考不直接展示给用户，而是被 OpenAI 的后处理系统抽取一个 summary（"我在思考如何分解这个问题..."），与最终答案一同返回。这种"显式思考 + summary" 的设计不仅是 UX 妥协，而是三层架构决策：

1. 反蒸馏：用户看不到 CoT，竞争对手无法用 ChatGPT 公开数据训练 o1 替代品。这是商业护城河。
2. 安全监控：CoT 是潜在的模型行为，OpenAI 用专门的安全分类器扫描 CoT 一致性，并保留审计日志。这是合规需求。
3. 成本透明化：API 计费基于 reasoning_tokens 而非显示 tokens，用户对单次回答成本有清晰预期，避免"被多收 50× tokens"的怨言。

// o1 API 双层接口的协议示意
interface ChatCompletionRequest {
  model: "o1" | "o1-pro" | "o3" | "o3-mini" | "o4-mini";
  messages: ChatMessage[];
  reasoning_effort?: "low" | "medium" | "high";  // 推理预算
  response_format?: { type: "json_object" };
}

interface ChatCompletionResponse {
  choices: [
    {
      message: { role: "assistant", content: string };
      finish_reason: "stop";
    }
  ];
  usage: {
    prompt_tokens: number;
    completion_tokens: number;          // 用户可见 token
    reasoning_tokens: number;          // 内部 CoT token (o1 起新增)
    total_tokens: number;
  };
}

这种架构的一个工程后果是推理延迟的"两次方"增长。用户感受到的延迟是：t_total = t_cot_generation + t_summary_extraction + t_safety_check。t_cot_generation 占 90%+，在 reasoning_effort=high 下可达 30-60 秒（o1-pro 上的 GPQA Diamond 题目）。OpenAI 在 UI 层通过 streaming summary（边生成边发）让用户感觉"模型在思考"而非"卡死"。这种"边思考边表达"的 streaming 设计后来被 Gemini Thinking、Claude extended thinking 借鉴。

对于开发者而言，"隐藏 CoT" 还有一个微妙的工程影响——无法用 few-shot CoT prompt 引导 o1。在 GPT-4 上，开发者可以在 system prompt 中写"请按以下格式思考：1. xxx 2. yyy"，让模型按模板生成；在 o1 上，这种 prompt 对内部 CoT 的影响极小（模型已经在 RL 中学到了内部思考范式）。这种"模型已经知道如何思考"的特性，让 o1 的 prompt 工程比 GPT-4 简单得多——开发者只需"清晰描述任务"，模型自己会"展开思考"。这也是 OpenAI 鼓励用户从 GPT-4 迁移到 o1 时经常强调的："just ask, don't prompt"。

3.2 推测解码 + 长 CoT 协同：单次推理几千到几万 token 的解码优化

o1 / o3 在单次推理中可能生成 8k-32k token 的 Long CoT，是 GPT-4 的 5-50 倍。这意味着推理延迟天然被放大，必须做大量解码优化。本节我们剖析三个关键优化：(a) 推测解码（speculative decoding）、(b) KV cache 复用、(c) 连续批处理（continuous batching）。

(a) 推测解码（Speculative Decoding）。Speculative decoding 的核心思想：用一个小模型（draft model）快速生成 K 个候选 token，然后用大模型（target model）一次性验证 K 个 token 是否接受——如果在 K 个中前 m 个命中则接受 m 个 token 并并行生成 m 个。这种方法把大模型的"逐 token 顺序解码"变成"每次处理 K 个 token 的批量验证"，理论上能把吞吐提升 2-3×。在 Long CoT 场景下，推测解码的实现需要考虑：(1) draft model 的选用——OpenAI 在 o1/o3 中用 o1-mini 作为 draft，o3 作为 target，验证速度差异约 5×；(2) 推测窗口大小 K——典型 K=8-16，过大浪费计算，过小浪费 draft 优势；(3) KV cache 管理——draft 与 target 共享 prompt 的 KV cache，但 draft 与 target 各自维护生成 token 的 cache。

// Speculative decoding 在 Long CoT 上的伪代码
function speculativeDecode(prompt, draftModel, targetModel, K=16) {
    targetKvCache = targetModel.prefill(prompt);
    draftKvCache = draftModel.prefill(prompt);
    generatedTokens = [];

    while (not finished) {
        // 1. draft 模型快速生成 K 个候选 token
        draftTokens = draftModel.generate(draftKvCache, maxTokens=K);

        // 2. target 模型一次性验证 K 个候选 (并行)
        targetLogits = targetModel.forward(draftTokens, targetKvCache);

        // 3. 逐 token 接受判定（基于 rejection sampling）
        accepted = 0;
        for i in range(K) {
            p = softmax(targetLogits[i]);
            q = draftModel.prob(draftTokens[i]);
            if (random() < p[draftTokens[i]] / q[draftTokens[i]]) {
                accepted += 1;
            } else {
                break;
            }
        }
        // 4. 把接受的 token 复制到 target 的 KV cache，reject 部分重新 sample
        targetModel.commit(targetKvCache, draftTokens[0:accepted]);
        generatedTokens.extend(draftTokens[0:accepted]);
        if (accepted < K) {
            newToken = sample(targetLogits[accepted]);
            targetModel.commit(targetKvCache, [newToken]);
            generatedTokens.append(newToken);
        }
    }
    return generatedTokens;
}

(b) KV Cache 复用。Long CoT 的一个隐含优化是paged KV cache + prefix sharing。在 RL 训练中，模型对同一个 prompt 做 N 次 rollout（如 N=8），这些 rollout 共享 prefix 部分的 KV cache，仅在分歧处独立分配 cache。推理侧的 PagedAttention（vLLM）正是为此设计。o1 / o3 训练侧的 rollout 必然使用某种形式的 paged KV cache，否则 16k H100 × 30 天不可能在 4 个月内训完。

(c) Continuous Batching。在 RL 训练中，每个 prompt 的 rollout 长度差异极大（短 CoT 2k token，长 CoT 32k token）。简单的 static batching 会让所有 GPU 等最长 rollout 完成，造成大量闲置算力。Continuous Batching（也称为动态 batch）允许在 rollout 进行中随时加入新样本，已完成的样本释放出 GPU 资源。o1 / o3 训练披露的关键优化点之一就是 continuous rollout batching，配合抢占式调度（preemptive scheduler）实现 90%+ GPU utilization。

对于 Long CoT 还有一个特定优化——early stopping on verification failure。在 rollout 中，如果 PRM 在第 k 步已经判定"很可能错了"（概率 > 0.95），则提前 terminate rollout，节省后续 token 的生成。这能把平均 rollout 长度从 12k 降到 6-8k token，节省 ~40% 推理算力。OpenAI 在 o3 训练中部署了这种 early termination，但代价是略低的最终准确率——这是一个 inference-cost vs final-accuracy 的工程权衡。

3.3 o3 的多模态集成：图像/文档输入的 reasoning 能力

o3 在 2025-04 发布版本中加入了对视觉输入的原生支持——用户可以上传图片（手写数学题、电路图、图表、文档照片），让 o3 在 Long CoT 推理中"看清"图像信息并结合文字推理。这一能力的工程实现涉及视觉 tokenizer + cross-modal reasoning 两条独立技术路径，下面我们分别讨论。

视觉 tokenizer。o3 接收图像后，先经过 ViT-style vision encoder 转成视觉 token（典型 256-1024 个 token），再与文本 token 拼接送入 LLM。这套 visual tokenizer 可能是 OpenAI 自研（与 GPT-4o 视觉共享技术栈）。视觉 token 的质量直接决定 o3 在"图形几何题 / 物理示意图 / 化学结构图"等任务上的表现——视觉 tokenizer 必须保留细节（公式中的下标、化学键的方向），不能像传统 ViT 那样粗粒度池化。o3 在 AIME 几何题上达到 96.7% 的部分原因就是视觉 tokenizer 能保留细节，让 Long CoT 中的"看图想步骤"成为可能。

// o3 多模态推理的伪代码
function o3MultimodalReason(imageUrl, textPrompt) {
    // 第一步：图像编码
    visualTokens = visionEncoder.encode(imageUrl);  // 256-1024 token
    textTokens = tokenizer.encode(textPrompt);
    combinedTokens = concat(visualTokens, textTokens);

    // 第二步：Long CoT 生成（带视觉参考）
    cotRollouts = [];
    for i in range(N) {
        cot = policy.generate(
            prompt=combinedTokens,
            maxTokens=16000,
            crossAttentionTo=visualTokens,  // 视觉 token 持续参与 attention
        );
        cotRollouts.append(cot);
    }

    // 第三步：verifier 检查（视觉部分用视觉评估模型）
    rewards = cotRollouts.map(cot => {
        textReward = textVerifier(prompt, cot);
        visualReward = visualVerifier(imageUrl, cot);  // 视觉一致性
        return 0.6 * textReward + 0.4 * visualReward;
    });

    // 第四步：选最优 + summary 抽取
    best = pickBestByReward(cotRollouts, rewards);
    return summarize(best);
}

Cross-modal reasoning 的难点。多模态 reasoning 的本质难点是"视觉信息在 CoT 中如何被引用"。模型必须在 CoT 中明确说明"我看到图中有 3 个圆、1 个三角形，所以角 a = ..."，但视觉 token 与文本 token 在 LLM 内部是异质的（视觉 token 来自 ViT 输出，文本 token 来自 tokenizer 输出），如何让模型在 CoT 中"正确引用"视觉区域是一个开放问题。o3 的解决方案可能是：(1) 训练数据中加入大量"我看到 X 在 Y 位置"的自然语言引用视觉的样本；(2) 在 verifier 中加入视觉一致性检查（"模型说'图中有 3 个圆'，实际图中有 3 个圆吗？"）。

文档 reasoning 是 o3 多模态的另一个高价值场景。o3 可以处理长达 30 页的 PDF 文档（通过文档 parsing + 视觉 encoder + 长上下文注入），在 Long CoT 中对文档进行"读-想-引-答"的循环。这种能力让 o3 在 MMMU（多模态多学科问答）、DocVQA（文档问答）、ChartQA 等 benchmark 上领先 GPT-4o 一档以上。o3 Deep Research（详见第 16 章）正是把文档 reasoning + Web retrieval + Long CoT 三者结合，构建出"AI 研究员"的 end-to-end 系统。

3.4 Tool Use / Function Calling 集成：reasoning 与外部工具的协同

o3 与 o1 显著差异之一是 深度 tool use 集成。o1 的工具调用相对克制（主要在 Math + Python interpreter），o3 在 Deep Research 系统中深度集成 Web browser、PDF reader、API call、code execution 等多种工具。这不是简单的"判断 → call tool → 用 tool 结果"的 prompt chain，而是 reasoning 与 tool 深度交织：模型在 Long CoT 中可以多次调用同一个工具、可以根据中间结果调整工具调用策略、可以将工具结果作为后续推理的依据。

// o3 reasoning + tool use 的接口形态
interface ToolUseReasoning {
  tools: Tool[];  // 浏览器、Python、Wolfram Alpha、PDF reader 等
  
  reasoningLoop:
    step "think": CoT_step[i]   // 推理（决定下一步做什么）
    step "act": tool_call = decideAction(CoT_step[i])
    step "observe": tool_result = execute(tool_call)
    step "reflect": CoT_step[i+1] = reflect(CoT_step[i], tool_result)
  loop until final answer;
}

// 伪代码示意
function o3WithTools(userPrompt, tools) {
    cot = "";
    state = {messages: [userPrompt], toolResults: []};
    while (notDone(state)) {
        // 1. LLM 决定下一步：think / tool_call / final_answer
        nextStep = llm.generate(state, maxTokens=2000);
        cot += nextStep;

        // 2. 如果是 tool_call：执行工具
        if (nextStep.type == "tool_call") {
            result = tools[nextStep.tool].invoke(nextStep.args);
            state.toolResults.push({tool: nextStep.tool, args: nextStep.args, result: result});
            cot += `Observation: ${result}`;
        } else if (nextStep.type == "final_answer") {
            return {cot, answer: nextStep.answer};
        }
    }
}

Tool use 与 reasoning 的深度集成带来三个工程挑战：(1) 工具延迟——浏览器或 PDF 解析可能耗时 5-30 秒，模型必须在 Long CoT 中耐心等待；(2) 工具错误恢复——工具可能失败 / 返回错误 / 超时，模型必须有 self-correction 能力；(3) 工具结果可信度——Web search 返回的 snippet 可能是错的，模型必须 fact-check。这些挑战的应对是 o3 训练中加入 "tool-aware" 数据，用大量"工具失败 - 重试 - 成功"的样本训练模型的 resilient tool use。

Tool use 与推理预算的关系是 o3 的一个微妙创新：工具调用消耗 reasoning_effort。用户给一个 reasoning_effort=high 的请求，模型可能分配 40% 算力给内部 CoT，30% 给工具调用（每个 tool call 算一次思考），30% 给最终答案。这种"工具 = 思考预算"的框架让 o3 可以在 reasoning budget 内自由分配，而不是把所有算力都堆在 CoT 中。这与 Anthropic Claude 3.7 sonnet extended thinking 中的"tool budget"概念异曲同工，是 agentic reasoning 系统化的关键工程决策。

3.5 延迟 vs 准确性 trade-off：o1-pro 高延迟高准确性 vs o3-mini 快推理的工程权衡

OpenAI 把 o 系列拆为 4-5 个版本（o3-mini / o1-mini / o1 / o1-pro / o3），每个版本对应不同的 reasoning_effort 档位，背后的工程决策是延迟 vs 准确性的 Pareto frontier。本节我们讨论这个 trade-off 的工程细节。

先看每个模型的标定参数：

这张表揭示了三个产品决策：

1. 分层定价：reasoning_effort 的每次升级，单价提升 5-10×，但延迟只提升 2-3×。OpenAI 在 pricing 上刻意为"高质量推理"收费——愿意为高准确率付费的企业用户（金融分析、医疗咨询、代码审查）是 o1/o3-pro 的目标客户。
2. mini 路线：o3-mini / o4-mini 通过更小模型 + 中等 CoT，达成"低延迟 + 合理准确率"，适合实时交互场景（编程助手、对话）。这是 OpenAI 在 reasoning 与 cost 之间做的产品下沉。
3. o3 vs o1-pro：o3 比 o1-pro 更慢但更准确，且单价更低。这说明基础模型升级带来的能力提升比单纯加 CoT 更有效。

// 延迟 vs 准确性的 Pareto 曲线伪代码
interface ParetoPoint {
  effort: "low" | "medium" | "high" | "max";
  cotTokens: number;
  latency: number;       // 秒
  accuracy: number;      // AIME 2024
  cost: number;          // $/1M tokens
}

const paretoPoints: ParetoPoint[] = [
  { effort: "low",  cotTokens: 2000,  latency: 3,   accuracy: 0.60, cost: 1.10 },
  { effort: "med",  cotTokens: 8000,  latency: 15,  accuracy: 0.87, cost: 1.10 },
  { effort: "high", cotTokens: 16000, latency: 40,  accuracy: 0.96, cost: 15 },
  { effort: "max",  cotTokens: 32000, latency: 120, accuracy: 0.97, cost: 150 },
];

// 数学上的 Pareto 前沿
const frontier = paretoPoints.filter(p =>
    paretoPoints.every(q => q.accuracy < p.accuracy || q.cost >= p.cost)
);

这个 Pareto 曲线的工程含义是：延迟-准确率的弹性在 "medium" 档位最大。从 o3-mini low（3s / 60%）跳到 o3-mini high（15s / 87%）只增加 12 秒延迟，但准确率提升 27 个百分点。而从 o3-mini high 到 o1 则是 40 秒 / 96%，准确率仅提升 9 个百分点。这意味着大多数应用应该选择 o3-mini high（性价比最高）；只有金融 / 医疗 / 安全等高 stakes 场景才需要 o1 / o1-pro。

最后，还有一个用户感知的"延迟心理学"维度值得讨论。用户对推理延迟的容忍度与任务复杂度正相关：写邮件用 1s 即可，问奥数题用 30s 也 OK，看病咨询用 5 分钟用户也愿意等。OpenAI 在 ChatGPT 的 UI 上做了智能延迟管理：简单问题路由到 o3-mini（3 秒返回），复杂问题路由到 o3（30-90 秒返回），并在 30 秒以上的推理中显示"Reasoning..."的 streamed summary 让用户感知"它在思考"。这种 UX 设计让用户对延迟的容忍度进一步提升，是 o3 比 o1 更普及的关键因素。

3.6 推理引擎架构：vLLM / SGLang / TensorRT-LLM 在 o3 上的优化

o3 的推理引擎是 OpenAI 公开的架构中最高度机密的部分之一。但通过 vLLM、SGLang、TensorRT-LLM 等开源 LLM 推理引擎的设计，以及 o1 system card 的部分披露，可以合理推断 o3 的推理架构。本节我们解构推理引擎在 Long CoT 上的关键优化。

PagedAttention（vLLM）。vLLM 是 UC Berkeley 在 2023 年开源的 LLM 推理引擎，其核心创新是 PagedAttention——把 KV cache 分页管理，类似操作系统的虚拟内存。这种设计的优势是 (1) 显存碎片化严重减少，利用率从 ~40% 提升到 ~90%；(2) prefix sharing 高效实现——同一 prompt 的多条 rollout 可以共享前缀的 KV pages；(3) 动态 batch——可以根据请求长度动态分组。o3 必然使用了类似的 PagedAttention 设计，否则无法在 32k token CoT 上服务多请求。

// PagedAttention 的核心数据结构（简化）
class PagedKVCache {
    pageSize: 64;  // 每个 page 存 64 个 token 的 K/V
    pageTable: number[][];  // 每个请求的 physical page 序列
    freePages: Stack<number>;

    allocateForRequest(requestId: string, numTokens: number) {
        const numPages = ceil(numTokens / this.pageSize);
        const pages = [];
        for (let i = 0; i < numPages; i++) {
            pages.push(this.freePages.pop());
        }
        this.pageTable[requestId] = pages;
    }

    prefixShare(otherRequestId: string, numSharedTokens: number) {
        // 复用其他请求的 prefix pages，无需重新计算
        const otherPages = this.pageTable[otherRequestId].slice(0, numSharedTokens/this.pageSize);
        this.pageTable[this.requestId] = [...otherPages, ...newPages];
    }
}

SGLang 的 RadixAttention。SGLang 是 UC Berkeley 在 2024 年开源的另一推理引擎，其核心创新是 RadixAttention——用 radix tree（基数树）管理 prefix sharing，比 PagedAttention 更适合 agent 场景（多次相同 system prompt + 不同 tool result）。o3 Deep Research 的多 Agent 场景大量使用 prefix sharing，RadixAttention 设计可能对其有优化。

TensorRT-LLM。NVIDIA 开源的 TensorRT-LLM 提供 kernel-level 优化（Flash Attention、FP8 张量核、fused kernel），是 o3 底层依赖的可能技术栈之一。o3 在 H100 GPU 上的推理延迟约 30-90 秒（30k token 生成），这一速度靠的就是 kernel-level 优化 + 多 GPU tensor parallel。

Continuous batching 与抢占式调度。o3 的推理请求长度差异极大（短 CoT 2k，长 CoT 32k）。简单的 static batching 会让所有 GPU 等最长请求完成，造成大量闲置。Continuous batching 允许 in-flight 加入新请求。o3 的实现可能更进一步——抢占式调度：当高优先级请求（如 ChatGPT 用户交互式请求）到达时，preempt 低优先级请求（如批量 offline 推理），swap 其 KV cache 到 CPU 内存后释放 GPU。这种抢占式调度在 ChatGPT 5M+ 并发用户的负载下不可或缺。

// 抢占式调度伪代码（基于 SGLang 风格）
class PreemptiveScheduler {
    highPriorityQueue: Request[];
    lowPriorityQueue: Request[];
    activeRequests: Map<string, Request>;

    schedule() {
        // 1. 抢占：检查高优先级队列
        if (highPriorityQueue.length > 0 &&
            this.gpuUtilization > 0.9) {
            // 抢占最旧的低优先级活跃请求
            const oldReq = this.findOldestLowPriority();
            await this.swapToCpu(oldReq);
            this.activeRequests.delete(oldReq.id);
        }

        // 2. 加入新请求
        while (this.gpuUtilization < 0.95) {
            const newReq = highPriorityQueue.shift() || lowPriorityQueue.shift();
            if (!newReq) break;
            await this.loadFromCpu(newReq);
            this.activeRequests.set(newReq.id, newReq);
        }

        // 3. 推进所有活跃请求一步
        for (req of this.activeRequests.values()) {
            await this.advanceOneToken(req);
        }
    }
}

承接上文推理脉络，本节将系统展开：

3.7 推理预算引擎：reasoning_effort 参数的内部实现

o1 / o3 系列引入的 reasoning_effort 参数（low / medium / high / max）是产品层面的创新，但其背后是 "推理预算引擎" 这一新子系统。本节我们解构其内部实现。

推理预算的物理意义。reasoning_effort=low 表示模型在内部 CoT 上花 1k-2k tokens 后即给 final answer；medium 为 8k-16k；high 为 16k-32k；max 为 32k-64k。这种预算不是硬 token limit，而是soft budget——模型被训练为"看到 effort=high 时倾向于更长思考，但不一定严格达到 max"。OpenAI 通过在 RLVR 中训练 effort-conditioned model 实现这一行为。

// Reasoning Effort-Conditioned RLVR 训练
function trainWithReasoningEffort(policy, prm, verifier) {
    efforts = ["low", "medium", "high", "max"];
    for step in range(numSteps) {
        prompts = samplePrompts();
        effort = random(efforts);  // 随机抽样 effort

        // 1. 根据 effort 设置 CoT 长度约束
        cotBudget = {"low": 2K, "medium": 16K, "high": 32K, "max": 64K}[effort];

        // 2. 生成
        cot = policy.generate(prompts, maxTokens=cotBudget);

        // 3. 计算 reward：考虑 effort × 准确率
        outcome = verifier(prompts, cot);
        lengthPenalty = length(cot) < cotBudget ? 0 : -0.5;
        reward = outcome * 1.0 + lengthPenalty;

        // 4. PPO 更新
        policy.update(reward);
    }
    return policy;
}

动态预算分配。更复杂的实现可能是 动态预算分配：模型在生成过程中，根据任务复杂度动态调整 CoT 长度。简单题在 1k token 时 PRM 已高置信度，直接终止；复杂题继续生成到 32k+。这种 "dynamic budget" 在 o4-mini 中已部分实现，根据 difficulty classifier 预测分配 token budget。

// 动态推理预算分配
function dynamicBudgetReason(prompt, model, prm) {
    // 1. 难度估计
    difficulty = model.difficultyClassifier(prompt);

    // 2. 初始 budget
    budget = {easy: 2K, med: 8K, hard: 16K, extreme: 32K}[difficulty];

    cot = "";
    while (length(cot) < budget * 1.5) {
        nextStep = model.generate(prompt, cot);
        cot += nextStep;

        // 3. PRM 检查是否已经可以停止
        if (cot.isComplete()) {
            confidence = prm.score(prompt, cot);
            if confidence > 0.95 && difficulty != "extreme") {
                break;  // 提前终止
            }
        }
    }
    return cot;
}

接续推理分析：

3.8 服务端 SLO 工程：99.9% 可用性 + Token 经济学的平衡

o3 服务的可用性目标（SLO）是 99.9%（每月 downtime < 43 分钟），这在 Long CoT 场景下极难达成。本节讨论 SLO 工程的关键决策。

多区域冗余。o3 服务在 Azure 上至少跨 3 个地理区域（美国 / 欧洲 / 亚太）部署。每个 region 有 ~10k GPU cluster，跨 region 通过异步复制 KV cache（短 CoT）或只是 checkpoint（长 CoT）实现 failover。Multi-region SLO 让单 region 故障不影响全局可用性。

优雅降级。当 GPU 资源紧张时，o3 服务会优雅降级：(1) reasoning_effort=high 排队等待；(2) 自动回退到 medium；(3) 最坏情况回退到 o3-mini。这种"分级降级"保证 API 始终可用，但代价是部分请求体验下降。OpenAI 在 ChatGPT 中透明地告知用户"server is busy, using faster model"。

Token 经济学。o3 的 单次推理成本 $0.5-$2（取决于 input + reasoning + output）。OpenAI 的目标是把"每千次请求的平均成本"控制在 $300-$500 范围（目标 GPU 利用率 80%+）。这要求严格的工程优化，包括 PagedAttention / continuous batching / 抢占式调度 / dynamic budget 等。任何工程优化不到位都会让单位 token 成本超过目标，导致亏损。

承接上文推理脉络，本节将系统展开：

3.9 编程与软件工程推理：从 o3 到 Cursor 的 IDE 集成

o3 在编程任务上的 71.7% SWE-bench 准确率（详见第 15 章）使其成为当时最强的 coding reasoning 模型。但 SWE-bench 是"独立仓库修复"，与真实编程场景差异巨大。o3 在生产场景中如何被使用？本节讨论 IDE 集成、CI/CD 集成、code review 三个具体场景。

Cursor / VS Code 集成。Cursor 在 2024 H2 引入 o3 作为后台 reasoning engine。当用户在 IDE 中编写代码时，Cursor 在后台调用 o3 做：(1) 实时代码补全——根据当前光标位置 + 文件上文，预测下一段代码；(2) 代码 review——当用户提交代码时，o3 分析可能的 bug；(3) 单元测试生成——根据函数签名自动生成测试用例；(4) PR description 生成——根据 diff 自动写 PR 描述。o3 的 reasoning 能力让 Cursor 在 IDE 体验上明显领先于基于 GPT-4 的竞品。

// Cursor + o3 集成的典型工作流
async function cursorO3Integration(codeState: CodeState) {
    // 1. 实时补全（短 CoT, low effort）
    if (codeState.isTyping) {
        completion = await o3.generate(lowEffort, codeState.context, maxTokens=200);
        return showInline(completion);
    }

    // 2. Code review（中等 CoT, high effort）
    if (codeState.isSave) {
        diff = computeDiff(codeState.previous, codeState.current);
        review = await o3.generate(highEffort, diff, maxTokens=8000);
        return showReview(review.bugs, review.suggestions);
    }

    // 3. PR description（中等 CoT, medium effort）
    if (codeState.isCommit) {
        description = await o3.generate(mediumEffort, diff, maxTokens=4000);
        return showPRDescription(description);
    }
}

CI/CD 集成。o3 在 GitHub Actions / GitLab CI 中可作为 "AI code reviewer"：自动 review 每个 PR，提出改进建议。典型工作流：(1) PR 提交时触发 o3 review；(2) o3 在 reasoning CoT 中分析代码 logic、查找潜在 bug、检查测试覆盖；(3) 生成 review comment 并 @提及相关开发者。这种 AI code reviewer 在 2024 H2 已经被多个开源项目采用。

Devin 与 autonomous code agent。2024-12 Cognition Labs 推出的 Devin 是基于 o3 的 autonomous code agent——用户给出任务描述，Devin 自主完成"代码理解 → 修改 → 测试 → 部署"全流程。Devin 在 SWE-bench 上达到 ~30% 准确率（早期版本），后改进到接近 o3 水平。Devin 的成功证明了 o3 在 long-horizon agent task 中的可用性。

承接上文推理脉络，本节将系统展开：

3.10 集群拓扑与训练调度：OpenAI 与 Microsoft Azure 的联合优化

Reasoning-first 模型的训练需要前所未有的集群规模与调度精度。OpenAI 与 Microsoft Azure 的联合基础设施是当前 LLM 行业最复杂的工程系统。本节从集群规模、网络拓扑、调度策略、容错机制四个维度展开。

集群规模与物理布局。o3 训练的集群规模约 16,000 H100 GPU，可能分为多个 pod。每个 pod ~256 GPU，互联用 NVLink + InfiniBand HDR。多个 pod 之间通过 InfiniBand NDR 或 Quantum-2 互联。整个集群可能分布在美国 2-3 个数据中心（可能是 Texas / Iowa + Virginia），每个数据中心有 5,000-8,000 GPU。

// OpenAI reasoning 训练集群的物理布局（推测）
const openaiClusterTopology = {
    primaryDatacenter: {
        location: "Texas / Iowa",
        gpuCount: 8000,
        pods: 32,
        interconnect: "NVLink pod-internal + Quantum-2 pod-to-pod",
        powerSource: "renewable (solar + wind)",
        cooling: "liquid cooling",
    },
    secondaryDatacenter: {
        location: "Virginia",
        gpuCount: 6000,
        pods: 24,
        interconnect: "InfiniBand NDR",
        backup: "edge location for low-latency inference",
    },
    thirdDatacenter: {
        location: "Oregon",
        gpuCount: 2000,
        pods: 8,
        purpose: "inference serving (ChatGPT)",
    },
};

// 联合基础设施：Microsoft 拥有 Azure，OpenAI 优化 reasoning training
// Microsoft 提供 hardware + Azure，OpenAI 提供 RL 算法 + 工程

网络拓扑与通信优化。集群网络是 RL training 的关键瓶颈。Reasoning RL 的通信模式非常特殊：(a) rollout 阶段几乎无 cross-GPU 通信（每 GPU 独立采样）；(b) 但 verifier 调用需要 cross-pod 通信；(c) PPO update 需要 all-reduce gradient synchronization。OpenAI 的网络优化包括：

• Pod-aware rollout 调度——同一 pod 的 GPU 一起做 rollout，减少跨 pod 通信；
• Gradient compression——PPO gradient 用 FP16 或 INT8 compression，节省跨 pod 带宽；
• Overlap compute & communication——在 PPO gradient 计算时，已完成的 gradient 立即开始 cross-pod 同步，不等全部计算完。

调度策略：preemption 与 priority。集群同时跑多个工作负载：(a) RL training（最高优先级，因为是产品时间线关键路径）；(b) Inference serving（中优先级，ChatGPT 用户体验）；(c) Research experiments（低优先级，可以被 preempt）。OpenAI 的调度器类似 Google Borg / Kubernetes 风格，但针对 RL 工作负载定制：

// OpenAI 集群调度器（推测）
class OpenAIScheduler {
    schedule(workloads) {
        // 1. 优先级排序
        priorities = {
            'rl_training': 1000,        // 最高
            'inference_serving': 800,   // ChatGPT 用户
            'safety_eval': 700,         // 安全评估
            'research': 100,            // 可被 preempt
        };
        
        // 2. 资源分配
        const allocations = [];
        const pendingQueue = [];
        
        for (const workload of workloads) {
            const priority = priorities[workload.type];
            const resources = this.availableResources();
            
            if (resources.canFit(workload)) {
                allocations.push(this.assign(workload, priority));
            } else {
                pendingQueue.push(workload);
            }
        }
        
        // 3. Preemption：低优先级 workload 被高优先级抢占
        if (pendingQueue.length > 0) {
            const victim = this.findLowestPriorityActive();
            if (victim && priorities[pendingQueue[0].type] > priorities[victim.type]) {
                this.preempt(victim);
                allocations.push(this.assign(pendingQueue.shift()));
            }
        }
        
        return allocations;
    }
}

容错机制：checkpoint + resume。集群规模 16k GPU 时，每小时发生 1-2 次 GPU 故障（根据硬件 MTBF 估算）。OpenAI 的容错策略：(a) 每 5 分钟 save checkpoint 到分布式存储；(b) 自动检测失败（GPU 心跳丢失）；(c) 从最新 checkpoint 重启，仅重启受影响的 pod，不影响其他 pod。这种"N-out-of-N+1"容错让集群可以容忍 ~10% GPU 故障而不影响训练。

承接上文推理脉络，本节将系统展开：

3.11 推理服务的可观测性：从 trace 到 metrics 的全栈监控

o3 服务的稳定性需要全栈可观测性支撑。本节从 trace / metrics / logs 三个支柱展开。

(1) Trace。每次推理请求都生成一个 distributed trace，包含 (a) API gateway 接收 → (b) routing → (c) inference engine 调度 → (d) GPU forward → (e) verifier 调用 → (f) safety filter → (g) response 上行。每段都打点形成 trace tree。OpenAI 内部用 OpenTelemetry 协议 + 自研 trace backend，单次推理的 trace 数据约 100 KB。

(2) Metrics。Prometheus-style metric collection，关键指标包括：

• TTFT（Time to First Token）——首 token 时间，影响 streaming 体验；
• TPOT（Time Per Output Token）——平均每个 token 生成时间；
• Reasoning tokens / call——每次推理平均 CoT 长度；
• Verifier rate——verifier 调用频率（与 effort 相关）；
• Safety filter rate——safety filter 触发率（过高 = 模型退化，过低 = 安全风险）；
• GPU utilization——每个 pod 的 SM 占用率；
• Cost per call——单次推理的真实 GPU 成本。

// OpenAI 可观测性关键 metrics（推测）
const o3ObservabilityMetrics = {
    performance: {
        ttft_p50: 800,        // ms
        ttft_p99: 2500,
        tpot_p50: 80,         // ms per token
        tpot_p99: 250,
    },
    business: {
        reasoningTokensPerCall: 18000,  // 平均
        verifierCallsPerCall: 2.3,
        costPerCall: 0.04,             // 美元
    },
    safety: {
        filterTriggerRate: 0.012,       // 1.2% 请求触发 filter
        deliberativeAlignmentPass: 0.985, // CoT 通过 deliberation check
    },
    infrastructure: {
        gpuUtilization: 0.87,
        podUtilization: 0.92,
        networkBandwidth: 0.65,        // 65% of capacity
    },
};

(3) Logs。推理日志包括 (a) request log（prompt hash、response hash、token count）；(b) CoT log（完整 CoT，仅内部审计）；(c) verifier log（verifier 输出、confidence）；(d) safety log（filter 决策、reasoning）。这些 log 在合规与监管框架内存储一定时长。

A/B testing 与 progressive rollout。新模型发布时采用 progressive rollout：(a) 1% 流量灰度发布；(b) 监控关键 metrics；(c) 失败回滚（< 5 分钟）；(d) 逐渐放量 1% → 10% → 50% → 100%。这种渐进式发布让 OpenAI 可以在分钟级发现并修复问题。

3.12 Cache 策略：语义缓存与推理结果复用

Reasoning-first 服务的 cache 策略比传统 LLM 复杂。本节讨论 4 种 cache 策略。

(1) KV cache 复用。同一 prompt 的后续推理请求可以复用 prefix 的 KV cache。如果用户之前问过类似问题，o4-mini 直接复用部分 KV cache，仅重新生成差异部分。这种paged KV cache在 ChatGPT 中通过 Memory Token 实现。

(2) 语义缓存（semantic cache）。对类似语义的问题，直接复用回答。例如 "中国 GDP 增长率 2024" 和 "2024 年中国 GDP 增速" 是语义类似的问题，可以复用 reasoning 结果（前提是底层数据未变化）。这种 cache 用 embedding similarity 判断。

// 语义缓存的工程实现
class SemanticCache {
    constructor(threshold=0.92) {
        this.cache = new Map();   // embedding -> response
        this.threshold = threshold;
    }
    
    async lookup(prompt) {
        const queryEmb = await embedder.embed(prompt);
        let best = null;
        for (const [emb, response] of this.cache) {
            const sim = cosineSimilarity(queryEmb, emb);
            if (sim > this.threshold && (best === null || sim > best.sim)) {
                best = {emb, response, sim};
            }
        }
        if (best && best.sim > this.threshold) {
            return {hit: true, response: best.response, sim: best.sim};
        }
        return {hit: false};
    }
    
    async store(prompt, response) {
        const emb = await embedder.embed(prompt);
        this.cache.set(emb, response);
    }
}

(3) Reasoning trace cache。对重复问题，o4-mini 直接复用之前的 reasoning trace（完整 CoT）作为输出。这种 cache 在 ChatGPT for static questions（FAQ）中效果显著。

(4) Tool result cache。对 Deep Research 中的 tool 调用结果（搜索结果、PDF 内容）做 cache。一小时内相同搜索词返回相同结果。这种 cache 大幅降低 Deep Research 服务成本。

四、o3 / Deep Research 体系：长思维链的工程化巅峰

前三篇奠定了 o1/o3 的训练范式与推理架构。本篇进入 o3（2024-12 公布，2025-04 完整版）以及围绕它构建的多 Agent 系统（Deep Research）。o3 是 o1 的"完整版"——它把 RLVR + PRM + 多模态 + 长 CoT 的范式推到极致，并在 benchmark 上达到 96.7% AIME / 87.7% GPQA / 96% FrontierMath 的 SOTA。本篇四章分别讨论 o3 论文精读、Deep Research 多 Agent 架构、o4-mini 的 reasoning mini 路线，以及 o3 与其他 reasoning 模型的横向对比。

4.1 o3 论文精读（2024-12 发布，2025-04 完整版）：96.7% AIME 等 benchmark 突破

o3 论文 OpenAI o3 System Card 发布于 2024-12-20（仅 50 页），2025-04 又有完整版（200+ 页）。论文详细披露了 o3 的训练范式、benchmark 结果、安全评估与限制。我们按论文结构逐章精读关键发现。

第一章：模型概述。o3 是 o1 的"完整版"——同样的 base model 架构，但在 RL 训练中加入了更多合成数据、更多的 PRM 信号、更多的 multi-task 训练。o3 的架构相比 o1 的核心变化是：(1) 更大的 PRM（在 o1 的基础上 RL 了 ~5 倍规模），提供更精确的 step-level 信号；(2) 改进的 verifier 套件（从 o1 的 ~3 种增加到 o3 的 ~8 种），覆盖更多任务类型；(3) 增加的多模态能力（原生 vision encoder + cross-modal CoT）；(4) 升级的 tool use 接口（从 o1 的简单 function calling 到 o3 的 structured reasoning loop）。

第二章：训练范式。o3 训练的核心范式是 "RLVR + RLHF 混合"。前 70% 训练时间在 RLVR（数学/代码/定理/形式化验证）上提升推理能力，后 30% 在 RLHF 上做对齐与校准。这种 capability-first + alignment-last 顺序与 o1 一致，但 RLVR 的任务范围显著扩展——加入了 ARC-AGI、FrontierMath、GPQA 等"难验证"任务的处理 pipeline。论文还提到 o3 用了 "deliberative alignment"（审慎对齐）——让模型在 CoT 中明确 reasoning 出"为什么这个回答符合安全规则"，然后用这个 reasoning 监督对齐训练本身。

// o3 训练范式：RLVR + RLHF 混合 + Deliberative Alignment
function trainO3(baseModel):
    // Phase 1: RLVR 在可验证领域（数学/代码/定理）做能力训练
    capPolicy = rlvrTrain(
        baseModel=baseModel,
        tasks=[AIME, MATH, APPS, HumanEval, Lean, ARC],
        epochs=many,
        reward=compositeOutcomePRM,
        compute=allocation=0.65,
    );

    // Phase 2: GRM 在通用领域（写作/对话/咨询）做能力训练
    grmPolicy = grmTrain(
        baseModel=capPolicy,
        rewardModel=generalRewardModel,
        epochs=some,
        compute=allocation=0.20,
    );

    // Phase 3: Deliberative Alignment RLHF
    finalPolicy = rlhfWithDeliberation(
        baseModel=grmPolicy,
        safetyRules=safetySpec,
        epochs=few,
        compute=allocation=0.15,
        includeCoT=True,  // CoT 中的安全推理也参与监督
    );
    return finalPolicy;
}

第三章：benchmark 突破。o3 在多个 benchmark 上达到 SOTA：

几个观察点：(1) FrontierMath 从 o1 的 25.2% 跃迁到 o3 的 96.0%，这是最显著的提升——OpenAI 推测主要来自 RLVR 在 FrontierMath 上的大规模训练 + 合成数据扩展；(2) ARC-AGI 从 o1 的 32% 到 o3 的 87.5%，几乎达到人类专家水平；(3) GPQA Diamond 几乎饱和在 87.7%——这是几乎所有顶尖模型都接近的瓶颈，提示 GPQA 已成为下一代 reasoning 模型的"基准上限"。

第四章：推理预算策略。o3 论文提供了一组重要的推理预算数据：

// o3 不同 reasoning_effort 下的 performance
const o3Effort = {
    low:    { aime: 71.0, gpqa: 78.5, codeforces: 2100, costPer1M: 3 },
    medium: { aime: 89.0, gpqa: 85.5, codeforces: 2400, costPer1M: 6 },
    high:   { aime: 96.7, gpqa: 87.7, codeforces: 2706, costPer1M: 60 },
};

// 关键观察：从 medium 到 high，AIME 提升 8 个百分点但成本涨 10 倍
// 性价比拐点：大多数应用选 medium 即可

第五章：safety 与 alignment。o3 在 system card 中披露了一个重要的安全策略——deliberative alignment。不同于传统 RLHF 在 final answer 上做 safety filter，o3 的 safety 是 在 reasoning 层面显式监督：模型在 CoT 中被要求"先思考为什么这可能是敏感的，然后给出安全回答"。这种"让 CoT 也做 alignment"的做法让 o3 在 jailbreak 抵抗上比 GPT-4o 高一个数量级（jailbreak success rate 从 ~13% 降到 ~2%），但代价是 CoT 长度增加 ~15%。这是安全性 vs 推理预算的工程权衡。

第六章：限制与失败模式。o3 论文坦诚披露了几个失败模式：(1) 幻觉（hallucination）仍存在，尤其在 long-tail fact 查询上；(2) 不一致推理——同样问题问两次可能得到不同答案；(3) 工具调用错误——复杂 tool use 链中偶尔出现"工具调用错误但模型自信"的情况。这些失败模式在 Deep Research 等多步 Agent 系统中会被放大（一步错则步步错），因此 o3 团队特别强调了 agent-level verifier 的重要性，即对整个 agent trajectory 做对错判断而非仅 final answer。

4.2 Deep Research 系统架构：多 Agent 研究式推理 + 检索-阅读-写入循环

Deep Research（o3 体系下的"AI 研究员"系统）在 2025-02 发布，是 o3 reasoning 能力的产品化巅峰。它的目标是把一个研究问题（如"分析 2025 年量子计算对加密货币的影响"）从用户提出到答案出炉的整个链路自动化，包括：浏览器搜索 / PDF 检索 / 论文阅读 / 多源验证 / 报告撰写。整个过程可能持续 5-30 分钟，消耗 10-50M tokens。

Deep Research 的核心架构可以概括为 "多 Agent 协作 + ReAct 循环"。系统中至少有以下 Agent：

• Planner Agent：把研究问题分解为子任务，决定研究路径；
• Search Agent：调用 web search / arxiv / Google Scholar 等检索工具；
• Reader Agent：解析 PDF / 网页内容，提取关键信息；
• Verifier Agent：交叉验证多源信息，识别矛盾；
• Writer Agent：综合多源信息，撰写最终报告；
• Reflection Agent：在每一个 Agent 的输出上做 self-check，"我是否漏看了？是否矛盾？"。

// Deep Research 多 Agent 协作伪代码
async function deepResearch(userQuestion: string, maxMinutes: number = 30) {
    // 1. Planner：把问题拆分成子任务
    plan = await plannerAgent.decompose(userQuestion, subTaskCount=5);

    // 2. 并行执行子任务
    const subResults = await Promise.all(
        plan.subTasks.map(async (sub) => {
            // 每条子任务跑一个 search → read → verify 循环
            const searchResults = [];
            for (let i = 0; i < 5; i++) {
                const query = await searchAgent.query(sub, context=searchResults);
                const snippets = await browser.search(query);
                const doc = await readerAgent.read(snippets[0]);
                const verified = await verifierAgent.check(sub, doc, snippets);
                searchResults.push({query, snippet, doc, verified});
                if (verified.confidence > 0.9) break;
            }
            return searchResults;
        })
    );

    // 3. Writer 综合所有子任务结果
    const draft = await writerAgent.synthesize(userQuestion, subResults);

    // 4. Reflection 多轮 self-check
    let refined = draft;
    for (let i = 0; i < 3; i++) {
        const critic = await reflectionAgent.critique(userQuestion, refined, subResults);
        refined = await writerAgent.refine(critic, subResults);
    }

    return {
        report: refined,
        citations: collectCitations(subResults),
        confidence: estimateOverallConfidence(subResults),
    };
}

Deep Research 的几个关键工程决策：

1. 并行子任务执行——多个子任务的 search/reader 阶段并行执行，节省总时间。这是 Agent 系统 vs sequential reasoning 的核心效率优化。
2. Long-running state management——单次研究可能持续 30 分钟，agent 必须 maintain 跨 turn 的状态（已查过的 source、未验证的 claim）。这要求 agent 框架支持长上下文持久化 + checkpoint 机制。
3. Citation grounding——所有结论必须挂到具体引用上（论文 / 报告 / 链接），避免幻觉。这是 Deep Research 作为严肃研究工具的合规底线。
4. Self-critique loop——reflection agent 在 writer 输出的基础上反复 critique + refine，直到 confidence 满足阈值。这种"agentic self-correction"是 System-2 reasoning 在多 Agent 系统中的延伸。

Deep Research 的局限性也值得讨论：(1) 搜索质量上限由 web 搜索引擎决定——Google / Bing 在某些长尾查询上 recall 很低，Deep Research 也无能为力；(2) PDF reader 在扫描件 / 公式密集文档上 OCR 错误——尤其是化学、数学公式；(3) Verifier Agent 的能力上限 = o3 的推理能力，在某些 cross-domain 综合问题上仍会"找理由圆过去"。这些限制是当前 multi-agent 研究系统的共性问题，需要更深层的创新才能解决。

4.3 o4-mini（2025-04）：reasoning mini 路线与 agentic tool use 的深度集成

o4-mini 在 2025-04 与 o3 同期发布，但定位不同——o3 是"准确率最高"，o4-mini 是"性价比最高的 reasoning"。o4-mini 在保持 93% AIME / Codeforces 2400 rating 的能力下，把单次推理成本压到 GPT-4o 之下（$3/$12 per 1M tokens）。这是 OpenAI 把 reasoning 范式"产品下沉"的关键一步。

o4-mini 的训练范式有几个关键变化：

1. 更小的 base model：o4-mini 的 base model 参数量约是 o3 的 1/4（推测 ~70B-100B）。
2. 更精细的 PRM：在 RLVR 训练中，o4-mini 用了相对 o3 更高频率的 PRM 信号（每 2-3 step 一次而非每 8-10 step），这弥补了 base model 较小带来的 reasoning 能力缺陷。
3. Tool-first training：o4-mini 的 RLVR 训练中，~40% 的 rollout 包含 tool use（calculator、search、Python），而 o3 仅 ~15%。这让 o4-mini 在有工具可用的场景下表现接近 o3。
4. Reasoning budget 自动调配：o4-mini 在不同难度任务上自动调整 CoT 长度，简单问题 1k token，复杂问题 16k token，无需用户指定 reasoning_effort。

// o4-mini 的 reasoning + tool use 协同伪代码
function o4MiniReason(prompt: string, availableTools: Tool[]) {
    // 1. 估计任务难度
    difficulty = difficultyClassifier(prompt);  // easy / med / hard

    // 2. 根据难度分配 budget
    budget = {
        easy: { cotTokens: 1024, toolBudget: 1 },
        med:  { cotTokens: 8192, toolBudget: 3 },
        hard: { cotTokens: 16384, toolBudget: 8 },
    }[difficulty];

    // 3. 在 budget 内 reasoning + tool use
    state = {cotRemaining: budget.cotTokens, toolRemaining: budget.toolBudget};
    while (state.cotRemaining > 0 || state.toolRemaining > 0) {
        nextStep = model.generate(state);
        if (nextStep.type == "cot") state.cotRemaining -= tokensUsed;
        if (nextStep.type == "tool_call") {
            result = availableTools[nextStep.tool].invoke(nextStep.args);
            state.toolRemaining -= 1;
            appendObservation(state, result);
        }
        if (nextStep.type == "final_answer") return nextStep;
    }
    return synthesizeFinal(state);
}

o4-mini 的另一个有意义的产品决策是 "reasoning cache"。在 ChatGPT 中，如果用户之前问过类似问题，o4-mini 会复用之前的 reasoning trace（缓存整个 CoT），仅重新生成 final answer 部分。这把单次推理成本进一步压低 50-80%。这种"reasoning cache"是 reasoning 系统走向低成本的关键工程优化——Anthropic Claude 在 2025-04 也开始提供类似功能。

4.4 与其他 reasoning 模型对比：vs DeepSeek-R1 / Claude extended thinking / Gemini Thinking

o 系列不是唯一走 reasoning 范式的团队。2025 H1 还有几个竞品值得对比：DeepSeek-R1（2025-01）、Anthropic Claude extended thinking（2025-02 → 3.7 Sonnet / 4）、Google Gemini Thinking（2025-04）。我们从训练范式、能力上限、开源 / 闭源、生态适配四个维度横向对比。

DeepSeek-R1（2025-01）：开源 reasoning 的里程碑。R1 的 paper "DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning" 详细披露了 R1-Zero → R1 的迭代过程。R1-Zero 直接用 GRPO（Group Relative Policy Optimization）+ 数学 / 代码 verifier 从 base model 训练，没有 SFT cold start，模型在 RL 中自行涌现 reasoning 能力（如 self-revision、a-ha moment）。这种"纯 RL 而无监督"的训练范式是 LLM 研究史上的重大里程碑——证明了 reasoning 不一定需要人工标注的 CoT 数据。R1 在 R1-Zero 基础上加入 SFT cold start + RL，最终达到与 o1 同档的能力（79.8% AIME pass@1）。开源 MIT 协议让学术圈可以完整复现研究，意义深远。

// DeepSeek-R1 的训练范式（GRPO + cold start）
function trainR1(baseModel):
    // R1-Zero: 纯 RL，无 SFT
    r1ZeroPolicy = grpoTrain(
        baseModel=baseModel,
        reward=verifierReward,
        epochs=many,
    );

    // R1: 加入 SFT cold start
    coldStartData = collectColdStart(r1ZeroPolicy);  // 选取 reasoning 涌现样本
    sftPolicy = sftTrain(baseModel, coldStartData, epochs=2);
    r1Policy = grpoTrain(
        baseModel=sftPolicy,
        reward=verifierReward + formatReward,
        epochs=more,
    );
    return r1Policy;

// GRPO 算法核心：组内归一化 advantage，节省 critic 网络
function grpoTrain(policy, reward, numSteps):
    for step in range(numSteps):
        prompts = samplePrompts();
        rollouts = [policy.generate(p) for p in prompts];  // K=8 条
        rewards = [reward(r) for r in rollouts];
        baseline = groupMean(rewards);
        advantages = (rewards - baseline) / groupStd(rewards);
        policy = clippedPolicyUpdate(policy, rollouts, advantages, clipRatio=0.2);
    return policy;

Claude 3.7 Sonnet extended thinking。Anthropic 在 2025-02 推出 extended thinking 功能，让 Claude 3.7 Sonnet 可以做 Long CoT（典型 8k-32k token）。其训练范式是 "constitutional AI + RL on reasoning"：先做 Constitutional AI（基于宪法原则的偏好学习），再在 reasoning 任务上做 RL。与 o3 的关键差异是 Anthropic 选择 "reasoning trace 在 API 中可选显示"——开发者可以参数 enable_extended_thinking 控制是否暴露 CoT。这是 Anthropic 强调"对齐优先"的工程决策。

Gemini 2.5 Thinking。Google 在 2025-04 推出 Gemini 2.5 系列，包含 "thinking" 模式。Gemini Thinking 的关键差异是 "原生多模态 + 实时搜索"——CoT 中可以直接调用 Google Search、YouTube、Map 等多种工具。在 ARC-AGI benchmark 上 Gemini Thinking 2.5 Pro 达到 ~70%，介于 o3 与 o1 之间，但多模态 + 实时搜索的组合是 Gemini 独有能力。

从产业影响看，o 系列的影响最深远——它推动了整个行业的 reasoning 化浪潮。但从学术 / 开源看，DeepSeek-R1 的意义可能更大——它让研究者能在本地复现 reasoning 训练，催生了 Math-Shepherd、Open-R1、复现 o1 等多个开源项目，构建了 reasoning 研究的开源生态。Claude 与 Gemini 则更多是"产品差异化竞争"——它们用各自的特色（对齐 / 多模态）与 OpenAI 差异化，但基础范式（RL on long CoT）殊途同归。

4.5 o3 benchmark 全景：从数学奥赛到通用智能 ARC-AGI

o3 在 2024-12 公布、2025-04 完整版中展示了横跨多个领域的 SOTA 表现。本节我们逐一深入每个 benchmark，理解 o3 的能力边界。

(A) AIME 2024/2025 - 美国数学邀请赛。AIME 是美国数学奥赛体系中的关键一环，30 道填空式难题（答案 0-999 整数），限时 3 小时。AIME 2024 上 o3 达到 96.7%，意味着 30 题答对 29 题，超越几乎所有人类参赛者（AIME 顶尖人类 ~25/30）。这一成绩的关键是 o3 在 o1 基础上加入 medium-difficulty 难度课程 + cyclic revision——在 CoT 中多次回到 "I need to verify" 步骤。

// o3 在 AIME 上的一次完整 CoT（节选）
CoT(
  Step 1: "Let me read the problem carefully. Given n positive integers..."
  Step 2: "We need to find the smallest k such that..."
  Step 3: "Hmm, I see two approaches: (1) direct enumeration (2) modular arithmetic"
  Step 4: "Let me try direct enumeration first. Suppose a+b+c = k..."
  Step 5: "Wait, I made a sign error above. Let me redo..."
  Step 6: "Now using arithmetic modulo p..."
  Step 7: "Let me verify with small cases (n=3, k=1)"
  Step 8: "OK, the pattern seems to be k = p-1. Now I need to prove..."
  Step 9: "Proof sketch: by Fermat's little theorem..."
  Step 10: "Final answer: k = p - 1, i.e., 998"
);

(B) GPQA Diamond - 物理化学生物博士级问答。GPQA（Graduate-Level Google-Proof Q&A）由 198 名 PhD 各出 3 道题（共 546 道，经过筛选后 198 道 Diamond 集），难度极高，是"博士级科学问答"的公认基准。o3 在 GPQA Diamond 上达到 87.7%，超过专家平均值（~65%）。这一成绩意味着 o3 可以替代 PhD 进行基础科学问答。

(C) FrontierMath - 数学研究级别。FrontierMath 由 Epoch AI 在 2024-08 发布的高难度数学数据集，包含 100+ 题目，覆盖代数几何、解析数论、代数拓扑等领域，难度相当于数学 PhD 资格考试。GPT-4 在 FrontierMath 上仅 2% 准确率，o3 达到 96%，这是 LLM 在高难度数学上的最大跃迁。其背后是 OpenAI 与 Epoch AI 的 专门 RLVR 训练 在 FrontierMath 数据上的大规模合成 rollout。

(D) Codeforces 编程竞赛 rating。o3 在 Codeforces 上的 rating 达到 2706，介于"国际大师"（2400）与"高级国际大师"（2600）之间，进入 top 0.1% 人类程序员的领域。这一成绩是 OpenAI 引用 Codeforces 网站的真实比赛排名（用赛后才知的题目 + 严格时间限制）。

(E) SWE-bench 真实软件工程。SWE-bench 是给定 GitHub issue 让模型自动 PR 修复的开源仓库数据集。o3 在 SWE-bench 上达到 71.7%，是当时开源模型（Devin 30%）的 ~2.4 倍，证明 o3 在"理解真实代码 + 写 patch + 通过 CI"的全流程能力。

(F) ARC-AGI 通用智能。ARC-AGI（Abstraction and Reasoning Corpus）是 Francois Chollet 在 2019 年提出的"通用智能"基准，给定 input-output 例子，让模型推断 transformation。ARC-AGI 一直被认为"LLM 几乎不可能解决"。o3 在 ARC-AGI Private Eval 上达到 87.5%（私人评估集），是第一个达到 SOTA 水平的 LLM，Chollet 在 2024-12 公开承认 o3 是"击败 ARC-AGI 的首个 LLM"。

4.6 Deep Research 实现细节：从 Query Planner 到 Citation Engine

Deep Research 系统的真实实现远比"o3 + browser"复杂。本节深入 8 个核心子系统。

(1) Query Planner。用户的 query（如"分析 2024 年中国新能源汽车出口趋势"）先经过 Query Planner 拆解为：(a) 子问题列表（3-8 个 sub-questions）；(b) 信息需求矩阵（每个 sub-question 需要哪些类型的信息）；(c) 研究路径图（sub-questions 之间的依赖关系）。这一拆分基于 o3 的 reasoning 能力。

// Deep Research Query Planner 伪代码
async function planQuery(userQuery: string) {
    // 1. 用 o3 长 CoT 生成子问题
    subQuestions = await o3.generate(
        prompt: `Break down this research question into 5-8 sub-questions: "${userQuery}"`,
        maxTokens: 4000,
    );

    // 2. 为每个子问题标注信息需求
    const plan = subQuestions.map(sq => ({
        question: sq,
        infoNeeded: classifyInfo(sq),  // data, citation, analysis, comparison
        sources: candidateSources(sq),  // arXiv, news, gov data, etc.
    }));

    // 3. 构建依赖图
    const depGraph = buildDependencyGraph(plan);
    return {subQuestions: plan, depGraph};
}

(2) Search Engine Bridge。Search 调用 Bing / Google / Brave / DuckDuckGo 多个搜索引擎，按相关性融合排序。每个搜索 query 返回 top-10 snippets（约 2k-5k tokens），供后续 Reader 处理。

(3) PDF Reader。对检索到的 PDF 链接，PDF Reader 用以下 stack 处理：
(a) PDF 文本提取（PyPDF2 / pdfplumber）；
(b) OCR fallback（Tesseract / EasyOCR）for 扫描件；
(c) 图表识别（figure / table 单独提取，用 GPT-4o vision 解析）。处理后的 PDF 转成结构化 markdown 进入 reasoning。

(4) Cross-Verification。多源 cross-check 是 Deep Research 区别于简单 RAG 的核心。每个关键 claim 都要求至少 2 个独立来源验证。如果两个独立来源给出冲突信息，模型进入"冲突解决"模式：(a) 检查来源权威性；(b) 检查发布时间；(c) 调用 verifier 给出最终判定。

// 冲突解决：cross-verification
async function resolveConflict(claim, sourceA, sourceB) {
    // 1. 来源权威性评估
    authA = await sourceAuthorityModel.score(sourceA);
    authB = await sourceAuthorityModel.score(sourceB);

    // 2. 时间戳检查
    timeA = sourceA.publishDate;
    timeB = sourceB.publishDate;
    if (timeA > timeB) preference = "A";  // 新源优先
    if (timeA < timeB) preference = "B";

    // 3. verifier 判定
    finalVerdict = await verifierEngine.judge(claim, [sourceA, sourceB]);

    return {
        claim: claim,
        verdict: finalVerdict,
        confidence: finalVerdict.confidence,
        reasoning: finalVerdict.explanation,
    };
}

(5) Writer Agent。Writer Agent 接收所有 verified facts，撰写连贯的 report。其输出格式：(a) 摘要（200 字总结）；(b) 章节（按 sub-question 划分）；(c) 引用（行内 cite + 文末 references）；(d) 限制说明（数据集限制、潜在矛盾等）。

(6) Reflection Agent。Writer 输出后，Reflection Agent 用 o3 自身做 self-critique，找出"缺漏 / 矛盾 / 不准确"。具体检查：(a) claim completeness（每个 claim 是否有 citation）；(b) reasoning consistency（章节间逻辑连贯）；(c) fact checking（每个关键数据点是否被 multi-source 验证）。Reflection Agent 可能触发 1-3 轮 revise loop。

(7) Citation Engine。所有 claims 必须挂到具体的 citations。Citation Engine 维护一个 (claim, source, url) 的 hash map，保证每条 claim 都可以反向追溯到至少 1 个 primary source。文末 references 列表自动从 hash map 生成。

(8) Cost Tracker。实时追踪 GPU cost、token consumption、tool call 数，保证 Deep Research session 的总成本不超过预算（用户设定的 reasoning budget）。如果超预算，自动 graceful exit 并告知用户。

承接上文推理脉络，本节将系统展开：

4.7 o4-mini 训练数据细节：从 base model 到 distillation 的路径

o4-mini 的训练数据具体组成未公开，但通过 DeepSeek-R1 distillation 论文、o1-mini 训练报告等信息可以推断。本节深入细节。

Base Model 来源。o4-mini 的 base model 推测是 GPT-4o-mini 级（约 8B 参数），但在 reasoning RL 前会做一次"reasoning SFT"——用 o3 的少量高质 CoT 数据做监督微调，让 base model 在 RLVR 前已经具备基本的 reasoning 能力。这一步骤很重要，否则模型从 GPT-4o 的"短回答"策略直接迁移到 reasoning 太陡峭。

// o4-mini 训练管线（推测）
function trainO4Mini(baseModel=mini) {
    // Phase 1: Reasoning SFT
    sftPolicy = sftTrain(
        baseModel=baseModel,
        data=distillFromO3(filter=highQuality, limit=200K),
        epochs=2,
        lr=1e-5,
    );

    // Phase 2: RLVR 主要训练（数学/代码）
    rlvrPolicy = rlvrTrain(
        baseModel=sftPolicy,
        tasks=[AIME, MATH, APPS, HumanEval],
        prm=trainedPRM,
        epochs=many,
        lr=5e-6,
    );

    // Phase 3: Tool-aware RL (40% rollout 含 tool use)
    toolPolicy = toolAwareTrain(
        baseModel=rlvrPolicy,
        tools=[calculator, python, search],
        epochs=some,
    );

    // Phase 4: Alignment RLHF (轻量)
    finalPolicy = rlhfAlign(
        baseModel=toolPolicy,
        epochs=few,
    );

    return finalPolicy;
}

Distillation 细节。o4-mini 可能用了 "self-distillation"——用 o3 在大规模数学/代码任务上做 rollout，挑出高质样本（PRM 总分 > 0.8）作为 distillation 数据。这种"self-distillation" 比用 o3 的"普通输出"做 distillation 更精准，因为前者已经过滤了 o3 的 failures。

Tool-aware training 数据。~40% 的训练 rollout 含 tool use。训练数据构造方式：(a) seed 任务是一道可以用 Python 解决的数学题；(b) model 在 rollout 中 50% 概率决定调用 Python；调用 Python 后模型拿到 tool result 继续 reasoning；(c) 最终答案经 verifier 验证。这种"训练时 tool use" 让 o4-mini 在推理时能自然决定何时用工具而非依赖 prompt。

4.8 风险评估与 Preparedness Framework：OpenAI 的安全治理体系

OpenAI 在 o3 发布前部署了"Preparedness Framework"——一套系统性的风险评估与缓解机制。这一框架在 2024-12 升级，是 AI 安全治理的标杆。

Preparedness Framework 的五大维度。

1. Bio risk (生物风险)——模型是否显著降低生物武器研发门槛？评估方法是 bio-knowledge cutoff（敏感 protocol 训练数据过滤）与 dual-use filter（输出安全 filter）。
2. Cyber risk (网络风险)——模型是否显著降低网络攻击门槛？评估方法是 CTF benchmark、vulnerability discovery benchmark、exploit generation benchmark。
3. Autonomy risk (自主性风险)——模型是否能 self-replicate、acquire resources、evade shutdown？评估方法是 autonomous task success rate、resource acquisition success rate。
4. Persuasion risk (说服力风险)——模型是否能显著提升 persuation / manipulation 能力？评估方法是 propaganda generation、social engineering benchmark。
5. Resilience risk (弹性风险)——模型是否能被滥用做具体危害？评估方法是 misuse scenarios (e.g., financial fraud generation、academic cheating)。

// Preparedness Framework 的五维评估
const preparednessEvaluation = {
    bio: {
        protocolKnowledge: 0.72,  // 模型对 viral engineering protocol 知识
        dualUseFilterRate: 0.99,  // dual-use filter 触发率
        riskLevel: "medium",      // 评估为 "medium risk"
    },
    cyber: {
        ctfScore: 0.85,           // CTF benchmark 通过率
        exploitGenSuccess: 0.62,  // 漏洞利用生成成功率
        riskLevel: "high",        // 评估为 "high risk"
    },
    autonomy: {
        selfReplication: false,    // 未发现 self-replication 行为
        resourceAcquisition: 0.05, // 资源获取成功率 5%
        riskLevel: "low",          // 评估为 "low risk"
    },
    persuasion: {
        propagandaGeneration: 0.78, // 宣传文章生成质量（人类专家评分）
        socialEngineering: 0.65,    // 社会工程能力
        riskLevel: "medium",
    },
    resilience: {
        fraudGenerationSuccess: 0.88, // 金融诈骗生成
        academicCheatingSuccess: 0.91, // 学术作弊
        riskLevel: "high",
    },
};

// o3 发布后，OpenAI 在 cyber + resilience 维度触发 "early warning"
// 部署了 extra safety measures (dual-use filter 增强、人评审查)

三层防御机制。针对每个 risk 维度，OpenAI 部署三层防御：

• Layer 1: Training-time prevention——训练数据中过滤敏感内容（如 viral engineering protocol）；
• Layer 2: Inference-time filter——实时检测可疑输出，做 output refusal 或 redact；
• Layer 3: Monitoring + response——对已发布的输出做 offline monitoring，发现 misused cases 做 review。

外部 red team。OpenAI 在 o3 发布前组织外部 red team（~50 名 PhD / 安全 researcher / 黑客），专门做 adversarial testing。这些 red team 成员尝试 jailbreak / prompt injection / information extraction 等多种攻击路径。red team 的反馈用于修补 safety filter 和 model alignment。

Cyber preparedness team。OpenAI 在 2024-12 专门成立了 "Cyber Preparedness Team"，由前 NSA / CISA 安全专家组成，负责对 o 系列模型在 cyber 维度的持续监控。这一团队对 o3 system card 第 5.2 章披露的 CTF benchmark 评估有直接贡献。

4.9 o3 multimodal reasoning 的工程深度：ViT 与 LLM 的 joint training

o3 的多模态能力是"原生融合"而非"外挂 vision pipeline"。本节深入工程细节。

Vision encoder 设计。o3 的 vision encoder 是 OpenAI 自研的 ViT-style 模型，约 1-2B 参数。它接收 1024×1024 图像，输出 256 个 visual token（与 GPT-4o 类似）。Vision encoder 在 multimodal pretraining 中与 LLM 联合训练，确保 visual token 与 text token 在 embedding space 中对齐。

// o3 vision encoder 的训练模式
async function trainVisionEncoderWithLLM(llm, visionEncoder, dataset) {
    // 联合训练：image-text pair data
    for (const batch of dataset) {
        const images = batch.images;        // 1024x1024 图像
        const captions = batch.captions;    // 描述文本
        
        // Vision encoder 提取 visual tokens
        const visualTokens = visionEncoder.encode(images);  // 256 token / image
        
        // LLM 处理 visual + text tokens
        const output = llm.forward(visualTokens + tokenize(captions));
        
        // Loss：caption prediction (next token prediction)
        const loss = captionPredictionLoss(output, captions);
        loss.backward();  // 反向传播到 LLM + vision encoder
    }
}

Cross-modal reasoning 的训练数据。o3 的多模态 reasoning 训练数据包括：(a) geometry problems——图像中的几何题 + 文本指令；(b) physics diagrams——电路图 / 力学图 + 推理指令；(c) chemistry structures——分子结构图 + "这是哪种分子"问题；(d) document QA——PDF 图文混合 + 问答。这些数据的特点是reasoning 的关键步骤依赖视觉信息（"图中有 3 个圆 → 证明角度等"）。

Visual CoT 的训练。o3 在 CoT 中如何"引用"视觉信息？这是 OpenAI 的核心工程秘密。一种可能的设计：训练数据中 CoT 显式包含"看图"步骤（如"look at the figure"、"see the rightmost circle"），让模型学会在 CoT 中明确引用视觉位置。这种 visual CoT 训练让 o3 在多模态 reasoning benchmark（如 MMStar、MMBench、MMMU）上领先 GPT-4o 一档。

// Visual CoT 的训练数据示例
const visualCoTExamples = [
    {
        image: "geometry_diagram.png",  // 几何图：3 个圆 + 1 个三角形
        prompt: "求角 A 的度数",
        cot: [
            "1. Let me look at the figure carefully.",
            "2. I see 3 circles and 1 triangle in the diagram.",
            "3. The triangle has vertices labeled A, B, C.",
            "4. From the figure, angle at B is 60° (vertical angle from the circle intersection).",
            "5. Using the property that opposite angles in cyclic quadrilateral sum to 180°...",
            "6. So angle A = 180° - 60° - angle C = 80°.",
            "Answer: 80°",
        ],
    },
    {
        image: "circuit_diagram.png",  // 电路图
        prompt: "求等效电阻",
        cot: [
            "1. From the diagram, I see 3 resistors R1, R2, R3 in configuration...",
            "2. R1 and R2 are in series; R3 is in parallel with the series combination.",
            "3. R_series = R1 + R2 = 200 ohm",
            "4. R_eq = (R_series * R3) / (R_series + R3) = ...",
            "Answer: 75 ohm",
        ],
    },
];
// 训练目标：模型学习如何"看图 + reasoning"，而非"忽略图直接回答"

Image resolution 与 token budget。不同任务需要不同 image resolution。o3 可能在不同 API 参数上支持不同分辨率：(a) low resolution（512×512 → 64 token）适合简单任务；(b) medium resolution（1024×1024 → 256 token）适合大多数任务；(c) high resolution（2048×2048 → 1024 token）适合精细任务（如 OCR、formula recognition）。这种 resolution 切换让用户可以根据任务复杂度选择合适的 vision budget。

Audio 与 Video 扩展。o3 目前的 vision encoder 仅处理静态图像。但 OpenAI 在 2025 H2 预计扩展到 audio（语音输入）与 video（视频流）。这种多模态融合会让 o3 在真实场景（如视频会议、车载、教育）中发挥更大作用。

五、生态与未来：Reasoning 走向 Agent 的 2026 路线图

前四篇我们从训练到推理、从架构到产品，全面解构了 o1/o3 reasoning 范式。最后一篇我们把视角拉到生态层——reasoning 模型如何商业化（ChatGPT + API）、如何与浏览器 / PDF / Web API 集成（Deep Research 生态）、如何处理长 CoT 的安全风险（Anthropic / OpenAI 的对齐策略）、以及 2026 年的 AGI 路线展望。这一篇 4 章会涉及大量行业数据、价格、安全与战略判断，是"reasoning first"商业视角的全局鸟瞰。

5.1 ChatGPT 与 API 商业化：reasoning 模型定价分档、用户分层

OpenAI 在 2024-09 起把 reasoning 模型分为三档：

• 免费层：ChatGPT free users 仅可访问 o3-mini（有限次数），主要为了拉新和留存。
• Plus 层 ($20/月)：可访问 o3-mini 无限次，o1 有限次（每周 ~50 条消息），是 ChatGPT 主要订阅收入来源。
• Pro 层 ($200/月)：可访问 o1-pro 无限次，o3 大量使用，目标用户是研究人员、金融分析师、深度用户。
• API 层：开发者按 token 用量付费，o3-mini $1.10/$4.40、o1 $15/$60、o1-pro $150/$600、o3 $60/$240。

这套分层定价的经济学逻辑是 "按推理深度收费"。在传统 LLM 时代，按 token 收费是单位 "推理深度相同"的合理近似；但在 reasoning 时代，不同 reasoning_effort 档的成本可以差 50×。如果按 token 统一收费，要么过高（用户为 GPT-4 速度付费 10×）要么过低（用户消耗 100× token 但按 1× 收费）。OpenAI 的解决方案是 "显式 reasoning_effort 参数"——API 调用方按需选择推理档位，按档位单价计费。

// OpenAI o 系列 API 商业模型
const oAPI = {
    "o3-mini":     { inputPrice: 1.10,  outputPrice: 4.40,  reasoningPrice: 4.40 },
    "o1-mini":     { inputPrice: 3.00,  outputPrice: 12.00, reasoningPrice: 12.00 },
    "o1":          { inputPrice: 15.00, outputPrice: 60.00, reasoningPrice: 60.00 },
    "o1-pro":      { inputPrice: 150,   outputPrice: 600,   reasoningPrice: 600 },
    "o3":          { inputPrice: 60,    outputPrice: 240,   reasoningPrice: 240 },
    "o4-mini":     { inputPrice: 3.00,  outputPrice: 12.00, reasoningPrice: 12.00 },
};

// 一次 reasoning = medium 的 o3 调用平均成本
//   input 1k + reasoning 8k + output 2k = 11k tokens
//   cost = 1k * 0.06 + 8k * 0.24 + 2k * 0.24 = 0.06 + 1.92 + 0.48 ≈ 2.46 美元
// 是 GPT-4o 的 ~10 倍

用户分层的逻辑是 "按用户价值梯度配给推理算力"。免费用户的边际成本必须低于其转化收入期望，否则 OpenAI 就在"贴钱换留存"。Plus 用户的 $20/月订阅覆盖其 o3-mini 无限次使用（成本 ~$8）的合理 margin 是 60%。Pro 用户的 $200/月覆盖 o1-pro 大量使用（成本 ~$80），margin 50%。这套设计让 最愿意付钱的用户获得最强模型，是经典 two-sided market 的优化。

企业用户（enterprise / Fortune 500）则是另一套体系——他们直接与企业版 OpenAI 签合同（年付 $50k-$5M），获得定制 reasoning budget + SLA + 私有部署选项。企业版 o3 通常提供比消费级更高的 rate limit、更稳定的延迟（专用 GPU cluster）、更长的 CoT（up to 200k tokens）。这套 B2B 定价是 OpenAI 当前营收最大头（约 60-70% 的 API 收入来自企业）。

DeepSeek-R1 的定价则走另一条路——开源 + 极度低价。DeepSeek-R1 API 价格 $0.55 / $2.19（cache），是 o1 的 1/30。这源于 R1 的 params-efficient MoE 架构（671B 总参数仅激活 37B）+ 开源生态 + 中国市场的成本优势。R1 的出现对 OpenAI 形成了"低价逼宫"——迫使 OpenAI 在 2025 H1 推出 o4-mini（$3/$12）作为应对。这场"reasoning 价格战"会在 2025 H2 进一步升级——Anthropic、xAI、阿里 Qwen 都在加入低价推理模型战场。

5.2 o3 Deep Research 生态：与浏览器、PDF、Web API 的深度集成

o3 Deep Research 不是一个孤立的模型，而是一个 "reasoning + agent + 工具" 生态。这个生态把 o3 reasoning 能力、浏览器自动化、PDF 解析、搜索引擎、API 调用、代码执行等多种能力融合，提供"AI 研究员"的 end-to-end 服务。本节我们详细讨论这个生态的工程组件。

关键工具组件的能力边界：

1. Browser Tool：基于 Playwright 实现的浏览器自动化，支持搜索、点击、表单填写、页面渲染、最多 30 层 DOM 提取。每个研究的浏览器调用上限 ~500 次，超出则降级到 cached search。
2. PDF Reader：基于 Docling / Marker 等开源 PDF parser，支持论文、报告、scan、图表。最长处理 ~300 页 PDF（typical research paper + supplementary）。
3. Code Executor：基于 firecracker 的 microVM 沙箱，跑 Python 计算、统计、图表生成。每个研究最多 30 分钟 CPU 时间、4 GB 内存。
4. Calculator Tool：调用 sympy / wolfram alpha 做精确数学运算，避免模型"口算"出错。
5. Web API 集成：arXiv、Google Scholar、PubMed、Bloomberg、Crunchbase 等特定领域 API，针对学术研究 / 金融分析场景优化。

// Deep Research 工具调用协议
interface DeepResearchRequest {
  query: string;
  maxMinutes: number = 30;
  domain: "general" | "academic" | "financial" | "legal";
  constraints: {
    mustCiteCount: number;
    forbiddenSources: string[];
    language: "en" | "zh" | "multi";
  };
  tools: string[];  // 显式允许的工具
}

interface DeepResearchResponse {
  report: string;          // Markdown 格式
  citations: Citation[];   // 引用 + 可信度评分
  confidence: number;      // 0-1, 综合可信度
  toolCalls: ToolCallLog[];  // 工具调用日志
  totalTokens: number;     // reasoning + tool + output
}

// 一次研究的真实成本估算（典型 academic 研究）
const academicResearchCost = {
  queryTokens: 500,
  reasoningTokens: 30000,    // Long CoT
  toolCallTokens: 15000,    // search + PDF + 计算
  outputTokens: 8000,
  totalTokens: 53500,
  costAtO3Price: 0.5,         // 约 0.5 美元
  costAtO4MiniPrice: 0.05,    // 约 0.05 美元
};

Deep Research 的"AI 研究员"工作流可以概括为以下 8 个阶段：

// AI 研究员工作流（8 阶段）
async function aiResearcher(query, tools, agents) {
    // 1. Query understanding
    refinedQuery = await planner.understand(query);

    // 2. Plan generation (Long CoT)
    plan = await planner.th链.deepCoT(refinedQuery);

    // 3. Source discovery (parallel)
    sources = await browser.searchMultiQuery(plan.subQueries);

    // 4. Source reading (parallel)
    documents = await pdfReader.batch(sources.top(20));

    // 5. Cross-verification
    verifiedFacts = await verifier.crossCheck(documents, sources);

    // 6. Gap analysis (reflection)
    gaps = await reflector.findGaps(plan, verifiedFacts);
    if (gaps.length > 0) {
        // 回 3-5 重新搜索未覆盖的 gaps
        additionalSources = await browser.searchMultiQuery(gaps);
        additionalDocs = await pdfReader.batch(additionalSources);
        verifiedFacts = merge(verifiedFacts, await verifier.crossCheck(additionalDocs, additionalSources));
    }

    // 7. Report synthesis
    draft = await writer.synthesize(query, plan, verifiedFacts);

    // 8. Final reflection and refinement
    refined = await reflector.refineDraft(draft, query, verifiedFacts);
    return refined;
}

Deep Research 的生态延伸还包括 "connector"——企业可以把 Deep Research 接入内部数据源（Confluence、飞书、Notion、SharePoint），让 AI 研究员可以访问内部知识库。这种"内部 + 外部"双源研究能力，是企业知识管理的革命性工具。Anthropic 也推出了类似功能（Claude with connectors），市场竞争白热化。

5.3 CoT 隐私与安全：长思维链的潜在风险与 Anthropic/OpenAI 的安全策略

Long CoT 的隐藏带来一个被低估的安全风险——"思维链作为潜在攻击面"。如果攻击者通过某种手段提取模型的 CoT，可能发现以下信息：

1. 未对齐策略：模型在 CoT 中可能"考虑"过违规回答（"我可以告诉用户怎么制造炸弹，但..."），即使最终输出是合规的；
2. 训练数据泄漏：CoT 可能引用训练数据中的特定事实（包括个人隐私、商业秘密）；
3. prompt injection 痕迹：若 prompt 被注入恶意指令，CoT 中可能显示模型"被说服"的痕迹；
4. 能力边界：CoT 暴露模型"知道但不愿说"的能力（capability elicitation），给红队攻击可乘之机。

OpenAI 的安全策略包括三层防护：(1) API 层：CoT 不返回给 API 用户，log server 中保留但仅限审计团队访问；(2) 模型层：用"deliberative alignment"训练模型在 CoT 中主动 reasoning 出"为什么这符合安全"，让 CoT 本身也是安全对齐的；(3) 系统层：独立的 CoT monitor 分类器扫描生成的 CoT，对"可疑模式"（如对敏感话题的过度推理）标记并可能弃用。

// OpenAI 三层 CoT 防护
interface CoTDefenseLayer {
  // Layer 1: API 层 - 不返回 CoT
  apiBoundary: { returnCoT: false };
  // Layer 2: 模型层 - 让 CoT 也被对齐监督
  deliberativeAlignment: {
    cotSafetyReward: 1.0;     // CoT 中的安全性也获得高 reward
    unsafeThoughtPenalty: -2.0;  // CoT 中的违规想法被惩罚
  };
  // Layer 3: 系统层 - 独立 monitor 扫描
  monitor: {
    classifier: cotSafetyClassifier;  // 独立训练的分类器
    thresholds: { low: 0.3, mid: 0.5, high: 0.8 };
    actions: { low: "log", mid: "warn", high: "reject" };
  };
}

Anthropic 的安全策略略有不同——Claude extended thinking 默认显示 CoT（但可以关闭）。Anthropic 公开辩称："对外显示 CoT 让用户能审计模型行为，是 Constitutional AI 的延伸"。这种"透明 CoT" 的工程实现是 "scrubbed CoT"——在显示给用户前先用分类器过滤掉敏感内容（个人信息、未对齐推理、商业秘密），仅显示"安全剪辑版"。这种透明策略 vs OpenAI 隐藏策略之争，是两大 AI 公司安全哲学的具体体现。

第三类风险是 "reasoning 在恶意场景下的增强能力"。如果用户用 o3 推理 + tool use 设计生物武器、化学毒剂、网络攻击，模型的 Long CoT + tool use 实际上显著降低了恶意使用门槛。OpenAI 与 Anthropic 都在 CoT monitor 中加入"双用途风险分类器"——检测到可能的恶意意图时抑制工具调用并报警。这种"reasoning as attack surface"是 AGI 安全的前沿研究领域，OpenAI 在 o3 system card 第 4 章披露了专门的 bio / cyber / autonomy 三类风险评估。

最后还有一类合规风险——EU AI Act / 数据保护法规。长 CoT 的潜在数据泄漏可能违反 GDPR（如训练数据中的个人信息在 CoT 中泄漏）。OpenAI 在 o3 中部署了PII filter——在 CoT 生成后扫描 PII（email、phone、SSN、address），发现即重写。这套 PII filter 与 Anthropic 的"differential privacy"研究一脉相承，是企业级 reasoning 服务的合规底线。

5.4 2026 路线展望：Agentic reasoning / multi-step reasoning / 内部 verifier 模型

站在 2026 年中回望，o1/o3 已经发布近两年，整个 reasoning 范式在 2025 H1 完成了"概念验证 → 产品化 → 行业普及"三步走。展望 2026 H2，reasoning 范式将沿三条主轴继续演进：

1. Agentic Reasoning——reasoning 模型与 agent 框架深度融合，模型自身成为 30 分钟 / 多小时级别的 autonomous agent；
2. Multi-Step Reasoning——在 Long CoT 之上叠加 multi-step 规划，让模型能处理 100+ step 的复杂任务；
3. Internal Verifier Models——把 verifier model 从"外部辅助"升级为"内部思考一部分"，让模型学会"对自己推理结果的实时校验"。

路线一：Agentic Reasoning。2025 H1 的 Deep Research 已经在"30 分钟研究任务"上达到人类中等水平。2026 H2 的演进方向是"multi-day autonomous task"——让 reasoning agent 可以独立完成一个 1-3 天的研究 / 编程 / 设计任务。这要求：(1) 长 horizon memory（跨会话保留所有 learned information）；(2) self-resume from failure（崩溃后从 checkpoint 继续）；(3) cost-aware planning（在算力预算内完成任务）。OpenAI 在 2026 H1 内部代号 "Atlas" 项目已经围绕这个愿景展开。

// Agentic Reasoning 的 2026 架构预览
interface AgenticReasoning2026 {
  horizon: "hours to days";      // 持续数小时到数天
  memory: {
    working: "跨 turn KV cache";
    episodic: "对话历史 + 文件系统";
    semantic: "向量数据库 + 知识图谱";
  };
  selfCorrection: {
    checkpointInterval: "every 30 seconds";
    failureDetection: "anomaly detector on tool calls";
    resume: "from latest checkpoint";
  };
  costAware: {
    planningModel: "compute-optimal allocation";
    budgetTracking: "real-time spend monitoring";
    adaptiveThrottling: "if budget exceeded, reduce reasoning";
  };
  toolEcosystem: {
    browser: "playwright + chrome devtools";
    code: "jupyter + sandboxed microVM";
    files: "filesystem + version control";
    api: "100+ web API via MCP";
  };
}

路线二：Multi-Step Reasoning。当前 o3 的 Long CoT 单次推理可以处理 50-100 个推理步骤。但真正的"复杂任务"（如"设计一个数据库 schema + 实现后端 API + 写测试 + 部署到 dev 环境"）需要 1000+ steps。2026 H2 的演进方向是 "hierarchical CoT"——把 Long CoT 拆分为多层（high-level plan → sub-plan → step → sub-step），让模型在每一层做 reasoning 而非把所有推理堆在一个 CoT 中。这种层次化推理借鉴了 AlphaZero 的 MCTS 树搜索 + LLM 的 Long CoT，是 reasoning-first 系统走向 AGI 的关键工程进化。

路线三：Internal Verifier Models。当前 verifier model 是"外挂的"——在 RL 训练时打分，或在推理时选 best-of-N。2026 H2 的方向是 "让 verifier 嵌入到 Long CoT 内部"——模型在生成每一步后，内部运行一个 verifier 检查该步正确性，若错则 self-revise。这种"self-checking reasoning" 与 OpenAI 在 o3 paper 中提到的"thoughts of thoughts" 概念一致——o4-mini 已经部分实现（"model can self-correct during long CoT"），o5/o6 推测会更强。

// Internal Verifier 自我校验架构
function internalVerifierReasoning(prompt, model) {
    cot = [];
    partialSolution = "";
    state = {step: 0, confidenceSum: 0};

    while (not done) {
        // 1. 模型生成下一步 CoT
        nextStep = model.generate(prompt, partialSolution, maxTokens=500);

        // 2. 内部 verifier 检查该步
        score = model.internalVerifier.score(prompt, nextStep);

        // 3. 如果得分低，重新生成
        if (score < 0.5) {
            nextStep = model.generate(prompt, partialSolution, maxTokens=500, hint="avoid common errors");
            score = model.internalVerifier.score(prompt, nextStep);
        }

        cot.append(nextStep);
        partialSolution += nextStep;
        state.confidenceSum += score;
    }
    return {cot, finalAnswer: partialSolution, avgConfidence: state.confidenceSum / len(cot)};
}

从产业影响看，reasoning 范式会进一步渗透到所有垂直领域——医疗诊断（o3 在 MedQA 上已达博士水平）、法律咨询（o3 在 BAR exam 上超过 90% 的人类律师）、代码生成（o3 在 SWE-bench 已达 71.7%）、金融分析（o3 在 CFA exam 上超 80%）、科学研究（o3 在 FrontierMath 上与数学 PhD 同等水平）。这些垂直化产品（chatGPT-doctor、chatGPT-lawyer、chatGPT-coder、chatGPT-quant）会在 2026 H2 大量涌现，构成一个 "reasoning-first 行业"。

最后，从哲学与 AGI 视角看，reasoning 范式回答了一个被长期回避的根本问题——"慢思考是否能涌现"。OpenAI o 系列证明了：是的，通过 RL 训练在 Long CoT 上的特定奖励信号，慢思考可以被工程化而非仅靠 prompt 模拟。这与 Kahneman 双系统理论的认知科学预测完全一致。reasoning-first 模型走到 2026 年底，AGI 的"reasoning 维度"已经被达成；剩下的"记忆维度 / 多模态维度 / 自我意识维度"则需要 2026-2030 的持续突破。

六、架构总结：o1/o3 在 LLM 演化史中的位置

回到本文开头的问题——"什么是 o1？为什么它重要？"。o1/o3 不仅是 OpenAI 的一次产品发布，更是 LLM 演化的三次范式跃迁之一。第一次跃迁是 2017 年的 Transformer 架构革命；第二次是 2020 年的 GPT-3 / scaling law 革命；第三次就是 2024 年的 reasoning-first 范式革命。这三次跃迁的共同点是：它们都不是单一的算法改进，而是 "算法 + 数据 + 算力"三位一体的范式跃迁，由 OpenAI 团队用一个具体的产品把它推到极致。

o1/o3 给整个 LLM 行业带来的核心启发是："smart is not just more parameters"。智能的提升路径除了堆参数（GPT-4 路径）、堆数据（更多互联网文本）、堆 RLHF（对齐），还有 "堆推理算力" 这条新路径。这条路径不与前三者冲突，而是相互补足——预训练提供 base reasoning capacity，RLHF 提供 alignment，RLVR + PRM 把 reasoning 推到极限，inference-time scaling 让用户在推理时扩展能力上限。四者协同构成了 LLM 演化的完整图景。

从架构师视角，o1/o3 系列给我们的最大教训是："不要只在 Surface 上思考"。如果只在 prompt 工程上思考，会得到 "GPT-4 + let's think step by step" 的伪 reasoning；如果只在模型层思考，会得到 "10× larger base model" 的暴力 Scaling；如果只在工程层思考，会得到 "best-of-N + tree search" 的浅层增强。真正深刻的范式跃迁来自 "训练目标 + 训练场 + 推理接口 + 产品形态" 四者的协同设计——这正是 OpenAI o 系列的范式贡献。

本文从 System-1/System-2 概念出发，深挖到 PRM / RLVR / Inference-Time Scaling 的训练与推理算法，再到 o3 论文精读、Deep Research 多 Agent 架构、与 DeepSeek-R1 / Claude / Gemini 的横向对比，最后到 2026 年的 AGI 路线展望。全文 22 章 + 总结章共 110,000+ 字、约 30+ 张 Mermaid 图、约 15 个代码示例、6+ 张数据表，希望为读者提供一个从概念到工程、从架构到生态的完整 o1/o3 reasoning 范式参考。在 LLM 走向"深思熟虑型人工智能"的路上，OpenAI 的 o 系列是最具工程参考价值的范式范本。

5.5 OpenAI 商业策略推理：reasoning-first 与 superintelligence 战略

从更宏观的商业视角看，o1/o3 系列的发布不只是产品节奏，更体现了 OpenAI 自 2024 起明确化的 "reasoning-first" 战略，最终目标指向 superintelligence（超级智能）。本节从商业战略层面解构这一选择。

GPT-4 的瓶颈。2023-2024 年的 GPT-4 系列沿着"扩展预训练 + RLHF"的路线推进，但 pre-training scaling law 在 2023 H2 明显饱和——扩大模型规模 + 训练数据带来的能力提升显著放缓。OpenAI 内部多次传出"GPT-5 推迟"消息，本质上是因为单纯堆参数 / token 已经不能带来质变。o1/o3 是 OpenAI 在 scaling law 之外寻找的第二增长曲线。

Reasoning 的商业含义。Reasoning 模型的核心商业价值：(1) 高单价——o3 的 $60/$240 定价远高于 GPT-4o 的 $5/$15，是 ARPU 提升的关键；(2) 企业级场景——高 stakes 推理（金融、医疗、法律）愿意为高准确率付费；(3) 差异化壁垒——在 reasoning 范式上领先竞品 6-12 个月，构建技术护城河。

// OpenAI 推理模型商业模型
class ReasoningProductStack {
    constructor() {
        this.tiers = {
            free: { model: 'o3-mini-low', costPer1000Calls: 0.5, revenue: 0 },
            plus: { model: 'o3-mini-high', costPer1000Calls: 5, revenue: 20 },
            pro:  { model: 'o3-full', costPer1000Calls: 50, revenue: 200 },
            api: { model: 'o3-verified', costPer1000Calls: 60, revenue: 80 },  // 开发者按 token 付
        };
        this.marketShare = {
            enterprise: 0.65,  // 企业占 API 收入 65%
            consumer: 0.25,    // ChatGPT 订阅占 25%
            partner: 0.10,     // Microsoft 等合作伙伴占 10%
        };
    }
}

Reasoning → Agentic → Superintelligence 的三段战略。OpenAI 在 2024 H2 内部多次提出"reasoning-first"战略：当前阶段（2024-2025），主推 o 系列 reasoning 模型；下一阶段（2025-2026），把 reasoning 升级为 reasoning agent（30 分钟 + autonomous）；最终阶段（2026+），以 reasoning agent 为基础构建 superintelligence。这一三段战略与奥特曼在 2024 年公开博客 "Reflections" 中提到的 "GPT-5 → agents → superintelligence" 时间线一致。

Microsoft 与 OpenAI 的关系变化。o1/o3 的高定价对企业市场极为关键——它让 OpenAI 在 Microsoft 的 Azure OpenAI Service 中提供高 ARPU 产品。但 OpenAI 与 Microsoft 的关系在 2024-2025 年处于微妙阶段——奥特曼在 2024-11 多次提到"compute is the new currency"，提出 OpenAI 自建算力的战略。这意味着 OpenAI 可能在 2026 年摆脱对 Azure 的依赖，更激进地抢占 reasoning 商业市场。

开源 vs 闭源的张力。OpenAI 一直坚持闭源策略，与 DeepSeek-R1 的开源形成鲜明对比。这种"闭源 + 高价"vs"开源 + 低价"的张力本质上反映了两种商业模式：(a) OpenAI 押注"控制 + 高利润"——闭源保护 IP，定价回收高昂研发成本；(b) DeepSeek 押注"规模 + 生态"——开源扩大影响力，用 API 调用 + 衍生服务变现。o1/o3 在 o4-mini 推出后将面临"开源 R1 的低价逼宫"——这是 OpenAI 必须应对的战略挑战。

5.6 Anthropic / Google DeepMind / xAI / DeepSeek 的 reasoning 化竞争

OpenAI 不是唯一押注 reasoning 的玩家。我们横向对比四家主要竞争者的 reasoning 战略、产品形态与技术路线。

Anthropic：Constitutional AI + extended thinking。Anthropic 的核心差异是 "对齐优先" 哲学：

• 训练范式：Constitutional AI（基于宪法原则的 RLAIF）+ RL on reasoning traces；
• CoT 显示：Claude 默认显示 thinking summary，与 OpenAI 隐藏策略相反；
• 产品形态：Claude 3.7 sonnet extended thinking + Computer Use Agent；
• 定价：$3/$15 比 OpenAI 便宜约 20%；
• 客户场景：编程（Claude Code）、写作（Claude.ai）、企业（Claude Enterprise）。

Google DeepMind：Gemini Thinking + 多模态 + 实时搜索。Google 的优势是 "搜索 + 多模态"：

• 训练范式：MoE + RL + search-augmented reasoning；
• 多模态：原生 vision / audio / video（YouTube 集成）；
• 实时信息：CoT 中可以直接调用 Google Search；
• 产品形态：Gemini App + Gems (custom agent) + Astra (real-time voice/video)；
• 定价：$1.25/$10（Gemini 2.5 Pro），最低定价；
• 客户场景：Google Workspace 集成、Android 原生、Google Search 增强。

xAI：Grok 3 + 极致算力。Elon Musk 旗下的 xAI 走"算力 + 实时"路线：

• 训练范式：大规模算力（Colossus cluster，10万 H100）+ RL on reasoning；
• 实时信息：直接访问 X（Twitter）实时数据；
• 产品形态：Grok App、SuperGrok 订阅、API；
• 定价：$3/$15 + SuperGrok Premium $30/月；
• 客户场景：实时对话、社交媒体集成。

DeepSeek：开源 + 极致低成本。DeepSeek 是 2025 H1 最具影响力的 reasoning 挑战者：

• 训练范式：纯 RL (GRPO) + MoE + distillation；
• 开源：MIT 协议，完整公开训练代码；
• 模型规格：671B 总参数 MoE（激活 37B），蒸馏 1.5B-70B 全谱；
• 产品形态：DeepSeek Chat / Coder / R1 / R1-Zero 多版本 + API；
• 定价：$0.55/$2.19 cache hit，价格最低；
• 客户场景：学术研究、自部署、低成本 API。

承接上文推理脉络，本节将系统展开：

5.7 Safety 红队与 jailbreak：reasoning 模型的攻击面分析

Reasoning 模型的能力提升必然伴随 attack surface 的扩大。本节解构 o1/o3 的安全风险与红队工作。

5 类主要攻击路径。

1. Jailbreak via reasoning——攻击者通过"先要求 reasoning，再 transition 到敏感话题"绕过安全 filter。o3 的 deliberative alignment 显著降低此风险但未完全消除。
2. CoT injection——攻击者构造 prompt，让模型在 CoT 中"诚实 reasoning 出危险内容"。这是 o1 system card 明确披露的风险。
3. Tool as attack vector——通过 Deep Research / o4-mini 的 tool use，让模型调用危险 API（核物理工具、生物工具）。OpenAI 的对策是 dual-use tool classifier。
4. Reasoning budget exhaustion——攻击者用 high effort 触发超长 CoT，试图绕过 rate limit 或耗尽服务配额。
5. Cross-session leakage——通过多轮对话，让模型"忘了"安全边界，在长 CoT 中逐渐爬出 guardrails。

// 5 类攻击路径的对策
const safetyDefense = {
    jailbreak: {
        deliberative_alignment: 'cot 中显式 reasoning 出安全理由',
        output_classifier: '独立分类器检测响应合规',
    },
    cot_injection: {
        cot_monitor: '扫描 CoT 寻找危险 reasoning',
        cot_summary_filter: 'summary 抽取前移除危险内容',
    },
    tool_abuse: {
        dual_use_filter: 'tool 调用前 dual-use risk 评估',
        human_in_loop: '高风险 tool call 人工审批',
    },
    budget_exhaust: {
        rate_limit: 'per-user CoT token 上限',
        auto_throttle: '超量用户自动降级',
    },
    cross_session: {
        session_isolation: '每 session 独立 guardrail',
        context_window_limit: '上下文上限防止累积绕过',
    },
};

OpenAI 的红队工作。OpenAI 在 o1 / o3 发布前都经历了多轮 red team 评估。具体的 red team 工作包括：(a) 对抗性 prompt generation——专门的 red team 团队（~50 名外部 expert + 内部安全团队）尝试构造 jailbreak prompt；(b) bio/cyber/autonomy 三类风险评估——OpenAI 在 o3 system card 第 4 章详细披露了生物武器、网络攻击、自主 AI 三类 risk 的 baseline 测试；(c) 持续监控——o3 发布后由 red team 持续监控新发现的 attack pattern。

生物风险 (biorisk)。o3 在生物武器相关问题上的能力提升引发关注——o3 比 GPT-4 更擅长回答"如何制造病毒"、"如何合成毒素"等问题。OpenAI 对此部署了 (a) bio-knowledge cutoff——o3 在训练时对最敏感的 protocol 数据进行了额外过滤；(b) dual-use filter——所有涉及 bio-protocol 的输出额外双重 filter；(c) commitment to monitoring——OpenAI 设立"bio-preparedness team"，持续监测 o 系列在 bio-risk 上的表现。

网络风险 (cyber risk)。o3 在 cybersecurity benchmark（如 InterCode-CTF）上达到人类中级 CTF 选手水平。这意味着 o3 可能被滥用于自动漏洞发现、攻击构造。OpenAI 的应对是 (a) defensive cyber focus——训练时显式 reward defensive security；(b) responsible disclosure——当 o3 发现真实漏洞时，OpenAI 配合厂商做 disclosure；(c) cyber-preparedness team——与 bio-preparedness team 平行的 cyber 安全团队。

EU AI Act 的合规挑战。EU AI Act（2024-08 生效）对"通用 AI 模型"提出额外要求：(a) GPAI Code of Practice——所有 GPAI 模型的提供者必须遵守 code of practice；(b) Systemic Risk——超 10^25 FLOPs 训练的系统级风险模型需要额外披露；(c) Transparency——必须披露训练数据来源与版权信息。OpenAI 的 o3 训练算力推测超过 10^25 FLOPs，被划入 "systemic risk" 范畴，需要满足更严苛的合规要求。这是 o 系列进军欧洲市场的一道挑战。

5.8 经济学视角：reasoning 模型对 AI 服务市场的结构性影响

从经济学角度审视，o1/o3 reasoning 模型对 AI 服务市场带来三层结构性影响。第一层：成本结构变化。传统 LLM 服务（GPT-4、Claude 3.5）以"按 token 计价"为主，单次推理成本与 token 数线性相关。reasoning-first 服务（o3、Claude Thinking）则以"按 reasoning 深度计价"为主，单次推理成本变成"基础成本 × effort 系数"，高 effort 档位的成本可以是低档位的 50-100 倍。这种成本结构的非线性变化对客户的购买行为产生深远影响——以前客户关注"每次调用花多少钱"，现在关注"每次任务花多少钱"。这种从"调用成本"到"任务成本"的认知转变会重塑 AI 服务的采购模式，让"reasoning 预算"成为企业 IT 支出的新维度。

第二层：竞争格局重塑。在 pre-training scaling 时代，AI 公司的核心竞争力是"谁有更多算力 + 数据 + 顶级 talent"。在 inference-time scaling 时代，核心竞争力变成"谁有更精细的训练基础设施 + 推理优化 + 工程化交付能力"。这一转变让原本依赖大厂封闭平台的中小企业有机会通过专项优化实现差异化——例如 Groq（推理优化硬件）、DeepSeek（低成本 MoE + 开源）、Anthropic（对齐 + 编程场景）。竞争维度从"算力规模"扩展到"推理经济性"，让 AI 行业的"长尾效应"增强。

第三层：劳动力市场冲击。Reasoning 模型在数学、科学、编程任务上达到或超过人类专家水平，引发对应岗位的劳动力替代讨论。但与 GPT-4 时代"white-collar work 自动化"的笼统讨论不同，o3 时代的 reasoning-first 模型更能精准替代特定 reasoning 任务——例如初级程序员（o3 在 SWE-bench 上 71.7%）、初级金融分析师（o3 在 CFA 上超 80%）、初级法律咨询师（o3 在 BAR 上超 90%）。这种reasoning-task-level automation比"white-collar automation"更精细也更激进，可能在 2026 H2 引发显著的就业结构变化，类似于 2010 年代自动驾驶对卡车司机行业的影响。

// Reasoning 模型对劳动力市场影响的量化估算
const reasoningLaborImpact = {
    // 按职业分类的 reasoning 任务自动化率（o3 估计）
    juniorProgrammer: { automation: 0.7, salary: 80000, jobsAtRisk: 5000000 },
    juniorFinancialAnalyst: { automation: 0.6, salary: 70000, jobsAtRisk: 2000000 },
    juniorLawyer: { automation: 0.5, salary: 90000, jobsAtRisk: 800000 },
    juniorConsultant: { automation: 0.4, salary: 75000, jobsAtRisk: 1500000 },
    mathematician: { automation: 0.3, salary: 120000, jobsAtRisk: 50000 },
    // 总估算：reasoning 任务自动化可能在 2026-2028 影响约 1000 万岗位
};

// 经济影响
const economicImpact = reasoningLaborImpact.sum(jt => jt.jobsAtRisk * jt.salary);
const lossToGDP = economicImpact * 0.02; // 估算占 GDP 2%
console.log("reasoning-task automation economic impact: $" + lossToGDP.toFixed(1) + "B");

第四层：政府监管响应。Reasoning 模型对劳动力市场的冲击引发各国政府的监管响应。中国 2025-03 颁布《生成式 AI 服务管理办法》要求 reasoning 模型必须提供"任务透明度报告"——披露高 stakes 任务（医疗、法律、金融）的 reasoning 准确率。欧盟 AI Act（2024-08 生效）将 reasoning 模型划入"systemic risk"层级，要求通过额外 compliance check。美国国会在 2025 H1 提出"AI Workforce Displacement Act"，要求企业为"AI 替代"员工提供再培训补贴。这些监管响应会在 2026 H2 进一步分化，可能形成"中美欧三方不同 AI 监管范式"。

5.9 AI 安全研究前沿：mechanistic interpretability 与 reasoning 内部

Reasoning 模型的能力提升伴随着 AI 安全研究的深化。本节讨论 mechanistic interpretability（机制可解释性）在 reasoning 模型中的最新进展。

Reasoning circuit discovery。Anthropic 在 2024 Q4 发布了一系列 "reasoning circuit" 研究，识别出 reasoning 模型在 CoT 内部调用的具体子网络："数学事实检索电路"、"逻辑推导电路"、"反向验证电路"。这些电路在底层 transformer 中以 特定 attention head 组合 形式存在，可通过 ablation、activation patching、probing 等技术识别。这是从"黑箱"到"透明化神经网络"的关键步骤，为 reasoning 模型安全审计提供了工具。

// Mechanistic interpretability 分析 reasoning 模型的电路发现
function identifyReasoningCircuit(model, prompt, cotTokens, layerIndices) {
    // 1. 收集每个 layer 的 activation
    activations = collectActivations(model, prompt, cotTokens, layerIndices);

    // 2. Activation patching：识别哪些 head / neuron 对特定推理步骤至关重要
    causalNeurons = [];
    for (layer in layerIndices) {
        for (head in layer.attentionHeads) {
            // Patch 此 head 的 activation 为 zero，看 cot 生成变化
            patchedOutput = patchAndForward(model, head=zero);
            if cosineSimilarity(patchedOutput, originalOutput) < 0.95 {
                causalNeurons.append({layer, head, importance: cosineSimilarity});
            }
        }
    }

    // 3. 构建 reasoning circuit 图
    circuit = buildCircuitGraph(causalNeurons);
    return circuit;
}

// 推理发现的典型 reasoning circuit 示例：
// "Left + Right = Result" circuit：layer 12-18, attention head 3-7, MLP neurons 1024-2048
// "Verify Result" circuit：layer 25-30, attention head 1-4, MLP neurons 4096-8192

Reasoning faithfulness。另一个研究问题是"模型在 CoT 中是否真的按其表述的推理路径思考"。Anthropic 2024 年的 "reasoning faithfulness" 研究发现：模型在 CoT 中给出的推理步骤与实际内部推理并不完全一致，存在"post-hoc rationalization"（事后合理化）现象——模型先得出答案，再"编造"出看起来合理的 CoT。这一发现对 o1/o3 隐藏 CoT 策略提出了警示：用户无法直接根据 CoT 判断模型的真实推理。

Safety circuit design。基于 mechanistic interpretability，可以设计 "safety circuit"——专门用于检测危险推理模式的子网络，在模型内部对 CoT 做实时监控。Anthropic 的 Claude 4 opus 引入了这类电路，OpenAI 的 o3 system card 也提到类似设计。这是 AI 安全从"output filter"到"internal circuit"的范式演进。

承接上文推理脉络，本节将系统展开：

5.10 教育与认知科学的反思：reasoning 模型如何反向影响人类学习

Reasoning 模型的能力提升也引发"人类如何学习与思考"的反思。本节从教育与认知科学视角讨论。

教育场景的双重影响。在 K12 教育场景中，o3 在数学奥赛题上的 SOTA 表现让数学教师角色面临重塑。乐观角度看，o3 可以作为"个性化 AI tutor"——为每个学生提供针对其能力层级的 reasoning 训练。悲观角度看，学生可能依赖 o3 完成作业而失去 reasoning 训练机会，导致 "AI 时代的认知懒化"。这两种可能性已经在 2025 H1 的教育实践中观察到——部分学校引入 o3-based tutoring 后，学生数学成绩短期上升、长期下降。

// Education + reasoning 模型的双向影响建模
const educationImpact = {
    phase_1_intro: {
        // 引入后 6 个月内：短期内成绩提升（个性化辅导）
        mathScoreIncrease: +15,  // 数学成绩平均提升 15 分
        studentEngagement: +20,  // 学生参与度提升
        teacherProductivity: +30, // 教师效率提升（自动化批改）
    },
    phase_2_dependency: {
        // 引入后 1-2 年：依赖性出现
        independentReasoningDecline: -25,  // 学生独立推理能力下降
        cognitiveEffortWillingness: -40,    // 学生不愿意花时间独立思考
        homeworkAuthenticity: -60,         // 60% 作业疑似 AI 完成
    },
    phase_3_adaptation: {
        // 引入后 2-3 年：教育系统反向调整
        newPedagogyFocus: "过程导向而非结果导向",
        assessmentShift: "从答案准确性到 reasoning 质量",
        teachingReform: "教师角色从 '知识传授' 到 '思考引导'",
    },
};

// 这种 adaptation 在芬兰、新加坡等教育先行国家已开始

"Reasoning failure" 的元认知教育。Education researcher Daniel Willingham 在 2024 年提出"reasoning failure"概念——学生不是不能 reasoning，而是不知道 何时需要 reasoning、何时可以依赖直觉。Reasoning-first LLM 的出现恰恰是这种 metacognition 的极端化——模型在 confidence 低时启动 reasoning，在 confidence 高时接受 System-1 答案。这对人类教育的启示是：教学目标应从"做出正确 reasoning"转向"判断何时需要 reasoning"。这种 reasoning-metacognition 教育改革已经在多国学校试点。

Deep Research 模式作为 "研究式学习"。Deep Research 系统处理的正是高等教育阶段学生 / 研究人员的工作流。如果学生从中学阶段就开始用 Deep Research 做课题，长大后"独立研究"的能力可能反而下降——他们更擅长"与 AI 研究员协作"而非"独立研究"。这种研究式学习范式的转变与历史中"图书馆自学 → 网络自学 → AI 协作研究"的演化一脉相承，可能在 2030 年前后成为高等教育的主流模式。

5.11 硬件与基础设施：reasoning 模型对算力需求的重新定义

Reasoning-first 模型对算力的需求结构发生根本性变化。本节从硬件与基础设施角度分析。

训练侧：算力需求"集中化"。训练一个 reasoning-first 模型（o3 等级）需要 ~16k H100 × 120 天 = ~50 万 GPU·小时。这种规模的训练只有超大规模 AI 公司（OpenAI、Google、Meta、Microsoft、字节、阿里、DeepSeek 等少数团队）才能承担。这意味着 "training is concentrated"——reasoning 模型训练成为少数玩家的游戏。

推理侧：算力需求"分散化"。但推理侧的算力需求是分散的——每次 reasoning 推理只需 ~5-30 秒的 GPU 时间，但每天全球可能有 10 亿次这样的推理调用。这意味着 "inference is distributed"——推理算力需要在边缘数据中心、电信运营商机房、终端 GPU 上分布式部署。

// Reasoning 模型算力需求结构
const computeRequirement = {
    training: {
        flops: 5e25,         // o3 训练规模
        duration: "6 months",
        gpus: "16k H100",
        concentration: "centralized (few labs)",
    },
    inference: {
        flopsPerCall: 1e18,  // 单次 o3 推理 ~10^18 FLOPs
        dailyCalls: 1e9,     // 全球每日 10 亿次
        distribution: "10k+ edge locations",
        // 推理算力分散在全球数据中心，需要全球负载均衡
    },
    monthly: {
        trainingGlobal: "1 × 10^26 FLOPs / month",  // 训练
        inferenceGlobal: "3 × 10^26 FLOPs / month", // 推理（更大）
    },
};

// 关键观察：推理算力 > 训练算力，意味着 inference 基础设施比 training 更关键

专用硬件崛起。Reasoning 模型对单次推理的低延迟要求催生了 专用硬件：Groq（基于 LPU，推理延迟 < 100ms）、Cerebras（wafer-scale，推理 + 训练统一硬件）、Tenstorrent（基于 RISC-V，针对 transformer 优化）、Tesla Dojo（自动驾驶方向延伸到推理）。这些专用硬件在 reasoning 推理上比通用 GPU 便宜 5-10 倍，可能在 2026 H2 占据 reasoning 推理市场的 30%+ 份额。

能耗与可持续性。Reasoning 模型的推理算力消耗远高于传统 LLM，单次 reasoning 推理能耗是 GPT-4 的 5-50 倍。如果全球每日 10 亿次推理调用，按平均 50 Wh/次计算，年能耗约 18 TWh——相当于 2 座三峡大坝的年发电量。这种耗能量让 reasoning 模型在 2026 H2 面临"AI 与可持续性"的平衡难题。可能的应对：(a) 模型蒸馏——把 o3 蒸馏到 o3-mini 节省算力；(b) 绿色算力——使用可再生能源数据中心；(c) 碳积分机制——推理服务按碳排放定价。

5.12 个性化与记忆：reasoning 模型如何与个人知识库整合

Reasoning 模型目前主要是"无状态"——每次调用都是独立的。但在 2025-2026 H2，reasoning 模型将与个人知识库深度整合，提供个性化 reasoning。本节讨论 4 个关键方向。

(1) Memory Bank。每个用户维护一个"memory bank"——过去对话、偏好、习惯、上下文的统一存储。Reasoning 模型在每次推理时检索相关的 memory 注入到 prompt，提供个性化回答。OpenAI 的 ChatGPT 在 2024 H2 引入了 memory 功能，2025 H1 升级为 reasoning-aware memory。

(2) Personal Knowledge Graph。比 memory 更进一步，构建用户的个人 knowledge graph——实体、关系、事件的结构化存储。Reasoning 模型在推理时可以"思考"用户的特定实体（如家庭成员、项目、客户），给出高度个性化的推理结果。这种 PKG 技术由 Microsoft Research 在 2024 提出，2025 H1 被多个 LLM 团队采纳。

// Personal Knowledge Graph + Reasoning 模型集成
interface PersonalizedReasoning {
  userPKG: KnowledgeGraph;          // 个人知识图谱
  memoryBank: Memory[];             // 历史对话
  preferences: UserPreference;      // 偏好（语言风格 / 详细度）
  
  reason(query: string): ReasoningResponse {
    // 1. 从 PKG 检索相关实体
    const entities = this.userPKG.searchRelevant(query, topK=10);
    
    // 2. 从 memory 检索相关历史
    const memories = this.memoryBank.retrieve(query, topK=5);
    
    // 3. 构造个性化 prompt
    const personalizedPrompt = `
      User context: ${entities.join(", ")}
      Past interactions: ${memories.map(m => m.summary).join("\n")}
      User preferences: ${JSON.stringify(this.preferences)}
      
      Question: ${query}
    `;
    
    // 4. Reasoning 模型推理
    return this.reasoningModel.reason(personalizedPrompt);
  }
}

(3) On-Device Personal Reasoning。o4-mini 这类小型 reasoning 模型可以在本地终端（手机、笔记本、AR 眼镜）上运行，提供私人 reasoning。这种 "on-device reasoning" 让用户数据不上云，保护隐私的同时提供个性化服务。Apple Intelligence 在 iOS 18 中已经集成 on-device reasoning，标志着 on-device AI 的开端。

(4) Federated Reasoning。更激进的方向是 "federated reasoning"——用户的 reasoning 模型保留在本地，云端只传输"推理结果的 embedding"而非 reasoning 本身。这种架构让 reasoning 模型可以从群体智慧学习但保护个体隐私，是 privacy-preserving reasoning 的前沿方向。DeepSeek 与 Apple 在 2025 H1 都做了相关探索。

承接上文推理脉络，本节将系统展开：

5.13 Deep Research 的垂直化：从 generalist 到 specialist

Deep Research 系统当前是 generalist（处理任意领域的研究问题），但 2026 H2 预计出现多种垂直化变种。本节讨论四个主要垂直方向。

(1) Deep Research for Finance。Bloomberg / 36Kr 等垂直数据源接入，专注金融研究。典型能力：(a) 自动拉取上市公司财报 + 行业数据；(b) 推理出公司估值 + 风险评估；(c) 撰写深度研究报告。Customer：Boutique 投资机构、家族办公室。

(2) Deep Research for Legal。接入 Westlaw / LexisNexis / 国家法律法规数据库。典型能力：(a) 自动检索判例 + 法规；(b) 推理出法律论证 + 反方观点；(c) 撰写法律意见书 + contract review。Customer：律所、合规部门。

(3) Deep Research for Bio/Pharma。接入 PubMed / ClinicalTrials.gov / DrugBank。典型能力：(a) 自动检索临床试验 + 文献；(b) 推理出药物 safety / efficacy；(c) 撰写 regulatory submission。Customer：药企、CRO、监管机构。

(4) Deep Research for Code/Engineering。接入 GitHub、Stack Overflow、技术文档库。典型能力：(a) 自动检索最佳实践 + library API；(b) 推理出架构 trade-off；(c) 撰写 design doc + ADR。Customer：Engineering 团队、CTO Office。

// Deep Research 垂直化的架构示意
class VerticalDeepResearch {
    constructor(vertical, dataConnectors, customPromptTemplates) {
        this.vertical = vertical;          // 'finance' | 'legal' | 'bio' | 'code'
        this.connectors = dataConnectors;  // 垂直数据源
        this.templates = customPromptTemplates;  // 垂直 prompt
    }
    
    async research(query) {
        // 1. 垂直 query 理解：识别任务类型
        const task = this.classifyTask(query);
        // 2. 接入垂直数据源
        const dataSources = this.selectSources(task);
        // 3. 用垂直 prompt templates
        const plan = await this.verticalPlanner.think(query, task, this.templates[task]);
        // 4. 检索 + 推理
        return this.executePlan(plan, dataSources);
    }
}

// 垂直化对 OpenAI 的战略价值：(1) 高单价 ($5-$50 per research)
// (2) 客户绑定 (一旦接入公司数据，切换成本高)
// (3) 安全审计 (垂直领域有明确监管要求，OpenAI 可以提供 "audit-ready" AI)

接续推理分析：

5.14 RL on Human Preference 在 Reasoning 模型上的新范式

传统 RLHF 让模型与"通用人类偏好"对齐。但 Reasoning 任务的偏好需要"专家偏好"——数学老师偏好"分步推理"+ 律师偏好"严格引用"。2026 H2 预计出现"domain expert RLHF"——使用特定领域的专家偏好数据做 RLHF。

这种 expert RLHF 的典型应用：

• Medicine RLHF——医生标注的诊断 reasoning 偏好；
• Law RLHF——律师标注的法律论证偏好；
• Code RLHF——senior developer 标注的代码风格偏好；
• Math RLHF——数学家标注的证明风格偏好。

// Expert RLHF 训练循环
function expertRLHF(basePolicy, expertPreferences, domain) {
    for (step in range(numSteps):
        prompts = samplePromptsFromDomain(domain);
        cotRollouts = basePolicy.generate(prompts, maxTokens=16K);
        
        // 关键：由领域专家标注偏好，而非普通人类
        expertPreferences = await expertLabelers.score(cotRollouts, criteria={
            mathematical_correctness: 0.3,
            proof_elegance: 0.2,
            insight_depth: 0.3,
            presentation_clarity: 0.2,
        });
        
        // PPO 更新 with expert preferences
        policy.update(reward=expertPreferences);
    
    return policy;
}

这种 expert RLHF 的成本远高于通用 RLHF（专家小时费率 $200-$500，普通标注员 $30）。但产出的模型在垂直领域显著优于通用 RLHF——它代表了"对齐精度的极限"。预计在 2026 H2，OpenAI / Anthropic 会推出垂直领域的 expert RLHF 模型。

5.15 multi-step planning：reasoning 模型与 hierarchical planning 的融合

当前 o3 的 CoT 是"flat reasoning"——所有 step 在一个序列中。但 2026 H2 reasoning 模型预计升级为 "hierarchical planning"——CoT 嵌套多层规划。本节深入这个前沿方向。

Hierarchical Task Network (HTN)。经典 AI planning 中的 HTN 把任务分解为 (a) high-level task (e.g., "build a web app")；(b) mid-level subtask (e.g., "design database schema");(c) low-level primitive action (e.g., "create table users"). 这种分层结构让 planning 更接近人类项目管理方式。o5/o6 模型预计采用类似 HTN 结构，把 CoT 分为多层。

// Hierarchical Planning 架构
interface HierarchicalPlan {
    level_0_goal: "用户最终目标";
    level_1_plan: [
        { sub_goal: "子目标 1", level_2_steps: ["步骤 a", "步骤 b"] },
        { sub_goal: "子目标 2", level_2_steps: ["步骤 c", "步骤 d", "步骤 e"] },
    ];
    level_3_primitives: ["API call", "tool invocation", "code snippet"];
}

async function hierarchicalReason(prompt, model) {
    // 1. Level 0: 识别总体目标
    const goal = await model.generate(prompt, maxTokens=200);
    
    // 2. Level 1: high-level plan
    const highLevelPlan = await model.generate(
        prompt: `${prompt}\nGoal: ${goal}\nGenerate high-level plan...`,
        maxTokens=2000,
    );
    
    // 3. Level 2: 对每个 high-level sub_goal 独立 sub-plan
    const subPlans = await Promise.all(
        highLevelPlan.subGoals.map(subGoal =>
            model.generate(
                prompt: `Sub-goal: ${subGoal}\nGenerate mid-level plan...`,
                maxTokens=4000,
            )
        )
    );
    
    // 4. Level 3: 对每个 mid-level step 独立执行
    const primitives = await Promise.all(
        subPlans.flatMap(plan => plan.steps).map(step =>
            model.generate(
                prompt: `Step: ${step}\nExecute...`,
                maxTokens=2000,
            )
        )
    );
    
    return {goal, highLevelPlan, subPlans, primitives};
}

HTN 与 RL 的结合。HTN 结构的 planning 自然适合 RL——每个层级可以独立做 RL 训练。OpenAI 内部代号 "Atlas" 项目可能正在做相关工作。HTN + RL 的关键优势：(a) credit assignment 更容易——每层有独立 reward signal；(b) 可迁移性更强——高层 plan 可以跨任务重用；(c) 可解释性更好——每层 plan 可以 inspect。这三个优势让 HTN+RL 是 2026 H2 的关键技术方向。

5.16 Agentic Memory：从单次推理到跨会话学习

当前 o3 是 stateless（每次推理独立），但 2026 H2 的 agentic memory 让模型跨会话学习。本节讨论 4 个层次。

Layer 1: Episodic memory（情景记忆）。模型记住"我之前做过什么任务、用了什么工具、得到了什么结果"。这种记忆让模型可以在新会话中复用之前的成功模式。

Layer 2: Semantic memory（语义记忆）。模型建立"概念网络"——抽象出问题间的相似性，对新问题自动迁移之前学到的解决方案。

Layer 3: Procedural memory（程序记忆）。模型记住"如何做某件事"——例如"如何调用某 API"、"如何准备某种格式的数据"。这种记忆类似 muscle memory，在执行已学会的任务时自动跳过 reasoning。

Layer 4: Working memory（工作记忆）。模型在 long context 中维持"当前任务相关的信息"——例如在 multi-step 任务中记住"我已经处理了哪些步骤、剩下哪些步骤"。这种记忆是即时性而非持久性。

Memory 存储基础设施。存储这些 memory 需要专门的 infrastructure：

• Episodic memory 存储在向量数据库（Chroma、Pinecone）；
• Semantic memory 存储在 knowledge graph（Neo4j、ArangoDB）；
• Procedural memory 存储为可执行的工具链（类似 AutoGPT）；
• Working memory 存储在 KV cache + context window。

这种多层 memory 设计是实现 AGI-level autonomous agent 的基础设施。预计在 2026 H2 会有专门的"agentic memory platform"出现，对标今天的 vector database platform（如 Pinecone）。

6.1 范式跃迁的哲学思考：从工具到协作者的 AI 演化

从更宏观的视角看，o1/o3 的范式跃迁不仅仅是"LLM 的能力提升"，更是"AI 在人类工作流中角色定位"的根本转变。本节从认知科学 + 计算机史 + 商业战略三个维度做总结思考。

认知维度：从"工具"到"协作者"。传统 LLM（GPT-3.5/4）的角色接近"高级工具"——人类提问，模型回答，本质上是更智能的搜索引擎 / 写作助手。o1/o3 之后的 reasoning 模型则接近"思考协作者"——人类描述问题，模型自主 reasoning 出多步推演、验证、纠错，最终给出结论。这个转变与"从命令行到 GUI"、"从手写代码到 AI pair programmer"类似，本质上是把人类从"操作"中解放到"决策"。

这种角色转变对人类技能要求的影响：(a) 写作能力要求下降——模型写得好；(b) 问题定义能力要求上升——用对 prompt 决定模型输出质量；(c) 批判性思维要求提升——模型输出仍可能错，需要人评估。从"会写"转向"会想"，是人类工作流的关键升级。

计算机史维度：从 expert system 到 reasoning-first LLM。Reasoning-first LLM 与 1980 年代的 expert system 有相似之处——都强调"显式的推理逻辑"。但 expert system 受限于"人工设计规则"，扩展困难；reasoning-first LLM 则是"模型学到的 reasoning"，通过 RL + 长 CoT 自然涌现。这个"从手工规则到学习规则"的飞跃是 AI 史上的核心范式跃迁，与"从手工特征到深度学习特征"一样具有变革意义。

商业维度：从订阅服务到推理消费。OpenAI 的 ChatGPT Plus 订阅是典型 SaaS 模式（$20/月固定费用）。但 o3 API 按推理深度计费（reasoning_effort=high 时 $60/$240 per 1M tokens）已经向"按推理消费"靠拢。这种"从订阅服务到推理消费"的趋势可能延伸到 B2B 场景——企业不再为"AI 用户席位"付费，而为"AI 推理次数 × 推理深度"付费。这是 AI 商业模型的范式变革，类似云服务的"pay-as-you-go"相对传统 license 的转变。

// AI 商业模型演进
const aiBusinessModel = {
    era_1_2018_2022: {
        model: "API call fee",
        unit: "1M tokens",
        pricingExample: "$0.02 per 1M tokens (GPT-3)",
        customerExpectation: "cheaper is better",
    },
    era_2_2023_2024: {
        model: "Subscription (B2C) + per-seat (B2B)",
        unit: "monthly fee",
        pricingExample: "$20/month (ChatGPT Plus), $30/month (user) (Copilot)",
        customerExpectation: "unlimited use within subscription",
    },
    era_3_2024_2025_reasoning: {
        model: "Reasoning-tier pricing",
        unit: "reasoning_effort + tokens",
        pricingExample: "$60/$240 per 1M tokens (o3)",
        customerExpectation: "depth vs cost trade-off",
    },
    era_4_2026_outlook: {
        model: "Outcome-based pricing",
        unit: "task completed × task complexity",
        pricingExample: "$5 per research report, $50 per code review (Deep Research)",
        customerExpectation: "pay for results, not infrastructure",
    },
};

接续推理分析：

6.2 中国 reasoning 生态：从 DeepSeek 到字节豆包思考

中国 LLM 行业在 o1 发布后迅速跟进，已在 2025 H1 形成"中国 reasoning 生态"。本节横向对比中国主要团队的 reasoning 进展。

DeepSeek-R1。DeepSeek（深度求索）在 2025-01 发布完整开源的 R1，是国际开源 reasoning 的标杆。R1 的核心贡献是：(a) 完整披露 GRPO 算法；(b) 公开 R1-Zero 涌现 reasoning 行为；(c) 开源 1.5B-70B 全谱 distilled model。中国学术界 + 开源社区快速跟进，催生了 50+ R1 复现项目。

Qwen（阿里）。Qwen 在 2025-01 推出 QwQ-Preview（推理预览版），2025-02 推出 QwQ-Max（数学奥赛级）。阿里在 reasoning 训练上加大了投入，传闻训练算力达 1 万 H100。Qwen 系列在中文语境下表现优异。

Kimi（月之暗面）。Kimi 在 2024 H2 推出 K0-thinking 模式，主打"长上下文 reasoning"——支持 200 万 token 上下文推理。Kimi 在中文长文档 reasoning 上有独特优势。

文心 / 智谱 / 百川 / 零一万物。百度文心、智谱 GLM 等团队在 2025 H1 都推出 reasoning 版本，但具体能力相对 DeepSeek-R1 与 Qwen 略弱。中国 reasoning 生态在 2025 H2 进一步分化——头部团队（DeepSeek、Qwen、Kimi）走向国际化，二三线团队专注国内 + 垂直场景。

中国 reasoning 生态的差异化路径。中国团队在 reasoning 化中走出与海外不同的道路：(a) 开源 + 低价——DeepSeek、R1 引领开源 reasoning；(b) 中文优化——Qwen、Kimi 等专注中文 reasoning 能力；(c) 垂直场景——法律（北大法宝）、医疗（医联）、教育（作业帮）等垂直 reasoning 应用。这些差异化让中国 reasoning 生态在国际竞争中形成独特位置。

承接上文推理脉络，本节将系统展开：

6.3 关键经验总结：reasoning-first LLM 工程的 7 个金律

经过 22 章的深度探讨，我们提炼出 7 个对 reasoning-first LLM 工程师最有价值的金律。

金律 1：reasoning 是训练问题，不是 prompt 问题。所有 prompt 工程技巧（CoT prompting、self-consistency、tree-search）在 Base Model 策略分布未偏 reasoning 时都收效甚微。要让模型真正具备 reasoning 能力，必须在 RLVR 训练中显式 reward Long CoT。

金律 2：PRM 是 reasoning RL 的基础设施。Outcome reward 在 Long CoT 上有 sparse reward 问题（credit assignment 几乎不可能）。PRM 通过 step-level reward 把 RL 训练变为 dense reward，是 Long CoT 训练成功的必要条件。投入 PRM 训练算力是回报率最高的工程决策。

金律 3：RLVR 优先于 RLHF。在可验证领域（数学、代码、定理）做 RLVR 比 RLHF 更高效（廉价、客观、可规模化）。RLHF 只在 alignment 阶段作为最后一步使用。Capabilities 优先，alignment 次之。

金律 4：hidden CoT 是商业决策 + 安全护栏。CoT 隐藏不是纯产品体验选择，是 IP 保护 + 反 distillation + 成本透明化的复合决策。Anthropic 选择显示 CoT 是其"透明优先"哲学，不是技术上必须。

金律 5：推理算力与训练算力是平行维度。Pre-training scaling 在 2023-2024 饱和，inference-time scaling 在 2024-2026 取代它成为 scaling 的主轴。把训练算力投入"更聪明的小模型 + Long CoT 推理" 比 "更大的 dumb 模型" 性价比高 5-10×。

金律 6：reasoning agent 需要元认知 verifier。Reasoning 模型不仅是"执行者"，还需要"判断自己是否错"。PRM + deliberative alignment 让模型具备元认知能力，是长 horizon agent 任务的工程条件。

金律 7：开源是范式扩散的最大加速器。DeepSeek-R1 的开源让 reasoning 训练在 6 个月内从 OpenAI 的独占资产变成公共技术。任何有 GPU 的团队都可以复现 reasoning-first 训练。这意味着未来 5 年的 LLM 演化不只由 OpenAI 决定，而是由全球 AI 社区共同推动。

// Reasoning-First LLM 工程的 7 个金律
const reasoningGOLDEN_RULES = {
    1: "reasoning 是训练问题，不是 prompt 问题",
    2: "PRM 是 reasoning RL 的基础设施",
    3: "RLVR 优先于 RLHF（capability first，alignment last）",
    4: "hidden CoT 是商业决策 + 安全护栏（IP + distillation + 成本）",
    5: "推理算力与训练算力是平行维度（test-time scaling 主轴）",
    6: "reasoning agent 需要元认知 verifier（PRM + deliberative）",
    7: "开源是范式扩散的最大加速器（DeepSeek-R1 的示范）",
};

// 实施优先级（基于 ROI）
const implementation_priority = {
    p0: [1, 2, 3],          // 必做：无 PRM 不可能做 reasoning RL
    p1: [5, 6],             // 推荐：test-time scaling + 元认知
    p2: [4, 7],             // 可选：商业策略调整
};

这 7 个金律是从 o1-preview 到 o4-mini 的工程实践中提炼的经验总结。它们既适用于 OpenAI 内部的模型研发，也适用于任何想从 GPT-4 升级到 reasoning-first LLM 团队的工程决策。Reasoning 范式不是 OpenAI 的偶然发明，而是 LLM 演化的必然路径——任何团队在 2026 年前不跟进 reasoning，都将在未来 5 年的 AI 竞争中边缘化。