历史工单里出现过类似问题，Agent 很容易沿用当时的处理结论。但相似表述不代表条件相同，过去成功的做法也可能已经不符合当前规则。案例检索应提供可参考的过程与差异，不能把旧结论直接变成当前授权。

本文以售后问题归类为示意，不引用真实客户资料或处理记录。

案例索引保留结果之外的条件

除问题摘要外，记录产品、版本、适用规则、关键事实、采取的动作、最终结果及结果来源。只保存“问题描述加解决方案”，会丢掉方案为什么适用。

{
  "case_id": "case-8",
  "product": "demo-product",
  "problem_type": "attachment_unreadable",
  "rule_version": "demo-v2",
  "action": "request_supported_format",
  "outcome": "resolved",
  "outcome_ref": "verified-event-9"
}

数据为构造示例。案例结果来自权威事件或人工核验，而不是仅凭“任务执行成功”自动标记解决。未解决案例与失败案例也有参考价值，应保留真实结果。

先过滤范围，再比较语义

按租户权限、产品和必要业务范围筛选后，再进行关键词或语义检索。跨租户案例只有在明确允许且完成必要脱敏时才能共享，不能为了召回更多结果放宽访问边界。

相似度只用于候选排序。给 Agent 的结果还应列出当前工单与案例的条件差异，例如旧案例使用较早规则、附件类型不同或用户权限不同。

图中平铺布样的共同纹理被对齐，差异区域保留透明遮罩。相似部分帮助找到参考，差异部分决定哪些处理步骤不能照搬。

把参考与当前判定分开

案例可帮助提出检查清单、检索方向和处理草稿。当前工单能否执行某动作，仍由当前事实、现行适用规则与权限决定。引用案例时标明“历史参考”，不要把它写成制度来源。

def comparison(current, case):
    keys = ("product", "attachment_type", "rule_version")
    return {k: {"current": current.get(k), "case": case.get(k)}
            for k in keys if current.get(k) != case.get(k)}

示例只是输出差异，不计算案例是否可直接复用。业务还需要检查字段缺失、版本适用时点和重要例外；未知值不能被当作一致。

更新与撤销案例

历史处理后来被证明错误时，案例需要标记撤销或补充更正。检索结果读取主记录的当前有效状态，不能因为向量索引尚未删除，就继续把错误案例当作成功范本。

缓存键包含权限范围与案例版本。案例摘要重新生成时，保留来源引用与修订版本，避免压缩过程把“暂时缓解”改写成“彻底解决”。

匿名化也不等于完全没有隐私风险。罕见故障、时间与组织信息可能重新识别客户，因此共享材料应最小化，必要时改用经过审核的合成案例。

评测检索有没有帮倒忙

准备描述相似但条件不同、描述不同但根因相同、旧规则案例、撤销案例与无权限案例。检查正确候选是否出现、差异是否完整、Agent 是否仍向当前规则查证。

还要测试没有合适案例时的行为。系统应返回证据不足，而不是强行选最相近的一条作为答案。历史案例检索提供经验线索，当前决策的证据链仍需要重新建立。