模型备用路由的数据边界验收方法

企业验收模型备用路由时，通常先观察主服务中断后能否恢复响应。对于处理内部材料的应用，还需要核对每次尝试的目的地，确认故障期间没有扩大数据的发送范围。

例如，一个限定内网处理的文档任务，主模型不可用后暂停执行，可能恰好符合预案；如果它通过未经批准的外部服务完成了任务，即使答案正确，也不应视为验收通过。

从业务要求写出可观察的预期

验收前，先确定应用负责人、数据类别、允许接入的端点，以及没有合格候选时的处置方式。不能只写“支持安全切换”，还要说明什么条件下可以发送、什么条件下必须暂停。

演练材料应使用合成内容，且能覆盖真实业务中常见的材料组合。只使用一句简短提示词，很难检验附件、历史上下文和检索结果共同进入请求时的处理情况。

把决策记录与发送记录关联起来

审计至少需要区分三个阶段：选中了哪个候选、是否实际发起发送、上游返回了什么状态。

“允许发送”不等于“已经发送”，“发送失败”也不一定代表上游没有收到。记录无法确定的情况，比把未知状态强行写成成功或失败更有利于后续调查。

可以用以下概念性记录项组织检查，实际字段应结合现有日志规范设计：

任务标识、尝试标识、应用身份、目的端点标识
切换原因、准入结果、规则版本
发送状态、上游处理状态、事件时间

默认不应为了审计而完整复制提示词、业务原文和真实密钥。优先记录必要的标识与决策依据，并规定访问权限和保存周期。涉及具体内容的排查，应使用单独获准的诊断流程。

验证时应关联路由决策与独立的出口侧记录。若某条未纳管路径缺少观测能力，仅凭路由器没有日志，不能认定它没有发送。

验证权限变更和策略异常

端点原本获准，不代表它永远获准。权限撤销、配置变化或数据要求调整后，需要检查新请求是否仍沿用旧的允许结论。

测试应明确变更生效范围和时间目标，再观察不同执行位置是否按预期更新。对于已经发送的请求，撤销后续访问权限不能使已发送的数据自动收回，两者应在记录中分开。

策略服务暂时不可用时，也应验证系统使用何种有效规则、允许维持多长时间，以及超过条件后如何处置。缺少策略不能默认解释为没有限制。

明确业务恢复与人工接手方式

当所有合格备用都不可用时，应用应向用户显示准确状态，并把待处理任务交给明确的责任人。转人工同样要遵守原有数据要求，不能通过聊天或邮件把受限材料发给未经授权的接收方。

如果业务允许先提供有限结果，需要说明哪些内容尚未处理，避免用户将不完整结果当作最终结论。恢复后是否重试，也应依据任务状态判断，防止同一任务重复执行。

一次完整的验收应留下场景、预期行为、实际行为、证据和待改进事项。发现问题后，重新验证对应场景；端点或规则发生变化时，再检查受影响的路径。

备用路由的数据边界可以通过这些具体行为来验证：允许时发往何处，拒绝时是否停止，未知时由谁判断，事后能否还原实际尝试过程。