Apple 声明式软件更新 macOS 27 Golden Gate：旧 MDM 迁移清单

症状：控制台显示更新命令已发送，但 macOS 27 节点没有按计划更新。
最快解法：不要等正式版发布后再迁移，立即把旧 MDM 更新命令、查询、推荐节奏和传统延迟策略改为 Apple 声明式软件更新，并先在非关键节点验收状态回报、强制安装、授权重启和 CI 重新接单。

最后更新于 2026 年 8 月 9 日，数据核实自 Apple 的 WWDC26 设备管理更新说明、Apple 声明式软件更新文档 与 macOS 27 Beta 发布说明。

这篇文章适合仍通过旧 MDM 命令推送、查询或延迟 macOS 更新的 IT 管理员。维护远程 Mac、无人值守构建节点和 CI Runner 的平台工程师，也需要提前验证授权、重启与任务恢复链路。管理 macOS 26、macOS 27 混合集群的运维负责人，则应先建立双轨策略，而不是一次性切换。

旧命令控制面与新声明的差异

典型故障不是“更新包下载失败”，而是控制面已经失效：MDM 控制台记录了 ScheduleOSUpdate 或相关查询动作，平台也显示命令已发送，但升级后的 macOS 27 节点没有按原计划执行。Apple 已在 WWDC26 设备管理更新中说明，macOS 27.0 的受影响系统不再完整支持旧软件更新命令、软件更新查询、推荐更新节奏，以及传统软件更新限制和延迟机制。官方同时要求管理团队改用声明式软件更新管理。(support.apple.com)

这意味着你不能再把“命令入队”当作成功证据。需要确认的是：

• 声明是否已经激活；
• 目标版本和构建号是否适用于该设备；
• 设备是否进入下载、准备、安装或失败状态；
• 重启后设备是否重新注册并持续回报；
• CI Agent 是否恢复接单，而不只是系统版本发生变化。

Apple 的声明式方案把“设备达到目标状态”的责任更多交给设备本身。管理服务发布期望状态，设备处理配置并发送状态变化；官方文档列出了 waiting、downloading、prepared、installing、failed 等安装状态。(developer.apple.com)

注意： 截至 2026 年 8 月 9 日，macOS 27 相关管理能力仍属于预发布内容。Apple 明确提示 WWDC26 页面中的功能可能在正式版前调整，因此不要把 Beta 4 的表现当成最终版承诺。

旧 MDM 流程的盘点范围

先不要从“怎样推送 macOS 27”开始。第一步是找出哪些自动化仍把旧机制当成事实来源。建议按下面 4 类对象盘点：

1. 命令发送器：检查 MDM 服务、脚本和队列系统是否仍发送旧软件更新命令，或在命令成功入队后直接把节点标记为“已升级”。
2. 版本查询器：检查是否依赖旧的可用更新查询、AvailableOSUpdates 返回值，或通过一次查询结果决定整个集群的放量。
3. 配置描述文件：查找旧的软件更新限制、推荐节奏、传统延迟键，以及多个团队重复下发的同类描述文件。
4. 状态判断器：确认监控是否只读取当前系统版本，没有订阅安装状态、失败原因、待安装版本和安装触发来源。

如果 macOS 27 节点没有执行旧更新动作，应该先查什么？
先区分“命令没有送达”和“命令已送达但系统不再按旧机制执行”。Apple 的更新说明把软件更新命令、查询、推荐节奏和相关限制列入移除范围；因此，控制台显示“发送成功”不能证明系统仍会执行该动作。

Apple Software Lookup Service 返回公开可用版本、设备管理可推送版本、产品版本、构建号、发布日期、过期时间和支持设备列表。它适合用于发布前的目标版本适用性计算，但不能代替设备端的安装状态回报。(developer.apple.com)

声明式配置与延迟策略的迁移

声明式软件更新至少涉及两类配置。SoftwareUpdateSettings 用于自动更新行为、通知和延迟设置；SoftwareUpdateEnforcementSpecific 用于指定某个系统版本或构建号，并设置目标安装时间。Apple 文档还说明，多份设置会合并为设备的有效配置，重复配置同一个键时，具体结果取决于该键的合并规则。

旧的 MDM 延迟设置还能不能作为 macOS 27 的主要控制手段？
不能再把旧配置描述文件里的延迟键当成 macOS 27 的唯一控制依据。迁移后可以继续保留“暂缓提供版本”的组织审批逻辑，但应把它落到声明式 Deferrals、自动更新行为和指定版本强制安装时间上。Apple 现有文档显示，声明式延迟仍可按天配置，范围为 1 至 90 天；但独立的强制更新声明仍可要求设备在目标时间前完成更新。(developer.apple.com)

声明式强制安装不是“设了时间就一定成功”。设备仍需要判断更新是否适用，并经历下载、准备、安装和重启过程。多份强制声明同时存在时，Apple 文档说明，设备会优先处理目标日期更早的配置；升级后会重新处理剩余配置，并忽略不高于当前版本的旧目标。(developer.apple.com)

配置目标系统时，如何同时锁定版本、构建号和安装时间？
先从 Apple Software Lookup Service 获取适用于设备型号的产品版本和构建号，再把目标版本写入强制安装声明，并设置目标本地时间。不要只写“最新版本”，也不要只比较 ProductVersion；对 CI 节点，应同时保存构建号、声明标识符、目标时间和生效范围，方便判断到底是哪一条声明触发了安装。

macOS 26 与 macOS 27 的双轨集群

混合环境最容易出现两个错误。第一，把 macOS 26 和 macOS 27 放在同一策略组，用旧流程判断所有节点。第二，先按版本号筛选，再忽略设备管理能力、监督状态和目标构建号，导致 26 节点提前进入 27.0 放量。

混合系统集群应如何划分更新策略？
按“系统版本 + 管理能力 + 业务角色”建立策略组。macOS 26 节点暂时保留旧流程，但要同步准备声明式迁移；macOS 27 节点直接进入声明式路径。每次发布前，用设备的系统版本、构建号、硬件型号和管理登记状态计算适用性，再决定它能否收到目标声明。

推荐使用下面的分组：

• 26-legacy：仍运行 macOS 26，旧命令可用，但只允许小批量测试。
• 26-ready：运行 macOS 26，已完成声明激活和状态回报验证。
• 27-pilot：运行 macOS 27 Beta 或候选版本，只放非关键 Runner。
• 27-production：声明式更新已验收，允许进入正式发布窗口。
• hold-retire：无法满足授权、回连或构建链要求，暂缓或退役。

双轨阶段的退出条件不能写成“所有节点版本相同”。至少应满足：27.0 节点已完成声明激活和安装状态验收；macOS 26 节点都有明确的升级、替换或退役计划；旧命令不再参与 macOS 27 的成功判定；监控已经能区分“未收到声明”和“声明已收到但安装失败”。

无人值守 Apple silicon 节点

无人值守 Apple silicon Mac 的关键不是“能否远程执行重启”，而是设备是否具备非交互式更新所需的授权链。你需要核对监督状态、登记方式、Bootstrap Token 托管情况、卷所有权和启动安全策略。Apple 说明，自动非交互式更新需要 MDM Bootstrap Token；Apple silicon 的更新还涉及安装所有权和启动安全策略。(developer.apple.com)

无人值守节点进行强制更新前，需要完成哪些授权检查？
按以下顺序验收：

1. 确认设备通过设备登记或自动设备登记加入管理，并处于监督状态。
2. 确认 MDM 服务已声明支持 Bootstrap Token，并能读取设备托管状态。
3. 确认卷所有权和启动安全策略允许目标版本启动。
4. 用 Apple Software Lookup Service 验证型号支持目标版本和构建号。
5. 下发声明式设置与指定版本强制安装声明。
6. 订阅安装状态、失败原因、待安装版本和当前系统构建号。
7. 等待设备完成重启，再验证 MDM 回连、远程连接和 CI Agent 状态。
8. 未通过重启回连或授权验收的节点，不得进入生产放量。

Apple 的状态报告文档列出了 StatusDeviceOperatingSystemBuildVersion、StatusSoftwareUpdatePendingVersion、StatusSoftwareUpdateInstallState 和 StatusSoftwareUpdateFailureReason 等可订阅项目。状态报告默认还可用于持续观察，而不是只在发送命令后读取一次结果。(developer.apple.com)

经验： 对无人值守节点，系统版本变化只是中间事件。真正的成功条件是“重启后仍能远程登录、管理状态持续回报、构建任务可以重新接单”。任何一个条件缺失，都应回退到人工维护或平行节点接管。

CI Runner 的试升与放量出口

CI Runner 不适合直接套用办公 Mac 的升级窗口。升级前先排空任务，锁定当前构建链版本，再在非关键 Runner 上创建目标声明。试升过程中要记录声明激活时间、开始下载时间、进入准备状态时间、重启回连时间和重新接单时间；如果没有本站实测数据，不要自行填写耗时或成功率。

建议把试升分成 5 步：

1. 任务排空：禁止新任务调度，等待正在运行的构建完成或转移。
2. 声明验证：确认设备收到目标版本声明，且状态报告中的目标构建号正确。
3. 系统安装：观察 waiting、downloading、prepared、installing 和 failed 状态。
4. 远程恢复：验证 MDM 回连、SSH 或远程控制链路、磁盘解锁和登录服务。
5. CI 复上线：确认 Agent 版本、证书、密钥、缓存目录和构建工具链恢复，随后提交一条真实的最小构建任务。

最终出口只有 3 个：

• 继续分批升级：声明、授权、回连和 CI 接单全部通过。
• 暂缓升级：系统能更新，但构建链或远程恢复仍有不确定性。
• 启用平行 Mac 节点：生产节点无法安全试升，或没有足够维护窗口。

迁移后的运营判断

你可以把旧流程与新流程的判断方式写成一条简单规则：

• 只看到“命令已发送”——不算成功；
• 只看到系统版本改变——不算生产可用；
• 看到声明激活、目标构建号匹配、安装状态完成、重启回连和 CI 重新接单——才算一次可放量升级。

如果当前环境仍依赖旧 MDM 更新命令，继续拖到 macOS 27 正式版后再改，会把迁移、试升和生产升级压缩到同一个维护窗口。传统流程还存在 3 个真实缺点：无法解释命令为何没有产生设备动作；延迟策略和推荐节奏可能给出错误控制感；CI 节点重启后即使系统上线，也可能没有重新接单。声明式方案并不会替你解决所有兼容性问题，但它至少把目标状态、安装阶段和失败原因变成可持续观察的管理对象。

当关键节点无法安全试升，或者你的团队没有足够的备用 Runner 时，准备一组平行远程 Mac 往往比在生产节点上反复重发命令更稳妥。MacHTML 的远程 Mac 使用帮助可作为接入和维护窗口的参考；如果你需要临时准备测试节点、平行构建环境或升级期间的替代算力，也可以查看 MacHTML 的远程 Mac 方案，按节点数量、无人值守程度和维护窗口决定是继续本地迁移，还是先租用一组独立 Mac 完成试升与接管。

延伸阅读: macOS 27 新功能与升级指南 macOS 27 应用兼容性测试清单 Mac CI/CD 性能与升级验收实践