承接上篇第 12 节本篇继续整理第 13 到第 20 个概念重点放在推理加速、训练反馈、检索增强和 Agent 工程实践文末会用两张表把上下两篇的概念放回同一套技术栈中对照理解。13. Prefill / Decode读题和答题核心原理一次 LLM 请求通常分为两个阶段阶段类比特点Prefill读题一次性处理完整 prompt可并行度高Decode答题逐 token 生成依赖 KV CachePrefill 特点计算密集型。主要消耗矩阵乘法算力。prompt 越长这一阶段越重。Decode 特点更偏内存带宽密集型。需要频繁读取 KV Cache。输出越长这一阶段越明显。工程实现Prefill / Decode 增量推理伪代码defserve(prompt):# Prefill处理完整输入logits,kv_cachemodel.forward(prompt,past_kvNone)# Decode逐 token 生成output_tokens[]for_inrange(max_new_tokens):# 从当前概率分布中选出下一个 tokennext_tokensample(logits)# 把生成结果追加到输出序列output_tokens.append(next_token)# 如果已经生成结束符就不再继续解码ifnext_tokeneos:break# 只计算最新 token并继续复用前面得到的 KV Cachelogits,kv_cachemodel.forward(next_token,past_kvkv_cache)returnoutput_tokens实践建议生产系统中可以根据负载做分离调度长 prompt 请求优先进入高吞吐 Prefill 资源池。长输出请求需要更关注 Decode 阶段的延迟和 KV Cache 显存。是否物理拆分 Prefill / Decode 节点取决于系统规模、模型大小和网络传输成本。14. RLVR把可验证结果变成训练奖励核心原理RLVR是Reinforcement Learning with Verifiable Rewards即基于可验证奖励的强化学习。它的核心思路是如果一个任务能自动判断答案好坏就可以把这个判断结果直接当作奖励信号。和依赖人类偏好打分的 RLHF(Reinforcement Learning from Human Feedback) 不同RLVR 更强调可验证、可程序化、可复现的奖励。典型场景包括数学题答案是否匹配符号推导是否等价代码题单元测试是否通过结构化输出JSON Schema 是否通过格式任务字段是否齐全类型是否正确工具任务调用结果是否满足目标条件。工程实现奖励函数设计任务类型奖励来源代码任务单元测试通过率、编译结果、静态检查数学任务答案匹配、符号验证、数值校验结构化输出JSON Schema 校验、字段类型检查工具调用API 返回状态、业务规则校验训练流程概念版forpromptintrain_prompts:# 清空上一轮梯度避免不同 batch 的梯度意外累积optimizer.zero_grad()# 同一个题目生成多个候选答案方便比较好坏responsesmodel.generate_many(prompt,n8)rewards[]forresponseinresponses:# 用规则、测试或工具自动判断答案质量rewardverify_with_rules_or_tools(prompt,response)rewards.append(reward)# 根据奖励计算强化学习目标让高奖励答案更容易被生成lossrl_objective(responses,rewards)loss.backward()# 更新模型参数optimizer.step()实践建议RLVR 很适合“答案能验”的任务但不适合所有任务。比如开放式写作、审美判断、战略建议这类任务很难用一个确定规则判断“对”或“错”。这时如果强行设计奖励可能会出现奖励黑客、格式投机或表面优化。奖励函数要尽量可靠不能只奖励“看起来像正确答案”。对代码任务单元测试要覆盖边界条件避免模型钻测试漏洞。对数学任务要避免只看最终字符串匹配最好支持等价表达式或数值验证。奖励太稀疏时训练会不稳定可以加入过程约束、格式约束或更细粒度检查。RLVR 是后训练工具箱的一部分不是替代 SFT、RAG 或人工评测的万能方案。15. Test-time Compute推理时计算核心原理Test-time Compute也叫测试时计算或推理时计算最值得关注的地方不是“推理本来就要花算力”而是在模型参数不再更新的情况下主动增加推理阶段的计算让模型在交付最终答案之前多生成、多比较、多验证、多搜索。这个概念在推理模型兴起之后变得重要是因为它把“模型能力提升”从单纯的训练阶段扩展到了推理阶段预训练时代主要问“训练时多给多少数据和算力”推理模型时代还要问“回答这一题时值得给多少思考、搜索和验证预算”。可以把它理解成三件事的组合生成更多可能性一次不够就生成多个候选答案或多条推理路径。判断哪些更可靠用投票、规则、测试、奖励模型或验证器筛选。把推理当成搜索不是只让模型顺着一个答案写到底而是在多个中间状态之间扩展、回溯和选择。三条实现路径实现路径简单理解适合场景主要局限N 选 1 / Best-of-N / 多数投票一次生成多个候选答案再用投票、打分或验证器选一个答案容易比较、成本能接受的任务如果候选里没有正确答案再怎么选也没用长链思维推理让模型在回答前生成更长的推理过程给自己更多中间步骤数学、代码、逻辑推理、复杂分析写得更长不等于推得更对容易产生看似合理的错误推理搜索 验证把推理拆成多步每一步生成多个可能方向再通过验证器或奖励模型筛选可验证、可分步的问题如证明、规划、复杂 Agent 任务工程成本高效果依赖验证器质量这三条路径并不互斥简单系统可以只做多候选选择复杂系统可能同时使用长链推理、搜索和验证。实践建议多数投票适合做基线复杂任务更需要验证器、过程奖励或搜索。不要只增加输出长度真正有价值的是提高有效搜索密度。在线搜索很强但成本高也可以把搜索得到的高质量轨迹沉淀为训练数据用来提升后续模型。16. Thinking Budget给 AI 的思考预算核心原理Thinking Budget是显式指定模型推理时可用的计算资源。它可以表现为最大生成 token 数搜索宽度迭代次数时间预算可调用工具次数候选答案数量。核心是在速度和深度之间做取舍。工程实现应用层预算参数在应用层加入类似参数thinking_budget它不一定是模型 API 的原生参数也可以是系统自己维护的调度策略。策略示例任务类型Budget适合投入预算的原因需要控制的上限简单问答低通常可直接回答额外推理步骤收益很小避免为了“想得更久”增加无意义 token优先降低成本和延迟常规分析中需要适度拆解、对比和归纳能从少量中间推理中受益超过一定阈值后容易出现收益递减要限制响应时间代码 / 推导 / 复杂规划高多步推理、草稿验证、工具检查能明显提升可靠性受最大上下文、生成 token、工具调用次数和 GPU 时间限制不能无限拉高实时对话 / 在线客服低到中用户更看重快速响应只保留必要的理解和检查思考越长等待越久容易损害交互体验高风险决策辅助中到高需要更充分的校验、引用和反思降低遗漏风险要把准确率提升与成本、延迟一起评估必要时交给人工复核调度伪代码classThinkingScheduler:defget_budget(self,query):# 简单问题少花算力优先降低延迟ifis_simple_question(query):return1# 代码和数学更容易从多步推理或工具检查中受益elifis_code_or_math_task(query):return8# 普通分析任务使用中等预算else:return3实践建议不要把“思考预算”简单等同于“越大越好”。对用户可见的产品要提供速度与质量之间的清晰选择。对企业场景要把成本、延迟和成功率放在一起评估。17. Speculative Decoding让小模型先写大模型来审核心原理Speculative Decoding即推测解码/投机推断。该方法实现了在不降低目标大模型输出质量的前提下减少大模型逐 token 解码的次数从而提升生成速度、降低延迟和成本。它的思路是先让一个便宜的小模型也叫 draft model快速生成几个候选 token再让大模型也叫 target model一次性并行验证这些候选 token。如果候选 token 被接受就直接使用如果某个位置不被接受则从修正后的目标分布中重新采样。**核心指标**接受率acceptance rate。接受率越高加速效果越明显。很多文章会把推测解码讲成小模型先猜大模型看看猜得对不对。这个说法便于理解但不够严谨。更准确地说大模型不是只看“小模型猜出的下一个 token是不是自己最想生成的那个 token”。它会比较这个候选 token 在小模型和大模型各自判断中有多大可能性再决定接受还是拒绝从而尽量让加速后的生成结果接近“完全由大模型自己一步步生成”的结果。具体的算法原理在这位老师的博客写的很好https://charlestar.github.io/2026/05/12/%E6%8E%A8%E6%B5%8B%E8%A7%A3%E7%A0%81SpeculativeDecoding%E5%8E%9F%E7%90%86%E4%B8%8E%E5%AE%9E%E8%B7%B5/通俗易懂的讲Speculative Decoding能够提升生成速度的核心原因是普通解码大模型生成 4 个 token要跑 4 次大模型。 推测解码小模型先猜 4 个 token大模型只跑 1 次来验证这 4 个 token。普通解码Prompt → 大模型 → token1 Prompt token1 → 大模型 → token2 Prompt token1 token2 → 大模型 → token3 Prompt token1 token2 token3 → 大模型 → token4大模型跑了 4 次。推测解码小模型先猜token1 token2 token3 token4 Prompt token1 token2 token3 token4→ 大模型一次 forward→ 同时得到 4 个位置的概率工程实现基本步骤Draft 模型自回归生成k个候选 token。Target 模型对这k个候选 token 做一次批量验证。对候选 token 逐个做接受 / 拒绝判断。一旦拒绝就从修正后的目标分布中采样并结束本轮。继续下一轮推测解码。实践建议Draft 模型要足够快也要和 target 模型分布足够接近。Draft 模型与 target 模型最好使用一致或兼容的 tokenizer。k不是越大越好过大时接受率下降反而浪费计算。适合输出比较可预测的场景例如代码补全、格式化文本、结构化回答。18. GraphRAG基于知识图谱的RAG核心原理GraphRAG是在 RAG 基础上引入知识图谱或图结构。传统 RAG 更擅长找相关片段GraphRAG 更适合处理关系密集、需要跨文档整合的问题例如A 依赖哪些 B某项目和哪些系统有关某客户投诉和哪些版本变更有关一个组织内部有哪些主题、社区和关系链工程实现构建流程从文档中抽取实体、关系、事件或主题。构建图结构例如实体关系图、社区图或主题图。对图进行聚类或社区发现。为图节点、社区或关系生成摘要。查询时根据问题召回相关图结构和文本证据。将图结构描述与文本证据一起交给模型回答。实际例子客户投诉归因假设知识库里有三类材料客服工单、版本发布记录、系统依赖文档。负责售后的技术支持收到投诉后问AI助手客户 Alpha 升级到 3.2.1 后订单支付失败可能和哪些系统变更有关普通 RAG 可能只召回“支付失败”的工单片段GraphRAG 会先把材料抽成图关系(Alpha)-[:提交]-(工单 T-1023) (工单 T-1023)-[:提到]-(payment-service) (版本 3.2.1)-[:修改]-(payment-service) (版本 3.2.1)-[:引入]-(签名算法调整) (payment-service)-[:依赖]-(auth-service)查询时可以沿着“客户 → 工单 → 服务 → 版本变更 → 依赖服务”这条关系链召回证据MATCH (c:Customer {name: Alpha})-[:SUBMITTED]-(t:Ticket)-[:MENTIONS]-(s:Service) OPTIONAL MATCH (r:Release {version: 3.2.1})-[:CHANGED]-(s) OPTIONAL MATCH (r)-[:INTRODUCED]-(change) OPTIONAL MATCH (s)-[:DEPENDS_ON]-(dep:Service) RETURN t.id, s.name, r.version, change.name, dep.name最终交给模型的上下文就不只是几个相似文本片段而是图结构摘要Alpha 的工单 T-1023 提到 payment-service版本 3.2.1 修改了 payment-service并引入签名算法调整payment-service 依赖 auth-service。 原文证据工单中的错误描述、发布记录中的变更说明、依赖文档中的服务链路。 用户问题客户 Alpha 升级到 3.2.1 后订单支付失败可能和哪些系统变更有关这样模型更容易回答“优先排查 3.2.1 中 payment-service 的签名算法调整以及它与 auth-service 的鉴权兼容性。”实践建议对小型 FAQ 或简单知识库普通 RAG 往往已经够用。对长报告、组织知识、跨文档主题分析GraphRAG 更有优势。19. Worktree给每个 AI 分一个独立工位核心原理工作树严格意义上并不算LLM相关的黑话只是在AI coding“更高更快更强”的过程中该工具的优势逐渐凸显。Git Worktree允许在同一仓库下创建多个独立工作目录是AI辅助代码开发时代的神器。在普通开发里它的作用是让你不用反复切分支也能同时打开多个分支。在 AI Agent 辅助的开发过程中它更像是给每个 Agent 或每个任务分配一张独立工位主仓库 main ├─ ../wt-fix-login 分支 agent/fix-login交给 Agent A 修登录问题 ├─ ../wt-add-tests 分支 agent/add-tests交给 Agent B 补测试 └─ ../wt-update-docs 分支 agent/update-docs交给 Agent C 改文档这些目录共享同一份 Git 仓库历史但各自有独立的文件树、分支和未提交状态。这样做的好处是多个 Agent 可以并行工作互不覆盖对方正在修改的文件每个 Agent 的改动也可以单独测试、单独审查最后再决定是否合并回主分支。为什么我们要在开发中使用worktree:优点说明节省磁盘空间多个 worktree 共享同一套 Git 对象库不需要像多次git clone那样复制完整.git历史。远程状态同步一个 worktree 执行git fetch后其他 worktree 通常也能看到更新后的远程引用。本地分支互相可见在一个 worktree 中提交的本地分支可以在其他 worktree 中直接查看方便对照进度。配置集中管理Git config、alias、hooks 等配置可以复用避免多个 clone 重复配置。适合并行开发每个任务或 Agent 使用独立目录和分支互不覆盖改动最后统一 review 和合并。工程实现典型流程为每个任务创建一个独立分支和 worktree。把 Agent 的工作目录限制在对应 worktree 中。Agent 在自己的 worktree 里修改、运行测试、提交结果。主仓库统一 review、比较差异并合并。创建两个 Agent 工作区gitworktreeadd-bagent/fix-login../wt-fix-login maingitworktreeadd-bagent/update-docs../wt-update-docs main此时可以让两个 Agent 分别在不同目录中运行Agent A 的 cwd ../wt-fix-login Agent B 的 cwd ../wt-update-docs如果两个 Agent 都改了同一个文件冲突会在合并阶段暴露而不是在工作过程中互相覆盖。实践建议多个 Agent 并行处理不同 issue。避免多个任务在同一个工作目录里相互覆盖。避免未提交状态相互污染。便于回滚和审查。每个任务都要绑定清晰分支名。Agent 修改前先同步主分支减少后续冲突。合并前要跑测试和代码审查。临时 worktree 要及时清理避免仓库膨胀。Worktree 只隔离代码目录和 Git 状态不等于安全沙箱运行命令、访问网络、改数据库仍然需要额外权限控制。把这些概念串起来看假设你要做一个 AI 编程助手可以这样理解整套技术栈目标对应技术底层模型成本可控MoE推理成本和速度优化KV Cache、Prefill / Decode、Speculative Decoding、Quantization长材料处理Long Context、RAG、Context Engineering复杂任务推理Test-time Compute、Thinking Budget能力对齐RLVR、LoRA / QLoRA知识检索RAG、GraphRAG工具连接Agents、MCP隔离与审计Sandbox、Worktree、Hooks进一步拆成四个核心问题核心问题对应概念怎么更快MoE、KV Cache、Prefill / Decode、Speculative Decoding、Quantization怎么更会解决问题RLVR、Test-time Compute、Thinking Budget怎么处理长材料Long Context、RAG、GraphRAG、Context Engineering怎么连接真实世界Agents、MCP怎么安全干活Sandbox、Worktree、Hooks总结一下2026 年的 LLM 相关概念已经不只是“模型参数多大”这么简单。真正重要的变化是AI 正在从聊天框变成一个能接工具、会查资料、能写代码、能按流程执行任务的数字员工。本篇只是建立直觉性的理解真正做到方法应用还需要对各个概念进行深入的理解和研究。