CI里检查过一个镜像，部署时却在另一种CPU上启动。相同标签并不代表执行了相同的二进制组合；多平台镜像还可能通过镜像索引为不同平台选择不同内容。

worker镜像验收应回答两件事：准备部署的内容是哪一份，以及检查真正在哪个平台执行。只保存一个“测试通过”的绿色标记，无法把结果追溯到最终部署对象。

标签是入口，摘要用于绑定内容

流水线可以用标签定位候选，但验收记录应保留内容摘要，以及它指向镜像索引还是单个平台manifest。多平台构建时，还要能查到目标平台对应的manifest摘要，不把索引摘要与其中一个子manifest混为一谈。

同一索引支持哪些操作系统与架构，属于产物信息。运行检查实际覆盖哪个平台，属于验证信息。构建产物有linux/amd64和linux/arm64两个变体，不等于两个变体都已经经过同等运行验证。

给有限验证一个明确类型

可以分开记录静态检查、启动自检、合成音频处理和部署环境验收。静态检查配置不启动进程；启动自检确认入口、依赖与必要初始化；合成处理再检查输入到输出契约。部署环境仍可能有不同的文件挂载、设备和资源限制。

把其中任何一项写成all tests passed，都会让后续阅读者猜测覆盖范围。尤其是GPU后端，CPU环境能启动不能替代目标设备初始化与实际推理。

下面示例仅验证一条受控验收记录能否用于当前目标。image_digest表示平台manifest摘要，platform使用团队统一的规范化字符串。摘要存在不等于已访问仓库核实，这个函数只处理已有可信记录。

import re

def require_worker_check(record, target_digest, target_platform):
    if not re.fullmatch(r"sha256:[0-9a-f]{64}", target_digest):
        raise ValueError("目标摘要格式无效")
    if record["image_digest"] != target_digest:
        raise ValueError("检查内容与部署内容不一致")
    if record["platform"] != target_platform:
        raise ValueError("检查平台不匹配")
    if record["check_kind"] != "startup_self_check":
        raise ValueError("缺少要求的启动自检")
    if record["result"] != "passed":
        raise ValueError("自检未通过")
    return True

真实协议还应记录检查时间、执行环境、工具版本、证据位置和完整性校验，必要时结合可信流水线身份或签名。不能让用户随意上传一份JSON就当作供应链证明。这里也没有实现多平台索引解析、仓库鉴权或摘要拉取。

自检命令不要顺手消费真实任务

worker提供独立的self-check入口时，应在入口分派阶段就隔离业务模式。自检检查必要依赖和配置后退出，不能因为复用主循环而连接生产队列、领取一条任务，再以它是否完成作为镜像健康依据。

需要处理夹具时，使用独立、确定性生成的小输入与可丢弃输出，设置超时和资源预算。测试凭据与业务凭据隔离。检查日志保留版本与错误类别，不输出令牌、签名URL和用户素材路径。

镜像还需要在目标架构实际运行。跨平台模拟可以帮助执行某些检查，但应在记录中说明它是模拟环境；宿主运行、模拟运行和原生目标运行不能抹掉区别。部署门根据所需证据类型决定是否放行。

从验收到部署，不再偷偷重新打包

最终部署引用应绑定已验收产物。若验收后重新构建，即使源码提交相同，也需要重新确认生成内容；依赖解析、构建参数与基础镜像都可能影响最终产物。把构建与验证产物的关系留在记录里，比依赖“标签应该没变”明确。

本地合成记录核对同摘要同平台通过、摘要变更拒绝、平台变化拒绝、只有静态检查拒绝和失败结果拒绝。没有构建、拉取或运行Docker镜像，没有访问镜像仓库、GPU或部署集群；这些检查只验证记录匹配规则，不证明任意镜像可运行。

参考：Docker多平台构建、docker image inspect，2026-10-20核对。