从Context Rot 到上下文工程：生产级 AI Agent 的上下文基础设施设计

摘要

AI Agent 在生产环境中的失败，多数时候不是模型能力不够，而是上下文设计出了问题：给得太少，Agent 凭空猜测；给得太多，触发 context rot，注意力被噪声淹没；切割方式不对，任务边界模糊，模型在错误的信息邻域里做决策。提示工程解决的是“怎么问”，上下文工程解决的是“模型在每一步看到什么、何时看到、以什么结构看到”。本文把上下文工程当作一项独立的系统工程问题来处理：先分析上下文失效的机制，再给出五条可操作的质量标准，然后展开两条核心工程路径——渐进式披露与 ACE 动态演化框架，最后讨论评估与落地中的关键权衡。目标是给出一套可以在生产系统中直接参照的设计语言，而不是又一篇 prompt 技巧合集。

一、为什么提示工程不够用了

单轮问答的场景里，把提示词写得清晰、加上 few-shot 示例，确实能显著改善输出。但当一个 LLM 被嵌入到多步编排的 Agent 中——规划二十步工作流、调用外部工具、维护跨轮次状态——单个提示词已经无法承载所有必要的约束。一个二十步的 Agent 在第 15 步时“忘记”第 3 步的关键约束，不是因为模型理解不了那条约束，而是因为那条约束在上下文中的“有效可见性”已经衰减到了阈值以下。

更棘手的是，更长的上下文窗口并不自动意味着更好的上下文利用。研究反复观察到一种跨模型普遍存在的现象：随着上下文 token 数增长，模型对上下文中信息的召回准确率持续下降，关键信息的位置逐渐“腐烂”，模型的注意力无法有效覆盖全部内容。这就是 context rot。同时，“lost in the middle”效应意味着即便窗口足够大，模型对上下文中段的注意力也显著弱于首尾。把 50 个文档全部塞进去，指望模型自己挑出相关的 3 个，在注意力分布不均匀的现实下是一种赌博。

由此可以提炼出一个根本性的视角转换：上下文不是一段静态文本，而是一条动态管道。上下文工程的设计目标，用一句话概括是：“让模型在任意时刻看到的上下文窗口，恰好包含完成当前步骤所需的全部信息，且不多也不少”。

二、上下文质量的五条标准

要把“恰好够用”从直觉变成可操作的工程目标，需要一组可检验的质量维度。近期的工作提出了五条生产级标准：相关性、充分性、隔离性、经济性和来源可追溯性。这五条标准构成了一个互相约束的系统：

相关性要求进入上下文的每一段信息都与当前决策步骤直接相关，而不是“可能有用”。向量相似度检索返回的结果“相似”不等于“相关”；相似性度量的是语义距离，相关性判断的是对当前任务的信息增益。交叉编码器重排之所以必要，正是因为它把查询和文档放在一起联合阅读，捕捉的是任务层面的匹配，而非表面语义的接近。

充分性是相关性的对偶约束：如果关键信息缺失，模型不会停下来提问，而是会“合理地猜测”。Agent 的失败模式中，沉默的幻觉往往比显式的错误更危险。充分性要求设计者对“完成当前步骤所需的最小信息集”有明确的判断，而不是把充分性外包给模型自己去发现。

隔离性处理的是多任务、多 Agent 场景下的边界问题。在同一个上下文窗口中混入多个任务的中间状态，等同于在信号中注入结构化噪声。子 Agent 架构和独立上下文窗口的价值不在于“分担计算”，而在于强制隔离：每个决策单元只看见属于自己的信息邻域。

经济性是 Token 成本和延迟约束的直接映射。但经济性不应被理解为“尽量少给”，而应被理解为“不为未被使用的可能性付费”。把静态指令前置并通过 prompt caching 缓存，与把动态检索结果按需加载，是两种不同的经济性策略，适用于不同稳定性的信息类别。

来源可追溯性是生产系统中最容易被忽视的一条。当一个 Agent 在第 50 轮做出错误决策时，如果你无法确切知道它当时看到了哪些上下文片段，调试就只能靠猜。给每个进入上下文的条目附加来源、时间戳和版本，不是为了模型的 benefit，而是为了工程团队的可观测性。

三、路径一：渐进式披露——用“索引 + 按需加载”替代前端全量灌注

渐进式披露的核心洞察非常简洁：不要在初始化时加载所有可能相关的东西，而是先给一份轻量索引，让 Agent 在需要时主动拉取。Thoughtworks 在其技术雷达中将这一模式列为上下文工程成熟的关键技术之一：系统从“一个包含所有指令和参考材料的单体提示词”，转向“轻量索引 + Agent 按需检索”。

这一模式在工程上有三个层次。最浅层是元数据先行：每个可加载的资源（文档、工具、Skill）只暴露 50–200 字符的名称、描述和摘要，Agent 基于元数据判断是否需要深入。中间层是分层加载：触发后先返回一个中等粒度的概览，只有在 Agent 明确要求“展开”时才加载完整内容。最深层的即时检索（JIT） 则把外部数据源的查询推迟到真正需要该数据的那一步，而不是在任务开始时预取。

渐进式披露的真正难点不在“按需加载”这个动作本身，而在触发机制的设计。由 LLM 自主判断是否加载某个 Skill，灵活但不可靠：模型可能“忘记”去加载一条关键的安全规则。因此，对于高确定性的约束——安全边界、scope 限制、合规规则——应当使用软件触发的钩子在生命周期事件中强制注入，而不是依赖模型的自觉性。混合使用 LLM-controlled 的语义加载和 software-triggered 的确定性注入，是生产系统与演示系统的分水岭。

四、路径二：ACE 框架——把上下文当作可演化的剧本

渐进式披露解决的是“何时加载”的问题，但没有回答另一个问题：加载进来的策略本身如何随着 Agent 的经验积累而变好。Stanford/SambaNova 在 ICLR 2026 提出的 ACE 框架给出了一个值得认真对待的答案：把上下文当作一本不断演化的策略手册，而非一次性写死的提示词。

ACE 的架构由三个角色协同完成一次“上下文更新循环”。Generator 面对当前查询执行任务；Reflector 对执行结果进行反思，提炼出成功或失败的模式；Curator 将这些反思转化为结构化的增量条目，用确定性的逻辑合并进已有的 playbook。关键在于“增量”和“确定性合并”：ACE 不重写整个上下文，而是只追加和整合经过验证的条目，从而避免了“简洁偏差”——即每次优化都把上下文压缩得太短，丢失了必要的细节和领域知识。

ACE 的工程意义在于，它把上下文从静态配置变成了带有反馈回路的运行时资产。在离线场景中，playbook 可以通过批量任务预训练和精炼；在在线场景中，每一次交互都可以成为增量的来源。这与传统的 prompt 优化有本质区别：prompt 优化是在参数空间之外寻找更好的文本表述，ACE 是在积累一个可审计、可回滚、可迁移的领域经验库。

五、评估与落地：几个容易被低估的工程约束

5.1 基准测试的配置混淆

上下文工程的性能收益很难通过“换一个框架”来获得，因为它高度依赖于具体的工作负载特征。以推理引擎的缓存架构为例：vLLM 和 SGLang 在共享前缀的复用粒度上设计不同，但在默认配置下对比时，chunked prefill 的默认值差异会混淆缓存本身的效果。控制实验表明，在匹配这一设置之后，容量差距的 78% 和延迟差距的 30–67% 可以被消除；真正稳健的差异是等吞吐下 2.4–6.4 倍的尾延迟优势，与缓存感知的请求排序一致。这意味着，在评估任何上下文优化手段时，必须冻结模型、精度、并行拓扑和流量分布，否则得到的数字很可能测量的是配置差异而非架构差异。

5.2 协议层的演变对上下文设计的影响

MCP 2026-07-28 规范将协议核心转向无状态请求/响应模型，移除了 initialize 握手和 session header，服务器可以部署在 serverless 和边缘基础设施上。这对上下文工程的影响是间接但深远的：无状态化降低了 MCP 服务器的运维复杂度，但也意味着跨请求的会话状态必须由 Agent 侧显式管理。上下文工程不能再假设“协议层会帮我保持状态”；记忆、checkpoint 和跨轮次摘要的责任完全回到了上下文管道设计者手中。

5.3 从“优化 Token”到“管理注意力预算”

一个常见的误区是把上下文工程等同于 Token 压缩。压缩当然是手段之一，但评估指标不应止于“省了多少 Token”。更有意义的度量是单位成功任务的有效上下文成本：在给定准确率目标下，每一步决策所消耗的上下文预算，以及这些预算中有多大比例落在模型的有效注意力范围内。选择性检索的实验数据显示，移除噪声上下文后准确率提升 15–30%，Token 消耗降低 20–40%，但真正的收益是可追溯性——你确切知道模型看到了什么，才能系统性地修复失败。

六、结语

上下文工程的本质，是把“模型在运行时看到什么”从一个事后调试问题前移为架构设计问题。渐进式披露提供了空间维度的控制——在每一步只加载当前需要的；ACE 提供了时间维度的控制——让加载进来的策略随着经验演化；五条质量标准提供了判断“好上下文”的坐标系；而配置混淆和协议无状态化提醒我们，上下文管道的性能从来不是孤立的算法问题，它与服务引擎、协议语义和运维约束深度耦合。

一个可操作的起点是：挑一条你最常失败的 Agent 工作流，在每一步记录实际进入上下文的全部条目及其来源，然后问三个问题——这一步真正需要的最小信息集是什么？哪些条目是因为“可能有用”而存在的？如果这一步失败，我能否从上下文中重建模型当时的决策依据？ 这三个问题的答案，比任何提示词技巧都更接近生产级上下文工程的实质。