Token消耗优化器

SKILL.md

---
name: token-optimizer
version: 1.5.0
description: |
  API账单太贵？6级优化+7步诊断+Pre-LLM压缩管道+CCR可逆压缩，逐项审计token消耗并量化优化。v1.5新增：headroom(26.7K⭐)的CCR模式（压缩→标记→按需恢复，零信息损失）+跨Agent缓存共享+失败会话挖掘。实测代码搜索省92%、SRE日志省92%、Issue分类省73%。
  触发词：省token、降低消耗、API费用高、成本控制、API太贵、批量调用省钱、RAG优化、Agent成本、token预算、降本增效、成本优化、模型切换、缓存策略、prompt瘦身、成本预测、工具输出压缩、上下文压缩、CCR压缩、可逆压缩
  排除：模型推理速度优化、模型训练微调成本、硬件采购
---

# Token消耗优化器 💰

## 触发条件
- API费用太高/预算不够
- prompt/上下文太长
- 优化skill/Agent的token效率
- 对比不同模型成本
- RAG场景消耗过大
- 需要做预算规划
- 工具输出太大撑爆上下文

## 核心流程（7 Steps）

### Step 1: 消耗诊断
审计7大消耗源：System Prompt/对话历史/SKILL加载/工具调用/references/RAG/输出长度

### Step 2: 基线评分（6级体系）
- L0未优化→L1基础→L2标准→L3高级→L4精细→L5极致
- 量化每个消耗源token数，标记Top3大户

### Step 3: 分层优化（P0-P5优先级）
- P0: Prompt瘦身（省30-75%）
- P1: SKILL瘦身≤5KB（省50-70%）
- P2: 历史管理（省60-80%）
- P3: 工具调用优化（省40-70%）
- P4: 输出控制（省30-60%）
- P5: 模型路由（省40-80%）

### Step 4: 成本速算与对比
- 计算基线成本，多平台对比

### Step 5: 预算预测
- 月/季成本预测+预警阈值

### Step 6: 生成优化方案
- 含优先级/节省预估/实施难度/ROI

### Step 7: 执行与验证
- A/B对比+质量检查（质量下降≤10%）

## Pre-LLM 压缩管道（v1.4.0 新增）

> 灵感来源：headroom (26.7K⭐) — 在工具输出到达LLM之前进行压缩，减少60%+ token消耗

### 5层压缩流水线

```
原始内容 → L1过滤 → L2摘要 → L3去重 → L4结构化 → L5裁剪 → 送入LLM
```

| 层级 | 技术 | 压缩率 | 适用场景 |
|------|------|--------|---------|
| L1 噪声过滤 | 删除日志头/时间戳/分隔符/空行 | 20-30% | 所有工具输出 |
| L2 渐进摘要 | 保留首段+末段+关键段落，中间折叠 | 40-60% | 长文档/网页 |
| L3 语义去重 | 检测重复段落，保留首次出现 | 15-25% | 多工具结果合并 |
| L4 结构化提取 | 提取JSON/表格/列表，丢弃叙述 | 50-70% | API响应/日志 |
| L5 相关性裁剪 | 按任务目标只保留相关片段 | 30-80% | RAG检索/搜索结果 |

### 工具输出压缩模板

```
## 压缩前
[完整工具输出: ~5000 tokens]

## 压缩后（L1+L4）
- 状态: success
- 关键结果: [仅保留与任务相关的字段]
- 异常: [仅保留非OK项]
[压缩后: ~500 tokens, 节省90%]
```

### 压缩决策树

```
工具输出 > 2000 tokens?
├─ 是 → 需要压缩
│   ├─ 结构化数据(JSON/API)? → L1+L4 (提取关键字段)
│   ├─ 长文本(网页/文档)? → L1+L2 (首尾+关键段)
│   ├─ 日志/输出流? → L1+L4 (错误+摘要)
│   └─ 多源结果? → L1+L3+L5 (去重+相关性)
└─ 否 → 直接传入
```

### CCR 可逆压缩模式（v1.5.0 新增）

> 来源：headroom (26.7K⭐) — Compress-Cache-Retrieve，零信息损失的确定性压缩

**核心机制：** 不同于LLM摘要（可能丢信息/幻觉），CCR用确定性算法压缩，原始数据本地缓存，LLM按需取回。

```
Step 1: 压缩 → 用确定性算法压缩工具输出（JSON提取/日志去噪/代码结构保留）
Step 2: 标记 → 注入可逆标记："98个字段已压缩，需详情调用 retrieve(hash)"
Step 3: 恢复 → LLM判断需要细节时，调用 retrieve_compressed(chunk_id) 获取原始数据
```

**实测压缩率（headroom 基准测试）：**

| 场景 | 原始Token | 压缩后Token | 节省率 |
|------|----------|-----------|--------|
| 代码搜索（10万行项目） | 17,765 | 1,408 | **92%** |
| SRE日志排查（10K行日志） | 65,694 | 5,118 | **92%** |
| GitHub Issue分类 | 54,174 | 14,761 | **73%** |
| 代码库探索 | 78,502 | 41,254 | **47%** |

**与v1.4.0的5层管道关系：** v1.4的L1-L5是压缩策略分类，CCR是执行模式——两者互补。L4（结构化提取）最适合CCR模式，因为结构化数据的压缩天然可逆。

**跨Agent缓存共享：** 多个Agent可共享压缩后的缓存（如Claude审查→Codex测试→Cursor重构，后两个直接复用首个的缓存索引，省40-60%初始扫描Token）。

**失败会话挖掘（headroom learn 模式）：** 分析失败的Agent会话日志，挖掘错误模式，自动修正配置文件。实测：9个失败会话/378次调用 → 每次会话节省8,000 tokens。

### 实施检查清单

- [ ] 所有工具调用设置 response_length 参数（优先 short/medium）
- [ ] 网页抓取后执行首尾提取（不超过2000字）
- [ ] 搜索结果只保留 Top 3，摘要模式
- [ ] 代码文件只传相关函数，非整个文件
- [ ] 对话历史超过10轮时启用摘要压缩
- [ ] RAG chunk 大小控制在500-1000 tokens
- [ ] 结构化数据输出启用CCR模式（JSON/API结果） ← v1.5.0
- [ ] 多Agent协作场景启用共享缓存 ← v1.5.0

## 成本速算表（2026年6月）
| 模型 | 输入$/1M | 输出$/1M | 适合 |
|------|---------|---------|------|
| SiliconFlow 9B | 免费 | 免费 | 高频简单 |
| Gemini Flash | 0.10 | 0.40 | 超长文档 |
| GPT-4o-mini | 0.15 | 0.60 | 日常对话 |
| Haiku 3.5 | 0.25 | 1.25 | 高性价比 |
| GPT-4o | 2.50 | 10.00 | 复杂推理 |

## 紧急降本剧本
1. 切换免费/低价模型（省80-100%）
2. Prompt瘦身（省30-50%）
3. 历史截断到3轮（省50-70%）
4. 关闭非必要技能（省20-40%）
5. 工具返回short模式（省30-60%）
6. 部署结果缓存（省40-80%）
7. **启用Pre-LLM压缩管道（省60-90%）** ← v1.4.0
8. **启用CCR可逆压缩（结构化数据省92%）** ← v1.5.0新增

## Anti-rationalization 反借口表

| # | 借口 | 真相 |
|---|------|------|
| 1 | "这个优化影响不大" | 每次省10%，10次调用就是省一次完整调用的成本 |
| 2 | "压缩后质量会下降" | L1-L3几乎零质量损失，L4-L5有明确质量标准(≤10%) |
| 3 | "用户不在乎费用" | 用户永远在乎费用，只是不说——直到账单来了 |
| 4 | "模型越来越便宜不用优化" | 用量增长速度远超降价速度，总成本在上升 |
| 5 | "实施太复杂了" | Pre-LLM压缩只需在工具输出后加一步处理，5分钟实施 |
| 6 | "已经优化过了" | 检查是否用了5层管道，大部分只做了L1 |
| 7 | "这个场景不适用" | 任何>2000 tokens的工具输出都适用 |

## 约束
1. 质量下降≤10%
2. 优先优化固定成本（System Prompt/SKILL）
3. 给出量化预估（必须带数字）
4. 紧急方案标注恢复条件
5. 压缩前必须评估任务对信息完整性的依赖程度

## Output Language
中文输出