提示词成本实测：字符限额与 token 账单的错位陷阱

本文目标：解释一个反直觉的坑——记忆库的限额按「字符」计，而账单按「token」计，两者错位会导致「改英文省 token 却撑爆限额」的死循环；并给出一套可复现的零配额实测方法，让你在额度紧张时也能拿到真实分词数。

典型误判：看到「中文更耗 token」就把记忆库整体译成英文，结果字符数暴涨 45% 直接超限，写入被拒。

文中所有数值均为本机实测，不含推测；测量方法见第四节，可自行复现。

一、错位的根源：两个不同的计量单位

以 Hermes Agent 为例，内置记忆库 MEMORY.md / USER.md 的限额配置在 config.yaml：

memory:
  memory_char_limit: 3000   # 单位是「字符」；本机覆写值（Hermes 出厂默认 2200/1375）
  user_char_limit: 2000     # 单位是「字符」

但模型计费按 token 结算。这两个单位之间的换算率，取决于内容语言：

语言	每字符折合 token	3000 字符预算折合 token
中文（G​emini 分词器）	≈ 0.59	≈ 1770
英文（G​emini 分词器）	≈ 0.29	≈ 870

于是出现两难：

• 留中文：字符数没超，但每轮成本高；
• 译英文：token 降了，可英文表达同样的信息需要约 2.5 倍字符——3000 字符装不下原来的内容。

二、实测：中英文 token 成本到底差多少

G​emini 真值（gemini-3.8-flash，countTokens 实测）

样本	中文字数 / token	英文字符 / token	倍率
规则类长句（Fork-First）	140 / 94	361 / 82	1.15x
说明类段落（记忆架构）	175 / 107	374 / 103	1.04x
混合配置（大量英文术语）	174 / 86	181 / 77	1.12x
短指令	10 / 7	24 / 6	1.17x
合计	499 / 294	940 / 268	1.10x

结论：G​emini 下中文 ≈ 英文的 1.10 倍 token。

注意「混合配置」样本倍率只有 1.12x 但英文字符数几乎没增加（181 vs 174）——因为技术术语、路径、标识符本身就是 ASCII，中英混排的内容翻译收益最低。

O​penAI o200k_base 对照

• 同一句 Fork-First：中文 140 字符 = 104 token，英文 361 字符 = 80 token（1.30x）；
• 六组配对基准：中文 1.06–1.55x，平均 1.34x；日文 1.73x；
• 旧 cl100k_base 分词器下中文达 2.08x——分词器代际差异极大。

关键教训：厂商不可外推

G​emini 1.10x vs O​penAI 1.34x，相差约 22%。G​emini 对 CJK 明显比 O​penAI 友好。

不要用 tiktoken 估算 G​emini 的开销，会高估约 20%。 要准数就必须调对应厂商自己的计数接口。

三、正确顺序：先做减法，再谈换语言

既然译英文会撑爆字符限额，正确操作是：

1. 分类：高频必带 vs 低频可检索
2. 迁移：低频条目先进检索层（如 OpenViking），腾出字符预算
3. 压缩：把内容压掉约 60%
4. 翻译：此时译英文才装得进限额
5. 校验：实测字符数确认未超限

本机 2026-09-09 的落地结果：

文件	token 变化	字符占用
SOUL.md	826 → 797	无限额
MEMORY.md	1525 → 740	2992 / 3000
USER.md	1079 → 464	1996 / 2000

收益要按真值重算：按 o200k 的 1.34x 估算会得出「省 1426 token/轮」，但按 G​emini 的 1.10x 实际只省约 200 token/轮。相对每轮约 21.7k 的固定底座，这只占 0.9%。

所以换语言的真正理由是腾出限额空间（同样预算能塞进更多事实），而不是省下那点 token。

一个反例：不要为了小钱动缓存前缀

SOUL.md 位于系统提示词 cache 前缀的最头部，任何改动都会让它后面整段前缀失效一次，属一次性重算成本。为省几十 token 反复改它，是净亏的。

四、零配额实测方法（可复用）

想在不消耗任何生成配额的前提下拿到 G​emini 的真实 token 数，用 Antigravity 的 countTokens 端点——它只做计数，不做生成。

请求构造

POST https://daily-cloudcode-pa.googleapis.com/v1internal:countTokens
Authorization: Bearer <access_token>
User-Agent: antigravity/hub/2.8.1 windows/amd64
Content-Type: application/json

{
  "request": {
    "model": "models/gemini-3.8-flash",
    "contents": [{"role": "user", "parts": [{"text": "待计数的文本"}]}]
  }
}

响应：

{ "totalTokens": 294 }

三个必踩的坑

坑	现象	正解
body 格式	直接给 {"model":..,"contents":..} 返回 400 Unknown name "model"	必须套一层 {"request": {...}}
端点路径	/v1beta/models/{m}:countTokens 与 /v1/models/{m}:countTokens 均返回 404	只有 /v1internal:countTokens 通
网络出口	直连超时	需挂本地代理（如 127.0.0.1:3067）

排错信号：如果拿到的是 400 而不是 404/403，说明端点存在且认证已通过，只是 body 格式错——方向是对的，改格式即可。

凭据来源与保密

access_token 从 EasyCLIProxyAPI 的 auth/antigravity-*.json 取（字段 access_token，project_id 默认 aicode-consumers）。

安全提醒：该 token 等价于账号凭据，严禁打印到日志、写入公开仓库或提交进任何公开文档。建议只在临时脚本中读取并立即销毁，用后删除脚本。

五、速查表

场景	做法
想知道某段提示词真实 token 数	countTokens 端点，零配额
记忆库顶格了	先迁移低频条目，不调限额
想改英文省 token	先压掉约 60% 内容，再译，最后实测字符数
估算 G​emini 成本	用 1.10x，不要用 o200k 的 1.34x
改 SOUL.md 前	三思——它在缓存前缀头部，改动有一次性代价
中英混排的技术内容	翻译收益最低（术语本来就是 ASCII），优先压缩而非翻译

---

相关阅读：《Hermes 双记忆库并行架构与迁移 SOP》、《Google Antigravity 双配额池隔离陷阱与实时监控》