跳转至

agent-efficiency-backfill-20261001 — 效率回填机制收口

  • 主题：让「效率分析与回填」不再漏（方案 A+B）；并压降大输出（方案 2，方案 1 列为待办 12）
  • 产生时间：2026-10-01
  • 触发：用户指出「好几次会话都没有效率分析/规划，怎么确保这步不漏」

1. 根因

与 2026-10-01 立「收尾自查硬门禁」时同一个根因：要求只写在按需加载的 skill 正文里， 没有触发点、也没有验收方。收尾清单当年靠「结论必须出现在最终答复里」治好； 而「效率数据回填到 references/measured-baselines.md」这条没被纳入，于是反复漏。

附带发现的第二类问题：只量成本、不量时间，导致「时间花在哪一阶段」只能凭印象—— 本次就因此把一节变更的文档阶段估成 60% 墙钟（实测为 16%，见第 5 节）。

2. 改了什么

文件 改动
~/Documents/services/token_proxy/cost_audit/selfcheck.py 输出新增墙钟 / 平均步间隔 / 最大步间隔 TOP3 / 输出 TOP3（数据由命令给出，不靠回忆）
~/.trae-cn/user_rules/rule-agent-efficiency.md 「收尾自查（硬门禁）」表新增一行：效率回填，验收物 =最终答复出现「效率回填：measured-baselines.md §N（日期）」；无新增节须写明理由
~/.trae-cn/skills/ops-execution-efficiency/SKILL.md §6.2 新增两条实测纪律（大文件扩展走增量编辑；同一文件多段读取用一次宽窗口）+ selfcheck 新口径说明
~/.trae-cn/skills/ops-execution-efficiency/references/measured-baselines.md 新增第十一节（时间分布口径）；并纠正初版错误结论（留痕）
docs/HANDOFF.md（根级） 待办 2 措辞收紧；新增待办 12（大盘 YAML 模板化）

3. 备份台账

备份文件 原路径 产生时间 因何产生 回滚什么 何时可删
backup/cost_audit/selfcheck.py.bak.20261001-014005 ~/Documents/services/token_proxy/cost_audit/selfcheck.py 2026-10-01 01:40 输出新增时间分布三项 覆盖回滚即恢复只输出成本的旧版 确认新输出稳定使用后
backup/user_rules/rule-agent-efficiency.md.bak.20261001-014005 ~/.trae-cn/user_rules/rule-agent-efficiency.md 2026-10-01 01:40 收尾自查表新增「效率回填」行 覆盖回滚即删除该行（回滚后需再开新会话） 确认该门禁连续 3 天生效后
backup/skills/ops-execution-efficiency/SKILL.md.bak.20261001-014005 ~/.trae-cn/skills/ops-execution-efficiency/SKILL.md 2026-10-01 01:40 §6.2 新增两条纪律 覆盖回滚即删除这两条 同上

user_rules 的备份已设 600（含全局规则正文，无凭据）。

4. 实测验证

  1. selfcheck 新输出生效：--last 2 实测输出含 墙钟 2.6 分钟 ｜ 平均步间隔 15.8s、最大步间隔：01:40:05 处 39s …、输出 TOP3：01:38:38 4429 tok …。
  2. 缓存结论（关键）：在不切窗口的连续对话中，上一轮改完 SKILL.md 正文 + references/ 之后，下一轮第 1 步 cache_miss_tokens = 345； 对照 SKILL.md §8 记载的「改 description 后下一轮第 1 步 ≈364,998」—— 相差约 1000 倍，证实「改正文与 references 不进每轮前缀、不需开新会话」。
  3. 效果待观察：本次是机制上线轮，真正判据是下一轮起「效率回填」行是否每轮都出现。

5. 本轮附带纠正的错误结论（重要）

上一轮我写进 measured-baselines.md 第十一节的「文档与交接占 ~60% 墙钟」是错的—— 那是凭时间印象填的。用 usage.jsonl 逐条时间戳实测（53 条请求，01:14:33 → 01:28:12，墙钟 13.7 分钟）：

阶段 墙钟 占比
勘察 3.6 min 26%
实现（写采集器 + 大盘） 5.4 min 39%
部署与验证 2.0 min 15%
文档与交接 2.2 min 16%

真实杠杆是三处大 Write（采集器 14,283 / 大盘 12,763 / SOP G.8 6,103 token，合计 33K ≈ 0.13 元， 占该轮输出成本一半以上）。已在第十一节留痕，教训：时间类结论必须由时间戳算出，不得凭印象。

6. 待办 12：大盘 YAML 模板化（下一步，新会话执行）

  • 目标：把面板样板抽成「数据 + 生成器」，扩展大盘时只写差异行 → 单步输出 12.8K → ~2K
  • 思路：
  • dashboards/<name>.panels.yaml：只写分组、面板类型、标题、expr、legend、gridPos（精简格式）
  • utils/dashboard_builder.py：渲染成现有 manifests/NN-env-<name>-dashboard.yaml（ConfigMap + JSON）
  • 纳入 main.py 的渲染流程或作为独立预处理步骤
  • 验收判据：用现网某个大盘反向生成，生成结果与现网内容语义等价 （JSON 解析后逐键比对，允许键序差异），否则不上线
  • 风险：生成器与手写 YAML 双轨漂移 —— 需在 SOP 中写明「大盘一律由生成器产出，不再手改 YAML」

来源：/home/rain/Documents/k8s_ins/agent-efficiency-backfill-20261001/README.md ｜ 最后更新：2026-10-01 01:41（由 build/sync.py 同步，请勿在站点侧修改）