第5章 · Token经济学与上下文管理

5.1 三层压缩系统

第一层：Snip压缩（预防性）

Snip压缩的目标是在不影响对话质量的前提下，渐进式地回收Token。它的工作方式是：

扫描消息历史，找到"时间上远离当前对话焦点"的工具输出
将这些工具输出替换为一行摘要（如 "File content was read successfully"）
严格保护近期N轮对话的完整内容不被压缩

Snip压缩是静默执行的，用户不会感知到任何变化。

第二层：自动压缩（阈值触发）

当Token用量达到 有效上下文窗口 - 13,000 时，触发完整的对话压缩：

发起一次独立的LLM调用（使用更快的模型）
将整段对话历史作为输入
输出一份结构化的摘要
用摘要替换原始对话历史

13,000 Token的缓冲区是经验值——它为"压缩请求本身"和"压缩后的首次回复"预留了足够空间。

第三层：响应式压缩（紧急兜底）

如果自动压缩后API仍然返回 prompt-too-long，执行紧急压缩：

使用更激进的压缩策略
同时缩减 maxOutputTokens 预算（最多3次）
如果仍然失败，返回错误给用户

5.2 微压缩

这是一个精妙的优化。当用户通过 FileEditTool 修改了一个文件，系统会在消息历史中精确定位之前 FileReadTool 读取该文件的工具结果，并将其删除。

实现方式是在工具结果上维护文件路径索引。当检测到文件被修改时，通过索引快速定位过时的读取结果。

这比全局压缩更精确——只删除已知过时的数据，保留所有仍然有效的上下文。

5.3 缓存断点策略

Claude API支持Prompt Caching——对重复出现的前缀内容，只需支付十分之一的Token费用。Claude Code利用这一机制，在消息序列中的稳定位置插入缓存断点：

[系统提示] ← 缓存断点1（几乎不变）
[工具Schema] ← 缓存断点2（会话内不变）
[早期对话历史] ← 缓存断点3（压缩后稳定）
[近期对话] ← 不缓存（频繁变化）

成本计算公式：

实际成本 = input_tokens × price_per_token
         + output_tokens × price_per_token
         + cache_creation_tokens × price_per_token × 1.25
         + cache_read_tokens × price_per_token × 0.1

缓存读取只需正常价格的10%。在典型的多轮对话中，系统提示和早期历史会被反复缓存命中，实际输入成本可降低70-90%。

5.4 cost-tracker.ts：实时计费

cost-tracker.ts（323行）实现了精确的实时成本追踪：

每次API调用后累积Token和成本
按模型聚合统计（将具体版本号归一化为短名，如 claude-opus-4.1-20250514 → Opus）
处理Advisor工具的嵌套成本递归
接入OpenTelemetry计数器
会话结束时持久化到项目配置文件

第5章 · Token经济学与上下文管理