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

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,7651,40892%SRE日志排查（10K行日志）65,6945,11892%GitHub Issue分类54,17414,76173%代码库探索78,50241,25447%

与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 Flash0.100.40超长文档GPT-4o-mini0.150.60日常对话Haiku 3.50.251.25高性价比GPT-4o2.5010.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层管道，大部分只做了L17"这个场景不适用"任何>2000 tokens的工具输出都适用

约束#

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

Output Language#

中文输出