上下文工程¶

窗口再大，也不该什么都往里塞——上下文工程是「在有限的注意力预算内，让对的信息出现在对的位置」的艺术。 🟡 半稳定（原则稳定，具体技巧随模型演进）｜对位 W4 ｜最后核实：2026-09-08

为什么要懂¶

2025 年后行业有个共识：agent 表现的上限，更多由上下文质量而非模型本身决定（《深入理解 AI Agent》第 2 章的标题就是「上下文决定能力上限」）。你 W4 做 SDTM spec 阅读器、W6–7 读 Codex 的 compaction 机制，本质都是在做上下文工程。这一页是它们的原理底稿。

核心解释¶

回到注意力页的会诊类比：会议室桌面（窗口）再大，与会者（token）的注意力也是有限的。每多塞一份资料，所有资料分到的关注就被稀释一分。 这就是上下文工程要解决的核心矛盾：

Lost in the middle：模型对上下文开头和结尾的内容关注最强，中间的最弱。把关键约束埋在 3000 行 log 中间，约等于没说
信噪比原则：上下文里无关内容越多，模型被带偏的概率越高——无关信息不是"无害的填充物"，是噪声
上下文是复合体：系统提示词 + 工具定义 + 对话历史 + 工具结果 + 检索资料，全都在抢同一个注意力预算

由此推出四条工程原则：

只放必要的：SAS log 分析器不该塞整个 3000 行 log——先提取 ERROR/WARNING 段落再送进去（W1 项目的天然升级版）
重要信息放两端：关键指令、评判标准放开头（系统提示）或结尾（用户消息末尾重申）
压缩与摘要：长对话定期把旧历史浓缩成摘要（compaction）——你 W6 会在 Codex 源码里读到生产级实现
隔离：复杂任务拆给子 agent，各自带干净的上下文，只回传结论（阶段 3 多 agent 的动机之一）

动手试试（连接你的 W1 项目）¶

拿出 W1 的 SAS log 分析器做对比实验：同一份 log，① 全文塞入提问 vs ② 先用脚本提取 ERROR/WARNING ± 前后 5 行再提问。比较回答质量和 token 消耗——你刚刚就完成了一次上下文工程实践。

常见误解¶

❌「1M 窗口时代，上下文工程过时了」→ 恰恰相反：窗口越大，塞得越爽，稀释越狠。窗口解决的是"能不能装"，工程解决的是"装进去有没有用"
❌「RAG 已死 / 长上下文已死」→ 两者是互补工具：RAG 解决"从海量里选什么"，长上下文解决"选完放得下"。L2 有一页专门讲这场争论（待写）
❌「系统提示词越长越严谨」→ 冗长的系统提示是注意力预算的最大浪费源之一。精确、分层、可检验，像写 SAP 一样写它

现状与深挖¶

2026 年实践前沿：自动 compaction、上下文分层（系统/会话/任务三层）、「上下文预算」成为 agent 框架标配配置项——W6–7 读 Codex 时重点验证这些概念的生产级形态。
深挖：《深入理解 AI Agent》第 2 章（KV Cache、提示工程、上下文压缩、Agent Skills），见 resources.md 中文体系化教材。