症狀：關閉本地電腦後，Agent 任務也跟著中斷，或重新連線後找不到變更。
最快解法：把 Agent Host 放在靠近程式碼倉庫與 Xcode 工具鏈的獨立雲端 Mac，以 SSH 或開發隧道連線，並為每個任務建立隔離工作樹；先驗證斷線續跑、多視窗同步、工具可用性與回退，再擴大使用。
這篇適合需要讓 GitHub Copilot、Claude 或 Codex 在 Xcode 專案執行長任務的 iOS、macOS 開發者；也適合集中管理多個遠端 Agent 會話、工作樹與憑據的平台工程師。若你正在評估 AI Coding 團隊的雲端 Mac 長任務交付和彈性容量，以下流程可作為第一週的值班 runbook。
最後更新於 2026 年 9 月 3 日；功能狀態與連線方式核實自 VS Code Agent Host 架構說明、VS Code 遠端 Agent 會話文件 及官方遠端連線文件。Agent Host Protocol 仍在持續開發，Claude、Codex、自帶金鑰與部分客戶端工具能力可能受版本或設定限制。
先畫清楚四層責任，再決定是否使用雲端 Mac
VS Code Agent Host 雲端 Mac 部署的第一個錯誤，通常不是指令打錯，而是把不同元件當成同一件事。你需要先分開看：
| 元件 | 實際責任 | 不應假設的能力 |
|---|---|---|
| Agent Host | 保存會話、啟動 Agent harness，並在遠端工作區執行檔案修改與命令 | 不是模型服務，也不是完整安全沙箱 |
| Agent harness | 代表 GitHub Copilot、Claude 或 Codex 執行推理後的工作流程 | 三者的帳號、模型入口與實驗功能不一定相同 |
| 模型提供方 | 提供模型與帳號授權 | 不會自動替你隔離遠端檔案或憑據 |
| 遠端 macOS 環境 | 提供檔案系統、Xcode、Simulator、簽名工具與測試依賴 | 不代表所有客戶端工具在斷線後仍可用 |
如果任務只涉及通用後端程式碼，Linux 或現有 CI 可能更簡單；但只要需要 Xcode 建置、Simulator、Apple 平台測試、簽名工具或 macOS 專屬依賴，雲端 Mac 才有明確理由。獨立環境的目的，是把長任務的執行位置、工作區和憑據邊界固定下來，而不是只讓會話在背景繼續存在。
部署前先寫下四項資料：程式碼目錄、Agent 可以呼叫的工具、可讀寫的憑據範圍，以及任務結束後由誰清理工作樹與撤銷金鑰。這些資料若沒有保存，日後即使能重連，也很難判斷 Agent 是否改動了錯誤目錄。
第一小時：SSH 與開發隧道的連線取捨
官方架構已確認 Agent Host 可作為本地程式或遠端獨立服務執行，並可由多個客戶端連線至同一會話；遠端入口則可在 SSH 與開發隧道之間選擇。不要同時開兩條未治理的入口，否則你很難追查哪個身份曾經接管會話。
| 決策維度 | SSH | 開發隧道 |
|---|---|---|
| 身份管理 | 由 SSH 金鑰、使用者與主機存取規則管理 | 由隧道登入身份與 VS Code 支援的存取流程管理 |
| 網路入口 | 需要管理遠端主機可達性與 SSH 入口 | 適合不希望直接暴露主機入口的情境，仍須管理登入權限 |
| 維運重點 | 金鑰輪換、主機指紋、跳板與登入紀錄 | 隧道生命週期、登入主體與重新連線行為 |
| 適合情境 | 平台團隊已有標準化主機管理 | 團隊希望以 VS Code 的遠端流程接入受控環境 |
| 回退方式 | 保留受限 SSH 作為維修入口 | 隧道故障時切回已驗證的 SSH 路徑 |
選擇前閱讀 VS Code 的 SSH 遠端連線說明與 Remote Tunnels 安全文件；兩者不是單純的「哪個速度較快」問題，而是身份、網路入口和日後值班責任不同。
第一小時的操作順序如下：
- 在本地確認 VS Code 版本、Agent 功能狀態與相關設定，並以 AI 設定參考 核對實驗性選項。
- 準備一台不與其他高風險工作混用的雲端 Mac，確認程式碼倉庫、Xcode 工具鏈和執行身份位於同一個可管理環境。
- 依 Agent Host 架構文件 啟動遠端 Agent Host，不要把一次性的前景測試程式直接視為正式服務。
- 只選 SSH 或開發隧道其中一條路徑，保存連線主體、啟動方式、版本、主機識別資料和首次成功連線紀錄。
- 從第二個客戶端測試同一會話的接管，若身份不清楚、工作區位置不明或日誌無法保留，先停止，不要進入長任務。
連線驗收評分
下表是部署決策工具，不是官方功能評分。每項以 0 至 2 分記錄：0 代表未驗證，1 代表僅在理想條件成功，2 代表已能留存證據並可回退。
| 驗收項目 | SSH | 開發隧道 | 上線門檻 |
|---|---|---|---|
| 身份可追溯 | 至少一條路徑達 2 分 | ||
| 斷線後可重新接管 | 代表性會話達 2 分 | ||
| 遠端工作區位置清楚 | 不得出現未確認目錄 | ||
| 主機重啟後可恢復 | 有明確啟動與回退步驟 | ||
| 維修與撤銷權限 | 值班人員能執行 |
首個小任務：用工作樹隔離 Agent 的修改
連線成功不代表可以立刻交給 Agent 一個大型重構。先選一個可逆的小任務，例如修改一個測試、調整一個建置設定，或補上一個不涉及生產憑據的錯誤處理路徑。核心是確認 Agent Host 直接寫入的是哪個目錄，以及變更是否能被完整檢視。
| 工作方式 | 優點 | 隱性成本 | 建議用途 |
|---|---|---|---|
| 共用主工作區 | 啟動快，人工檢查位置直觀 | 並行任務容易互相覆蓋，回退邊界模糊 | 只適合一次性的低風險驗證 |
| 每個任務獨立工作樹 | 變更、測試和提交範圍清楚 | 需要清理目錄、同步基準分支與管理磁碟空間 | 適合長任務與多視窗接管 |
| 每個任務獨立雲端 Mac | 權限和依賴隔離最清楚 | 成本、啟動時間和容量管理更複雜 | 適合高風險或相互衝突的 Xcode 工作 |
你可以依 Git worktree 的既有團隊規範建立工作樹，再把 Agent Host 的工作目錄明確指向該位置；若團隊尚未定義規則，應先在內部建立目錄命名、基準提交與清理責任，不要假設 Agent 會自動替你完成隔離。
首次會話逐項留存證據：
- harness 使用的是 GitHub Copilot、Claude 還是 Codex，以及實際登入帳號和模型入口。
- 是否開啟實驗性設定；不要把某個客戶端出現的選項推論成所有 harness 都可用。
- Agent 直接修改的路徑、工作樹名稱、基準提交和差異檔案。
- 測試命令、輸出、人工確認請求，以及未執行的高權限操作。
- 提交、丟棄、恢復三條路徑各自的結果。
GitHub Copilot、Claude 和 Codex 能否視為同一種 Agent？不能。它們可能使用不同的帳號授權、模型入口和工具整合；你應該為每一種 harness 各做一次最小任務驗收，而不是只用其中一種成功結果代表全部可用。
停止條件也要先寫好：若 Agent 修改了工作樹以外的目錄、讀取了不在白名單內的憑據、無法說明待確認命令，或丟棄後仍留下未預期變更，立即中止會話，保存日誌並回到乾淨快照。
斷線驗收：持久會話不等於安全執行
關閉本地電腦後，Agent 是否還會繼續執行？只要 Agent Host 是在遠端 Mac 上持續執行，會話可以脫離單個 VS Code 視窗；但你仍要分開測試客戶端關閉、網路中斷、遠端 Mac 重啟和 Host 程式退出。官方會話文件說明了會話管理與重新連線邏輯，不能把「編輯器關閉後可重連」擴大解讀成「任何主機故障都會自動恢復」。
讓一個代表性任務進入執行狀態後，依序執行以下驗收：
- 記錄會話識別資料、工作樹位置、當前命令、終端輸出和待批准操作。
- 關閉第一個 VS Code 視窗，等待一段足以觀察任務狀態的時間，再重新連線。
- 使用第二個 VS Code 視窗或受支援的瀏覽器入口接管同一會話，核對狀態、終端輸出、變更集和確認請求。
- 暫時切斷本地網路，再恢復連線；確認遠端任務是否繼續，以及輸出是否有明確缺口。
- 重啟遠端 Mac，檢查 Agent Host 的啟動方式、工作樹完整性和未完成任務的回復策略。
- 額外停止 Host 程式，驗證這和單純斷線的結果不同；若無法恢復，就把它列為人工接管事件，而不是標記為自動續跑。
多個 VS Code 視窗能否接管同一個 Agent 會話？在官方已確認的架構範圍內，多個客戶端可以連線同一會話，但同步不代表並行輸入沒有衝突。測試時只讓一個視窗送出修改或批准操作，另一個視窗先作唯讀觀察；若兩邊同時下達命令，應以事件日誌和工作樹差異判斷最後狀態。
Xcode、MCP 與瀏覽器工具：由「能連線」走向可交付
Agent Host 能在遠端 macOS 執行命令，不代表每項客戶端擴充工具都能在客戶端斷線後繼續工作。Xcode、瀏覽器和 MCP 應分別驗收，並為互動式輸入、高權限動作和外部服務存取保留人工批准。
先用低風險、接近真實交付的專案測試：
- 確認 Xcode、命令列工具、套件依賴和簽名相關環境位於遠端 Mac，而不是只安裝在本地電腦。
- 讓 Agent 執行一次建置和測試，保存命令、輸出、測試結果與產物路徑；Apple 的 Xcode 命令列工具參考 和 測試結果文件 可作為核對依據。
- 檢查產出的 App、測試報告或封裝檔是否真的位於預期工作樹，而不是把「程式碼生成成功」當成專案已交付。
- 依 MCP 設定參考 核對伺服器位置、環境變數、轉發方式和權限；不要把本地 MCP 設定自動視為遠端可用。
- 對瀏覽器工具測試登入狀態、互動式輸入和提示注入邊界；需要人工批准的操作不可改成無人值守。
實際上，Xcode 建置可能因憑據、模擬器狀態、套件快取或簽名環境而失敗；因此驗收記錄至少要包括「依賴安裝成功」「建置成功」「測試通過」「產物可取得」四個結果，而不是只截取 Agent 的文字回覆。
第一週基線：從試點資料決定共享池或獨占環境
完成一次成功會話後，不要立即把所有倉庫搬到同一台 Mac。連續記錄長任務執行時間、工具呼叫、失敗重試、人工接管、工作樹清理和遠端 Mac 占用情況，再依實際峰值決定環境形態。需要估算並行工作樹與 Xcode 建置峰值時，可延伸閱讀 雲端 Mac 遠端開發容量指南。
| 觀察結果 | 較適合的方案 | 上線前仍要補的控制 |
|---|---|---|
| 任務短、工作樹少、依賴相近 | 受控共享環境 | 強制工作樹命名、權限分層與清理 |
| 長任務常跨本地工作時間，且需要重連 | 任務級獨立環境 | Host 啟動、快照和異常恢復 |
| Xcode 建置、簽名或模擬器互相干擾 | 獨立雲端 Mac | 憑據隔離、產物保存和人工批准 |
| 失敗後常需要人工接手 | 先限制任務範圍 | 事件日誌、回退腳本與值班責任 |
第一週結束前，至少完成以下運維動作：
- 為倉庫建立可恢復快照，並驗證工作樹清理不會刪除主分支或其他任務的檔案。
- 為 Agent 使用的金鑰、環境變數和服務帳號設定最小權限，測試撤銷後會話的實際反應。
- 模擬異常停機，保存 Host、連線、終端和 Agent 事件日誌，確認值班人員能重建任務狀態。
- 為每項高權限工具設定人工批准，不用「會話可持久化」掩蓋命令執行權過大的問題。
- 將成功、失敗、重試和人工接管結果寫入同一份運行紀錄，再決定試點、限制範圍或擴大部署。
如果你目前以本地 Mac 或一般遠端主機代替這套流程，常見缺點是 Xcode 工具鏈不在同一處、工作樹容易共用、斷線後沒有可追溯的會話狀態，並且擴充 MCP 或簽名依賴時需要反覆手動整理環境。完成最小會話與斷線測試後，你可以再比較 MacPull 的雲端 Mac 方案與使用方式，按長任務時長、並行工作樹數量和 Xcode 建置峰值判斷共享池或任務級獨立環境；若只是短期測試或臨時算力，租用通常比先購置一套只為試點服務的設備更容易回退，但長期穩定重負載、需要實體介面或固定簽名設備的團隊，仍應先評估自購和專屬環境。