症状： MDM 控制台显示更新策略已下发，但 Mac CI 节点的系统版本和构建状态对不上。
最快解法： 先核对 Apple 当前设备管理文档列出的移除项，再盘点你的 MDM 实现，逐步迁移到声明式软件更新管理；不要把“已下发”当成“已更新”。(Apple：已移除的设备管理命令与配置描述文件)
适合负责企业 Apple 设备策略、更新审批和合规记录的 IT 与安全负责人。
如果你维护 iOS CI 节点，还需要把构建接单、Xcode 环境和故障回退一并纳入迁移验收。
最后更新于 2026 年 9 月 29 日；核实依据为 Apple Device Management 官方文档及其当前列出的移除状态。若 Apple 后续调整支持状态或你使用的 MDM 控制台行为有变化，应重新核对并更新迁移计划。
控制台显示“已下发”，不等于设备已完成更新
判断更新是否成功，至少要分开看三个状态：MDM 服务是否同步了配置，设备是否接受并激活声明，以及操作系统是否完成下载、准备、安装和重启。只看控制台里的“命令已发送”或“配置已推送”，无法证明节点已经达到目标系统版本。
Apple 当前的移除清单将旧式 SoftwareUpdate 配置描述文件，以及“可用更新”“更新状态”“安排更新”和“安排扫描”等命令列为已移除，并分别指向声明式软件更新设置、强制更新声明或更新状态项。这个判断应以 Apple 文档里的支持状态为准；某项配置在你的 MDM 控制台里仍可选，不代表设备端仍会按旧方式处理。
旧的 SoftwareUpdate 配置描述文件还能作为更新策略使用吗？
不要预设它仍受支持。Apple 文档已将该配置描述文件列为移除项，并指向 com.apple.configuration.softwareupdate.settings；旧式状态查询和更新命令也有各自的声明式替代方式。先查清当前策略实际调用了哪些配置和命令，再以目标系统版本上的设备回报验证，而不是只检查管理后台的策略名称。
最常见的误判来自以下情况：
- 策略被接受，但更新条件不匹配。 目标系统版本或构建号如果不是当前可用版本，强制更新声明可能保持激活，却无法执行更新。(Apple：特定版本的软件更新强制声明)
- 设备已开始处理，操作尚未结束。 更新状态可能依次反映等待、下载、准备、安装或失败；这些状态不能互相替代。(Apple：软件更新强制执行阶段)
- 设备端状态没有正确回传或被后台误读。 声明式状态项只有在 MDM 服务订阅、接收并正确处理后，才能成为验收证据；只看推送回执会漏掉后续状态变化。
- CI 节点恢复了系统，但没恢复构建能力。 重启后还要核对网络、远程访问、Xcode、签名材料和 CI Agent，不能仅凭登录界面出现就宣布节点恢复。
注意：把同一旧策略反复下发，不能修复已移除的设备管理接口。先找到后台具体发送的配置类型、命令和状态查询，再决定迁移对象。
先按支持状态盘点，再决定迁移路线
迁移到声明式更新管理前，应核对哪些策略细节？
从策略载体、目标版本、设备适用条件和状态回报四处入手：旧描述文件对应什么声明、旧命令由什么机制替代、声明的 OS 版本与构建号是否可用，以及设备是否报告了安装状态与最终系统版本。还要检查多个软件更新设置声明是否对同一键产生合并或冲突。Apple 说明，多个有效的软件更新设置声明会合并应用，单个键的合并行为则取决于具体字段。(Apple：软件更新设置声明)
| 迁移选项 | 支持依据与核验重点 | 主要风险 | 适用判断 |
|---|---|---|---|
| 继续沿用旧配置与命令 | 对照 Apple 移除清单，逐项确认当前调用项是否仍受支持。 | 后台显示已配置，但设备不再按预期执行或回报。 | 仅用于盘点、短期隔离问题；不要把它当作长期迁移方案。 |
| 切换到声明式软件更新管理 | 用软件更新设置声明表达更新行为，用特定版本强制更新声明表达目标版本与安装时间；订阅设备状态。 | MDM 实现、设备资格、目标版本或回报解析不匹配。 | MDM 厂商实现已验证，且试点节点通过构建验收时采用。 |
| 暂停生产节点升级 | 保持当前生产基线，先在非生产节点验证声明与回退流程。 | 安全更新延后，需由安全负责人接受并记录风险。 | 无法确认目标版本可用、节点恢复能力不足或试点未通过时采用。 |
这张表是迁移选择工具，不是对任意 MDM 平台的兼容性评级。Apple 定义声明类型和设备侧行为；你的 MDM 服务是否正确生成声明、同步声明并解释状态，需要单独实测。声明式设备管理的核心变化，是服务端声明目标状态，再由设备处理并回报状态，并非把旧命令换个名字继续发送。(Apple：通过声明式管理部署软件更新)
盘点时，把以下资料保存在同一份变更记录中：
- 当前使用的配置描述文件、软件更新命令和状态查询，以及它们分别影响哪些设备组。
- 声明式设置与强制更新声明的目标版本、可选构建号、强制安装时间和适用范围。目标版本或构建号不匹配可用更新时，设备不能因此自动完成更新。
- MDM 控制台对声明状态、安装状态、失败原因和最终系统版本的读取结果；每项都要能对应到具体节点。
- 更新对 CI 服务的影响范围：节点离线期间任务如何排队，节点启动后由谁确认 Xcode 和 Agent 状态，何种情况禁止重新接单。
按设备状态与 CI 链路定位故障
怎样测试系统更新，同时避免生产构建被打断？
先选非生产节点，暂时移出正常任务路由；验证策略同步和设备回报后，再执行更新。只有目标系统版本、声明处理状态、远程访问和一次完整构建都通过，才扩大到下一批节点。Apple 描述的软件更新执行过程包含声明同步、设备下载与准备、强制安装以及更新后系统版本状态回报，验收应覆盖整条链路，而非止于后台出现“已发送”。
可以按以下步骤操作：
- 冻结基线：记录节点当前系统版本与构建号、Xcode 版本、签名相关配置、Agent 连接状态和最近一次成功构建。把生产节点与试点节点分开，先确认现有任务有可用的替代执行位置；没有替代位置时，不要对唯一的生产打包机直接试升级。
- 审计旧策略：导出实际使用的描述文件和更新命令，逐项匹配 Apple 移除清单。对已标为移除的项目记录替代声明和数据来源，不要因管理后台仍能显示旧策略就跳过这一项。
- 核对声明输入：在试点设备上确认软件更新设置、强制更新目标和设备适用条件；核对目标版本或构建号确实可用。Apple 的强制更新声明以目标系统版本为必填字段，安装时间也必须提供；可选构建号应与希望安装的版本相符。
- 验证设备回报：确认 MDM 服务实际收到并解析声明处理状态、
softwareupdate.install-state、失败原因和最终 OS 版本。Apple 建议订阅软件更新相关状态，并说明状态报告在订阅状态变化时发送；收到报告后仍需检查字段值，不能仅凭“收到回报”判定成功。可对照 Apple 软件更新状态项文档检查管理服务订阅的状态类型。 - 更新后逐层验机：先查设备是否完成重启、能否进入管理网络，再检查远程访问和节点可连接状态，随后核对 Xcode 与签名环境，最后确认 CI Agent 已注册并完成测试构建。每一步保留时间、日志或控制台状态证据；出现无法远程访问、系统版本不符、构建失败或签名环境缺失时，停止扩大范围。
- 逐批放量并明确回退：试点验收通过后才扩展设备组；每批完成前不叠加下一次系统变更。指定审批人、执行人和回退负责人，并写明暂停条件、重新接单条件及故障升级路径。不要把“回退”简化为降级系统：是否能恢复原 OS 版本，须按设备和组织流程事先验证；无法验证时，回退方案应以隔离节点、恢复可用构建容量和修复配置为主。
Apple Silicon Mac 强制更新有哪些前置条件？
先确认设备符合声明适用条件，并检查 MDM 是否支持、请求并托管 Bootstrap Token。Apple 文档指出，对受监督的 Apple Silicon Mac 执行强制软件更新时，MDM 服务可请求并托管 Bootstrap Token；服务还需根据设备回报的相关安全信息判断是否需要该令牌。不要把“已启用强制更新”当成授权条件已经满足。
更新状态可帮助缩小排查范围：设备显示等待或下载时，先检查声明是否生效与更新是否可用；显示准备完成后，再核对强制时间和设备在线情况；进入安装或报告失败后，保留失败原因与最终系统版本。Apple 说明，设备更新成功后会报告操作系统版本和构建版本；失败时也会返回失败状态相关信息。
用停止条件保护生产节点
遇到更新后无法接单，按故障层次检查，不要一上来重装系统或连续重启：
- 系统启动与网络：确认机器已启动、管理网络可达、DNS 与必要的更新服务访问正常。若设备无法回到受管网络，停止后续更改，保留现场日志并按组织的设备恢复流程处理。
- 远程访问：确认远程管理入口可连接且账号权限有效。若你通过 VNC 操作试点节点，可先参照本站的 VNC 连接说明核对连接条件；远程入口恢复并不等于 CI 节点已恢复。
- Xcode 与签名环境：核对所需 Xcode 是否仍可用、项目工具链与签名配置是否符合构建要求。发现版本或证书问题时，先按基线修复，不要把构建失败误判成系统更新失败。
- CI Agent 与任务路由：确认 Agent 在线、任务队列可见、节点标签和并发配置正确；完成测试构建后再重新接单。未完成验证的节点继续隔离，避免失败任务进入发布流水线。
提醒：如果 MDM 已报告更新失败，或节点重启后无法联系，不要同时修改声明、Agent 和远程访问配置。一次只改变一个故障层，才能留下可归因的证据。
团队若要先演练独立节点的远程连接与交接，可以结合 SSHMac 帮助中心梳理访问流程。远程访问可以作为排障和测试手段，但不能替代 MDM 状态回报、系统版本确认或构建验收。对声明式管理的状态订阅与设备回报机制，也可参照 Apple 的声明式管理数据模型说明。
根据证据选择迁移、暂缓或退出旧策略
决策时按以下条件执行：
- 若 Apple 文档已将当前调用项标为移除，就把它列入迁移清单；不要把后台仍能编辑误认为设备仍支持。
- 若声明可下发、设备状态能回报，且非生产节点完成构建验收，再按批次扩展；在此之前保留生产基线与停止条件。
- 若目标版本不可用、设备资格不符合、Bootstrap Token 未准备好，或 MDM 状态解析尚未验证，暂停生产升级，先解决条件缺口。Apple 文档明确指出，不匹配可用更新的目标版本或构建号不能被设备安装。
- 若节点无法远程恢复、没有可用任务承接位置，不要在唯一生产打包机上试运行迁移；先建立替代执行能力或安排维护窗口。
- 若安全要求不允许继续延后更新，由安全负责人批准风险处置与时间安排，并留下责任人和审批证据；不要用“暂缓”代替正式风险决策。
旧策略留在生产环境的代价，是难以确认它究竟还在执行，还是只剩后台配置记录；直接在唯一 CI 节点升级，则会把系统兼容性、远程访问和构建恢复风险集中到同一台机器。自购 Mac 可提供本地设备控制，但需要自行承担采购、维护与备用容量安排。若你需要先搭建短期迁移试点或临时 CI 环境，租用 SSHMac 的远程 Mac 可提供真实 Mac 节点，并通过 VNC、SSH 或网页控制台访问；这适合补充试点与临时容量，不应替代长期重负载场景下对持续容量、恢复能力和物理接口需求的评估。你可以先用文中的核对项盘点现有节点，再查看 SSHMac Mac mini 租赁方案，判断远程节点是否适合作为迁移验证或备用环境。