摘要9-27/01 的 RAG、9-27/02 的微调、9-28/01 的工具调用最终都汇聚到一个地方——上下文Context。本文把塞进上下文提升为一门工程学科上下文四大来源系统提示 / RAG 检索 / 记忆 / 工具结果、窗口管理与压缩、模块化与动态编排。并把它接到 9-20 的 KV Cache 成本账与 9-25/03 黄金集、9-26 法官评测上。提示词工程是怎么问上下文工程是给模型什么记忆——后者往往比前者决定 70% 的回答质量却最容易被当成拼字符串敷衍了事。一句话结论把上下文当成受预算约束的结构化拼装——用四大来源分层供给、用 token 预算做压缩与淘汰、用模块化/动态编排让每次请求只携带刚好够用的信息并把上下文质量量化进 9-26 的法官评测闭环。1. 提示词工程 ≠ 上下文工程维度提示词工程上下文工程关注点怎么措辞、用什么模板给模型什么背景、什么证据输入来源人写死的指令RAG 记忆 工具 系统规则动态拼装优化目标指令清晰度信息密度 / 相关性 / 成本失败表现模型没按格式答关键证据被截断、噪声稀释注意力一句话提示词工程决定模型听不听话上下文工程决定模型知不知道真相。9-27/01 的 RAG 检索结果最终也是作为上下文的一段喂进去——但检索到了不等于拼对了、没被挤掉。2. 上下文的四大来源任何一次 LLM 请求的最终上下文都是这四块的拼接┌─────────────────────────────────────────┐ │ System : 角色 / 规则 / 输出格式稳定 │ │ History : 对话记忆 / Agent 长期记忆 │ │ Retrieval: 9-27/01 RAG 检索到的证据块 │ │ Tools : 9-28/01 工具返回的结构化结果 │ └─────────────────────────────────────────┘ ↓ 拼装 → 压缩 → 截断保护 → 发送来源稳定性体积治理重点System高小版本化、A/BHistory中中摘要/淘汰策略Retrieval低大相关性排序、去重Tools低不定截断保护、结构化这四块正是前序文章的产出9-25 网关的 system 规则、9-27/01 的 retrieval、9-27/02 微调后模型的内隐知识、9-28/01 的 tool results。3. 上下文窗口管理与压缩长上下文有两笔账注意力稀释信息越多越记不住重点和成本账9-20 已算过70B 模型 1M context 的 KV Cache 无压缩要 160–320GB 显存。因此要主动瘦身。3.1 Token 预算分配BUDGET{system:1500,# 角色与规则history:2000,# 近期对话 摘要retrieval:3000,# RAG 证据块tools:1500,# 工具结果reserve:1000,# 留给模型输出}defassemble(req,retrieved,tools_out,memory):ctx{}ctx[system]truncate(req.system,BUDGET[system])ctx[history]summarize_then_keep(memory,BUDGET[history])# retrieval 按相关性裁剪到预算ctx[retrieval]top_k_by_score(retrieved,BUDGET[retrieval])ctx[tools]keep_structured(tools_out,BUDGET[tools])returnrender(ctx)3.2 压缩三板斧手法做法取舍摘要压缩旧对话/长文档先 LLM 摘要丢细节保主线选择式裁剪只留 Top-K 相关块可能漏边缘证据层级加载先给索引模型按需展开多一轮请求贵但省 context承接 9-27/01 的 RAG 上下文压缩重排后的 Top-5 块再按预算二次裁剪避免把不相关的块硬塞进窗口。4. 上下文编排模式4.1 模块化上下文Modular把上下文拆成可独立开关的模块按任务动态加载写代码任务加载代码规范模块客服任务加载工单模板模块。4.2 可复用上下文Reusable把高频且稳定的片段如公司制度原文预计算 embedding 或预填借 9-25 语义缓存复用避免每次重新检索。4.3 动态上下文Dynamic根据中间结果增量补充上下文先给大纲模型判断需要查哪块知识再二次检索注入——这正是 9-27/03 多 Agent 里检索子 Agent的角色。defdynamic_assemble(goal):baseassemble_basic(goal)# 系统 记忆planllm_plan(base)# 模型判断需要哪些证据forneedinplan[retrieval_needs]:base[retrieval]retrieve(need)# 按需注入returnbase5. 长上下文的成本账接 9-20上下文工程不是无限堆长。把 9-20 的 KV Cache 账单算进每次请求上下文长度70B 模型 KV 显存GQA, 近似相对成本8K~12 GB1×32K~48 GB4×128K~190 GB16×1M160–320 GB无压缩25×结论能压缩到 32K 就别上 128K。上下文工程的直接回报是 9-20 KV 压缩 9-25 语义缓存之外第三道成本闸门。6. 把上下文质量量化进评测闭环上下文拼得好不好必须可测否则只是玄学。接入 9-25/03 黄金集 9-26 法官评测Context Recall黄金答案所需的证据块是否都在上下文里漏了 检索/裁剪失败Context Precision上下文里的块有多少真的相关噪声 稀释Faithfulness最终回答是否只基于上下文无幻觉接 9-27/01defctx_eval(question,context_blocks,gold_evidence_ids):got{b[id]forbincontext_blocks}recalllen(gold_evidence_idsgot)/len(gold_evidence_ids)precisionlen(gold_evidence_idsgot)/max(1,len(got))return{context_recall:recall,context_precision:precision}低分样本回流 9-20 RLVR 或 9-19 数据工厂形成上下文拼装 → 评测 → 改进检索/裁剪的飞轮。7. 小结上下文工程是 RAG、微调、工具三大能力的汇聚层与仲裁层它决定这次请求模型到底看到了什么。抓三件事分层供给四大来源、预算约束压缩与淘汰、量化评测接法官闭环。下一节9-28/03讲改了上下文/模型后怎么安全地把它发到生产——持续交付是上下文工程的最后一公里。常见问题FAQQ1上下文越长越好吗A不是。注意力稀释 KV 成本9-20双重惩罚。实测在多数任务上干净的中等上下文16K–32K优于塞满噪声的 128K。Q2History 记忆该留多少A近期 N 轮原文 更早的摘要。用摘要压缩保主线避免把三个月前的闲聊全带上。Q3RAG 检索块和上下文预算冲突怎么办A先按相关性9-27/01 的 cross-encoder 重排排序再按预算裁剪宁可少而精不要多而杂。Q4动态上下文多一轮检索会不会太慢/太贵A会但只在复杂任务开启简单问答走静态拼装。可用 9-25 语义缓存 amortize 重复检索成本。Q5System 提示频繁改版怎么灰度A把 System 当可版本化资产做 A/B接 9-28/03 持续交付用 Context Precision / Faithfulness 看新版是否更稳。Q6微调模型9-27/02还需要 RAG 上下文吗A需要。微调改能力分布RAG 补最新/私有事实二者互补过度依赖参数记忆会 reintroduce 幻觉。Q7上下文里的工具结果太长被截断怎么保护A工具结果结构化存储上下文只放摘要 引用 ID模型需要时再按需拉取层级加载避免关键数据被硬截断。参考资料Anthropic《Context Engineering》工程实践笔记2026本专栏 9-20《百万上下文推理成本工程》KV Cache 压缩与分页注意力本专栏 9-25《应用级可观测与黄金集回归》黄金集与发布回归本专栏 9-26《LLM-as-Judge 自动化评测流水线》Context Recall / Precision 量化本专栏 9-27《RAG 检索增强生成架构实战》检索块压缩与重排本专栏 9-28《函数调用与工具执行沙箱实战》工具结果作为上下文来源
