0 Fork 0

Files

T

用户选 B 方案：只改规则文字，把「必须建接续会话 ＋ 报 automation id」钉进
session-log-guard.py 日志硬档的处置文案。技能仓提交 80ddf12 已推送。

缺口实证：本会话 10-14 已到三级告警（.budget-alert-level 记 →3），
而宿主库里接续类排期 0 条 —— 钩子只「叫」，少了「必须建」这句，叫完仍没人建。

提交时发现另一条线在并发改：humanizer-zh 整包被删、product-planning 判据来源
改成「只有 humanizer 一份」，期间又新增 4 项去 AI 味相关改动，一律未碰。

2026-10-15 09:34:05 +08:00

7.1 KiB

Raw Blame History

2026-10-15 工作日志

排查「为什么不会自动创建接续会话」

用户问：「为什么现在不会自动创作接续会话了，日志达到上限了吗」

结论：日志没到上限，机制也没坏。真因是「接续会话」这条链只有"叫"没有"自动建"—— 建会话得由会话里的模型去做，而本机历史上从未建过。

一、日志水位（实测，⛔ 非推测）

本会话 23715e76-a2fd-4d42-8656-21ca3bde10f5 在 10-14 的日志 = 5 190 834 B（≈4.95 MiB）。
- 软档 SOFT_BYTES = 5 MiB（5 242 880 B）⇒ 差 52 KB；
- 硬档 HARD_BYTES = 8 MiB（8 388 608 B）⇒ 差 3.14 MiB。
10-15 已按天换成新文件（52 893 B）⇒ 同一会话跨天从 0 重来。
dsh log 自诊断：🟢 低于软档（523 B 的 warning.log 只含两条无关告警： CHANNEL_DISCONNECTED、PHASE_PLANNING）。

二、机制状态（体检脚本，⛔ 非目测）

session-rules-check.py --ws <本区> ⇒ fail 0 ／ warn 1 ／ ok 14 唯一 warn ＝ [C] 此刻无活会话（按需创建属正常） ⇒ 钩子全在册、在跑，机制没坏。

三条触发线（均已接线，见两处常量块）：

1、日志（session-log-guard.py）—— 软 5 MiB（开始写交接材料）；硬 8 MiB（回收；回收不成 ⇒ 停手＋建接续会话）。 2、上下文 token（stop-dialog-guard.py）—— 120 000（轻提示）／220 000（建议收口）／300 000 BUDGET_FORCE（强制收口：先落盘、出接续包、再开新会话）。 3、工具调用（同上）—— 软 200 BUDGET_TOOLS；硬 250 BUDGET_TOOLS_HARD（停手＋建接续会话）。

三、真正的答案（源码级）

session-log-guard.py 硬档的处置文案逐字：

③ 建接续会话（走一次性 automation —— 自动化是唯一能开新会话的通道）； ⚠️ 钩子开不了新会话 ⇒ 这四步必须由你自己做完；本钩子只负责"叫"。

⇒ 「自动创建接续会话」本机从来不存在。 钩子只负责"叫"，建会话要会话里的模型去建一条一次性 automation（那是唯一通道）。

宿主库佐证（只读查）：automations 表里名字/提示含「接续」「交接」的 ⇒ 命中 0 条 ⇒ 历史上从未建过接续会话。

四、两个真的短板（据实报）

1、日志线基本"叫不动"：宿主日志按天分目录（logs/<日期>/sdk/conversations/），同一会话跨天换新文件 ⇒ 单日要涨到 8 MiB 才触发硬档；本会话 10-14 跑了一整天只到 4.95 MiB。 2、昨天到过三级、但没有建接续会话：.budget-alert-level 里写着 23715e76-…→ 3（2026-10-14 11:09）⇒ token ≥300 K 或工具调用 ≥250 次已命中；而那条线（stop-dialog-guard.py）的处置也只是提示我收口，同样不自动建。 ⇒ 这是执行缺失（该建没建），不是机制缺失。

五、🔴 两处记忆订正（实测推翻旧记）

1、「工具调用软 200／硬 250 尚未接线」＝过期结论。实测 stop-dialog-guard.py 已有 BUDGET_TOOLS = 200（一级）／BUDGET_TOOLS_HARD = 250（三级），并在 t >= BUDGET_FORCE or ncalls >= BUDGET_TOOLS_HARD 的分支里生效 ⇒ 已接线。 2、「宿主库 187 条 ACTIVE once 排期＋ 7 条 ACTIVE recurring」＝与实测不符。实测：deleted_at IS NULL AND status='ACTIVE' ⇒ recurring 4 条、once 0 条 （4 条为：AI变现日报 ×2、WorkBuddy 日志定时清理、决策线体检）。 ⇒ 那条"遗留待清理"要么已被清掉，要么当初口径就不是"ACTIVE"（待下次核实时一并查清）。

六、沉淀

🔴 「自动」这个词要先证伪再采信：本轮用户问"为什么不再自动建接续会话了"，查源码才发现根本没有"自动建"这条实现 —— 钩子只叫、建会话要模型动手。 ⇒ 判据：凡涉及"某机制会不会自动做 X"，先 grep 出 X 的实现方，看它到底是谁在触发。
🔴 日志按天分目录 ⇒ 单日阈值要按"单日增量"重算：设 8 MiB 硬档前，先确认宿主会不会跨天重置。

第二件：用户选 B 方案 —— 把「必须建接续会话＋报 id」钉进钩子文案

用户指令：「b方案」（我给的 A/B/C 三选一里，B = 只改规则文字，不加自测判据）。

改了什么（技能仓提交 80ddf12，推送 2f65609..80ddf12，1 文件＋4 −2）： session-mechanism/scripts/hooks/session-log-guard.py 日志硬档（8 MiB）的处置文案 —— 1、③ 由「建接续会话」改为「🔴 必须建接续会话」，并加「建完把 automation id 写进给用户的最后一条回复」。 2、④ 告知语补上 id：「已登记自动接续（automation id xxx），约 N 分钟后自动开新会话，不需要你操作」。

为什么这句非有不可（实测缺口，⛔ 不是想当然）：2026-10-14 本会话已到三级告警 （.budget-alert-level 记 23715e76…→ 3），而接续会话一封都没建 —— 宿主库里名字/提示含「接续」「交接」的排期命中 0 条。根因是钩子只负责"叫"（源码明写「钩子开不了新会话」），建会话要会话里的模型走一次性 automation；少了「必须建＋报 id」，叫完仍可能没人建。

⛔ 没动架构文档：references/architecture.md §③ 讲的是接续会话的命名规范（标题怎么起），与本处「是否必须建」互补、不冲突 ⇒ 属"别处已覆盖"，改它才是半改。

验收：全量自测 PASS 110 / FAIL 0（确认没有判据锚定改的那两句 —— 今天已因"判据锚点过期"栽过两次）。

⚠️ 提交时发现：有另一个会话在并发改同一批文件

git status 里除了我这处，还躺着别人的改动（我一律没碰）：

humanizer-zh/ 整包被删（LICENSE / README.md / SKILL.md 三个 D）；
product-planning/SKILL.md 的「判据来源」被改写成「只有 humanizer 一份，humanizer-zh 已整包删除、不再引用」，并把门槛改成「中文自动评分没可信来源 ⇒ 改人工五维评分 ≥45/50」；
我操作期间又新增 4 项：product-planning/references/stage-discovery/SKILL.md、 session-mechanism/SKILL.md、session-mechanism/references/collab-detail.md、 session-mechanism/references/作业规矩/04-去AI味和说话方式.md、改包纪律.md。

⇒ 判读：另一条线正在做「去 AI 味」相关改造（连 04-去AI味和说话方式.md 都动了）。判据：提交时只 git add 自己改的那一个文件，⛔ 不 git add -A （否则把别人半拉的改动一起带进提交）。

🔴 沉淀：技能仓是被多会话共写的 ⇒ 提交动作一律点名单文件加入，⛔ 不用 -A。且"剩余未提交"从 5 项涨到 9 项这件事本身就是信号 —— 看到它变多，就说明有别人在并发改，别顺手带上。

7.1 KiB Raw Blame History Unescape Escape