第8章 上下文工程（Context Engineering）
📖 "提示工程让你学会如何跟 LLM 说话，上下文工程让你学会如何帮 LLM 看见全世界。"
本章概览
如果说 Prompt Engineering 是"如何提一个好问题"，那么 Context Engineering（上下文工程） 就是"如何为 LLM 构建一个高质量的信息环境"。
随着 Agent 承担的任务越来越复杂——从简单的问答到跨越数百轮交互的长时程任务——单纯优化 prompt 已经远远不够。你需要系统性地管理 LLM 在每次推理时能看到的全部信息：对话历史、工具返回、检索文档、任务状态……这些信息的总量可能轻松超过 100K tokens，而上下文窗口是有限的。
这是 Agent 开发中最容易被忽视、但对实际效果影响最大的主题之一。Anthropic CEO Dario Amodei 曾明确表示："我更愿意称之为上下文工程，而不仅仅是提示工程" [1]。掌握上下文工程，是从"能写 prompt"到"能构建生产级 Agent"的关键跨越。
本章目标
学完本章，你将能够：
- ✅ 理解提示工程与上下文工程的本质区别，建立系统性的上下文设计思维
- ✅ 识别并诊断上下文腐蚀现象，掌握 Lost-in-the-Middle 效应的应对方法
- ✅ 灵活运用压缩整合、结构化笔记、子代理架构三大长时程策略
- ✅ 动手实现完整的 GSSC 上下文构建流水线，并应用于自己的 Agent 项目
本章结构
| 小节 | 内容 | 核心收获 | 难度 |
|---|---|---|---|
| 8.1 从提示工程到上下文工程 | 定义上下文工程，对比两者差异 | 六大信息源模型 + 三大设计原则 | ⭐⭐ |
| 8.2 上下文窗口管理与注意力预算 | 上下文腐蚀、注意力分布、管理技术 | 注意力预算分配 + 三种管理技术 | ⭐⭐⭐ |
| 8.3 长时程任务的上下文策略 | 压缩整合、结构化笔记、子代理架构 | 三大策略的原理与组合使用 | ⭐⭐⭐ |
| 8.4 实战：构建上下文管理器 | 完整 GSSC 流水线实现 | 可复用的上下文管理基础设施 | ⭐⭐⭐⭐ |
⏱️ 预计学习时间
约 90-120 分钟（含实战练习）
为什么 Agent 开发者必须掌握上下文工程？
一个典型场景：你的 Agent 在第 1 轮对话中表现完美，但在第 20 轮后开始"忘事"、"重复"、"偏题"。这不是 LLM 变笨了——而是上下文空间被低质量信息填满了。
上下文工程就是解决这类问题的系统方法论。它让你从"碰运气写 prompt"升级为"工程化管理信息流"：
- 信息收集：从多个来源（对话、工具、RAG、任务状态）聚合候选信息
- 智能筛选：按优先级和相关性，在 token 预算内选出最优子集
- 动态压缩：对冗长内容进行摘要，释放空间给新信息
- 最优布局：利用注意力分布规律，将关键信息放在 LLM 最"关注"的位置
💡 前置知识
- 已完成第 3 章（大语言模型基础），了解 LLM 的工作原理
- 已完成第 4-7 章（工具调用、记忆系统、规划推理、RAG），了解 Agent 的核心信息源
- 理解 Token 和上下文窗口的基本概念
- 熟悉 Python 的 dataclass 和基本数据结构
🔗 学习路径
前置知识：第3章 LLM 基础、第4-7章 核心能力
后续推荐：
- 👉 第11章 LangChain — 用框架实现上下文管理策略
- 👉 第16章 评估与优化 — 评估上下文策略的效果
参考文献
[1] AMODEI D. Context engineering vs prompt engineering[EB/OL]. 2025.
下一节：8.1 从提示工程到上下文工程