上下文成本由基础上下文和会话数决定

更新于 2026-07-05

**「为什么上下文这么多，不是每轮都压缩吗」——压缩不是每轮发生，且只压历史。每次请求仍要带：系统/开发者指令、项目 AGENTS/rules/skills 列表、工具 schema、压缩后的历史摘要、最近几轮原文。如果这堆基础包袱本身就很大，压缩历史也只能从 180k 降到 130k，不会降到 10k。**

成本公式

每小时消耗 ≈ 请求次数 × 每次上下文大小。三个乘数都可优化：

  1. 会话数：多个 session 并发/交替跑，每个都自带一份系统上下文、项目上下文、摘要和最近历史。
  2. 请求次数：同一功能多线程反复跑。
  3. 单次上下文：重规则 + 多工具 + 长历史 + 长工具输出。

优化手段

  • 一个功能只留一个主 session，做完归档
  • 新任务开新线程只带 10–20 行 handoff，不继承整段历史
  • 命令输出限量（精确文件 + 行号 + max_output_tokens），避免全量 diff / 全仓 rg / 长日志
  • 长规则迁到按需 reference，AGENTS.md 只放每次都要看的短规则
  • 简单 UI 小改用轻量模型/低推理，别每个按钮都上高推理
  • 少开并行 subagent

看账要区分 cached

日志里的 total 大头常是 cached input（重复前缀）。真实新增 = 非缓存输入 + 输出。判断「贵不贵」要看非缓存部分，但缓存仍占窗口、仍计入 total。

相关