推理：RAG、Agent 与长上下文系统

现代推理系统已经很少只是“给模型一个 prompt 然后生成答案”。很多真实系统更接近下面这种结构：

$\text{retrieval} \rightarrow \text{context assembly} \rightarrow \text{model} \rightarrow \text{tools/agents}$

如果只想先建立 RAG、Prompt Chaining、ReAct 和 CoT 的基础直觉，可以先回看 Prompt、CoT 与 RAG 入门。本页重点放在推理系统里的容量、状态、上下文装配和线上失效。

这意味着推理系统必须同时处理检索、长上下文、工具调用和多轮状态：从外部文档、数据库或索引中找证据，把证据、历史和用户问题装进有限 token 预算，让模型在需要时调用搜索、数据库、OCR、浏览器或业务 API，并持续追踪已经查过什么、得到什么、下一步该做什么。

而这四件事一旦组合起来，系统的核心问题就会从“单次推理质量”转向“信息如何被组织、更新、裁剪和追踪”。这也是为什么很多看似是模型问题的线上故障，最后会落到检索、上下文装配或状态管理上。

初学者先抓住

RAG、Agent 和长上下文不是简单把更多信息塞进 prompt。真正难点是证据怎么选、上下文怎么装、工具状态怎么追踪、旧信息什么时候丢掉。

有趣例子：带资料参加会议

你不能把整个档案柜搬进会议室，只能带最相关的几页。RAG 负责找资料，context assembly 负责排版和取舍，Agent 则像会议中不断查资料、执行任务、更新记录的人。

1. 为什么 RAG 不只是“加个检索器”

RAG 的核心不只是把文档拼进 prompt，而是决定查文档、表格、数据库、网页还是历史记录，决定放多少证据进上下文，决定关键证据是否出现在模型更容易使用的位置，并避免无关信息塞爆上下文后误导模型。

如果检索链不稳，模型会被看似权威但不相关或过期的材料误导；上下文虽然变长，信息密度却下降；无关材料还会被编码进 KV cache，直接增加 prefill 延迟和显存。

1.1 RAG 的真实目标是证据组织，不是文本召回

很多系统刚做 RAG 时，目标只是“把相关文本找回来”。更成熟的目标应该是判断证据能否直接支撑回答、是否足够新、多份证据是否相互一致，以及在有限上下文预算内是否值得保留。

换句话说，RAG 真正优化的是 evidence orchestration，而不只是 retrieval recall。

2. 上下文装配本身就是系统设计

设检索到的候选片段为 $\{d_1,\dots,d_k\}$，真正送入模型的上下文不等于全部片段简单拼接。实际需要解决：

$\mathcal{C}^\star = \text{Assemble}(d_1,\dots,d_k, q, B)$

其中 $B$ 是上下文预算。这一步包括去重、排序、裁剪和模板包装：移除重复片段，把最关键、最新或最可信证据放在合适位置，删掉无关段落、表格行或历史消息，同时保留来源、时间、权限和引用格式。

2.1 为什么上下文装配经常比模型更影响效果

因为它决定哪些信息先被模型看到、哪些证据被截断、哪些元数据被保留，以及哪些证据会相邻出现并形成局部关联。

在长文档问答、法规审查和多模态文档系统里，这一步经常比“换更大模型”更直接地改变答案质量。

3. 长上下文不等于信息利用率高

很多系统把上下文长度加大后，确实“放得下更多文本”，但未必“用得好更多文本”。现实中的问题常是：

• 重要证据被埋没：关键句子被大量无关材料挤到不显眼的位置。
• prompt 冗长推高 prefill：模型必须先编码大量低价值 token。
• cache 压力增大：长上下文会线性增加 KV cache 占用。

所以长上下文系统的关键是有效信息密度，而不只是 token 上限。

3.1 一个简单的信息密度视角

如果一个 100k 上下文里只有 5k token 与当前问题真正相关，那么剩余 95k token 并不是无害背景：它们会增加 prefill 成本、稀释模型注意力、放大无关证据混入的风险，并占据缓存预算。

因此长上下文能力若没有配套压缩、重排和淘汰策略，常常只会把系统拖慢，而不会让系统更聪明。

4. Agent 系统为什么更复杂

当系统不只回答，还会调搜索、数据库、OCR、浏览器或业务 API 时，它就不再是单步生成，而是一个多步控制系统：

$a_t \sim \pi_\theta(a_t \mid c_t),\qquad c_{t+1}=U(c_t,a_t,o_t)$

其中 $o_t$ 是工具返回结果。

4.1 Agent 为什么更像控制而不是聊天

每一步动作都会改变未来可见信息。模型选择了哪个工具、取回了什么结果、是否继续检索，都会直接影响下一轮决策。因此 agent 更像闭环系统，而不是多轮版 prompt。

这意味着评测 agent 不能只看最终回答，还必须看它是否会进入低价值工具循环、是否会在错误证据上越走越偏、是否能在必要时终止探索，以及是否能管理中间状态而不把上下文越堆越乱。

5. RAG 与 Agent 的交叉点

很多真实系统会先用 RAG 获取第一批证据和候选方向，再根据证据缺口调用数据库、OCR、搜索或浏览器，最后把多步工具结果和检索材料合成可引用答案。

这意味着推理系统的真正难点已经不只是 decode，而是状态管理、上下文复用和工具链容错：记录已检索证据、工具结果、用户约束和当前任务阶段，避免每轮重复塞入相同材料，并在工具失败、超时或返回冲突结果时降级和重试。

5.1 一个典型工作流

在企业知识助手中，系统经常先检索制度文档，再从检索结果判断是否需要调用数据库；若数据库结果与文档冲突，就再次召回更多证据，最终输出答案并给出引用。

在这个过程中，RAG 和 agent 早已不是两条线，而是一个统一的多阶段信息流。

6. 长上下文系统最常见的瓶颈

Prefill 成本

上下文越长，prefill 越贵。

Cache 压力

KV cache 很快成为显存大头。

证据污染

无关检索片段反而降低答案质量。

多轮漂移

Agent 在多步工具调用后，上下文容易越来越乱。

证据版本冲突

检索到的不同文档可能来自不同时间、不同权限层或不同版本。若系统不处理这些冲突，模型会在相互不兼容的证据上推理。

状态膨胀

随着多轮交互进行，系统会不断追加工具返回结果、中间推理文本、历史检索片段和用户追问。

没有压缩与淘汰机制时，系统很快会变成“上下文很长，但自己也说不清当前状态是什么”。

7. 一个直观例子：企业合规问答代理

系统可能要同时处理合同、邮件、内部流程文档和法规片段：合同提供义务、违约条款和责任边界，邮件补充协商过程和时间线，内部流程文档说明审批规则，法规片段提供外部合规约束。

用户问的是一句话，但系统背后可能经历检索相关条款、检索内部规范、调用表格解析工具和汇总结果等多个阶段。

这已经不是普通 chat inference，而是完整的多阶段信息流。

7.1 这个例子里最容易出错的地方

最容易出错的地方包括初始检索召回过期法规、内部规范与公开法规版本不一致、表格工具把金额字段识别错，以及最终答案只引用其中一条证据却忽略另一条冲突证据。

用户最终只会看到“答案错了”，但系统内部其实可能是多个环节一起导致的失败。

8. 工程建议

做这类系统时，建议单独评估检索质量、上下文装配质量、模型推理质量和工具调用成功率。

不要只看最后答案。否则出了问题，你会很难知道是检索错了、拼接错了，还是模型没用好证据。

8.1 建议增加的专项评测

更成熟的系统还应增加证据一致性评测、上下文压缩前后效果对比、多轮工具链稳定性评测、长上下文成本与质量联合评测，以及版本更新后的回归集。

9. 一个实用抽象

可以把这类系统拆成三层：retrieval layer 决定找什么，assembly layer 决定怎么组织证据，reasoning layer 决定怎么用这些证据和工具完成任务。

分层优化往往比端到端黑箱调 prompt 更有效，也更便于定位问题。

10. 一个总判断

RAG、Agent 和长上下文系统的结合，代表着推理系统已经从“单次生成”走向“受约束的信息编排与决策系统”。因此它们更像系统工程问题，而不是单纯模型推理问题。真正强的系统，不只是能读很多 token，而是知道何时检索、何时压缩、何时调用工具、何时停止继续扩张上下文。

工程收束

RAG、Agent 和长上下文系统要把检索质量、上下文压缩、工具链时延、长文档 prefill 和会话级反馈分开看。生产验收要区分检索失败与推理失败，记录每轮工具收益，让长上下文走专门通路，并维护 session 回放；oncall 面板也应直接看到 route、cache、queue 和 fallback 状态。