# 子设计 3：Daily Run 成本控制

**Date:** 2026-04-20
**Status:** Draft for discussion

---

## Summary

如果 evaluation 系统要长期跑 daily regression，成本控制必须是设计前提，而不是实现后的优化项。

在当前阶段，daily run 的**主成本不是 collection，也不是 workspace 执行本身，而是 LLM token**。尤其是：

- semantic judge 读取长 transcript
- semantic judge 对同一结果重复判分
- 使用大模型处理本可以规则化判断的 case
- judge 输出过长解释

本设计目标是：

- 保证 daily run 可以长期稳定运行
- 在有限 token 预算下优先覆盖核心故障模式
- 尽量把大模型调用缩小到最小必要集合
- 避免对未变化结果重复付费
- 让 LLM 只处理规则无法稳定判断的部分

---

## Cost Sources

### 1. Judge token cost

这是当前主成本。

主要包括：

- 读取长 transcript 或全量 workspace messages
- 把大量 tool trace 原文送进 judge
- 一个大 prompt 同时判断 root cause、causality、recommendation、overall quality
- 生成过长 explanation

### 2. Repeated judge cost

很多成本并不是来自新 case，而是来自对同一份 diagnosis 重复做 semantic judge。

主要场景包括：

- baseline diff 重算
- 展示逻辑变化
- judge prompt 升级但输出未变化
- 同一天重复 rerun 同一结果

### 3. Replay execution cost

包括：

- workspace 初始化
- source prepare
- metrics / TopSQL / SlowQuery / logs / profiling 调用
- follow-up 轮次

在当前问题下，它不是主成本，但仍需要受控。

### 4. Environment cost

包括：

- 固定 eval 环境的 API 配额
- 数据源访问稳定性和吞吐
- 外部依赖的时间和并发消耗

---

## Cost Control Principles

### 1. Core suite 小而精

daily regression 不追求“所有 case 都做 full semantic review”，而是优先覆盖最高价值模式。

### 2. 先 deterministic，后 semantic

先用规则做掉明确 pass/fail，只把边界问题交给 LLM。

### 3. 压缩 judge 输入

LLM judge 默认不能直接读取全量 transcript，而应只读取压缩后的 evaluation packet。

### 4. 结果缓存

相同输入不重复 judge，相同 diagnosis 不重复 semantic review。

### 5. 预算与熔断

一旦预算或环境状态异常，系统应主动降级，而不是把整批 run 拖死。

---

## Judge Input Compression Strategy

降低 token 成本最重要的一步，不是减少 case 数，而是减少 judge 的输入体积。

### Default rule

semantic judge 默认输入应为一个压缩后的 `evaluation packet`，而不是全量消息流。

建议结构：

```json
{
  "case_id": "TCOC-5019",
  "final_answer": "...",
  "facts": {
    "root_cause_candidates": [],
    "instances": [],
    "digests": [],
    "metrics": [],
    "tools_touched": [],
    "recommendations": []
  },
  "rubric": {
    "critical": [],
    "major": []
  },
  "negative_assertions": [],
  "baseline_diff": {}
}
```

### Do not send by default

- 全量 transcript
- 全量 workspace messages
- 全量 tool logs
- 全量 metrics 原始值
- 全量 evidence 文件

### Only include when necessary

- 少量必要原文片段
- 某条结论对应的关键证据摘要
- fail case 的额外上下文

---

## Suite Strategy

建议把 suite 分成四类：

### `core-daily`

- 10 到 20 个最关键 case
- 每天全跑
- 作为主 pass rate 和 regression 信号

### `daily-lite`

- 范围更广
- 每天跑，但默认只做 execution + deterministic

### `weekly-extended`

- 高成本或长链路 case
- 每周跑

### `manual-debug`

- 不进入定时任务
- 只用于人工验证

---

## Case Cost Tier

每个 case 在 authoring 时必须定义 `cost_tier`。

### `low`

- 主要依赖 metrics / TopSQL / SlowQuery
- 诊断链路短
- 没有 profiling

### `medium`

- 包含 logs / events / 少量 follow-up
- 可能需要更多 cross-reference

### `high`

- 包含 profiling / heap
- 需要更多 follow-up
- 跨多个系统或外部依赖

默认执行策略：

- `low`：可进入 daily，并优先只做轻量 judge
- `medium`：只保留少量代表 case 进入 core
- `high`：默认放 weekly，除非是强 guardrail case

但需要明确：`cost_tier` 主要反映 replay 成本，不等于 judge token 成本。一个 `low` case 如果把整段 transcript 送给 LLM，一样会很贵。

---

## Judge Cost Strategy

### Deterministic first

默认所有 case 都执行：

- execution checks
- extracted facts
- deterministic rubric

这些步骤的目标是最大化拦截掉“不需要 LLM 的 case”。

### Semantic on demand

只有以下情况才触发 LLM semantic judge：

- case 标记必须做语义判分
- deterministic 结果接近阈值
- 与 baseline 出现结构化 diff
- case 属于 `core-daily`
- 人工指定 rerun

这样可显著降低 token 成本。

### Split semantic tasks

不要用一个大 prompt 同时完成：

- root cause 判断
- causal chain 判断
- recommendation 判断
- overall quality 总评

更推荐拆成按需触发的小 judge：

- `root_cause_judge`
- `causal_chain_judge`
- `recommendation_judge`

只有某一维不确定时，才调用对应 judge。

### Model tiering

建议采用分级模型：

- `cheap judge`
  处理大多数 semantic 判断
- `expensive judge`
  只处理低置信度、回归 case、核心 case 或人工指定复核

默认策略：

- 小模型优先
- 大模型按需升级

### Short output contract

semantic judge 默认输出必须是短 JSON，而不是长篇解释。

建议默认字段：

```json
{
  "passed": true,
  "root_cause_score": 0.94,
  "causal_chain_score": 0.88,
  "recommendation_score": 0.79,
  "failure_codes": [],
  "reason": "root cause and evidence chain are consistent"
}
```

只有 fail case、回归 case 或人工要求 explain mode 时，才允许展开 explanation。

---

## Caching Strategy

### 1. Replay result cache

若以下输入完全一致，可直接复用上次执行结果：

- case version
- agent revision
- environment fingerprint
- prompt
- source snapshot

适用场景：

- judge 规则升级但 agent 未变化
- 重新生成 regression diff

### 2. Judge cache

若 diagnosis 输出未变化，则可以复用：

- facts extraction
- deterministic rubric result
- semantic judge result

只有 judge version 变化时，才需要重判。

### 3. Packet cache

若 final diagnosis 与 extracted facts 未变化，则压缩后的 evaluation packet 也应缓存。

这样可以避免：

- 每次 rerun 都重新拼装长上下文
- 为同一结果多次做上下文压缩

### 4. Explain-on-fail cache

对于 pass case，只保留短 verdict。

只有 fail / regression case 才生成详细 explanation，并单独缓存。这能避免把解释性 token 消耗摊到所有 case 上。

---

## Follow-up Budget

follow-up 是最容易放大 daily 成本的因素之一。

建议默认：

- `core-daily`：最多 1 轮 follow-up
- 特殊高价值 case：最多 2 轮
- `daily-lite`：默认 0 到 1 轮
- 超限后直接结束，并记录为结果的一部分

原则：

daily run 的目标是监控回归，不是在线人工调教 agent。

---

## Budget Model

建议显式定义 daily budget：

- 每日最大总 case 数
- 每日最大 semantic judge 次数
- 每日最大大模型 judge 次数
- 单 case 最大 semantic token
- 单 case 最大 explanation token
- 单 run 最大总 cost

### Degrade order

当预算接近上限时，按顺序降级：

1. 跳过 `weekly-extended`
2. 关闭非核心 case 的 semantic judge
3. 改为小模型 judge only
4. 关闭 explanation mode
5. 停止剩余非核心 case

---

## Circuit Breakers

系统需要自动熔断，避免无意义烧钱。

### Environment breaker

若短时间内大量 case 因环境失败，应中止 run，并标记为 `run_invalid` 或 `env_unhealthy`。

### Tool breaker

若某个关键 tool adapter 大面积失败，应停止依赖该 adapter 的后续 case。

### LLM quota breaker

若 semantic judge 配额不足，应退化为 deterministic-only，而不是整批 run 失败。

---

## Cost Metrics

daily run 至少应记录以下指标：

- total_duration
- case_count
- per-case token usage
- semantic judge token usage
- semantic judge input tokens
- semantic judge output tokens
- explanation token usage
- packet cache hit rate
- replay cache hit rate
- judge cache hit rate
- deterministic-only verdict count
- small-model judge count
- large-model judge count
- skipped-by-budget count

这些指标需要能按 suite、case、revision 查看趋势。

---

## Operational Policy

建议默认策略：

- 每天先跑 `core-daily`
- `daily-lite` 仅在 token 预算充足时运行
- `weekly-extended` 独立 schedule
- 高成本 case 需要明确 owner
- 每周 review 一次 token 成本和缓存命中情况

---

## Defaults

- daily run 默认以 `core-daily` 为主
- `high` cost case 默认不进入 daily 全量
- semantic judge 默认按需触发
- semantic judge 默认只读取压缩 packet，不读取全量 transcript
- semantic judge 默认使用短 JSON 输出
- 小模型优先，大模型只处理回归或争议 case
- follow-up 默认最多 1 轮
- 预算超过阈值时优先降级 semantic 深度，而不是让 core suite 失效