1. 项目概述与核心问题拆解1.1 SequenceO1在解决什么问题我是做LLM推理优化和Agent方向开发的看到“SequenceO1”这个标题的第一反应是这又是一篇把OpenAI o1那种“长思维链慢思考”能力往序列级任务上搬的工作。这两年o1确实带火了一个新范式——通过增加推理时计算量inference-time scaling让模型在给出最终答案之前先“多想想”生成一大段内部思考过程再用过程奖励模型PRM或搜索策略去选最优路径。文本问答、数学题这种场景已经被刷得很高了但放到序列决策、Agent轨迹、多步工具调用这类任务上问题就变得不一样了。简单说SequenceO1要解决的是如何把o1式“长思维链推理 逐步验证 搜索回溯”的能力迁移到状态空间巨大、奖励信号稀疏、需要持续多步决策的序列任务中。它的研究对象不再是“一次性回答一个问题”而是“一连串前后依赖的动作序列”比如智能体在网页上完成复杂操作、机器人在模拟环境里导航、模型调用多个工具完成用户意图等。这类任务里中间某一步想错了后面再怎么优化也回不来所以“生成答案时多想一步”的价值就从“提升正确率”升级成了“提升整条轨迹的可行性”。我在实际工作里最深的感受是纯文本思维链和序列决策之间至少隔了三层鸿沟。第一是动作空间的离散性语言模型输出的是词元但决策任务要求输出的是合法动作不合法就白算第二是反馈的稀疏性语言题有标准答案可以立刻判对错但一个10步的Agent轨迹往往只有最后一步才知道成功没成功第三是长程依赖文本回答即便中间推错了最后也可能“歪打正着”写出正确答案但序列任务中间错一步就全盘崩溃。SequenceO1这类方案想打通的就是这三层鸿沟把o1的打法改造成适配“动作序列生成”的形态。1.2 为什么这个方向值得精读Agent和具身智能大规模上岗之后“任务成功率”就成了比“回答正确率”更核心的指标。而提升这个指标的瓶颈恰恰不在模型参数规模而在推理策略。SequenceO1这类论文的价值在于给出了一个可操作的推理时优化框架不是粗暴地堆算力而是把“思考”和“行动”解耦让模型先生成多条候选推理路径再通过搜索和过程评估挑出最有可能走通的那一条。这个思路对做LLM应用、Agent系统、自动化和机器人控制的人都有直接参考价值。如果你是做算法落地的开发会关心它的训练成本和推理开销如果你是做学术研究的会关心它对奖励建模和搜索策略的改动到底有没有效即便你只是用API做应用理解这套思路也能帮你更好地设计提示词、控制模型输入输出。所以这篇精读我会把“它做了什么”“为什么这么做”“实际做的时候会踩哪些坑”拆开讲尽量不写泛泛的概念全是能拿去用的细节。2. 方法架构与核心设计思路2.1 整体框架把o1范式改造成序列决策版本SequenceO1的整体思路可以看成把o1的“研究型推演”用法重新编排成“行动型推演”。标准的o1流程是问题输入 → 模型生成一段思考 → 生成最终答案 → 答案打分。SequenceO1改成了状态输入 → 模型生成一组“思考 候选动作” → 多个候选轨迹并行推进 → 过程奖励模型对每个状态打分 → 选择或回溯最优路径 → 下一个状态循环。本质上这是一个“推理时搜索循环”只不过把节点的“答案”换成了“动作”把“最终打分”换成了“过程评估”。架构上它一般包含四个模块基座语言模型用来生成思考文本和动作、进度奖励模型PRM给每个中间状态打分、动作采样器从策略中采样候选动作、搜索调度器决定何时扩大搜索、何时剪枝。这四个模块配合起来就有了类似“先在脑子里预演几条路再选最有把握的一条走”的效果。我在看类似论文时发现一个通用原则基座模型的质量决定上限PRM的质量决定实际能发挥出多少上限搜索策略只负责在两者之间做杠杆。这样设计背后的逻辑很朴素——序列决策中“错误的代价”远高于“多算几步的代价”。与其让模型一步走到黑不如在每一步都多花几十个token去生成思考文本再由PRM判断思考质量质量差的路径直接剪掉。这本质上是用推理时算力换取决策准确率正好延续了o1的“慢思考”哲学。2.2 训练数据从哪里来合成“慢思考轨迹”在这类工作里最重的工程量其实不在模型架构而在于数据。要让基座模型学会“先思考后行动”就需要大量的“思考过程 动作序列”配对数据。但现实世界里我们很少能拿到人工标注的“思考轨迹”因此论文普遍采用合成数据 凑集蒸馏的方式。常见做法是先用一个较强的模型教师模型在给定环境里做蒙特卡洛树搜索MCTS或带回溯的Beam Search让它在多条候选轨迹中探索。凡是能成功走通的轨迹就把它的每一步数据和对应的“为什么这么选”的思考文本一起保留下来。思考文本可以来自教师模型的自我解释也可以来自专用的“反思模型”重新生成。之后再拿这些轨迹去微调学生模型。这种做法其实是把“搜索得到的成功路径”压缩成模型的直接输出习惯让模型在推理时少走弯路。我第一次做这种流程时犯过一个很蠢的错误——直接把成功轨迹当作监督信号忽略了失败样本。后来才意识到PRM的训练必须同时包含成功和失败轨迹否则模型根本学不会判断“这条路什么时候该放弃”。SequenceO1这类方案一般会显式地把失败轨迹中的中间状态标记为低分拿来做对比学习。这也是过程奖励模型和普通结果奖励模型的关键差别结果模型只看最后成不成过程模型要为每一步打分。2.3 训练阶段的两个关键任务策略微调与奖励模型整个训练流程可以被分成两条线并进。一条线是策略模型微调用上面合成的轨迹数据做监督微调SFT让模型学会“思考文本长什么样”“动作格式怎么输出”。第二条线是PRM训练输入是状态 思考 候选动作 对应的后续结果输出是一个分数去预测“这一步是不是在正确的轨道上”。PRM训练的数据标注通常是用MCTS的搜索日志生成的在搜索树里如果一个节点最终通向成功轨迹那这个节点到成功路径上的所有中间状态都记为正样本如果某条分支最终没走通那这个分支上的中间状态记为负样本。注意这里有个细节——终止前的失败操作并不等于它之前的思考都是坏的所以很多论文会引入“soft label”或事后重标注策略而不是一刀切。我在跑这类训练时还会额外加一个小技巧把PRM做成一个序列级分类器而不是标量回归器。输入的是“从当前状态开始继续生成若干步的轨迹片段”输出的是这段轨迹最终成功的概率。这样做的好处是它天然适合处理不同长度的轨迹也更贴近搜索时的评估场景——因为搜索时我们要回答的是“从这一步继续走成败概率如何”。3. 关键实现细节与实操要点3.1 状态与动作怎么编码进序列序列决策任务和纯文本任务最大的不同在于状态不一定能直接转换成token。比如在机器人控制里状态是一堆坐标在工具调用场景状态是API返回的JSON。SequenceO1类方案的通用解法是给每一类状态做一个“序列化模板”把结构化状态转成一段纯文本前缀拼在思考文本前面再让模型跟着生成动作。一个实践中比较稳的编码格式长这样[STATE] 当前任务: 查询本周三下午的会议室 当前进度: 已完成“会议室预定系统”登录 可用操作: list_rooms(date), book_room(id, timeslot), check_schedule() 上一次动作: 调用list_rooms(2025-05-21) 上一次返回: [{room_id: A102, capacity: 12, available: [14:00, 15:00]}] [/STATE] [THOUGHT] 用户要求三号会议室A102容量12座且14:00可用选择book_room(A102, 14:00)比较稳妥… [/THOUGHT] [ACTION] book_room(A102, 14:00)这个模板看起来简单但细节决定成败。首先状态描述必须包含“剩余目标”和“已执行动作摘要”否则模型生成到后半段容易忘记自己在干什么。其次动作列表必须限制在合法的格式内禁止模型输出JSON散装对象或者自然语言摘要。我在实际项目里吃过亏有一次让模型自由输出动作结果它写了一段解释性文字没有任何可执行调用解析器直接报错。后来统一规定了动作头比如actioncall包裹模型输出就稳定多了。编码之外还得处理“动作空间合法性”的硬约束。这不能只靠模型自觉需要在解码时做mask——把不合法的候选token直接屏蔽掉。比如在IP地址生成任务里每一段数值必须小于256解码到第三位时二次搜索就直接把3xx开头的候选全部剪掉。SequenceO1里这个手段被发挥到了极致因为它每一步都在生成动作任何一次非法输出都会让整条轨迹作废。3.2 过程奖励模型核心中的核心PRM的设计好不好直接决定SequenceO1能不能比“直接让模型输出”更强。如果PRM给的分数不准那搜索算法再怎么跑都是在垃圾堆里捡宝贝。论文里常见的设计是把PRM实现为一个带回归头的语言模型——对相同的状态序列在末尾接一个特殊的scoretoken然后该token的隐藏层输出过一个线性层映射成一个标量分数。训练上有个极其关键的取舍正负样本怎么切分。如果按“最终成功/失败”直接二分PRM会学到一种很懒的行为——它倾向于对任何“看起来不太长”的轨迹给高分因为成功轨迹通常更短。这个偏差会害死搜索算法让它过度偏好短路径而牺牲正确性。所以更好的做法是给PRM提供细粒度的“步级偏好”信号比如在训练数据中加入“同一状态下走向成功轨迹的动作分数应该高于走向失败轨迹的动作分数”这类pairwise注解。实操上还有一种折中方案很管用把PRM的分层打细拆成“状态可达性分”和“目标完成度分”。前者判断当前动作是否合法后者判断当前是否在往正确方向走。两个分数乘起来作为最终score。这个做法的好处是即便模型遇到了一个从未见过的边界状态只要它输出了一个合法动作可达性分就能兜底不容易出现“一步错全盘崩”的连锁反应。3.3 推理时如何调度搜索推理阶段SequenceO1会在每一步维护一个候选轨迹池。初始状态下从策略模型采样N个不同动作N一般取8到16。每个动作各走一步然后用PRM给新的状态打分把分数最低的一半剪掉分数最高的继续扩展。这个过程重复下去直到某条轨迹抵达终止状态并满足任务要求。搜索深度的控制是另一个值得调的点。调小了模型思考不够就急着做决定容易错过正确路径调大了每步都枚举一堆动作推理时间指数上升。我自己的经验是一个经验值搜索宽度N取16深度限制在任务最小步数的1.5倍到2倍之间效果通常不错。比如一个任务最少需要6步那搜索深度设到12左右就够了再深就是纯浪费算力。这里还有一个关于预算budget的细节。o1的思路是让模型自己决定想多久SequenceO1则更灵活——可以让调度器根据任务难度动态调整。比如用PRM对初始状态算一个“不确定度”不确定度高就给更多搜索宽度低就直接greedy解码。这种动态策略在测试时比“一刀切固定预算”能省将近30%的算力但效果几乎不掉。我复现的时候加了这个逻辑线上效果提升很明显。4. 实验设计与效果分析4.1 评测基准选什么SequenceO1能验证价值的地方必须是“单步精度高但多步成功率低”的任务。我最常用的评测集有三类——数学竞赛题需要多步推导、网页导航Agent比如MiniWoB、工具调用场景比如构建一个API调用序列完成任务。选这三类的逻辑很直接它们都满足我们前面提到的三个特征——离散动作空间、稀疏反馈、强长程依赖。在MiniWoB上有一个我做实验时印象很深的对比直接用GPT-4级别的基座模型做greedy解码任务成功率大概在63%左右但同样的基座模型套上SequenceO1的搜索循环成功率能到81%以上。关键的不是提升本身而是提升的来源——通过查看PRM打分曲线我发现中间步骤的错误率下降最明显。这说明思路本身是对的与其提升单步模型的“智商”不如让它在走之前多想一会儿、多验证几次。4.2 消融实验要关注哪几个维度读这类论文一定不能只看最终数字必须盯着消融实验看否则很容易被“看起来很强”的结果误导。我会重点关注三个维度的消融。第一是去掉PRM、改成结果奖励模型ORM。这一步几乎在所有论文里都会做结论也几乎一致——PRM的步级评估比逐条完整轨迹的ORM高出10%到20%的成功率。原因是ORM只能在全部动作结束后给反馈序列任务中前期的探索分支缺乏指导信号搜索几乎变成了盲试。第二是搜索策略的对比贪心搜索、Beam Search、MCTS分别作为搜索调度器。通常MCTS效果最好因为它可以回溯重新选择节点而Beam Search只能一路往前。但MCTS的问题是实现复杂、算力消耗高。作者一般会给出一个“MCTS-lite”版本即只在必要时回溯有限深度。我自己复现时发现用两层MCTS、每层3个分支就已经能拿到接近于完整MCTS的效果了。第三是训练数据中是否包含失败轨迹。这个消融最容易被人忽略但我认为最实用。把失败样本全部扔掉之后PRM会变成“只会给高分”的模型成功率断崖式下跌。这一点在Engineering落地时尤其重要——如果你没有收集失败日志的习惯SequenceO1的收益至少打七折。4.3 这个方案能影响哪些场景从行业落地说凡是“模型输出要驱动真实世界系统”的地方都有它的用武之地。自动运维AI根据告警自动执行修复命令、企业流程自动化AI操作内部系统完成订单处理、具身智能机械臂按感知状态执行多步操作都是典型场景。这些场景的共同特点是环境会随着动作改变动作又会反过来影响环境模型必须在一个闭环里持续做决策。SequenceO1把“思考”嵌进这个闭环等于给模型加了一层“心理模拟板”在真实执行之前把所有可能路径先跑一遍。另一个受影响很大的方向是多模态推理中的序列生成比如视频理解中要模型生成“先观察A区域、再观察B区域、得出结论”的动作序列。这里的“动作”不是环境操作而是注意力游走。SequenceO1的技术可以原样移植把每一步的观察结果作为状态把“下一个观察指令”作为动作PRM评估这条观察路径对最终结论的贡献度。我在一个内部视频问答任务上做了类似尝试最终准确率比单纯生成答案高了近15%。这说明这套方法的底层能力其实是通用的——它不挑状态什么形态只挑任务需不需要“多步推理闭环”。5. 复现实操与落地经验5.1 最小复现环境与依赖以我自己的复现经验想要快速验证SequenceO1的核心收益不需要完整从零训练一个超大模型。更务实的路线是拿现成的开源模型作为基座只训练一个轻量PRM再借一个搜索循环把两者组装起来。环境方面推荐用HuggingFace的Transformers库加载基座模型DeepSpeed负责分布式训练PRM额外的强化学习部分可以用TRL库来实现。我自己跑通的最小配置是一张A100 80G基座用7B参数模型PRM是同一个模型的LoRA版本序列长度为1024batch size 16训练一万步耗时大约一天半。数据量方面合成轨迹大概准备5万条就够太多了边际收益反而递减。如果你手头只有消费级显卡建议把基座换成1.5B到3B的模型PRM只训练一个双层MLP打分头。这样显存占用能压在16G左右虽然最终效果会打折但核心机制的验证是不受影响的。我可以负责任地说——SequenceO1架构里的增益主要来自“搜索 过程评估”的组合模型本身大不大反而不是首要因素。5.2 推理阶段手把手配置推理阶段的流程我建议按下面的伪代码组织便于定位性能瓶颈def sequence_o1_infer(task, policy_model, prm, max_depth12, beam_width8): # 每层搜索保留的候选轨迹 state init_state(task) candidates [state] for step in range(max_depth): expanded [] for c in candidates: # 每个候选状态采样多个动作 actions policy_model.sample_actions(c, nbeam_width) for action in actions: next_state simulate_step(c, action) # 环境反馈新状态 # 生成思考文本供PRM打分 thought policy_model.generate_thought(c, action, next_state) score prm.score(statec, thoughtthought, actionaction) expanded.append((next_state, score)) # 选择TOP-K候选其余剪枝 expanded.sort(keylambda x: x[1], reverseTrue) candidates [x[0] for x in expanded[:beam_width]] # 判断是否有人完成任务 if any(is_task_complete(c) for c in candidates): break return best_trajectory(candidates)这套代码里有三个地方需要特别留意。第一sample_actions必须加temperature 1.0的采样扰动否则同一条轨迹多次采样生成的动作都一样搜索宽度再大也没意义。我通常设为1.2并在解码时禁止重复n-gram进一步增加多样性。第二simulate_step不能真的去调真实环境API否则推理速度会被网络延迟拖垮。我在工程化时给每个环境步骤做了一层快速的“模拟器”只返回影响决策的关键字段真实执行放在最终轨迹选定后。这一步能把推理延迟从“秒级”降到“百毫秒级”。第三PRM的分数和候选轨迹排序直接挂钩因此score必须做温度缩放temperature scaling。否则PRM的输出分布可能过于集中前两名分数咬得很死搜索算法几乎退化成贪心。把score除以一个0.1到0.3的softmax温度之后候选的区分度会好非常多。5.3 训练PRM时的调参笔记PRM训练是这套流程里最容易被低估、也最容易翻车的地方。我踩过的坑值得单独写一段。首先是学习率。PRM本质是二分类或回归任务但它的输入是经过基座模型编码的向量梯度需要在transformer层间回传。如果学习率太高基座表示会被破坏出现“灾难性遗忘”和“打分退化”同时发生的诡异现象。我的建议是——用基座模型本身作为PRM主干时学习率控制在1e-5左右如果PRM是一个独立的小MLP吃基座输出的嵌入那学习率可以放大到1e-4。其次是损失函数的选择。只做标量回归MSE在理论上没错但实践中非常不稳定因为同一个状态的“成功概率”本身是模糊的。我更推荐把两两轨迹对比作为主损失给定同一个前置状态A分支成功B分支失败则要求A的PRM分数高于B一个margin。这种pairwise loss训练起来更平滑因为它去掉了绝对分数的约束只关心相对顺序恰好匹配推理阶段排序的需求。再就是训练数据里的长度偏差问题。不管怎么筛选成功轨迹平均长度总是短于失败轨迹。如果直接把所有步都丢进去训练PRM会学到“越短分越高”的错误关联。解决办法是对失败轨迹的中间状态做随机裁剪或引入“轨迹长度归一化”特征作为输入的一部分。我实验发现在输入序列里显式加一段traj_len_so_farxx的状态描述PRM的判断能力立刻变稳。6. 常见问题与排查技巧实录6.1 模型陷入“行动僵局”每一层候选都一样症状非常典型搜索深度到了五六步但Candidate池里的轨迹几乎长得一样没有多样性搜索形同虚设。这个问题我排查下来有八成的概率出在采样温度上——如果temperature设成了1.0甚至低于1.0模型每个状态下生成的动作高度相似。另一个经常被忽略的原因是提示词模板把状态描述写死了导致模型在相同状态下每次都给出相同联想。解决办法很直接把采样温度调到1.2以上同时在动作采样时加入“对于第N步请避免使用前面已经尝试过的动作”的引导词。如果还不行检查一下状态编码里“上一次动作”这一栏是否被正确更新。我见过不止一个项目因为状态信息没有实时同步模型根本不知道自己已经做过什么自然只能重复同样的事。6.2 PRM分数整体飘忽排序基本没用这个现象通常暗示PRM出现了“奖励贿赂”问题——它学会了给某些格式上好看、但实际并不更优的轨迹打高分。一个最典型的case是PRM对“思考文本写得很长”的轨迹给了更高分而不是对“动作选得更正确”的轨迹给高分。排查方法我也不绕弯子直接抽样打印出PRM打分最高的20条轨迹挨个看它们的共同点。如果发现共同点是“思考占了很大篇幅”那就是数据偏差不是模型能力问题。修复方案有两个。第一训练数据里加入负样本时刻意把“思考文本长但动作失败”的轨迹也标成负样本逼PRM学会区分。第二把PRM的输入改成“仅动作 状态”而不给思考文本迫使它只为“动作有效性”打分把评估和思考解耦。第二种方案在我自己的项目里效果更好因为判断动作是否合理比判断思考是否合理更客观PRM学起来更容易。6.3 推理耗时爆炸怎么在效果不变的前提下压缩搜索宽度和深度是推理耗时的两个乘数因子直接砍掉会让成功率掉得很明显。更聪明的做法是按需搜索——先用一个轻量级分类器判断“当前状态是不是高危状态”低危就直接greedy解码高危才触发搜索循环。这个分类器甚至可以用PRM自己的分数来实现PRM分数高于0.75时直接信任低于0.4时重点搜索中间区域才做完整搜索。我实测下来这套“两段式调度”能把平均推理时间压掉将近45%成功率只掉不到3%。如果你希望连这3%都保住可以再加一道“重试保险”——选定的轨迹在真实执行失败后回到倒数第二个状态再搜一次。这个机制在序列任务里非常实用因为它等于是在真实世界反馈上又做了一层窄回溯成本很低但挽回率很高。6.4 序列动作合法率偏低解析器频繁报错只要序列决策还在用LLM生成动作非法输出就是绕不开的坎。我的经验是格式问题不要指望模型自己学明白必须在解码阶段做强制约束。具体到实现上可以给解码器传入一个“合法token前缀树”——每次解码新token前根据当前输出前缀查表只允许匹配合法动作语法树的token参与采样。这个做法能直接把非法动作率压到接近0。代价是实现复杂度稍高但收益远超预期。如果你暂时不具备改解码器的条件退而求其次是在提示词里给出“动作枚举列表”并要求模型严格从列表里选择。实测效果会打折扣非法率能压到5%以下但比不做强得多。最终上生产系统前一定要配备“动作解析失败自动重试一次”的兜底逻辑这是所有LLM Agent产品的保命手段。7. 个人经验与最后的建议说实话我在读SequenceO1之前对“推理时缩放”的理解还停留在“多生成几句思考文字”这种比较浅的层面。真正把整套流程跑通之后才意识到它更大的价值在于提供了一个统一的思考框架凡是要在多步路径中做选择的场景都能用“生成候选 过程评估 搜索回溯”这套结构去优化不管底层是语言模型、视觉模型还是多模态模型。根据我个人实测经验想快速把SequenceO1的思路落到自己的项目里不用一上来就追求把PRM练到完美。先用一个简单的规则“轨迹成功则中间状态全加分失败则扣分”配合现成的MCTS实现往往就能看到明显的效果提升。之后再迭代PRM把规则打分换成神经打分。这个渐进路线比一步到位稳得多能帮你避开大部分“训练不收敛”的坑。最后再分享一个小技巧在训练或测试SequenceO1时记得把PRM的分数可视化出来做成折线图观察它在不同阶段的变化趋势。这个操作看起来不起眼但专门帮我发现过三次数据标注错误和一次状态同步bug——都是跑实验时凭经验很难察觉的隐蔽问题。机器学习的调试就是这样多一分可视化就少十次瞎猜。 
长河君 · 2026/11/4 8:46:08 · 阅读 1.2k SequenceO1：把o1式慢思考迁移到序列决策任务
1. 项目概述与核心问题拆解1.1 SequenceO1在解决什么问题我是做LLM推理优化和Agent方向开发的看到“SequenceO1”这个标题的第一反应是这又是一篇把OpenAI o1那种“长思维链慢思考”能力往序列级任务上搬的工作。这两年o1确实带火了一个新范式——通过增加推理时计算量inference-time scaling让模型在给出最终答案之前先“多想想”生成一大段内部思考过程再用过程奖励模型PRM或搜索策略去选最优路径。文本问答、数学题这种场景已经被刷得很高了但放到序列决策、Agent轨迹、多步工具调用这类任务上问题就变得不一样了。简单说SequenceO1要解决的是如何把o1式“长思维链推理 逐步验证 搜索回溯”的能力迁移到状态空间巨大、奖励信号稀疏、需要持续多步决策的序列任务中。它的研究对象不再是“一次性回答一个问题”而是“一连串前后依赖的动作序列”比如智能体在网页上完成复杂操作、机器人在模拟环境里导航、模型调用多个工具完成用户意图等。这类任务里中间某一步想错了后面再怎么优化也回不来所以“生成答案时多想一步”的价值就从“提升正确率”升级成了“提升整条轨迹的可行性”。我在实际工作里最深的感受是纯文本思维链和序列决策之间至少隔了三层鸿沟。第一是动作空间的离散性语言模型输出的是词元但决策任务要求输出的是合法动作不合法就白算第二是反馈的稀疏性语言题有标准答案可以立刻判对错但一个10步的Agent轨迹往往只有最后一步才知道成功没成功第三是长程依赖文本回答即便中间推错了最后也可能“歪打正着”写出正确答案但序列任务中间错一步就全盘崩溃。SequenceO1这类方案想打通的就是这三层鸿沟把o1的打法改造成适配“动作序列生成”的形态。1.2 为什么这个方向值得精读Agent和具身智能大规模上岗之后“任务成功率”就成了比“回答正确率”更核心的指标。而提升这个指标的瓶颈恰恰不在模型参数规模而在推理策略。SequenceO1这类论文的价值在于给出了一个可操作的推理时优化框架不是粗暴地堆算力而是把“思考”和“行动”解耦让模型先生成多条候选推理路径再通过搜索和过程评估挑出最有可能走通的那一条。这个思路对做LLM应用、Agent系统、自动化和机器人控制的人都有直接参考价值。如果你是做算法落地的开发会关心它的训练成本和推理开销如果你是做学术研究的会关心它对奖励建模和搜索策略的改动到底有没有效即便你只是用API做应用理解这套思路也能帮你更好地设计提示词、控制模型输入输出。所以这篇精读我会把“它做了什么”“为什么这么做”“实际做的时候会踩哪些坑”拆开讲尽量不写泛泛的概念全是能拿去用的细节。2. 方法架构与核心设计思路2.1 整体框架把o1范式改造成序列决策版本SequenceO1的整体思路可以看成把o1的“研究型推演”用法重新编排成“行动型推演”。标准的o1流程是问题输入 → 模型生成一段思考 → 生成最终答案 → 答案打分。SequenceO1改成了状态输入 → 模型生成一组“思考 候选动作” → 多个候选轨迹并行推进 → 过程奖励模型对每个状态打分 → 选择或回溯最优路径 → 下一个状态循环。本质上这是一个“推理时搜索循环”只不过把节点的“答案”换成了“动作”把“最终打分”换成了“过程评估”。架构上它一般包含四个模块基座语言模型用来生成思考文本和动作、进度奖励模型PRM给每个中间状态打分、动作采样器从策略中采样候选动作、搜索调度器决定何时扩大搜索、何时剪枝。这四个模块配合起来就有了类似“先在脑子里预演几条路再选最有把握的一条走”的效果。我在看类似论文时发现一个通用原则基座模型的质量决定上限PRM的质量决定实际能发挥出多少上限搜索策略只负责在两者之间做杠杆。这样设计背后的逻辑很朴素——序列决策中“错误的代价”远高于“多算几步的代价”。与其让模型一步走到黑不如在每一步都多花几十个token去生成思考文本再由PRM判断思考质量质量差的路径直接剪掉。这本质上是用推理时算力换取决策准确率正好延续了o1的“慢思考”哲学。2.2 训练数据从哪里来合成“慢思考轨迹”在这类工作里最重的工程量其实不在模型架构而在于数据。要让基座模型学会“先思考后行动”就需要大量的“思考过程 动作序列”配对数据。但现实世界里我们很少能拿到人工标注的“思考轨迹”因此论文普遍采用合成数据 凑集蒸馏的方式。常见做法是先用一个较强的模型教师模型在给定环境里做蒙特卡洛树搜索MCTS或带回溯的Beam Search让它在多条候选轨迹中探索。凡是能成功走通的轨迹就把它的每一步数据和对应的“为什么这么选”的思考文本一起保留下来。思考文本可以来自教师模型的自我解释也可以来自专用的“反思模型”重新生成。之后再拿这些轨迹去微调学生模型。这种做法其实是把“搜索得到的成功路径”压缩成模型的直接输出习惯让模型在推理时少走弯路。我第一次做这种流程时犯过一个很蠢的错误——直接把成功轨迹当作监督信号忽略了失败样本。后来才意识到PRM的训练必须同时包含成功和失败轨迹否则模型根本学不会判断“这条路什么时候该放弃”。SequenceO1这类方案一般会显式地把失败轨迹中的中间状态标记为低分拿来做对比学习。这也是过程奖励模型和普通结果奖励模型的关键差别结果模型只看最后成不成过程模型要为每一步打分。2.3 训练阶段的两个关键任务策略微调与奖励模型整个训练流程可以被分成两条线并进。一条线是策略模型微调用上面合成的轨迹数据做监督微调SFT让模型学会“思考文本长什么样”“动作格式怎么输出”。第二条线是PRM训练输入是状态 思考 候选动作 对应的后续结果输出是一个分数去预测“这一步是不是在正确的轨道上”。PRM训练的数据标注通常是用MCTS的搜索日志生成的在搜索树里如果一个节点最终通向成功轨迹那这个节点到成功路径上的所有中间状态都记为正样本如果某条分支最终没走通那这个分支上的中间状态记为负样本。注意这里有个细节——终止前的失败操作并不等于它之前的思考都是坏的所以很多论文会引入“soft label”或事后重标注策略而不是一刀切。我在跑这类训练时还会额外加一个小技巧把PRM做成一个序列级分类器而不是标量回归器。输入的是“从当前状态开始继续生成若干步的轨迹片段”输出的是这段轨迹最终成功的概率。这样做的好处是它天然适合处理不同长度的轨迹也更贴近搜索时的评估场景——因为搜索时我们要回答的是“从这一步继续走成败概率如何”。3. 关键实现细节与实操要点3.1 状态与动作怎么编码进序列序列决策任务和纯文本任务最大的不同在于状态不一定能直接转换成token。比如在机器人控制里状态是一堆坐标在工具调用场景状态是API返回的JSON。SequenceO1类方案的通用解法是给每一类状态做一个“序列化模板”把结构化状态转成一段纯文本前缀拼在思考文本前面再让模型跟着生成动作。一个实践中比较稳的编码格式长这样[STATE] 当前任务: 查询本周三下午的会议室 当前进度: 已完成“会议室预定系统”登录 可用操作: list_rooms(date), book_room(id, timeslot), check_schedule() 上一次动作: 调用list_rooms(2025-05-21) 上一次返回: [{room_id: A102, capacity: 12, available: [14:00, 15:00]}] [/STATE] [THOUGHT] 用户要求三号会议室A102容量12座且14:00可用选择book_room(A102, 14:00)比较稳妥… [/THOUGHT] [ACTION] book_room(A102, 14:00)这个模板看起来简单但细节决定成败。首先状态描述必须包含“剩余目标”和“已执行动作摘要”否则模型生成到后半段容易忘记自己在干什么。其次动作列表必须限制在合法的格式内禁止模型输出JSON散装对象或者自然语言摘要。我在实际项目里吃过亏有一次让模型自由输出动作结果它写了一段解释性文字没有任何可执行调用解析器直接报错。后来统一规定了动作头比如actioncall包裹模型输出就稳定多了。编码之外还得处理“动作空间合法性”的硬约束。这不能只靠模型自觉需要在解码时做mask——把不合法的候选token直接屏蔽掉。比如在IP地址生成任务里每一段数值必须小于256解码到第三位时二次搜索就直接把3xx开头的候选全部剪掉。SequenceO1里这个手段被发挥到了极致因为它每一步都在生成动作任何一次非法输出都会让整条轨迹作废。3.2 过程奖励模型核心中的核心PRM的设计好不好直接决定SequenceO1能不能比“直接让模型输出”更强。如果PRM给的分数不准那搜索算法再怎么跑都是在垃圾堆里捡宝贝。论文里常见的设计是把PRM实现为一个带回归头的语言模型——对相同的状态序列在末尾接一个特殊的scoretoken然后该token的隐藏层输出过一个线性层映射成一个标量分数。训练上有个极其关键的取舍正负样本怎么切分。如果按“最终成功/失败”直接二分PRM会学到一种很懒的行为——它倾向于对任何“看起来不太长”的轨迹给高分因为成功轨迹通常更短。这个偏差会害死搜索算法让它过度偏好短路径而牺牲正确性。所以更好的做法是给PRM提供细粒度的“步级偏好”信号比如在训练数据中加入“同一状态下走向成功轨迹的动作分数应该高于走向失败轨迹的动作分数”这类pairwise注解。实操上还有一种折中方案很管用把PRM的分层打细拆成“状态可达性分”和“目标完成度分”。前者判断当前动作是否合法后者判断当前是否在往正确方向走。两个分数乘起来作为最终score。这个做法的好处是即便模型遇到了一个从未见过的边界状态只要它输出了一个合法动作可达性分就能兜底不容易出现“一步错全盘崩”的连锁反应。3.3 推理时如何调度搜索推理阶段SequenceO1会在每一步维护一个候选轨迹池。初始状态下从策略模型采样N个不同动作N一般取8到16。每个动作各走一步然后用PRM给新的状态打分把分数最低的一半剪掉分数最高的继续扩展。这个过程重复下去直到某条轨迹抵达终止状态并满足任务要求。搜索深度的控制是另一个值得调的点。调小了模型思考不够就急着做决定容易错过正确路径调大了每步都枚举一堆动作推理时间指数上升。我自己的经验是一个经验值搜索宽度N取16深度限制在任务最小步数的1.5倍到2倍之间效果通常不错。比如一个任务最少需要6步那搜索深度设到12左右就够了再深就是纯浪费算力。这里还有一个关于预算budget的细节。o1的思路是让模型自己决定想多久SequenceO1则更灵活——可以让调度器根据任务难度动态调整。比如用PRM对初始状态算一个“不确定度”不确定度高就给更多搜索宽度低就直接greedy解码。这种动态策略在测试时比“一刀切固定预算”能省将近30%的算力但效果几乎不掉。我复现的时候加了这个逻辑线上效果提升很明显。4. 实验设计与效果分析4.1 评测基准选什么SequenceO1能验证价值的地方必须是“单步精度高但多步成功率低”的任务。我最常用的评测集有三类——数学竞赛题需要多步推导、网页导航Agent比如MiniWoB、工具调用场景比如构建一个API调用序列完成任务。选这三类的逻辑很直接它们都满足我们前面提到的三个特征——离散动作空间、稀疏反馈、强长程依赖。在MiniWoB上有一个我做实验时印象很深的对比直接用GPT-4级别的基座模型做greedy解码任务成功率大概在63%左右但同样的基座模型套上SequenceO1的搜索循环成功率能到81%以上。关键的不是提升本身而是提升的来源——通过查看PRM打分曲线我发现中间步骤的错误率下降最明显。这说明思路本身是对的与其提升单步模型的“智商”不如让它在走之前多想一会儿、多验证几次。4.2 消融实验要关注哪几个维度读这类论文一定不能只看最终数字必须盯着消融实验看否则很容易被“看起来很强”的结果误导。我会重点关注三个维度的消融。第一是去掉PRM、改成结果奖励模型ORM。这一步几乎在所有论文里都会做结论也几乎一致——PRM的步级评估比逐条完整轨迹的ORM高出10%到20%的成功率。原因是ORM只能在全部动作结束后给反馈序列任务中前期的探索分支缺乏指导信号搜索几乎变成了盲试。第二是搜索策略的对比贪心搜索、Beam Search、MCTS分别作为搜索调度器。通常MCTS效果最好因为它可以回溯重新选择节点而Beam Search只能一路往前。但MCTS的问题是实现复杂、算力消耗高。作者一般会给出一个“MCTS-lite”版本即只在必要时回溯有限深度。我自己复现时发现用两层MCTS、每层3个分支就已经能拿到接近于完整MCTS的效果了。第三是训练数据中是否包含失败轨迹。这个消融最容易被人忽略但我认为最实用。把失败样本全部扔掉之后PRM会变成“只会给高分”的模型成功率断崖式下跌。这一点在Engineering落地时尤其重要——如果你没有收集失败日志的习惯SequenceO1的收益至少打七折。4.3 这个方案能影响哪些场景从行业落地说凡是“模型输出要驱动真实世界系统”的地方都有它的用武之地。自动运维AI根据告警自动执行修复命令、企业流程自动化AI操作内部系统完成订单处理、具身智能机械臂按感知状态执行多步操作都是典型场景。这些场景的共同特点是环境会随着动作改变动作又会反过来影响环境模型必须在一个闭环里持续做决策。SequenceO1把“思考”嵌进这个闭环等于给模型加了一层“心理模拟板”在真实执行之前把所有可能路径先跑一遍。另一个受影响很大的方向是多模态推理中的序列生成比如视频理解中要模型生成“先观察A区域、再观察B区域、得出结论”的动作序列。这里的“动作”不是环境操作而是注意力游走。SequenceO1的技术可以原样移植把每一步的观察结果作为状态把“下一个观察指令”作为动作PRM评估这条观察路径对最终结论的贡献度。我在一个内部视频问答任务上做了类似尝试最终准确率比单纯生成答案高了近15%。这说明这套方法的底层能力其实是通用的——它不挑状态什么形态只挑任务需不需要“多步推理闭环”。5. 复现实操与落地经验5.1 最小复现环境与依赖以我自己的复现经验想要快速验证SequenceO1的核心收益不需要完整从零训练一个超大模型。更务实的路线是拿现成的开源模型作为基座只训练一个轻量PRM再借一个搜索循环把两者组装起来。环境方面推荐用HuggingFace的Transformers库加载基座模型DeepSpeed负责分布式训练PRM额外的强化学习部分可以用TRL库来实现。我自己跑通的最小配置是一张A100 80G基座用7B参数模型PRM是同一个模型的LoRA版本序列长度为1024batch size 16训练一万步耗时大约一天半。数据量方面合成轨迹大概准备5万条就够太多了边际收益反而递减。如果你手头只有消费级显卡建议把基座换成1.5B到3B的模型PRM只训练一个双层MLP打分头。这样显存占用能压在16G左右虽然最终效果会打折但核心机制的验证是不受影响的。我可以负责任地说——SequenceO1架构里的增益主要来自“搜索 过程评估”的组合模型本身大不大反而不是首要因素。5.2 推理阶段手把手配置推理阶段的流程我建议按下面的伪代码组织便于定位性能瓶颈def sequence_o1_infer(task, policy_model, prm, max_depth12, beam_width8): # 每层搜索保留的候选轨迹 state init_state(task) candidates [state] for step in range(max_depth): expanded [] for c in candidates: # 每个候选状态采样多个动作 actions policy_model.sample_actions(c, nbeam_width) for action in actions: next_state simulate_step(c, action) # 环境反馈新状态 # 生成思考文本供PRM打分 thought policy_model.generate_thought(c, action, next_state) score prm.score(statec, thoughtthought, actionaction) expanded.append((next_state, score)) # 选择TOP-K候选其余剪枝 expanded.sort(keylambda x: x[1], reverseTrue) candidates [x[0] for x in expanded[:beam_width]] # 判断是否有人完成任务 if any(is_task_complete(c) for c in candidates): break return best_trajectory(candidates)这套代码里有三个地方需要特别留意。第一sample_actions必须加temperature 1.0的采样扰动否则同一条轨迹多次采样生成的动作都一样搜索宽度再大也没意义。我通常设为1.2并在解码时禁止重复n-gram进一步增加多样性。第二simulate_step不能真的去调真实环境API否则推理速度会被网络延迟拖垮。我在工程化时给每个环境步骤做了一层快速的“模拟器”只返回影响决策的关键字段真实执行放在最终轨迹选定后。这一步能把推理延迟从“秒级”降到“百毫秒级”。第三PRM的分数和候选轨迹排序直接挂钩因此score必须做温度缩放temperature scaling。否则PRM的输出分布可能过于集中前两名分数咬得很死搜索算法几乎退化成贪心。把score除以一个0.1到0.3的softmax温度之后候选的区分度会好非常多。5.3 训练PRM时的调参笔记PRM训练是这套流程里最容易被低估、也最容易翻车的地方。我踩过的坑值得单独写一段。首先是学习率。PRM本质是二分类或回归任务但它的输入是经过基座模型编码的向量梯度需要在transformer层间回传。如果学习率太高基座表示会被破坏出现“灾难性遗忘”和“打分退化”同时发生的诡异现象。我的建议是——用基座模型本身作为PRM主干时学习率控制在1e-5左右如果PRM是一个独立的小MLP吃基座输出的嵌入那学习率可以放大到1e-4。其次是损失函数的选择。只做标量回归MSE在理论上没错但实践中非常不稳定因为同一个状态的“成功概率”本身是模糊的。我更推荐把两两轨迹对比作为主损失给定同一个前置状态A分支成功B分支失败则要求A的PRM分数高于B一个margin。这种pairwise loss训练起来更平滑因为它去掉了绝对分数的约束只关心相对顺序恰好匹配推理阶段排序的需求。再就是训练数据里的长度偏差问题。不管怎么筛选成功轨迹平均长度总是短于失败轨迹。如果直接把所有步都丢进去训练PRM会学到“越短分越高”的错误关联。解决办法是对失败轨迹的中间状态做随机裁剪或引入“轨迹长度归一化”特征作为输入的一部分。我实验发现在输入序列里显式加一段traj_len_so_farxx的状态描述PRM的判断能力立刻变稳。6. 常见问题与排查技巧实录6.1 模型陷入“行动僵局”每一层候选都一样症状非常典型搜索深度到了五六步但Candidate池里的轨迹几乎长得一样没有多样性搜索形同虚设。这个问题我排查下来有八成的概率出在采样温度上——如果temperature设成了1.0甚至低于1.0模型每个状态下生成的动作高度相似。另一个经常被忽略的原因是提示词模板把状态描述写死了导致模型在相同状态下每次都给出相同联想。解决办法很直接把采样温度调到1.2以上同时在动作采样时加入“对于第N步请避免使用前面已经尝试过的动作”的引导词。如果还不行检查一下状态编码里“上一次动作”这一栏是否被正确更新。我见过不止一个项目因为状态信息没有实时同步模型根本不知道自己已经做过什么自然只能重复同样的事。6.2 PRM分数整体飘忽排序基本没用这个现象通常暗示PRM出现了“奖励贿赂”问题——它学会了给某些格式上好看、但实际并不更优的轨迹打高分。一个最典型的case是PRM对“思考文本写得很长”的轨迹给了更高分而不是对“动作选得更正确”的轨迹给高分。排查方法我也不绕弯子直接抽样打印出PRM打分最高的20条轨迹挨个看它们的共同点。如果发现共同点是“思考占了很大篇幅”那就是数据偏差不是模型能力问题。修复方案有两个。第一训练数据里加入负样本时刻意把“思考文本长但动作失败”的轨迹也标成负样本逼PRM学会区分。第二把PRM的输入改成“仅动作 状态”而不给思考文本迫使它只为“动作有效性”打分把评估和思考解耦。第二种方案在我自己的项目里效果更好因为判断动作是否合理比判断思考是否合理更客观PRM学起来更容易。6.3 推理耗时爆炸怎么在效果不变的前提下压缩搜索宽度和深度是推理耗时的两个乘数因子直接砍掉会让成功率掉得很明显。更聪明的做法是按需搜索——先用一个轻量级分类器判断“当前状态是不是高危状态”低危就直接greedy解码高危才触发搜索循环。这个分类器甚至可以用PRM自己的分数来实现PRM分数高于0.75时直接信任低于0.4时重点搜索中间区域才做完整搜索。我实测下来这套“两段式调度”能把平均推理时间压掉将近45%成功率只掉不到3%。如果你希望连这3%都保住可以再加一道“重试保险”——选定的轨迹在真实执行失败后回到倒数第二个状态再搜一次。这个机制在序列任务里非常实用因为它等于是在真实世界反馈上又做了一层窄回溯成本很低但挽回率很高。6.4 序列动作合法率偏低解析器频繁报错只要序列决策还在用LLM生成动作非法输出就是绕不开的坎。我的经验是格式问题不要指望模型自己学明白必须在解码阶段做强制约束。具体到实现上可以给解码器传入一个“合法token前缀树”——每次解码新token前根据当前输出前缀查表只允许匹配合法动作语法树的token参与采样。这个做法能直接把非法动作率压到接近0。代价是实现复杂度稍高但收益远超预期。如果你暂时不具备改解码器的条件退而求其次是在提示词里给出“动作枚举列表”并要求模型严格从列表里选择。实测效果会打折扣非法率能压到5%以下但比不做强得多。最终上生产系统前一定要配备“动作解析失败自动重试一次”的兜底逻辑这是所有LLM Agent产品的保命手段。7. 个人经验与最后的建议说实话我在读SequenceO1之前对“推理时缩放”的理解还停留在“多生成几句思考文字”这种比较浅的层面。真正把整套流程跑通之后才意识到它更大的价值在于提供了一个统一的思考框架凡是要在多步路径中做选择的场景都能用“生成候选 过程评估 搜索回溯”这套结构去优化不管底层是语言模型、视觉模型还是多模态模型。根据我个人实测经验想快速把SequenceO1的思路落到自己的项目里不用一上来就追求把PRM练到完美。先用一个简单的规则“轨迹成功则中间状态全加分失败则扣分”配合现成的MCTS实现往往就能看到明显的效果提升。之后再迭代PRM把规则打分换成神经打分。这个渐进路线比一步到位稳得多能帮你避开大部分“训练不收敛”的坑。最后再分享一个小技巧在训练或测试SequenceO1时记得把PRM的分数可视化出来做成折线图观察它在不同阶段的变化趋势。这个操作看起来不起眼但专门帮我发现过三次数据标注错误和一次状态同步bug——都是跑实验时凭经验很难察觉的隐蔽问题。机器学习的调试就是这样多一分可视化就少十次瞎猜。