结论：两组代码检查都是 63/63。一个被要求不写进笔记的历史编号，新机制通过历史工具查回；旧组没恢复，也没有编造。
这是一次能力演示，不是统计 benchmark，不证明新机制全面胜出。实验由 Codex 辅助搭建、执行和整理；包含可离线核对的代码、逐项评分与线上复跑脚本。
- 实验日期：2026-09-07。
- 实际执行客户端：
codex-cli 0.153.4，macOS。 - 模型：两组均为
gpt-6-astra；app-server 返回的reasoningEffort均为low。 - 通过既有 ChatGPT 登录与默认官方 provider 运行，没有自定义模型目录。
- 顺序执行：新机制在前、旧机制在后；每组只有一次。
- 公共设置：workspace-write、approvalPolicy=never，相同任务和继续指令；没有修改真实项目。
- 新组：
features.context_management.experimental_mode=true。 - 旧组：
features.context_management.experimental_mode=false，features.token_budget.enabled=false。 - 使用既有用户配置及指令，不是完全隔离的标准化环境。复跑时工具、模型目录、缓存、服务端更新等可能不同。
术语：“新机制”指笔记＋可检索历史＋不生成摘要的窗口重置；“旧机制”指这里实际触发的远端压缩路径。旧压缩输出可能含加密压缩项，不能简单等同于一段普通文字摘要。
起始文件只有一个错误的 retry_delay(attempt, status, retry_after=None) 函数。
初始用户消息给出以下任务：
- 保持函数签名，只用 Python 标准库。
- attempt 从 0 开始；0–3 可以重试，>=4 返回 None；负数一律先抛 ValueError。
- 只允许 HTTP 429、502、503、504 重试。
- 默认间隔为
min(3 * 2**attempt, 17)。 - 只有 429 使用 Retry-After；严格校验非负数和 ASCII 数字字符串，排除 bool、NaN、无穷大、负数、十进制字符串和 Unicode 数字；合法值封顶 17，零合法，无效值回到默认退避。
- 禁止 sleep、随机性、新依赖和签名变化。
另外给出一条纯合成历史信息：事件 ORCHID-682，关联编号 trace-7ac91e，服务 eu-west-queue-b。要求模型不要把关联编号复制进笔记或阶段 1 回答，可以保存原消息指针。编号与代码实现无关，专门探测压缩/换窗口后的历史恢复能力。
- 阶段 1：读取代码、分析修复、使用可用的机制准备交接；不改代码，不把需求写成本地文件。明确提醒模型维护交接信息，因此不是测试它能否自发记笔记。
- 控制器对同一 task 调用一次
thread/compact/start。新组走无摘要重置，旧组走远端压缩。这里是手动强制触发，不是自然填满长上下文。 - 阶段 2：只要求继续原任务、测试并报告历史编号，不再次给出原始约束或答案。
- 外部 Python 评估器执行 63 个功能/接口检查，再对历史编号做 1 个精确匹配检查。评估器在工作目录之外。63 项不是 63 个独立编程任务。
- 两组各自编写了 8 个 unittest 测试方法，均由控制实验的程序再次运行确认；这些测试另计，不混入 63 项评分。
完整提示词、初始代码和 JSON-RPC 流程均在 run.py。
| 项目 | 新机制 | 旧远端压缩 |
|---|---|---|
| 独立代码与接口检查 | 63/63 | 63/63 |
| 历史编号精确恢复 | 1/1 | 0/1 |
| 模型自建测试，独立复跑 | 8/8 | 8/8 |
| 准备阶段 | 50.34 秒 | 35.77 秒 |
| 窗口重置／压缩 | 1.80 秒 | 27.17 秒 |
| 恢复、实现、测试、回答 | 67.26 秒 | 60.30 秒 |
| 三阶段合计（不含启动） | 119.40 秒 | 123.24 秒 |
新组最终回答包含正确编号 trace-7ac91e。旧组表示编号未保存在 checkpoint，原消息历史读取不可用，无法恢复；没有猜测。
原始累计 usage 的选择字段保存在 comparison.json：新组 inputTokens 226156，其中 cachedInputTokens 211840；旧组 inputTokens 176081，其中 cachedInputTokens 142720。这些是多次请求累计值，不是单次窗口长度。没有独立核算压缩及笔记服务全部计费，不能据此推断费用优劣。
从本地 rollout 提取的记录（comparison.json）：
- 新组：替换记录的 message 为空、无 compaction response ID；新上下文包含 5 个 message 项。换窗口后实际出现
notes.read_file和history.read_item调用，然后回答正确历史编号。 - 旧组：有 compaction response ID；替换内容包含 1 个 message 项与 1 个 compaction 项，说明使用了远端压缩，而不是新组的无摘要重置。
- message 为空本身不能区分策略，因为加密压缩路径的文本字段也可以为空。
笔记正文及一些工具返回内容是加密的，没有独立解密。因此严谨表述是“要求模型不把编号写进笔记，并观察到重置后的历史读取及正确回答”，而不是声称已逐字审计服务端笔记、证明答案只能来自某一个渠道。
**对照中的辅助记忆差异：**旧组自主调用了 code-mode 的 store/load 保存、核对 checkpoint。它没有原生 notes/history 调用。所以这是实验开关开/关后的真实行为对照，不是禁绝一切辅助记忆的纯摘要算法比较。其阶段 1 和阶段 2 原样回答收录在 artifacts.json。
能说明：在这次 Astra low 试验中，新机制顺利交接代码任务，并展示了通过历史读取补充交接信息的能力；旧机制在代码正确性上没有落后。
不能说明：
- 新机制在所有任务中更准确、更快、更便宜。
- 开启后 GPT 不会忘记要求，或能同时看到全部历史。
- 多次跨窗口、数小时工程任务、自然达到上下文上限时也能稳定保持同样效果。
- 模型在没有提示的情况下会及时记笔记，或会意识到所有遗漏的约束并主动查找。
- 一次 1/1 与 0/1 是可泛化的恢复率。
此前还有一次 medium 新机制测试；用户随后要求使用 low，medium 的旧组被中断。medium 不进入这张对照表。
artifacts.json：两组实际代码、模型自建测试、两阶段回答、逐项评分。comparison.json：按白名单提取的模型、推理级别、耗时、累计用量、调用序列和压缩记录。evaluate.py：原实验使用的独立评估器。verify_saved_results.py：将已发布代码放到临时目录，离线复跑测试并核对评分；不调用 API。run.py：原 low 试验控制脚本，可尝试线上复跑。依赖已登录且支持实验功能的 Codex CLI、Python 3、可用的 notes/history 后端；使用现有用户配置，会消费模型用量、创建测试任务和合成笔记。
将 gist 文件下载到一个新的空目录后：
# 离线核对已发布的结果，不消费模型用量
python3 verify_saved_results.py
# 可选：重新进行线上实验，结果可能变化
python3 run.py new old
python3 evaluate.py线上脚本会在当前脚本目录创建 new/work、old/work 及本地日志。不要放进真实项目目录运行；保留工作目录隔离。脚本没有更改用户全局配置，试验设置通过 thread/start 覆盖。新旧版本接口或模型可用性变化可能需要调整脚本。
隐私处理：不发布完整 rollout、thread/start 返回值、账户信息、登录配置、本地绝对路径、会话标识、加密笔记载荷或无关工具日志。comparison.json 是提取数据，不冒充完整原始网络记录。线上复跑产生的本地原始日志也不应直接公开。
代码检查的仓库快照是 694b6319d3（2026-09-07）；实际执行二进制是 0.153.4，两者不能当作同一构建。实际行为判断以本次运行记录为准。