Codex的滚动窗口上下文在GLM5.3亦适用,附10项DeepSWE测试报告

yu1745 2026-09-12 21:01 1

# Codex最新滚动窗口上下文机制在GLM5.3测试报告


## 主要观察


本次比较Pi Native 原生压缩Pi Smart CompactCodex滚动窗口的Pi实现 在DeepSWE Bench中表现。


滚动窗口指的是在切换前保存 Notes,切换后读取检查点,必要时通过 History 回查旧对话,实现完全复刻自Codex开源代码,并加入了我对OpenAI服务端实现的猜测,因为OpenAI的服务端代码不开源。


共有10项任务取得完整有效的三组结果,另有1项因滚动组异常而不计入总比较。以下结果仅适用于GLM 5.3,上下文召回场景受模型后训练影响非常之深,换一个模型需重测。




  1. 滚动窗口的上下文重置次数更少,且多数任务耗时较短。 10项任务共轮换18次,对应Native压缩30次、Smart配置组压缩27次;滚动窗口在 6/10 任务中Agent耗时最短。猜测任务解决更快的原因是在切换上下文窗口时,滚动窗口机制相比压缩,上下文召回更快。




  2. 完全未观察到滚动窗口导致普遍、明显的任务质量下降,部分场景反而更好。 相比Native,滚动窗口新增测试通过数为3项更高、6项持平、1项较低;相比Smart为4项更高、4项持平、2项较低。完整通过任务数为滚动窗口6/10、Native 4/10、Smart 4/10。反例包括HTTPX流式JSON与HTTPX multipart,说明滚动窗口并非每个场景都更好。




  3. Notes通常足以完成恢复。 18次轮换共成功写入Notes 34次,只调用History 2次,说明模型通常不需要反复读取完整旧对话。所有有效三组的原有测试均全部通过,质量差异主要集中在新增需求实现完整度。




每任务每方案仅运行一次,以上仍是小样本观察。Smart Compact配置为 auto,已核查到的Smart执行模式为 fast,同时存在回退及未标明Smart模式的事件,不能将其视为全部fast或纯EESV实验。


## 图表


### 上下文重置次数



### 完整通过任务数



## 任务结果


表中通过数为新增功能测试;所有已完成组的原有测试均全部通过。耗时为 Agent 执行墙钟时间(含API排队、工具执行,不含容器准备和Verifier),不是纯模型生成时间。



## 项目链接与致谢



  • Smart Compact(本次测试版本):[yu1745/pi-smart-compact]

  • 我的 OpenAI Toolkit Fork:[yu1745/pi-openai-toolkit] 感谢上游:[awoaCrim/pi-openai-toolkit]· 作者:[awoaCrim] 预先完成的所有工作

最新回复 (7)
  • yu1745 楼主 09-12 21:15
    1

    (帖子已被作者删除)

  • Max Verstappen 09-12 21:23
    2

    被人举报是ai了?md格式不太对?用了几个月smart-compact看样子又有新东西换了^-^

  • yu1745 楼主 09-12 21:24
    3

    第一次发帖的时候,不知道为什么我的Markdown粘贴上来之后,格式直接爆炸了 ^-^ 然后我就改了几次

  • ansusu 09-12 21:25
    4

    有具体的报告吗,捞

  • Max Verstappen 09-12 21:27
    5

    看起来不错啊,多多更新^-^

  • ansusu 09-12 21:30
    6

    谢谢佬了,对我很有帮助

  • Rao 09-12 21:48
    7

    为什么完整通过任务数这么差,有点不是很敢相信,有实际的测试题集吗,我目前使用 pi 来说, 完成任务没有什么问题, 由于提示词少,所以流程上需要明确。

* 帖子来源Linux.do
返回