成本与行为效率审查 · 区间台账 2026-10-01 ~ 2026-10-06¶
- 生成时间：2026-10-06 16:07（10-06 当天未完结，仅到 16:07）
- 数据来源：
cost_audit/daily_review.py --date <每天>（逐日四段）+.trae/skills/cost-deep-review/scripts/session_deep_dive.py（会话归因）+logs/req_shape.jsonl指纹比对（失效责任方） - 口径：区间总量一律取
daily_review台账（按模型/时段定价）；session_deep_dive的「折算成本」用统一价 (0.02/1.0/4.0 元每百万)，仅供同日相对比较，不与台账混用（两者在 10-01/10-05/10-06 相差 1.0~2.0 倍， 即 ds / glm / mi 三路由价目不同所致）。
① 区间汇总（6 天）¶
| 指标 | 数值 |
|---|---|
| 请求 / 会话 / 用户轮 | 6,460 / 112 / 393 |
| 步/轮 | 16.4 |
| 总成本 | 95.322 元 |
| 元/轮 · 元/请求 | 0.243 · 0.0148 |
| 四段成本 | 命中 24.443（25.6%）｜未命中 22.741（23.9%）｜输出 48.138（50.5%） |
| 思考 | 31.788 元 = 占输出 66.0%、占区间总成本 33.3% |
| token | 命中 1,026,277,120 ｜ 未命中 19,890,211 ｜ 输出 10,553,579 ｜ 思考 7,010,378 |
| 上下文中位（prompt） | 117k ~ 207k（逐日 117k / 133k / 143k / 152k / 145k / 207k） |
一句话：区间近 95 元里，一半是输出、其中三分之二是思考；命中重放 25.6%（步数 × 十几万 token 的前缀）； 未命中 23.9% 中可归因的大头是会话中段的一次性前缀重建（详见 ②）。
② 逐日趋势¶
| 日期 | 请求 | 轮 | 步/轮 | 成本¥ | 元/轮 | 命中 | 未命中 | 输出 | 思考占输出 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|
| 10-01 | 1,545 | 66 | 23.4 | 24.469 | 0.371 | 33.1% | 17.5% | 49.5% | 62.1% | 区间峰值日（步/轮最高） |
| 10-02 | 1,732 | 103 | 16.8 | 25.635 | 0.249 | 25.6% | 26.5% | 47.9% | 63.7% | 成本峰值日（规则大批改动日） |
| 10-03 | 892 | 50 | 17.8 | 11.469 | 0.229 | 20.8% | 25.6% | 53.6% | 68.3% | 余额对账最准（+0.3%） |
| 10-04 | 1,363 | 101 | 13.5 | 16.719 | 0.166 | 20.2% | 25.8% | 54.0% | 71.0% | 当日有充值，余额不可对账 |
| 10-05 | 683 | 50 | 13.7 | 11.654 | 0.233 | 25.1% | 24.0% | 50.8% | 68.1% | 自算比实扣高 37.3% |
| 10-06 | 245 | 23 | 10.7 | 5.376 | 0.234 | 20.5% | 30.0% | 49.5% | 70.2% | 半日未完结 |
方向性：步/轮 23.4 → 10.7（-54%）、元/轮 0.371 → 0.234（-37%），效率指标在改善； 但输出占比 49.5%→54.0%、思考占输出 62%→71% 在走高——成本结构从"步数重放"转向"思考体量"。
余额对账（实扣 vs 自算）：
- 10-01 19.830 vs 24.469（+23.4%）；10-02 21.610 vs 25.635（+18.6%）；10-03 11.430 vs 11.469（+0.3%）；
10-05 8.490 vs 11.654（+37.3%）；10-04 充值不可对账；10-06 待明日。
- 已知 4 天合计：实扣 61.36 元 vs 自算 73.23 元 → 自算系统性高估约 +19%，且各日偏差不一致（0.3%~37.3%）。
与 daily_review 自身提示一致：价目表 / 峰谷 / 多路由加权口径需核对（此段不作结论）。
③ 异常判定¶
| 项 | 判定 | 依据 |
|---|---|---|
| 10-02 成本 25.635 元（基线 +152%） | 需关注 | 请求 1,732（+103%）、未命中 token +251%；当日为规则/交接文档大批改动日，轮首重建叠加 |
| 10-01 步/轮 23.4（基线 +32%） | 需关注 | 单轮步进 top：76 步/轮、61 步/轮、53.5 步/轮；但 status 全 200、零输出步 0、无重复提问 → 任务驱动的长执行，非失控 |
| 会话中段整段失效（miss>10k，宽口径） | 需关注（客户端主导，非上游） | 336 条该类请求未命中 token 合计 10.96 元（占区间 11.5%）；其中真失效仅 17 条（3.6 元），逐条归因：15 条＝客户端工具集变化（同会话内 tools 27↔26 或 tools_hash 变，system 段同步 ±336 字符）、1 条＝代理 prompt_hint 首次生效（10-02 19:08:54，miss=235,072）、1 条＝代理 reasoning_effort 变档；全部一次性重建。⚠ 本节原结论「10 步＝改规则复用旧会话、7 步＝上游缓存侧」已作废，见 ⑥ 6.2 |
| 会话首条未命中 | 正常（结构必然） | 每会话第 1 条请求未命中偏高（system+规则+HANDOFF 重建），不判异常 |
| 单会话步/轮 > 2× 当日中位 | 需关注 | 6 天均出现（如 10-01 9e97ba273376 61.0、10-02 1fc1afc5c55e 83.0、10-04 e19010792020 67.0）——同属"任务长链"，无一例伴重试/空转 |
| 长会话（轮≥40 或请求≥100） | 需关注 | 10-01 7 个、10-02 3 个、10-04 3 个、10-05 1 个；最大 24 轮 / 198 请求（10-02 50eeaae9e92f） |
| 输出截断嫌疑 | 正常 | 6 天均报"无" |
④ 评估¶
- 整体：6 天属"高投入、可解释"。成本集中在"多步任务 + 超大上下文（十几万到 52 万 prompt token）× 步数"， 叠加"输出里 66% 是思考"。不是配置失控（失败/空转/重复提问三项基本干净），而是任务体量与工作方式决定的。
- 不合理之处指名：
- 思考占输出的 62%~71% 是最大单项（区间 31.79 元 = 33.3% 总成本）。10-01~10-06 逐日升高， 与"每步重放 + 长链推理"直接相关——压步数 = 直接压思考体量。
- 重复问同一句：10-01 b379f7430bea「好的，执行吧」3 轮、10-04 983c7b952434 4 轮、10-02/10-05 各 2 轮—— "确认后继续"类口令重复出现在同一会话多轮，每轮都触发整段前缀重放。
- 单轮 60~83 步（10-01 abf64ca6cb3b 76、10-02 1fc1afc5c55e 83、10-04 e19010792020 67、10-05 54a9b6732f34 60）： 一条"列计划→逐步执行"的链在单轮内跑完，prompt 从 3 万涨到 36 万，命中重放随步数线性涨。
- 上传件触发的会话中段重建：多日 top miss 的提问串都以
<user_uploaded_files>开头 （10-01/10-03/10-04/10-05/10-06 皆然），miss 100k~365k；指纹判定一半是 system 段变化（注入侧，如规则/系统提示改写）、 一半是上游未命中。
⑤ 会话归因（全量，按台账成本降序取前 12；完整逐日表见各日 daily_review 输出）¶
| conv | 日 | 开场 | 结束 | 请求 | 轮 | 步/轮 | 成本¥ | 触发 | 开场提问 |
|---|---|---|---|---|---|---|---|---|---|
| 56c7cce23d0f | 10-01 | 15:50 | 17:06 | 164 | 7 | 23.4 | 3.617 | 成本+中段失效 | 关于监控蓝图还有哪些未做完的 |
| 413dcb4ed35d | 10-02 | 14:10 | 15:08 | 98 | 10 | 9.8 | 2.904 | 成本+中段失效 | 是否单独立项执行下，然后就是读取 daily-review-20261001 |
| b906d61b4384 | 10-01 | 14:39 | 15:49 | 97 | 4 | 24.2 | 2.827 | 成本+中段失效 | harbor 已就位 |
| 9e97ba273376 | 10-01 | 03:10 | 12:38 | 183 | 3 | 61.0 | 2.798 | 成本+步/轮 | 你好，现在专门建了一台 harbor 的节点，可以直接 ssh root 192.168.31.31 登陆 |
| 50eeaae9e92f | 10-02 | 00:18 | 01:53 | 198 | 10 | 19.8 | 2.605 | 成本+中段失效 | 按服务级别你做成什么效果了，我在界面怎么没有感受 |
| 329217fa401d | 10-01 | 17:08 | 21:56 | 177 | 8 | 22.1 | 2.406 | 成本+中段失效 | 帮我看下 efk 当前吃掉的系统资源 |
| 56dd5f610063 | 10-05 | 14:27 | 15:20 | 80 | 3 | 26.7 | 2.139 | 成本+步/轮 | 针对 lmod 我有 4 个问题 |
| 983c7b952434 | 10-04 | 02:46 | 04:21 | 116 | 24 | 4.8 | 2.027 | 成本+中段失效 | 这一步卡住了，怎么做？<user_uploaded_files> |
| 00fcb071175a | 10-01 | 00:33 | 01:11 | 101 | 3 | 33.7 | 1.924 | 步/轮+中段失效 | lustre 的监控大盘同样也太单调了些 |
| 949d98e91b75 | 10-05 | 15:24 | 15:44 | 91 | 3 | 30.3 | 1.811 | 成本+步/轮 | 请读取 /home/rain/Documents/eda_tools_ins/docs/LMOD-CROSS-PROJECT |
| 2d70881bdd73 | 10-02 | 16:25 | 19:10 | 92 | 7 | 13.1 | 1.786 | 中段失效 | 根因是 req_shape.jsonl 不含工具名 |
| dad79f16e831 | 10-06 | 15:25 | 16:05 | 68 | 4 | 17.0 | 1.645 | 成本+步/轮 | 我当前的 lsf master 节点是参考计算的吗？这符合 EDA 的行业规范吗？ |
⑥ 深挖取证¶
6.1 区间最贵会话 56c7cce23d0f（10-01，3.617 元，164 请求 / 7 轮，model=deepseek-flash）¶
- 各轮起始：轮1 15:50:19｜轮2 15:53:20｜轮3 15:56:04｜轮4 15:57:26｜轮5 15:58:21｜轮6 16:07:18｜轮7 16:47:48； 会话结束 17:06:20。单轮最多步 = 轮 6 的 100 步（16:07→16:44，prompt_p50 22.3 万），轮 7 37 步（prompt_p50 36.7 万）。
- 成本构成（统一价折算，仅同会话内可比）：轮6 0.995 元 = 命中 0.439 + 未命中 0.089 + 输出 0.467；轮7 0.500 元 = 命中 0.269 + 输出 0.195。 → 命中重放 + 输出（含思考）各占约一半，与区间总体结构一致。
- 关键证据：轮 2 两次中段失效（15:53:27 miss=17,894、15:54:35 miss=42,806），均下一条 hit 回升（一次性重建）； 全程 status 200、零输出步 0。
6.2 会话中段失效的责任方判定（区间 17 步 miss>100k 全查）——首版结论已作废，此处为重做¶
为什么重做：首版用 req_shape 的 head[0] 判「客户端改了 system」，并据此断言"用户改规则后复用旧会话"。
两条都不成立：① 该指纹在代理注入 prompt_hint 之前采集（proxy.py L819 vs L843），只能算客户端原文；
② 逐条复核发现 head[0] 变化与 tools 数量/hash 变化严格同现——是客户端工具集在换，不是规则。
| 归因 | 步数 | 代表（时间 / miss） | 判据 |
|---|---|---|---|
| 客户端：同一会话内工具集变化 | 15 | 10-01 01:09:18 / 364,998；10-02 15:03:40 / 268,573；10-04 15:47:44 / 217,501 | tools 27↔26 或 tools_hash 变（≠ 时 head0 同步 ±336 字符）；全部下一条 hit 回升 |
代理：prompt_hint 首次生效 |
1 | 10-02 19:08:54 / 235,072（hit 4,224→237,440） | 代理 19:08:41 重启后第一条请求；该步 head0/tools_hash 与前后完全一致，miss 只能来自代理给 system 追加的 227 字符；SOP §4 称"文本固定故不破坏前缀缓存"不成立（固定只在"一直开着"时无害，开关状态变化即全量重建） |
代理：reasoning_effort 变档 |
1 | 10-04 03:38:38 / 156,303 | effort low→high（stage collecting→coding），head/tools 均未变；样本仅 1 例，待定（另有 184 次变档未造成 >100k，故非普遍原因） |
| 上游缓存侧 | 0 | — | 首版归到这里的 7 步，复核后 6 步伴随 tools_hash 变化、1 步即上表 prompt_hint 首启 |
统计口径（全量相邻步对 6,575）：tools_hash 变化 48 次，其中 15 次造成 miss>100k；
thinking_effort 变化 184 次，其中 1 次造成 miss>100k。→ "整段失效"的头号驱动是客户端换工具集，代理只贡献 2 例。
口径澄清（重要）：daily_review 的「整段失效 miss>10,000」是宽口径——区间 336 条该类请求（miss 合计 10.96 元）里，
只有 17 条是"前缀真失效"（miss≈全量前缀、hit 骤降后回升，合计 3.6 元）；其余 254 条（5.96 元）是同前缀下的增量新内容
（大工具结果 / 新轮用户内容），不应计入浪费。该标签口径偏宽，建议挂账修正。
6.4 prompt_hint 降思考效果：没有可测收益¶
- 代理确实注入了：本会话 system 开头即为该段原文，且
~/.trae-cn全域 grep 无此文本 → 排除"未生效"。 - ds 路由、按 prompt 规模分桶、比
reasoning_tokens中位（应用前 = 10-02 19:08 前，应用后 = 之后）：
| prompt 桶 | 应用前（步数 / 思考 tok 中位 / 思考占输出） | 应用后 |
|---|---|---|
| <60k | 217 / 472 / 72.5% | 527 / 501 / 68.8% |
| 60–150k | 677 / 858 / 69.6% | 1638 / 724 / 66.0% |
| 150–300k | 1106 / 542 / 57.3% | 1423 / 722 / 59.8% |
| >300k | 530 / 622 / 55.4% | 112 / 920 / 64.7% |
- 结论：小上下文桶思考略降 / 占比略降，大上下文桶反升；逐日"思考占输出" 62.1%→63.7%→68.3%→71.0%→68.1%→70.2% 整体走高。 即：不能证明有效，观测上更接近"无效/负向"；且它已知会带来一次性全量重建（上表 1 例 = 0.235 元）。
- 口径修正：初稿写"10-02 19:08 同时开启了
thinking注入"——错。逐日核usage.jsonl的thinking_applied： 9-20~9-30 0%、10-01 起 100%（reasoning_effort=high）。即思考注入从 10-01 就已全量应用，10-02 19:08 那次只加了prompt_hint。 因此上表 10-02 19:08 的分界对prompt_hint而言是单变量的 → "未见效果"的结论比初稿更硬。 - 附带发现（更可疑的成本开关）：
thinking注入才是 10 月才有的代理侧改动。逐日 思考/请求： 9 月（无注入）841 / 均值 ≈843；10-01~10-02（仅 thinking）994 / 936；10-03~10-06（thinking + hint）1102 / 1241 / 1084 / 1251。 思考占输出 9 月 ≈57% → 10 月 ≈68%。这是"单位成本上升"的第一嫌疑，须 A/B 分离（把reasoning_effort降档或改为不注入，跑 1~2 天比思考/请求）。
6.3 收益修正（按技能红线：只对命中重放段折算）¶
- 若把"单轮 60~83 步"压到 ≤30 步（少跑一半步），命中重放约省 5~6 元/区间 + 部分输出（思考体量同步下降）； 不可把输出按步线性折算。区间口径的日均约 18 元，此项预计可省 0.8~1.2 元/日。
- 会话中段失效 15.15 元/区间中，约半数（~7.5 元）可由"改规则后开新会话"规避（另一半属上游，不可控）。
⑦ 改进建议（最多 3 条，只提不改）¶
- 定位「客户端在同一会话内换工具集」——针对 6.2 的 15 步真失效（miss 合计 ≈3.2 元/区间，与
tools27↔26 同现）； 建议查 Trae 侧是哪种能力在会话中途挂载/卸载（Skill / MCP / Subagent 动态加载最可疑），若属实可改为"会话开始一次性挂载"。 属客户端行为，代理侧无解；但先定位到具体是哪一类切换，才知道能不能绕。 - 对
prompt_hint做单变量 A/B 定论——针对 6.4：现有观测不支持"降思考有效"（大上下文桶反升）， 且已见其带来一次性全量重建（0.235 元/次）。做法：thinking.prompt_hint置空 + 重启，跑 1~2 天，比 ds 路由reasoning_tokens中位； 若无差异则永久置空（保留代码，一键可回）。属改配置，需确认后执行。 - 单轮长链拆成"分轮确认"——针对 76 / 83 / 67 步三例；截断 prompt 线性膨胀，按命中重放折算约省 0.8~1.2 元/日。 同时把「确认后继续」类口令去重（10-01 同一句 3 轮、10-04 4 轮）。
（原「改规则后开新会话」一条已删除——6.2 复核证明该归因不成立。）
来源：
/home/rain/Documents/services/token_proxy/reports/daily-review-20261001-20261006.md｜ 最后更新：2026-10-06 16:23（由build/sync.py同步，请勿在站点侧修改）