Apple 聲明式軟體更新 macOS 27 Golden Gate

控制台顯示「舊更新命令已送出」，但 macOS 27 節點沒有下載、重啟或回報新版本。
最快解法：不要等正式版發布後才遷移，立即把更新流程改為 Apple 聲明式軟體更新 macOS 27 Golden Gate，先在非關鍵節點驗收狀態回報、強制安裝、授權重啟與 CI Runner 重新接單。

誰應該先處理這份遷移清單

如果你仍透過舊 MDM 命令推送、查詢或延遲 macOS 更新，這篇是給你的。
如果你管理遠端 Mac、無人值守構建節點、CI Runner 或 macOS 26/27 混合集群，也應在正式版前完成試升。

最後更新於 2026 年 8 月 9 日；資料核實自 Apple WWDC26 裝置管理更新頁、Apple Developer 聲明式軟體更新文件、macOS Golden Gate Beta Release Notes。 目前 macOS 27 相關內容仍屬預發布資料，正式版日期、最終建置編號與已知問題不能當作已確認事實。

舊 MDM 命令仍顯示成功，實際控制卻已失效

Apple 已明確列出 macOS 27.0 的變更：舊軟體更新命令、軟體更新查詢、Recommended Cadence，以及傳統延遲與 Background Security Improvements 限制，不再於全部 27.0 系統中維持原有功能。Apple 建議管理團隊改用聲明式軟體更新管理。

這會形成一個很危險的錯覺：

• MDM 控制台記錄「命令已發送」，但裝置沒有進入下載階段。
• 舊查詢沒有回傳可靠結果，平台仍以過期資料判斷節點可升級。
• 舊延遲設定看似存在，實際上不能再作為 macOS 27 的放量閘門。
• 遠端 Mac 重啟後可能沒有回到原有管理流程，CI Runner 也未重新接單。
• 管理員只檢查系統版本，沒有確認聲明是否啟用、更新是否失敗或裝置是否持續回報。

因此，正式版前的判斷不是「舊命令現在還能不能用」，而是：你的平台是否已能在不依賴舊命令的前提下，完成一個節點從接收聲明到 CI 復原的完整閉環。

從舊能力切換到新控制面

遷移時不要把「命令」「查詢」「配置描述文件」「聲明式設定」混為一談。它們在流程中的責任不同。

Apple 的官方文件指出，Apple Software Lookup Service 會提供公開版本、可供管理服務使用的版本、建置編號、發布日期、過期日期及支援裝置資料。管理平台應用它核對「可以推送什麼」，而不是只讀取本身資料庫中的版本清單。

同時，聲明式管理不是把舊命令換成另一個按鈕。裝置會自行朝聲明描述的目標狀態前進，管理服務則透過狀態報告觀察結果。管理服務應訂閱系統版本、建置版本及軟體更新安裝狀態；狀態會反映等待、下載、準備、安裝及失敗等階段。

第一個場景：仍使用舊命令的遠端 Mac

先盤點目前平台真正呼叫的能力，不要只看管理主控台的功能名稱。至少要找出以下資料：

1. 是否仍發送按需更新命令。
2. 是否用舊查詢判斷目標版本可用。
3. 是否用傳統延遲或 Recommended Cadence 決定放量日期。
4. 是否用配置描述文件中的舊限制判斷 Background Security Improvements。
5. 是否有自製腳本把 MDM 命令結果直接轉成「升級成功」。

每一項都要有替代路徑。按需命令改為指定版本聲明；版本查詢改為 Apple Software Lookup Service；裝置狀態改由 StatusReport 與相關狀態項回報；延遲與最後期限則拆成設定聲明及強制更新聲明。

這裡可以保留的，通常是外圍審批流程，例如變更單、維護窗口、節點分組、通知及人工核准。不能保留的是把「命令已送出」當成「裝置已接受並完成更新」的判定方式。

注意： 聲明處於 active，不等於系統已升級。你至少要同時看到聲明有效、目標版本可用、安裝狀態有進展，以及裝置在重啟後再次回報。

第二個場景：延遲升級與指定期限不能混成一件事

macOS 27 的遷移應把三種政策分開：

• 繼續暫緩： 適合正在等待相容性測試的群組。用 SoftwareUpdateSettings 控制版本何時提供，但仍要監控可用版本與安全更新影響。
• 開放使用者安裝： 適合非關鍵遠端 Mac。裝置可以自行安裝，平台仍需追蹤目標版本與建置編號。
• 到期強制安裝： 適合已通過測試、必須在維護窗口完成的節點。使用指定版本與本地安裝時間的強制聲明。

Apple 文件說明，延遲設定定義的是版本公開後多久才向使用者提供；即使設定了延遲，管理服務仍可對裝置強制指定更新。多份聲明同時存在時，裝置會依個別鍵的合併規則處理；多個較新目標版本並存時，較早的目標日期會先進入處理。

你應把每個節點的有效政策記錄成可讀結果，而不是只保留 JSON。至少能回答：

• 目前生效的是哪一份聲明？
• 目標是 macOS 27 哪個版本與建置？
• 是等待提供、允許安裝，還是已進入強制期限？
• 舊政策是否仍殘留並影響判斷？
• 失敗後會暫緩、人工接管，還是切換平行節點？

第三個場景：macOS 26 與 macOS 27 的雙軌管理

混合環境不要以「所有 Mac」作為一個更新群組。至少分成：

• macOS 26、仍使用舊管理能力的節點。
• macOS 26、已具備聲明式管理能力但尚未升級的節點。
• macOS 27 測試節點。
• macOS 27、已完成生產驗收的節點。

每組都要核對系統版本、建置編號、硬體識別、監督狀態、註冊方式及目標聲明作用範圍。Apple Software Lookup Service 的支援裝置資料可用於判斷某版本是否適用於指定硬體；不要讓平台只用作業系統主版本作粗略匹配。

雙軌階段的退出條件也要先寫好：

• macOS 27 節點的聲明已有效。
• 目標版本與建置編號能被服務查到。
• 至少一個非關鍵節點完成下載、準備、安裝與重啟。
• 遠端連線恢復，管理狀態重新回報。
• CI Runner 完成重新註冊並成功接下一個測試工作。
• macOS 26 節點已有升級期限、退役計畫或明確保留理由。

沒有這些條件，雙軌就會變成永久例外，最後仍由舊命令繼續承擔生產風險。

第四個場景：無人值守 Apple silicon Mac 的授權驗收

無人值守更新最容易卡在授權與重啟，不是卡在「命令沒有送到」。Apple 說明，Apple silicon Mac 可使用 Bootstrap Token 授權軟體更新；進行更新時也需要符合卷宗擁有權條件。

逐台驗收時，按以下順序執行：

1. 確認裝置處於受監督狀態，且使用裝置註冊或自動裝置註冊。
2. 確認管理服務已託管 Bootstrap Token。
3. 確認至少有符合條件的卷宗擁有者。
4. 由 Apple Software Lookup Service 核對目標版本與建置編號。
5. 下發聲明，不要先使用舊更新命令作為補救。
6. 觀察聲明啟用及軟體更新狀態是否由等待進入下載、準備、安裝。
7. 驗證重啟後遠端連線、管理註冊及狀態回報。
8. 驗證構建工具、憑證、Runner Agent 和工作佇列恢復。

SoftwareUpdateEnforcementSpecific 可使用 TargetOSVersion、TargetBuildVersion 及 TargetLocalDateTime 指定目標與期限。若目標版本或建置編號尚未被 Apple Software Lookup Service 提供，裝置會保留聲明，但不能完成更新；這種狀態不能算作推送成功。

第五個場景：CI Runner 的試升與生產放量

CI Runner 不應以「系統版本變了」作為唯一成功條件。試升前先排空工作佇列，或把節點標記為不可排程；否則升級期間中斷的建置可能被誤判為程式碼或工具鏈問題。

建議用這個放量順序：

1. 選一個非關鍵 Runner，確認目前沒有執行中工作。
2. 套用 macOS 27 指定版本聲明。
3. 觀察聲明啟用、下載、準備及安裝狀態。
4. 等待節點重啟，測試 SSH、遠端桌面或管理平台連線。
5. 確認 Runner Agent 自動啟動並重新接單。
6. 執行一個包含實際編譯、簽署或測試的驗證工作。
7. 檢查失敗記錄、版本回報及備用節點是否可接管。
8. 只有全部條件通過，才進入下一個小批次。

放量判斷

如果你需要補足非關鍵試升節點，可先查看 MacHTML 的遠端 Mac 服務說明，按節點數量、維護窗口與是否需要平行接管來規劃，而不是把所有生產 Runner 一次切換。

遷移完成前的最小驗收門檻

在正式版或下一個候選版本前，你的管理平台至少要留存以下證據：

• 聲明識別碼、啟用狀態與有效性。
• Apple Software Lookup Service 回傳的目標版本、建置編號及硬體適用性。
• StatusSoftwareUpdateInstallState 的階段變化。
• 安裝原因為聲明式更新，而不是舊 MDM 命令。
• Apple silicon 節點的 Bootstrap Token 與卷宗擁有權結果。
• 重啟後的管理回報時間與遠端連線結果。
• CI Runner 重新接單的驗證工作結果。
• 失敗節點的人工維護或平行節點接管方案。

Apple 的狀態報告採增量回報，並會定期提供完整狀態；管理服務不能只保存最後一次增量事件，否則漏掉事件後可能無法還原節點真實狀態。

常見問題

macOS 27 為什麼收不到舊 MDM 軟體更新命令？

因為 Apple 已將舊軟體更新命令、查詢、Recommended Cadence 及傳統限制列入 macOS 27.0 的停用範圍。控制台的送出記錄只證明管理服務發出要求，不證明裝置接受或完成更新。你應以聲明有效性、目標版本可用性及狀態回報作為新判斷基準。

macOS 27 還能使用 MDM 延遲系統升級嗎？

不要繼續把舊 MDM 延遲命令當作 macOS 27 的主要策略。版本提供延遲應改由 SoftwareUpdateSettings 控制；到期安裝則使用指定版本強制聲明。兩者可以同時存在，但要分別驗證合併結果、目標日期及實際安裝狀態。

如何用聲明式軟體更新指定 macOS 27 版本與安裝時間？

先核對 Apple Software Lookup Service 的可用版本，再設定 TargetOSVersion、可選的 TargetBuildVersion 及 TargetLocalDateTime。目標建置尚未可用時，聲明不會自行創造可安裝版本；平台必須持續更新可用版本清單，並處理過期或撤下的目標。

macOS 26 與 macOS 27 混合環境應怎麼推送？

按作業系統版本、硬體型號、監督狀態與管理能力分組。macOS 27 使用聲明式更新驗收，macOS 26 則保留明確的升級或退役計畫。不要讓 macOS 26 節點誤套用 macOS 27 的指定版本聲明，也不要把兩套狀態回報混成一個成功率。

無人值守 Apple silicon Mac 如何完成強制更新授權？

先確認受監督、註冊方式、Bootstrap Token 託管及卷宗擁有權，再驗證目標版本與建置編號可用。更新成功還不夠；你必須確認裝置重啟後重新連線、回報管理狀態，並讓 CI Runner 恢復接單。任一項未通過，都應留在人工維護或平行節點批次。

你的現有方案與平行 Mac 方案，應按風險而不是按習慣選

繼續依賴舊 MDM 流程，缺點是控制台結果可能與裝置實際狀態脫節、混合系統需要維護兩套例外，而且無人值守節點的授權與重啟失敗會直接放大 CI 停機範圍。單純等待正式版後再處理，還會把試升、回報與工具鏈復原壓縮在同一個維護窗口內。

如果你的生產 Mac 不能停機，或現有節點沒有足夠時間完成授權與 Runner 復原測試，準備一組可切換的平行遠端 Mac 通常比在原節點硬推更容易控風險。你可以在 MacHTML 的價格方案中按維護週期與節點用途評估臨時算力；需要長期穩定重負載、實體介面或固定硬體資產時，自購 Mac 仍可能更合適。對短期試升、版本驗收及升級期間的備援，租用 MacHTML 的遠端 Mac 則能把「先接管 CI，再慢慢遷移」變成可執行的運維方案。

參考資料

• Apple：WWDC26 裝置管理更新
• Apple Developer：使用聲明式管理部署軟體更新
• Apple Developer：SoftwareUpdateEnforcementSpecific
• Apple Developer：軟體更新強制執行階段
• Apple Developer：SoftwareUpdateSettings
• Apple：安全權杖、Bootstrap Token 與卷宗擁有權
• Apple：檢視軟體更新流程
• Apple Developer：StatusReport

延伸閱讀: macOS 27 升級前後的完整檢查指南