> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # Agent 成本体检：92,413 个 token 的启动账 - URL: https://www.hubwiz.com/blog/agent-cost-audit-context-budget-prompt-cache/ - Published: 2026-10-15T23:18:30.000Z - Updated: 2026-10-15T23:18:54.000Z - Description: 15 个 MCP、901 个技能：发消息前烧 92,413 token；30 token 让缓存归零，压缩只值 2%。一份 Agent 成本体检清单。 - Author: admin - Tags: AI Agent, 成本优化, 上下文工程, 提示缓存 **一句话结论**：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 六套配置里做同样的统计。 他自己的结果很难看： | 指标 | 数值 | | -------------------- | ---------- | | 安装的 skills | **901** | | 始终加载的 skill 描述 token | **39,402** | | MCP 服务器 | 15 | | **每轮烧掉的 token** | **92,413** | | 评级 | **F** | 比数字更难受的是原因： - 同一个 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** 的会话头： ```plaintext Session context: local time , turn , session , mood index <0.00>. ``` 三份内容**逐字节相同**，只是这个波动头的位置不同： | 变体 | 波动头位置 | 典型做法 | 缓存命中率 | 8 轮成本 | | -- | ------------------------ | ------- | -------- | ----------------- | | A | system 消息**开头** | 大多数初版实现 | **0.0%** | $0.021006 | | B | system 消息**末尾** | 一行改动 | 85.8% | $0.003465（−83.5%） | | C | 最新 user 回合末尾（system 永不变） | 追加式架构 | 86.8% | $0.003326（−84.2%） | 排除必然 miss 的第一轮，稳态差距更刺眼：A 每轮 $0.002633，B 是 $0.000127（**−95.2%**），C 是 $0.000107（**−95.9%**）。变体 A 在 8 轮里**一次缓存都没命中**——整个 17,000 token 的前缀每次按全价重算，只因为开头那 30 个 token 变了。 作者还直接 diff 了两次请求的原始字节： | 变体 | 请求字节 | 相同前缀 | 占比 | | -- | ------ | ------ | -------- | | A | 84,665 | **75** | **0.1%** | | B | 84,665 | 84,493 | 99.8% | | C | 84,665 | 84,664 | 100.0% | 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： | 概念 | 回答什么 | 例子 | | ---------------------- | ------------------ | ---------- | | 上下文窗口（context window） | 模型物理上能接受多少 | 200K token | | token 预算（token budget） | 一次调用总共能消耗/生成多少 | 50K token | | 上下文预算（context budget） | 我们**有意**放在模型面前多少信息 | 20K token | **容量是能力上限，上下文预算是你的工作点。** 好的工程师从不把两者混为一谈。 ### 把预算写下来 上下文由这些部分拼成，每一块都在咬预算：系统指令、用户请求、对话历史、记忆、工具定义、检索文档、示例、工具结果。 与其问"我的模型能吃多少上下文"，不如问：**"这个任务应该被允许消耗多少上下文？"** 一个客服 Agent 的预算可以写成一份类似 K8s 资源声明的 YAML： ```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。所以作者建议一个习惯指标： ```plaintext 上下文价值密度 = 有用信息 / 消耗的 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 块不是免费的，它们稀释信号。预算感知的流水线是： ```plaintext 问题 → 取候选 → 排序 → 过滤 → 去重 → 压缩 → 装进检索预算（如 5K）→ LLM ``` 问题要从"哪些文档相关"换成**"完成这个任务所需的最小信息集合是什么"**。 ### 3\. 对话历史：重放不是记忆 40 分钟的对话会堆得很快。每轮把全部历史重发，那不是记忆，是**历史重放**。更好的做法是把对话逐步转成状态：重要事实、已做的决定、未完成的任务、当前目标——不是记住每一句话，而是只留下还重要的东西。 ### 4\. 过期记忆：事实也有保鲜期 | 事实 | 保鲜期 | | ------ | ----- | | 偏好的语言 | 数月到数年 | | 所在城市 | 数月到数年 | | 当前住的酒店 | 天 | | 当前天气 | 小时 | | 登录会话状态 | 分钟 | | 股价 | 秒 | 给记忆项加上类似缓存条目的元数据（`source` / `timestamp` / `ttl_seconds`）。否则 Agent 会基于昨天为真的事实做出逻辑完美的错误决定——**模型没错，是上下文过期了**。 ### 5\. 胖工具响应 提示词调了、检索调了、记忆调了，然后一个工具调用返回了 `metadata`、`debug`、`internal_state` 和几千行记录。工具本身没问题，它只是**不是为 AI 消费者造的**：人类 UI 可以选择显示什么，Agent 会把一切都吞下去。面向 Agent 的工具应当支持字段选择、过滤、排序、分页、上限和摘要——不要"这是我能找到的全部"，而是"这是你下一步需要的五件事"。 ### 6\. 为同一个事实付两次钱 "用户的项目在 us-central1" 同时出现在 system、历史、记忆、工具响应和检索文档里，就是一个事实付了五次。保持每个事实一份权威副本、其余引用——数据规范化在上下文里同样成立。 ### 超预算了怎么办：三种策略，对应三种 K8s 结局 | 策略 | K8s 类比 | 代价 | | --------------------- | --------- | ----------------------- | | 截断最旧的内容 | 驱逐最老的 pod | 简单，但最旧的信息常常最重要（比如最初的目标） | | 拒绝请求 | OOMKilled | 安全，但用户体验差 | | 压缩：去重、摘要、丢弃低价值、保留关键事实 | 优雅降级 | 建设成本高，但 Agent 能继续工作 | 无论选哪种，**要主动选**，不要在生产事故里发现你的上下文策略。作者还给了一份约 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 上限保护）。 | 实验臂 | 完成 | 循环中止 | 成本中位数 | 输入 token 中位数 | 请求数中位数 | 缓存命中率 | | ------------- | ----- | ---- | --------- | ------------ | ------ | ------ | | 对照（不压缩） | 23/25 | 2 | $0.024820 | 450,810 | 16 | 92.23% | | deterministic | 24/25 | 1 | $0.026699 | 479,087 | 19 | 91.68% | | model 门控 | 24/25 | 1 | $0.022465 | 444,625 | 17 | 92.75% | - 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 倍）**。你移除的旧工具输出本来就近乎免费；而改写会让该点之后的前缀按新输入计费，直到缓存重建。盈亏平衡条件： ```plaintext 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**。 | Agent 范围 | 2026 规划区间 | 典型用途 | | -------------- | ----------- | ------------------- | | 聚焦的 PoC | $20K–$50K | 验证单个工作流 | | 生产级单工作流 Agent | $50K–$125K | 客服、研究、运营 | | 跨系统企业 Agent | $125K–$300K | CRM + ERP + 数据 + 动作 | | 受监管/多 Agent 平台 | $300K–$1M+ | 大规模复杂自治 | 同期 AWS 把 AgentCore memory 改成用量计费、OpenAI 把 GPT-6 Sol/Luna 的 API 价格砍了 50%（GPT-6 Sol 现为 $2/M 输入、$10/M 输出）——**模型更便宜了，但企业 Agent 没有更便宜**：便宜推理不会让不可靠的工作流在经济上变便宜。 两个可直接抄的公式： ```plaintext 年度 Agent TCO = 构建与集成 + 模型与工具用量 + 基础设施 + 可观测性 + 人工审核 + 安全与治理 + 维护 ``` ```plaintext 单次成功工作流成本 = 总运营成本 / 成功完成的工作流数 ``` 例子：每月 $12,000、尝试 20,000 个用例，95% 成功率下是 **$0.63/成功工作流**；如果只有 60% 无需人工返工就完成，**有效经济性会迅速恶化**。作者引 Gartner 对 107 个 Agent 部署的分析：可衡量的回报更可能来自**专门、领域化的 Agent**，而不是通用大 Agent。投资判断：工作流要有足够体量、可衡量的工时/周期成本、可访问的系统、可控的异常，以及明确的财务后果；不要只用"省了多少小时"证明，要测真实的成本下降、吞吐、收入速度、错误减少或风险降低。 ### 5.3 热路径税：一个 console.log 的 $40,000 @infoinlet1 的故事（作者在构建 xenition，文内披露）是"成本体检"在普通代码里的版本：API 在大流量下"神秘地、昂贵地变慢"，p99 逐月爬升、扩容、云账单上涨。真凶是一行没人会看第二眼的代码： ```js 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 的上下文折叠](https://www.hubwiz.com/blog/subagent-fork-fold-context-handoff/) - [Agent 审计日志：证人即嫌疑人，怎么让谎言留下痕迹](https://www.hubwiz.com/blog/agent-audit-logs-witness-suspect/) - [Agent 说"做完了"，证据呢：三道交付验证门](https://www.hubwiz.com/blog/agent-delivery-verification-gates/) - [专题：Agent / MCP / 自动化完全指南](https://www.hubwiz.com/blog/agent-stack/) - [专题：本地 & 自托管 LLM 完全指南](https://www.hubwiz.com/blog/local-llm-stack/) - [专题：AI 基建 / 评测 / 安全完全指南](https://www.hubwiz.com/blog/ai-infra-stack/) ## 本系列另两篇（三站相关系列 · 成本体检） - [CAD 工作站别为 64 核买单：配置实测与 AI 3D 账单](https://bimant.com/blog/cad-workstation-budget-ai-3d-bills/?ref=hubwiz.com)（同样的"先体检再花钱"落到 3D/CAD：参数化建模是单线程的、20–35 倍内存规则、一次 Blender AI 建模会话 $22.13） - [交易的真实成本：四笔费用、Gas 假设与到手的价格](https://defiplot.com/blog/crypto-trading-all-in-cost-fees-gas/?ref=hubwiz.com)（落到链上：入金/交易/换算/提现四段费用、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 基建 / 评测 / 安全完全指南](https://www.hubwiz.com/blog/ai-infra-stack/)