如果你每天都在运行编码代理，你最终会注意到一些奇怪的事情。有些周账单看起来几乎很无聊。然后会出现一些尖锐的峰值——通常是在有人在另一台机器上重新打开旧聊天“只为了一个问题”的日子。这种模式不是神秘主义。它是提示缓存命中率。
本文是一篇实地笔记，介绍了在真实基础设施工作中运行Grok风格的编码代理：WordPress多站点、API、运营。同样的经济规律适用于任何计费输入令牌并提供缓存前缀路径的助手。
你实际上在支付什么
每个模型轮次大致有两堆令牌:
- 前缀——系统指令、工具定义、技能、项目规则，以及提供商可以视为稳定块的早期轮次。
- 后缀——你的最新消息、新鲜工具结果、新文件数据。
当提供商最近看到过相同的前缀时，该块的大部分可以被计费为缓存读取而不是全价输入。当前缀变化——或者缓存变冷——你就需要为整个提示重新付费。
因此，低成本并不是“模型是免费的”。它是缓存读取≫未缓存输入在第二轮及以后。命中率是使长期代理工作负担得起的比例。
缓存的单位是会话，而不是主题标签
人们有时会听到“同一学科”，并想象一个叫做API或WordPress的神奇桶。缓存不基于标签。它基于字节稳定的连续性:
- 相同的对话血统（恢复相同的会话),
- 相同的模型,
- 相同的作业目录和项目规则,
- 同一运行的工具和技能表面。
在实施DutchBud API更改，然后是PolitiCap API更改时，保持在一个长生命周期的会话内，你仍然受益。系统提示、工具和早期轮次仍然是一个温暖的前缀；只有新工作位于后缀中。为每个微服务开始一个全新的会话，因为“两者都是API”，每次你都会失去这种温暖。
为什么在另一台工作站上的旧会话会造成伤害
从笔记本电脑恢复一个冷的、多天的聊天通常与命中率悬崖相吻合。典型原因:
- 不同的机器和目录——另一个检出，另一个规则树，另一个会话存储。不同的前缀。
- 冷提供商缓存——即使是“相同”的历史在闲置时间后可能不再热；你重新支付来加热它。
解决方案很无聊：为每个工作流命名几个持久的会话，在实际工作的宿主上恢复这些会话，当旧会话不再是任务时使用一个新的会话。
什么保持前缀稳定
| 做 | 为什么有帮助 |
|---|---|
| 每个工作流一个长会话 | 前缀增长；后来的轮次大多是缓存读取。 |
| 按会话ID或清晰标题恢复 | 避免意外的冷僵尸。 |
| 相同的宿主和项目目录 | 规则和会话分组保持一致。 |
| 线程生命周期相同的模型 | 模型切换重置缓存命名空间。 |
| 稳定的技能/MCP/项目规则 | 周转重写前缀。 |
| 短跟进在同一线程中 | 小后缀，大缓存前缀。 |
什么破坏缓存（和预算）
- 每个小请求都创建一个新会话（尤其是没有恢复的无头默认值）。
- 线程中模型切换。
- 每小时启用或禁用MCP服务器和技能。
- 每次轮次都粘贴整个文件，而路径就够了——新颖性导致昂贵的后缀。
- 为适合一个grep的工作创建子代理——每个子进程都是自己的上下文，通常是冷前缀。
- 当你只需要一个辅助问题时随意分叉会话。
压缩不是敌人——会话切换是
长线程最终会触及上下文窗口。压缩会缩小历史，以便代理可以继续工作。这确实会改变前缀，所以缓存必须重新预热。这通常仍然比放弃任务，为另一台笔记本电脑上的一个随机旧会话，或者在没有你已经支付建立的决策的情况下重新开始要便宜。
当线程长但仍然是相同的工作时使用压缩。当主题真正新时使用新会话。不要每次轮次都压缩“以节省资金”；你只会强制重复预热。
团队的简单策略手册
- 命名会话 — 例如 fleet-wordpress, bank-api, content — 让人们恢复热的工作线。
- 固定工作场所 — 在记录树所在的树中进行基础设施编码；将笔记本电脑留给轻量级或个人线程。
- 自动化必须恢复 — 无头作业应该传递一个稳定的会话ID，而不是在每次cron滴答时打开一个冷会话。
这在实际工作中是如何体现的
在一个产品系列中——计算、钱包、市场、公民工具——一个下午通常会跨越仍然共享一个运营故事的仓库。在一个服务上实施 API 更改，然后在另一个服务上实施相关更改，正是连续会话奖励的模式：共享工具和先前的上下文保持缓存；只有新的差异和工具痕迹是新的。
相反，“我打开上个月关于广告的聊天，因为我当时已经在 TUI”是你在一个两行问题的基础上购买全价前缀的方式。
定价现实检查：Kimi K3 vs Grok 4.5 在高缓存命中率下
单价只告诉了故事的一半。对于代理编码，长时间会话的大部分是重复前缀——系统提示、工具、项目规则和先前的回合。Moonshot 的 Kimi K3 主机和 xAI 的 Grok 4.5 都以低廉的价格将这种重用作为缓存读取令牌出售。有趣的数据是，一旦你的命中率高，**有效输入价格**。
下图是截至 2026 年中期的公开列表价格（每百万令牌美元）。始终确认实时控制台文档；促销和长期上下文层级会有所变化。此处使用短上下文 Grok 4.5 价格（<200k 提示）
| 模型（托管 API） | 输入缺失 | 缓存命中/缓存输入 | 输出 | 上下文 |
|---|---|---|---|---|
| Kimi K3（Moonshot 主机） | $3.00 | $0.30 | $15.00 | ~1M |
| Grok 4.5（xAI，短上下文） | $2.00 | $0.30 | $6.00 | 500k（长期上下文层级更高） |
Moonshot 公开谈论过在编码/编程工作负载上 >90% 的缓存命中率，当前缀保持稳定时，他们的服务堆栈就是这样。这正是上面描述的长期会话纪律。在90% 的命中率下，百万令牌的混合输入成本如下：
- Kimi K3: 0.9 × $0.30 + 0.1 × $3.00 = $0.57 / 1M 输入令牌
- Grok 4.5: 0.9 × $0.30 + 0.1 × $2.00 = $0.48 / 1M 输入令牌
因此，在相同的命中率下，Grok 4.5的有效输入在这个列表中略便宜，其输出更便宜（每百万美元6美元 vs 15美元）。大量工具调用和散文流的代理会让输出成本高昂——这个差距通常比混合输入的几美分对账单的影响更大。
如果命中率崩溃（每个提示新会话，冷僵尸聊天，前缀 thrash），两个模型都会恢复到全错价格：K3在输入时为3美元，Grok为2美元，加上全输出。操作教训在任何主机上都是一样的：保护前缀，测量 cache_read，并将90%的命中率作为你工程的目标——而不是从价格表中免费获得的礼物。
K3更大的上下文窗口仍然可以赢得特定工作（巨大的单次拍摄仓库）。Grok 4.5结合较低的错输入、匹配的缓存命中率和更低的输出，这就是为什么一个运行良好的长 Grok 编码会话即使工作量大也能感觉“相对便宜”——前提是你保持在一个温暖的会话中。
总结
同一主题，更长的块，相同的活动会话是让你保持 AI 编码成本稳定的方法。这种纪律不是神秘的节俭。它是保护缓存键：会话、模型、目录和规则。把新奇放在最新消息中。保持前缀不变。
持续这样做，昂贵的尖峰会变得罕见——通常是一个冷会话、错误的主机，或者一个本应该是一个新的短线程而不是化石的一次性事件。
3DN 运行编码代理是我们构建和操作软件的一部分。上述机制是通用的；产品名称和 UI 因供应商而异，但前缀缓存经济学则不同。
发表回复