拆.
AI Agent 设计学 · 卷 02 · 主循环——AI 怎么'思考'一轮对话 · 第 03 章
主循环——AI 怎么'思考'一轮对话 · 第 03 章

上下文窗口与 token 经济学

把 token 当资源管的产品判断

约 4500 字读完约 23 分钟craft：B+发布于 2026-06-21

一、原理：把 token 当资源管的产品判断

第 0.3 章我们已经知道 token 是 AI 产品的稀缺资源。这一章我们走深一层——把 token 当资源管，需要建立一套"经济学"思维。

经济学的核心是稀缺与配置。同一项目里有几种不同的"token 消费场景"：

场景 A：高频小消费——用户问"帮我看下这个函数怎么写更好"。这种问题每天可能问 50 次。每次消耗 5K-10K tokens。总消耗 250K-500K tokens / 天。

场景 B：低频大消费——用户说"重构这个模块"。可能一周做 1-2 次。每次消耗 100K-300K tokens。总消耗也是 200K-600K tokens / 周。

场景 C：系统级开销——title agent、summary agent、compaction agent 这些 background 任务。用户感知不到，但每个 session 都会跑。每次几百 tokens，但每个 session 都有，累积下来不少。

这三种场景的"经济学性质"完全不同。

场景 A 是单次便宜但累积可观——需要的策略是降低单次成本。比如用 prompt caching 让 system prompt 部分能复用、用小模型代替大模型。

场景 B 是单次贵但低频——需要的策略是让单次任务完成度高——不要 3 次跑了 3 次都没干完。

场景 C 是单次便宜但每次都跑——需要的策略是评估必要性——这个 system 任务真的需要 LLM 吗？能不能用确定性算法代替（比如 summary 改成 diff 计算）？

把这三种场景的策略合起来，就是一套 token 经济学思维。它不是"省 token"，是把 token 分配到价值最高的地方。

但 token 不只是钱。还有几个隐藏维度：

Token 是延迟。LLM 处理 50K tokens 比处理 5K tokens 慢得多——大约慢 5-10 倍。一个 100K tokens 的 prompt 可能要 30 秒首 token、几分钟才出完。这直接影响 UX——用户等不了。

Token 是错误率。LLM 在长上下文里的注意力会"散开"——这就是 lost in the middle 现象。50K tokens 的 prompt 里，写在第 30K 位置的关键指令可能被模型忽略。所以长 prompt 的错误率高于短 prompt。

Token 是缓存效率。如果你的 prompt 结构稳定（system 部分不变、只是 messages 增加），Anthropic 的 prompt caching 能命中 90% 折扣。如果 prompt 每次都变（每次重组），命中率 0%。

把这三个隐藏维度合起来——token 不只是钱，还是延迟、错误率、缓存效率——你才能真正做好 token 经济学。

二、案例：opencode 的 token 经济学三件套

opencode 在 token 经济学上有三套机制叠加。我们一个个看。

第一套：粗粒度估算 + 精确报销。

opencode 不用每个 provider 的精确 tokenizer。它用一个简化的 4 字符近似（packages/core/src/util/token.ts:5）做本地估算——4 个字符算 1 个 token。误差 5-10%。

为什么这样选？因为精确 tokenizer 太重——加载一个 OpenAI 或 Anthropic 的 tokenizer 模型要几十 MB、要 init time。opencode 不愿意为了 5% 的精度引入这个复杂度。

但报销时用真实 token 数——每次 LLM 调用完成后，provider 在 response body 里附带 usage.input_tokens / usage.output_tokens 的精确值。opencode 用这些精确值算 cost、累加到 session 总额。

这种"估算用近似、报销用真实"的设计很务实——决策时不需要精确（决定要不要 compaction，5% 误差不影响），结算时需要精确（用户看的成本必须准）。

第二套：三层阈值驱动决策。

opencode 在 compaction.ts 定义了三个魔法数字：

PRUNE_MINIMUM = 20_000    
PRUNE_PROTECT = 40_000    
DEFAULT_TAIL_TURNS = 2

这三个数字是 opencode 关于 token 经济学的核心判断：

PRUNE_MINIMUM = 20K——压缩有成本（要让 LLM 读历史再写摘要），20K 以下压不值得。这是个"压缩门槛"。

PRUNE_PROTECT = 40K——最近 40K tokens 范围内的工具输出完整保留，不参与压缩。理由是这些是 LLM 当前"工作记忆"——压缩了 LLM 就忘了刚读的文件。

DEFAULT_TAIL_TURNS = 2——最近 2 个完整 turn 不压缩。理由跟 PRUNE_PROTECT 类似——保护"近期"内容。

这三个数字是经验调出来的——opencode 团队大概做了上百次实验确定。不是拍脑袋来的。把这种"经验数字"显式写在源码、用大写常量命名，意味着它们是产品判断不是技术细节。

第三套：cost 跟钱直接挂钩。

session.ts 里有个 getUsage() 函数。每次 LLM 调用完成后算这次的 cost：

cost = (input_tokens × input_price 
       + output_tokens × output_price 
       + cache_read_tokens × cache_read_price 
       + cache_write_tokens × cache_write_price) / 1_000_000

价格表从 models.dev 拉取。每个模型有自己的定价：

Claude 3.5 Sonnet: input $3/M, output $15/M, cache_read $0.30/M, cache_write $3.75/M
Claude 3 Haiku: input $0.25/M, output $1.25/M
GPT-4o: input $2.50/M, output $10/M

注意缓存价格——cache read 比 input 便宜 10 倍。这是 Anthropic 的 prompt caching 经济学——你愿意让某段 prompt 写一次缓存（cache_write，贵一点），后续可以 10 倍便宜地复用（cache_read）。

opencode 整合了 Anthropic 的 cache_control 机制——它会把 system prompt + tools 描述这种不变的部分标记为可缓存。每次 LLM 调用会自动命中缓存——只为变化的 messages 部分付全价。

这对长 session 是巨大的成本优化。一个 200 turn 的 session 可能有 50K tokens 的稳定 system 部分——如果不用缓存，每次都付全价 50K × 200 = 10M tokens；用了缓存，第一次写入付 1×50K，后续 199 次只付 0.1×50K = 1M tokens。降本 90%。

这就是为什么 0.4 章我们提到 opencode 把 system prompt 拼装顺序设计成"不变的在前、变化的在后"——为了 caching 命中率。

三、设计启示：token budget 决策框架

这一章的核心论点：做 AI 产品要建立 token 经济学思维，把 token 当资源管而不是当成本省。

你需要建立的几个决策框架：

框架 1：高频 vs 低频任务分开优化。

高频任务（场景 A）的优化方向是降单次成本——caching、小模型、context trim。低频任务（场景 B）的优化方向是提一次完成率——给足够 context、用大模型、加 plan 阶段。两者用同一套优化策略可能两边都没做好。

框架 2：system 任务必须评估必要性。

opencode 的 summary agent 不调 LLM——它是 diff 聚合（第 2.5 章会展开）。这是个明智选择——不需要 LLM 智能的任务用确定性算法，省下大量 token。

很多 AI 产品犯的错——把每个"看起来 AI"的任务都用 LLM 做。"自动生成 session 标题"——LLM；"算 file diff"——LLM；"判断用户意图"——LLM。其实很多任务用规则、用字符串处理、用现成的算法都能做，根本不需要 LLM。

每个 system 任务问自己——这个真的需要 LLM 吗？如果不需要，省下来的 token 给真正需要 LLM 的任务用。

框架 3：prompt caching 是必选项不是 optional。

如果你用 Anthropic 的 LLM 而不用 prompt caching，你的成本是别人的 10 倍。这不是 nice-to-have——是必做。

要用好 caching 需要 prompt 结构设计——把不变部分放前面、变化部分放后面。这要求你设计 prompt 时就考虑 caching——不要先写好再后悔。

框架 4：监控 cost 而不是 token。

cost 是用户能感知的指标——他们看账单看的是 $ 不是 tokens。token 数能告诉你"消耗了多少"，cost 能告诉你"花了多少钱"。这两个数在不同 provider / 不同模型上不一样——同样 100K tokens 用 Claude 3.5 跟 Claude 3 Haiku 差 12 倍。

在 UI 上展示 cost，让用户感知到自己的"消费"。这种透明度建立信任——用户知道每次对话花了多少钱，更愿意按需使用而不是滥用。

框架 5：建立"任务 → token 预算"映射。

不同任务有不同的"合理 token 范围"：

  • 问一个简单问题：5K-10K tokens
  • 改一个简单 bug：20K-50K tokens
  • 重构一个模块：100K-300K tokens
  • 完成一个 feature：300K-1M tokens

如果你的 AI 产品给"简单问题"消耗了 100K tokens——肯定哪里不对。要么 system prompt 太长、要么读了不必要的文件、要么 LLM 在死循环。

把这种"任务复杂度 → token 范围"的映射建立起来，作为监控的基准。超出预算就告警——可能是 bug 也可能是用户场景出了问题。

最后一个观察。Token 经济学这种思维在 AI 产品开发里还很新——大部分团队还在"省 token"的初级阶段（把 prompt 写短一点）。真正的 token 经济学是把 token 分配到价值最高的地方——某些场景该多花、某些场景该少花，关键是判断标准清晰。

opencode 的三个魔法数字（20K / 40K / 2）就是这种判断标准的产物。它们不复杂——三个数字而已——但背后是上百次实验调出来的经验。这是 AI 产品的核心知识资产。

下一章 2.4 我们看 compaction——当 context 超出 token 预算时怎么办。这是 token 经济学落地的最具体场景。

← 上一章
一次 turn 的完整生命周期
下一章 →
Compaction