我们优化 Token，不是为了省钱，而是因为 Token 是我们产品的原材料——而浪费是一种产品缺陷。
00 · ActelosAI 为什么谈 Token
生成式引擎优化（GEO）本质上是一场押注于「与前沿模型对话」的生意。我们的 agent 调用模型去测量一个品牌在 AI 生成回答中的呈现方式，并越来越多地去塑造它。每一次查询、每一步推理、每一页检索——它们都是 Token。一家卖「生成式引擎优化」的公司，首先必须擅长优化自己对生成式引擎的消耗。
你不可能一边教客户做生成式引擎优化，一边让自己的 Token 账单漏水。我们应该先把同样的纪律用在自己的工作中。
01 · Token 是产品问题，不是成本问题
默认的本能是把 Token 消耗当作一条基础设施成本——一张可以往下砍价的账单。这个框架是错的。对一家 AI Native 公司而言，Token 是单位经济学：它是我们所交付一切的分母，并在每一个 agent、每一个客户、每一次重试中复利累积。
真正的问题比账单更深。一个 agent 的自主性携带两重授权，而它们几乎从没有被分开过：
| 授权 | 含义 | 我们的做法 |
|---|---|---|
| 执行授权 | 行动的权利：调用工具、写文件、跑代码。 | 在明确范围内授予。 |
| 消费授权 | 消费的权利：发起 LLM 请求、派生 subagent。 | 谨慎授予，且必须可见。 |
作者原稿记录的一次事故，说明了忽略后者可能发生什么。一次任务失控成 12 个 subagent → 265 次 LLM 请求 → 约 1980 万 Token → 不到 5 分钟烧掉 ≈ ¥1000。这些数字来自作者的内部记录，并非受控基准测试或客户成果。账单拆解如下：
| 指标 | 数值 | 信号 |
|---|---|---|
| 输入 | ~19.64M | 上下文扛下了大头。 |
| 输出 | ~0.13M | 模型几乎没产出。 |
| 缓存读取 | 每轮都是 0 | 未记录到缓存读取，根因需结合请求记录核实。 |
教训 agent 的自主性有两半——行动的权利与消费的权利。两者都需要明确边界；消费还需要可见的预算和停止条件。
02 · 一笔 Token 账单的解剖
要治理消费，先要看见它。大多数人严重误判了自己的 Token 去向，原因是一个反直觉的可能性：你亲手打出的字，可能只占实际处理输入的一小部分。
| Token 的去向 | 占比 | 原因 |
|---|---|---|
| 你的输入 | 随任务而变 | 你真正写下的提示词。 |
| 系统税 | 大头 | 可能在多次调用中重复出现的系统指令，以及实际加载的工具和上下文定义。 |
| 历史 | 大头 | 应用实际保留的历史轮次。 |
| 检索上下文 | 可变 | 你塞进窗口的一切。 |
这就是为什么只建议「把提示词写短」往往不够。成本住在你携带的东西里，而不是你输入的东西里。因此优化不从消息开始，而从环境开始：系统提示、工具定义、以及对话的卫生。
03 · 五层漏斗
下面的五层漏斗，是检查 Token 效率的一种实用顺序。先从顶部开始，再通过实际任务测量，判断哪一层最有杠杆。
| # | 层 | 回答的问题 | 例子 |
|---|---|---|---|
| 1 | 不用模型 | 这一步真的需要智能吗？ | 确定性代码、缓存、规则。 |
| 2 | 用更便宜的模型 | 需要旗舰模型吗？ | 例行步骤路由到小模型。 |
| 3 | 少发 Token | 我是否在携带死重？ | 压缩上下文、丢弃过期历史。 |
| 4 | 让 Token 变便宜 | 这段内容是否在重复付费？ | 提示词缓存。 |
| 5 | 不重复付费 | 这次调用能复用吗？ | 经过有效性检查的结果复用、记忆化。 |
不要停在缩短提示词。先问：这次调用是否必要，重复上下文能否复用。
04 · 缓存：一个高杠杆的起点
对于重复提示词，缓存可以明显降低输入处理成本。但缓存读取折扣，不等于整项任务的折扣：写入、未命中、输出，以及可能的存储费用，都需要一起计算。
| 厂商 | 机制 | 关键点 |
|---|---|---|
| Anthropic | 提示词缓存 | 5 分钟写入通常为基础输入价的 1.25 倍，1 小时写入为 2 倍；读取价格随模型而变。 |
| OpenAI | 提示词缓存 | 可缓存前缀、写入计费和保留策略随模型而变；prompt_cache_key 可帮助路由，但不保证命中。 |
| 上下文缓存 | Gemini 2.5 及更新模型支持隐式缓存；最低长度和价格按模型确认。 |
技术参考： Anthropic 提示词缓存, OpenAI 提示词缓存、Google 上下文缓存；查阅于 2026 年 9 月 8 日。
让缓存真正生效的三条纪律：
01 · 稳定的放前，动态的放后
被缓存的前缀必须逐字节一致。把系统提示、工具 schema、静态指令放在最前；把可变部分——用户消息、检索上下文、工具结果——放到最后。开头哪怕一个字符的漂移，都会让其后全部失效。
02 · 别打断缓存链
对对话开头的任何编辑，都会重置其后所有内容的缓存。把共享前缀当作不可变的——只追加，不插入。
03 · 校验缓存是否真的活着
在上述事故中，cacheReadTokens = 0 是需要排查的信号，而不是完整诊断。应检查厂商返回的用量字段、可缓存前缀长度、缓存设置、过期情况与请求变化。“缺少会话头”不是缓存未命中的通用解释。缓存指标必须成为遥测的一等公民，否则你会在“优化”一个根本没接上的杠杆。
05 · 上下文管理：只携带工作真正需要的内容
当重复上下文占据输入的大头，杠杆在于你停止携带的东西。纪律如下：
- 早压缩、勤压缩 长会话会累积陈旧轮次，模型每轮都要重读。在保留后续所需判断和证据的前提下，把已完成工作折叠成摘要；同时测量压缩收益与缓存复用损失。
- 环境瘦身 检查 Memory、Rules、Skills、MCP 实际加载进模型上下文的内容，在任务需要时加载有用的部分。
- 检索，而非囤积 小而精准的检索，胜过塞满的窗口——对成本和对答案质量都是如此。
上下文的纪律是减法，不是加法。你毫无目的地携带的每一个 Token，都是对之后每一轮征收的税。
06 · 模型分级 + 结构化输出
不是每一步都需要旗舰模型，也不是每一个回答都需要写成散文。
按难度分级
把旗舰模型留给真正需要判断力的步骤——推理、综合、边界情况。把例行步骤——分类、格式化、抽取——路由到更小、更便宜的模型。节省幅度取决于模型、重试与质量要求；应比较每项成功任务的成本。
拧推理旋钮
reasoning.effort / text.verbosity 这对旋钮（OpenAI）在支持的模型上提供了分开的控制：它把模型思考多用力和它说多少话解耦。例行工作调低；只在深度能带来回报处调高。
强制结构
结构化输出——JSON schema、工具调用——压掉了模型注水的倾向。受约束的格式可以减少冗余文字和格式重试，但不保证 Token 更少、内容正确或任务一定成功。
07 · Agent 架构：Token 总量 ≠ 费用
一个值得注意的区别：Token 总量本身并不能决定费用。 在作者原稿记录的一次内部对比中，Claude Code Internal 跑了 22 次小请求、花 ¥9.05；CodeBuddy IDE 只跑 2 次大请求、却花了 ¥18.34——Token 少得多，费用却是两倍。在把差异归因于架构之前，需要比较模型、输入输出构成、缓存使用与计费条件。这些数字仅说明所记录的运行，不构成同等条件下的产品排名。
由此得出三条架构规则：
- 限制 subagent 树 深度与扇出会让请求指数级翻倍。两者都要设上限，派生必须给出理由。
- 偏好边界清晰的调用 在不损失必要上下文和质量的前提下，拆分工作以降低总成本；调用更多不等于一定更便宜。
- 让「消费」成为一等产品界面 agent 应当实时显示运行成本、缓存命中率与消费上限——而不是把它们藏进月度账单。
08 · 需要盯住的数字
你无法治理你测不到的东西。这七个指标一起看，才能告诉你 Token 策略是否奏效：
| 指标 | 揭示什么 |
|---|---|
| 单位任务成本 | agent 一次运行的单位经济学。 |
| 缓存命中率 | 你最大的杠杆是否接上了。 |
| 输入输出比 | 上下文是否臃肿。 |
| 单位产出 Token | 每单位交付价值的效率。 |
| P50 / P90 / P99 延迟分位 | 分级与缓存是否健康。 |
| 重试率 | 解析与确定性在哪失效。 |
| 单客户成本 | GEO 原生视角：每次交付的毛利。 |
成功完成一项任务的成本，是经济性北极星；质量、控制与延迟是它的约束。
09 · 这对 ActelosAI 意味着什么
对 ActelosAI 而言，Token 效率应该进入能力设计本身。Actelos Delta 帮助判断什么结果值得追求，以及用什么证据证明变化有用；Actelos Forge 把这些判断落实到工程中：模型选择、上下文、权限、评估，以及运营这项能力所需的资产。
增长营销中的 GEO 则提供了一个具体的应用场景：
- 共享且被缓存的 ontology 在所选厂商支持的前提下，把经授权的品类定义、品牌事实库和查询库放入稳定、可复用的前缀。
- 单品牌每日预算 设定约定的消费上限；触顶应该触发复核，而不是一张意外账单。
- 按问题类型分级模型 能用确定性检查或较小模型完成的工作，不必调用更大的模型；把更深的模型判断留给真正需要它的问题，并通过评估验证。
- 先测后优 我们从不优化一个看不见的杠杆。
10 · 演进方向：从按 Token 计费到按结果计费
按 Token 计费是一种过渡期的诚实：它是我们目前拥有的，而不是我们想要的。客户购买的价值不是「更少的 Token」，而是一个在 AI 回答中被呈现、被引用、被信任的品牌。随着推理模型与缓存的成熟，我们期待更多商业模式把收费与有用输出及业务结果连接起来，而不只看输入量。
但这种迁移不会让我们放松。在计费追赶上价值之前，把 Token 当作原材料——测量、缓存、分级、设限——的公司，会战胜把它当作账单的公司。成本纪律不是野心的敌人，而是野心得以落地的方式。
我们的立场 Token 优化不是一场省钱运动。它是一家 AI Native 公司对原材料所怀的、如同制造企业对待钢材般的尊重。浪费不是支出，而是缺陷——而我们拒绝交付缺陷。