效率体系：系统侧 vs agent 侧（专项待处理）¶
2026-10-07 立档。用途：把「效率与成本措施目前只覆盖 agent 侧、被测系统侧完全空白」讲清楚， 并把本次已落地的措施、工具与遗留项一次交清，供单独会话专项处理。 关联：全局规则
rule-agent-efficiency.md（收尾自查）｜skillops-execution-efficiency（含 MB）｜skilldeployment-tool-engineering（源头）。
一、结论¶
当前「效率与成本措施」= 只度量 agent 侧（我的步数、token、工具调用、子智能体）。 被测系统自身的执行效率（远端命令数、重复探测、建连数、任务墙钟）既无度量口径、也无验收方。
后果（2026-10-07 实测）：两类问题在旧口径下完全不可见 ——
① slurm_ins 单次 --dry-run 下发 864 条远端命令，其中 483 条（56%）为同一主机的重复探测；
② 2026-09-30 的连接复用改造因工程内同名副本遮蔽共享库，在该工程失效约 3 个月。
二、两侧对照¶
| 维度 | agent 侧（已有） | 系统侧（本次新增） |
|---|---|---|
| 度量对象 | 我的行为：步数 / 轮次 / 工具调用合并 / 上下文前缀 / 子智能体 | 被测系统：远端命令数 / 重复探测数 / 建连数 / 任务墙钟 |
| 计量单位 | token（命中 / 未命中 / 输出） | 秒 + 条 + 次 |
| 现有机制 | 收尾自查五组（A–E）+ selfcheck.py / wrapup.py / step_profile.py + MB §二十六/§二十七/§二十九 样本 |
此前为零；本次新增「条件触发行」+ remote_cmd_profile.py + MB §三十 |
| 与 token 成本的关系 | 直接 | 不直接 —— 省的是墙钟与目标端资源（故只进效率、不进成本） |
| 优化手段 | 合并工具调用、减少轮次、缓存前缀、子智能体隔离 | 连接复用、命令合并、探测去重、并发模型 |
| 载体 | 全局规则 + token_proxy/cost_audit/ |
skill deployment-tool-engineering + references/scripts/ |
注意口径：规则里此前出现的「墙钟」全部指轮次墙钟（轮内首步→末步，即我的耗时）， 不是任务执行时长 —— 这两者同名不同义，是这次混淆的根源之一。
三、本次已落地（四处）¶
- 全局规则
~/.trae-cn/user_rules/rule-agent-efficiency.md：收尾自查新增「任务侧效率（条件触发：仅本轮执行过部署器 / 巡检 / 远程批量操作时输出）」—— 墙钟 / 远端命令 / 可省重复 / 建连；并明写「只进效率、不进成本」。附「十一修」修订注释。 - skill
ops-execution-efficiency：收尾自查清单补该口径说明，指明前文 §1–§5 的系统侧原则此前无度量、无验收。 - MB
measured-baselines.md：新增 §三十「任务侧效率样本」（与 agent 侧 §二十七 并列），已填本次基线。 - 源头 skill
deployment-tool-engineering：新增「探测效率与可观测」节（SKILL 里此前一条都没有）； 遮蔽检测进交付前自检·阻断项、探测效率进建议项；常见反例加两行；shared-lib-contract.md补「本地副本遮蔽检测」节。
四、工具（本次产出，可直接跑）¶
| 脚本 | 用途 | 退出码 |
|---|---|---|
~/.trae-cn/skills/deployment-tool-engineering/references/scripts/remote_cmd_profile.py |
部署器效率画像：重复探测表 / 命令数 / 阶段与主机分布 / 最慢 TOP | 0（纯度量） |
~/.trae-cn/skills/deployment-tool-engineering/references/scripts/shared_lib_divergence_check.py |
共享库分叉与遮蔽巡检（六档判定） | 非 0 = 有「版本落后」 |
五、遗留（本专项待处理）¶
| # | 事项 | 现状与方案 |
|---|---|---|
| 1 | 部署器层重复探测消除 | ✅ 已做（2026-10-07）：基类加「进程内 host+cmd 只读探测缓存」，重复 49 → 0、命令 433→384 次、墙钟 134.6→116.1 s；档案 slurm_ins/dedupe_probe_20261007/README.md |
| 2 | 系统侧效率是否需要独立门禁（而非条件触发的一行） | 待定。当前刻意做成条件触发，避免重蹈「每轮逐项自评 → 被成本反噬」的覆辙 |
| 3 | remote_cmd_profile.py 是否纳入常态化巡检 |
待定 |
| 4 | MB §三十 任务侧样本目前只有 1 次运行，跨轮可比性不足 | 待累积 |
| 5 | 其它工程是否也有同类重复探测 | 未查（本次只画像了 slurm_ins） |
六、基线数字（供后续对比）¶
| 项 | 值 |
|---|---|
slurm_ins 主部署器单次 --dry-run（6 台） |
命令 433 次 / 可省重复 49 次 / 建连 6 次 / 墙钟 134.6 s（改造前 247.7 s）；加基类探测缓存后 384 次 / 重复 0 / 116.1 s |
| 阶段分布 | sync_status 131.4 s · deploy 115.2 s · pre_check 49.3 s |
| 重复探测 TOP | systemctl is-active slurmctld ×6/台 · ldd ×5/台 · findmnt … /mnt/slurm-shared ×5/台 · command -v dnf ×4/台 |
| 判据（已写进规则） | 可省重复应为 0；6 台主机的配置类工程命令量应在百条以内 |
七、为什么这次"发现的层级"值得单列¶
此前所有效率优化都在agent 侧（我少走一步、少读一次、少重放一遍上下文）， 度量也全在 token 上。而任务本身的执行效率（发多少命令、建多少连接、重复探测多少） 是另一整套东西：它不省 token，但它决定任务要跑多久，也决定"同样的任务要占用多少目标端资源"。
两者唯一的耦合是「等待」：任务越久，我空转越久。但这条链路的强度未经证实， 本档案不把它当作论据（MB §三十一 已补边界声明：该节为单次实测，不构成因果规律）。
来源：
/home/rain/Documents/services/token_proxy/task-side-efficiency-20261007/README.md｜ 最后更新：2026-10-07 07:00（由build/sync.py同步，请勿在站点侧修改）