对运行多步任务的 AI Agent 来说，上下文窗口不够用并不是偶发异常，而是一种结构性问题：只要任务足够长、工具调用足够多，历史信息迟早会超出模型可处理范围。近期，Aiden 在其固件更新中公开了一套针对该问题的处理方案，核心不是简单压缩上下文或重新开启会话，而是把任务状态保存到上下文之外，并在恢复前先判断“是否还有足够证据继续”。
两种溢出，都不容忽视
素材显示，Aiden 将长任务中的上下文溢出分为两类。一类是累积型溢出：没有单条特别长的消息，但随着轮次不断累积，历史记录最终超过窗口限制。另一类是单次事件溢出：某一次工具调用返回的内容过大，直接占满可用空间，和此前历史长短关系不大。
这两种情况在生产环境中都无法用简单方式绕过。上下文压缩会减少模型当前可用的信息，本质上是有损操作，不能单独作为继续执行的依据；切换到新会话看似重新开始，但任务信息仍需保留，否则 Agent 也无法真正接续工作。因此，Aiden 选择了第三种路径：把关键任务状态写入保存结果文件，在恢复时再读取。
恢复不是重启，而是三分支决策
这套机制的关键在于，溢出发生后系统不会直接继续，也不会直接失败，而是先进入恢复流程：压缩上下文或切换会话后，读取保存的结果文件，检查其中的 continuation ID、state、errors 和 output tail 四个字段，再判断是否有足够证据安全推进。
如果证据足够，任务恢复执行；如果证据不足或情况不明确，则停止并把问题呈现给用户。这里的设计重点不是“继续或失败”的二选一，而是形成 continue、verify-then-retry、stop-and-surface-to-user 的三分支决策。Aiden 将“不确定”作为独立结果处理，而不是把它混入成功或失败之中。
把任务记账放到上下文之外
为什么不在上下文内部做摘要，而要把状态外置？素材给出的解释是：任务记录属于“记账信息”，例如执行到哪一步、工具返回了什么、哪里出错，这些内容并不是模型推理本身所需的思考空间。如果把记账信息和推理内容放在同一个受预算限制的上下文里，一次溢出就可能同时摧毁两者。
将任务状态外置后，溢出造成的影响主要限于当前推理状态，而不是已经发生的事实。这一点也与业界已有方向形成呼应。素材提到，LangGraph 通过持久化执行检查点保存工作流状态，以便从最近步骤恢复；OpenAI 的会话状态指南也建议使用持久化会话对象，避免每次请求都重新推导上下文。Aiden 的做法更接近检查点模型，但不会完整重放所有内容，而是有选择地读取四个字段。
恢复之后还要重新观察现实
Aiden 的设备交互循环遵循 observe、interpret、act、verify 的概念模式。上下文恢复在这一循环中加入了一个连续性检查：在执行下一步前，先检查持久化证据；对于面向界面的任务，还要重新观察当前界面，而不是盲目信任旧检查点。
- 保存记录代表 Agent 认为发生了什么。
- 新的观察代表当前环境实际是什么状态。
- 两者不能互相替代。
素材还提到，畸形文件和设备状态变化等测试，专门用于暴露那些在演示中看起来正常、但在真实环境下会失败的实现。这意味着该机制关注的并不是理想流程，而是长任务 Agent 在复杂现实环境中的可持续性。
这一方案并没有宣称解决上下文窗口的物理限制，也没有承诺所有任务都能安全完成。它做的，是把“任务执行到一半失去上下文”这一常见失败，转化为基于持久化证据的决策过程。对于需要人类监督的重要操作，系统仍会停下来，把判断权交回给用户。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/zhang-ren-wu-agent-ka-zai-shang-xia-wen-shang-xian-wai
