跳转至

BASELINE：token_proxy 稳定层

本文件装稳定内容——环境事实、机制与陷阱、命令速查、文档地图。 变化的状态与待办在 docs/HANDOFF.md；历次变更过程在 docs/SOP.md。 更新触发：拓扑 / 版本 / 路径 / 服务名 / 命令入口变化时；以及机制性结论被实测推翻时（如 2026-10-07「hooks.json 须重启」被证伪——本文件不被注入、只在主动查阅时暴露，腐化更隐蔽）。否则不动。

1. 环境事实【已确认】

项 值
主机 / 工程 192.168.31.250（用户 rain）/ /home/rain/Documents/services/token_proxy
监听 / 白名单 0.0.0.0:8788 / 192.168.31.0/24 + 127.0.0.1/32
路由 ds→DeepSeek / glm→智谱 / mi→api.xiaomimimo.com/v1（路由表在 config.yaml 的 routes，加新上游只改配置、不改代码）
服务 systemd 用户服务 token-proxy（linger 已开，开机自启）
不可再生数据 logs/usage.jsonl、logs/balance_history.jsonl、logs/req_shape.jsonl、logs/guard_events.jsonl、logs/tool_timing.jsonl —— 绝不可删（五个均为 append-only）
全局规则 / Hook ~/.trae-cn/user_rules/*.md（5 个）/ ~/.trae-cn/hooks.json
Hook 脚本 sessionstart-hook/、docs-read-hook/、glob-grep-guard/、webfetch-guard/、merge-guard/、sched-guard/、handoff-landing-guard/、script-safety-guard/、shadow-check-guard/、posttooluse-guard/、tool-timing-hook/ —— 11 个脚本 / 14 条挂载（hooks.json 的活跃消费者；2026-10-12 核实，旧记「7 个 / 10 条」已过期）
工程外写死路径 见 docs/SOP.md 30.9；Hook 侧为 hooks.json 的 11 条 $HOME 路径（每个脚本一条）
代理侧机制 thinking.inject: true；DeepSeek 按会话档位注入思考与 reasoning_effort（三档：off = disabled 不带 effort / low = enabled + low；high = enabled + high，默认，2026-10-11 由 low 改 high），升 high 四类信号：失败窗口 / 疑难关键词 / 优化关键词 / 手动口令（词表见 config.yaml）；GLM glm-5.3* 与 MiMo mimo-* 原样放行；计价映射含 deepseek-chat: deepseek-v4-flash
merge-guard 判据级别 全部仅提醒（2026-10-11 用户裁定清空 ENFORCE_MARKS，不再 deny；判据全是效率目的，用拒绝纠正效率建议属语义错位）；INJECT_MAX=99（旧值 2 是跨判据总计数，会让整会话只轮到 2 条判据），每条判据每会话至多提醒 1 次。判据 S 另排除 wrapup.py / backup_ledger.py / cost_audit/ 目录；判据 H（内联 heredoc python3 - <<EOF，窗口内 ≥2 次 → 脚本化提醒）与 S 共用台账、分桶不串。提醒有效率按 remind_ineffective ÷ remind 算（提醒后 10 min 内同判据再命中即记无效，属代理指标）。完整判据清单以脚本头注为权威
计费单价 命中 0.02 / 未命中 1.0 / 输出 4.0（元每百万）；步/轮分母用 conv_key#turn_seq

2. 机制与陷阱

  • 三层机制：Hook ✅ 必然 > Rules 🟡 靠遵守 > Skill 🔴 概率 → 「必须发生的事」不能托付给 skill。
  • 全局 Hook（3 事件）：SessionStart 注入中文指令 + HANDOFF + 过账提醒；PreToolUse 的强制面（JSON deny）共 6 个脚本（2026-10-13 核实；sched-guard 当日降为提醒）：docs-read-guard（读已存在文件 >32 KB 且未带 offset/limit，图片豁免）、glob-grep-guard（无目录限定通配 / 过浅目录列举，判据 G/H）、webfetch-guard（距上一次抓取不足 120 秒的连续抓取，判据 W）、handoff-landing-guard（写 docs/HANDOFF.md 预计越 14.5 KB 动作线或 16 KB 硬线，判据 H）、script-safety-guard（写脚本命中红线，判据 D1~D5）、shadow-check-guard（工程内存在共享库同名副本）；一律「指纹重发即放行」，另设每会话上限的有 glob-grep-guard / sched-guard / handoff-landing-guard（各 3 次）。merge-guard 全部判据仅提醒（级别见 §1）；sched-guard 自 2026-10-13 起同样只提醒（命中调度动词 scontrol/srun/sbatch/scancel/bsub/bkill 即注入一行提醒、绝不 deny，同一命令每会话至多提醒一次；档案 sched-guard-remind-20261013/），其余守卫为提醒或注入；PostToolUse(写类工具) 命中 user_rules / commands / hooks.json / SKILL.md 的 description 后分档提醒。改 hooks.json 与改 Hook 脚本均即时生效（2026-10-07 实测：新增两条挂载后下一次工具调用即落盘，期间未重启 Trae；旧「hooks.json 须重启」的说法已证伪）；判据能否生效取决于 matcher，不取决于脚本——glob-grep-guard 曾因缺 LS matcher 而静默失效。
  • 前缀缓存边界（2026-10-11 修正；2026-10-12 补生效时点）：会整段失效的是落在 system prompt 前部的改动——skill 的 description / 增删 skill / thinking.prompt_hint（实测增 skill 得 176,394/189,706=93%、开 prompt_hint 得 miss=282,917）。而改 user_rules 文本 / skill 正文 / references/ / 项目档案只产生极小 miss（复测 2%）——user_rules 随用户消息注入、不在前缀顶部，只重建被改的那一段（2026-10-12 实测轮首未命中 1.6%）；skill 正文与 references/ 按需加载、根本不进前缀（同日实测 tools_hash 未变）。生效时点统一为「同会话下一次请求」，不是下一轮对话 / 新会话。旧口径「user_rules 改动会使前缀失效」被实测推翻。
  • 「要不要为此开新会话」（2026-10-07 立、2026-10-11 细分、2026-10-12 更正）：改 user_rules 文本 / skill 正文 / hook 脚本 → 不必开新会话（本会话内改、几乎无额外 miss，复测 2%）。「增 / 删 skill」或「改 skill 的 description」会整段重建（实测 93% ≈¥0.18），但同样不必开新会话——一次整段重建（≈0.18~0.43 元，随上下文规模）仍低于切会话固定开销 F ≈ 49 步 ≈ 0.58 元/次。旧建议「这类改动该在『新会话』里做」与旧口径「每轮多付 ≈0.35 元 / 改完即开新会话只付 ≈0.03 元」一并作废；「为省 token 而无谓切会话是亏的」仍成立。
  • Hook 脚本红线：绝不能以非 0 退出码结束且 stderr 必须为空（防脚本故障干扰主流程；例外：merge-guard 经批准升级为强制拦截，其 deny 走 JSON 协议并在 stderr 复写理由）；PostToolUse 纯文本回注无效，须用 additionalContext JSON；state / 日志一律相对脚本自身位置推导。
  • PreToolUse 的 deny 不能靠退出码（2026-10-07 实测）：hooks.json 的命令行结尾为 || true; exit 0，会吞掉脚本退出码——脚本内部即使 sys.exit(2) 仍被放行（state 已记 deny、调用照常执行）。要拦截必须由脚本输出 JSON permissionDecision: "deny" + permissionDecisionReason。
  • Hook 侧 tool_name 与请求体名不一致（2026-10-07 实测）：请求体里的 SearchReplace，Hook 收到的 tool_name 是 Edit；Read/Grep/LS/Write/RunCommand 则同名。按请求体名写判据会静默失效——merge-guard 的判据 C 因此自上线起从未在真机触发，须在 Hook 入口做别名归一化（TOOL_ALIAS）。
  • PostToolUse 守卫的写类工具白名单是 WRITE_TOOLS，新增写类工具名须同步，否则提醒静默失效。
  • 请求体改写边界：代理改 thinking / reasoning_effort（prompt_hint 2026-10-02 启用、2026-10-06 关闭、2026-10-11 重新启用并固定为中文指令文本，启用那一刻一次性全量重建 miss 282,917 ≈¥0.28；勿改其文本，一改即再重建一次），并自 2026-10-07 起把 tools 数组按 function.name 稳定排序（normalize_tools_order()；仅重排、不改内容、幂等），不改消息条数结构。system 位于前缀最前——任何 system 变动（含客户端 tools 集合变化）都会使整条会话的历史前缀全量重建；prompt_hint 开启/关闭那一瞬即属此列。2026-10-12 起另有一处「消息内容」改写：答复形状检查（reply_check）在新一轮首请求回看上一轮 assistant 答复，缺四列表或「要你拍板：」行时，把提醒追加到本条用户消息末尾（不改条数、不动 system，故不影响前缀命中；命中时 usage.jsonl 的 meta 记 reply_nudge_applied）。开关见 config.yaml 的 reply_check.enabled，档案 reply-nudge-20261012/。
  • 「轮首 tools 顺序抖动」是独立的一类冷启动，且可修（2026-10-07 实测，全库 18,432 步 / 263 会话）：Trae 每轮重组 tools 数组，tools_hash 变、但 tool_defs 与排序后的 tool_names 完全不变（真实增删 = 0）→ 上游判前缀失效、整段重建。短间隔（≤5min）且单步 miss ≥5万 的 50 步中，21 步属此类、全部落在轮首、合计 4.34 元 / 25 天（占 58%）；另 21 步（1.92 元）tools_hash 相同却未命中 = 上游 best-effort，不可控。对策：proxy 侧排序，见 tools-order-20261007/SOP.md。注意：build_shape_fingerprint() 必须在排序之前执行，否则 tools_hash 会失去"区分顺序抖动与真实增删"的判据价值。2026-10-07 07:35 起对策已生效：生效后同口径真顺序抖动 0 步（生效前 21 步 / 4.337 元，口径可复现）。另发现排序补不回的第 4 类残留——客户端改工具定义内容（工具名与顺序全同、tools_hash 变）引起的整段冷启动，wrapup.py 已单列为「定义内容变动」（实测 1 步：20:30:43，miss 84,309 tok），见 wrapup-tools-jitter-20261007/SOP.md 第 9 节。
  • 指纹字段分工（2026-10-06）：tools_hash = 整个 tools 定义数组的哈希，含顺序（json.dumps(..., sort_keys=True) 只排 dict 键、不排 list）；tool_defs = 按原序的工具名列表（用于区分「增删」与「顺序抖动」）；tool_names = 本步实际调用的工具名。三者不可混用——工具集变化常发生在未被调用的工具上，故只看 tool_names 看不见 tools_hash 的变化（实测：90 次变化中 0 次伴随新工具调用）。
  • 贴图 ≠ 前缀失效（2026-10-06 复测修正；证据见 MB §1「归因修正」）：同会话贴图步实测 prompt 10.8 万、miss 仅 4.4 k（命中 96%），未打碎文本前缀；旧记录把 22 万+ 长会话的 ~20 万 miss 归因于贴图，真因更可能是上下文压缩/规模。判「前缀是否失效」看中段（非轮首）是否出现旧内容的大 miss，不看该步 miss 绝对值。

  • 「可并组」主口径与分列（2026-10-06 更新）：step_profile.py 主口径为「未合并块」——连续 ≥2 个单工具步（tool_names 恰 1 个且末尾为 tool 结果）构成的块，不设末尾大小门槛；同口径给出「已合并率」= 一步多工具步 ÷ 有工具名步。旧「碎步组」口径（连续 ≥3 步且末尾 <2000 B）保留作跨轮可比。两口径均按动作类型全集 12 类分列（查-读取 / 取数命令 / 改-验循环 / 改 / 增 / 删 / 编排 / 计划 / 等待 / 交互 / 展示 / 其他），每类带可合并性（merge / partial / na / unknown），并给出「可并类合计」（不计 编排·交互·展示·其他）；另给旧 5 类聚合（只读 / 取数命令 / 改-验循环 / 纯编辑 / 其他）供跨轮可比。旧口径实测只覆盖 1985/3953 步（约一半），漏掉 2 步组（+179 组 / 358 步）与大结果步；基线（2026-10-06）：未合并块 439 组 / 2346 步、已合并率 33.7%、可并类合计 426 组 / 2315 步（98.7%）。分类只做归类、不判依赖（req_shape 不记工具参数），有依赖的必须串行。

  • turn_key 会被客户端复用，不能当「每轮唯一」用（2026-10-07 实测）：历史 1,205 个 turn_key 中 1,071 个（88.9%）被复用，最大样本含 807 步、跨度 21 天。故任何「按 turn_key 聚合后取首→末步跨度」的口径都会失真——wrapup.py 的「时间墙」因此曾报出 30,567 min（≈21 天） 的假象（同一样本切分后为 10.3 min）。正确做法：先按活跃段切分（相邻请求间隔 > IDLE_SECONDS = 900 即断开），再取最后一段——wrapup.py 已用 active_tail() 修正（wrapup-turn-span-20261007/），efficiency-sides-20261007/profile_time_sides.py 自始即用该口径。连带：凡用 turn_key 做分组统计（步数 / 费用 / 合并 / miss），都要先切分，否则会把十几天前的旧段算进来。根因（客户端为何复用）未查。

  • 诊断工具/指标的口径必须自证，否则会把正常结果判成故障（同族两条）：① remote_cmd_profile.py 曾把同一次远端执行被 run_cmd 与 exec_linux 各记的一条日志算成两条命令 → 命令数与重复数双双虚高约一倍，据此一度误判「缓存改造未达标」（MB §三十）；② 上一条的 turn_key 复用同属此类。判据：新取数脚本首次使用前，先拿一个已知答案的样本对账。

  • 「逐条」与「批量入参」是两个不同量级，合并调用 ≠ 批量入参（2026-10-07，slurm_ins deploy 阶段实测）： ① 合并调用（N 次往返 → 1 次）省的是握手 / 往返——agent 侧由判据 A/E 强制； ② 整批入参（一次调用处理 N 个对象，如 rpm -q pkg1 pkg2 … 取代 for p in …; do rpm -q $p; done）省的是进程启动与解析。 二者不可互相替代：slurm_ins 三项改动里，整批入参那项是最大单项收益（十来个包逐个起 rpm 进程 → 一次查询； deploy 阶段 7.2 → 4.0 s、远端命令 41 → 18、整体墙钟 13.83 → 10.34 s；本会话累计 247.7 → 10.3 s）。 同族口径：exec_linux 内部是 for cmd: conn.run_cmd(cmd)——一次传多条命令不减往返，必须拼成一条 shell； 同理 RunCommand 一次发多条也不等于整批入参。判据 L（仅提醒）覆盖「命令含逐项循环」这一形态。

  • 操作基准分析 = 「账 → 拦」闭环的底账（2026-10-08 上线）：cost_audit/baseline_check.py（由 cost_audit/wrapup.py 每轮自动调用）把本轮每步按「类别 + 规模」（如「读 · 小」）归堆，对照 cost_audit/ops_baseline.json 判 正常 / 异常 N×（偏离 ≥3 倍）/ 沉淀基准（样本 <3 条）；异常追一条到 cost_audit/ops_incidents.md，收尾回吐「本次入账 N 条」。无异常也沉淀——累积成「某场景调某工具正常该几秒、几 tok」的最优实践标尺。数据取自既有三份日志（usage 的 token / tool_timing 的耗时 / req_shape 的规模），不改代理。读者是模型自己、不是用户，只为让下一个任务更短更省；终局清算成 merge-guard 判据（现 13 强制（A/C/D/E/F/I/J/L/N/O/R/T/U）+ 5 提醒（B/K/M/P/Q）；2026-10-09 按空转率回收 M/B/K，并新增 T / U）。 可见性坑（2026-10-08 实证）：本机制原先只活在代码与一个 references/ 里，HANDOFF 与全局规则均未登记 → 同项目另一会话被问到时答「没有此物」，并把旧台账说成「给用户看的玩意」。教训：新机制必须登记进新会话会加载的地方（SessionStart 注入的 HANDOFF、全局《收尾自查》、skill 正文），否则等于没做。

  • 旧「实测基线台账」已整体移除（2026-10-08）：references/measured-baselines.md 与其「每轮变更样本」自动回填（wrapup.py 的 autofill_baseline / --note）全部删除（skill 侧全文亦已物理删除，无留存）。现行可比基线只有 cost_audit/ops_baseline.json（baseline_check.py 机检）。相关旧口径（0.35/0.03 元、「回填 MB §N」、「已回填样本行」）一律作废，勿再引用。注：docs/measured-baselines.md（4 节残片）是另一份历史归档、口径已废，见其页首横幅。

  • Trae 权限档会被重启写回默认，已上系统级守护（2026-10-09 实测）：~/.trae-cn/permission/global.json 每次 Trae 启动被重写为默认（filesystem.default=read_only、可写白名单仅 /tmp、无通配命令规则），且 Trae UI 无对应入口；被重置后 shell 写该文件会被沙箱拦（TRAE Sandbox Error: hit restricted）。守护 = systemd 用户级 trae-perm-guard.path（PathChanged/PathModified，事件驱动、秒级）+ .timer（60 s 兜底）→ 调 token_proxy/trae-perm-guard/perm-converge.py，只收敛三项不变量（readWrite 含 /home/rain、default=read_write、commandRules["*"] 放行），其余字段一字不碰、幂等、非法/半截 JSON 不碰。关键：systemd 起的进程在 Trae 沙箱之外，故能写该文件——这是「shell 改不动、守护改得动」的原因。变更/判据/回滚见 token_proxy/trae-perm-guard/backup/README.md。

  • 前缀缓存探测（cache_probe，2026-10-11 上线并补快照过期判据）：空闲 ≥1 h 时，首个请求先探本次请求的前缀，命中 <90% 即拦（返 500），拦后冷却 120 s；工具定义指纹变化则免探测直接拦。快照 TTL 24 h，快照过期即判无缓存（修「超长空闲盲区」：空闲 >24 h 时旧机制静默放行）。开关 config.yaml 的 cache_probe.enabled；档案 cacheprobe-expired-20261011/。仍待观察：快照龄 >24 h 的真实拦截路径（需等某会话空闲 >24 h）。

  • merge-guard 判据 W 与备份清理（2026-10-11）：同一会话累计 ≥15 步仍未见 wrapup.py → 提醒一次（收尾自查此前无 hook 兜底，纯文本口径）；WRAPUP_STEP_NUDGE=15 松紧待标定。docgen/backup_ledger.py --prune 按「双 3 天」（备份龄 / 已被取代 / 源静默）列出可删备份，默认只报告，--delete 需显式授权；流程见技能 backup-hygiene，档案 backup-hygiene-20261011/。实盘首测：可删 18 / 需人工 156。
  • 跨天整段重建的真因与用户习惯（2026-10-12）：失效源是 WebSearch 工具 description 内嵌的 Today's date；触发点是「跨天后新开一轮的首个请求」，跨天当时仍在旧轮内续跑不触发（实测三条请求指纹未变、命中完好，miss 分别为 215,804 / 237,564 ≈¥0.43）。用户习惯：跨天后先在客户端就地压缩上下文再继续，重建额随上下文规模线性下降；不为此开新会话。
  • 远端操作入口（2026-10-11 固化）：多主机只读取数走共享库 ~/py_public_modules/remote_exec.py——一个进程内复用连接 + 主机间并发 + 每台一条 shell 一次往返（6 台实测 0.927 s / 1 轮；逐条 ssh 为 5.472 s / 6 轮）。merge-guard 判据 Z（检测 ssh 直连 → 提醒走入口）与判据 Y（写盘跨出当前工作区 → 提醒落盘归属）均为提醒级、每会话一次。跨项目落盘口径（谁被改、落谁家）见全局规则 rule-ops-evidence-constraints。档案 remote-exec-20261011/。

2.1 成本模型与「已证伪结论」清单（2026-10-06）

由来：2026-10-06 一轮对话中，同一问题连续给出 4 个被推翻的结论（详见 MB §二十五「修正~第八次」）。 下列为已核实事实与禁止重犯的错误结论。讨论成本 / 会话切换 / Hook 阈值前必读本节。 ⚠️ 本节的结论优先于历史台账（原 measured-baselines.md §二十五；skill 侧该文件已于 2026-10-08 删除，留存归档见 docs/measured-baselines.md 页首横幅）——历史序列含已被推翻的中间结论，只可用于追溯、不可用于决策。 ⚠️ 本节内部亦残留旧口径（2026-10-06 二次修正）：表中「不切要贵 6.5~19 倍 / 103.55 元」（#3）与正文「支出 ≈ 0.098 元」「切省 0.058 / 0.195 元/次」均为只算"重放边际差"的旧口径，已由本节「每次切换的真实代价（F ≈ 49 步 ≈ 0.58 元/次）」取代——决策一律以 0.58 元/次与「为省 token 而切会话是亏的」为准，旧数字仅作推演过程保留。

成本公式（唯一口径，与 cost_audit/*.py 一致）

成本 = Σ(命中 × 0.02 + 未命中 × 1.0 + 输出 × 4.0) / 1e6 元     # 命中价仅为未命中的 1/50

成本优先级：少输出 > 少未命中 > 少历史（输出 ¥4/百万 = 命中价 ¥0.02/百万 的 200 倍）。本条原仅在 docs/HANDOFF.md，2026-10-06 落入稳定层。

实测结构（2026-10）：输出 50%（其中思考占 59~66%）、命中 25~30%、未命中 20~24%； 每步成本 ≈ 0.0126 元 = 命中重放 0.0031 + 新增未命中 0.0031 + 输出 0.0065。

前缀失效（大 miss）归因（2026-10-06；口径与样本见 cost_audit/analyze_prefix_fail.py）

样本：2026-09-16 ~ 10-06，单次 miss>10,000 共 600 条 / 22.3 M tok / 30.0 元；以同会话相邻两步做对照（失效对 vs 正常对）。

主因 条数 成本 占比 可控性
F 无结构变化（上游缓存过期等） 320 12.37 元 47.8% 不可控
B 仅 tools 变（改工具 / 技能定义） 25 5.08 元 19.6% 已有措施
C system + tools 同变 33 4.34 元 16.8% 已有措施
E 仅历史中段变 107 3.69 元 14.2% 成因未明
A 仅 system 变（改规则 / 技能） 3 0.14 元 0.5% 已有措施
D msgs 减少（上下文压缩 / 剪枝） 2 0.28 元 1.1% —

读数：① 失效的近半成本（47.8%）在上游缓存侧，proxy 无法干预；② 与 system / tools 变动相关的 B+C（36.4%）已有措施且近期回落（09-19 建设期 2.45 元/日 → 10-05·10-06 约 0.24~0.29 元/日）；③ 仍未归因的只有 E 类 3.69 元。→ 「治大 miss」的净可优化空间约 3.7 元（约占全期总成本 200 元的 1.8%），不再就此投入；勿再重跑归因，直接查本表。

三条稳定事实

  1. 思考不入上下文：reasoning_content 不回传、只计输出费——"重放"里没有思考；
  2. 上下文重放不贵：单价 1/50，32.5 万 tok 仅 0.0065 元/步，1 M 也才 0.02 元/步；
  3. 新会话不携带旧内容：首步 prompt_tokens 中位 3.2~3.7 万；增长曲线 1 步 34 K / 10 步 71 K / 30 步 145 K / 80 步 274 K。
  4. 闲置会让前缀失效、时点不定【已确认｜2026-10-08 改写】：旧口径用了新会话首步（隔夜 30.8% vs 10 min 内 28.7%，两者无差异 → 测不出 TTL，故曾误判为"不失效"）；改按同会话内空闲后首步重算， 全 miss 占比随空闲时长递增：<10 min 0.32% ｜ 1–3 h 19.0% ｜ 6–12 h 42.9%（3/7）｜ >24 h 45.5%（5/11）。 → "怕过夜要重付全量"成立（>6 h 近半次数全额重建）；但结论不是"因此要切会话"—— 切会话 ≈0.58 元/次，手动压缩仅 0.155 元/次（见下「不切会话路线」）。 判据：看同会话内空闲后首步的 miss，不看新会话首步。样本 n=7/11，单点值仅供参考； 但 0.32% 与 42.9% 的对比极显著。

切会话的收支（算式，勿再凭感觉）

  • 支出 ≈ 0.098 元（重新探索多跑 ~7.8 步 × 0.0126）；
  • 收益 =（旧上下文 − 新会话当步上下文）× 0.02 × 剩余步数；
  • → 在 35 万处切，盈亏平衡点约在"之后还跑 20~30 步"，而实测剩余步数恰在此量级 = 收益≈0。

实测校验（9 月「长会话模式」 vs 10 月「勤切模式」）

区间 会话 曾达 35 万 跨过 35 万后剩余步数（P50 / P75 / max） 不切（尾部重放） 切（重放＋探索） 切省
09-12~09-30（19 天） 143 32 个 37 / 98 / 270（均值 68.9） 17.88 元 11.64 元 6.24 元 = 0.195 元/次
10-01~10-06（6 天） 112 12 个 26 / 52 / 79（均值 27.1） 2.63 元 1.93 元 0.70 元 = 0.058 元/次

读数：

  1. 9 月的长会话跑得远得多（P50 37 vs 26 步，max 270 vs 79），此时"切"的边际收益才显现（0.195 元/次）；
  2. 但这 32 次合计 6.24 元 / 19 天 = 0.33 元/天，仅占 9 月日均成本（7.17 元）的 4.6%；
  3. 上述「切省 0.058~0.195 元/次」仅是重放边际差，未含新会话固定开销（F ≈ 49 步）；计入后切会话是亏的（见下「每次切换的真实代价」）——故 1、2 两条不能读作"切更省"。 步数增量归因（2026-10-06 修正；此前"任务量本身增加"的说法是错的）
会话/天 步/会话 步/天
09-20~09-30 10.4 68.5 712
10-01~10-06 18.7 59.8 1119
  • 增量 +407 步/天：其中会话数增加贡献 +568 步，每会话步数下降回吐 −161 步；
  • → 会话数（即"切任务"）解释了全部增量（贡献 568／净增 407 = 140%，被每会话步数下降抵消一部分）；
  • 反证：10 月若仍只开 10.4 个会话 → 622 步/天，比 9 月的 712 步还少 → 任务量并未增加；
  • 成本端：多出的 ~407 步 ≈ 4.8 元/天，占日成本增量（6.42 元）的约 75%。

结论：成本上升的主因就是「切任务」——每切一次都要重付一遍定位 / 注入 / 探索的固定开销， 会话数翻倍直接推高步数总量。（此前"切只解释 13%"错在把切换开销窄化成 7.8 步，忽略了每个新会话都要重走的前段。） 每次切换的真实代价（2026-10-06 二次修正）：设每个新会话有固定开销 F（重新定位 / 注入 / 探索）、任务总量 T：

9 月  : 10.4F + T = 712
10 月 : 18.7F + T = 1119
相减  : 8.3F = 407  →  F ≈ 49 步/会话 ≈ 0.58 元/次

与实测"续做型首轮总成本 0.44~1.15 元"量级相符；每天多切 8.3 次 × 0.58 = 4.84 元/天 = 日成本增量的 75%。 此前"0.05~0.2 元/次"只算了尾部重放的边际差，漏掉新会话重新定位 / 注入 / 探索的步数，低估 3~12 倍（=0.58÷0.2=2.9 ~ ÷0.05=11.6；旧稿"约 6 倍"系取区间中点，2026-10-06 改为区间）。

推论（重要）：为省 token 而切会话是亏的。 要收回 0.58 元/次的固定开销，需"切完后还跑 70~116 步" （旧上下文 35~50 万 vs 新会话均值 ~10 万 → 每步仅省 0.005~0.008 元）；而实测长会话跨过 35 万后 P50 只跑 26~37 步 → 切不回来。切会话的正确理由是"效率与判断质量"，不是省钱。

窗口 1433 K 下的切点量化（2026-10-06，参数全部由实测反推）

参数：起始 34 K、每步 Δ 2.8 K、每次切换固定开销 F 49 步、重放单价 0.02/百万、每步其他 ≈ 0.0095 元、每天净任务 203 步。

切点 步/会话 会话/天 总步数/天 成本/天
~200 K（实测现状） 59 19.7 1170 13.85 元（模型；实测 14.15）
300 K 95 4.4 419 5.38 元
400 K 130 2.5 325 4.49 元
500 K 166 1.7 288 4.27 元
600 K（最优） 202 1.3 268 4.24 元
700 K 237 1.1 256 4.31 元
800 K 273 0.9 247 4.41 元
1000 K 345 0.7 237 4.69 元

结论：① 800 K 切比 300 K 切省 18%（0.97 元/天），步数少 172 步/天；② 最优切点约 600 K（4.24 元/天）， 过 800 K 后回升（重放增速超过固定开销的节省）；③ 实测的 ~200 K 切是全表最差点（13.85 元/天）—— 因固定开销占了 82% 的步数。

不切会话路线：手动压缩点模型（2026-10-07 实测）

前提：长对话永不切（切会话固定开销 F ≈ 49 步 ≈ 0.58 元/次，见上），改用 Trae 客户端「压缩」按钮就地压。 本模型不计 TTL 失效，只算对话成本（用户指定口径）。

模型：设压缩后上下文 A、压缩点 L、每步增量 Δ、重放单价 p、单次压缩代价 K：

f(L) = p·(A+L)/2 + K·Δ/(L−A)        →        L* = A + √(2KΔ/p)

实测参数（2026-10-07）

参数 值 来源
p 2e-8 元/tok（0.02/百万） 成本公式
Δ 2,028（P25 1,121 / P75 3,584） 18,821 步
A 47,162（手动压缩后）；168,300（自动压缩历史中位） 10-07 23:38 实测
K 0.155 元 = 压缩请求 miss 129,135（0.129）+ 摘要输出 6,584（0.026） 同上

结论：L* = 47,162 + √(2×0.155×2028/2e-8) ≈ 224,000。

压缩点 L 每步成本 相对最优 回本步数
200 K 0.004528 +0.9% ~51
224 K（理论最优） 0.004489 — ~44
300 K（实操取值） 0.004715 +5.0% ~31
400 K 0.005363 +19.5% ~22
600 K（自动压缩触发区） 0.007040 +57% ~14

实操取 300 K：曲线在 200~350 K 平坦（≤+12%），300 K 仅比最优贵 5%，换更少中断与更充裕上下文——符合成本优先级「少输出 > 少未命中 > 少历史」（压缩省的正是末位的"历史重放"）。上限 400 K。

两条机制事实【已确认】

  1. 手动压缩请求不带 tools（req_shape 记 tool_defs=[]）→ 无前缀可复用 → 该步必然 hit=0 全量未命中（129,135 tok = 0.129 元）；压缩后的正常请求前缀仍命中（system+tools ≈ 22.9 K）。
  2. 压缩会改写对话首条 → conv_key（= sha1 首条 user 文本）变化，按 conv 的统计会断链——判断"是否发生过压缩"不能只看 conv_key。

与切会话对比：手动压缩 K=0.155 元/次 < 切会话 0.58 元/次（便宜 3.7 倍），且用户输入不丢（压缩只丢工具输出与助手回复）。档案：compress-point-20261007/。

Hook 阈值（2026-10-08 落地）：已按不切会话 + 手动压缩路线改为 CTX_THRESHOLDS = (300_000,)，文案同步改为「已达手动压缩点（≈300 K）：建议就地压缩，而不是开新会话」； STEP_THRESHOLDS = ()（步数维度停用）。改阈值必须同时改文案——两条路线的阈值语义相反 （切会话最优 600 K vs 压缩点 300 K），只改数字会自相矛盾（300 K 处提醒"开新会话" = 推向最差点）。 配套：shadow-check-guard 无关；本条只涉 posttooluse-guard/skill-edit-guard.py。

作废记录：旧的「现值 35/50/70 万、过早触发 / 建议改窗口比例 573/860/1146 K」属切会话口径， 已随路线切换作废，勿再引用。

模型假设：F = 49 步为拟合值（含"任务量不变"假设）；相对比较对 F 敏感，但方向稳定。

K 的实测口径（2026-10-10 补测，90 次压缩事件）

上面记的 K = 0.155 只是某一规模下的取值，不是常数。实测口径：

K = 输入 tok × 1.0 + 输出 tok × 4.0        （输入恒按未命中全额计）
实测时刻 输入（miss / hit） 输出 K
10-07 23:38 129,135（全 miss） 6,584 0.155 元
10-10 00:20 350,719 / 21,760 1,328 0.357 元
10-10 02:01 315,711（全 miss） 9,789 0.355 元

三行均严格符合上式。输入越大越贵，按 1.0 元/百万线性增长；「0.155 元一次」是 12.9 万输入那次的成本，不是压缩的固有价格。

回本步数：36 次可算样本（有压缩前同会话上下文 + 压缩后新基数），压缩后每步省 = 降幅 × 0.02/百万，回本步数中位 39 步（P25 32 / P75 54）。它与上下文绝对规模弱相关——压缩成本按未命中价 1.0、每步收益按命中价 0.02，两者比值恒定 50 倍。

判据设计约束（2026-10-10 定）：回本步数是事后统计量，「剩余步数」事前不可知 → 不得把压缩判据改成「剩余步数 ≥ 40」，CTX_THRESHOLDS = (300_000,) 维持现状。压缩只回答「这一笔花多少」，不回答「该不该压」。

已证伪结论（禁止重犯）

# 错误结论 正确的说法
1 成本 ≈ 步数 × 上下文规模 重放单价 1/50，非主项；每步主项是输出（思考）
2 思考会被重放 思考不进上下文，只计输出
3 切会话推高成本 / 很贵 切会话省重放；不切要贵 6.5~19 倍（10-02 理论多花 103.55 元）
4 切换成本 = 0.03 元 那只是首步 token；"续做型"首轮实测 0.44~1.15 元
5 用跨期均值做因果（9 月 vs 10 月单步成本） 无对照的跨期比较不能归因
6 双峰分布取均值 先按性质分层（"续做任务" 0.44~1.15 元 vs "只问一句" 0.006~0.08 元）
7 每步都贵（32.5 万 × N 步） 0.0065 元/步；1 M 也才 0.02 元/步
8 减步数是控成本主杠杆 步数主要影响效率侧；成本主项是每步的输出
9 建议把 Hook 阈值降到 15 万 无支撑、已作废（切换成本被严重低估）
10 Hook 会话规模提醒"尚未实现" 2026-10-02 已落地（ctx-warn-20261002/ 为其回归用例）
11 成本上升主因是"任务量增加"，切会话只占 13% 反证：会话数 10.4→18.7/天，而每会话步数反降 68.5→59.8 → 任务量未增；若维持 10.4 会话，10 月只需 622 步/天（少于 9 月的 712）。会话数解释 140% 的步数增量，成本增量 75% 来自多出的 ~407 步
12 单次切换只值 0.05~0.2 元 只算尾部重放的边际差；真实代价 ≈ 0.58 元/次（会话固定开销 ≈ 49 步），与"续做型首轮 0.44~1.15 元"相符，低估 3~12 倍（0.58÷0.2=2.9 ~ ÷0.05=11.6；旧稿"约 6 倍"取中点，不严谨）
13 「改 user_rules / skill 后须开新会话，否则持续吃 miss」；「改 skill description → 全量重建 36.5 万 tok」 两个都错（2026-10-07 实测更正）：本会话内分别改 user_rules、skill description、hook 脚本、skill 正文与项目文档，均未观察到前缀失效——改 skill description 后下一步 miss 仅 299 tok / 0.1%，其余各步 0.1~1.6%（正常区间）。推测 Trae 对更新后的规则/技能索引按增量注入，而非替换 system prompt，故不打断前缀。改动同会话下一次请求即生效（Trae 会话内即回注 "rules have been updated"）。开新会话省不掉任何 miss，反而多付首步固有 miss 3~6 万 + F≈49 步≈0.58 元。旧「36.5 万 tok」归因存疑——2026-10-01 那次未做对照，疑为其它原因

| 14 | 「重启代理会打断在途流式回答」（曾写进 HANDOFF 红线、规则《攒批重启》理由①、本节命令速查） | 推翻（2026-10-08 用户实测）：重启不会中断输出流——旧结论系推测、从未实测，且"影响好多次"。「攒批重启」已于 2026-10-09 整体作废（规则改为「可直接重启」，配套 merge-guard 判据 O 移除），故「重启清内存态 → 空闲保护缺席一次」也不再作为限制。禁止再用「会打断流式」解释或论证任何事 |

归因方法论（四条）：① 同时看量 × 价两维，只盯"价"会抓错主因；② 双峰分布禁用均值； ③ 无对照的跨期比较不做因果结论；④ 谈"切换成本"按整轮（含重新探索步数）计，不是首步 token。

3. 命令速查

systemctl --user restart token-proxy                    # 重启代理（不中断在途输出流；仅清内存态）
python3 -c "import urllib.request,json;print(json.load(urllib.request.urlopen('http://127.0.0.1:8788/healthz')))"   # 看路由
./venv/bin/python cost_audit/daily_review.py            # 当日审查四段事实（只读幂等）；新会话 /cost 出评估+建议
./venv/bin/python .trae/skills/cost-deep-review/scripts/session_deep_dive.py [--conv ID]  # 会话归因表 / 单会话深挖
./venv/bin/python cost_audit/analyze_usage.py           # 全局用量/成本分析（含步/轮分母口径）
./venv/bin/python cost_audit/step_profile.py [--top N | --conv ID]  # 会话步序列画像（重复读 / 未合并块 + 已合并率；分列动作全集 12 类 + 可并类合计）
python3 cost_audit/selfcheck.py --since "YYYY-MM-DD HH:MM:SS" --until "YYYY-MM-DD HH:MM:SS"   # 指定窗口消耗自查（须带秒）
python3 cost_audit/wrapup.py                            # 收尾四项：时间墙/步数取本轮 turn_key、费用取本会话累计 + miss≥5000 检测
python3 cost_audit/rule_compliance.py [--by week | --cut YYYY-MM-DD]   # 规则遵守率代理对照（DUP / 中段大 miss / 大输出 / 违规列举；B 类须覆盖≥80%）
tail -n 1 logs/usage.jsonl                              # 看最新记账（route 是否为 mi）
tail -n 1 sessionstart-hook/state/session-start.log     # 看注入命中与留痕字段

4. 文档地图

文档 管什么
docs/HANDOFF.md 当前状态快照（SessionStart 注入；目标 6 KB / 上限 10 KB）
docs/BASELINE.md 本文件——稳定层（环境事实 / 机制 / 命令速查 / 文档地图）
docs/SOP.md 历次变更档案（按节累积）
*/SOP.md（各主题目录） 单次变更的实施、验证与回滚；backup/README.md 为备份台账
md-文件清单.md 工程内 md 的作用与删除影响（含「哪些可删」判据）
cost_audit/*.py · reports/*.xlsx 只读分析脚本（analyze_usage.py 含轮次口径）；成本报表（cron 每日 00:00 刷新）
.trae/skills/cost-deep-review/ /cost 深挖技能（三阶段流程 + 归因与取证脚本）

5. 修订记录

日期 变更
2026-10-10 §2.1 补 K 的实测口径（K = 输入×1.0 + 输出×4.0，输入恒按未命中全额计，90 次压缩事件验证，其中 10-10 两次为 0.357 / 0.355 元）+ 回本步数中位 39 步（36 样本，P25 32 / P75 54）；并记判据设计约束：「剩余步数」事前不可知，不得用于替换 300 K 阈值。档案：compress-cost-20261010/
2026-10-13 sched-guard 由强制拦截降为提醒（用户裁定「我不拦，都改成提醒」）：删 _emit_deny 与 DENY_MAX，命中调度动词只注入一行提醒并按指纹每会话去重；§2 强制面由 7 个脚本改为 6 个。档案 sched-guard-remind-20261013/（含离线用例、备份与回滚）
2026-10-02 自 docs/HANDOFF.md 首次拆出（该文件达 10.8 KB 超硬限），建立稳定层
2026-10-02 命令速查补登 step_profile.py（前次遗漏）；req_shape 起记 shape.tool_names
2026-10-06 命令速查补登 rule_compliance.py（规则遵守率代理对照）；tool_names 自 10-02 起有值 → B 类指标无 pre 窗口
2026-10-06 新增 §2.1「成本模型与已证伪结论清单」：成本公式 / 实测结构 / 切会话收支算式 + 10 条禁止重犯的错误结论（同日连续 4 次翻案后固化）
2026-10-07 命令速查补登 wrapup.py（收尾四项取数）。口径：时间墙/步数取本轮 turn_key（= 末条用户输入哈希，轮内步进稳定、不含用户回答/暂停）、费用取本会话累计（conv_key = 首条用户输入哈希）；selfcheck.py --since/--until 是跨轮窗口、不得再用于「时间墙」
2026-10-06 §2 增「疑似可并组分列」机制、§3 速查同步——原只读口径仅覆盖 1% 可并机会（改-验循环占可省成本 79%，取数命令 15%）
2026-10-06 §2 可并组口径改主「未合并块 + 已合并率」、§3 速查同步——旧「碎步组」只覆盖 1985/3953 步（漏 2 步组与大结果步），旧口径降为跨轮可比项
2026-10-08 §2.1 增已证伪 #14：「重启代理会打断在途流式回答」推翻（用户实测，重启不中断输出流）；§3 命令速查同步。攒批理由只剩「清内存态致空闲保护缺席一次」一条
2026-10-06 分列扩为动作类型全集 12 类 + 可并类合计（§2 / §3）；Hook 清单补全为 6 条并登记 merge-guard（PreToolUse 合并提醒）
2026-10-07 §2 增「PreToolUse 的 deny 不能靠退出码」机制事实 + Hook 红线补强制拦截例外——merge-guard 升级为 A/B/D/E 强制拦截（JSON deny + 指纹放行），C 保持仅提醒；见 merge-guard-enforce-20261006/SOP.md
2026-10-07 §2 增「Hook 侧 tool_name 与请求体名不一致」（SearchReplace→Edit）；merge-guard 判据扩为 7 条（A/B/D/E/F/I 强制、C 仅提醒）——F = Write 覆盖已存在 >2 KB 文件；I = 文档类「改-验循环」≥3 轮
2026-10-13 §1 思考默认档更正为 high（2026-10-11 改，旧记 low 过时）；§2 更正 prompt_hint 状态（2026-10-06 关闭 → 10-11 重新启用并固定文本），并新增四条：前缀缓存探测（含快照 TTL 24 h）、判据 W 与备份清理、跨天整段重建真因与用户习惯、远端操作入口 remote_exec.py。四条均自 HANDOFF §1 落点搬移而来。档案 handoff-landing-20261013/
2026-10-07 §2「请求体改写边界」补 tools 按 function.name 稳定排序；新增机制条目「轮首 tools 顺序抖动」（可修类 4.34 元/25 天 vs 上游 best-effort 类 1.92 元）——见 tools-order-20261007/SOP.md
2026-10-07 §2 Hook 清单更新：glob-grep-guard 判据 G/H 升强制（LS 过浅目录 / 无目录限定 ** 通配），hooks.json 新增 LS matcher（须重启)；补「判据能否生效取决于 matcher，不取决于脚本」——该 Hook 曾因缺 LS matcher 静默失效
2026-10-06 §2.1 增「前缀失效（大 miss）归因」表（F 上游 47.8% / B+C tools·sys 36.4% / E 中段 14.2% / A·D 1.6%）——原结论只在 analyze_prefix_fail.py 的运行输出里，未沉淀，导致每次讨论都要重跑
2026-10-07 §2 机制条目「轮首 tools 顺序抖动」补生效验证（proxy 排序自 07:35 起生效，同口径真顺序抖动 21 步 → 0 步）与第 4 类残留「工具定义内容变动」（排序补不回，wrapup.py 判据加了「有序序列」维度并单列该项）——见 wrapup-tools-jitter-20261007/SOP.md 第 9 节
2026-10-07 §2.1 新增「不切会话路线：手动压缩点模型」——L* = A + √(2KΔ/p)，实测 A=47,162 / Δ=2,028 / K=0.155，理论最优 224 K、实操取 300 K、上限 400 K；并记两条机制事实（手动压缩请求不带 tools → 该步必然 hit=0；压缩改写对话首条 → conv_key 变、按 conv 统计断链）——见 compress-point-20261007/

来源：/home/rain/Documents/services/token_proxy/docs/BASELINE.md ｜ 最后更新：2026-10-13 01:51（由 build/sync.py 同步，请勿在站点侧修改）