症狀：科研專案必須在 macOS 建置或測試，但實驗室沒有合適的 Mac CI 環境。 最快解法：若團隊能維護主機，先在隔離的儲存庫部署 GitHub Actions 自託管 macOS Runner，驗證註冊、執行與清理；不要讓它直接執行不受信任的 PR 工作流程。
這篇適合需要把 macOS 建置或測試接入 GitHub Actions 的研究生與科研開發者。 如果你負責課題組工具鏈，或要管理 Runner 的存取權、憑證與日常維護，也可以按以下流程逐段驗收。
部署前：確認專案是否真的需要自託管 Runner
自託管 Runner 適合必須在 macOS 執行，且依賴特定工具、資料或環境設定的工作；它不會自動讓工作流程更安全，也不代表科研結果已獲得驗證。若 GitHub-hosted Runner 已符合專案需求，就沒有必要只為了使用遠端 Mac 而遷移。
部署前先盤點工作流程的實際需求：建置或測試要用哪些 macOS 工具，是否有特定架構依賴，是否需要存取大型專案檔案，以及產物要如何交給研究者檢查。再確認程式碼、資料和憑證是否可以在實驗室或遠端主機執行；機構的資料政策與 GitHub 的權限設定是兩件事，前者仍須依校內規範另行審批。
| 選項 | 適用條件 | 維護與風險判斷 |
|---|---|---|
| GitHub-hosted Runner | 可用環境及工具足以完成工作流程 | 團隊無須管理常駐主機；先核對專案所需的 macOS 環境是否可用 |
| 實驗室自託管 Runner | 有可管理的 Mac，且實驗室能負責更新、存取控制與清理 | 主機由團隊維護；要檢查本機殘留資料、憑證及執行任務的範圍 |
| 遠端 Mac 自託管 Runner | 專案需要 macOS 主機，但實驗室沒有可用設備 | 適配度取決於資料政策、連線方式、責任分工與服務條款；不應以「主機在線」代替安全審核 |
遠端 Mac 能不能執行 GitHub Actions 的 macOS 工作流程？可以，但「遠端」本身不是相容性保證。主機必須符合 Runner 要求、保持必要的網路連線，並安裝專案需要的工具；你還要確認資料能否傳到該主機，以及如何限制誰能讓它執行工作。
若你正在比較實驗室主機與遠端方案，可先查看 MACGPU 的遠端 Mac 服務資訊，再依自己的資料和機構要求判斷是否適用；頁面介紹不能替代校內資安審批。
註冊前：劃定儲存庫、工作流程與權限
正式註冊前，準備一個可恢復的專用測試儲存庫，或專案的清理副本。先檢視工作流程會讀取哪些檔案、使用哪些機密資訊、是否有外部貢獻者提交的程式碼，以及工作完成後會留下哪些產物。不要把真實敏感資料或高權限憑證放進初次驗證任務。
接著決定 Runner 的管理範圍。GitHub 官方提供新增自託管 Runner 的流程，可按儲存庫或組織等範圍設定；實際註冊位置會影響哪些工作流程有機會使用該 Runner。請依新增自託管 Runner 的官方步驟逐項操作，並對照Runner 存取範圍說明核實哪些儲存庫或使用者可以派送工作。
GitHub Actions 自託管 Runner 怎麼加入 macOS 主機？在 GitHub 的 Runner 管理頁面選擇適當的註冊範圍，再依頁面提供的指令於 macOS 主機下載、設定並啟動 Runner。指令與註冊權杖應從你的 GitHub 管理頁面取得，不要複製其他專案的權杖或沿用過期指令。設定時記錄 Runner 名稱、標籤、所屬範圍與負責人，方便後續確認任務派送對象。
工作流程須明確選取預期的標籤。GitHub 的工作流程語法文件說明可透過 runs-on 指定 Runner；若標籤不吻合，任務可能無法派送到預期主機。另要按最小權限原則檢查 GITHUB_TOKEN：官方的GITHUB_TOKEN 身分驗證說明可協助你設定工作流程所需的權限，不要因為測試方便而授予超出任務範圍的存取權。
**提醒：**GitHub 的安全指引指出，自託管環境可能受到不受信任工作流程的持續影響。即使單次任務完成後，主機仍可能保留檔案、工具設定或其他狀態；不要把 Runner 當成每次工作完成便自動還原的乾淨環境。
註冊後：建立可恢復的主機執行方式
完成註冊後，先從終端機確認 Runner 能啟動並連上 GitHub Actions，再記下手動啟動、狀態檢查及移除 Runner 的操作路徑。這些紀錄應放在團隊可接手的位置，不要只留在單一管理員的筆記或個人帳戶中。
若主機需要在重新啟動後自動恢復，先評估是否符合實驗室的管理政策，再依照macOS Runner 服務設定文件設定服務。不要僅因主機可以自動啟動，就允許它自動接收所有工作；服務管理解決的是啟動與執行方式，不是工作流程的信任或授權問題。
同時建立清理程序：每次任務完成後，要檢查臨時目錄、快取、下載檔案及測試資料如何處理；如果工作流程會留下憑證、輸出資料或使用者內容，就要明確規定清理責任與確認方式。這類主機狀態通常不會因工作流程顯示成功而自動消失。
首次執行：用最小科研工作流程核對鏈路
首次工作流程應採用容易人工核對、且不含敏感資料的任務。確認它能指派到預期標籤，在預期 macOS 主機執行，輸出日誌與產物也能由研究者檢視。不要一開始便執行完整資料分析或包含正式憑證的部署流程，否則出錯時很難分辨是環境、權限還是分析本身造成。
自託管 macOS Runner 怎麼驗證科研專案的建置和測試？把驗收拆成不同檢查：Runner 是否在線、工作流程是否成功、科研軟體是否按預期運作，以及分析結果是否經過研究者複核。前面的狀態只能證明執行鏈路的部分環節，不能單獨證明結果正確、可重現或符合機構政策。
驗證時逐項記錄實際執行環境、使用的工具版本、輸入資料來源、命令與輸出位置。若失敗，保留足以排查問題的日誌，同時確認日誌沒有曝露機密資訊。對科研工作而言，至少要由熟悉專案的人員獨立檢查關鍵產物；綠色的 CI 狀態不是學術結果的審核結論。
安全驗收：不讓不受信任的 PR 直接使用主機
是否允許 fork 來源的 PR 執行在自託管 Runner 上，必須先從程式碼信任、主機隔離及權限範圍評估；不要把「PR 工作流程能觸發」當作「可以安全執行」。GitHub 的安全使用建議特別提醒，自託管主機可能被不受信任的工作流程持續影響。即使敏感機密在某種事件情境下不可用，執行中的程式碼仍可能接觸主機上可存取的檔案或留下內容。
自託管 macOS Runner 能否執行 fork 的 PR？技術上能否觸發取決於事件設定和儲存庫政策，但能觸發不表示應該允許。對不受信任的外部程式碼，先避免派送到持續存在的自託管主機；若目前無法隔離執行、限制儲存庫存取或清除任務殘留，就暫停接入正式儲存庫，改用符合安全要求的 CI 路線。
接入正式專案前，還要確認工作流程可否讀取儲存庫密鑰、專案檔案與主機上的既有資料，並檢查任務結束後的快取、暫存檔和測試資料處理方式。權限設定看似正確，並不代表實際主機環境已隔離；你需要同時核對 GitHub 設定與主機上的可存取內容。
長期維護：保留環境基線與交接紀錄
Runner 上線後，指定負責人定期檢查 macOS、開發工具、Runner 版本與儲存庫權限是否改變，並在每次環境更新後重新執行最小驗證。若工具版本或工作流程標籤變更，記錄變更內容、驗證結果與回退方法；否則後續人員可能無法分辨建置失敗是程式碼回歸還是環境漂移。
保留環境基線、失敗日誌、Runner 啟停與移除方式，以及資料清理和負責人交接紀錄。遇到疑似權限外洩或執行殘留時，先停止派送新任務，再檢查主機狀態與相關權限；不要只重新啟動 Runner，便把問題視為已解決。
如果你的實驗室目前依賴臨時共用 Mac，這種做法可能有環境狀態難追蹤、權限邊界不清、主機離線便中斷工作等缺點；但若研究工作長期高負載、必須直接連接特定實體設備，或受資料不得離開校園的規範限制，遠端租用也未必適合。完成最小工作流程和安全檢查後，才決定是否需要持續可用的 macOS 主機；若要比較遠端 Mac 的部署條件，可參考 MACGPU 遠端 Mac 方案資訊，再按資料政策、維護責任及實際工作流程作選擇。