跳转到主要内容

长程处理将上下文管理变成调度问题

更大的上下文窗口并不能消除限制;它把上下文组装变成了一项调度决策:加载什么、何时加载、以何种成本加载。

昏暗数据中心里服务器机架的近景,成排的指示灯和整齐布线的线缆。

误读

当模型的上下文窗口扩大时,本能反应是把限制当作已经解决。窗口变成了一个桶:把所有东西都放进去,让模型自己去理清。这是对窗口用途的误读。窗口不是检索纪律的替代品;它是一个形状不同的预算。

对无关历史的注意力并非中性。每一个存在但不相关的 token 都在争夺注意力权重,随着信噪比下降,模型的决策质量也随之退化。这种效应不是一道硬悬崖,而是一个斜坡。一个在紧凑上下文中本应正确的运行,当同一查询被无关材料填充后,会变得听起来合理但实际错误。失败模式是安静的:模型仍然产出流畅的输出,因此只有当输出与真实基准核对时,退化才可见。

调度上下文

重新框定很简单:上下文组装是一个调度问题。问题不是“我们能装多少”,而是“当前步骤需要什么,以及何时需要”。调度器决定加载什么、何时加载、以及驱逐什么。应用到 agent 运行中,这意味着把运行分阶段,每个阶段都有明确的上下文契约。

只加载当前步骤所需的内容

一个步骤应当只接收它所需的材料,别无其他。在实践中,这意味着上下文构建器不是拼接器;它是一个带清单的选择器。每个步骤声明其输入:一个 schema、一个检索查询、一组先前的工具结果、计划的一个切片。构建器根据运行的状态存储解析这些声明,并组装满足契约的最小上下文。

一个具体机制:带类型化条目的逐步上下文清单。

{
  "step": "reconcile_invoice",
  "requires": [
    {"type": "artefact", "id": "invoice_4417", "max_tokens": 1200},
    {"type": "tool_result", "id": "ledger_lookup", "freshness": "current"},
    {"type": "policy", "id": "ap_policy_v3", "pinned": true}
  ],
  "excludes": ["chat_history_older_than_phase", "raw_pdf_bytes"]
}

Close-up of a microscope objective lens in a laboratory

构建器解析此清单,截断超出预算的材料,并记录它加载了什么。正是这份记录使运行可审计:当一个步骤产生错误答案时,第一个问题是所需材料是否存在,而不是模型是否有能力。

显式地提升与降级

长运行倾向于默认累积上下文。每个阶段追加其输出,窗口被运行自身的历史填满。替代方案是在阶段之间显式地提升和降级。在阶段边界处,运行写入一个摘要材料,并降级它所摘要的原始材料。下一阶段从摘要开始,而不是从完整记录开始。

这是一个有成本的调度决策。摘要会丢失细节;被降级的材料之后可能仍需要,重新获取它要付出一次工具调用和延迟。这种权衡是真实的:激进的降级保持上下文紧凑,但有丢失关键细节的风险。缓解办法不是保留一切;而是让降级可逆。被降级的材料留在运行的存储中,已索引且可检索,因此后续步骤可以按需将它们提升回来。窗口保存工作集;存储保存归档。

检查点状态,使长运行可以恢复

一个无法恢复的长程运行,就是一个在任何中断后都必须重放其完整历史的长程运行。这种重放代价高昂,更糟的是,它重新引入了调度器本就是为了避免的噪声。在阶段边界处对状态做检查点,将运行的时长与其上下文大小解耦。

检查点应捕获足以在无完整记录的情况下恢复的内容:计划及其当前位置、到目前为止产出的材料(按引用而非按值)、仍然有效的工具结果,以及每个已完成步骤所消耗内容的清单。恢复时,调度器从检查点加上该步骤清单所要求的内容,重建当前步骤的上下文。运行的历史可供审计,但默认不加载到窗口中。

这正是调度框架的价值所在。没有检查点,长运行的上下文是Close-up of a white Thai keyboard on a wooden desk showing keys and texturesedia/server-rack-closeup-dark-d40599-0ca2dd.jpg)

评估含义

如果上下文是被调度的,那么单一的聚合成功率就是错误的评估单位。一个在视野 5 成功、在视野 50 失败的运行,不是一个 90% 的系统;而是一个具有视野相关失败画像的系统。聚合掩盖了形状。

评估应当报告成功率作为视野长度的函数。具体而言:以步骤或工具调用定义视野,在递增的视野上运行同一任务族,并报告曲线。成功在哪里保持,在哪里弯曲,弯曲处发生了什么变化?一条先平坦、然后在特定视野处下降的曲线,指向调度失败:某个阶段边界处所需材料被降级、某个检查点遗漏了字段、某个清单对其输入说明不足。

这也让权衡变得可见。更激进的降级策略可能改善每步成本,同时使弯曲点提前。更宽松的加载策略可能延长视野,同时提高开销。两者孤立来看都没有错;曲线才能告诉你你拥有的是哪一种。

同样的纪律适用于源材料。关于长程能力的声明应当被读作关于曲线的声明,而非一个点。一个对长程任务报告单一数字的系统,报告的是它尚未刻画的分布的平均值,而该分布中有趣的部分是尾部。

这在实践中改变了什么

把上下文当作调度问题,会改变 agent 代码库中的三件事。上下文构建器变成带清单的选择器,而非拼接器。阶段边界变成显式的提升与降级点,并有一个使降级可逆的存储。运行状态被检查点化,因此恢复不意味着重放。

这些都没有消除上下文限制。它改变了限制所约束的对象。它不再约束一个运行能有多长,而是约束调度器将上下文与步骤匹配得有多好。这是一个更易处理的问题,也正是长程处理实际提出的问题。

封面照片:panumas nikhomkhai / Pexels。

分享XLinkedIn永久链接5 分钟阅读

相关阅读

这能回答的问题

Does a larger context window remove the need for retrieval discipline?

No. A larger window raises the ceiling on what can be loaded, but attention over irrelevant history still degrades decision quality and increases compute per step. The window changes the budget, not the need to select.

What does it mean to schedule context in an agent run?

It means each step declares a context manifest of the artefacts it needs, the builder resolves that manifest against the run's state store, and phase boundaries promote or demote context explicitly rather than accumulating history.

How should long-horizon agent performance be evaluated?

Report success as a function of horizon length rather than a single aggregate number. The curve shows where performance holds and where it bends, which points at scheduling failures such as demoted artefacts or incomplete checkpoints.

What is the trade-off in aggressive context demotion?

Demotion keeps the working set tight but risks losing detail a later step needs. The mitigation is reversible demotion: demoted artefacts stay indexed in the run's store and can be promoted back on demand.