Agent 成本体检：92,413 个 token 的启动账

一句话结论：Agent 的账单首先不是"模型单价"问题，而是你把多少不需要的东西塞进了每一轮请求。本文编译 2026 年 10 月的一组实测：一次真实审计里，15 个 MCP 服务器 + 901 个技能让 Agent 在发第一条消息前就烧掉 92,413 token（@princejain756，10-12）；而另一个 20,000 token 的场景里，系统提示词开头约 30 个 token 的波动头让缓存命中率从 0% 变成 86%，成本降了 96%（@chenyu-ai，10-04）；最反直觉的是"压缩工具输出"：实测只值 约 2%，因为缓存命中价已经便宜了约 120 倍（@projectescape，10-08）。再加上上下文预算的六个泄漏点（@karthidec，10-07）、token 级路由的系统开销（@reidmarlow，10-09）与企业预算构成（Quokka Labs，10-15），合起来是一份可执行的成本体检清单。

披露：部分来源作者/所在机构有产品立场（Torana 插件、ctxvitals、xenition、Quokka Labs 服务）或为单厂商实测，数字按"方法与口径"引用，文中逐一标注。

一、先看两个数字：92,413 与 30

92,413：发第一条消息之前，账单已经开始

r/mcp 上有一条流传很广的帖子："跑 15 个以上 MCP 服务器，能在 Agent 读到你的消息前烧掉 60,000 token。" 评论区大家都在打补丁——懒加载、自己写一个 get-tool-help、手动 grep /context 的输出——但没有人做诊断工具。

@princejain756 做了 ctxvitals：它启动你配置里的每个 stdio MCP 服务器，发真实的 initialize + tools/list，数每个服务器实际注入进上下文的 schema token；对 skills、规则文件、命令、hooks 也在 Claude Code、Cursor、Windsurf、Copilot、Codex、Devin 六套配置里做同样的统计。

他自己的结果很难看：

比数字更难受的是原因：

• 同一个 MCP 服务器被配了三个不同的名字，同一份 schema 付了三次钱；
• 一个 env 块里躺着明文 API key；
• 一个服务器指向的二进制已经不存在了。

更晚一些的 per-tool 排名还发现：claude-code 的 Read 工具一个工具就占 7,487 token 的 schema。

它同时做安全检查：配置与 skill 文件里的硬编码密钥、同文件里"凭据库 + 网络调用"的外带模式、curl | sh 安装器、提示注入短语、未锁版本的 npx/uvx、以及同名重复注册但指向不同二进制（这意味着哪个进程响应你的调用取决于加载顺序，是一种供应链轮盘赌）。

一句话：你的 Agent 在说第一句话之前，就把一叠说明书从头到尾读了一遍——而且每一轮都要重读。

30：把波动头挪个位置，缓存从 0% 到 86%

另一个数字来自 @chenyu-ai 的 DeepSeek 基准：一个稳定的 20,000 token 角色扮演提示词（角色卡 + 20 条世界书 + 长期记忆 + 关系状态），外加一个约 30 token 的会话头：

Session context: local time <ISO timestamp>, turn <n>, session <uuid>, mood index <0.00>.

三份内容逐字节相同，只是这个波动头的位置不同：

排除必然 miss 的第一轮，稳态差距更刺眼：A 每轮 $0.002633，B 是 $0.000127（−95.2%），C 是 $0.000107（−95.9%）。变体 A 在 8 轮里一次缓存都没命中——整个 17,000 token 的前缀每次按全价重算，只因为开头那 30 个 token 变了。

作者还直接 diff 了两次请求的原始字节：

84,665 字节里只有 75 字节相同——这就是全部故事。按 1,000 日活 × 人均 50 轮外推：A 每月 $3,948.78，B 是 $190.78，C 是 $161.12。绝对金额取决于你的提示词大小和体量，但比例就是结论。

两个额外细节值得抄走：

1. 一行改动拿到几乎全部收益：B 和 C 只差 0.7 个百分点，你不需要重构架构，只需要把那个字符串挪走；
2. 缓存有 64 token 粒度：B 的命中 token 数恰好卡在 16,896（264 × 64），因为 system 每轮都变，system 之后的历史永远重算；C 的命中数随轮次继续爬升（第 8 轮 17,536）。

还有一个免费的坑：thinking mode 默认开启、effort 为 high，而推理 token 按输出计费。角色扮演/客服这类场景不需要内心独白——如果你的集成从未显式关闭，可能一直在为每一句话付推理费（{"thinking": {"type": "disabled"}}）。

二、把上下文当预算：三个概念先分清

@karthidec 用一个 3 AM 值班的比喻开场：一份日志里就有错误，你五分钟能找到问题；同样的日志，再加 500 份无关日志、三个月的 Slack、20 份架构文档、100 个仪表盘和五年的事故报告——信息更多了，清晰度更低了。我们对 Agent 干的正是这件事。

容量 ≠ 运行点

模型支持 200K 上下文，不代表每个请求都该塞满 200K。就像 64GB 内存的节点不会被"全部加载进内存"，而是设 requests/limits、留 headroom：

容量是能力上限，上下文预算是你的工作点。 好的工程师从不把两者混为一谈。

把预算写下来

上下文由这些部分拼成，每一块都在咬预算：系统指令、用户请求、对话历史、记忆、工具定义、检索文档、示例、工具结果。

与其问"我的模型能吃多少上下文"，不如问："这个任务应该被允许消耗多少上下文？"

一个客服 Agent 的预算可以写成一份类似 K8s 资源声明的 YAML：

# Context budget for: customer-support-agent
total: 20000
allocations:
  system_instructions: 2000
  user_request: 1000
  recent_conversation: 3000
  relevant_memory: 2000
  tool_definitions: 3000
  retrieved_documents: 5000
  tool_results: 4000

数字不是普适的；关键是你有数字。写下来之后，上下文从"API 调用里的一团黑盒"变成可以评审的对象：

• 为什么这次用了 38K，预算是 20K？
• 为什么工具定义吃了 12K？
• 为什么检索返回 15K，而答案只需要 2K？
• 为什么客户的账号 ID 在提示词里出现了三次？

价值密度：不是所有 token 都值钱

同样花 10,000 token：一篇 6,000 token 的"大概相关"文档，和一段 500 token、包含决定性业务规则的片段，后者价值高得多，而成本只有 1/12。所以作者建议一个习惯指标：

上下文价值密度 = 有用信息 / 消耗的 token

放进任何内容前问一句："它会帮 Agent 做出哪个决定？" 答不上来，它大概率不该出现在这次请求里。

还有一条独立实验结论——context rot：输入越长，模型表现（即使简单任务）越容易下降。作者给出的示意曲线是：10K → 87% 成功、20K → 93%、30K → 92%、50K → 84%。真实曲线取决于模型与任务，所以甜点是测出来的，不是模型窗口的极限。

FinOps 视角：Agent 很少只调一次模型。单任务十步，每步 30K 输入 = 300K token；每步 12K = 120K token——同样的任务少 60% 输入。而且上下文更聚焦时质量还可能上升：成本与质量同赢的改动很罕见，值得追。

三、六个泄漏点：上下文不是一次性炸掉的，是慢慢漏的

1. 工具定义：装上的 ≠ 看得见的

接 20 个 MCP 服务器、暴露 500 个工具，如果每个请求都携带全部描述，Agent 还没读你的问题就花掉了大半预算。

"已安装的能力"与"可见的能力"是两件事。 500 个工具装好，每次只让 Agent 看见当下相关的 3–10 个——用工具路由器按意图筛选，或采用按需加载的 skill registry（Google Cloud 的 Skill Registry 就是这个思路）。

2. 检索：为什么是 top 20？

大多数 RAG 流水线以 "top 20" 收尾。为什么是 20？为什么不是 5、不是 2？多数时候那是配置默认值，不是工程决定。另外 15 块不是免费的，它们稀释信号。预算感知的流水线是：

问题 → 取候选 → 排序 → 过滤 → 去重 → 压缩 → 装进检索预算（如 5K）→ LLM

问题要从"哪些文档相关"换成"完成这个任务所需的最小信息集合是什么"。

3. 对话历史：重放不是记忆

40 分钟的对话会堆得很快。每轮把全部历史重发，那不是记忆，是历史重放。更好的做法是把对话逐步转成状态：重要事实、已做的决定、未完成的任务、当前目标——不是记住每一句话，而是只留下还重要的东西。

4. 过期记忆：事实也有保鲜期

给记忆项加上类似缓存条目的元数据（source / timestamp / ttl_seconds）。否则 Agent 会基于昨天为真的事实做出逻辑完美的错误决定——模型没错，是上下文过期了。

5. 胖工具响应

提示词调了、检索调了、记忆调了，然后一个工具调用返回了 metadata、debug、internal_state 和几千行记录。工具本身没问题，它只是不是为 AI 消费者造的：人类 UI 可以选择显示什么，Agent 会把一切都吞下去。面向 Agent 的工具应当支持字段选择、过滤、排序、分页、上限和摘要——不要"这是我能找到的全部"，而是"这是你下一步需要的五件事"。

6. 为同一个事实付两次钱

"用户的项目在 us-central1" 同时出现在 system、历史、记忆、工具响应和检索文档里，就是一个事实付了五次。保持每个事实一份权威副本、其余引用——数据规范化在上下文里同样成立。

超预算了怎么办：三种策略，对应三种 K8s 结局

无论选哪种，要主动选，不要在生产事故里发现你的上下文策略。作者还给了一份约 40 行的 Python 草图：按优先级装入、精确去重、超预算时 must-keep 报错、并输出按来源的 token 分解（retrieval 31% / tool_results 24% / tools 17% / conversation 12% / system 8% / memory 8%）。能按来源看见，才有可执行的动作：检索最多就收紧 top-k 或加 reranker，工具结果最多就改响应形状。

四、真正改变账单的两件事：位置，与"压缩值不值"

4.1 先修位置：波动内容不要放在前缀里

第一节的 30 token 实验说明：前缀缓存的命中在分歧点是"全有或全无"的。把时间戳、回合数、随机 ID、心情指数放在开头，后面 99.99% 相同的字节都会变成新内容。

自查三问：

• system 消息里有没有东西每轮都变（时间戳、回合计数、用户状态、随机 ID、"当前心情"）？
• 我每轮是重建消息数组，还是追加？
• 历史有没有被重新摘要到"改变更早 token"的程度？

如果第一问答案是"有"，你有一个一行修复，它可能比本季度任何换模型的决定都值钱。注意事项：缓存是尽力而为、条目数小时到数天过期、任何对话的第一条必然 miss、峰时价格可能是谷时的 2 倍、具体数字属于该厂商，但"波动内容在开头毁掉前缀缓存"是任何前缀缓存厂商都成立的原理。

4.2 再问压缩：结果只值约 2%

@projectescape（Torana 项目）测试了看起来最显然的省钱办法：coding agent 每一轮都会重发旧工具输出，那就把旧输出换成更小的东西。

第一次尝试就翻车：把超过 2,000 字符的工具输出一律摘要化。coding agent 用精确的搜索替换来改文件，当文件读取被换成自然语言摘要，编辑就对不上；Agent 重读、再次失败、循环烧 token——"省 token"的工具反而烧了更多 token（issue #166）。

第二版设计：默认一律精确，策略按序首匹配、大小写不敏感；未匹配的工具永不改动。

• exact：永不改动。更改类工具、diff、失败命令、错误、堆栈、非零退出，即使被更宽的规则匹配到也强制精确；
• deterministic：保留有界的头尾证据，外加大小、SHA-256、省略字节数、重跑指令；first_pass 模式下从模型第一次看到输出就应用，避免事后重写前缀；
• keyword：只保留命中意图的行，且必须在至少一次精确暴露之后；
• model：用便宜模型按意图摘要，同样要经过一次精确暴露，并且只有在经济门槛预测为正收益时才做；
• source（文件读取）：配置里接受，但行为等同 exact。

改写旧消息会改变从该点往后的提示词前缀，所以 model 门控要过两道经济闸：预检（最好情况下的缩减能否赚回缓存重写成本，在付摘要费之前判断）与最终检查（按实际候选再算一次）。只有净收益为正才批量应用。

实验口径：2026-07-21，OMP 16.2.9，目标模型 DeepSeek V4 Pro，摘要模型 V4 Flash；5 个仓库任务 × 5 次重复 × 3 个实验臂 = 75 个会话，同一任务内随机排序；价格按当时 DeepSeek 表（V4 Pro 输入 $0.435/M、缓存命中 $0.003625/M、输出 $0.87/M）。总花费 $1.90（有 $15 上限保护）。

• deterministic 臂：25 次中 15 次真的变换了内容，共 399 次应用（34 次新变换 + 365 次缓存复用），移除 4,809,164 字节；配对节省中位数 $0.000524（约 2.1%），95% 区间 −$0.003714 ~ +$0.003725，25 对里 13 对更便宜；
• model 门控臂：只有 4 次运行发生变换；配对节省中位数约 1.9%，25 对里 15 对更便宜；预检一次 Flash 都没有调用——按缓存命中价算，任何前缀重写都赚不回自己的缓存 miss。

为什么没赚到：输入 token 约 92% 是缓存命中，而 V4 Pro 的缓存命中价是 miss 的 0.83%（便宜约 120 倍）。你移除的旧工具输出本来就近乎免费；而改写会让该点之后的前缀按新输入计费，直到缓存重建。盈亏平衡条件：

N > (R × max(0, W − C) + S) / (D × C)

N 是未来轮数，R 是被重写的缓存跨度，W 是写/输入费率，C 是缓存读费率，D 是每轮移除的 token，S 是摘要成本。"删除字节"只有在后续轮次的节省超过它造成的 miss 时才划算。

作者也诚实列出了边界：一个厂商、一个 harness、五个任务、五次重复、七月的价格；轨迹有波动、很多处理会话其实是 no-op；字节不等于 tokenizer 计数；排除的早期试点只作为负面安全证据保留。压缩仍然可能在缓存读很贵或没有缓存的厂商、或者 Agent 快撑爆上下文时有用——那是下一个实验。

优化顺序因此很清楚：先查上下文结构（第三章的六个泄漏点），再修缓存位置（4.1），最后才讨论压缩；而任何压缩都必须用你自己的工作负载与真实价格做配对实验（provider 上报的 token、含摘要成本）。

五、模型单价之外的三本账

5.1 路由的系统账：省钱架构自己的开销

论文算法（如 R2R）承诺：1.5B 小模型解码 95% 的 token，只把 5% 高熵分支 token 交给 32B 大模型，就能在 AIME 数学题上追平 32B 的准确率；而查询级路由要达到同等质量，得把约 40% 的整段 prompt 发给 32B。看起来 token 级路由该全面普及，但生产里几乎没人跑——因为 vLLM/SGLang 假设"一个请求属于一个模型"。

@reidmarlow 介绍的清华 + CMU 论文《TokenRouter》把时间拆开：在两个标准 SGLang 服务器之间按 token 反复横跳时，小模型服务端最后 128 个解码步里，小模型推理只占 1.56ms（4.20%）；RadixCache 更新 12.12ms（32.62%）、前缀匹配 7.78ms（20.94%）、缓存节点加锁 6.49ms（17.47%）、解锁 5.13ms（13.81%）——超过 95% 的时间花在了"为一个 5 毫秒前还在显存里的请求"重新走前缀与锁竞争。输出长度从 2,048 涨到 8,192，标准实现会丢掉 58.1%–85.2% 的吞吐，只是在重走前缀。

三个被打破的假设：步同步（0.6B 每步 6.0ms vs 32B 27.9ms，同步屏障让小模型每步空等 22ms）、连续批处理的准入延迟（路由是数据依赖的，批处理碎片化）、CUDA graph 抓不到热路径（回传触发 extend 而非 decode，没有覆盖变长 extend 批的 graph，内核启动开销吃掉收益）。

TokenRouter 的解法（请求态与批调度分离、pending 状态保留 KV/Radix 指针、覆盖 extend 的 CUDA graph、按马尔可夫链求解的延迟批处理阈值）把 R2R 在并发 8 下从 132.78 tokens/s 提到 372.48 tokens/s（官方 R2R 是 134.89，即 2.76×）；五种算法、三类负载（含 8k 上下文的 SWE-Smith Agent 轨迹）吞吐提升 2.01×–64.15×；在更紧的延迟预算下并发 16 对 R2R 并发 1，吞吐高 18.58×、单用户快 1.13×。

诚实的边界：论文自述马尔可夫模型假设切换概率近似平稳，而 coding agent 的熵是阵发的（五十个容易 token 的 JSON，接着十个难的逻辑 token）；这套东西只对自托管开源权重有意义——如果你只通过 HTTPS 调闭源前沿 API，每 token 一次网络往返会把收益全部吃掉。

要点：省 token 的架构也有自己的账单。看到"5% token 给大模型"这种标题时，先问服务系统的固定开销在哪里。

5.2 项目预算账：token 便宜了，Agent 不一定便宜

Quokka Labs 的这篇（厂商内容，区间为规划口径，注意立场）给了 2026 年的预算画像：企业级 Agent 通常需要 $50K–$300K 的规划预算，受监管、多 Agent 或深度集成的平台可超过 $300K、达到 $1M+；最大的成本驱动是集成、数据就绪、评测、安全、权限、可观测性与异常处理，不是 API token。

同期 AWS 把 AgentCore memory 改成用量计费、OpenAI 把 GPT-6 Sol/Luna 的 API 价格砍了 50%（GPT-6 Sol 现为 $2/M 输入、$10/M 输出）——模型更便宜了，但企业 Agent 没有更便宜：便宜推理不会让不可靠的工作流在经济上变便宜。

两个可直接抄的公式：

年度 Agent TCO = 构建与集成 + 模型与工具用量 + 基础设施 + 可观测性
                + 人工审核 + 安全与治理 + 维护

单次成功工作流成本 = 总运营成本 / 成功完成的工作流数

例子：每月 $12,000、尝试 20,000 个用例，95% 成功率下是 $0.63/成功工作流；如果只有 60% 无需人工返工就完成，有效经济性会迅速恶化。作者引 Gartner 对 107 个 Agent 部署的分析：可衡量的回报更可能来自专门、领域化的 Agent，而不是通用大 Agent。投资判断：工作流要有足够体量、可衡量的工时/周期成本、可访问的系统、可控的异常，以及明确的财务后果；不要只用"省了多少小时"证明，要测真实的成本下降、吞吐、收入速度、错误减少或风险降低。

5.3 热路径税：一个 console.log 的 $40,000

@infoinlet1 的故事（作者在构建 xenition，文内披露）是"成本体检"在普通代码里的版本：API 在大流量下"神秘地、昂贵地变慢"，p99 逐月爬升、扩容、云账单上涨。真凶是一行没人会看第二眼的代码：

logger.info(`Request payload: ${JSON.stringify(req.body)}`)

生产日志级别是 warn，所以这行永远被丢弃。但字符串在 logger 做判断之前就已经建好了：JSON.stringify 序列化整个请求体（有时几百 KB 嵌套数组）、模板字符串再复制一份、垃圾产生后交给 logger，logger 看一眼级别说"不要"，然后 GC 再收拾几 MB 没人看过的字符串。日志本身免费，"准备打日志"才是税——而且每个请求都付。

修复是一行：传对象而不是拼字符串（logger.info('Request payload: %o', req.body)），或显式 if (logger.isLevelEnabled('info')) 包住。结果：p99 显著下降、砍掉为吸收垃圾而加的多余实例，年化约 $40k。

这个模式比日志更宽：被丢弃的急切序列化、先计算再检查守卫、调试遗留物。作者还有一句对 AI 时代的提醒：Agent 极其擅长生成这种"正确但浪费"的代码——干净自信的 diff 掩盖一次无意义的分配，和掩盖一个逻辑 bug 一样容易。

六、一份 Agent 成本体检清单

请求之前 - [ ] 这个任务实际需要什么？哪些内容是无条件自动加载的？ - [ ] 什么在重复？什么在过期？（同一事实是否在 system/历史/记忆/检索里各付一次） - [ ] 每个任务用同样的预算吗？该用吗？

工具与技能 - [ ] 每轮模型看得见多少个工具 schema？能否按需发现？ - [ ] 每个工具响应里有没有 Agent 永远不用的字段？ - [ ] 同一服务器是否被重复注册（不同名字/不同二进制）？skill 描述是否全量常驻？

缓存与位置 - [ ] system 消息里有没有每轮变化的内容？消息数组是重建还是追加？ - [ ] 有没有读取 provider 的缓存命中字段（而不是只看总 token）？ - [ ] 不需要推理的任务是否显式关闭了 thinking？

检索与记忆 - [ ] top-k 是谁定的？有没有排序、过滤、去重、压缩？ - [ ] 是否在测量"检索回来的内容真的被用了吗"？ - [ ] 哪些事实有 TTL？Agent 应该忘记什么？

观测与预算 - [ ] 是否按来源统计 token（不只是总数）？上下文利用率是多少？ - [ ] 有没有一条评测曲线告诉你"上下文加到多少就不再有用"？ - [ ] 是否在算单次成功工作流成本，而不是只盯模型单价？ - [ ] 超预算时的策略是什么：截断、拒绝还是压缩？（必须主动选）

任何优化之前 - [ ] 先用配对实验、provider 上报的 token、真实价格测一遍——"看起来该省"和"实际省了"常常隔着一次缓存失效。

相关阅读

• 子代理交接：compaction、subagent 与 fold 的上下文折叠
• Agent 审计日志：证人即嫌疑人，怎么让谎言留下痕迹
• Agent 说"做完了"，证据呢：三道交付验证门
• 专题：Agent / MCP / 自动化完全指南
• 专题：本地 & 自托管 LLM 完全指南
• 专题：AI 基建 / 评测 / 安全完全指南

本系列另两篇（三站相关系列 · 成本体检）

• CAD 工作站别为 64 核买单：配置实测与 AI 3D 账单（同样的"先体检再花钱"落到 3D/CAD：参数化建模是单线程的、20–35 倍内存规则、一次 Blender AI 建模会话 $22.13）
• 交易的真实成本：四笔费用、Gas 假设与到手的价格（落到链上：入金/交易/换算/提现四段费用、EIP-1559 实时估算、DEX/CEX 报价差异与 6 位 vs 18 位精度损耗）

来源

• @karthidec, Your AI Agent Has a Context Budget: Treat It Like a CPU Budget（dev.to，2026-10-07；含 context rot 与 Chroma 研究引用）：https://dev.to/karthidec/your-ai-agent-has-a-context-budget-treat-it-like-a-cpu-budget-hif
• @chenyu-ai, Your system prompt is silently killing your prompt cache（dev.to，2026-10-04；DeepSeek deepseek-flash 8 轮基准，原始数据 github.com/chenyu520-ai/rp-cache-lab）：https://dev.to/chenyu-ai/your-system-prompt-is-silently-killing-your-prompt-cache-28oa
• @projectescape（Torana）, Does compacting tool output lower a coding agent's API bill?（dev.to，2026-10-08；75 会话配对实验，作者为 Torana 插件作者，文内已披露产品立场）：https://dev.to/projectescape/does-compacting-tool-output-lower-a-coding-agents-api-bill-ena
• @princejain756, I audited my AI agent stack: 92,413 tokens burned before the first message（dev.to，2026-10-12；工具 ctxvitals 为作者自建）：https://dev.to/princejain756/i-audited-my-ai-agent-stack-92413-tokens-burned-before-the-first-message-52hc
• @reidmarlow, Why Token-Level LLM Routers Spend 95% of Their Time on Cache Bookkeeping（dev.to，2026-10-09；论文 TokenRouter，arXiv 2610.12242，清华 + CMU）：https://dev.to/reidmarlow/why-token-level-llm-routers-spend-95-of-their-time-on-cache-bookkeeping-5959
• @dhruvjoshi9（Quokka Labs）, How Much Does It Cost to Build an Enterprise AI Agent in 2026?（dev.to，2026-10-15；厂商内容，预算区间为规划口径、附带自家服务链接，数据请按此折价阅读）：https://dev.to/quokkalabs/how-much-does-it-cost-to-build-an-enterprise-ai-agent-in-2026-3c5o
• @infoinlet1, A single console.log was costing us $40,000 a year. I found it by accident.（dev.to，2026-10-12；作者在构建 xenition，文内披露）：https://dev.to/infoinlet1/a-single-consolelog-was-costing-us-40000-a-year-i-found-it-by-accident-4cop

本文由 汇智网 · Software 2.0 编译整理，转载请注明出处。

这是「AI 基建 / 评测 / 安全」专题的一部分。完整地图见：AI 基建 / 评测 / 安全完全指南