引言
从 2022 年 ChatGPT 发布到 2025 年，上下文工程从零发展成了一个完整的领域。我们经历了：
- API 从续写模式进化到对话模式
- Token 从神秘概念变成了可以精确计算和优化的成本单位
- 上下文窗口从 4K 增长到 200 万
- 从「请输出 JSON」到 100% Schema 保证
- 从只能聊天到能调用工具、检索知识、管理记忆
但最有趣的问题不是我们已经解决了什么，而是还有什么没解决。
未解问题 1：无限上下文的梦想
我们想要什么？
理想状态：
用户可以给模型任意长的内容
模型都能完整理解、精准回忆、高效处理
现实：
├── 上下文窗口有限（即使 200 万也不够某些场景）
├── 注意力 ∝ N² → 超长上下文计算成本爆炸
├── Lost in the Middle → 模型对中间信息视而不见
└── 成本随长度线性（输入 token）甚至超线性（计算量）增长可能的方向
方向 1：更高效的注意力机制
标准注意力：每个 token 关注所有 token → O(N²)
稀疏注意力：每个 token 只关注部分 token → O(N × k)
线性注意力：近似计算 → O(N)
代表：Flash Attention, Ring Attention, Mamba
方向 2：记忆压缩
不存储完整的 KV Cache，而是压缩旧的上下文
类似人类记忆：遗忘细节，保留要点
代表：AutoCompressors, ICAE
方向 3：分块处理
不把所有信息同时放进上下文
而是按需检索——本质上就是 RAG 的思路
但需要更智能的「什么时候检索什么」策略未解问题 2：上下文效率
模型真的「用到」了所有上下文吗？
研究发现：
在一个 128K token 的上下文中
模型实际「有效关注」的可能只有其中几千 token
这意味着：
你花了 128K token 的钱
但模型可能只用了 5K token 的信息
效率只有 ~4%上下文效率研究
如何让模型更高效地利用上下文？
方向 1：更好的注意力分配
让模型学会「什么时候该仔细看，什么时候可以粗略扫」
方向 2：上下文压缩
在放入上下文前，先压缩信息
例如：1000 字的文档 → 200 字的摘要 → 放入上下文
方向 3：动态上下文
不是一次性放入所有信息
而是根据查询动态决定放入多少信息
类似「主动读取」而非「被动接收」未解问题 3：可靠性
上下文工程的「最后一公里」
即使在 2025 年，AI 应用仍然面临可靠性挑战：
1. 格式可靠性
Structured Outputs 解决了 JSON 格式
但更复杂的约束（比如「输出必须是合法的 SQL」）还不完美
2. 指令遵循可靠性
system prompt 说「不要讨论政治」
模型在 99% 的时候遵守，但有 1% 可能违反
对于生产系统，1% 的失败率可能不可接受
3. 工具调用可靠性
模型可能在不该调用工具时调用
或在该调用时没调用
或调用了但参数错误
4. 记忆一致性
长期记忆可能过时或矛盾
如何确保记忆的准确性和时效性？状态空间模型：Transformer 的挑战者？
Mamba 和 SSM
Transformer 的问题：
注意力机制的 O(N²) 复杂度
→ 长上下文的计算瓶颈
状态空间模型（SSM）的思路：
不用注意力，用「状态」来压缩信息
→ O(N) 复杂度
类比：
Transformer = 每次回答都要翻阅所有笔记（O(N²)）
SSM = 把笔记总结成精简的「知识状态」（O(N)）
代表：Mamba, Mamba-2, Jamba（Mamba + Transformer 混合）
现状：
SSM 在某些任务上表现优秀
但在复杂推理上仍不如 Transformer
混合架构可能是未来方向课程总结：上下文工程的全景图
2022.11ChatGPT 发布，对话式 AI 时代开启
2023.3ChatGPT API 开放，token 经济学成为话题
2023.6Function Calling 发布，AI 从聊天到行动
2023.7开源向量数据库爆发，RAG 成为标配
2023.11Gemini 发布 100 万 token 上下文
2024.8Structured Outputs 发布，格式问题终结
2024.11MCP 协议发布，工具标准化起步
2024-25记忆系统、Prompt Caching 成为新焦点
2026Harness Engineering 兴起，Agent 进入操作系统时代
上下文工程的核心框架
上下文工程 = 设计模型完成任务所需的完整信息环境
┌───────────────────────────────────────┐
│ Harness Engineering │
│ （运行时系统层） │
│ │
│ ├── Skill 模块化（指令管理） │
│ ├── 渐进式披露（信息按需加载） │
│ ├── Hook 机制（硬约束） │
│ ├── 子 Agent 调度（上下文隔离） │
│ └── 状态交接（跨会话管理） │
│ │
│ ┌─────────────────────────────────┐ │
│ │ 上下文工程 │ │
│ │ │ │
│ │ 输入层 │ │
│ │ ├── System Prompt │ │
│ │ ├── Few-Shot 示例 │ │
│ │ └── Structured Outputs │ │
│ │ │ │
│ │ 知识层 │ │
│ │ ├── RAG │ │
│ │ ├── 长上下文 │ │
│ │ └── 记忆系统 │ │
│ │ │ │
│ │ 行动层 │ │
│ │ ├── Tool Calling │ │
│ │ └── MCP │ │
│ │ │ │
│ │ 优化层 │ │
│ │ ├── 上下文管理 │ │
│ │ ├── Prompt Caching │ │
│ │ └── 模型选择 │ │
│ └─────────────────────────────────┘ │
└───────────────────────────────────────┘关键洞察
1. 上下文是 AI 应用的核心
模型能力再强，没有正确的上下文也白搭
「Garbage in, garbage out」
2. 从 prompt 到工程到运行时
提示工程 → 上下文工程 → Harness 工程
每一步都是对 AI 应用认知的升级
从「写好提示词」到「设计信息环境」到「构建运行时系统」
3. 成本是不可忽视的维度
上下文越长越贵
优秀的上下文工程 = 用最少的 token 获取最好的效果
4. 可靠性是生产级应用的前提
从 85% 到 100% 的格式匹配
从「大部分时候对」到「每次都对」
这是工程要解决的核心问题
5. 约束是赋能而非限制
Harness 的约束悖论告诉我们
给 AI 设定边界反而让它更可靠、更高效
栏杆让高速公路更安全、更快速
6. 这个领域还在快速进化
今天的最佳实践可能半年后就过时
保持学习、保持实验本节小结
| 概念 | 要点 |
|---|---|
| 无限上下文 | 梦想很美好，但 O(N²) 注意力是物理瓶颈 |
| 上下文效率 | 模型可能只用了 4% 的上下文信息 |
| 可靠性 | 1% 的失败率在生产环境中不可接受 |
| SSM/Mamba | O(N) 复杂度，Transformer 的潜在挑战者 |
| Harness 工程 | 上下文工程的下一个范式——为 Agent 构建运行时操作系统 |
| 课程总结 | 提示工程 → 上下文工程 → Harness 工程，三次范式转移 |
思考题
- 回顾整个课程，哪一个技术变革让你印象最深？为什么？
- 如果你要在一个完全新的领域（比如医疗 AI、法律 AI）应用上下文工程，你会从哪些方面入手？
- 你认为 2026 年，上下文工程领域最可能出现的突破是什么？
课程结语
上下文工程是 AI 应用开发的核心学科。它不是关于如何写一段「魔法提示词」，而是关于如何设计一个完整的系统——让 AI 拥有正确的知识、正确的工具、正确的行为规则，以及正确的成本结构。
从 2022 年到 2026 年，这个领域经历了三次范式转移：从提示工程到上下文工程，再到 Harness 工程——为 Agent 构建运行时操作系统。每一次转移都意味着我们对 AI 应用开发的认知更进了一层。
而这只是开始。