Slipstream：轨迹锚定的异步压缩验证——让 Agent 上下文管理不再靠猜
同步压缩的结构性缺陷
现在的 Agent 框架——Claude Code、LangChain、Microsoft Agent Framework——都在用一种看起来理所当然的方式管理上下文：同步压缩（Synchronous Compaction）。
流程很简单：Agent 执行到一定步数，上下文开始膨胀，系统暂停 Agent，调用一个 LLM 把累积的轨迹"总结"成一段精炼的摘要，然后用摘要替换原始上下文，Agent 继续执行。Anthropic 甚至建议在 5-20k tokens 时就触发压缩，而不是等到上下文窗口快满。
这听起来没问题——压缩不就是个性能优化吗？但实际上，同步压缩有一个根本性的结构缺陷，它不仅仅是慢，更重要的是它会静默地损坏 Agent 的准确性。
问题出在哪里？两个层面。
第一，预测盲区。压缩器必须在不知道 Agent 未来需要什么信息的情况下，决定保留什么、丢掉什么。"判断什么信息对后续推理有用"这件事，正是我们雇佣 Agent 自己去发现的过程——压缩器不可能提前知道。
第二，不可自查。一旦摘要替换了原始上下文，Agent 的后续每一步都受这个摘要条件化。如果摘要错了，Agent 的行为会在错误的方向上保持一致——看起来逻辑自洽，实际已经走偏。更致命的是，因为没有参照系，系统无法检测这个错误。它只能等到最终结果出错才发现问题，而那时已经太晚。
这就是所谓的结构性验证缺口（Structural Validation Gap）：同步压缩让 Agent 的后续行为无法作为摘要质量的独立检查。
三类沉默失败
论文从真实的 Agent 轨迹中提取了三类压缩失败模式，其中省略型占 ~90%：
- 省略（Omission）：摘要丢弃了 Agent 后续需要的信息。例如一个搜索任务中，摘要静默地丢弃了三个候选中的正确答案"Tom"，Agent 永远不再验证它，最终给出错误答案。
- 捏造（Commission）：摘要引入了原始上下文中不存在的错误信息。例如将"只从 a.py 删除函数"扭曲为"从所有文件删除函数"——Agent 照做，代码崩溃。
- 组合错误：丢弃正确实体并替换为虚假实体。例如把"Tom Thumb"替换为不存在的"Jeffrey Hudson"，Agent 沿着错误线索搜索，永远无法恢复。
关键是，现有评估指标——faithfulness、coverage、QA-probe、ROUGE——都无法捕获这些错误。它们要么假设所有事实同等重要（但 Agent 只需要其中一小部分），要么需要参考摘要（但压缩没有"标准答案"）。缺少的维度是充分性（Sufficiency）：压缩后的上下文是否保留了 Agent 沿原始轨迹前进所需的信息？
异步压缩：唯一的答案
Slipstream 的核心洞察非常精妙：异步执行是唯一能产生独立验证信号的压缩模式。
思路是这样的：当触发压缩时，不让 Agent 停下来等。让 Agent 继续在原始上下文中执行，同时压缩器并行运行。因为两者从同一个前压缩状态出发，所以：
- 候选摘要和 Agent 的 next-k 步是独立生成的
- Agent 的后续行为不受摘要条件化
- 两者可以做独立的交叉验证
这就是"同源异路"（same pre-compaction state, independent generation）的精髓。
⚠️ Agent 暂停"] B1 --> C1["压缩器运行
（占用关键路径）"] C1 --> D1["摘要替换上下文"] D1 --> E1["Agent 继续
❌ 已受摘要条件化
❌ 无独立验证信号"] end subgraph "Slipstream 异步压缩" A2["Agent 执行"] --> B2["触发压缩"] B2 --> C2["Agent 继续
（原始上下文）"] B2 --> D2["压缩器并行
（不在关键路径）"] C2 --> E2["生成 next-k 步
✅ 不受摘要条件化"] D2 --> F2["候选摘要"] E2 --> G2["Trajectory-Grounded Judge
双重验证"] F2 --> G2 G2 -->|"Accept ≥7分
（91-99%）"| H2["采纳摘要 + next-k"] G2 -->|"Reject
（1-9%）"| I2["针对性修复"] end style E1 fill:#ff6b6b,color:#fff style C2 fill:#51cf66,color:#000 style G2 fill:#339af0,color:#fff
Judge 的双重验证
Slipstream 的 Judge 做两件事：
- 意图对齐检查（Plan-level）：摘要是否支持与原始延续相同的 forward intent？目标：防止"结构性漂移"——比如从"只改 a.py"变成"改所有文件"。
- 事实保留检查（Statement-level）：Agent 依赖的具体事实、约束、中间结果是否在摘要中保留？目标：防止"内容错误"——比如遗漏或替换关键实体。
两部分各打 0-10 分，总分 = 平均，≥7 分通过。
一个关键问题是：只看 next-k 步够吗？答案是 够。压缩错误的首次暴露有极强的局部性：
- BrowseComp：97% 在 k=1 暴露，100% 在 k=2
- SWE-bench：60% 在 k=1，88% 在 k=3，96% 在 k=6
Slipstream 的平均异步窗口是 2.1-3.7 步，恰好覆盖绝大多数错误。
实验数据：12/12 全胜
在两个长周期 Agent 基准上的结果：
| 基准 | 模型 | 阈值 | Sync | Slipstream | Δ |
|---|---|---|---|---|---|
| SWE-bench | Qwen3.5-9B | 4k | 23.4% | 29.8% | +6.4 |
| SWE-bench | Qwen3.5-9B | 6k | 22.0% | 30.8% | +8.8 |
| SWE-bench | Seed-OSS-36B | 4k | 29.6% | 35.8% | +6.2 |
| BrowseComp | Qwen3.5-9B | 32k | 53.3% | 57.3% | +4.0 |
| BrowseComp | Seed-OSS-36B | 16k | 46.7% | 48.7% | +2.0 |
所有 12 个配置组合（2 个模型 × 2 个基准 × 3 个阈值）全部提升。
延迟方面，同步压缩占端到端时间的 26-44%。Slipstream 将压缩移出关键路径后，延迟降低 11.3-39.7%，阈值越小（压缩越频繁）收益越大。
最关键的消融：Async-only = 零收益
这是整篇论文最重要的消融实验：
- Async-only（只异步重叠，不验证，直接采纳摘要）：保留了全部延迟收益，但准确率与同步压缩持平——静默采纳了所有损坏的摘要。
- Full Slipstream（异步 + Judge 验证）：延迟收益保留，准确率 +6.4 ~ +8.8pp。
结论很清楚：准确率提升来自轨迹锚定的验证信号，而非异步执行本身。异步只是前提——它让同源异路的独立生成成为可能——但验证才是价值来源。
Judge 可以用更小的模型
默认配置下 Judge 和 Agent 用同一个模型（方便共享 KV-cache prefix）。但如果换成更小、更便宜的模型呢？
| Judge 模型 | SWE-bench 准确率（4k 阈值） |
|---|---|
| 无 Judge（Sync baseline） | 23.4% |
| Qwen3.5-9B（同模型） | 29.8%（+6.4） |
| Qwen3.5-2B（小模型） | 28.2%（+4.8） |
| Llama-3.2-3B（跨家族） | 28.2%（+4.8） |
小模型和跨家族模型仍然保留了大部分收益。结论：验证信号本身的价值 > Judge 模型的能力。
这对实际部署是个好消息——不需要为 Judge 预留昂贵的算力。
系统设计的优雅之处
Slipstream 的实现充分利用了现代 Agent serving 的结构特性：
- Agent serving 是内存瓶颈，不是计算瓶颈：有效 batch size 远低于算力上限，有充分的 headroom 并行跑压缩器和 Judge。
- 共享 KV-cache prefix：两个线程共享前压缩上下文的 KV-cache，避免冗余的 prefill 开销。
- Judge 输入极轻量：只需要候选摘要 + next-k 轨迹，占前压缩上下文的 3.6-6.8%。
- 拒绝率很低：1.0-3.5%（BrowseComp）和 5.4-8.5%（SWE-bench），大部分摘要直接通过，无需额外开销。
超越压缩：一条通用架构原则
论文在结论中提出了一个比 Slipstream 本身更重要的观察：
"Running auxiliary procedures synchronously on an agent's critical path can foreclose validation signals that asynchrony makes available — a pattern worth examining beyond compaction itself."
翻译一下：在 Agent 的关键路径上同步运行辅助程序，会丧失异步执行可以提供的验证信号。这个模式值得在压缩之外更广泛地审视。
适用场景远不止上下文压缩：
- 工具执行验证：Agent 调用工具后，是否需要一个独立的验证器检查输出？
- 子代理编排：主 Agent 分配子任务时，子代理的输出能否与主 Agent 的预期交叉验证？
- 计划生成：生成的计划是否可以在 Agent 执行第一步的同时接受评判？
- 记忆策展：决定保留/丢弃记忆时，能否参考 Agent 后续行为中实际使用的内容？
核心思想是一致的：任何需要在不确定条件下做出不可逆决策的辅助程序，都应该考虑异步执行以获取独立的验证信号。
对 Hermes 等 Agent 基础设施的启示
Slipstream 对 Agent 基础设施设计有几个直接影响：
- 上下文压缩需要验证层：Hermes 已经使用 compression_threshold 和 auto_prune，但没有验证步骤。Slipstream 的模式可以直接集成——异步运行压缩，用轻量 Judge 验证。
- 验证成本可以很低：2B/3B 模型就能提供大部分收益，甚至在资源受限的环境（树莓派、本地 Mac）上也可行。
- 异步不仅是性能优化：它改变了验证的可行性。把原本不可验证的决策变成了可验证的。
- 设计范式：未来的 Agent 系统应该区分"关键路径操作"和"辅助操作"，后者的默认执行模式应该是异步的，以产生独立验证信号。
局限与展望
Slipstream 没有探索的是：
- Judge 本身的可靠性——Judge 也是 LLM，也会犯错
- 多模态上下文压缩——当前只处理文本轨迹
- 压缩策略的自适应选择——什么情况下该压缩，k 值该设多大
- 多 Agent 场景下的压缩协调
但作为一个原则性解决方案，它回答了一个比"如何更好地压缩"更根本的问题——如何验证压缩是否正确？——并给出了一个优雅的答案：让 Agent 自己去证明。