肇事消息解剖 msg[6] 的结构(user 角色,打包了 4 个 tool_result): 1. search_context 结果 ×2(2,665B / 2,627B,稳定) 2. read(run-regression.sh, limit:93) 结果(call_ab9463efe43d447eabf8696e)—— 不稳定 ① 3. bash 扫描结果(1,066B,稳定) 4. 消息尾部的 <dcp-message-id> 标注 —— 不稳定 ② 字符级 diff(18:01 → 18:03,首差 @char 2599): ``` A: ...→ decompress(b9) for full content <dcp-message-id tokens="3.3K" type="tool:search_context,read,bash">m00472</...> B: ...→ decompress(b9) for full content <dcp-message-id tokens="2.8K" type="tool:search_context,read,bash">m00472</...> ^^^^^ 同一个 m00472,token 标注 3.3K ↔ 2.8K ``` 同一个 tool_use_id 的 read 结果:A 版 7,386B ↔ B 版 5,090B(同一文件同一 limit,一个多一个少)。然后 18:05 又整体翻回 A 版(A→B→A 三轮振荡)。
Activity
ranxianglei commentedon Oct 16, 2026
补充 好像是一种东西占位符导致的
三轮请求体本身就是三个不同的大小区(消息数还在涨,体积却在 550K↔670K 之间跳)。
② 那条 read 结果(call_ab9463efe43d447eabf8696e)的 content 本身
③ 差的到底是什么(字符级,首差 @char 2278)
两边都是同一文件同一位置断开的:
B 版 = 客户端的压缩层在 read 结果中间剪掉了 ~2,814 token 的文件内容,塞进一行 ...[truncated for context space — original ~2814 tokens]...(164 行→135 行);A/C 版是完整原文。
[-]<dcp-message-id tokens="2.8K" type="tool:search_context,read,bash">m00472</...> 不稳定导致cache反复miss[/-][+]<dcp-message-id tokens="2.8K" type="tool:search_context,read,bash">m00472</...> Instability causes repeated cache misses | <dcp-message-id tokens="2.8K" type="tool:search_context,read,bash">m00472</...> 不稳定导致cache反复miss[/+]feat: sticky emergency truncation — frozen outputs replay byte-identi…
merge: master (v1.18.5 + emergency truncation) into image context gua…
Merge branch 'master' into 2026-09-16_serialize-session-init-transforms