当大模型面对一道需要 5 步推导的数学题时最让人头疼的不是它“不会”而是它“会一半就断”。前两步推理正确第三步开始自说自话最后给出一个看起来很确定、但经不起推敲的答案。很多人把这类问题归结为模型能力不足但从推理范式看真正缺少的是把“思考过程”显式建模成可以反复检查的递归链。“Chained Recursive Language Models for Multi-Iteration Reasoning”这个标题指向的正是这样一条技术路线让语言模型不再是“一次生成完整答案”而是通过递归调用自身在每一轮只推进一小步同时保留可评估的中间状态直到满足终止条件才停止。和常见的 Chain-of-Thought思维链相比它的核心变化是多了一个“递归自检回路”和 Self-Consistency 相比它不是在结果层面做投票而是在过程层面做迭代修正。这篇文章会从理念、机制、代码、评估四个角度拆解这一方向它解决什么问题和已有推理方法有什么区别一个最小可运行的实现长什么样以及在实际工程落地时要注意哪些坑。如果你正在做大模型推理增强、Agent 链路设计或者被“多步推理结果不稳定”折磨过这篇文章值得读完并收藏备用。1. 这篇文章真正要解决的问题先看一个典型场景。你让大模型做一道应用题要求它“请思考后给出答案”。模型确实生成了长长的推理过程但中间某一步算错了后续所有步骤全部建立在错误结果之上。更麻烦的是模型会在错误的推导上继续生成最终给一个自信的结论根本没有“回头检查”的机制。这就是多步推理中的错误累积问题。单轮生成的长链推理一旦在早期出现偏差后续很难自动纠正。即便你发现结果不对也只能重新生成一次可第二次可能又会错在另一个地方。再看另一个常见方案Self-Consistency即多次采样然后投票。它的思路是让模型独立生成多条推理路径最后选一个“多数答案”。这个方法能提升部分任务的稳定性但它依然没有利用“过程信息”来修正当前路径。每条路径都是独立的模型没有机会看到上一条路径错在哪也无法在已有步骤上继续思考。Chained Recursive Language Models链式递归语言模型解决的是同一个问题但思路不同把一次长生成拆成多次短生成每一步都基于“原问题 历史步骤”继续直到模型或外部校验器认为可以收尾。这样做有三个直接好处错误可以被尽早发现。每一轮只推进一小步状态是显式的可以单独检查。中间结果可复用。每一步都保存在历史里后续步骤能参考之前的结论。终止条件可编程。不再依赖模型一口气生成到最后一个 token而是由规则、自评、外部工具共同决定什么时候停止。这篇文章最适合三类读者正在研究大模型推理能力的算法工程师、想给 Agent 增加“自我反思”能力的应用开发人员以及准备把多步推理框架接入复杂任务的架构师。理解链式递归语言模型能帮你重新思考“推理框架”应该怎么设计而不是只知道提示词模板。2. 基础概念与核心原理2.1 什么是 Chained Recursive Language Models从字面拆开看Chained链式每一步的输出会成为下一步的输入形成一条推理链。Recursive递归每一次调用都以“问题 当前状态”为输入输出新的状态或最终答案这本质上是一个递归过程。Multi-Iteration Reasoning多迭代推理整个推理过程不止一次生成而是多轮迭代直到满足停止条件。更直白地说这不是一个新的模型架构而是一种“调用语言模型的方式”。同一个模型可以在循环里被反复调用每次只做一个小决策。决策可能是“继续推导下一步”也可能是“我已经有足够信息可以输出答案”。这种设计很像递归函数base case当某个条件满足时直接返回答案。recursive case否则调用模型得到新步骤把新步骤加入历史再进入下一轮。在传统的语言模型生成中我们通常用“生成多少个 token”来定义推理过程在链式递归模型中我们用“推理步数”来定义推理过程。每一步可以很短但必须是有意义的推进。2.2 和 Chain-of-Thought、Self-Consistency 的区别为了看清这个方向下表把几种常见推理方法放在一起对比。方法核心思路是否迭代是否修正中间过程对结果的处理Chain-of-Thought (CoT)先生成推理步骤再给出答案否否直接取模型最终输出Self-Consistency多次采样 CoT结果投票否否多个答案取多数Self-Refine先生成输出再让模型自我修正是部分修正后的输出ReAct推理逐步生成并可调用工具是部分终止条件由工具/模型决定Chained Recursive LM递归调用模型每步检查中间状态和终止条件是是满足条件后返回答案从这个对比能看出链式递归语言模型最独特的地方在于“递归结构 自检回路”。它不是一个孤立的技巧而是可以把 CoT 的步骤拆分、ReAct 的工具调用、自评和终止条件整合进同一个框架。2.3 递归与多迭代推理的关系你可能会有疑问既然是多迭代为什么不叫“循环推理”而叫“递归推理”工程上两者其实可以互相转化但概念上有细微差异。循环推理更强调“重复执行相同动作”每一次循环执行同样的步骤直到达到某个条件。递归推理则强调“每一步依赖于更小规模的子问题”模型在每一步都在重新处理“当前问题 历史上下文”并且需要定义明确的基条件base case。在真实的链式递归语言模型中递归主要体现在“状态传递”上状态 S_n 包含问题、历史步骤。模型 f 接收 S_n输出新步骤 a_{n1} 或终止标记。如果继续则状态更新为 S_{n1} S_n a_{n1}。直到 f 输出终止标记或者外部校验通过。在代码实现时为了防止 Python 递归深度过大经常会用显式循环来模拟递归。这是合理的工程折中但你在设计 Prompt 和状态结构时仍然要把“递归”的思维方式融进去每一步都必须知道“当前进行到哪了”“下一步该做什么”“什么时候可以停下”。3. 核心机制拆解从 Prompt 到自检回路3.1 四个关键组件一个可落地的链式递归语言模型通常包含四个组件状态表示State生成函数Generator评估函数Evaluator终止条件Termination状态表示解决的是“模型现在看到什么”。最简单的状态是“原问题 历史步骤列表”。复杂一点的状态还可以包含置信度、工具执行结果、子问题树等。生成函数解决的是“下一步要生成什么”。在每一轮模型要么生成一个新的推理步骤要么生成终止标记和最终答案。这一步非常依赖 Prompt 设计。评估函数解决的是“当前状态是否足够好”。评估可以用规则比如“历史中是否出现了答案表达式”也可以用另一个模型来评估还可以使用外部工具比如代码解释器。评估函数的作用是辅助终止判断而不仅仅是打分。终止条件解决的是“什么时候停下来”。推荐设置多层条件包括模型主动输出终止标记、评估函数返回通过、达到最大迭代次数等。缺少终止条件会带来最严重的工程问题无限调用模型产生大量 token 和费用。3.2 核心 Prompt 设计下面是一个可以复用的 Prompt 模板你是一个多步推理引擎。请根据问题和已有步骤执行一步操作 - 如果你能产生下一步推导只输出新步骤本身。 - 如果你认为已有信息已足够得到最终答案请先输出 END再换行输出最终答案。 问题{question} 已有步骤 {history} 下一步推导这个模板的关键点是明确要求“只输出新步骤”避免模型把一堆解释一起抛出来。提供终止标记END让模型有明确的“结束”路径。把历史步骤显式放在上下文中让模型能看到自己之前的所有推理。3.3 为什么需要外部自检回路只靠模型自己的“ ”并不足够可靠。模型可能在错误的步骤上自信地输出END所以外部评估器很重要。举个例子你要解决代数题模型输出了 “答案是: x 3”但题目需要求 x 2。这时代码解释器可以检查“x 3 是否满足原方程”。如果检查不通过推理不应该终止而应该继续修正。因此链式递归框架的设计中评估器可以有多种形式规则评估判断历史中是否出现特定格式。工具评估执行代码、查询数据库、调计算器。模型评估用一个不同的模型判断当前推理是否正确。人机协同评估在关键节点让人工确认。4. 环境准备与前置条件这一节聚焦于“把最小框架跑起来”所需的环境。假设你本机是 macOS 或 LinuxPython 版本建议 3.8 及以上实测 3.9、3.10、3.11 均可用。Windows 也可以运行只是 API key 的读取方式稍有不同。需要安装的依赖很简单pip install openai python-dotenv如果你计划调用本地模型也可以安装 transformerspip install transformers torch如果只是想先跑通递归框架连 OpenAI SDK 都不需要直接使用 Mock 模型即可。代码会提供一个模拟客户端让它返回固定步骤方便调试整个递归流程。需要注意OpenAI SDK 的调用方式在 v0.x 和 v1.x 之间变化较大。大部分新项目使用 v1.x本文代码以 v1.x 风格为例。如果你用的是旧版 SDK需要把client.chat.completions.create改成openai.ChatCompletion.create。5. 核心流程拆解在写完整代码之前先梳理一遍实现步骤。这样做的好处是后续看代码时你知道每一步在解决什么问题。5.1 定义推理状态推理状态是一个容器记录问题、历史步骤、当前轮数、最大迭代次数和最终答案。它解决了“模型在每一轮看到了什么”的问题。理想状态下这个对象应该不可变每次更新都产生新对象这样便于日志回放和调试。不过为了演示简单这里使用可变 dataclass。5.2 实现 Prompt 构建函数Prompt 构建函数把“问题”和“历史步骤”组装成模型输入。这一步要求格式稳定否则模型输出格式会漂移。5.3 实现模型客户端模型客户端的职责很单一输入 Prompt返回字符串。它可以是 OpenAI SDK 封装、本地模型封装、或者 Mock 客户端。这样主循环不需要关心底层模型是谁。5.4 实现递归主循环主循环是最核心的部分。它要做的事判断当前是否还有剩余迭代次数。如果剩余则构建 Prompt 并调用模型。解析模型输出如果以END开头认为推理结束否则把新步骤加入历史。每次追加历史后调用外部评估函数看是否满足终止条件。如果达到最大迭代次数仍未终止则强制停止并给出一个默认答案或提示失败。5.5 实现评估逻辑评估逻辑可以是简单的规则检查也可以是复杂的外部工具。为了演示我们先用一个极简规则如果历史步骤中出现“答案是:”就提取其后的内容作为最终答案。真实项目里你应该把这一块换成代码执行器或独立的验证模型。5.6 日志与可观测性多步推理最怕“黑盒”。建议在每个关键节点输出结构化日志比如当前轮数、模型输出、是否触发终止。这样一旦结果不对你可以回溯到具体某一步。6. 完整示例与代码实现下面给出一个最小可运行框架。先复制recursive_reasoner.py它包含状态定义、Prompt 构建、解析、评估和递归主循环。# 文件路径recursive_reasoner.py from __future__ import annotations import logging from dataclasses import dataclass, field from typing import List, Optional, Protocol, Tuple logger logging.getLogger(__name__) dataclass class ReasoningState: question: str history: List[str] field(default_factorylist) step_count: int 0 max_iterations: int 5 final_answer: Optional[str] None dataclass class StepResult: finished: bool step: str answer: Optional[str] None class ModelClient(Protocol): 任何实现了 generate_step 的对象都可以作为模型客户端。 def generate_step(self, prompt: str) - str: ... def build_prompt(question: str, history: List[str]) - str: history_text \n.join(f- {step} for step in history) if not history_text: history_text (尚无任何推理步骤) return f你是一个多步推理引擎。请根据问题和已有步骤执行一步操作 - 如果你能产生下一步推导只输出新步骤本身。 - 如果你认为已有信息已足够得到最终答案请先输出 END再换行输出最终答案。 问题{question} 已有步骤 {history_text} 下一步推导 def parse_model_output(output: str) - StepResult: output output.strip() if output.startswith(END): answer output[len(END):].strip() return StepResult(finishedTrue, answeranswer or 未提供答案) return StepResult(finishedFalse, stepoutput) def evaluate_state(question: str, history: List[str]) - Tuple[bool, Optional[str]]: 演示用规则如果某一步以“答案是:”开头则认为可以终止。 真实场景中可以把规则换成代码解释器、外部计算器或另一个评估模型。 for step in reversed(history): if step.startswith(答案是:): return True, step.split(:, 1)[1].strip() return False, None def recursive_reasoning(client: ModelClient, question: str, max_iterations: int 5) - ReasoningState: state ReasoningState(questionquestion, max_iterationsmax_iterations) while state.step_count state.max_iterations: prompt build_prompt(question, state.history) raw_output client.generate_step(prompt) logger.debug(step%d raw_output%s, state.step_count, raw_output) result parse_model_output(raw_output) if result.finished: state.final_answer result.answer logger.info(model emitted END at step %d, state.step_count) break state.history.append(result.step) state.step_count 1 # 外部规则验证 rule_finished, rule_answer evaluate_state(question, state.history) if rule_finished: state.final_answer rule_answer logger.info(rule finished at step %d, state.step_count) break else: # while 循环正常结束说明达到 max_iterations logger.warning(reach max_iterations without explicit END) if not state.final_answer and state.history: state.final_answer state.history[-1] return state这个文件里的ModelClient是一个 Protocol只要对象实现了generate_step(self, prompt: str) - str方法就能被主循环使用。这样做的好处是你在开发早期可以用 Mock 客户端跑通逻辑线上再切换到真实模型。接下来实现一个基于 OpenAI SDK 的客户端。注意不同版本的 SDK 调用方式不同下面的代码基于 OpenAI Python SDK 1.x。# 文件路径openai_client_example.py import os from openai import OpenAI from recursive_reasoner import ModelClient class OpenAIModelClient(ModelClient): def __init__(self, model: str gpt-4o-mini, temperature: float 0.2): self.model model self.temperature temperature self.client OpenAI(api_keyos.environ.get(OPENAI_API_KEY)) def generate_step(self, prompt: str) - str: response self.client.chat.completions.create( modelself.model, messages[{role: user, content: prompt}], temperatureself.temperature, ) return response.choices[0].message.content.strip()如果使用 OpenAI SDK 0.x对应实现大致是# 仅用于旧版本 SDK新版本可忽略 import os import openai openai.api_key os.environ.get(OPENAI_API_KEY) class LegacyOpenAIModelClient(ModelClient): def __init__(self, modelgpt-3.5-turbo, temperature0.2): self.model model self.temperature temperature def generate_step(self, prompt: str) - str: response openai.ChatCompletion.create( modelself.model, messages[{role: user, content: prompt}], temperatureself.temperature, ) return response.choices[0].message.content.strip()再写一个演示用的 Mock 客户端和一个入口脚本。Mock 客户端的作用是返回预先设计好的步骤让我们不调用任何真实模型就能测试递归主循环是否正确。# 文件路径demo.py from recursive_reasoner import ModelClient, recursive_reasoning class MockModelClient(ModelClient): def __init__(self, steps, final_answer): self._steps list(steps) self._final_answer final_answer self._index 0 def generate_step(self, prompt: str) - str: if self._index len(self._steps): output self._steps[self._index] self._index 1 return output return fEND\n{self._final_answer} if __name__ __main__: mock_client MockModelClient( steps[15 ÷ 3 5, 答案是: 5], final_answer5, ) state recursive_reasoning(mock_client, 计算 15 ÷ 3并给出最终答案) print(问题, state.question) print(历史步骤) for i, step in enumerate(state.history, 1): print(f {i}. {step}) print(最终答案, state.final_answer)在这个演示中模型第一次输出15 ÷ 3 5第二次输出答案是: 5。主循环在第二次追加历史后会通过evaluate_state检测到“答案是:”前缀从而提前终止并把5作为最终答案。代码会打印历史步骤和最终答案验证整个递归流程是否按预期运行。运行方式python demo.py如果你已经配置好OPENAI_API_KEY可以把demo.py中的MockModelClient换成OpenAIModelClient然后传入一个真实问题。7. 运行结果与效果验证7.1 预期输出如果demo.py运行成功你应该看到类似下面的输出问题 计算 15 ÷ 3并给出最终答案 历史步骤 1. 15 ÷ 3 5 2. 答案是: 5 最终答案 5这个输出说明主循环已经正确执行了两轮迭代并且通过规则评估结束了推理过程。7.2 如何判断框架运行正确判断一个链式递归框架是否工作正常可以从四个方面看是否出现无限循环。运行结束时step_count不应该大于max_iterations。历史步骤是否按预期累积。每一步都应当出现在state.history中。是否触发了终止条件。可能是模型输出END也可能是外部规则评估通过。最终答案是否可解析。答案应该是一个明确字符串而不是空值或原始推理步骤。7.3 真实模型评测的注意点把这个框架放到真实数据集上评测时建议记录以下指标最终准确率平均迭代轮数触发终止标记的比例达到最大迭代次数后仍未终止的比例每次调用的平均 token 消耗结果出错时是“第一步就错”还是“后几步偏离”这些指标能帮你判断模型到底是在“过程上修正”还是在“结果上碰运气”。8. 常见问题与排查思路在实际使用中最容易出问题的地方往往不是“模型能力”而是“框架设计”。下面的表格列出了一些高频问题。问题现象可能原因排查方式解决方案主循环无限运行没有设置最大迭代次数或模型从未输出终止标记检查max_iterations是否传入查看日志中出现多少次生成调用统一设置max_iterations兜底例如 5 或 10模型拒绝按格式输出Prompt 中历史步骤格式不清晰或输出太长被截断查看模型原始输出确认是否被解析函数截断在 Prompt 中强调“只输出新步骤”并限制每步输出长度达到最大迭代次数仍无答案模型一直在生成中间步骤但始终不收敛记录每轮历史看是否存在重复循环增加外部评估器提前发现重复步骤并强制停止token 消耗过高每步重复携带完整历史上下文越来越长观察调用日志统计 token 使用量压缩历史只保留关键步骤设置更小max_iterations外部规则误判判定规则过于简单例如“答案是:”格式不统一检查evaluate_state的规则是否覆盖模型输出格式后端增加正则解析或改为代码解释器验证API 调用失败网络波动、限流、key 失效查看异常堆栈确认是否在重试逻辑之内加入指数退避重试并设置请求超时评估模型与推理模型相同导致反馈偏置让同一个模型既推理又自评容易掩盖错误比较“同模型自评”和“外部工具验证”的差异关键场景使用外部工具或更强大的模型作为评估器9. 最佳实践与工程建议9.1 终止条件一定要有三层不要只依赖模型输出END也不要只依赖最大迭代数。我推荐三层终止设计模型主动终止。模型输出END标记表示它认为推理已经完成。外部验证通过。规则引擎、代码执行器或独立评估模型确认当前答案正确。最大迭代数兜底。无论如何都不能无限调用超过上限后强制停止。三层条件缺一不可。缺少第一层模型可能永远不会自己停下来缺少第二层模型可能过早自信地停下缺少第三层系统可能消耗大量 token 甚至崩溃。9.2 状态管理要显式历史记录要完整递归推理的本质是状态转换。每一轮的状态都应该能完整回放。建议至少记录当前轮数本轮输入 Prompt 的 hash 或完整内容模型原始输出解析后的步骤评估结果是否触发了终止条件这样当线上结果出错时你可以精确找到是哪一步开始偏离的而不是对着一个最终答案猜。9.3 用显式循环代替 Python 递归虽然这个方向叫“递归语言模型”但在 Python 工程实现中不要真的用递归函数来调用recursive_reasoning。原因很简单Python 默认递归深度约 1000而大模型推理通常只需要几轮但如果你在一个递归函数里又嵌套调用另一个递归函数很容易踩到递归深度限制。更好的做法是用while循环模拟递归同时在状态对象中保留“递归调用栈”的语义。本文的示例代码正是这样做既避免了递归深度问题也保留了递归结构的设计思路。9.4 安全边界不要直接执行模型生成的代码如果你在评估函数里引入代码解释器比如让模型写一段 Python 代码来验证数学答案必须注意不要直接eval()或exec()模型生成的不可信代码。正确做法是运行在沙箱环境中例如subprocess Docker或者使用专用的沙箱服务。本文示例中的evaluate_state只是一个规则演示不能直接用于生产。9.5 成本与延迟平衡链式递归推理最大的代价是“反复调用模型”。一次推理可能调用 5 到 10 次如果每次还携带完整历史token 消耗会显著上升。实际项目中可以这样优化设置单次生成的最大 token 数例如max_tokens200。历史步骤只保留最近几轮或先做摘要压缩。对于简单任务先用 CoT 一次生成失败后再进入递归修正模式。如果不需要特别强的推理选择更小、更便宜的模型作为“生成引擎”。9.6 评测不是只看最终准确率在对比“链式递归推理”和“单次 CoT”时只比较最终答案准确率会掩盖很多细节。更合理的做法是增加过程指标修正率某一步出错后后续迭代是否修正了错误。过早终止率模型在错误答案上输出了END的比例。无效迭代率某轮生成的步骤没有带来任何新信息只是重复已有内容。这些指标能帮助你判断问题到底出在生成器、评估器还是终止策略上。10. 总结与后续学习方向链式递归语言模型并不是要让模型“变得更聪明”而是给推理过程增加一个“可回退、可审计、可验证”的结构。它的核心价值在于把原本不可控的长时间生成拆分成若干次短生成并在每步增加自检和终止机制。从工程角度看这是完全可行的从研究角度看它把“提示词工程”上升到了“推理框架设计”的高度。如果你想继续深入可以关注这几个方向Reflexion通过语言记忆让模型记住前一轮失败并在下一轮修正。Tree of Thoughts把单一推理链扩展为树形探索。Self-Consistency与链式递归结合对多条链的中间结果进行投票。Tool-Enhanced Reasoning在评估器中引入计算器、搜索引擎或代码执行器。现代 Agent 框架中的 planner/executor 模式本质上也是链式决策。建议你先跑通本文的最小框架再用真实模型换掉 Mock最后找一个逻辑任务或数学任务做小规模评测。只有亲手看到“步骤被保存、错误被修正、停止条件被触发”你才能真正理解这个方向的潜力。