CompactionBench / APEC：稳定前缀、异步消费与多轮评测单位

CompactionBench / APEC：稳定前缀、异步消费与多轮评测单位

知识轴：context management / harness-runtime / benchmark-evaluation；关联sandbox-security的答案隔离。 官方2026-10预印本，今天发现非今日首发。已读15页PDF的主文机制/实验、附录A和B的模型适用范围；没有运行作者harness、任务容器或模型。contested仅指§5.1原文保留尾部预算的表达未对齐，见末节，不否定全部方法。

为什么对用户重要

Context-Engineering已有“压缩后续跑”和“摘要实际被消费”的门，但把摘要搬到后台不自动保住prefix cache。如果每次仍重写早期摘要，云端API会重复付缓存未命中的输入费用。APEC把时间调度和prompt布局联合设计；CompactionBench则问评测是否真正触发了多次压缩，而不是只用了一个名义很长的任务。这对Hermes长任务/cron和内部coding评测都比单看摘要压缩比更有价值。

生产观察不能误读为压缩的因果成本

作者分析2026-06的13.5M Copilot sessions、3.2M users、约760M调用；发生压缩的session占7.8%，却占44.2%总token。44.2%是这些长session的消耗，不是摘要本身吃掉44.2%。 样本中的压缩事件中位占所在turn时间约22%；事件前后cache-hit分布及配对下降另统计。不能用两个边际中位数之差替代配对下降的中位数，也不能将该生产样本外推本机账单。

一阶机制：稳定前缀只是一个epoch内的保证

1. 连续分段，而非反复重写总摘要。 同步单体方案用一份新摘要替掉旧历史；APEC保留system + 已有摘要prefix + raw tail。完成段的摘要追加到prefix，先前摘要不变，让缓存可复用的连续前缀保留。
2. 后台准备不等于已受益。 软阈值时固定snapshot/覆盖边界并在后台摘要，前台仍执行；完成后才应用，并保留未被覆盖的raw tail/新消息。准备、完成、应用及首次请求消费须分记。论文成本模型对“已启动但会话结束前未应用”的摘要也收费，不能只统计成功消费的工作。
3. 有硬上限，也有同步回退。 达硬阈值而仍需腾空间时同步压缩；prefix自己长到限制后不再持续后台追加，最终同步全文压缩并开启新的append-only epoch。不是无限不失效的KV cache，更不是零阻塞保证。
4. 阈值基于输入余量。 主实验窗口400K、输出预留128K，50%/90%按剩余空间算；本轮Python复算分别136,000/244,800 tokens，不是模型标称窗口的一半/九成。摘要output cap、实际保留summary、raw tail和旧prefix/快照后增长是不同预算。

缓存获益还依赖provider的缓存粒度、TTL、路由和实际cache-hit；工具输出噪音、摘要新增token和后台调用争用可能抵消收益。与bud-contextcompact-reasoning-headroom-and-budget-boundaries互补：Bud突出推理余量和时限；APEC突出保留前缀的布局与启动/应用分账，二者不是同一实现或用户实例实测。

CompactionBench：评测单位是持续的release transition

• 不是堆长prompt。 从SWE-EVO的release/changelog拆出预先固定的依赖需求序列，在同一仓库工作树、同一会话中逐条实现；后续需求不随某个agent的轨迹临时生成。仅单次自主运行、初始长输入或反复“继续”未必产生持续增长—压缩循环。
• 实际规模。 主表8个release transitions、4个仓库、315个changelog items；items是一个transition中的连续用户请求，不是315个独立任务。各配置5次重复；这些重复和同session内事件不能都当独立样本。
• 最终判分。 附录A用最终累计source patch跑仓库测试，并按测试数量加权；排除agent改动的tests。77.95%是作者的accuracy口径，不能改写成“77.95%的release任务全部完成”，还应另报逐需求/逐release通过与中途回归。
• 答案隔离。 作者发现原环境能从git history/tags找target-release代码，于是重建镜像去历史/refs。该修正只关闭本地答案通道，不证明网络、挂载、构建缓存、工具元数据和模型记忆全部无泄漏；测试文件不让agent修改也不等于判分器不可被影响。与Agent-Benchmarks的hidden verifier与通道审计共同验收。

结果读法：比较基线必须写在每个收益旁

主表GPT-5.6 Sol、固定harness，跨任务/重复统计；以下是作者表3，非Hermes实测：

按表中四舍五入值Python复算：APEC相对Sync-H成本下降约25.35%、accuracy增加8.66pp；相对Sync-L时间下降约9.59%。不能合写成“相对同一基线同时省25%钱和10%时间”；PEC成本更低，另一个Prune-H基线更快，APEC不是每个指标第一。简单Async-L与APEC的不同也说明异步本身不等于渐进布局的全部效果。作者未在所读结果中给出足以复核统计显著性的逐trial数据，运行轨迹/工作量又会受策略影响，不把汇总值当普适因果增益。

给Hermes / llm-wiki的最小实验合同

1. 先做离线固定序列，不直接改生产压缩器。 从获准仓库历史生成BASE与预固定后续需求，隐藏GOLD/verifier并清理history/refs；采用同模型、同输出余量、同总deadline和测试权重，对同步/单体异步/渐进候选多次比较。
2. 恢复边界用可验证ID。 snapshot版本/覆盖末项、保留tail、新消息和重置epoch绑定；验无漏消息、无重复消费、工具call/result成对、最新需求/来源权限不被摘要覆盖。按trace-boundary-paired-continuation用同边界续跑与独立业务状态验收，不只抽查摘要。
3. 成本看完整账单。 包含后台已启动未应用/取消摘要、重试、实际cache-hit、前台排队和硬阈值同步回退；同时报逐task全通过、测试加权通过、墙钟分布及总API费用，保留原始汇总口径。
4. wiki低风险落地是改检索词/候选合同。 新增stable-prefix epoch / 稳定前缀周期、started vs consumed compaction / 已启动与已消费压缩、release-transition vs test-weighted accuracy / 发布迁移任务与测试加权准确率。来源标签与摘要分离，不把旧授权摘要当当前权限。

原文歧义、证据缺口与边界

§5.1同时给出summary cap 20K、H = 40K − S (at most 20K)，而§4定义S为实际摘要长度、H为raw-tail预算；未说明哪种附加限制令该上界成立。不能擅自“修正”为某个默认H，也不据此否定表3。复现前要核实际代码/配置的summary cap、retained size和tail clamp。PDF数学字体/双栏抽取有警告，原PDF已保留，公式并未全量重推；本轮只对清楚可读的表3数值和触发公式复算。

本轮未定位并审计作者专用实现/逐trial材料，官方页面没有提供足以在本轮独立重放的运行包；不等于全网不存在代码。不能将OpenClaude引用仓库当APEC已开源实现，也不为此安装本地模型或修改Hermes。安全权限、相同任务、缓存收费和真实终态仍是采纳门，而非某个固定阈值。

写入记录

• 2026-10-27 09:09 CST：深读官方预印本机制/表3/附录A，归档PDF原件与文本；沉淀稳定prefix epoch、后台启动/消费成本与release/test评测分母，复算收益和阈值并保留tail预算歧义。