大语言模型在处理多跳问答或数学推理等复杂任务时，直接生成最终答案往往会导致逻辑跳跃和幻觉现象。为了缓解这一问题，研究人员引入了思维链技术，而分步推理策略则是将思维链进一步结构化的产物。通过显式地将复杂问题拆解为多个中间步骤，模型能够更稳健地逼近最终答案。目前业界广泛采用的两种分步推理范式为Least-to-Most与Plan-and-Solve，它们在拆解逻辑和执行流上存在显著差异。
Least-to-Most策略：由易到难的递进式拆解
Least-to-Most策略的核心思想是将复杂问题分解为一系列相对独立的子问题，并按照从简单到复杂的顺序依次求解。在第一阶段，模型需要识别当前问题所依赖的先决子问题，并生成一个子问题列表。在第二阶段，模型依次回答这些子问题，并将前一个子问题的答案作为上下文，辅助解答下一个更复杂的子问题，直到最终解决原始问题。这种策略模拟了人类解决复杂问题的认知过程，通过建立前置知识的依赖链，有效降低了模型在单次推理中的认知负荷。
在具体实现上，Least-to-Most通常需要设计两次独立的大模型调用。第一次调用负责问题分解，第二次调用则负责按序执行。以下是一个基于伪代码的实现框架，展示了如何通过提示工程引导模型完成这一过程。
def least_to_most_reasoning(llm, question):
# 第一阶段：问题分解
decompose_prompt = f"请将以下问题分解为一系列从简单到复杂的子问题：\n{question}"
sub_questions = llm.generate(decompose_prompt)
# 第二阶段：按序求解
context = ""
for sub_q in sub_questions:
# 将历史子问题和答案作为上下文传入
solve_prompt = f"已知信息：{context}\n请回答问题：{sub_q}"
answer = llm.generate(solve_prompt)
context += f"{sub_q} 答案是：{answer}\n"
return context
这种策略的优势在于其极强的可解释性和准确性。由于每一步推理都有明确的上下文支撑，模型很少会在中间步骤迷失方向。然而，它的缺点也十分明显：高度依赖第一阶段问题分解的质量。如果模型生成的子问题顺序错误或遗漏了关键依赖，后续的整个推理链路都会崩溃。此外，多次串行的模型调用会导致显著的延迟增加，不适合对响应时间要求极高的实时交互场景。
Plan-and-Solve策略：全局规划与按部就班执行
Plan-and-Solve策略是为了解决Zero-Shot CoT中常见的计算错误和步骤缺失问题而提出的。该策略的核心理念是先让模型制定一个全局的解题计划，然后再严格按照计划执行。与Least-to-Most不同的是，Plan-and-Solve不需要将问题拆分为不同层级的子问题，而是直接生成一个操作步骤列表，随后依次执行这些步骤。它通常通过特定的提示语触发，例如引导模型先输出计划，再输出执行过程。
在实际工程落地时，Plan-and-Solve可以通过一次或两次模型调用完成。如果采用单次调用，模型会在同一个输出中先生成计划，再生成执行结果；如果采用两次调用，则可以分离计划与执行，便于对计划进行人工校验。下面展示的是单次调用的提示词构建与解析逻辑。
def plan_and_solve_reasoning(llm, question):
# 触发Plan-and-Solve的提示词
ps_prompt = (
"请先制定一个解题计划，然后按照计划逐步执行。\n"
f"问题：{question}\n"
"请按以下格式输出：\n"
"计划：\n1. ...\n2. ...\n"
"执行：\n步骤1：...\n步骤2：...\n最终答案：..."
)
response = llm.generate(ps_prompt)
# 解析最终答案
final_answer = response.split("最终答案：")[-1].strip()
return final_answer
Plan-and-Solve策略的优点是实施成本较低，通常不需要复杂的外部调度逻辑，单次提示即可激发模型的规划能力。它在数学计算和逻辑推理任务中表现优异，因为明确的计划阶段能够有效减少模型在中间步骤的遗漏。但是，该策略的鲁棒性有时不如前者，因为一旦生成的全局计划存在逻辑缺陷，模型在执行阶段往往只会盲目遵循，缺乏自我纠错机制。同时，单次输出包含的信息量过大时，模型容易在长文本生成中出现注意力分散。
策略对比与实战场景选择
在评估这两种策略时，我们需要从推理深度、调用成本和容错率三个维度进行考量。Least-to-Most在处理具有强依赖关系的多跳问答时表现更好，因为它强制模型在回答后续问题前必须确认前置条件。而Plan-and-Solve在处理需要多步骤操作但步骤间相对独立任务时更具优势，例如编写一段复杂的数据处理脚本或解决多步骤的数学应用题。
为了更直观地展示两者的差异，我们可以参考下表进行对比分析。开发者在选型时，应首先评估业务场景对延迟的容忍度。如果是在离线数据分析或对准确率要求极高的医疗、法律知识问答系统中，推荐使用Least-to-Most策略，即使它会带来成倍的Token消耗。而在面向C端用户的实时聊天机器人中，Plan-and-Solve策略则是更好的平衡点。
| 对比维度 | Least-to-Most | Plan-and-Solve |
|---|---|---|
| 拆解逻辑 | 按依赖关系递进拆解 | 按操作步骤平铺拆解 |
| 上下文传递 | 前序答案作为后续输入 | 全局计划作为执行指导 |
| 调用延迟 | 高（多次串行调用） | 低（单次或双次调用） |
| 适用场景 | 多跳问答、强依赖逻辑 | 数学计算、流程执行 |
在实际的复杂工程中，这两种策略并非互斥关系。一种高级的工程实践是将两者融合：首先利用Plan-and-Solve的思想让模型生成一个粗略的全局计划，随后针对计划中每一个具有复杂依赖的子任务，再采用Least-to-Most策略进行递进式求解。这种混合模式能够在控制延迟的同时最大化推理的准确性，是当前构建高可靠推理Agent的常见路径。
推理模型Least-to-MostPlan-and-Solve修改时间：2026-08-25 05:12:48