Agent缓存命中可能执行相反操作
文章展示了工具调用轨迹缓存的风险：“停用用户”和“启用用户”的向量相似度可达0.853，超过0.85阈值后可能复用相反操作。文本主题相似并不代表动作语义一致，单靠向量距离判定命中会把回答误差升级为执行错误。
原文暂未完整获取，基于公开信息的快读
给 Agent 缓存工具调用轨迹，不能只看两条指令有多像。dev.to 的一篇文章展示：用 text-embedding-3-small 比较「停用用户 4471」与「启用用户 4471」，余弦相似度达到 0.853，超过示例中的 0.85 命中阈值。两条指令只差一个动作，目标却完全相反。
目前能确认什么
语义缓存通过向量相似度寻找可复用内容。轨迹缓存保存的则是 Agent 的工具调用步骤及结果，匹配出错会涉及操作含义，不能只按回答是否接近来衡量。
这组例子说明：相同实体、相近句式和相同话题，可以让相反指令在向量空间里靠得很近。主题相似，不能作为动作一致的充分条件。
作者介绍的 Pomerene 要求每个工具步骤声明副作用，分类为 read、replay_safe_write 或 external_write，缺少标注就拒绝存储。只要轨迹包含写步骤，就必须精确匹配目标和上下文；仅含读取步骤的轨迹才允许模糊匹配。
还有一个关键区别：按节选描述，Pomerene 命中后返回已记录的步骤结果，不会重新调用工具。因此，不能把这里的「重放」直接理解成再次执行停用操作。
我的判断
对接用户管理、订单状态等功能的程序员，缓存审查应该先检查动作和对象，再考虑相似度阈值。单纯调高阈值，仍然没有建立操作一致性的保证。
作者选择让写请求的改写表达落入未命中路径，由 Agent 重新运行。这项取舍有明确理由：少一次缓存命中，比把相反操作的记录当作当前请求的结果更容易处理。
但节选尚未交代上下文包含哪些字段、权限与状态变化如何影响命中，以及副作用标注怎样保证准确。它也不足以证明真实请求中的错误比例。更需要核实的是：缓存返回的旧结果是否会被下游当作本次操作成功的凭据，这决定了错误会停留在回答层，还是继续影响业务流程。