Context Engineering：构建可靠 Agent 上下文管理的工程体系

title: "Context Engineering：构建可靠 Agent 上下文管理的工程体系"

从 Prompt Engineering 到 Context Engineering 的范式转移

2026年，AI 应用开发的核心挑战已经从"如何写好 Prompt"演变为"如何管理复杂的上下文"。随着 Agent 系统处理的任务越来越复杂——从简单的问答到多步骤推理、工具调用、长期记忆管理——上下文工程（Context Engineering）已经成为决定 Agent 可靠性的关键因素。

传统的 Prompt Engineering 关注的是单次交互的指令优化，而 Context Engineering 面对的是一个更本质的问题：当 LLM 需要在海量信息中做出准确决策时，我们如何确保它看到的上下文是完整、相关且结构化的？

Agent 上下文管理的核心挑战

1. 上下文窗口的"注意力稀释"问题

尽管主流 LLM 的上下文窗口已经扩展到 128K 甚至 1M token，但这并不意味着填满窗口就能获得更好的输出。研究表明，当上下文长度超过一定阈值后，模型对关键信息的注意力会显著下降——这就是所谓的"Lost in the Middle"现象。

在实际的 Agent 运行中，上下文可能包含：

• 系统提示词和角色设定
• 历史对话记录（可能跨越数小时甚至数天）
• 检索增强（RAG）引入的外部知识
• 工具调用的输入输出结果
• 中间推理链和草稿内容
• 用户画像和偏好设置

如何在这个多维度的信息空间中动态组织和优先级排序，是 Context Engineering 要解决的首要问题。

2. 动态上下文的实时性约束

Agent 系统往往是实时运行的——用户期望在秒级内获得响应。这意味着上下文检索、压缩和重组不能成为性能瓶颈。一个典型的 Agent 执行循环中，上下文管理的时间预算通常只有总延迟的 10-20%。

这要求我们在设计上下文管道时就必须考虑：

• 预计算和缓存策略
• 索引结构的增量更新
• 近似检索与精确检索的混合使用
• 预取和预热机制

3. 多轮推理的上下文一致性

当 Agent 执行一个跨越数十步的复杂任务时，需要确保每一步都能引用之前步骤的关键信息，同时避免被过时或无关的中间结果干扰。这本质上是一个"可変记忆管理"问题：什么该记住、什么该遗忘、什么该摘要化。

四层上下文架构模型

基于生产环境的实践经验，我们提出一个四层上下文架构模型：

第一层：持久化语义层（Persistent Semantic Layer）

这一层存储的是相对稳定的信息：

• 领域知识库：结构化的业务规则、术语表、最佳实践
• 用户长期偏好：交互历史中提炼出的稳定偏好模式
• Agent 自身能力描述：工具列表、能力边界、已知限制

这一层通常通过向量数据库或图数据库实现，支持高效的语义检索。

第二层：会话状态层（Session State Layer）

这一层管理当前会话的动态状态：

• 当前任务的执行进度和中间结果
• 待确认的用户决策点
• 工具调用的上下文和返回结果
• 错误历史和恢复状态

这一层通常使用结构化的键值存储或文档数据库，支持原子更新和事务一致性。

第三层：活跃工作层（Active Working Layer）

这是直接送入 LLM 上下文窗口的内容，需要精心编排：

• 经过筛选和摘要的历史信息
• 当前步骤最相关的知识片段
• 格式化的工具输出
• 动态生成的辅助信息（如计算结果、数据摘要）

这一层的核心设计原则是"恰好够用"——不多不少，确保关键信息不被稀释，同时不浪费宝贵的 token 空间。

第四层：实时获取层（Real-time Retrieval Layer）

这一层在 Agent 执行过程中动态获取信息：

• API 调用的实时结果
• 数据库的最新查询结果
• 外部系统的状态变更
• 流式数据的窗口聚合

这一层的设计要点是缓存策略和一致性模型的权衡。

上下文工程的五个核心模式

模式一：渐进式披露（Progressive Disclosure）

不是一次性将所有信息注入上下文，而是根据 Agent 当前所处的执行阶段，逐步披露相关信息。比如一个代码审查 Agent：在初步扫描阶段只需要文件结构和变更摘要，在深入分析阶段才需要完整的代码内容和测试结果。

模式二：摘要金字塔（Summary Pyramid）

对历史信息进行多层次摘要：

• 最近 5 轮对话：保留原文
• 5-20 轮：压缩为关键决策点摘要
• 20 轮以上：仅保留主题标签和核心结论

这样可以在有限的上下文窗口内保留最大信息密度。

模式三：注意力锚点（Attention Anchoring）

通过结构化格式和关键信息高亮，引导模型的注意力分布。实验证明，将关键约束条件放在上下文开头和结尾、使用标记符号（如 [CRITICAL]）标注、以及采用表格形式组织对比信息，都能显著提升模型对关键信息的利用率。

模式四：上下文压缩蒸馏（Context Distillation）

当检索结果或历史对话过长时，先使用轻量级模型对内容进行预压缩，提取与当前任务最相关的片段，再将压缩后的结果送入主模型。这种方法可以将上下文量减少 60-80%，同时保留 95% 以上的有效信息。

模式五：自适应上下文窗口（Adaptive Context Window）

根据当前任务的复杂度和紧急程度，动态调整上下文窗口的分配策略。对于简单查询，使用最小上下文以降低延迟和成本；对于复杂推理任务，扩展上下文以容纳更多支持信息。

生产环境的可靠性保障

上下文质量的监控指标

在监控 Agent 系统时，以下指标能够反映上下文管理的质量：

• 上下文命中率：上下文中的信息被模型实际引用的比例
• 信息密度：每 token 承载的有效信息量
• 检索精度：召回的上下文片段与任务的相关度
• 上下文延迟：从请求到上下文就绪的时间

混沌工程测试

通过故意制造上下文异常来测试 Agent 的鲁棒性：

• 注入不相关的上下文片段
• 模拟关键信息的缺失
• 测试超长上下文的处理能力
• 验证上下文不一致时的恢复机制

回滚与版本控制

上下文配置也需要版本控制——当新的上下文策略导致输出质量下降时，能够快速回滚到上一个稳定版本。这要求我们将上下文模板、检索策略和权重参数都纳入版本管理。

未来展望：从被动管理到主动构造

Context Engineering 的下一阶段是主动上下文构造——Agent 不仅仅是接收和管理上下文，而是能够主动预测在即将执行的步骤中需要什么信息，提前获取并组织好。

这种"前瞻性上下文管理"需要：

• 对任务流程的深度理解和预测能力
• 对模型注意力模式的事先了解和利用
• 对信息来源可靠性的实时评估

当 Agent 能够像经验丰富的专家一样，知道"在问这个问题之前需要先查什么"，我们就真正实现了从工具到伙伴的跨越。