上下文工程：窗口是最稀缺的资源

一句话定义

上下文工程是为 LLM 的每一次调用精心配置"此刻它该看见什么信息"的学科——它是提示工程在 Agent 时代的升级版，因为 Agent 的上下文是动态生长的，会腐烂、会超限、会被稀释。

为什么重要

Anthropic 在 2025 年把它明确为"新的编程学科"，理由很硬：Agent 的一切行为都由上下文决定。模型不会"内省"自己该做什么，它只对窗口内的 token 做条件生成。工具用错、目标遗忘、格式漂移，八成病因不在模型，而在你往窗口里塞了什么、塞在哪、塞了多少。这个领域的资深从业者有一句行话："上下文工程就是 Agent 的内存管理"——上个时代的程序员为 KB 级内存写代码，这个时代你为 200K token 的注意力写代码。

前置知识

kp-002（token、窗口、注意力机制直觉）。

核心概念

上下文里住着谁

一次 Agent 循环的调用中，窗口被四类内容瓜分：

系统提示：身份、目标、规则、工具使用守则——常驻，是"宪法"
工具定义：每个工具的 schema 与描述——常驻，但占空间（20 个工具可能吃掉 5K+ token）
对话历史：用户消息 + 助手回复 + 工具调用与返回（往往是最大头，一次网页抓取可达数万 token）
检索注入：RAG 取回的片段、记忆文件内容（kp-015/016）

上下文腐烂（Context Rot）

长任务中窗口逐步退化的三种症状：

淹没：关键指令被海量工具输出稀释，模型"看不见"最初目标
冲突：新旧信息打架（早期说"用美元"，后来工具返回了人民币数字）
漂移：格式与风格随历史逐渐走样（前 5 轮输出 JSON，第 30 轮混入了散文）

位置效应：迷失中间

模型对开头与结尾的内容注意力最强，中段召回显著变差（"Lost in the Middle"，Liu et al. 2023）。工程推论：关键指令放系统提示（头）或最后一条消息（尾）；长文档检索片段宁可分多次小批注入。

原理与机制

为什么不能"全塞进去"？三个物理约束：

成本与延迟线性增长：每次循环都重放整个历史，1M 窗口跑 50 轮，token 费用是天文数字（kp-027）
注意力稀释：transformer 的自注意力在长序列上被摊薄，中段信息召回下降——这是架构性质，不随"窗口标称值"消失
干扰：无关的历史工具输出会诱导模型复用旧模式（比如重复调用早已失败的路径）

由此导出上下文工程的四个基本操作：增（按需注入检索结果/记忆）、删（裁剪过期工具输出）、压（摘要压缩历史，kp-022）、隔离（把脏活丢给子 Agent，用完只带回结论，kp-019）。

直观类比

上下文窗口是 Agent 的办公桌桌面：

桌面有限（窗口固定），每份摊开的文件都占地方
干了三小时活，桌上堆满草稿（工具输出），最初的任务单早被压在最底下（淹没）
好的上下文工程 = 一个勤快的办公习惯：任务单钉在墙上（系统提示），干完一阶段把草稿归档为一张便签（压缩），大批材料搬到隔壁桌处理、只拿回结论（子 Agent 隔离）

实例与案例

同一个研究型 Agent 的上下文配置对比：

策略	结果
全量历史塞入	第 25 轮超窗报错；未超窗时中段召回差，漏掉关键约束
每轮网页全文追加	token 成本 ×12，回答质量反而下降（噪声稀释）
网页内容即时摘要 + 原文存文件 + 只留摘要入窗	成本降 70%，目标保持率明显提升

第三种即 "just-in-time context" 的雏形：原文存外部（文件/记忆），窗口里只留线索与结论，需要时再取（进阶见 kp-022）。

常见误区

误区一："系统提示越长越保险"。几十条规则堆叠后，模型对每条的遵守率都下降，且互相冲突的规则让它无所适从。规则应少而明确，行为约束优先写进工具与流程（kp-010）。
误区二："上下文工程 = 提示工程的时髦叫法"。提示工程优化一段静态文本；上下文工程设计的是随时间演化的信息结构与流转机制（检索、压缩、隔离），是系统设计问题。
误区三："窗口大就不用管了"。见上——成本、稀释、迷失中间都还在。
误区四：把工具原始输出无脑全量入窗。这是新手 Agent 最常见的成本黑洞与腐烂源。

自测题

说出上下文腐烂的三种症状。
为什么关键指令要放头部或尾部？
增删压隔离四个操作分别对应什么场景？

（参考答案：1. 淹没、冲突、漂移；2. 迷失中间效应，中段注意力召回差；3. 增=按需注入外部知识，删=清理过期输出，压=摘要压缩历史，隔离=子 Agent 处理脏数据只回传结论。）

与其他知识点的关系

进阶技术（压缩/分层/compaction）→ kp-022
长期记忆的文件化 → kp-015；检索注入 → kp-016
Claude Code 的实战应用 → kp-028