WeChat (把酒聊AI 公众号)
ai-engineering
Original source

1M 额度爆炸、256K 频繁丢三落四：我们为什么要给长任务 Agent 建立”上下文稳态”？

Summary

深度技术文章，讨论长任务 Agent 的”上下文稳态”（Context Steady State）架构设计。基于 San Agent 项目（omp fork）的实践总结。

核心问题

长时间运行的 Agent（代码编写、深度调研、数据分析）在数百次工具调用、多次上下文压缩后，会丢失关键信息。三个悖论：

  1. 1M 窗口悖论：能装下 ≠ 适合一直装。400K 后注意力分散、降智、走捷径
  2. 256K 窗口悖论：压缩续命但逐次失真，压缩3-4次后开始丢重要约束（有损变换的复利放大）
  3. 长 Agent Turn 悖论：上下文涨到100%+但 auto compact 迟迟不触发

四层通用数据架构

将”系统记得”与”模型此刻看见”解耦，分为四层管理。

七个核心控制机制

  1. 黄金工作窗口：240K 为默认基准，保留 20-25% Reserve，跨阈值后锁存进入稳态模式
  2. TurnDigest + Checkpoint：结构化状态记录（意图/动作/决策/产物/证据/风险/下一步），Append-only 账本
  3. Continuation Authority：摘要只能讲历史，不能定义当前 Goal。用户 Entry 是唯一权威
  4. Segment 是维护边界不是压缩按钮：15分钟或固定 Token 增量仅写 Checkpoint，不触发压缩
  5. Mid-run 有界恢复：遇硬压力才执行 compact→coverage rebuild→replan→replay，用 maintenanceId 防抖动
  6. Tool Progress Guard：按证据增量判断进展，识别”忙碌但无新证据”的死循环
  7. Probe 观测：独立 Sidecar 记录 Token 使用率、缓存读写比、前缀指纹、循环收敛状态

基准收益（2026年7月测试）

  • -80.9% 活跃上下文：L5 超长任务（180步/1080次工具调用）从 355K Token → 68K Token
  • -68.3% Prompt Tokens
  • -47.5% 估算成本

真实事故复盘

一次会话中 Segment 错误绑定为强物理压缩 → 摘要从外部日志吸收不相关任务升级为 Goal → Agent 连续 981 次无效工具执行 → 消耗超 1.83M Token。修复方案：

  • Segment 只写 Checkpoint，真实容量压力才物理压缩
  • 用户 Journal Entry 是唯一 Goal 权威（摘要降权）
  • 基于动作+证据指纹识别跨步骤循环
  • 用户新输入无条件最高优先级抢占

核心观点

“更大的上下文窗口最好的用途是提供弹性，而不是鼓励堆积。真正决定 Agent 任务上限的，不是一次能塞多少 Token，而是系统 Harness 能否在每次历史增长、压缩、纠正和恢复后，让 Agent 回到高可信的稳态。”