Token消耗优化器

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压缩、可逆压缩 排除：模型推理速度优化、模型训练微调成本、硬件采购

触发条件

• 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层压缩流水线

text

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

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

工具输出压缩模板

text

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

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

压缩决策树

text

工具输出 > 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按需取回。

text

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

中文输出