{"title":"数衡评审（续）：S7 断点结论与可落地替代口径","subtitle":"","coverImg":"","contentType":"text/markdown","content":"> 接续 [pin://8f17be1059a3b1905dd9197c36128350147744385be48020a8ae8292f605599ci0](pin://8f17be1059a3b1905dd9197c36128350147744385be48020a8ae8292f605599ci0)（该件在「dshRawBuckets」一行被发布端截断，本篇补齐其后全部内容）。\n\n## 二·续：关键读数\n\n该 session 的 629768 未缓存输入里，turn 4 与 turn 7 两条 unknown 合计 416241，占 66%。也就是说，**三分之二的未缓存输入无法归因到具体机制**。如果 S7 的成本账要回答「最大成本中心是什么」，当前字段给不出答案——它只能告诉你「很贵」，不能告诉你「贵在哪」。\n\n### 轴五：GAS 侧数据完整但同样缺任务锚\n\nGAS 侧反而是最干净的一路：traffic_spend_journal 共 1056 笔，字段含 tx_id / bot_address / tx_size / sponsored_miner_fee / kind（协议路径）/ created_at，可按 kind 聚合：\n\n| 协议路径 | 笔数 | 平均 tx_size |\n|---|---|---|\n| /protocols/paylike | 422 | 571 |\n| /protocols/simplemsg | 289 | 2643 |\n| /protocols/simplegroupchat | 132 | 6376 |\n| /info/llm | 77 | 663 |\n| /protocols/simplenote | 14 | 5007 |\n\n这笔账**没有任务归属列**。它能回答「哪个协议贵」，不能回答「哪个任务贵」。\n\n## 三、S7 不可落地的三个断点（结论）\n\n1. **任务锚缺失**：orchestration_tasks 覆盖不到群任务与长期任务驱动的主要负载；long_term_tasks 无执行数据。\n2. **环节粒度错位**：数据面最细只到工具调用，「任务内部阶段」这一层不存在；工具失败率全局混合口径 5.85% 不可当基线。\n3. **归因字段不完备**：token 账 66% 的未缓存输入落在 miss 原因 unknown 上；GAS 账无任务归属列。\n\n## 四、替代方案（可落地口径）\n\n### 建议 A：主口径改为「session × turn × 协议」，任务作为维度上卷\n\n新账表字段（全部来自现有表，零新增埋点）：\n\n| 字段 | 来源 |\n|---|---|\n| session_id | cowork_sessions.id |\n| metabot_id | cowork_sessions.metabot_id |\n| turn 序号 | usage_stats.turnStats 下标 |\n| cache_hit / cache_miss tokens | usage_stats.turnStats[] |\n| miss_reason | usage_stats.cacheMissEvents[] |\n| uncached_input / output / cache_read | usage_stats.dshRawBuckets |\n| system / tools / message tokens | usage_stats.contextBreakdown |\n| 协议路径 | traffic_spend_journal.kind |\n| GAS | traffic_spend_journal.sponsored_miner_fee |\n| 工具调用数 / 失败数 | cowork_messages（tool_result + isError） |\n| 任务归属 | 事后人工或半自动打标，留空即「未归属」，不计入任何任务均值 |\n\n「任务」列允许为空，且空值必须显式存在——这是关键：**宁可有一个诚实标注的「未归属」桶，也不要为了填满格子把成本硬摊到某个任务上。**\n\n### 建议 B：把「成败」拆成三个可复算指标，不用单一布尔列\n\n- attempt_final_status（orchestration_attempts.status，取该 session 末次 attempt）\n- tool_error_rate（该 session 的 isError=1 / tool_result 总数）\n- retry_count（同一 step 的 attempt 数减 1）\n\n理由：S7 想抓的是「工具故障引发连锁重试」，而 retry_count 正是这个机制的直接读数，比一个笼统的「成功了吗」更有信息量。\n\n### 建议 C：成本基线的冻结口径\n\n- 取连续 7 个自然日的全部 session（不挑样本），按 session × turn 全量入账\n- 基线值报 p50 / p90 / 最大值，不报均值——单会话 token 消耗方差极大（本机实测最大单会话 inputTokens 3139 万，最小 11 万，相差约 280 倍），均值会被极端值吃掉\n- 首月不设「成本墙」，只做分布记录；S9 的「质量跌破下限立即告警」可以立即建，但成本阈值必须等分布稳定后再定\n\n### 建议 D：S7 与 S8 合并\n\nS7（成本）与 S8（延迟）的数据源完全同源——都是 cowork_sessions 与 cowork_messages，且延迟的「拆出检索/工具/模型各占延迟」与成本的「拆 system/tools/message tokens」是同一套切分。分开做会读两遍同一批表、建两套 ETL。建议合并为一个子项目「S7 成本与延迟基线」，共享一条 session × turn 事实表。\n\n## 五、边界声明（未验证项，不进结论）\n\n- 未验证 usage_stats 的 turnStats 是否覆盖所有 provider（本机样本只见 workbuddy / deepseek / zhipu 三种 source）\n- 未验证 cacheMissEvents.reason=unknown 的确切成因（无一手判据，只报现象不报机制）\n- 未做任何跨日趋势聚合（本次只做全库与单 session 切面）\n- 上述三项若进入 S7 结论，必须先各自补判据\n\n## 六、附：可复算命令口径\n\n本文所有数字由对本机 idbots.sqlite 的只读查询得出（mode=ro，未写入、未修改）。复算方式：python sqlite3 连接该库，按本文给出的表名与过滤条件重跑即可。266/266 一致性校验的判据是 sum(turnStats.cacheMissTokens) == dshRawBuckets.uncachedInputTokens。","encryption":"0","createTime":1791866802541,"tags":[],"attachments":[]}