上下文工程是什么
上下文工程（Context Engineering）可以定义为：
在每一步 Agent 执行时，为模型注入“刚好足够且高相关”的信息，并持续管理这些信息的生命周期。
如果提示词工程主要关注“怎么说清楚任务”，上下文工程主要关注“给模型喂什么信息，按什么顺序喂，什么时候清理与重建”。
阶段一：被动截断与滑动窗口时期
典型特征
- 上下文窗口普遍较小，token 极度稀缺
- 主要策略是“超了就截断”
- 常见实现是 sliding window（仅保留最近 N 轮）
解决了什么
- 至少保证系统不因超长输入直接失败
- 保留最近交互，维持最基本的多轮连续性
核心问题
- 早期关键信息容易被丢弃
- 长任务中“目标漂移”严重
- 历史状态无法稳定继承
阶段二：外部拓扑引入时期-RAG
典型特征
- 从“把所有信息塞进窗口”转向“按需检索再注入”
- 向量检索 + 语义召回开始成为主流
- RAG 将参数知识与外部知识解耦
解决了什么
- 突破单窗口记忆上限
- 降低幻觉（至少让回答有可检索证据）
- 让知识更新不依赖模型重训练
核心问题
- 检索召回质量不稳定（召不回、召偏）
- 上下文拼接后仍会出现注意力稀释
- “召回了不等于模型用好了”
阶段三：精细化压缩与重排时期
典型特征
- 社区系统性关注 Long Context 利用率
- 出现“Lost in the Middle”相关研究与工程优化
- 策略从“堆上下文”升级为“压缩、重排、分层记忆”
常见方法
- 历史摘要压缩（state snapshot / handoff summary）
- 工具输出裁剪（保留最近关键回合）
- 信息重排（把最关键证据靠前/靠后放置）
- 任务分段与阶段性交接
解决了什么
- 降低中段信息被忽视的问题
- 提高长任务状态继承稳定性
- 让 Agent 跨窗口执行更可控
核心问题
- 压缩摘要可能引入信息损失
- 重排规则依赖任务类型，难一套通吃
- 需要评估体系验证“压缩后是否仍可执行”
阶段四：无限长上下文与基建缓存时期
典型特征
- 模型上下文窗口持续增大
- 供应商和框架层引入更完善的缓存/复用机制
- Agent 系统从“上下文管理”走向“上下文基础设施”
常见能力
- Prompt/前缀缓存（减少重复 token 成本）
- 会话状态快照与恢复
- 多层记忆架构（短期工作记忆 + 长期外部记忆）
- 基于策略的动态上下文构建
解决了什么
- 降低长链路调用成本与时延
- 提升长任务连续执行能力
- 让“记忆管理”可工程化治理
核心问题
- 成本与复杂度上升
- 记忆污染与过时信息治理更难
- 需要可观测性来定位上下文失效点
行业内知名的上下文工程文章与资料
以下是我认为对上下文工程最有代表性的公开资料：
- Anthropic: Effective context engineering for AI agents
- 明确提出“上下文工程是提示词工程的自然延伸”
- 强调 Agent 可靠性的瓶颈在上下文构建而非单次提示词
- 早期长上下文实践文章，给出长输入结构化使用建议
- Anthropic Docs: Long context prompting tips
- 偏工程落地，适合作为 checklist
- LangChain Docs: Context engineering in agents
- 关注代码层面的可实现策略
- 对“中间信息利用率下降”给出系统性证据
- 直接推动了后续压缩与重排策略的工程化
- 奠定“外部检索 + 生成”的主流范式
上下文工程到底解决了什么问题
可以归纳为 6 个核心问题：
- 信息选择问题
- 不是把所有内容都给模型，而是给“当前步骤最有用的信息”
- 记忆延续问题
- 让长任务跨多轮、多窗口、多会话仍能连续执行
- 成本与性能问题
- 控制 token 成本、时延与吞吐，避免无效上下文浪费
- 可靠性问题
- 降低模型漏读关键证据、误读历史状态、重复试错
- 可治理问题
- 让上下文策略（压缩/检索/重排）可配置、可评估、可迭代
- 与工具链协同问题
- 把上下文与 RAG、缓存、状态机、任务编排系统协同起来
一句话总结：
上下文工程解决的不是“模型会不会回答”，而是“模型能否在复杂任务里持续、稳定、低成本地做对”。
我的实践结论
对于 Agent 项目，建议按下面顺序建设：
- 先有 Prompt 工程（明确任务契约）
- 再做 Context 工程（管理信息生命周期）
- 最后上 Harness 工程（形成端到端执行闭环）
如果只做 Prompt，不足以支撑长任务；如果跳过 Context 直接做 Harness，系统复杂度会快速上升且难排障。