適合採用雙隊列：把標準化、短時及波動負載交給託管 Agent，把固定 Xcode、私網依賴、正式簽名及長時間任務保留在自託管真實 Mac；只有在工作負載完全標準化，或企業必須完全掌控主機時，才適合單獨選擇其中一種。
這篇文章適合三類決策者：
已採用 Buildkite、需要補充 iOS 或 macOS 構建資源的平台團隊；正在比較託管計算與自託管 Mac 完整 TCO 的企業 IT 及採購負責人；需要隔離正式簽名、內部依賴與非可信程式碼的安全及發布負責人。
00先用工作負載分流建立選型邊界
Buildkite 的 SaaS 控制面負責調度，macOS Hosted Agent 是由平台提供的構建執行環境，而自託管 Agent 則由企業自行安裝並連接至承載 Agent 的真實 Mac。這三者不能混為一談；Agent 架構與工作派送關係可參考 Buildkite Agent 官方架構說明。
企業首先應按任務的控制強度分流，而不是先問哪種 Mac 單次構建較快：
| 工作負載 | 建議隊列 | 主要理由 | 必須核查的證據 |
|---|---|---|---|
| PR 驗證、一般單元測試 | 託管 Agent | 環境標準化，較適合彈性容量 | Xcode 版本、依賴安裝、快取命中 |
| 模擬器測試 | 優先託管，必要時自託管 | 需要確認模擬器、權限及測試工具是否相容 | 測試穩定性、執行時間、並發排隊 |
| 正式歸檔 | 自託管 Mac 或隔離託管隊列 | 需要固定工具鏈與可審計環境 | 憑證位置、工作區清理、產物留存 |
| 生產簽名 | 隔離的自託管隊列 | 不應與非可信分支共用生產憑證 | 金鑰權限、Agent token、出站連線 |
| 企業內網依賴 | 自託管 Mac | 私網、代理及內部服務通常需由企業掌控 | DNS、代理、路由、最小出站規則 |
| 長時間或不穩定任務 | 自託管基線池 | 可自行定義主機、恢復及容量策略 | 無人值守啟動、遠端重啟、替代容量 |
Buildkite 的隊列管理文件說明，隊列是工作派送與 Agent 標籤匹配的重要邊界；因此託管隊列與自託管隊列應分開建立，不能把兩類執行環境放在同一個隊列中，再期待以腳本臨時解決安全或版本差異。隊列配置與管理規則應在架構設計階段先完成。
01版本治理與主機控制
Buildkite macOS Hosted Agent 和自託管 Agent 的差異，重點不只是「主機在誰手上」，而是版本責任由誰承擔。
託管 Agent 的優勢是可以使用已整理好的 macOS 與 Xcode 隊列，團隊不必從零維護每一台主機；但「可以選擇某個系統版本」不等於所有相依套件都能長期凍結。企業仍要檢查鏡像更新節奏、預裝工具、自訂初始化、Agent hooks、快取位置及額外工具鏈。
自託管 Mac 的控制力更完整，能固定特定 Xcode、編譯器、模擬器資料與內部套件，也能按企業變更流程安排升級。不過，固定環境會把維護責任轉回平台團隊：每次 macOS 或 Xcode 更新都要重新驗證簽名、模擬器、依賴管理與構建產物。
Apple 的 Xcode 26 系統要求與 Release Notes應作為版本准入依據。實務上，版本表至少要記錄 macOS、Xcode、SDK、模擬器映像、套件管理器及必要命令列工具；缺少其中一項，隊列看似一致，結果仍可能因主機漂移而不同。
Buildkite iOS 構建應使用託管還是自託管 Mac？
若任務只需標準 Xcode、公開依賴及短時驗證，先選託管 Agent；若涉及固定 SDK、私有套件、正式歸檔、企業內網或生產簽名，則應把任務路由至隔離的自託管 Mac。判斷依據是可審計性和失敗後的恢復責任，而不是單次構建的峰值速度。
02簽名安全與網路信任邊界
非可信分支、PR 驗證與正式發布不應共用同一組生產憑證。託管方案要核查任務結束後環境是否清理、短期憑證如何注入、網路出口是否固定，以及快取是否可能保留敏感檔案。
自託管方案則要把 Agent token、插件白名單、強制乾淨檢出、代理設定及出站連線列入基線。Buildkite 的 自託管 Agent token 文件可用來核對 token 建立、保存與撤銷責任；Job Dispatch 文件則可協助確認工作如何派送至指定 Agent。
| 信任邊界 | 可共用的內容 | 不應共用的內容 | 建議控制 |
|---|---|---|---|
| 公開 PR 驗證 | 非敏感依賴、測試腳本 | 生產簽名金鑰、內部網路憑證 | 獨立託管隊列、最小權限 |
| 內部分支構建 | 經審核的快取與工具鏈 | 未審核插件、長期生產 token | Agent 標籤、插件白名單 |
| 正式歸檔 | 固定版本工具鏈 | 非可信程式碼與共享工作區 | 隔離自託管 Mac、乾淨檢出 |
| 生產發布 | 必要簽名流程 | 一般 PR 任務 | 專用隊列、短期憑證、審計記錄 |
Buildkite 自託管 macOS Agent 如何接入企業內網？
不要先把整個內網暴露給構建節點。應先列出必要目的地，再由自託管 Mac 主動連出控制面，透過企業代理或受限路由存取私有套件、測試服務及簽名相關系統；同時驗證 DNS、代理失效、憑證輪換與出站封鎖後的錯誤行為。若內網依賴無法按最小權限開放，該任務不應與通用驗證隊列混用。
03排隊、任務時長與恢復能力
企業不能用單次構建速度直接推導整體吞吐。實際發布 SLA 會同時受到隊列等待、並發額度、快取命中、模擬器啟動、失敗重試及主機恢復影響。託管 Agent 適合吸收突發隊列，但必須核查任務時長限制與可用容量；Buildkite 的 macOS Hosted Agents 官方文件應作為可用環境與限制的現行依據。
自託管 Mac 的驗收重點則不是 Agent 顯示在線，而是主機失聯後能否無人值守啟動、遠端重啟、清理殘留工作區，並在故障期間由替代容量接手。平台團隊應保存以下記錄：
- 同一組真實專案在託管與自託管隊列的等待時間、構建時間及失敗原因。
- 快取命中與未命中時的差異，不把單次最佳結果當成容量基準。
- 主機重啟、Agent 重連、磁碟空間不足及網路中斷的恢復記錄。
- 發布高峰期間的隊列深度，以及超出基線容量後的回退路由。
建議以自託管 Mac 建立穩定生產基線池，以託管容量承接 PR、模擬器測試及短期高峰；只有在託管隊列通過版本、時長、隔離和排隊證據後，才適合擴大其生產任務範圍。
04完整 TCO 與容量敏感性
Buildkite 託管與自託管 Mac 的完整 TCO，不能只比較每月主機費用。
託管方案的模型應至少列出 Buildkite 當前定價頁所適用的使用費、Agent 使用量、並發或容量相關費用，以及企業自行負擔的網路、快取與秘密管理成本；費率必須以官方定價頁面的現行項目核對，不能套用舊報價或社群轉述。
自託管方案則要把真實 Mac 資源週期、托管或租賃費、平台工具、版本升級驗證、監控、備援容量、閒置時間、故障損失及人力工時全部列入。可用以下變數建立可審計模型：
託管 TCO = 使用量 × 現行費率 + 網路與快取成本 + 秘密管理成本
自託管 TCO = Mac 資源週期 + 平台費用 + 維護工時 + 閒置容量 + 故障損失
| 負載型態 | 託管方案的成本特徵 | 自託管 Mac 的成本特徵 | 決策傾向 |
|---|---|---|---|
| 固定且長時間運行 | 使用量持續累積，需核對長任務費率 | 閒置少，固定資源較容易攤薄 | 優先計算自託管基線 |
| 波動明顯、發布高峰集中 | 低谷不必預留完整主機，彈性較好 | 必須為高峰預留容量，低谷可能閒置 | 優先保留託管彈性 |
| 需要私網與固定工具鏈 | 可能受網路邊界及鏡像能力限制 | 控制力高，但維護與恢復成本增加 | 自託管或雙隊列 |
| 構建量尚未穩定 | 成本隨使用量變化，便於取得基線 | 過早採購會形成沉沒成本 | 先託管試跑，再用帳單決策 |
當企業把託管 Agent 的實際帳單、隊列等待與失敗重試，和自託管 Mac 的租用、維護及故障記錄放入同一張表，才可判斷哪一邊更便宜。不能預設託管一定低於自託管，也不能把未計入人力與閒置容量的硬體報價當成完整 TCO。
05雙隊列試點與准入清單
建議先建立標準託管驗證隊列，再建立與生產簽名隔離的自託管生產隊列；兩邊使用同一批真實專案任務，但憑證、網路權限、快取及工作區必須保持邊界。試點不是安裝教學，而是為企業取得可供採購與安全審查使用的證據。
試點執行清單
- [ ] 為 PR 驗證、模擬器測試、正式歸檔及生產發布建立不同隊列與 Agent 標籤。
- [ ] 固定記錄每個隊列的 macOS、Xcode、SDK、模擬器及額外工具鏈版本。
- [ ] 用同一組專案比較等待、執行、快取未命中及重試後結果。
- [ ] 確認非可信分支無法取得生產簽名憑證與內網秘密。
- [ ] 驗證自託管 Mac 的無人值守啟動、遠端重啟、Agent 重連及工作區清理。
- [ ] 記錄託管使用量、現行費率、自託管資源週期、維護工時及故障損失。
- [ ] 為隊列滿載、主機失聯、代理中斷及 Xcode 不相容設定明確回退路由。
- [ ] 由安全、平台、發布及採購負責人共同簽署准入結果。
准入判斷可按條件執行：若託管隊列能滿足版本、網路、簽名隔離及任務時長要求，並且帳單在實際負載下可接受，就繼續擴大託管範圍；若任一生產條件無法證明，任務回退至隔離自託管 Mac；若兩類任務同時存在，採用託管驗證池加自託管生產池的混合部署。
對於需要把 Mac 作為 Buildkite 自託管節點的團隊，可先閱讀 遠端 Mac 方案與使用方式，再依照企業的服務訂購與區域選擇資訊核對交付條件；正式上線前，仍應把遠端重啟、恢復記錄及實際構建結果納入企業驗收，而不是只以可連線作為合格標準。
06最終選型結論
Buildkite macOS Agent 選型的核心不是「託管或自託管誰更先進」，而是哪個隊列能對應工作負載的控制強度。標準鏡像、短時 PR 驗證及波動任務適合託管 Agent；固定 Xcode、自訂主機控制、私網依賴、生產簽名及長時間任務適合自託管 Mac。多數企業應先以雙隊列取得真實帳單與構建證據，再決定容量比例。
若現有方案是為每位開發者單獨採購 Mac，常見缺點是資產閒置、版本治理分散，且故障與換機需要逐台處理；若採用一般雲端執行環境，則可能缺少真實 Apple Silicon 主機、私網接入與固定簽名邊界。對於需要臨時擴充 CI 容量、測試固定 macOS 工具鏈，或建立可遠端恢復的生產基線，NUKCLOUD 的遠端真實 Mac 租用可作為自託管隊列候選；但長期穩定重負載、必須持有實體介面或已有成熟機房維運能力的團隊，仍應先比較自購 Mac 與既有資產的完整 TCO，再決定是否租用。