上下文工程实践：长上下文、RAG、记忆、压缩、路由和缓存
摘要
研究聚焦上下文工程在大模型应用中的实践问题：如何在长上下文、RAG、记忆、压缩、路由和缓存之间做系统性取舍。方法上，文章把上下文视为面向模型的动态供应链，分析任务上下文、知识上下文、会话上下文、记忆上下文、工具上下文和治理上下文的组织方式。结论是，稳定 AI 应用不应依赖“把材料全部塞进去”，而应通过边界定义、证据选择、状态压缩、链路路由和缓存治理，让模型在每次请求中获得最少但足够的信息。
关键词
上下文工程；长上下文；RAG；记忆；压缩；路由；缓存；证据治理
研究问题与方法
本文的研究问题是：面对不断增长的历史、文档、工具返回和用户状态，系统如何决定哪些信息进入模型、进入何处、保留多久。分析方法采用供应链视角，把上下文生产过程拆成获取、过滤、排序、压缩、注入、复用和观测，并用任务成功率、证据覆盖、延迟、成本与安全风险评估上下文策略。这个方法强调组合而非站队：长上下文、RAG 和记忆都只是上下文供应链中的不同环节。
上图说明，上下文工程的对象不是单段提示词，而是持续运转的信息链路。可以用一个评估表描述常见策略的取舍；正文后续各节会围绕这些取舍展开，而不是把某一技术当成默认答案。
| 策略 | 主要收益 | 主要代价 | 适合场景 |
|---|---|---|---|
| 长上下文 | 保留完整结构和跨段关系 | 成本高、位置偏差、冲突增加 | 固定资料包、深度阅读、跨文档比较 |
| RAG | 适合大规模和动态知识库 | 切分、召回、重排链路复杂 | 企业知识库、产品文档、政策问答 |
| 记忆 | 跨会话保持偏好和经验 | 事实污染、隐私和过期风险 | 个性化助手、长期项目、重复工作流 |
| 压缩 | 降低窗口压力和延迟 | 摘要误差可能累积 | 长对话、工具日志、阶段性任务 |
| 路由与缓存 | 降低成本并提高稳定性 | 策略维护和命中率治理 | 多模型平台、高频重复任务 |
这个表的意义在于把上下文策略从工具选择拉回任务约束。若任务要求证据可追溯，RAG 与引用更重要；若任务要求完整阅读，长上下文更有价值；若任务跨越多天，记忆和状态治理才是关键。
引言：上下文工程的系统边界
上下文工程讨论的不是“提示词怎么写得更漂亮”，而是一个智能系统怎样把正确的信息、正确的工具、正确的历史、正确的约束，在正确的时刻交给模型。提示词像一句话，上下文工程像一条供应链：资料从哪里来，如何切分，怎样排序，什么时候进入窗口，什么时候被压缩，什么时候被缓存，什么时候应该换模型或换检索方式，都要被设计、度量和维护。
大模型应用早期常见的做法，是把系统提示词写长一点，把用户资料拼进去，再期待模型自己理解一切。这个做法在原型阶段很快，但进入真实业务后会出现一批稳定问题：上下文越来越长，费用越来越高，延迟越来越大，引用越来越难核验，旧记忆和新事实互相冲突，工具结果把窗口塞满，长对话后模型忘掉最关键的目标，检索系统又经常找回看似相似但并不回答问题的片段。上下文工程的价值，就是把这些问题从“玄学调参”变成可观察、可迭代的工程系统。
本文把上下文工程拆成六个关键能力：长上下文、RAG、记忆、压缩、路由和缓存。它们不是互相替代的流派，而是可以组合的部件。长上下文解决“模型一次能看多少”；RAG 解决“知识库太大或会变化时怎样找”；记忆解决“跨轮次、跨会话、跨用户怎样保留经验”；压缩解决“窗口满了以后留下什么”；路由解决“不同任务应该走哪条链路”；缓存解决“重复上下文怎样降低成本和延迟”。真正可用的智能体，通常不是选其中一个，而是让六个能力协同工作。
上下文工程的边界定义
任何上下文系统都应该先回答一个问题：模型此刻需要知道什么，才有资格完成当前任务？这个问题比“能不能塞更多 token”重要得多。一个客服机器人处理退款问题，需要订单状态、用户身份、商品政策、历史沟通、可执行操作和安全限制；一个代码智能体修复 bug，需要仓库结构、相关文件、测试失败、约束规则、历史尝试和可运行工具；一个研究助手写报告，需要原始资料、引用位置、对比维度、论证目标和已知不确定性。它们需要的上下文类型不同，窗口长度也只是其中一个参数。
可以把上下文分为六层。第一层是任务上下文，说明用户要完成什么、成功标准是什么、输出形式是什么。第二层是知识上下文，来自文档、网页、数据库、论文、代码库或业务系统。第三层是会话上下文，包括当前对话中的目标、澄清、用户偏好和临时状态。第四层是记忆上下文，保存跨会话仍然有效的事实、偏好、流程经验和历史决策。第五层是工具上下文，包括可调用工具、工具返回、错误信息、权限边界和外部系统状态。第六层是治理上下文，包括安全规则、合规要求、引用规范、拒答边界和品牌口径。
这六层不能混成一锅粥。任务上下文要尽量靠近用户请求，方便模型理解当前目标；长期政策和稳定规则适合放在静态前缀，便于缓存；知识上下文应带来源和时间，便于引用和过期处理；工具结果应短而可追踪，不能把完整日志无限塞入窗口；记忆应区分事实、偏好和经验，不能把模型自己推测出的东西当成真实资料。上下文越多，越需要结构，不然长窗口会变成噪声容器。
上下文工程还有一个基本原则：上下文不是越多越好，而是越有用越好。大量无关文本会稀释注意力，增加成本，延长首 token 延迟，并制造更多冲突。论文《Lost in the Middle》提醒我们，模型并不总能均匀使用长输入中的信息，相关内容位于中间时可能更难被利用。这个结论并不意味着长上下文没有价值，而是说明长上下文必须配合排序、提纲、引用提取和检索策略。把所有资料扔进窗口，不能自动等于理解。
长上下文不是免检索通行证
长上下文最大的优势，是让模型一次阅读一组完整资料，而不是只看被切碎的片段。对合同审阅、论文比较、代码仓库局部理解、会议记录总结、复杂报告写作来说，完整上下文常常比碎片检索更自然。它能保留章节结构、论证顺序、表格前后关系和跨段引用，也能减少传统 RAG 因切分过细造成的语义损失。
但是长上下文不是免检索通行证。窗口再长，也有输入成本、延迟、位置偏差和冲突处理问题。一个模型可以接收几十万甚至更多 token，不代表每个 token 都被同等有效地使用。资料越长，模型越容易漏掉中间细节，越容易把早期要求和后期要求混在一起，也越容易在多个来源矛盾时给出看似折中的错误结论。真正的长上下文实践，不是“能塞就塞”，而是“先组织，再阅读”。
长上下文适合三类任务。第一类是资料包固定、任务集中、需要整体理解的工作，例如读一份招股书、审一套接口文档、总结一场访谈、比较几篇论文。第二类是资料之间存在强结构关系的工作，例如多章制度、产品规格、法律条款、代码文件之间的调用关系。第三类是一次性深度分析，资料体量不大到需要全文库检索，但又大到普通短窗口无法承载。
长上下文不适合三类场景。第一类是知识库持续变化，资料量远大于窗口，且每次只需要少量事实；这时 RAG 更经济。第二类是高并发在线服务，用户请求短而频繁，重复塞入长文档会带来明显延迟和成本。第三类是需要强权限隔离的企业知识场景，不能因为一个用户提问就把他无权访问的资料放进窗口。上下文窗口不是权限系统，放进去就等于暴露给模型推理过程。
长文档进入提示词时，应先保持资料在前、问题在后。Anthropic 的长上下文提示建议强调，把长文档放在上方，查询和指令放在下方，复杂多文档任务最好给每份文档加清晰标记和来源元数据。这个做法背后的原因很朴素：模型需要先“读材料”，再按任务回答。如果问题夹在大量资料前面，模型在处理后续资料时可能淡化最初目标；如果资料缺少来源标识，引用和冲突分析都会变差。
长上下文还应该要求模型先定位证据，再生成结论。对事实密集任务，可以让模型先列出与问题相关的原文片段、来源、章节和时间，再基于这些证据做综合判断。这个步骤会让输出稍长，但能降低“凭印象总结”的风险。对法律、医疗、金融、企业政策等高风险资料，证据定位不是装饰，而是基本可用性要求。
排序也很关键。重要资料不要机械按上传顺序放置，而要按任务相关性和结构关系排序。若必须放入很多材料，可以在顶部给出资料目录和任务索引，在每份资料前加摘要和来源，在结尾处再次明确问题。对于特别长的包，可以把最关键资料放在前部和后部，把背景材料放中间，或者通过分阶段阅读让模型先建立大纲，再针对问题读取细节。
长上下文评估不能只看一次回答是否顺眼。应该准备一组覆盖不同位置、不同粒度、不同冲突类型的问题：开头事实、中间事实、结尾事实、跨文档比较、表格数字、否定条件、例外条款、过期资料识别。每次调整资料排序、提示结构、模型或窗口长度，都用同一组问题回归。没有评估集的长上下文优化，很容易变成主观感觉。
RAG 不等于向量库套壳
RAG 的核心思想是把模型的生成能力和外部知识检索结合起来。经典论文《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》把参数化模型与非参数化外部记忆结合，用检索到的文档辅助生成。今天的工程实践已经比早期论文更复杂，但基本动机没有变：模型本身不可能掌握所有最新、私有、长尾和权限受控的知识，因此需要在推理时查资料。
很多失败的 RAG 系统看起来有完整链路：文档上传、切分、embedding、向量数据库、召回、拼接、回答。问题是它们只做到了“能搜”，没有做到“搜得准、用得对、答得可证”。用户问一个合同条款，系统召回了语义相似但合同版本不同的片段；用户问一个产品限制，系统召回了旧文档；用户问“哪些情况不能退款”，系统召回了退款流程却漏掉例外条款；模型最后仍然给出流畅答案。这样的 RAG 不是增强，而是把错误包装得更可信。
生产级 RAG 首先要重视文档解析。PDF 表格、扫描件、页眉页脚、脚注、代码块、图片说明、章节编号和多栏排版都会影响检索质量。解析阶段丢掉标题层级，后面的 embedding 再好也很难恢复结构。对政策、合同、财务报表和技术文档来说，保留页码、章节、表格标题、发布日期、版本号和权限标签，比盲目追求向量相似度更重要。
切分策略决定了召回的语义单位。切得太短，片段缺少上下文，模型不知道“本条”“该服务”“上述期限”指什么；切得太长，召回不精确，窗口被无关段落占满。可行做法是使用层级切分：小块用于匹配，大块或父段用于回答。也可以给每个块补充上下文说明，例如所在文档、章节主题、前后关系和适用范围。Anthropic 的 contextual retrieval 思路正是为了缓解传统切块丢失上下文的问题：在嵌入前给片段补上必要背景，让检索时更容易命中真实语义。
检索不应只依赖一种相似度。纯向量检索对概念相近问题有效，但对编号、金额、日期、产品名、错误码、法规条款、专有名词和中文短词可能不稳定。关键词检索能补足精确匹配，混合检索能兼顾语义和字面。召回后再用重排序模型或 LLM 判断相关性，通常比直接把前若干个向量结果塞给模型更可靠。检索链路的目标不是“多找一些”，而是“把真正能回答问题的证据排到前面”。
RAG 还要处理“没有答案”。很多系统只优化有答案问题，导致任何问题都会被强行回答。更好的做法是让检索器返回置信度、覆盖度和来源状态，让生成阶段能判断证据是否足够。如果检索结果只包含相关背景但没有直接证据，答案应该说明资料不足，而不是补脑。用户真正需要的不是每次都得到一段文字，而是知道哪些结论有证据，哪些还需要查。
引用是 RAG 的产品底线。引用不能只列文档名，应该尽量指向章节、页码、段落或片段编号。模型输出中的每个关键事实、数字、限制条件和比较结论，都应该能回到来源。引用体验还要避免“挂羊头卖狗肉”：引用片段必须支持对应句子，而不是只和主题相关。对中文读者来说，最直观的体验是点击引用后能看到原文片段、上下文和来源时间。
RAG 的更新机制也很重要。知识库不是一次建好就永远正确。企业制度会更新，价格会变化，接口会废弃，文档会合并，旧资料会被撤回。每个索引片段都应该带版本、时间、来源和失效规则。资料更新后要能增量重建索引，旧片段要能下线或降权，引用要能说明使用的是哪个版本。否则系统会把过期知识变成自动化错误。
评估 RAG 时，不要只看生成答案。至少要分开评估四件事：解析是否完整，召回是否命中，排序是否合理，生成是否忠实。一个答案错了，可能是文档解析丢了表格，也可能是检索没召回，也可能是模型忽略了证据，还可能是用户问题本身需要权限或实时数据。只有拆开指标，才知道该修哪一层。
长上下文与 RAG 的组合
技术讨论里经常出现“长上下文会不会取代 RAG”。这个问题本身容易误导。长上下文和 RAG 解决的是不同阶段的问题：长上下文提高模型一次阅读资料的能力，RAG 决定从大规模资料中选哪部分进入阅读。资料量小、任务深、结构强时，长上下文可能更好；资料量大、变化快、权限复杂时，RAG 仍然必要。多数生产系统应该组合，而不是站队。
可以用四象限判断。资料少且稳定，直接长上下文即可；资料少但反复查询，长上下文加缓存更合适；资料多但每次只需局部答案，RAG 是主链路；资料多且问题需要跨资料综合，先检索召回候选，再用长上下文阅读较完整的父文档或资料包。这个组合能减少碎片化，同时避免把整个知识库塞进窗口。
还有一种组合叫“先检索，再扩展”。用户问题进入系统后，先用关键词、向量和元数据过滤找到候选文档，再把候选文档的完整章节、相邻段落或父级单元放进长上下文。这样模型看到的不是孤零零的 chunk，而是有边界的资料单元。对于制度问答、代码解释、论文综述，这种方式通常比只拼接若干小片段更自然。
另一种组合叫“先长读，再建索引”。对一批高价值长文档，可以先让模型生成结构化目录、术语表、章节摘要、适用范围和问题清单，再把这些增强信息写入索引。这样后续 RAG 检索的不是原始碎片，而是带上下文的知识单元。它的成本更高，但对专业文档、产品手册、标准规范和复杂政策很有价值。
长上下文和 RAG 的选择也受成本影响。长上下文每次都读大量资料，简单但贵；RAG 前期有工程成本，单次请求更省；缓存可以降低重复长上下文成本，但要求稳定前缀和命中率。生产决策不应该只看模型能力，而要看查询频率、资料变化、并发量、延迟预算和维护人力。
长期记忆不是聊天记录回放
记忆是上下文工程最容易被误解的部分。很多产品把“保存聊天记录”叫记忆，但聊天记录只是原始材料，不是可用记忆。真正的记忆需要选择、归类、验证、更新和遗忘。否则系统会把临时说法、用户玩笑、过期事实、模型误判和失败尝试全部带入未来任务，越用越乱。
短期记忆服务于当前线程。它保存用户刚刚说过什么、任务进展到哪一步、工具调用返回了什么、当前计划还有哪些未完成。LangChain 的短期记忆文档把它放在 agent state 和 checkpointer 中，这个思路很实用：短期记忆应该随线程恢复，但不一定跨线程自动共享。它像工作台上的便签，帮助模型连续完成当前工作。
长期记忆服务于跨会话连续性。它可以保存用户偏好、组织规则、项目背景、常用流程、历史决策和经过验证的事实。长期记忆不应该无脑写入。写入前要判断来源是否可靠、是否长期有效、是否用户授权、是否有隐私风险、是否已有冲突版本。一个好的长期记忆系统，写入门槛比读取门槛更高。
长期记忆可以分成三类。语义记忆保存稳定事实，例如“这个团队使用某个文档模板”“某项目的正式名称是什么”。情景记忆保存曾经怎样解决过问题，例如“上次部署失败是因为环境变量缺失，最终通过某个步骤修复”。程序记忆保存可复用技能和流程，例如“处理客户退款争议时先查订单，再查政策，再给出可执行选项”。这三类记忆的存储、检索和更新策略不同，不应混放在一条聊天摘要里。
记忆必须有来源。没有来源的记忆会让系统越来越像自信的谣言机。每条长期事实都应知道来自哪次用户确认、哪份文档、哪个系统字段或哪次人工编辑。若来源资料更新，依赖它的记忆也应该重新验证。对价格、政策、权限、人员、接口、库存等变化快的信息，应设置过期时间或只在需要时实时查询。
记忆还必须可纠正。用户说“以后别按那个流程做了”，系统不能继续从旧记忆里召回过时经验。记忆界面应允许用户查看、删除、修改和禁用关键记忆。对团队系统来说，还要区分个人记忆、项目记忆和组织记忆。个人偏好不能污染组织规则，组织规则也不能被单个用户随意改写。
在智能体中，记忆读写最好不要完全交给主模型的即兴判断。可以设置专门的记忆策略：哪些内容可写，哪些需要用户确认，哪些只能由管理员写入，哪些只能短期保留。也可以让模型提出“建议记忆”，再由规则或人工批准。这样既保留智能体的学习能力，又避免把所有对话碎片长期化。
压缩质量不等于摘要越短
上下文窗口有限，工具调用和长对话会快速膨胀。压缩的任务不是把所有内容变短，而是在信息损失可控的前提下保留未来任务需要的状态。压缩做得好，智能体能长时间工作；压缩做得差，系统会丢掉约束、误解历史、重复失败或忘记用户真正目标。
最简单的压缩是裁剪。裁剪适合去掉明显无用内容，例如旧的闲聊、重复日志、完整堆栈中无关部分、已经完成的中间草稿。但裁剪不能按时间机械删除。当前任务依赖的早期需求、用户否定过的方案、关键错误和权限边界，即使很早也必须保留。时间顺序不是价值排序。
第二种压缩是摘要。摘要适合把多轮对话、长工具结果和文档阅读过程转成较短状态。好的摘要应包含目标、已确认事实、待办事项、决策理由、未解决问题、引用来源和禁止事项。坏摘要只写“用户想做一个系统，已经讨论了一些方案”，这种摘要几乎没有可执行价值。
第三种压缩是结构化提取。对业务系统来说，结构化状态比自然语言摘要更可靠。例如把一次客户支持对话压缩成：用户身份、订单号、问题类型、已查证据、适用政策、可选动作、下一步。把一次代码修复压缩成：失败测试、相关文件、已尝试改动、错误原因、剩余风险。结构化状态可以被程序验证，也更容易在不同模型之间传递。
第四种压缩是分层存储。热状态留在窗口里，温状态放在线程记忆中，冷状态进入可检索存储。当前步骤只需要最热的信息；如果模型需要旧背景，再通过检索或工具取回。这样比把所有历史都塞进窗口更稳定，也更符合真实工程系统的内存层级。
第五种压缩是工具结果清理。工具调用往往返回大量原始数据，其中只有少部分对后续推理有用。Anthropic 的 context editing 文档提到可以自动清理较旧的工具结果并保留占位提示。这个方向很实用：工具结果不应永远占据窗口，而应在完成证据提取后转为短结论、引用和可追踪标识。保留“查过什么、结论是什么、源头在哪里”，通常比保留完整原始输出更有价值。
压缩的最大风险是不可逆误删。一个摘要如果漏掉“不得使用某供应商”这样的约束，后续智能体可能做出严重错误。因此关键上下文要有保留规则：用户目标、硬约束、来源证据、未解决风险、外部系统状态、失败经验和安全边界不能被普通摘要覆盖。压缩结果还要能被检查，不能只存在模型隐含状态里。
压缩也需要评估。可以构造长对话任务，让系统运行多轮工具调用后继续回答早期约束相关问题，检查是否还记得关键目标。也可以比较压缩前后对同一问题的答案，看是否发生事实漂移。若压缩后引用丢失、时间线混乱、已完成事项被重新执行，就说明压缩策略有问题。
问题路由与链路选择
上下文工程中的路由，是判断一个请求应该交给哪种模型、哪套工具、哪个知识库、哪种检索策略、是否需要长上下文、是否需要人工确认。没有路由的系统，所有问题都走同一条链路：简单问题也查库，复杂问题也只看短提示，实时问题也用旧索引，敏感问题也被普通模型处理。这会造成浪费和风险。
最基础的路由是意图路由。用户问“解释这个概念”，可能只需通用模型；问“根据公司政策回答”，必须进入知识库；问“帮我改文件”，需要工具和权限；问“这个价格现在是多少”，需要实时查询；问“总结这份 PDF”，可以走长上下文；问“我之前让你怎么写标题”，需要记忆检索。意图路由可以由规则、分类模型或 LLM 完成，但结果要可观察。
第二类是数据源路由。一个企业系统可能同时有产品文档、客服工单、合同、代码库、数据库、知识图谱和网页搜索。不同数据源有不同权限、更新频率和引用方式。路由器应该先判断问题属于哪个知识域，再选择对应检索器，而不是把所有索引混在一起做一次向量搜索。LlamaIndex 的 Router Query Engine 和 Router Retriever 思路，正是把多个查询引擎或检索器放在候选集中，由选择器决定使用哪个或哪些。
第三类是模型路由。并非所有请求都需要最强模型。短文本分类、格式转换、关键词提取可以用小模型；长文档综合、复杂推理、代码修复需要更强模型；含图表或截图的任务需要多模态模型；低延迟交互可能优先快模型；高风险结论可能需要复核模型。模型路由应基于任务难度、上下文长度、成本预算和质量要求，而不是固定一个模型包打天下。
第四类是策略路由。问题能否直接回答？是否需要先检索？检索结果是否足够？是否应该升级到长上下文阅读？是否需要调用工具验证？是否应该让用户补充信息？这些判断决定了系统是否像真正的智能体。一个成熟系统会在证据不足时主动换策略，而不是继续沿着失败链路生成答案。
路由要避免黑箱化。用户不需要看到内部实现，但系统运营者必须知道每次请求走了哪条链路、使用了哪些来源、花费了多少 token、命中哪些缓存、为什么拒答或升级。没有路由日志，就无法定位“为什么这次答错”。面向最终用户的界面可以保持简洁，只展示必要的来源、状态和下一步；面向运维的观察数据则必须完整。
路由还要防止过度自信。LLM 路由器可能把问题分错类，尤其是短问题、含糊问题和多意图问题。稳妥做法是给路由输出置信度，低置信度时走保守路径，例如多检索几个候选源、让用户选择范围、先返回澄清问题，或使用更强模型复核。路由不是一次猜测，而是可回退的决策。
缓存的成本收益与语义风险
缓存在上下文工程里有两种常见含义。第一种是提示或上下文缓存，即模型服务商对重复输入前缀进行复用，降低延迟和成本。OpenAI 的 prompt caching 文档强调缓存命中依赖重复前缀，静态内容应放在前面，变量内容放在后面；Anthropic 的 prompt caching 允许开发者标记可缓存块；Gemini API 的 context caching 提供隐式和显式机制，适合反复围绕大文档提问。第二种是应用层缓存，即系统自己缓存检索结果、工具结果、回答草稿、embedding、重排序结果或长文档分析中间物。
提示缓存的第一条原则是稳定前缀。系统提示词、工具定义、固定规范、长期文档和示例适合放在前面；用户问题、实时数据、临时检索结果放在后面。如果把时间戳、随机 ID、用户输入插入前缀，就会破坏缓存命中。缓存不是打开开关就自动省钱，它要求上下文结构稳定。
第二条原则是区分可缓存和不可缓存。公司政策、产品手册、代码仓库某个 commit 的文件内容可以缓存；实时库存、账户余额、订单状态、权限判断和短期安全令牌不应该被当作长期静态上下文。缓存命中如果带来过期事实，省下的成本会变成业务风险。
第三条原则是关注缓存粒度。整段长提示缓存简单，但只要中间有变量就可能失效；按模块缓存更灵活，但实现复杂。研究和实践中也出现了针对 RAG chunk 或 KV cache 的缓存方案，目标是在保留准确性的同时复用高频知识片段。对于普通应用，先把稳定系统提示、工具定义和高频文档放在前缀，已经能获得明显收益。
缓存还会影响隐私和安全。提示缓存通常由模型服务商在其基础设施中管理，开发者需要理解服务商的缓存生命周期、隔离策略和数据处理承诺。应用层缓存则要考虑租户隔离、权限变更、删除请求和日志脱敏。一个用户有权访问的资料，不能因为缓存而被另一个用户间接读取。权限必须参与缓存键，不能只用问题文本做缓存键。
缓存不应该替代正确性检查。相似问题复用旧答案很诱人，但用户问题中的一个日期、地区、套餐、版本差异就可能改变结论。对事实类和政策类回答，更稳妥的缓存对象是检索结果、文档解析、embedding 和可复用摘要，而不是最终答案。最终答案可以短期缓存，但必须带来源版本和失效条件。
面向用户的上下文产品表达
上下文工程最终要体现在产品体验上。用户不关心系统使用了几个检索器、缓存命中多少 token、路由器置信度是多少。用户关心的是回答是否有用、证据是否可靠、错误能否纠正、资料是否安全、等待时间是否可接受。技术结构必须服务这些体验，而不是把内部术语推给用户。
好的知识问答界面应该让用户看到答案、引用和可继续追问的方向。引用展示应清晰，不要把一堆 chunk ID、embedding 分数、内部字段放到界面上。若资料不足，应该用自然语言说明缺少什么，而不是显示“retrieval score below threshold”。若答案依赖过期或低置信资料，应该提示来源时间和不确定性。最终用户需要判断依据，不需要调试信息。
好的智能体界面应该展示任务进度，而不是展示模型内心独白。用户要知道系统正在读取资料、查询状态、生成草稿、等待确认或执行操作。对于会改变外部状态的动作，例如发邮件、改配置、下单、删除文件，应明确让用户确认。上下文工程可以让智能体更聪明，但不能绕过用户对关键动作的控制权。
好的记忆界面应该让用户掌控长期信息。用户可以看到系统记住了哪些偏好和项目事实，可以删除或修改。团队系统可以把组织规则和个人偏好分开展示，避免用户误以为个人设置会改变团队知识。记忆越强，透明度越重要。
好的失败体验也很关键。当检索不到资料、长上下文超限、工具失败、缓存失效、模型输出不确定时，系统应给出可执行下一步：上传资料、缩小范围、选择知识库、授权访问、刷新数据或转人工。失败不是暴露内部错误，而是帮助用户继续完成目标。
可落地的上下文架构
一个生产级上下文架构可以按请求生命周期设计。用户请求进入后，先做意图识别和安全检查，判断是否需要资料、工具、记忆或澄清。接着读取短期状态和必要长期记忆，但只取与当前任务相关的部分。然后根据路由结果选择知识源：小资料包可直接长上下文，大知识库走 RAG，实时事实调工具或数据库。检索结果经过重排序、去重、权限过滤和上下文扩展后进入候选池。系统再构造模型输入，把稳定规则放前面，把资料按来源和重要性组织，把用户当前问题放后面。生成后进行引用校验、格式整理、必要时二次验证。最后把有价值的新状态写回短期记忆，经过策略判断后再决定是否写入长期记忆。
这条链路里，每一步都应该有观测指标。路由层看意图分类准确率和回退率；检索层看召回命中、重排序效果、引用覆盖；长上下文层看输入长度、位置敏感问题表现、成本和延迟；压缩层看关键信息保留率；记忆层看写入质量、冲突率和用户纠正率；缓存层看命中率、节省成本和过期错误；最终输出看满意度、事实一致性、引用正确性和任务完成率。
对不同场景，架构可以简化。个人知识助手可以使用长上下文加轻量 RAG，不必一开始建设复杂路由。企业客服系统必须强化权限、引用、实时工具和拒答。代码智能体需要仓库检索、文件读取、运行测试、失败记忆和工具结果压缩。研究写作助手需要资料包管理、引用提取、论点规划和版本化草稿。不要把一种架构套到所有产品上。
常见错误与修正方式
第一个错误是把系统提示词当万能药。提示词能约束表达，但不能替代资料质量、检索准确性、权限控制和评估。若知识库召回错了，提示词再强调“请准确回答”也无济于事。修正方式是拆开链路，先保证资料解析和召回，再优化生成。
第二个错误是把所有历史都当上下文。长对话里有大量已经完成、被否定或不再相关的信息。全部保留会让模型混乱，也会浪费成本。修正方式是维护结构化任务状态，把旧消息压缩成目标、事实、决策、待办和风险。
第三个错误是把记忆写得太积极。用户随口说“我最近喜欢短一点”，系统就永久记住，未来所有场景都输出过短；模型推测用户行业，系统也写入长期记忆。修正方式是给记忆写入设置来源、置信度、范围和过期规则，重要偏好需要用户确认。
第四个错误是检索结果不做权限过滤。企业知识库里，不同用户能访问的资料不同。如果先全库检索再在答案层控制，敏感片段可能已经进入模型上下文。修正方式是在检索前或检索中加入权限过滤，并把权限纳入索引和缓存键。
第五个错误是引用只做装饰。答案后面列几个文档链接，看起来可靠，但具体句子没有证据支持。修正方式是建立句子级或段落级引用校验，对关键事实要求来源片段直接支持。
第六个错误是缓存最终答案。最终答案依赖用户问题、时间、权限和上下文，复用风险高。修正方式是优先缓存稳定前缀、文档解析、embedding、检索候选和长文档结构化摘要；最终答案只在短 TTL、同权限、同资料版本下复用。
第七个错误是只测演示问题。演示问题往往与资料标题高度相似，容易命中。真实用户会问含糊问题、反向问题、跨文档问题、时间敏感问题和不存在答案的问题。修正方式是建立覆盖真实问题分布的评估集，并持续从失败案例中补充。
从一天原型到长期系统
第一阶段可以从最小可用上下文开始。选一个明确场景，准备一小批高质量资料，使用长上下文或简单 RAG，要求答案带引用。这个阶段不要急着做复杂记忆和多模型路由，先证明资料能被正确使用。评估重点是引用是否支持结论、用户能否完成任务。
第二阶段加入检索质量控制。完善文档解析、切分、元数据、混合检索、重排序和无答案判断。开始记录每次请求的检索结果和最终引用，建立小型评估集。这个阶段的目标是让系统从“能回答”变成“能稳定回答”。
第三阶段加入状态和压缩。长对话、工具调用和多步骤任务会暴露窗口管理问题。此时需要短期记忆、任务状态、工具结果摘要和上下文裁剪规则。目标是让系统连续工作几十步仍然不丢关键约束。
第四阶段加入长期记忆。只有当用户确实需要跨会话连续性时，才引入长期记忆。先做只读项目记忆或用户可见偏好，再做可写记忆。目标是提升连续性，而不是悄悄收集所有对话。
第五阶段加入路由和缓存。流量增长后，成本和延迟会成为主要问题。此时根据任务类型选择模型、检索器和长上下文策略，并把稳定前缀和高频资料缓存起来。目标是用更低成本保持质量，而不是牺牲准确性换速度。
第六阶段建设治理和运营。包括权限审计、引用抽检、记忆管理、资料更新、缓存失效、模型升级回归、失败案例复盘和用户反馈闭环。上下文工程不是一次性项目，而是持续运营的知识基础设施。
上下文策略判断清单
如果问题围绕一份或几份固定资料，并且需要整体理解，优先长上下文。若资料包会被反复查询，给稳定资料启用上下文缓存。若问题来自大规模资料库，优先 RAG，并确保元数据、权限和引用。若资料切块后容易丢失指代和章节关系，使用父子切分、上下文增强或检索后扩展。若任务跨多轮执行，维护短期状态和压缩摘要。若用户希望系统长期记住偏好和项目事实，引入可见、可纠正的长期记忆。若请求类型差异很大，使用路由选择模型、工具和知识源。若成本和延迟过高，先优化上下文结构和缓存命中，再考虑换模型。
还可以用一句话判断：上下文工程的目标，是让模型少看无关内容，多看关键证据，记住该记的，忘掉该忘的，必要时去查，重复时复用，拿不准时承认。做到这件事，比写一段华丽提示词更接近真正的 AI 产品能力。
参考资料
- OpenAI：Prompt caching，https://platform.openai.com/docs/guides/prompt-caching/overview
- OpenAI：File search，https://platform.openai.com/docs/guides/tools-file-search/
- Anthropic：Long context prompting tips，https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/long-context-tips
- Anthropic：Prompt caching，https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching
- Anthropic：Contextual Retrieval in AI Systems，https://www.anthropic.com/news/contextual-retrieval
- Google AI for Developers：Gemini API Context caching，https://ai.google.dev/gemini-api/docs/caching
- LangChain Docs：Short-term memory，https://docs.langchain.com/oss/python/langchain/short-term-memory
- LangChain Docs：Memory overview，https://docs.langchain.com/oss/python/concepts/memory
- LlamaIndex Docs：Routing，https://docs.llamaindex.ai/en/stable/module_guides/querying/router/
- Patrick Lewis 等：Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks，https://arxiv.org/abs/2005.11401
- Nelson F. Liu 等：Lost in the Middle: How Language Models Use Long Contexts，https://arxiv.org/abs/2307.03172
- Uri Anavi 等：Long Context RAG Performance of Large Language Models，https://arxiv.org/abs/2411.03538