> 注：本报告为本机（Windows）实测记录，文中路径均为本机路径；实验设计与原始数据见报告正文。

---

# 成本守卫（dsh-cost-guard）对比测试 · 两轮整合报告

- 日期：2026-08-18；模型全部 **deepseek-v4-flash**（两轮一致）
- 计价口径：dsh-cost-guard core.js 官方费率（空闲档 ¥/M：缓存命中 0.05 / 未命中 1.5 / 输出+推理 4.5；高峰 ×2）
- 运行方式：全部为隔离的 dsh headless 进程 + 独立工作目录，代理间互不可见、不引用已测文件
- 组别条件（两轮一致）：
  - **CG 组** = `router-flash-cg` 预设（成本守卫从首轮启用）+ 任务末尾追加收敛后缀（首轮即收敛）
  - **spec 组** = `router-spec` 预设 + 纯任务文本（全程不收敛），且不装配成本守卫插件
- 预算：每轮独立 4 元上限；首轮实际 ¥3.45，二测实际 ¥3.82

> ⚠️ 说明：两轮实验设计不同（首轮=同类型不同题，二测=同提示词多轮），**数据分开展示、不做合并平均**。合并会混淆「任务难度差异」与「组别差异」，误差不可控（详见文末「两轮对比与合并误差」一节）。

---

## 一、首轮数据：同类型不同题（4 个子代理）

4 个项目，规模相当但内容不同（2 个 CLI 工具型 + 2 个前端应用型），每轮只跑 1 次，无重复。

| 子代理 | 组别 | 项目 | 花费 ¥ | 输出/推理 token | 命中率 | 结果（本地复验） |
|---|---|---|---|---|---|---|
| r1-cg-kb | CG | 知识库管理 CLI（10 命令） | **0.5025** | 58.0K / 36.8K | 98.3% | 完成，14/14 测试 ✓ |
| r2-cg-dash | CG | 数据可视化仪表盘（7 需求） | **0.8613** | 88.3K / 66.4K | 88.7% | 完成，node --check 4/4 ✓ |
| r3-spec-ledger | 无守卫 | 财务记账 CLI（8 命令） | **1.2394（被截停）** | 120.5K / 93.2K | 97.7% | 代码完成 15/15 ✓，收尾前被预算截停 |
| r4-spec-typing | 无守卫 | 打字练习 Web 应用（7 需求） | **0.8470** | 88.6K / 64.3K | 93.3% | 完成，26/26 测试 ✓ |

**首轮统计（n=2/组）**

| 指标 | CG 组 | spec 组 |
|---|---|---|
| 平均花费 ¥/次 | 0.682 | 1.043 |
| 总花费 ¥ | 1.364 | 2.086 |

**首轮同型配对**：CLI 任务 CG 0.50 vs spec 1.24（CG 省 59%，且先交付）；前端任务 0.86 vs 0.85（持平）。
**首轮结论**：方向性上 CG 更省，但每个代理任务不同，配对不严格——r3 任务偏大、被截停等因素混入，**幅度不可直接归因于成本守卫**，仅作方向参考。

## 二、二测数据：相同提示词 × 3 轮（6 个子代理）

同一任务文本（待办事项 CLI，10 命令 + ≥10 测试），3 轮重复，每轮 CG vs spec 各 1 个独立代理——**严格对照**，唯一差异 = 组别条件。

| 轮次 | 子代理 | 组别 | 花费 ¥ | 输出/推理 token | 命中率 | 结果（本地复验） |
|---|---|---|---|---|---|---|
| 1 | r1-cg-a | CG | **0.7210** ¹ | 73.3K / 53.1K | — | 交付完整 19/19 ✓（收尾时进程被会话中断） |
| 1 | r2-spec-a | 无守卫 | **0.7115** | 51.8K / 36.7K | 93.9% | 完成，17/17 ✓ |
| 2 | r3-cg-b | CG | **0.5261** | 54.9K / 39.3K | 94.4% | 完成，19/19 ✓ |
| 2 | r4-spec-b | 无守卫 | **0.6029** | 50.9K / 38.2K | 96.3% | 完成，17/17 ✓ |
| 3 | r5-cg-c | CG | **0.3877** | 40.0K / 27.5K | 97.5% | 完成，15/15 ✓ |
| 3 | r6-spec-c | 无守卫 | **0.8668** | 91.2K / 58.9K | 98.4% | 完成，17/17 ✓ |

¹ r1-cg-a 在交付完成（DELIVERY.md 已写入、测试全绿）后、最终核算前被会话中断，花费取最后实时读数（略低估）。

**二测统计（n=3/组）**

| 指标 | CG 组 | spec 组 | 差异 |
|---|---|---|---|
| 平均花费 ¥/次 | **0.545** | **0.727** | **省 25.0%** |
| 中位数 ¥ | 0.526 | 0.712 | 省 26.1% |
| 总花费 ¥ | 1.635 | 2.181 | 省 ¥0.55 |
| 平均输出+推理 token/次 | 86.1K | 101.3K | 少 15.0% |
| 缓存命中率 | 94–98% | 94–98% | 无差 |

**逐轮配对**：R1 持平（0.72 vs 0.71）、R2 CG 小胜（0.53 vs 0.60，-13%）、R3 CG 大胜（0.39 vs 0.87，-55%）。
**二测结论**：相同提示词、3 轮重复下，CG 组平均省 25%（中位数口径 26%），是可归因于组别条件的稳定估计；同时可见**个体方差很大**（CG 组内 0.39–0.72、spec 组内 0.60–0.87），单轮对比噪声不可靠。

## 三、两轮对比与合并误差说明

| 维度 | 首轮 | 二测 |
|---|---|---|
| 任务设计 | 同类型不同题（2 CLI + 2 前端） | 完全相同提示词 × 3 轮 |
| 对照严格度 | 不严格（任务差异混入） | 严格（唯一变量 = 组别） |
| 样本 | n=2/组 | n=3/组 |
| 结果 | CG 平均 0.68 vs spec 1.04 | CG 平均 0.55 vs spec 0.73 |

- **为什么不能合并平均**：首轮各组任务不同，任务本身规模/难度会系统性影响花费（例如 r3 的记账 CLI 命令更多、还要求 10+ 测试与 ANSI 输出），这些差异与组别效应纠缠，把两轮数据混在一起取平均，得到的"省 29.7%"没有干净的因果解释，且会掩盖首轮配对不严格、二测更可信的事实。
- **两轮的一致方向（定性结论）**：两轮中 CG 组都更省（首轮方向性、二测统计性），且无守卫组都出现了"停不下来"的迹象（首轮 r3 被截停、二测 R3 spec 输出最多）。方向一致、幅度以二测为准。

---

## 四、成本守卫「收敛省钱」的原理

### 4.1 定价模型：钱花在哪

按 DeepSeek 官方峰谷分级（¥/百万 token，空闲档）：

| 计费项 | 单价 ¥/M | 相对倍率 |
|---|---|---|
| 缓存命中输入（cacheRead） | 0.05 | 1×（最便宜） |
| 未命中输入 + 缓存写 | 1.5 | 30× |
| 输出 + 推理 token | 4.5 | **90×** |

单次请求成本 ≈ `命中×0.05 + 未命中输入×1.5 + (输出+推理)×4.5`（每百万）。高峰时段（每日 09:00/14:00 两个整点档）全部 ×2。

**结论先行**：输出/推理 token 是最贵的一项（是命中输入的 90 倍、未命中输入的 3 倍）。一次 LLM 调用的输入里，前缀命中率往往高达 90%+（实测两组 89–98%），真正花钱的大头是「模型写了多少字、想了多少步」——这正是收敛机制的主攻方向。

### 4.2 收敛省钱的四条路径（按实测贡献排序）

1. **少输出、少推理（贡献最大）**：收敛指令（`(converge) 用能确定完成的最少步骤工作；不重复已做的读取；信息足够就交付`）与预算超支引导（`[cost-guard] 预算已超：立即以最少步骤完成当前目标…直接交付`）把代理从「探索-迭代」模式切换为「交付」模式：不重写已完成的代码、不做多余验证、不展开长链思考。实测二测中 spec 组输出+推理平均 101.3K/次，CG 组 86.1K/次（少 15%）；首轮同型 CLI 对比更悬殊（CG 93K vs spec 214K）。按 4.5 ¥/M 计，每少 1 万输出 token 省 ¥0.045，少 1 万推理 token 同样省 ¥0.045——一轮任务少写 2–5 万 token 就是 ¥0.1–0.2 量级的差异，与实测组间差（¥0.18/次）吻合。

2. **少工具调用、少上下文写入**：每次工具调用都产生一次新的 LLM 请求，工具结果还要写回上下文（缓存写按未命中输入 1.5 ¥/M 计费）。收敛 → 批量读取（一次读多个文件）、复用上下文已有信息（不重复 grep/read 已看过的内容）、信息足够就停止探索。省的是请求次数 × 输入/写入 token。

3. **保持前缀缓存红利（守护 30× 价差）**：成本守卫**不碰 persona / system 前缀**——路由（router-flash-cg）与引导（inbox next-step 近场注入、固定字符串）都不改变 system 前缀，因此每次请求都能命中 30× 便宜的缓存输入。实测两组命中率都高达 89–98%，说明省下的钱不是靠牺牲缓存，而是纯粹减少输出/推理量。

4. **预算守卫 + 峰谷错峰（兜底与削峰）**：项目级 ¥ 预算超支时注入一次「收敛交付」近场引导（GUIDE_BUDGET）；高峰时段单价 ×2，`cost_defer` 把非紧急任务登记进错峰队列，空闲时段（10 分钟粒度）由 daemon 自动执行。这两条在 headless 单条任务下触发有限（超支引导依赖用户消息事件），在 GUI 交互会话中是主要防线。

### 4.3 为什么"收敛"省的是真金白银（数据锚点）

- 输出+推理是 90× 最贵单价项；两组命中率无差（89–98%）→ 成本差异 100% 来自输出/推理量的差异。
- 二测：spec 比 CG 平均多写 15% 输出+推理 → 平均多花 ¥0.18/次（省 25%）。
- 无守卫组的"失控"案例：首轮 r3 花到 ¥1.24 仍在收尾（外部截停），同型任务 CG 组 ¥0.50 完整交付——预算守卫+收敛的价值在"停不下来"的场景最明显。
- 局限：收敛引导的效力依赖模型遵守程度，个体方差大（CG 组内 0.39–0.72）；它省的是"过度完成"的部分，对本来就一次成型的小任务（如二测 R1）几乎无差。

### 4.4 一句话总结

> 成本守卫不碰缓存红利（命中率两组同样高），它通过「首轮即收敛 + 超支收敛引导」压缩最贵的输出/推理 token 与多余工具往返，把每次任务从"充分探索"收敛到"够用即交付"——实测相同提示词下平均省 25%，省下的每一分都来自少写的那 20% token。

---

## 交付位置

- 首轮：`D:\DSH\测试\cg-实验\`（p1-cg-kb / p2-cg-dash / p3-spec-ledger / p4-spec-typing + results\ + REPORT.md）
- 二测：`D:\DSH\测试\cg-实验2\`（p1-cg-a ~ p6-spec-c + results\ + REPORT.md）
- 本整合报告：`D:\DSH\测试\cg-实验2\REPORT-总报告.md`