workbuddy.db 的 session_usage.credit_json 与 automation_runs.runs_json（宿主真实计费字段，非估算）sessionId）；钩子只能注入指令，末段动作必须由模型调 automation_update 完成。| 自动化运行 | 上下文 input tokens | 工具调用 | 积分 | 积分 / 工具 | 缓存命中 |
|---|---|---|---|---|---|
| 覆盖网络线·归档接续 | 200,013 | 54 | 13.82 | 0.256 | 99.8% |
| 决策方法-2 | 168,040 | 37 | 10.05 | 0.272 | 99.9% |
| 覆盖网络线·接续（优化版） | 141,401 | 31 | 8.93 | 0.288 | 99.8% |
| 代码仓三方同步 ③ | 87,177 | 20 | 1.93 | 0.097 | 99.8% |
| 代码仓三方同步 ① | 64,876 | 15 | 1.66 | 0.111 | 97.9% |
| 遗留项自动推进 | 82,712 | 12 | 1.20 | 0.100 | 98.7% |
| 代码仓三方同步 ④ | 63,147 | 16 | 1.18 | 0.074 | 99.7% |
| 代码仓三方同步 ② | 56,422 | 11 | 0.82 | 0.075 | 98.5% |
铁证：三次「新建会话跑一次」的积分 = 8.93 / 10.05 / 13.82，与你观察到的「提一轮就 7 8 个积分」完全吻合。而它们每一个都是全新会话的第一轮——证据在 automation_runs.metadata_json：
⇒ 已核实 自动化确实是「开新会话」的通道，但新会话第一轮的 31–54 次工具调用照旧收费，而且开局水位为零也没让它变便宜。
为什么不变便宜？因为成本 = 请求次数 × 每次请求量。开新会话把「每次请求量」的增量部分清零了，但：
⇒ 「会话多大」影响的是单价，不是总价；「跑多少次工具」才决定总价。
| # | 杠杆 | 效力 | 做法 |
|---|---|---|---|
| ① | 一轮内的工具调用次数 | 主导 · 线性 | 批量活写成脚本「一次跑完」：1 次 Bash 顶 20 次 Read/Edit/Bash。31 次 → 5 次 ⇒ 8.93 分 → 约 0.5 分 |
| ② | 会话水位 | 次要 · 约 3 倍 | 到阈值换会话（就是你想建的那套机制） |
| ③ | 固定注入 35,192 token | 很轻 | 缓存命中 99.5%，基本不用管 |
⚠️ 顺序不能反：先治 ①，再治 ②。只换会话不减工具调用 = 每次省一点单价、总量照旧，这正是「没达到节约效果」的成因。
stop-dialog-guard.py 三级阈值 12 万 / 20 万 / 30 万，数据源 = 转录里的真实 usage.input_tokens，同级去重只报一次SessionStart / PreToolUse / UserPromptSubmit，输出只有「注入上下文」与「拦工具」两种，没有任何创建 / 切换会话的能力automation_update 登记一次性自动化；宿主调度到点即开新会话automation_update 创建，这是硬约束。它的真实价值：把「被迫收口 → 用户手工开新会话」变成「自动续上」，省掉人工一步，并把单价膨胀（约 3 倍）压回去。它不省工具调用次数——所以第 ③ 步 prompt 里那句「工具调用 ≤ 8 次」才是真正值钱的部分。
它的局限（如实说）：末段是软环节——钩子只能要求模型照做，模型若不调 automation_update 则链条断在最后一步。硬保证只有前半段（提醒 / 强制收口）。
这是自动接续能不能用的真正前提——接不上状态，「自动开销」只是白花钱重新探索一遍。原规范（工作区根《会话接续规范》）已有 6 项内容清单，本轮补的是可校验性：文字会失真，证据不会。
实证：上一条接续点原话写「清理被截断的 .workbuddy/memory/MEMORY.md」——照做就会改错对象（真正被截断的是用户级那份）。凡是结论，必须附一条能复现的命令。
硬要求：① 「校验命令」必填，只读、30 秒内跑完、输出可判真假；② 「下一步」第 1 条必须可直接执行；③ 产物 / 未完成 / 不要重做 三节一个都不能空（空写「无」）；④ 全篇 ≤3 KB，只写「在哪 + 什么状态」。
| # | 动作 | 为什么 |
|---|---|---|
| 1 | 只读接续包（⛔ 不许一上来就全库探索 / 扫全盘） | 探索是最贵的动作；接续包就是用来免掉它的 |
| 2 | 跑「校验命令」并比对期望输出——不符就停下报告，⛔ 不许照文字硬做 | 文字会失真；跑不通的校验会伪装成"通过" |
| 3 | 复述「未完成」与「下一步」，确认与用户当时要的一致 | 防目标漂移（本线最大历史坑） |
| 4 | 从「下一步」第 1 条开工；⛔ 不重做「不要重做」列的东西 | 省掉重复劳动 |
⚠️ 接续包会过期：写完后又改了东西，必须回头改接续包并同步「基线」里的 sha 与时间戳。
第 ③ 条才是钱的开关：31 次工具调用 = 8.93 积分；压到 8 次 ≈ 1 分。前两条保证「不跑偏」，第 ③ 条保证「不贵」。
1. 两个「定时」自动化仍在按钟点烧钱——它们与水位无关，是「定时触发」而非「阈值触发」，恰好是你这次想改掉的那种：
| 自动化 | 周期 | 频率 | 已跑 | 已花 |
|---|---|---|---|---|
| 代码仓三方同步（DSH） | FREQ=HOURLY;INTERVAL=3 | 约 8 次/天 | 4 次 | 5.59 |
| 遗留项自动推进（DSH 平台） | FREQ=HOURLY;INTERVAL=8 | 约 3 次/天 | 1 次 | 1.20 |
合计约 11 次/天 × 每次新建会话；按实测均值 ≈1.4 积分/次估算 ⇒ 约 15 积分/天纯自动化消耗，且每次都会在仓库里产生一个新会话与新的未提交改动。
2. 五个一次性自动化已过期但仍为 ACTIVE（08-27 ×2、08-30、08-31，以及今天的三个覆盖网络/决策方法一次性任务）⇒ 属清理项。
3. 前一轮对本问题的结论需要更正：stop-dialog-guard.py 里写着「③ 因此本级不做自动开，做强制收口」并注明「自动开这一半无法实现」。前半句仍成立（钩子确实做不到），但后半句不准确——经自动化这一通道，自动接续可以做到半自动。此处属发现，未改脚本。
stop-dialog-guard.py 三级文案后追加第 ④ 条（提示模型登记 +2 分钟一次性自动化）。改动在 hook 脚本内、即刻生效，无需重启。收益次要 · 消除人工一步⚠️ 落地 ③ 需改文档库脚本 ⇒ 要抢全局执行锁 + 推镜像 + 复跑对账。本轮为无人值守运行，未动任何脚本 / 自动化 / 文档库，未抢锁、未提交、未推送；只升级了工作区根《会话接续规范》（本工作区自有文档，非文档库）。
| 会话 | 类型 | 轮数 | 积分总计 | 平均每轮 |
|---|---|---|---|---|
| 自动化·接续优化版 | 自动化 | 1 | 8.93 | 8.93 |
| 自动化·决策方法-2 | 自动化 | 5 | 44.77 | 8.95 |
| 自动化·确认覆盖网络待办 | 自动化 | 2 | 11.17 | 5.59 |
| 手动·检查覆盖网络方案 | 手动 | 5 | 16.52 | 3.30 |
⚠️ 手动会话的总量并不小（原会话 e2e090be 累计 221 次工具调用，比任何自动化都多）——差别在单轮。
你手动说「继续 XX 任务」，通常只指一件事；而自动化的 prompt 会把一整段工作串起来。以「决策方法-2」那条为例，它同时要求：三项任务 + 抢全局锁 + 只做三项 + 脚本化 + 反序释放锁 + 写简报 + 写记忆 + 不许承诺降低消耗 —— 八件事塞进一条指令，模型只能一路做到底。
实证：新会话 b08b1c35 那一轮，用户只说了「先确认待办事项」。实际发生的：
模型自己的思考留了痕：「重要取证完成」「取证非常完整了」「现在证据链完整了」—— 三次自我加码。你在场时，看到第三次就会说「够了，先停」；无人值守时没人喊停，它就自己给自己加码。
「接手前人结论先做最小取证」「交付门禁四层验证」「抢锁 / 反序释放锁」「写简报 + 写记忆」都是项目硬规则，每一条都是一个或多个工具调用。规则是对的，但把它们全塞进一条无人值守的指令里，就成了「必须一路做完」。
另有一笔环境税：Bash 每次都要重写 export PATH=…（shim 重置 PATH），虽不增加调用次数，但让每次调用都变长。
从转录里逐次请求的 credit 字段（与数据库 credit_json 合计完全对上，两个独立源交叉验证）：
| 会话 | 请求次数 | 单次中位 | 单次最低 / 最高 | 合计 |
|---|---|---|---|---|
| 自动化·确认覆盖网络待办 | 67 | 0.11 | 0.05 / 2.06 | 11.17 |
| 手动·检查覆盖网络方案 | 44 | 0.21 | 0.07 / 2.84 | 16.52 |
每一次调用只要 0.1 分左右——所以模型在单步决策时几乎感觉不到代价，它看不到「累计已经 67 次了」。没有人喊停，它就没有刹车。你在场时，你那句「够了，先停」就是唯一的刹车；无人值守时，刹车片不存在。
⛔ 注意：这里也顺带推翻了"自动化一定比手动贵"——按累计算，手动那个会话 16.52 反而更贵（水位 21.7 万、单次中位 0.21）。差别只在单轮塞了多少事。
在现有模板（§五）后面再加两条，直接掐掉前两个根因：
预期效果：b08b1c35 那一轮 77 次 → 约 8 次，11.17 分 → 约 1 分。这就是「把第一优先杠杆（一轮工具次数）压下去」的具体做法。
⚠️ 附带一条真实修正：早前记录写「转录 rawUsage 恒为空」——不准确。实测 b08b1c35 的 jsonl 里有 67 条带 credit 的 rawUsage，且逐次合计 11.17 与数据库 credit_json 完全一致。该字段可用，是逐次成本的最佳来源。