小结

实践从用户承诺开始，而不是从模型名称开始。工作负载契约要说明范围内的任务和总体、可接受结果、硬性约束，以及质量、延迟、可用性、成本和风险的上限。待评估的候选方案是一套带版本的在线服务系统：模型权重或托管模型版本，连同提示词、工具、检索、策略、运行时、路由和设置。工作负载究竟需要云端服务、端侧路径、修改权重，还是组合使用这些方式，应由契约决定。所有选项都必须针对同一工作负载接受评测，不能仅凭排行榜、参数量或更低的单位价格证明选择合理。

这些选择只有落实为完整的发布单元，才真正进入生产环境。带版本的服务契约把运行时和计算资源绑定到请求语义。带版本的端侧部署还要规定导出、量化、支持的硬件、运行状态和交付方式。适配发布版本把行为主张连接到受治理的数据、可复现的训练过程、评测和可逆工件。智能体发布版本用可信控制器约束模型提案、工具、持久状态、权限和外部影响。检索发布版本则发布语料库和经过授权的查询路径，并提供沿袭关系、新鲜度、删除和引用证据。仅仅因为核心组件能够运行，并不表示这些发布单元已经完整。

系统组合首先要为每项可能改变系统行为的配置与接口生成系统指纹，并为每项已发布工件赋予不可变身份。此后，每条连接都需要一份边界契约，明确含义、授权、数据类别、截止时间、重试归属、幂等性、取消、背压、证据和恢复。部署是一项受控状态转换，不是复制文件。团队要证明新旧版本可以共存，在适用时进行影子运行，先把候选版本限制在有界的金丝雀流量中，只有证据支持下一步决定时才扩大覆盖范围。目标状态、观测状态、分配状态和迁移状态必须保持分离。回滚要恢复最近一次已知正常的完整系统，而不是只改模型路由。

发布上线后，可靠性由用户可见结果定义，不是逐字节重复，也不是 HTTP 成功状态码。直接观测的事件可以支持可用性、延迟、策略、新鲜度或外部影响正确性的 SLI 和 SLO。语义质量通常还需要单独的概率样本、带版本的评分规则、经过校准的裁判或人工审查、标签截止时间和覆盖率报告。只有当审批针对将要发生的确切外部影响，并在提交时重新核验，人工监督才真正属于运行时。这个循环产生的事件只是证据，并非真值，产品事件不会自动成为标签。生产数据在成为带版本的数据产品之前，必须具备明确用途、最少必要内容、使用权限、抽样记录、数据分区和删除沿袭关系。

运营还必须把稀缺资源和故障状态写清楚。每个已接受任务的成本包括原始尝试、重试、回退、检索、工具、裁判和审查。运行时应在滞后的账单报告到达之前，完成估算、预留、准入、计量和对账。合格回退仍须满足任务的信息安全、质量、延迟和租户要求。租户隔离要分别落实到容量、缓存、索引、凭据、工具、出站访问、证据、审查和计费。身份、策略、外部影响、用量或提交状态未知时，系统必须把它保留为具名状态，不能悄悄当作成功。因此，事故处置需要负责人、时钟、遏制权限、保全证据、恢复条件和纠正措施；纠正措施必须得到验证，否则就要明确记录为已接受风险。

运营契约把上述决定汇集成一项带版本且可以执行的工件。它把每项承诺连接到对应的测量，把每项预算连接到准入控制，把每项权限连接到执行点，把每个租户边界连接到失败路径测试，也把每项事故决定连接到证据。运营契约发布记录要标明当前系统、适用范围、负责人、目标、例外、校验、发布、回滚、剩余风险和下次审查日期。这就是可靠基础设施在实践中的含义：它并非永不变化、永不故障的系统，而是即便系统已经发生变化或经历故障，仍能让承诺始终清晰可见、边界明确、可以测试且责任到人。