VS Code 1.138 Agent 建立 PR 後，Mac 建置該放哪？2026

PR 已建立，但 Xcode 建置只能在 Agent Host 上勉強重跑，結果不穩定。
最快解法：讓 VS Code 1.138 Agent 建立 PR 留在 Agent Host，通用檢查交給確定性 CI，Xcode、簽名與 Apple 平台回歸則移到獨立雲端 Mac。

本文最後更新於 2026 年 9 月 20 日；功能狀態核實自 VS Code 1.138 發布說明、Agent Host 架構文件及 GitHub 官方的分支保護與 Runner 文件。

這篇適合三類讀者：
- iOS、macOS 團隊：你需要判斷 Agent 建立 PR 後，哪一台 Mac 應完成 Xcode 驗證。
- 平台工程師：你需要拆分 Agent Host、CI Runner 與遠端執行環境的責任。
- AI 創業團隊：你想控制成本，同時避免共享主機污染與建置排隊。

三層責任

截至上述日期，VS Code 1.138 已確認支援從 Agent Host 工作階段審閱並建立 Pull Request，也可以選擇草稿狀態及可用的合併選項；Agent Merge 仍屬實驗能力。官方資料沒有表示「建立 PR」可以取代分支保護、必需檢查、人工審批或真實 Mac 建置。

你應先把四個容易混淆的狀態拆開：

• Agent 工作階段完成：模型已修改工作區，可能已產生提交。
• PR 已建立：變更已進入團隊審閱流程，不代表任何測試通過。
• 檢查已通過：CI 或 Mac Runner 回報指定工作成功，但仍要確認結果是否來自正確提交。
• 程式碼可發布：分支保護、人工審批、簽名、回歸測試及發佈權限均已滿足。

推薦的預設責任如下：

GitHub Actions 的工作流程可以選擇不同 Runner；自託管 Runner 也有自己的管理與安全責任。你可以參考 GitHub Runner 選擇方式及自託管 Runner 官方說明，不要把「能執行工作」誤當成「適合承擔所有權限」。

純 Web 程式碼場景

如果 PR 只包含前端、後端、腳本或跨平台程式碼，而且測試可以在容器或通用 Runner 中重複執行，你通常不需要為每個 Agent 任務新增 Mac。

這類場景的合理流程是：

1. Agent Host 在隔離工作區修改程式碼。
2. 產生提交並建立草稿或一般 PR。
3. GitHub Actions 依 PR 提交觸發靜態檢查、單元測試與容器化建置。
4. 把測試輸出、依賴鎖定檔和執行環境保存為工作流程證據。
5. 由審閱者確認必需狀態檢查與分支規則後，才決定是否合併。

GitHub 官方的 Workflow artifacts 文件說明了如何保存工作流程產物；工作流程日誌文件則可用來保留執行輸出。你的驗收紀錄至少應能回答：哪一個提交被測試、使用哪個 Runner、測試是否重試、產物從哪一次執行產生。

可以維持通用 Runner 的條件：

• 沒有 Xcode、Simulator、Apple 系統框架或 Apple 專屬工具。
• 測試不依賴本機鑰匙圈、簽名憑證或實體裝置。
• 容器化建置與本機建置的依賴邊界已經明確。
• 失敗後可以從同一提交重新執行，而不是依賴 Agent 工作區的臨時狀態。

若其中一項不成立，就不要因為 PR 已成功建立而把 Mac 驗證省略。

Apple 平台建置場景

一個典型衝突是：Agent 成功建立 iOS PR，GitHub Actions 的通用檢查也變綠，但 Xcode 任務在 Agent Host 上重跑時找不到正確的模擬器、依賴或簽名狀態。這不是 PR 功能失敗，而是執行環境責任放錯位置。

Apple 平台專案涉及 Xcode、Simulator、系統框架或實體裝置時，應使用真實 macOS 建置層。Apple 的模擬器與實體裝置測試說明可作為測試範圍的官方依據，但它不會替你決定憑證應放在哪一台主機。

簽名與發佈權限應再往外分離。產生程式碼的 Agent 不應同時持有發佈憑證；建置主機即使可以編譯，也不代表它應獲得上架或正式發佈權限。

提醒： 看到綠色檢查前，先核對它是否針對目前 PR 的最新提交。若結果來自舊提交、重試工作或另一個工作區，應停止合併，重新建立可追溯的檢查。

受保護分支與高風險倉庫

VS Code 1.138 Agent 建立 PR 的能力，只處理協作入口，不會自動放寬 GitHub 倉庫規則。GitHub 的受保護分支文件列出的分支規則，仍應由倉庫設定與審批流程決定。

在高風險倉庫中，你應逐項核對：

• Agent 使用的是哪一個 GitHub 身份，是否只具備建立分支與 PR 的必要權限。
• PR 的來源分支、目標分支及提交者是否清楚可追溯。
• 必需狀態檢查是否由獨立 CI 或 Mac Runner 回報。
• Agent 是否能修改工作流程、分支規則或檢查設定。
• 是否要求草稿 PR、人工審批及合併佇列。
• 建置產物和日誌是否保存，且與目前提交一致。

停止條件很明確：若同一個身份既修改程式碼，又能以不可分離的權限替檢查結果背書，就不要讓它直接進入合併流程。先降級為草稿 PR，再以獨立 Runner 執行檢查。

遠端工作階段與長任務

當 Agent Host 位於遠端伺服器或雲端 Mac，你要分別保存三種東西，而不是只保存一個工作目錄：

• 程式碼工作區：Git 提交、分支、未提交變更及依賴鎖定檔。
• 任務狀態：Agent 工作階段、工具呼叫、待辦事項和失敗位置。
• 建置產物：測試報告、Xcode 輸出、封裝檔及簽名結果。

客戶端斷線不等於建置可以恢復。你需要在正式採用前做一次中斷演練：

1. 啟動一個可識別提交的 Agent 任務。
2. 讓它建立 PR 或送入 Mac 建置佇列。
3. 中斷本機連線，確認遠端任務是否仍有明確狀態。
4. 重新連線，驗證能否接管同一工作區，而不是建立另一份副本。
5. 人為中止建置，確認產物、日誌與失敗原因仍可取得。
6. 以同一提交重跑，確認結果不依賴原本的暫存目錄。

長時間佔用 Xcode 的任務應進入專用佇列，不要阻塞負責生成程式碼的 Agent 主機。若工作區不能安全接管，或建置被中斷後只能人工猜測進度，就應停止把它當作可恢復的自動化流程。

常見問題

FAQ 對應的長尾意圖已集中在此，方便你按團隊現況直接判斷：

VS Code Agent Host 建立 PR 後，還需要跑 CI 嗎？

需要。Agent Host 負責修改工作區、提交變更和發起 PR；CI 才適合執行可重複的靜態檢查、單元測試與容器化建置。PR 已建立只是協作入口，不能取代必需狀態檢查、測試紀錄或受保護分支的審批條件。

Agent 產生的 iOS PR 應該在哪裡執行 Xcode 建置？

只要涉及 Xcode、Simulator、Apple 系統框架或簽名，就應放在獨立的 macOS 建置層。這台 Mac 可以是自託管 Runner 或雲端 Mac，但不宜和產生程式碼的 Agent Host 長期共用，否則依賴、工作區和權限狀態會互相污染。

Agent Host 和 GitHub Actions Runner 可以使用同一台 Mac 嗎？

低風險原型可以暫時共用，但必須限制權限、清理工作區並保留獨立建置紀錄。正式產品、簽名流程、發佈工作或無人值守任務不應共用，因為同一主機可能同時持有程式碼修改權、建置權和敏感憑證，難以界定結果責任。

多個 Agent 同時提交 PR 時，Mac 建置工作應怎樣排隊？

先把等待時間、實際執行時間、失敗重試和人工審批分開記錄，再決定調整佇列或增加彈性 Mac 容量。不要按照 Agent 工作階段數量直接一比一配置主機；若瓶頸只出現在 Xcode 建置，就擴充獨立 Mac 層，而不是增加產生程式碼的主機。

多 Agent 並行建置

多個 Agent 可以共享專案背景，但共享上下文不代表共享一台 Mac。當 PR 同時增加，瓶頸往往會從模型生成轉移到依賴安裝、測試佇列、Xcode 編譯和人工審批。

你應把每個 PR 的時間拆成四段：

• 等待 Mac 或 Runner 的時間。
• 實際執行建置與測試的時間。
• 失敗後重試或清理工作區的時間。
• 等待人工審批、簽名或發佈授權的時間。

如果只有等待時間持續增加，而實際建置時間穩定，優先調整佇列策略或增加彈性 Mac 容量。如果實際建置本身不穩定，先修正快取、依賴和工作區隔離，不要直接增加主機數量。如果瓶頸在簽名審批，擴充 Mac 也不會解決問題。

低風險共用條件

• PR 不涉及正式簽名、發佈憑證或生產環境。
• 任務可由人工監督，且工作區能在每次執行前清理。
• Agent、CI 和建置身份的權限已分離。
• 失敗可以用同一提交重新執行，並保留日誌與產物。

必須拆分環境的條件

• 任務需要存取簽名憑證、鑰匙圈或實體裝置。
• Agent 可以修改工作流程或倉庫權限。
• Xcode 建置會長時間佔用主機，影響其他工作階段。
• 任務要無人值守執行，或結果會直接進入正式發佈。
• 你無法證明檢查結果來自目前 PR 的提交。

三檔決策

你可以按以下三檔處理現有流程：

若你目前還未把 Agent Host 與 Mac 建置分開，可以先參考 kvmsync 的遠端 Mac 相關內容，再用 支援與使用說明核對連線、工作區接管和任務交付方式。不要先購買或租用更多主機，卻沒有測量佇列究竟堵在哪一層。

回到最初的選擇：把所有工作放在 Agent Host 原機，短期看似少了傳遞步驟，但會承受工作區污染、長任務互相阻塞、權限難以分離和結果不易重現等缺點；通用 CI 也無法替代真實 macOS 上的 Xcode 與簽名驗證。對需要臨時算力、峰值建置或隔離測試環境的團隊，租用 kvmsync 的雲端 Mac，通常比把 Agent、CI 和 Apple 平台交付硬塞在同一台主機更容易控制責任邊界。若你的負載是長期穩定的大量建置，或必須持有實體介面與固定硬體，則應如實比較自購 Mac、專用自託管 Runner 和雲端租用，而不是盲目採用租用方案。

你可以先用上面的三層表格標記目前 PR 流程：如果 Xcode 建置仍和 Agent 工作階段共用主機，再按團隊的佇列等待與任務恢復需求評估雲端 Mac；需要臨時 Mac 建置或隔離驗證時，可到 kvmsync 方案頁面查看可行的租用安排。