值班交接：今年继续执行的会话日志与数据留存检查

本班交接重点：继续保留能定位故障的请求记录，收紧会话正文的采集范围。接入模型后，一段提示词可能经过客户端、业务服务器、中转服务和模型提供方。界面里删除了聊天，并不能证明这条链路上的副本都已清除。今年值得坚持的做法，是把每一处留存写清楚，并定期验证实际行为。

先查清一条请求会在哪里留下副本

排查时，从客户端本地历史开始，依次检查应用数据库、网关日志、监控平台和上游服务。会话记录、附件、报错堆栈、工具调用结果以及客服工单，都可能包含同一段内容。开发环境里的调试输出也要纳入清单，尤其是把完整请求和响应打印到终端的脚本。

为每个位置记录采集字段、用途、保留期限、访问人员和删除方式。供应商说明没有写明的事项，应标记为待确认。不要根据“兼容某接口”推断数据政策，也不要把某个模型的政策直接套用到整条调用链。

让故障证据够用，让正文采集有边界

常规排障通常可以先使用请求标识、时间、模型名称、响应状态、耗时和用量信息。完整正文有助于复现部分问题，但也可能带入客户资料、源代码或内部文档。启用正文采集前，应明确具体故障、采集范围和停止条件，并确认相关人员有权访问这些内容。

• 在日志写入前移除访问密钥、身份凭证和不需要保存的个人信息，并检查异常堆栈是否绕过了脱敏处理。
• 需要临时采集正文时，应限定项目和时间窗口，设置到期关闭机制，并在交班记录中注明清理责任人。
• 共享排障材料前，应重新检查内容，避免把原始会话复制到工单、群聊或长期保存的文档中。

把保留期限落实到清理任务和备份

保留多久应由用途决定。短期排障记录、费用核对数据和用户主动保存的会话，可以采用不同期限。每项期限都需要对应实际的清理任务；只有文档说明，没有执行记录，交班时仍应视为未验证。

删除流程还要覆盖搜索索引、缓存、导出文件和备份。备份可能按自身周期淘汰，未必支持立即逐条删除，因此需要明确剩余副本的处理方式，并避免恢复备份后让已删除数据重新进入业务系统。向用户说明删除结果时，也应区分在线数据已清除、备份等待到期以及需要上游处理的部分。

经过中转调用时，分别确认各方承诺

Relay365 提供按量付费的多模型中转服务，适合希望集中接入和管理调用的团队。接入便利可以减少适配工作，但留存核查仍需分别覆盖自有应用、中转服务和上游提供方。切换模型或路由时，也应重新确认适用条款，尤其是正文记录、故障调查数据和删除请求的处理范围。

如果正在评估统一接入，可以创建一个 Relay365 账户，先用合成数据验证调用和排障流程，再核对当前数据政策。涉及敏感内容的工作负载，应在留存期限、访问权限和删除路径确认后接入。

交班时留下可核验的留存状态

交接记录应写明当前启用的日志字段、临时采集是否关闭、最近一次清理结果，以及尚未得到答复的供应商问题。抽查一条测试会话，确认它出现在哪里、何时消失，比只看配置开关更有说服力。后续调整采集范围时，也要同步更新这份记录，让下一班能够接着核查。