链路可观测
每个请求要能带上 trace 标识，串起网关、缓存、检索与模型调用。为什么是前提：没有链路就无法判断命中来自哪一层、延迟花在哪一段。怎么做：在入口生成标识并透传到所有下游；边界是日志量会上升，需要采样与保留策略配合。
模型清单与能力档案
路由依赖对各模型能力边界的了解，需要一份持续更新的档案。怎么做：用统一评测集定期测各模型在业务样本上的表现，记录版本与日期；边界是模型版本会变，档案过期比没有档案更危险，要标注有效期与复评时间。
业务分流规则
哪些请求可以缓存、哪些必须直连，需要业务方确认而不是技术单方决定。为什么：合规与体验的判断在业务侧。做法：把规则写成表，注明依据与审批人；边界是规则变更要走审批，避免为降成本偷偷放宽口径。
成本可归因
缓存、网关与模型调用要能按业务线拆开，否则无法判断投入是否值得。怎么做：在网关上打业务标签，账单按标签聚合；边界是共享资源的分摊口径要提前约定，否则月底对账会变成争论，最后谁也不认账。
维护责任人
阈值、失效标签与规则都需要人维护，还要有人看指标。为什么常缺失：项目上线后团队转场。做法：把维护写入岗位职责并约定复盘节奏；边界是无人维护时应主动下线缓存，而不是让它带着错误继续运行。
适用与不适用
适合谁
- 准备上线语义缓存、想先补齐前提条件的团队
- 已上线但效果不稳定、需要复盘条件的业务线
- 要为优化项目做资源与人力申报的负责人
不适合谁
- 调用量极小、缓存收益本就不明显的业务
- 没有可观测基础设施、也不打算补的早期项目
典型场景
某物流企业的智能客服上线缓存半年后命中率下滑、错答增多。复盘发现模型已换过两版、知识库改过结构，但缓存标签与阈值从未更新，也没有人负责看指标。团队补建了 trace 链路与模型档案，指定运营每周看一次看板，并把维护写进岗位职责后才恢复。
可执行步骤
- 在入口生成 trace 标识并透传到网关、缓存、检索与模型等全部下游
- 用统一评测集建立模型能力档案，标注评测日期、有效期、复评人与结论
- 与业务确认可缓存、不可缓存的规则表，逐条注明依据、审批人姓名与日期
- 在网关按业务打标签，账单按标签聚合，分摊口径要提前约定并签字确认
- 指定维护责任人与复盘节奏，并写入岗位职责说明、交接清单等文件之中
常见坑
- 没有端到端的链路标识，命中与延迟都说不清，优化只能靠猜，换人之后连历史结论也无法复核。
- 模型换了版本但能力档案未更新，路由仍按旧能力分配，错配率上升，业务方只感到质量变差却查不到原因。
- 分流规则由技术单方制定，业务方并不知情，出了问题后各部门互相推责，规则也没人敢动分毫。
- 上线后团队转场、长期无人维护，缓存内容逐渐失真，最终被整体关掉，前期优化投入全部沉没。
自检与验收清单
- 请求是否带 trace 标识，能否串起完整的调用链路
- 模型能力档案是否有版本、评测日期与明确的有效期
- 缓存与直连的分流规则是否经业务方审批并留档
- 调用与固定成本是否可以按业务线拆开并归因
- 维护责任人是否已明确到岗并写入岗位职责说明
常见问题
小团队也需要这些条件吗？
需要，但可以简化。链路标识与规则表是底线，成本归因可以先按一个业务粗算，维护人可以由现有开发兼任。省掉 trace 与规则记录，后面出问题时几乎无法定位，返工的代价更大。
规则表要写到多细？
至少写到请求类型与数据字段两级，注明可缓存、需脱敏、必须直连三种处理方式，以及每条的审批人。太粗等于没有约束，太细维护成本高，建议先覆盖高频场景，再按问题补充。
日常维护要做哪些事？
看指标、调阈值、处理失效任务、复审规则与处理告警。频率可以按业务量定，但要有固定节奏与记录。无人维护时宁可先下线缓存，也不要让它带着过期答案继续对外服务。