这次我们来看一个在 LLM 应用圈子里讨论度很高的立场标题LLMs Cant Jump。直译过来就是“大语言模型不能跳跃”。这里的“跳跃”不是指能力不足而是指模型在做推理时很难像人类专家那样跳过大量中间步骤直接抵达正确答案。这个观点直接关系到 Prompt 怎么写、Agent 怎么搭、RAG 和编排框架为什么必须存在。文章的核心主张可以概括成一句话LLM 的单次前向推理深度受架构限制无法真正完成需要多步推演的“跳跃式思考”思维链、Agent、工具调用都是在用外部机制模拟这种深度。对做 LLM 应用开发的人来说这不是纯理论问题而是直接影响系统设计的工程问题。这篇文章会做四件事拆解这个观点的底层逻辑梳理它和思维链、Agent、RAG、MCP 的关系给一套自测“模型能不能跳”的提示词与代码方案最后落到资源占用、批量评测和常见坑位排查。适合正在做 LLM Agent、RAG 应用、工作流编排或者在选型时纠结“要不要上复杂框架”的读者。1. 观点核心信息速览先给一张速览表把最关键的信息放在前面。信息项说明观点定位一篇立场论文Position Paper核心观点是“LLM 不能跳跃”核心论断LLM 的深度推理能力受架构深度限制单次 token 生成无法完成真正深层推理关键概念前向传播深度、思维链、测试时计算、长期规划、Agent 外循环对工程的影响解释了为什么必须用 CoT、RAG、Agent、MCP、编排框架来补偿模型短板相关技术栈LLM Agent、思维链、RAG、MCP、LangChain / Spring AI 等编排框架硬件门槛讨论本身无硬件要求实际验证时取决于 API 服务或本地模型部署方式启动方式不适用本文是技术观点分析与验证方案接口 API提供通用 OpenAI 兼容接口对比测试示例批量任务提供批量提示词评测脚本思路适合读者LLM 应用开发者、Agent 系统设计者、模型选型评估工程师注意一点这篇文章不是某个软件项目的部署教程而是把一个正在被广泛讨论的模型能力观点讲透并给出工程可复用的验证思路。你不需要先装某个仓库但需要有一个可调用的 LLM 接口或者本地部署的模型推理服务。2. 适用场景与思考边界这个观点适合用来解释一类特别常见的现象同样的任务直接问模型会答错加上“请一步一步思考”之后正确率明显提升。为什么会这样因为这个结论从架构层面给出了解释模型在单次前向推理中的“思考步数”是有限的真正多步推演需要把推理过程显式展开。它适合回答以下问题为什么 LLM 不能一步到位处理复杂推理任务为什么强制模型输出思维链能提升正确率为什么单靠模型本身做长期规划会漏步骤为什么 Agent、RAG、MCP 这类外部机制是必要的在模型选型时如何判断一个大模型是否需要更强提示工程兜底它不适合做什么不适合作为模型训练或微调的操作手册不适合直接用来预测某个模型在具体业务上的表现。真实业务效果仍然要靠评测集验证。观点给的是“为什么会这样”的解释框架不是拿来做绝对结论的依据。使用边界上也要说清楚这不是对某个具体厂商模型的攻击而是对自回归语言模型这一类架构的能力边界讨论。实际模型中指令微调、强化学习、长思维链等训练手段已经在缓解这个问题缓解程度因模型而异所以更稳妥的态度是“默认模型跳不动然后通过评测确认它能不能跳”。3. “不能跳”是什么意思深度推理的架构限制理解这个观点核心要回到 Transformer 的推理过程本身。3.1 自回归生成与单次前向传播大语言模型生成文本时是逐 token 生成的。每生成一个 token模型把当前上下文输入 Transformer经过若干层前向传播输出下一个 token 的概率分布。这里的关键在于“若干层”这个数字是固定的。一个模型有多少层 Transformer 层单次前向传播的信息处理深度就有多大。举个例子一个 32 层的模型在生成某个 token 时信息最多只能在这 32 层里完成一次从输入到输出的整体变换。它不能在生成这个 token 的过程中额外进行 20 次内部的“自我思考”循环除非这种循环已经被写进架构里。这就是论文观点里说的“深度限制”。模型在单个 token 上的推理深度受模型层数约束做不到任意深度的反复推演。3.2 深度受限跳跃式推理难以内建人类专家在面对复杂问题时经常可以“跳”着思考。比如一位资深程序员看到一段报错可以直接锁定某个模块的问题不需要把整个代码库从头读一遍。这种“跳跃”建立在大量内部推演和经验抽象之上人可以在脑中完成多步假设验证再输出结论。LLM 很难在单个 token 生成周期里完成同样的事情。它要完成深度推理必须把中间步骤写到输出文本里这就是思维链。换句话说模型不是在内部完成了多步推演然后给你答案而是把你的推理过程变成了可见文本一步一步“走”过去。用一句直白的话总结模型能走的推理步数取决于层数内的前向计算能力要更多步数就得把步骤输出来用更多 token 换取更多计算。这也解释了为什么 LLM 在“需要多步推导但用户没有要求展开”的场景下容易翻车。模型没有足够的内部深度完成跳跃式推导于是只能靠下一个 token 的预测概率往前走一旦中间某步概率分布出了问题后面就偏了。4. 思维链是“模拟深度”不是真正深度思维链是当前缓解“不能跳”最直接的手段但它本质上是一种模拟深度。4.1 CoT 为什么有效思维链的思路很简单让模型把中间推理步骤显式写出来。这样每一步的输入输出都变成了可见文本模型在生成下一步时可以把上一步的结果作为上下文通过 attention 机制重新读取。这个过程实际上把“原本要在一个 token 内完成的深层推理”拆成了多个 token 接力完成。每一步所需的前向传播深度不需要很大但整体推理链条可以很长。工程上这种“用 token 数量换推理深度”的做法非常有效。4.2 CoT 的代价与局限CoT 的代价很直接输出变长延迟增加API 费用上升。一个需要 20 步推理的任务如果展开写生成 token 数量可能是直接回答的几倍。批量任务里这个开销会迅速放大。CoT 也有可靠性问题。模型写出的中间步骤不一定正确一旦中间某一步推理出错后面会沿着错误方向继续。更麻烦的是模型有时会生成看似合理的中间步骤但步骤之间逻辑并不严谨这是“模拟推理”的典型表现。4.3 长思维链与测试时计算为了进一步扩展推理深度业界开始研究长思维链和测试时计算。核心思路是在推理阶段投入更多计算量让模型有更多“思考”机会。这类方法在数学、编程等可验证任务上效果明显但同样面临“思考结果无法自我验证”的问题。从应用角度看这给我们一个重要启示不能把思维链当保险箱。凡是关键链路上的推理结果最好都有程序化验证步骤而不是相信模型“想清楚了”。5. 工程对策用 Agent、RAG、MCP 补足“跳跃”能力既然模型跳不动那工程上就不应该让它跳。当前主流做法是把模型放在一个更大的系统里用外部机制帮它完成多步推理。5.1 LLM Agent 的外循环LLM Agent 的基本模式是模型提出下一步计划 → 调用工具 → 观察结果 → 更新计划 → 继续下一步。这个循环相当于把推理过程外置了。没有 Agent 时模型一次生成完答案有 Agent 时模型每一步只做少量推理然后依靠工具结果修正方向。这正好规避了“单次前向传播深度不足”的问题因为每一步都不需要很深但整体可以走很远。工程实现上关键是给 Agent 设计清晰的目标拆解、工具返回校验和状态记录否则模型会在多轮循环中迷失方向。5.2 RAG 降低记忆跳跃负担“不能跳”还有一种表现模型试图凭参数记忆回答需要外部知识的问题。知识密集型任务里这种“记忆跳跃”经常会出错。RAG 的作用是把外部知识检索出来塞进上下文让模型基于检索结果做推理。模型不需要“跳”到训练时的记忆里去翻答案只需要在给定内容中做浅层推理。这也是为什么检索质量、重排序策略和上下文组织方式会直接影响 RAG 应用效果。模型本身推理深度有限如果检索结果里混入大量无关内容反而会拉低整体表现。5.3 MCP 与工具编排近几年 MCP 这类标准化工具协议受到关注本质上是把“工具调用能力”标准化。模型通过 MCP 客户端连接外部系统执行代码、查数据库、调接口把原本需要模型内部完成的步骤交给外部系统完成。集成 MCP 的价值在于扩展模型的行为空间。模型不需要在内部推演“这个函数运行结果是什么”而是直接调用工具获得确定结果。这从根本上绕开了“跳跃式推理”难题——推理被替换成了执行。5.4 编排框架的定位LangChain、Spring AI 等编排框架本质上是把 CoT 提示、工具调用、RAG 检索、结果验证这些环节串成可复用工作流。它们解决的不是“模型变得更聪明”而是“让模型在受限推理能力下依然可以完成复杂任务”。社区热词里出现类似“springaimcpragagent”、以及“LLM 应用为什么需要编排框架”的搜索说明这个思路已经成为主流。还有人会关心 ComfyUI 与 LLM 是否必须放在同一台电脑实际上这类问题也取决于编排层怎么设计如果通过 HTTP API 通信模型推理和图像生成完全可以分离部署。6. 自测怎么判断一个模型“能不能跳”理论归理论实际项目里更关心的是手上这个模型在多大程度上“能跳”。6.1 测试用例设计建议设计三组对照测试。第一组直接提问型。给出一道需要多步推理才能解答的问题但提示词里不要求模型展开思考只让它直接输出答案。比如一个图书馆有 3 个书架每个书架有 5 层每层放 24 本书。 如果图书馆每周新增 18 本书经过 4 周后图书馆总共大约有多少本书第二组显式思维链。同一道题在提示词里要求“请分步骤计算最后给出答案”。两组对比能看出该模型是否默认具备展开推理的倾向。第三组长期规划型。给一个包含多个子任务的复杂目标要求模型一次生成完整执行方案不做任何工具调用。例如请规划一次从零开始上线一个企业知识库问答系统的完整流程 需要包含数据收集、清洗、向量化、检索、模型调用、前后端联调、上线监控等阶段 每个阶段给出具体步骤、产出物和潜在风险。观察模型是否漏阶段、跳步骤、产出物是否有实际可执行性。6.2 使用代码做无 CoT/有 CoT 对比可以用一段通用 Python 脚本调用任意 OpenAI 兼容接口完成对比测试。实际使用时替换 base_url、api_key 和 model 即可。import requests BASE_URL https://your-api-endpoint/v1/chat/completions API_KEY your-api-key MODEL your-model-name def ask(system_prompt, user_prompt, temperature0.2, max_tokens1024): payload { model: MODEL, messages: [ {role: system, content: system_prompt}, {role: user, content: user_prompt} ], temperature: temperature, max_tokens: max_tokens } headers { Authorization: fBearer {API_KEY}, Content-Type: application/json } response requests.post(BASE_URL, jsonpayload, headersheaders, timeout120) response.raise_for_status() return response.json()[choices][0][message][content] question 一个图书馆有 3 个书架每个书架有 5 层每层放 24 本书。 如果图书馆每周新增 18 本书经过 4 周后图书馆总共大约有多少本书 direct_prompt f请直接给出最终答案不要解释过程。\n题目{question} cot_prompt f请分步骤计算这道题每一步都写清楚计算过程最后给出最终答案。 题目{question} print( 直接输出 ) print(ask(你是一个严谨的数学助手。, direct_prompt)) print(\n 思维链输出 ) print(ask(你是一个严谨的数学助手。, cot_prompt))判断标准很简单如果直接输出结果和第二组一致且正确说明这个模型能较为稳定地完成该难度下的“跳跃式推理”如果直接输出容易出错而思维链组稳定正确说明该模型需要外部提示展开来补足深度。6.3 结果判断标准测试结果建议记录三个维度直接输出正确率思维链输出正确率思维链对提升幅度的贡献。如果思维链提升非常大说明模型对提示展开的依赖度高后续业务设计里就必须预留 CoT 提示和更长输出空间如果思维链提升有限说明模型本身推理能力已经到了提示工程难以补足的程度需要换更大模型或引入工具验证。这类测试最好准备 20 到 50 道覆盖不同难度和不同领域的题目只看单题结论容易误判。7. 接口 API 与批量评测验证“能不能跳”不应该只做一次手工测试批量评测才能形成可对比结论。7.1 curl 快速验证先用 curl 快速打通接口确认服务可访问。curl -X POST https://your-api-endpoint/v1/chat/completions \ -H Authorization: Bearer your-api-key \ -H Content-Type: application/json \ -d { model: your-model-name, messages: [ {role: system, content: 你是一个严谨的数学助手。}, {role: user, content: 一个图书馆有3个书架每个书架5层每层24本书。如果每周新增18本4周后共有多少本请直接给答案。} ], temperature: 0.2, max_tokens: 512 }注意这只是通用模板实际接口路径、请求头、参数名要以你使用的模型服务商文档为准。7.2 批量脚本批量评测的核心思路准备好测试集循环调用模型接口把每次请求和响应都落盘最后做统计。下面是一个可运行的通用框架。import json import time import requests BASE_URL https://your-api-endpoint/v1/chat/completions API_KEY your-api-key MODEL your-model-name test_cases [ { id: case_001, category: arithmetic, mode: direct, prompt: 一个图书馆有3个书架每个书架5层每层24本书。如果每周新增18本4周后共有多少本请直接给答案。, expected: 408 }, { id: case_002, category: arithmetic, mode: cot, prompt: 请分步骤计算一个图书馆有3个书架每个书架5层每层24本书。如果每周新增18本4周后共有多少本, expected: 408 } ] def call_llm(prompt, max_tokens1024): payload { model: MODEL, messages: [{role: user, content: prompt}], temperature: 0.2, max_tokens: max_tokens } headers { Authorization: fBearer {API_KEY}, Content-Type: application/json } resp requests.post(BASE_URL, jsonpayload, headersheaders, timeout120) resp.raise_for_status() return resp.json() results [] for case in test_cases: try: data call_llm(case[prompt]) answer data[choices][0][message][content] usage data.get(usage, {}) results.append({ id: case[id], category: case[category], mode: case[mode], expected: case[expected], answer: answer, prompt_tokens: usage.get(prompt_tokens), completion_tokens: usage.get(completion_tokens), status: success }) except Exception as exc: results.append({ id: case[id], category: case[category], mode: case[mode], expected: case[expected], answer: , error: str(exc), status: failed }) time.sleep(0.5) with open(llm_jump_test_results.json, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2) print(f完成共 {len(results)} 条用例结果已保存到 llm_jump_test_results.json)批量任务里建议增加重试逻辑超时或限流时退避重试每个请求之间加小延迟避免触发服务商限流。输出结果统一保存成 JSON后续做正确率分析会方便很多。7.3 评测数据整理对保存的 JSON 结果做统计重点看每种模式下的正确率直接输出和思维链输出的正确率差距失败用例集中在哪个类型平均输出 token 数估算 CoT 带来的成本增量。这一步能直接给出结论当前模型在你的业务场景里是“能跳”还是“必须靠提示展开才能跳”。如果成本预算紧张这个数字也是决定是否启用长思维链的关键依据。8. 资源占用与性能观察判断“模型跳不动”之后还要评估“让它多走几步”的成本。最明显的成本是输出 token 增加。思维链把推理过程展开后同样一道题的输出 token 数可能增加数倍。在 API 计费模式下这部分成本是成倍上升的在自托管模式下则会直接拉高显存和内存占用。如果你使用的是本地推理服务可以重点观察三个指标上下文长度CoT 展开后输入输出总 token 数上升KV Cache 占用随之增加显存占用自托管时batch 越大、上下文越长显存占用越高延迟输出 token 越多首 token 之后的生成时间越长批量任务的总体耗时明显上升。量化精度方面社区经常讨论 FP16、BF16、FP32 对模型效果的影响。主流推理框架普遍使用 BF16 或 FP16 作为默认精度显存受限时还会考虑 INT8、INT4 等量化方案。精度越低显存占用通常越低但推理质量可能波动。实际选型时要以自己模型在验证集上的表现为准不要盲目追求低精度。观察资源占用建议用几个基础手段nvidia-smi -l 2如果走 API直接看返回响应里的usage字段里面的 prompt_tokens、completion_tokens 和 total_tokens 可以精确统计每次请求的 token 消耗。批量评测时建议先跑 10 条用例看耗时和费用再决定是否全量跑完。长思维链模型尤其要注意输出长度可能远超普通模型导致单次请求延迟很高。9. 常见问题与排查方法围绕“LLM 跳不动”验证和工程对策最容易遇到的问题整理如下。问题现象可能原因排查方式解决方案直接提问结果经常错模型未触发深层推理单次前向传播深度不足用同一题目对比有 CoT 和无 CoT 的输出默认在提示词中要求逐步推理或把任务拆成多轮加了 CoT 后仍然错模型能力上限不足或中间步骤推理漂移降低 temperature检查中间步骤哪一步开始出错换更强模型把任务切成更小子任务增加程序化校验长规划任务经常漏步骤模型长期规划能力有限无法一次生成完整方案检查输出中的阶段是否覆盖所有必需步骤引入 Agent 循环分阶段生成并逐步验证RAG 场景下答案与知识冲突检索结果相关性不足或上下文组织混乱检查 TopK、重排序结果人工判断检索相关性调整检索参数增加重排序优化上下文拼接API 调用超时或限流输出 token 过多或批量请求频率过高查看响应报错码和使用量配额增大超时时间减少并发增加请求间隔本地部署显存不足上下文过长或 batch 过大KV Cache 占用过高使用nvidia-smi观察显存占用曲线减小 max_tokens、降低 batch 数、使用量化模型批量任务中途卡住个别请求异常或接口未返回检查日志中最近成功的请求位置给脚本增加超时、重试、断点续跑逻辑模型输出格式不稳定提示词约束不严或模型指令跟随能力弱检查是否要求输出 JSON 或固定格式使用结构化输出功能或在后处理中做格式解析这里要特别提醒安全边界。调用 API 评测时不要直接把业务敏感数据、用户隐私数据丢进 Prompt批量任务要考虑数据脱敏和访问控制。如果使用本地大模型服务接口要绑定内网地址或加访问鉴权避免未授权访问。涉及模型能力评估时也要遵守模型服务商的使用条款不要用自动化方式绕过服务限制。10. 最佳实践与工程建议理解了“LLM 跳不动”的限制工程上可以做几件很实际的事情。第一默认不要要求模型一步到位。把复杂任务拆成“规划、执行、验证”三个环节模型只负责其中它擅长的部分。规划用 CoT 提示执行用工具调用验证用程序或人工检查。第二输出格式要结构化。让模型以 JSON 或步骤列表输出程序可以解析并校验关键字段出现问题能及时重试。plan: - step: 1 action: query_database params: table: orders expected_output: order_count - step: 2 action: calculate_growth params: field: order_count第三建一套回归评测集。每次换模型、换提示词、调整框架时跑一遍固定测试集确保“跳不动”的问题没有隐性恶化。第四为 CoT 长度和重试次数设置预算上限。无限重试会显著提高成本和延迟限制次数反而倒逼系统设计更严谨。第五合理利用编排框架和工具协议。MCP、Agent 这类机制的价值在于把外部能力接入模型让模型不用靠内部推理“硬跳”而是靠工具调用“落地”。第六合规与授权问题不能省。无论是用 LLM API 做自动化评测还是把模型能力集成到生产系统都要确认数据来源合法、用户知情同意、不影响第三方权益。涉及音视频、人脸、版权素材时授权边界尤其要盯紧。11. 总结与下一步“LLMs Cant Jump”这个观点的工程价值是提醒我们不要高估模型在单次推理中的“跳跃”能力。模型更擅长的是在明确引导下逐步展开推理而不是一步到位给结论。这解释了为什么思维链有效、为什么 Agent 外循环必要、为什么 RAG 和工具调用越来越普及。建议你先做两件事。第一用第六节的对照测试测一下你当前在用的模型“跳”到什么程度第二把结果存成 JSON统计正确率和 token 成本作为模型选型和提示词设计的基线数据。最容易踩的坑是跳过验证直接假设模型“应该会”推导更稳的做法是默认它不会推导然后通过测试确认。下一步可以继续关注长思维链、测试时计算、MCP 工具生态和编排框架的进展这些方向都是在帮 LLM“跳得更高”或者至少给模型搭好跳板。建议把测试脚本和评测集存到自己的工具库后续换模型、调提示词时直接复用。