进四 Context Engineering：真正的护城河（含 Memory）

这一章是 2026 最重要的新认知。决定 Agent 强不强的，往往不是模型，是你往上下文里塞了什么、怎么塞。

04.1 全景：五个维度，一张地图

中科算网《上下文工程指南》把上下文从"系统提示"扩成五大类（文本/环境/用户/系统/组织）。落地时，我把它压成五个工程动作：

示意图 19：Context Engineering 五维地图

flowchart TD
  W["① 写入 Write<br/>构造系统提示/初始上下文"]
  S["② 选择 Select<br/>检索·挑相关料"]
  C["③ 压缩 Compress<br/>摘要·裁剪保重点"]
  I["④ 隔离 Isolate<br/>分窗·防互相污染"]
  K["⑤ 缓存 Cache<br/>复用前缀省钱"]
  W --> S --> C --> I --> K
  style S fill:#e8f0fe,stroke:#2563eb
  style K fill:#0ea5a4,stroke:#0f766e,color:#fff

04.2 System Prompt 工程化与 Context Rot

从"写一段提示词"升级到"搭一个行为控制系统"：系统提示不再是文案，而是角色、边界、输出格式、工具说明、禁忌的集合体，要像代码一样版本管理。

但坑来了——Context Rot（上下文腐烂）：系统提示越长，模型越容易"看不见"中间的规则，注意力被稀释。

核心建议：系统提示别写成长篇小说。能外置成 Skill/工具说明的，就别塞进系统提示。

04.3 上下文快爆了？聊聊压缩

呼应 §06.4 的分层摘要。工程上压缩三招：

• 摘要：旧对话压成要点（保留近期 N 轮原文）。
• 裁剪：丢掉与本任务无关的早轮。
• 压缩：用更小模型先提炼再喂大模型。

04.4 Cache 全解与成本控制：别再弄混这几个概念

这是 2026 最容易被混淆的一组。一次讲清：

崔亮《Prompt Cache》点破关键：前缀要稳定。你每轮开头都变，缓存永远不命中。Agent 的 I/O 常是 100:1（读多写少），Cache-Safe 是客户端工程责任——把不变的系统提示/工具定义放最前，且别乱插变量。

经验：省成本第一招不是换便宜模型，是让前缀稳定、复用缓存。

04.5 深入 Just-In-Time Context：不是越早塞越好

直觉是"把料早早全塞进上下文"。错。JIT（即时）上下文主张：用到那一步，才注入那块料。

例子：写代码 Agent，不必一上来把整个代码库塞进去；读到某文件时，才把该文件上下文注入。好处：窗口不爆、相关性强、缓存命中高。

04.6 RAG 全流程与检索优化

呼应 §06.3。补"全流程"：文档 → 切分 → 嵌入 → 建索引 → 检索 → 重排 → 生成。

关键坑：语义相似 ≠ 任务相关。检索回来"意思像"的，未必是"该用"的。所以要用 §06.3 的多路召回 + 重排，必要时让模型自己判断相关性。

04.7 LLM 编译知识库：让知识持续积累互联

进阶玩法：别把知识库当静态档案。让 Agent 跑完任务后，自动抽取新知识点、连成图谱、回写库。知识库越用越聪明，像人做笔记越记越通。

04.8 记忆系统：文件派 vs 数据库派，谁对

经验：没有标准答案。先看规模与可读性，再选。很多生产系统是"文件做源、库做索引"混合。

04.9 记忆会"坏"：五种失效模式

2026 年 4 月 golangstar 把"记忆覆盖"拆成三种故障；我合上行业经验，补成五种：

注意：记忆不是"写了就灵"。它和数据库一样，要防脏数据。