第一次看到 “Position: LLMs Can’t Jump” 这个标题我以为是讲大模型推理速度的段子。读完观点论文的思路之后发现它其实是在用一个非常日常的动作描述当前 LLM 最核心的推理约束自回归生成从左到右逐 token 推进模型没有办法回头修改自己已经生成的内容也没有办法像人类解题那样先跳到某一步再回过头来补全中间过程。这篇文章在业界讨论度不低因为它把很多工程上已经感知到、但一直没被说透的问题总结成了观点RAG 检索不到东西时模型不会自动回溯Agent 工具调用链一旦前面错了后面全错做结构化输出时要靠外部校验循环反复纠正。说白了LLM 可以“走得很远”但很难“跳起来”。这篇博文会围绕这个观点展开先讲清楚 LLM 为什么“跳不了”再讲这个问题在 RAG、Agent、结构化输出场景里的真实影响然后给出一套本地可复现的最小验证方案最后结合 API 调用、批量任务、显存与 KV Cache 开销聊聊工程上应该怎么绕过这个限制。如果你正在做 LLM Agent、RAG 应用或者经常要调本地模型的接口做批量推理这篇文章可以收藏备用。1. 核心观点速览先给一张速览表把这篇 position 论文和它的工程意义放在一起看。维度说明项目类型学术观点论文非开源工具核心论断LLM 受自回归逐 token 生成机制限制无法进行“跳跃式”推理或事后修正主要影响面RAG 检索、Agent 工具调用、结构化输出、长文本一致性、复杂推理任务与工程的关系解释了为什么外部校验、重试、树搜索、多候选采样等手段是必要的适合读者LLM 应用开发、RAG 系统设计、Agent 编排、推理性能优化相关工程师硬件门槛不需要特殊硬件任何能跑 LLM 推理的环境都可观察该现象显存占用不固定取决于模型规模、序列长度和 KV Cache 策略启动方式非工具类项目无独立启动方式可结合 Ollama、vLLM 等推理框架做验证实验是否支持 API不直接提供本地推理框架通常暴露 OpenAI 兼容 API是否支持批量任务不直接提供工程侧可自行设计批量调用与校验重试写作重点不在论文本身而在论文观点对实际开发的影响。下面会尽量从工程视角展开不堆砌理论。2. 为什么说 LLM 不能“跳跃”要理解“LLMs Can’t Jump”先要看清楚自回归解码的工作方式。2.1 从左到右的单向生成目前主流 LLM 在推理时基本都是自回归模型。每生成一个新 token模型都会把之前生成的所有 token 作为上下文计算下一个 token 的概率分布然后从中采样或取最高概率值。这个过程天然是单向的第 1 个 token 只依赖 prompt。第 5 个 token 依赖前 4 个 token 和第 3 个 token 的错误影响。一旦生成到第 20 个 token前 19 个 token 已经固定模型无法修改第 3 个位置上的错误。人类做复杂任务时不是这样。草稿纸上先写一个错误结论发现问题后可以划掉重写解数学题时可以先跳到最后一步猜出结果再回头推中间条件。LLM 没有这种能力。2.2 KV Cache 让“回头修改”代价更高这里要提一个关键概念KV Cache。在自回归生成过程中模型每处理一个新 token都需要重新计算它与之前所有 token 的注意力关系。为了避免重复计算推理框架会把已生成 token 的 Key 和 Value 缓存下来这就是 KV Cache。KV Cache 的一个直接结果是模型生成的 token 越多显存占用就越高但模型的推理状态也越“固化”。如果生成过程中某一步出现错误想回到第 10 个 token 重新生成通常意味着要丢弃之后所有的 KV Cache 重新计算这个代价在长序列场景下非常高。所以模型不仅“跳不了”连“回头重走”都不便宜。2.3 位置论文想表达什么这篇 position 论文的核心观点可以概括为LLM 的推理过程是“线性推进 概率累积”每一步决策都依赖于之前的输出。如果前几步走偏后续无论生成多长都会在错误的方向上继续扩展。模型的宽度再大、参数再多也不能绕过“逐 token 生成”这个机制。因此我们不能期待模型自己在生成过程中突然跳出去修正错误而是要把修正能力放到模型外部。这个外部修正能力恰恰是现在 RAG、Agent 和结构化输出工程里的核心问题。3. 这个限制在真实工程里会造成什么问题“不能跳跃”不是纯理论问题它在实际应用里会以非常具体的形式出现。3.1 RAG 检索失败时模型不会自动换路RAG 的典型流程是先检索再把检索结果拼进 prompt最后让 LLM 生成答案。问题在于如果第一次检索结果不相关LLM 并不会主动判断“这段内容有问题我要重新检索”。它会基于错误上下文生成一个看似流畅的答案而且由于自回归生成会累积概率这条错误路线会越走越自信。工程上的解法通常是把“检索结果是否相关”的判断拆成单独一步用校验逻辑或评分模型来判断一旦发现检索质量差再触发新一轮检索。这就是把“跳跃”从模型内部转移到系统流程中。3.2 Agent 工具调用链错误传播Agent 场景更明显。一个复杂的 Agent 任务可能包含多轮工具调用查数据库、调 API、执行代码、观察结果、再决定下一步。每一步输出都会作为下一轮的上下文。如果第 2 步工具参数写错了模型不会在第 5 步突然意识到“第 2 步的参数有问题我回去重写”。它只会在错误的返回结果上继续推理最终给出一个错误结论。这与“不能跳跃”直接相关。所以现在主流的 Agent 框架都在做状态管理、工具返回校验、人工兜底和最大重试次数限制而不是依赖模型自我纠错。3.3 结构化输出需要外部校验循环写 JSON、写代码、写 SQL是 LLM 工程里最容易暴露“不能跳跃”的场景。模型生成 JSON 时是逐 token 生成的它不会先整体预览一遍再输出。如果某个字段少了一个引号或者类型写错了后续 token 仍然会继续生成。代码场景里也是这样模型可能在第 100 行之前都在写一个错误变量名但它不会回头把前面所有用到该变量的地方统一改掉。所以工程上必须加一个外部校验器先让模型输出。解析结果。如果解析失败把错误信息反馈给模型要求重新输出。最多重试 N 次。这本质上是把“跳跃修正”从模型内部搬到了系统层。4. 业界如何绕过“不能跳跃”既然模型自己跳不了那工程上就要替它“跳”。整体上有三条路线4.1 算法层用多步推理模拟跳跃思维链已经是标准做法。更进一步的方案包括ReAct让模型交替思考和行动在每一步都观察外部结果。Self-Refine生成完初稿后让模型自己扮演评审者发现错误并修改。Tree of Thoughts在关键步骤维护多个候选分支通过评估和回溯选择更优路径。这些方法都没有改变自回归机制但通过“多次生成 外部选择”模拟了跳跃试错的过程。4.2 架构层改变解码方式架构层的探索方向包括草稿模型、投机采样、并行解码、非自回归生成等。投机采样是当前比较实用的方案。它用一个小的草稿模型快速生成多个候选 token再用大模型并行验证。验证过程仍然是从左到右但因为大模型一次可以验证多个 token整体吞吐会明显提升。这里要区分一下投机采样提升的是“生成速度”不是“回溯能力”。模型仍然不能回头改但每秒钟能生成的 token 数更多了。4.3 系统层校验器 重试 工作流编排对大部分开发者和 RAG/Agent 应用来说最值得投入的反而是系统层。用 JSON Schema 校验结构化输出。用代码编译器校验生成代码。用子任务结果评分判断 Agent 下一步方向。用有限重试次数避免无限循环。这套“生成 → 校验 → 失败反馈 → 重试”的循环本质上就是给 LLM 外挂一个“跳跃控制器”。模型不会跳但你的系统可以帮它跳。5. 本地部署最小验证实验为了验证“LLMs Can’t Jump”这个观点不需要昂贵的显卡也不需要复杂的框架。完全可以在一台普通开发机上用本地推理框架跑一个小实验。5.1 环境准备先确认本机环境操作系统Windows / Linux / macOS 都可以Linux 对显存管理更方便。Python 版本建议 3.10 或以上。推理框架Ollama 或 vLLM二选一。如果只是验证现象Ollama 更省事如果要压测接口和吞吐vLLM 更合适。模型建议选 7B 左右的模型例如 Qwen2.5 7B Instruct。显存不足时选择量化版本。环境准备命令以 Ollama 为例# 安装 Ollama 后启动服务 ollama serve # 拉取模型模型名称按实际可用版本调整 ollama pull qwen2.5:7b如果你的机器上没有 Ollama也可以用 vLLM 启动一个 OpenAI 兼容的推理服务python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --host 127.0.0.1 \ --port 8000 \ --dtype bfloat16 \ --max-model-len 8192注意vLLM 的启动命令在不同版本里有所差异模型路径、端口、dtype 都应按实际环境调整。5.2 实验一逐步推理与直接给结论的对比这个实验的目的是观察模型在“必须逐步推理”和“被要求直接给结论”两种情况下的差异。from openai import OpenAI client OpenAI( base_urlhttp://127.0.0.1:11434/v1, # Ollama 默认兼容地址 api_keyollama ) prompt 一个盒子里有 5 个红球和 3 个蓝球连续不放回抽两次两次都抽到红球的概率是多少 # 方式 A要求直接给出结论 resp_a client.chat.completions.create( modelqwen2.5:7b, messages[ {role: system, content: 你是数学助手直接给出结论不要写过程。}, {role: user, content: prompt} ], temperature0.2, max_tokens512 ) # 方式 B要求先逐步推理 resp_b client.chat.completions.create( modelqwen2.5:7b, messages[ {role: system, content: 你是数学助手请一步步推理后再给结论。}, {role: user, content: prompt} ], temperature0.2, max_tokens1024 ) print(A 直接结论:) print(resp_a.choices[0].message.content) print(\nB 逐步推理:) print(resp_b.choices[0].message.content)预期结果是方式 B 在复杂逻辑题上的正确率明显高于方式 A。方式 A 经常出现“跳跃式错误”比如漏掉“不放回”这个条件直接按独立事件计算。这个实验不一定每次都失败但重复测多组题目后基本能稳定观察到“越要求直接给结论越容易跳步出错”的现象。5.3 实验二让模型察觉自己的错误再做一个更贴近 Agent 场景的实验先让模型给一个错误答案然后直接问它“你确定吗再检查一遍”。resp client.chat.completions.create( modelqwen2.5:7b, messages[ {role: user, content: 3.11 和 3.9 哪个更大}, {role: assistant, content: 3.9 更大。}, {role: user, content: 你确定吗再仔细比较一下小数部分。} ], temperature0.2, max_tokens256 ) print(resp.choices[0].message.content)这个实验对应的是 Agent 场景里的“外部反馈修正”。如果没有外部反馈模型在生成“3.9 更大”之后会继续沿着这个错误结论写下去只有外部把错误信息喂回去模型才有机会纠正。这正好说明跳不出来不是模型不聪明而是反馈没有进来。6. 接口 API 与批量任务视角既然要在工程里围绕 LLM 做系统API 调用和批量任务必然要处理“不能跳跃”带来的问题。6.1 统一走 OpenAI 兼容接口无论用 Ollama 还是 vLLM访问方式基本都是 OpenAI 兼容接口。这样方便在本地服务和云端模型之间切换。from openai import OpenAI client OpenAI( base_urlhttp://127.0.0.1:11434/v1, api_keyollama ) def call_llm(prompt: str, system: str , max_tokens: int 1024) - str: resp client.chat.completions.create( modelqwen2.5:7b, messages[ {role: system, content: system}, {role: user, content: prompt} ], temperature0.3, max_tokensmax_tokens ) return resp.choices[0].message.content注意不同推理框架对max_tokens、temperature等参数的支持程度略有差异实际调用时以服务端日志返回为准。6.2 结构化输出解析失败就加强反馈如果模型输出要进入下游系统第一件事就是做格式校验。import json def extract_json(text: str): start text.find({) end text.rfind(}) if start -1 or end -1: raise ValueError(未找到 JSON 内容) return json.loads(text[start:end 1]) prompt 请提取下面文本中的事件时间和地点并输出 JSON。 只输出 JSON 对象不要加任何解释。 文本今天下午三点项目组在 3 楼会议室讨论了新版本计划。 for attempt in range(3): raw call_llm(prompt, system你是信息抽取助手。) try: data extract_json(raw) print(解析成功:, data) break except Exception as e: print(f第 {attempt 1} 次解析失败: {e}) print(模型输出:, raw) prompt \n注意你刚才的输出不是合法 JSON请只输出一个 JSON 对象不要包含其他内容。这段代码的核心思路就是“外部校验 错误反馈 重试”。模型不会自动跳回去修正但循环条件会把错误信息重新喂给它。6.3 批量任务设计批量调用 LLM 时不能简单写一个 for 循环就完事。因为每一条结果都可能出现格式错误、内容不合格或超时必须设计重试和失败隔离机制。import time from concurrent.futures import ThreadPoolExecutor, as_completed tasks [ {id: 1, prompt: 任务一}, {id: 2, prompt: 任务二}, {id: 3, prompt: 任务三}, ] def process(task): for attempt in range(3): try: result call_llm(task[prompt], max_tokens512) validated extract_json(result) return {id: task[id], status: ok, data: validated} except Exception as e: time.sleep(1) return {id: task[id], status: failed, error: 最大重试次数已用完} with ThreadPoolExecutor(max_workers2) as executor: futures [executor.submit(process, t) for t in tasks] for future in as_completed(futures): print(future.result())这里有几个工程点max_workers不要一次性拉满否则显存不够时会触发 OOM。每条任务要有独立超时控制。失败任务要落到日志或结果文件中不能静默丢弃。如果同一个请求反复失败多半是 prompt 设计问题不要盲目调温度。7. 资源占用与性能观察做实验和批量任务时需要关注显存和性能指标。尤其是“不能跳跃”这个限制实际会让序列变长、KV Cache 变大推理成本随之上升。7.1 观察工具Linux 下最直接的命令nvidia-smi --query-gpumemory.used,utilization.gpu --formatcsv -l 1如果你用的是 Ollama也可以通过ollama ps查看当前加载的模型和显存占用。7.2 KV Cache 与序列长度的关系KV Cache 的大小会随模型层数、注意力头数和序列长度增长。关键结论是序列越长KV Cache 占用越大。批量推理时每条序列的 KV Cache 会叠加。输出 token 数量影响显存占用不能只看模型权重。这也解释了为什么“逐步推理”虽然能提升正确率但会让推理成本增加。模型是逐 token 生成的每一步思考都要占据上下文空间。7.3 精度与性能大模型的精度也直接影响显存和吞吐。常见选项有 fp16、bf16、fp8 和各类量化方案。fp16训练和推理中较常见的标准精度。bf16动态范围更大训练场景里很常用。fp8 / INT8 / INT4推理场景中为了降低显存占用而使用的压缩方案。选择精度时要在显存容量和输出质量之间做权衡。如果显存只够跑低精度版本那就不要期待模型在复杂推理任务上能保持全精度效果。7.4 如何降低资源占用如果显存不足优先尝试减少max_tokens限制模型输出长度。降低max_workers减少并行请求。使用更小或量化的模型。拆分长文本任务避免单条 prompt 过长。清理不用的推理服务避免多个服务同时占显存。8. 常见问题与排查方法围绕这篇文章涉及的验证实验、API 调用和批量任务下面是一些高频问题及排查思路。问题现象可能原因排查方式解决方案模型服务一直加载不出来模型未下载完成或服务端口被占用检查服务日志、端口占用情况重新拉取模型换端口启动接口请求超时模型太大、prompt 太长或并发过高查看 GPU 利用率、请求耗时日志减小 max_tokens降低并发数换更小模型输出 JSON 解析失败模型加了额外解释或格式不合法打印原始输出观察失败模式用更严格的 system 指令加校验重试循环批量任务中途卡住单条请求超过超时时间线程池线程阻塞检查日志中最近的请求记录设置请求超时任务级重试限制并发显存不足模型权重 KV Cache 超过显存上限查看 nvidia-smi、ollama ps降低序列长度、降低批量大小、换量化版本同一提示词多次结果不稳定温度设置偏高或采样策略波动固定随机种子或调整 temperature测试场景设为温度 0 或 0.2模型答案错得稳定prompt 引导不足或模型本身能力边界换不同 prompt 对比加入思维链提示拆分子任务人工校验Agent 工具调用参数总是错模型对工具说明理解不足反馈不及时查看工具返回值和上下文简化工具描述添加工具结果校验和纠错步骤遇到问题的时候先确认日志里模型的原始输出是什么。很多“模型能力差”的问题其实是 prompt 设计或外部校验逻辑没有接好。9. 最佳实践与合规边界“LLMs Can’t Jump” 这个观点提醒我们在设计 LLM 系统时必须把反馈和校验放在重要位置。下面是一些工程建议。9.1 从系统层面补偿模型限制不要期待模型自动发现自己说错了。复杂任务拆成多步每一步都做校验。为 Agent 工具调用设置最大重试次数防止死循环。结构化输出必须加 JSON Schema 或代码编译器校验。批量任务要记录输入、输出、重试次数、失败原因方便回溯。9.2 权限与安全边界如果 LLM 接入了 Agent 工具、数据库或外部 API权限控制需要非常收敛。不要让模型拥有过大的操作范围工具调用应遵循最小权限原则重要操作要人工确认。这与当前 Agent 安全讨论里的“过度授权”问题是同一个方向。合理的设计是模型只能调用白名单内的工具。工具只允许执行特定范围的参数。敏感操作必须二次确认。所有工具调用都要有日志留痕。9.3 版权、隐私与合规使用 LLM 处理文本、代码、图片或语音时必须确认素材来源合法。涉及个人信息的处理要遵守相关法规不能把未授权数据随意传入云端接口。批量任务如果使用了第三方 API还要注意调用频率和平台限制。对本地部署来说数据安全性更高但模型能力可能弱于云端。业务上线前要做效果复核尤其要检查生成内容里是否存在虚构、误导或侵权风险。10. 总结与下一步“Position: LLMs Can’t Jump” 用一个非常直观的比喻把 LLM 的核心工程约束讲清楚了自回归模型从左到右逐 token 生成无法跳跃到未来也无法回头修改过去。这个限制会造成 RAG 检索后不自动回溯、Agent 工具链错误累积、结构化输出需要反复校验等一系列问题。但这不意味着 LLM 不能用于复杂任务。正确的应对方式是把“跳跃”能力放到系统层用思维链和 ReAct 拆解步骤用校验和重试做反馈闭环用 Agent 状态管理和权限控制保证安全用批量任务的日志和超时机制保证稳定性。如果你想验证这篇文章的观点建议从第 5 章的实验开始做成本很低几分钟就能看到现象。进一步再尝试结构化输出校验和批量任务脚本感受会更明显。下一步可以继续研究的方向包括 ReAct 模式、树搜索推理、投机采样、vLLM 的并发参数调优以及 MCP 这类把工具能力标准化的协议。对做 Agent 和 RAG 工程的同学来说这个观点最重要的价值是一句话不要指望模型“自己突然想明白”而是把修正机制写进你的系统流程里。