上下文工程完全指南：用「写、选、压、隔」四把手术刀，根治 LLM 的"上下文崩溃"
为什么你的 Agent 聊着聊着就"发疯"？为什么它会忘记几分钟前说过的话，又为什么它会"言之凿凿"地胡说八道？
答案藏在 上下文 里。
构建一个能跑通 demo 的 Agent 容易，构建一个能稳定生产的 Agent 难。难就难在：上下文窗口是有限的，而世界是无限的。一旦你往里塞的内容失控，模型就会出现各种"精神错乱"。
这就是 上下文工程（Context Engineering） 要解决的问题。
一、什么是上下文工程？
上下文工程 是研究如何设计、构建、优化和管理 AI Agent 的"上下文信息"的学科。它的目标很朴素：用恰到好处的信息填充上下文窗口，让系统更可靠、准确、实用。
1.1 Agent 的"大脑"由三块构成
| 组件 | 角色 | 关键特征 |
|---|---|---|
| 模型 | 推理引擎 | 预训练无记忆、接收上下文、基于知识推理、调用工具 |
| 上下文窗口 | 工作记忆 | 装着当前对话、工具、任务信息，但容量有限 |
| 长期记忆 | 持久存储 | 向量库、知识图谱、文件系统、以往对话存档 |
💡 关键认知：模型本身是没有记忆的。你给什么，它就用什么。
1.2 上下文一旦失控，会出现四种"病"
| 症状 | 表现 | 病根 |
|---|---|---|
| Context Poisoning（投毒） | 幻觉 / 错误信息进入后被反复引用，不断偏离 | 写入未做质量控制 |
| Context Distraction（分散） | 上下文过长，模型只关注上下文，忘了训练时的常识 | 未做压缩/修剪 |
| Context Confusion（混乱） | 冗余内容过多，模型抓不住主线 | 缺少精准选择 |
| Context Clash（冲突） | 新工具/新信息与旧信息打架，模型困惑 | 未做上下文隔离 |
二、四大关键策略：写、选、压、隔
接下来逐个拆解。
① 写入（Write）：把信息"搬"出窗口
核心理念：突破上下文窗口限制，将信息持久化到外部存储，实现"工作记忆 → 长期记忆"的转移。
两种写入方式
| 方式 | 适用场景 | 典型实现 |
|---|---|---|
| 会话中写入 | 轻量暂存，存中间思考/推理链 | Scratchpad 草稿板 |
| 持久化写入 | 跨会话信息积累 | 向量库、知识图谱、文件系统 |
持久化写入的三种玩法
- 记忆系统架构：用向量库 / 知识图谱做跨会话信息积累
- 智能记忆生成：ChatGPT / Cursor 风格，分析用户交互自动生成长期记忆
- 反思机制：Reflexion 模型在每次执行后生成自我总结 + 经验教训
⚠️ 工程要点
- 必须设容量上限（如 10 条思考记录）
- 超过阈值自动总结清理，否则写入本身会变成新的"投毒源"
② 选择（Select）：只把"对的"送进窗口
核心理念：在海量信息中精准定位最相关内容，把最具价值的喂给模型。
四种选择维度
| 维度 | 说明 | 关键技巧 |
|---|---|---|
| 草稿选择 | 通过文件/状态对象工具调用，精细控制向 Agent 暴露什么 | 默认不暴露，按需拉取 |
| 记忆选择 | 选任务相关的记忆 | few_shot 当情景记忆，instruction 当程序记忆 |
| 工具选择 | 工具 > 100 时只拉相关工具 | LangChain tool_selector 基于模型选工具 |
| 知识选择 | RAG 流水线 | 嵌入搜索 → 知识图谱检索 → 重排序 |
💡 小技巧：选择策略的核心不是"加更多上下文"，而是"减掉无关上下文"。
③ 压缩（Compress）：给上下文"瘦身"
核心理念：只保留后续任务所需信息，减轻 token 压力。在信息保留度和token 效率之间找平衡。
总结的三个要点
- 冗余识别与去重：合并重复信息
- 对话轨迹总结：把详细对话浓缩为关键要点
- 决策点保留：特别保留关键决策和上下文线索（不能压掉的底线）
修剪的典型实现
| 实现 | 思路 |
|---|---|
| 时间衰减策略 | 基于时间戳 + 访问频率决定删除优先级 |
| 重要性评分 | 模型给每条信息打分，低分删除 |
| Provence 框架 | 训练专门的修剪模型，针对问答场景优化 |
④ 隔离（Isolate）：别让一个 Agent 干所有事
核心理念：拆分上下文，按职责分配。解决的是信息交叉污染和目标漂移问题。
两种隔离方式
| 方式 | 做法 |
|---|---|
| 多智能体（Multi-agent） | 拆 SubAgent，每个有自己的 Context + Tool |
| 环境隔离（Environments Isolation） | 用状态对象、沙箱、写代理架构让步骤在独立环境执行 |
环境隔离的三种实现
- 沙箱执行：代码在隔离环境跑，只把结果回传主上下文
- 状态管理：复杂状态变量在沙箱内维护，不污染主上下文
- 资源隔离：token 密集型对象（图像、音频）在环境中处理，避免一次性吃掉窗口
三、症状 → 策略的对照表
诊断 → 处方 的思维模型：
看到症状 → 对照表 → 选策略 → 调 LangChain 模块。
四、LangChain V1.0 的能力矩阵
LangChain 在 V1.0 把这四大策略工程化了，模块和策略的对应关系如下：
| 策略 | LangChain 能力 |
|---|---|
| 写入 | 短期/长期 Memory、File system |
| 选择 | 每个节点精细控制、Tool selector、Todo list |
| 压缩 | 消息列表的 Summarization |
| 隔离 | 状态、沙箱、Subagent |
五、实战决策流程
当你的 Agent 出现"精神错乱"时，按这个流程来：
六、写在最后
合理的架构不是技术的盲目堆砌。
逐步观察迭代 → 发现问题 → 利用上下文工程的思路 → 针对性部署改进措施。
| ❌ 不要 | ✅ 应该 |
|---|---|
| 硬塞（堆技术、灌上下文） | 观察思考（从症状出发，匹配策略） |
一句话总结四大策略
写选压隔（Write · Select · Compress · Isolate）
- 写 → 决定存什么、存哪里
- 选 → 决定送什么进窗口
- 压 → 决定留什么、丢什么
- 隔 → 决定怎么拆、怎么分
📌 附：本文导图速览
如果觉得有用，欢迎转发给身边还在被 LLM "上下文崩溃"折磨的朋友 🙌