文件名tokens 消耗 20260927.md版本v62026-09-27· 定稿性质原始会话 transcript 的解释层第一人称自述来源02_领域/编程/Harness/tokens 消耗 20260927.md117,410 B / 1505 行原文一字未动版本演进v1685 行→ v2799 行→ v3 → v4710 行·完整版→ v5621 行→ v6本次修订凭证存档_ai_drafts/tokens 消耗 20260927自述版·完整版 v4.md保存源码片段、完整哈希表和全部原始细节本文件大小/哈希在交付汇报中给出文件不能包含自身最终哈希值核验数据见附录 D本版全部指标重新核验不直接继承旧版本结论〇、写在前面为什么叫「实践」而不是「失误」这篇文档我把原来标记成「失误」的三章全部重命名为「实践」。这不只是换个词玩文字游戏评判标准本身变了。以前我理解的失误一件事本来可以一次做对但我没做到。潜台词是存在唯一标准答案我没能拿到相当于做错了、有亏欠。现在想法不一样了。探索实验本身就会试错。出错不可耻定位问题、动手修复才是核心。反复试跑才能分清哪些路径可行、哪些走不通。我不想只看别人的 PPT、视频纸上谈兵必须亲自跑一遍。实践是检验真理的唯一标准。落到这次 token 消耗排查上最核心的因果纸面推演只能得到「看起来合理」的猜想动手跑起来才能拿到真实反馈。文中所有硬数字——57.1M、0.57%、176.8 倍、WinError 5、!!js 标签、pruner 的剪枝-重测-摘要三段逻辑没有一个是靠脑补算出来的全是踩坑踩出来的真实结果。事实不变只是换一套理解这件事的框架错是客观发生的事实实践是我们看待这件事的框架。〇.1 两条基本判据判据一修订解释文本时只调整措辞不改动实测数字和底层机制描述。任何机制说明都要能追溯到源码行号或者会话日志。判据二表格里每一个数字都要标注「实测」或者「预估」不带标签一律视作估算值。〇.2 错误点统计版本 漂移处数 问题落点v2 12 处 机制描述 10 处 口径/算术混淆 1 处132.3 和 176.8 混为一谈 标签错误 1 处写「占比估」v3 4 处 机制描述 2 处 凭证引用 1 处 标注错误 1 处把预估 −76% 写成实测v4 精简稿 7 处 可核验信息被删掉 3 处哈希值、四态归档链、正误对照内容被替换 3 处文件名引号书写错误 1 处v5→v6 5 处 表头颠倒 1 处自引用哈希 1 处锚点标签 2 处错误继承旧核验结果 1 处结论没有一处错误出在原始数字本身。→ 数字比文字描述、机制解释更稳定。所有关于机制的表述都必须能回查到源码或者原始日志。一、结论先行项目 数值 标记 来源会话到 185 步时单次会话输入总量 57.1M token 实测 会话日志有效信息占比 0.57% 实测 322,952 ÷ 57,105,160占比的倒数 176.8 倍 实测 57,105,160 ÷ 322,952131 步时点单步平均倍数 132.3 倍 实测 261,005 ÷ 1,972根因 五套上下文治理机制全部没有挂载 — 源码 日志预估可削减规模 从 33.3M 降到约 8M减少约 76% 预估双重外推没有实跑 未实测下一步处置第 0 步 新开会话先启用 custom-ctx — 见第八节状态 方案已经定好还没实际跑起来 — —注意这两个倍数不能混为一谈。132.3 倍是「单步平均」口径176.8 倍是按有效占比算出来的口径。−76% 只是预估从来没有实测验证。提到 57.1M必须带上步数说明见附录 A185 步。标签这一列只用来标记数字不写多余描述。二、统计口径说明输入总量 每一次请求里 prompt 的累加。这是无状态 API 天生的特点每发一次请求都要把完整上下文一并提交不是系统自动做了什么额外操作。账单 vs 上下文窗口99.2% 的 token 消耗属于缓存读cacheRead缓存把实际账单压得很低真正的硬约束是 1M 的上下文窗口。不要简单说成「99% 都浪费了」容易造成误解被占用的是窗口容量不是计费 token。三、钱token都花在哪了来源 实测值 占比 分母 标记第 1 步基础 prompt初始底板含系统提示、工具 schema 10,210 tok 4% 总输入量 33.3M 实测持续累积、反复重发的上下文 — 96% 总输入量 实测├ 助手历史回复正文 395,333 字符 — — 实测├ 工具返回结果 329,914 字符 — — 实测│ └ 其中 read 读取结果占工具返回的 71% — 71% 工具返回总字符 实测├ 工具调用参数 177,263 字符 — — 实测└ 思维链内容不计入模型输出 78,550 tok — — 实测用户发出消息 21,094 字符 2% 上下文总字符 实测⚠️ 71% 和 96% 不能直接对比二者分母不一样前者分母是工具返回内容后者分母是全部输入 token。最大的优化杠杆在 read 调用它占全部工具返回结果的 71%。四、根本原因治理机制全都没挂上问题不是 custom-ctx 反复全量重注入——本次会话根本就没启用它。custom-ctx 是解决办法不是病根。也不是 pruner 和摘要共用阈值互相干扰源码里根本没有这个逻辑。真正根源五套上下文治理机制全部未挂载。机制 状态 造成的后果会话压缩 未挂载 上下文无限累加从 1 万涨到 39 万没有自动回落工具结果剪枝 未挂载 read 读到的内容全部留在上下文里23.3 万字符永久驻留子代理委派 未挂载 所有工作都堆在主上下文4 轮探测、26 次读取、99 次修改全部在主会话里跑/compact 手动压缩命令 未挂载 无法手动触发压缩大输出落盘机制 未挂载 长结果不落地直接留在上下文默认阈值 0.8对应 1M 窗口就是 80 万 token。本次峰值才 39 万就算开启默认配置也永远不会触发压缩。→ 问题不只是「没挂载机制」这套默认参数本身并不适合 1M 窗口。五、成本真相桶内 token 分类uncachedInputTokens269,318全价计费 tokencacheReadTokens32,984,192缓存读取占 99.2%cacheWriteTokens0模型输出补全183,995口径一有效信息占比0.57% 的倒数 176.8 倍实测用来衡量新增有效信息的稀释程度。口径二单步均值131 步时261,005 ÷ 1,972 132.3 倍实测衡量每一步的信息效率。预估优化幅度33.3M → 约 8M减少约 76%预估。不是减少 99%。无状态 API 必须重复带上下文这个开销没法彻底消除。不能夸口说这里有 131.3 倍的节省空间——这属于过度承诺。六、实践一三处配置全错是追问核对才发现的背景拿到一份现成配置准备直接照搬修改。核对的时候多追问了一句对照官方预置模板校验查出 4 处错误。我原先写的错误 官方标准写法正确 问题说明name: ‘deepseek-ai/dsh-compaction’ name: cordis:group group: true 包名搞错这只是一个库不是可以直接挂载的插件行config: {compaction: true, …} isolate: {compaction: true, …} 键名放错层级把子配置写在顶层 compaction 放在 config 嵌套内 层级错误group 分组语义失效pruner 使用 thresholdRatio thresholdChars: 8192 / headChars: 4096 / tailChars: 1024 参数名混淆thresholdRatio 属于 compaction-basic 组件注意前面提到的「默认参数不合适」不属于这四项是第四节单独发现的另一个独立问题。官方文件路径凭证层也留存~/.dsh/profiles/node_modules/deepseek-ai/dsh/config/agent-presets/standard/agent.cordis.yml本次产出拿到权威结构后面就以此作为 custom-ctx 的基础骨架。发现一条失效的备份路径custom-minimal 注释里引用 standard_agent.cordis.yml完全匹配不到内容。如果没核对后续会出现「备份成功」的假象骗过所有人。直接复制粘贴配置的坑看起来配置写完了但所有功能静默失效一点报错都没有。教训已经登记到 ai_memory.md §6 第 6 条写入外部配置文件前必须读取权威源文件核对。七、实践二提前推翻准备写进交接单的假阴性测试不是跑一遍就能发现问题是读源码dsh-compaction-basic/lib/index.js L867–887才看懂。这也是这件事最有价值的地方上下文总量低于 30 万的时候怎么跑都看不出异常要搞清楚它什么时候触发、谁来读取这个参数只能读源码。调参优先动 retainRatio 的底层理由参数 控制事项 说明thresholdRatio 两件事 控制剪枝触发条件同时控制摘要触发时机两个行为共用这一个参数retainRatio 一件事 只控制摘要保留多少内容剪枝本身不改参数也能运行。改动 thresholdRatio会一次性修改两套逻辑。→ 优先调只负责一件事的 retainRatio。retainRatio 的语义两个比例的分母都是窗口上限1M不是当前上下文长度。触发后会丢弃300,000 − 80,000 22 万 token。retainRatio 和 retainTokens 互斥。retainTokens 是固定绝对数量不受窗口大小影响预测性更强。硬性约束retainTokens thresholdTokens。这次的收获在方案落地前拦下一个假阴性问题。不然接手的人会以为这套逻辑验证通过等到真实故障发生白白浪费好几天排查时间。教训登记原文ai_memory.md §6 第 10 条参数文档写的含义不等于运行时真实行为。八、处置方案步骤 动作 理由0 新开会话先启用 custom-ctx 不打开它后面调的预设参数都不会生效1 retainRatio从 0.08 调到 0.15~0.20 分母是窗口上限每次最多丢弃 22 万 token2 thresholdRatio 暂时不动保持 0.3 它同时控制剪枝、摘要两件事一次只改一个变量校准顺序启用 custom-ctx → 只修改 retainRatio → 双通道冒烟测试§14.1→ 对照五行判读表§14.3确认 → 确认没问题之后再考虑调整 thresholdRatio。⚠️ 两张表格不要弄混五行判读表用来验证压缩功能有没有正常跑四指标表§14.2用来检查我们自己的操作习惯。备选方案预测性更强如果不想比例跟着窗口大小浮动可以直接设置固定值 retainTokens: 150000。九、分段实测8 个观测数值锚点就是写这份规范文档的那次 write 操作同一会话切成前后两段不靠猜步数定位。指标 规范前166 步 规范后19 步 变化 标记uncached全新信息全价计费 1,856 780 −58% 实测工具返回结果 393,565 16,846 −96% 实测read 调用次数 32 2 −94% 实测单步平均 prompt 大小 289,595 475,384 64% 实测prompt 峰值 457,528 492,595 8% 实测9.1 背后的数学逻辑uncached新增全价 token总和322,952全部输入 token 总和57,105,160uncached 占总输入0.57%规范能优化的对象只占全部输入的 0.57%。就算做到新增信息为 0总 token 消耗也只能下降 0.57%。所以优化后看不到巨大降幅不是操作不到位而是底层原理限制。这套操作只能止血没法一次性大幅削减总量。 真正大幅度降量靠 compaction 压缩但本次会话里压缩没有挂载。步数增加边际成本越来越高是必然跑到 145 步总量 38.8M后面新增的 40 步每一步边际 token 约 458K是会话平均值 309K 的 1.5 倍。⚠️ −76% 是预估数值不是本表里面的实测结果。十、实践三归档晚于改动靠哈希补全证据链两件事分开看WinError 5创建 custom-ctx 的时候系统 ACL 沙箱拒绝写入。按流程重试提升权限即可成功属于正常操作不算故障。归档备份限制来自 vault_fp.py工具不支持同一天多次备份。我不拿这个当借口备份顺序是我自己安排的。操作过程text预期 sha2562b2b5353c421c48fce98aab4ff1f562a8aa79216d29025342606d331e3af884f重建文件 sha2562b2b5353c421c48fce98aab4ff1f562a8aa79216d29025342606d331e3af884f→ 哈希匹配校验通过 ✓中间状态可以凭哈希完整恢复。教训所谓「备份先行」不只是执行备份这个动作备份必须放在修改操作之前。十一、归档链与凭证ai_memory.md 四态归档链实践三的物证指纹校验 origin backup 文件原文状态 文件大小 sha256 说明v1 18,106 B / 221 行 518991f0… §5.4 第 12 条修改前v2 21,229 B / 241 行 a20b48b9… §6 第 6 条修改前中间态 24,068 B / 251 行 2b2b5353… 没有正式归档但可以按哈希重建v3 26,854 B / 265 行 8edca0ea… 最终版本交付文档凭证清单文档名 大小行数 sha256_ai_drafts/_tools/ 上下文减量操作规范.md 177 行 / 10,796 B增补 §2.0 后原版 163 行 / 8,848 B 4652bfeaf9d7cea6原版 d796365f09baf252_ai_drafts/ 上下文减量操作规范_备份_20260927.md 163 行 / 8,848 B d796365f09baf252_ai_drafts/ai_memory.md 29,687 B / 281 行同日增补 §6 第 11 条原版 26,854 B / 265 行 2855233e64730025原版 8edca0eafad88ce1_ai_drafts/tokens 消耗 20260927自述版_v5_备份_20260927.md 621 行 / 34,697 Bv5 旧稿 551f86e0e924ecf9_ai_drafts/ 交接单_四公子第二段_20260927.md 15,601 B / 232 行 b13fc6bc687ed14c预设配置 4 个文件明细放在凭证层文件 大小行数 sha256custom-ctx/agent.cordis.yml 9,527 B / 195 行 6c770e99f59796b7custom-ctx/preset.yml 317 B 13d32910282f9e0bcustom-minimal/agent.cordis.yml无改动 2,053 B 79362ecb22a19e77custom-minimal/preset.yml无改动 204 B 9cb0d9467ab1e2bd三条不变事实可复核落盘文件可以从备份原文逐字对齐开头 Truecustom-minimal 两个哈希 79362ecb… / 9cb0d946… 保持不变回退路径完好 ✓custom-ctx 顶层生效共 7 条delegation 不在启用列表 ✓本文件自身大小、哈希不在本表记录文件不能包含自己最终哈希这两项放在交付汇报里。如果缺少这些物证整篇文档就只是「我个人的描述」违背第〇节的原则。十二、实践四升级解释框架时事实描述最容易漂移实测数字保留了57.1M、0.57%、132.3 倍。但是造成现象的根因很容易被替换成「看起来说得通但不是真相」的解释。v2 版本就犯过这个错把根因说成 custom-ctx 全量重注入不存在还有「两个阈值互相干扰」刚好说反。漂移有三种形态这次全部遇到了形态 表现 本次例子替换 底层机制被换成看似合理的错误说法 v2 写错的两个根因剪除 删掉可以核验的证据比直接写错更隐蔽 v4 精简稿删掉哈希、对照校验表颠倒 表头和内容写反读起来完全是另一个意思 v6 草稿里的正误对照表这就是〇.1 判据的来由修订解释文本只能调整句式不能改动数字、不能篡改机制。表格内所有数字都标注「实测」或者「预估」。和第十三节第 8 条对应我提出的参数也只是假设。同理我写的机制解释也都必须能回源核验。十三、定律表7 条已验证 1 条待检验假设编号 定律 核验方式 标记1 开销大头是上下文反复重发不是初始系统提示词的大小 实测初始底板只占 4%重复上下文占 96% 实测2 输入总量 ≈ 上下文长度 × 请求步数prompt 持续变长时总输入接近步数的平方级增长 实测后期边际消耗 458K / 步是会话均值 309K 的 1.5 倍 实测3 配置写在文档/注释里 ≠ 运行时真的生效。报告、注释、备份路径都不算权威来源 三处静默失效一条路径完全匹配失败本文稿本身三次描述漂移 实测最强证据4 操作纪律只能止血没法一次性大幅削减总 token 实测read/write 优化能做到 −58%/−96%但这部分只占全部输入的 0.57% 实测5 参数文档写的含义 ≠ 运行时真实行为。找不到调用入口就不要设计测试 源码 L867–887 实测6 备份必须放在修改之前。一旦顺序颠倒只能靠历史记录反向重建 实践三哈希重建验证 实测7 无状态 API 必然重复提交上下文重复提交这个基础开销无法消除 API 本身特性 实测8 ⏳ 待检验假设thresholdRatio: 0.3 / retainRatio: 0.08 这套参数是否合适 新开会话跑一遍校准 假设第 8 条的意义就是留到下一次会话实测。按本文标准没有实测验证的推论和网上 PPT 上随便给的数字属于同一可信度等级。补充「假阴性测试比真故障更危险」属于心得不算定律实践二就是用来验证第 5 条定律。十四、验收标准14.1 双通道冒烟测试(a) /compact 命令是否可用由 compaction 组的 command-compact 组件提供(b) 读取 custom-ctx 生效清单顶层共 7 条delegation 不在启用列表如果两者结果冲突以 (b) 为准。 (a) 会因为前端不展示命令出现假阴性。14.2 四指标表用来评估我们自己的操作纪律指标 本次实测值 健康阈值 超标含义read 占工具返回结果比例 71% 40% 反复整段重读文档write 参数占工具参数比例 高 30% 频繁用 write 做大面积修改单步平均 prompt 254K 150K 上下文过长该压缩或者新开会话重发 ÷ 新增 token 132× 50× 步数太多上下文已经失控随时可用的单步判断规则如果某一步新增 uncached 输入 3000 token但整体 prompt 200,000 token → 这一步几乎没有新增工作绝大部分开销都在重复发送历史内容。这时应该合并步骤或者执行压缩不要继续往下跑。14.3 五行判读表验证 compaction 压缩是否生效序号 现象 判断1 峰值超过 40 万才回落 thresholdRatio 设置偏大2 反复触达上限但不会掉到 8 万 属于「只剪枝、不生成摘要」阶段正常不要改参数3 曾经下探到约 8 万 剪完仍然超阈值进入摘要阶段4 下限稳定低于 5 万 retainRatio 太小 → 优先上调到 0.15~0.205 数值单调上涨永远不回落 compaction 完全没挂载回到 14.1 做冒烟检查补充说明① 反复触顶、回落但下限远高于 8 万说明剪枝单独承担减压。这是成本最低、最健康的状态不会额外调用 LLM 做摘要。不要因为没掉到 8 万误以为压缩没起作用。② 剪枝先执行。看到单步 prompt 下降有可能只是剪枝生效不一定触发了摘要别误判。十五、实践观五句话每一句都对应本次实证表述 本次实证 证据强度实验本身就是探索 统计口径从渲染函数读出压缩分两阶段文档没有写靠读源码拼凑出来 强出错不可耻解决问题才是重点 4 条配置全部写错 → 对照官方模板修复假阴性风险读源码提前拦下归档顺序出错靠哈希重建证据 强持续试错才能知道方案行不行 一次只改动一个变量第七节源码推导理由四指标、五行判读表 强不想只听别人结论要自己动手验证 别人给的配置有三处错误就连我上一轮写的报告也不视作权威来源本文自己的描述三次出现漂移 极强实践是检验真理的唯一标准 所有数字带来源、标记实测/预估没跑过的估算明确标注预估、假设 强15.1 这个标准同样约束我自己thresholdRatio: 0.3目前和别人 PPT 上的数字一样只是假设。只有跑完实测它才能变成经过检验的结论。两处自我约束点① 参数假设§十三第 8 条② 机制文字描述§十二。如果「实践是唯一标准」只用来挑别人的错不拿来审查自己那就变成另一种形式的主观独断。15.2 ⚠️ 本次最重要的洞见已经写入规范pruner 的工作逻辑当总 token 超过阈值超过 8192 字符的工具返回结果会被截断为头部 4096 字符 截断标记 尾部 1024 字符总长度约 5160 字符。一旦 custom-ctx 启用一次性读取长文档的时候文档中段会被悄悄截掉。→ read 读取不再只是省 token更重要的是防止模型基于残缺文档做出错误判断。→ 操作硬性要求读长文档必须分段读取offset/limit。✅ 这条已经补进《上下文减量操作规范》§2.0第 0 条最高优先级正确性要求。15.3 待完善事项在《DSH纪律极简模式完整实现报告.md》增加反向引用27.2M / 57.1M就是这个设计决策带来的实测代价。把整套流程度量 → 归因 → 定位根因 → 制定处置方案 → 验收核验加上「实测/预估分级标记」抽象成一套可复用方法论。写一页简短 TL;DR 摘要放到 03_资源 目录方便引用。清理原始 transcript 里引号混用问题需要先备份并且遵守 §6 红线。⚠️ 文件名这个地方连续 4 次写错用了直双引号v3、v4、v5 粘贴稿、v6 草稿。规范写法是弯引号。凡是引用这个文件名直接从目录复制不要手动打字。十六、留给下一个会话的一句话新开会话第 0 步先启用 custom-ctx。它的启动清单在会话初始化的时候读取当前已经跑起来的会话修改不会生效。然后按第八节的校准顺序只调 retainRatio0.08 → 0.15~0.20→ 双通道冒烟测试 → 对照五行判读表确认 → 确认没问题再考虑 thresholdRatio。thresholdRatio: 0.3现在还不是定论只是我推导出来的假设。跑一遍。跑完它才算得到验证。附录 A五个观测时点总表时点 步数 输入总量 有效占比 来源 引用强制要求A 115 27.2M — footer 快照 引用必须带上「115 步」B 131 33.3M — 会话日志重算 引用必须带上「131 步」C 145 38.8M — footer 快照 引用必须带上「145 步」D 183 56.1M — footer 快照 引用必须带上「183 步」E 185 57.1M57,105,160 0.57% 会话日志终态 引用必须带上「185 步」引用规则引用这几组数字必须附带对应步数不带步数视为无效引用。⚠️ B 是日志重新计算其余是 footer 快照。两套数据源不要混在一起计算。不是数据矛盾是五个独立观测点。核心比率汇总实测见 §一、§五、§九。初始底板 10,210会话平均步长 308,676uncached 1,972 → 780单步重发 261,005132.3 倍、176.8 倍底板占比 4%0.57%缓存 99.2%思维链 78,550 tok。附录 B复现方法踩过的五个坑全部是实际踩坑总结不是文档查到的内容序号 坑 解决办法1 会话日志是 zstd 多帧追加压缩一次性解压只能读到 172 字节 使用流式解压不能一次性调用 decompress()2 agent.cordis.yml 文件包含 !!js 标签裸 pyyaml 直接报文件损坏 注册 js 自定义构造器再解析 yaml3 PowerShell 默认 GBK 编码读取 UTF-8 文本出现乱码 Python 打开文件强制指定 encoding‘utf-8’4 写入 ~/.dsh 被 ACL 沙箱拦截WinError 5 不算权限故障按流程重试按需提权即可5 事件结构不统一user message 的 data 字段直接是 content不是嵌套 message 对象 解析前先探测事件结构数据源~/.dsh/sessions/…/session.jsonl.zstd本次日志 6.4MB共 6416 条事件配套脚本放在 _ai_drafts/_tools/probe_session_log.py探查结构 流式解压analyze_session_tokens.pytoken 归因统计compare_segments.py分段对比collect_handover_credentials.py / check_handover.py凭证收集、哈希核验附录 C证据层可以直接 grep 检索的字符串源码行号证据描述 出处剪枝-重测-摘要三段逻辑pruner 触发点 dsh-compaction-basic/lib/index.js L867–887footer 渲染函数K/M 单位换算 dsh-client-ui-conversation/lib/client.js大约 2755 行compaction-basic 默认常量 0.8 / 0.16 同上源码包常量原始 transcript 可检索关键词串关键字 对应内容10,210 第一步 prompt 底板占总量 4%395,333 助手回复累计字符329,914 工具返回累计字符232,632 read 读取累计字符占工具返回 71%177,263 工具调用参数累计字符261,005 131 步单步平均重发上下文1,972 / 780 规范前后单步 uncached322,952 全部 uncached 新增 token 总量57,105,160 总输入 token和上面相除得到 0.57%command-compact 双通道 (a) 对应的命令组件thresholdChars pruner 参数 8192/4096/1024WinError 5 ACL 沙箱报错pruneSession pruner 触发入口假阴性来源2b2b5353 中间态重建校验哈希⚠️ 这些字符串必须在原文 grep 命中。如果检索不到这套证据链就失效了。三条不变量、凭证清单见 §十一。附录 D引号与格式核验口径定义正文 §〇十六 附录 A–C全文 正文加上附录 D、E。两者差值就是本附录自身的自引用。正文改动附录 D 必须重新跑核验。待核验项目 全文 正文一级弯引号「」配对数量 62 / 62 ✔ 51 / 51 ✔弯引号只用于文件名 2 1直双引号只允许在代码块内 0 ✔ 0 ✔标签计数实测预估假设 40117 3795文中「失误」出现次数只用于引用旧框架 7 5读数说明两处弯引号是引用 DSH纪律极简模式完整实现报告.md§15.3 和本段不属于正文一级引用。全文没有独立直双引号全部在代码块内本次代码块无直双引号为 0。行数、字节数、sha256 不在本表记录。文件不能包含自身哈希这几项放到交付汇报。附录 E《上下文减量操作规范》摘要规范正式条目第 0 条 四条硬纪律。§2.0 第 0 条最高优先级正确性强制要求读取长文档必须分段读取offset/limit禁止一次性读取完整文档。要点 内容底层机理 custom-ctx 生效之后如果工具返回超过 8192 字符会截断成 head 4096 标记 tail 1024约 5160 字符文档中间内容直接丢失触发条件 pruneSession() 只在 compactIfNeeded() 内部调用上下文总 token 小于 30 万直接 return不执行剪枝⚠️ 风险 不是永远截断。低于 30 万不剪高于 30 万才截断。能不能读到全文取决于当前上下文大小。这种「有时完整有时残缺」是最危险的和第 1 条的关系 第 1 条是成本管控第 0 条是正确性红线。第 0 条是必须遵守第 1 条是建议遵守优先级理由 四条纪律只是省钱第 0 条防止模型基于残缺文本推理一旦出错错误会持续传导下去四条硬纪律序号 纪律 本次实测反面案例1 read 定向检索先用 grep 定位再 offset/limit 分段读禁止整份重读 read 占全部工具返回 71%2 修改文件优先用 edit新建或者改动超过 50%才用 write write 单次参数 23,476 字符3 脚本只输出聚合统计结果原始日志落盘保存 6.4MB 日志被反复读回 3 次4 长交付结果落地写文件只粘贴关键片段附带文件路径 助手正文累计 395,333 字符自检判断标准四指标表 单步判据§14.2不是五行判读表。注「一次只改一个变量」属于规范 §5.4 会话卫生不属于这四条硬纪律。规范版本变更记录163 行 / 8,848 B / d796365f09baf252 → 177 行 / 10,796 B / 4652bfeaf9d7cea6同日增补第 0 条。附2026-09-27已决事项清单序号 事项 结果1 自述版文件落位 执行方案 (b)Move-Item移动至 02_领域/编程/Harness/tokens 消耗 20260927自述版.md原始基础文件一字未动2 规范文档增加第 0 条 已经写入 §2.0 §3.1 细则反面清单、页脚同步更新原文件备份_ai_drafts/ 上下文减量操作规范_备份_20260927.md8,848 B3 凭证同步更新 自述版 §十一、附录 E、本表同步哈希与状态完整版 v4 文档 §十一、§16.2 同步哈希和状态4 ai_memory.md §6 新增第 11 条 新增 §6 读取时正确性要求小节增加第 11 条「读长文档必须分段读」。本次顺序为先修改再备份修改前版本由 ai_memory_备份_20260927_v3.md 覆盖origin 和 backup 哈希完全匹配。没有额外新建第三份同日备份。版本变迁26,854 B / 265 行 / 8edca0eafad88ce1 → 29,687 B / 281 行 / 2855233e64730025原文未改动证明哈希、大小、mtime 三重凭证textBEFORE 117,410 B mtime 2026-09-27 10:03:51 sha256 941b47878de6689eAFTER 117,410 B mtime 2026-09-27 10:03:51 sha256 941b47878de6689e→ 源文件没有改动 ✔操作顺序所有编辑都放在 _ai_drafts 临时目录改完再移动文件。全程没有直接修改 02_领域 目录里任何已有文件遵守 §6 红线。
