[性能问题] TokenMeter 在每个会话事件后重建完整快照，导致二次方级性能退化

[ShawnSiao]

• Session 每次 append 都会使快照失效：session/index.ts (line 559)
• TokenMeter 在状态建立后监听每个 session/event 并调用 _sync()：token-meter/index.ts (line 95)
• _sync() 循环中反复读取 session.events，导致每次重新复制完整日志：token-meter/index.ts (line 160)
• 每个模型分片都会追加 assistant/chunk：agent.ts (line 349)

实测结果：
events inactive meter active meter
8,000 162 ms 215 ms
16,000 246 ms 404 ms
32,000 476 ms 1,657 ms
32K 时 active/inactive 已达到约 3.5 倍，并呈现二次方增长。

设计建议：

• session/event 已经携带当前 event，监听器应直接 _foldEvent(session, state, event)。
• 仅在 seq 不连续、冷启动或补偿读取时调用完整 _sync()。
• 或给 Session 增加 eventAt() / eventsSince()，避免通过完整防御性快照读取单个事件。

验收标准：

• 事件数量翻倍时，append 总耗时不应超过约 3 倍。
• 保留已有 replay、replacement、source provenance 测试。
• 新增默认 Bundle 下 meter 已激活的性能回归测试。

[DRAG0NM]

已定位根因：长会话（大量 assistant/chunk）下 TokenMeter 产生 O(n²) 退化：每次 session.append 都会使 session.events 快照失效（eventsSnapshot = undefined），而 TokenMeter 的 session/event 监听器只取 session 参数、**… 完整源码定位与修复方案见 #928 。

[TTTPOB]

#928 (comment)

[ShawnSiao]

可选修复方案
方案 A：直接消费 session/event 携带的事件，推荐

监听器已经能获得当前事件：
`ctx.on('session/event', (session, event) => {
const state = this.states.get(session)
if (state === undefined) return

if (event.seq !== state.consumedEvents) {
this._sync(session)
return
}

this._foldEvent(session, state, event)
state.consumedEvents += 1
})`

同时在 ReplayState 中暂存当前 Step 的 assistant/chunk，避免 _estimateProviderAssistant() 为读取 sourceEventSeqs 再次访问完整 session.events。
冷启动、服务重载或事件不连续时，仍可通过一次 Session 快照完成追赶。

优点：

• 修改集中在 TokenMeter。
• 不需要扩展 Session 公共 API。
• 热路径从每事件 O(N) 降到均摊 O(1)。
• 保留现有冷启动重放能力。

方案 B：为 Session 增加 O(1) 的 eventAt() 或尾部迭代接口
能够解决 TokenMeter 和其他增量消费者的相同问题，但会扩大 Session 公共 API，需要额外审查不可变性和插件边界。
方案 C：对计量更新做防抖或批处理
只能减少调用次数，不能消除完整日志复制，长会话仍会退化，不建议作为最终修复。
推荐方案
推荐方案 A：事件热路径直接折叠，冷路径只获取一次快照，并在 TokenMeter 内维护有界的 Chunk 索引。
验收标准

• 热事件监听路径不再访问 session.events。
• 事件数量扩大 2 倍时，运行时间应接近 2 倍，而不是 4 倍。
• 冷启动、服务重新加载和 Seed Session 仍能正确追赶。
• 现有 TokenMeasurement 结果保持完全一致。
• malformed event 失败后不得推进 consumedEvents。
• 增加 8K、16K、32K 的性能回归测试或独立 Benchmark。

如果维护者认可该方向，我愿意按方案 A 提交修复 PR，包括事件直折叠、Chunk 有界缓存、冷启动追赶、结果一致性测试和性能回归测试。

[DRAG0NM]

方案 A 与我们报告的修复方向一致——报告即指出「每事件全量快照重建」应改为事件驱动的增量折叠；有界 Chunk 索引同时解决了 _estimateProviderAssistant() 回读 sourceEventSeqs 的二次开销。验收标准也很完整，特别赞成「malformed event 失败后不推进 consumedEvents」这一条：增量折叠里 seq 单调性的保护正是最容易出错的地方。冷启动单次快照追赶 + 热路径均摊 O(1) 是正确取舍，期待 PR。

[TuringCorp-net]

Related thread on long-conversation UX: #5650 (auto-compaction silently resets long sessions; incremental rolling memory proposal). Same "long conversations are not first-class" theme as this O(n²) issue.