你的 agent 流量究竟有多少是重复的？先测量，再缓存

最近折腾智能体（agent）缓存，踩了几个坑，这篇把问题说清楚。轨迹缓存（trajectory caching）只有在一批智能体持续解决相似问题时才划算。所以在上缓存方案之前——无论是我们的还是别家的——先测清楚流量是否真的存在重复。下面这份检查清单，是我会让工程师最先跑一遍的流程，也包括那些诚实的答案是“别折腾”的场景。

先从最不适合缓存的情况开始

如果每个任务都独一无二，Pomerene 基本省不下什么。比如智能体只处理一次性的 Bug 修复，每张工单都是一次全新的排查；或者为不同客户做定制化工作，需求从不以可识别的方式重复出现。这类流量根本没有稳定内容可以重放。

给这种流量加缓存，就像建了一张永远命不中的查找表：你增加了基础设施、存储开销，还给每次请求加了一层匹配，却换来接近于零的命中率。与其推销一套帮不上忙的工具，不如直接把话说明白。

轨迹缓存真正划算的工作负载，恰好相反：处理相似意图的客服智能体、预订流程、常见问题（FAQ）智能体、定时任务——只要目标会重复出现，哪怕每次措辞不一样，也有缓存价值。

需要测量什么

想得到第一版结论，不一定需要新工具。现有的链路追踪（trace）和日志就足够算出四个数字。

1. 目标重复率。按照已完成运行试图达成的目标进行归类，而不是按照提示词原文分类，重点看意图。本周有多少比例的运行，其目标在上周也出现过？这个比例就是缓存命中率的理论上限。如果重复率不到大约五分之一，经济性很快就会变得勉强。

2. 改写聚类。直接按字符串去重会骗你。“我的退款到哪了？”和“麻烦告诉我你们欠我的钱什么时候处理”表达的是同一个目标，但两个句子的词完全没有交集。可以按照嵌入向量（embedding）的相似度对请求进行聚类，再观察各个簇的规模：如果大量请求都是孤立单例，说明工作内容高度独特；如果少数几个大簇占据了大部分流量，就说明少量目标主导了整体流量，这正是轨迹缓存最擅长利用的流量结构。

3. 单次运行成本。统计一次运行中所有步骤消耗的令牌（token）总数，不要只算最后一次模型调用。智能体真正的成本往往藏在中间的工具调用和推理步骤里。乘上前面测出的重复率，就能在动手开发之前得到节省成本的理论上限，单位是美元。

4. 延迟分布。记录端到端运行延迟，包括 p50 和 p95。耗时较长的多步骤运行最能从重放中受益：完整重放会跳过整个步骤序列，所以运行越长、重复度越高，每次命中带来的延迟收益就越大。

Pomerene 跑起来后会报告什么

如果最终部署了 Pomerene，它会提供诊断视图，方便你验证缓存的实际表现是否符合前面粗略计算出来的预期：

• 按租户及全局统计的命中率——确认你从追踪数据中测出的重复率是否真的转化成了命中，同时观察不同租户的流量是否存在明显差异。
• L1 / L2 / 未命中拆分——完整重放、部分重放（智能体从缓存计划不再匹配的那个步骤继续执行）以及完全未命中。健康的部署不应全部是 L1；如果 L2 占有一定比例，说明即使目标只部分重合，缓存仍在吸收工作流中的公共前缀。
• 命中路径与实时运行路径的延迟百分位数。
• 节省的美元和令牌数，并且按照真实重放方式核算：L1 命中计入全部轨迹令牌，因为整个运行都被跳过了；L2 命中只计入实际重放的部分。智能体仍然执行过的步骤不会被重复计算。

质量需要持续监控，不能想当然。/v1/feedback 回路可以把运行结果反馈给缓存：重放质量下降的条目会被淘汰，而不是因为曾经有一次表现良好，就一直被提供出去。

需要正视的限制

在围绕缓存设计系统之前，有两个约束必须提前知道。

Pomerene 当前采用单写入者实例和内存向量索引。它的实现简单又快，但它是由一个进程独占缓存，而不是一个分布式存储。

另外，由于保存的轨迹会按照嵌入向量建立索引，更换嵌入模型会导致已保存的向量失效：模型替换后，索引必须重新构建，不能原地迁移。这两点都不是藏在细则里的小问题，而是应该纳入当前部署适配性评估的因素。

决策规则

先测量目标重复率和改写聚类结果。如果至少三分之一的流量，其目标此前已经解决过，那么轨迹缓存大概率能在令牌成本和延迟上收回投入，而且一周之内就能通过诊断数据给出证明。

如果流量确实都是一次性、独一无二的工作，那就跳过缓存，把精力放到其他地方。无论选择哪条路，决策依据都应该来自你自己的数据，而不是厂商提供的基准测试。

Pomerene 的自托管 Starter Kit 提供上述诊断视图，包含 Indie $99 / Pro $249 两个版本，均为一次性付费并附带源码，因此采用之后仍然可以持续验证效果。访问 pomerene.io/starter-kit 了解更多。