為什麼 coding agent 應該使用一次性 VM

為什麼一次性 VM 勝過你的筆記型電腦

給 coding agent 一台一次性 VM，最糟的情況也只是它破壞一台你能在十分鐘內重建的機器。agent 仍然取得 root 權限、仍然能安裝套件，也仍然可以在不必逐步要求許可的情況下執行測試套件。差別在於損害發生的位置。在筆記型電腦上，agent 會與你的 SSH 金鑰、瀏覽器設定檔、.env 檔案，以及你曾經複製過的所有其他儲存庫共用 home 目錄。在一次性伺服器上，它只有 shell、checkout，以及其他沒有竊取價值的內容。

這就是完整的理由。重點不在機率，而在不對稱性。即使是在筆記型電腦上，謹慎的 agent 幾乎每次都不會造成問題。但只要有一次出錯，代價就不只是一次錯誤的提交。如果你有備份，就必須從備份還原。

先界定影響範圍，再討論它有多嚴重

影響範圍是指某個程序可以存取的一組資源。對於在一般使用者帳號和一般電腦上執行的代理程式而言，這組資源通常比多數人想像的更大。

其中包括 ~/.ssh/id_ed25519。由於不想反覆輸入密語，這裡通常未經加密。其中包括 ~/.aws/credentials 和 ~/.config/gh/hosts.yml，它們原本就是純文字格式。其中包括 ~/code 下的所有同層級儲存庫，包括本機環境檔案中含有正式環境連線字串的儲存庫。其中也包括 shell 歷程記錄，裡面可能留有你曾經貼上的權杖。它還包括筆記型電腦所在的網路，而該網路通常是家用或辦公室網路，可能有未經驗證的服務。

這些情況都不需要惡意代理程式。只需要一個看似正確、實際上錯誤的命令。例如，rm -rf 中未設定的變數展開為 /；在錯誤目錄中執行 git clean -xfd；執行會連同本機資料庫一起刪除的 docker system prune -af --volumes；或在家目錄上執行看似有幫助的 chmod -R 777。代理程式也是根據教會其他人使用這些命令的同一個網際網路資料訓練而成。

真正保護你的機制不是代理程式的判斷力，而是承受損害的那台機器，原本就是你願意放棄的機器。

成本計算很無聊，但重點就在這裡

小型 VPS 每月只需幾美元。復原開發者筆記型電腦需要一天，而這還是理想情況：你能立即發現問題，而且手上有備份。

請使用自己的數字計算。以你的時薪為基準，乘以重新安裝作業系統、還原家目錄、輪替 SSH key、輪替個人存取權杖，以及重新複製 20 個儲存庫所需的時數。再將結果與供應商提供的最小型伺服器 12 個月的費用比較。損益平衡點低於數年內發生 1 次事故，而且事故不必造成災難性後果就能超過這個門檻。本機環境損毀，僅損失一個下午的時間，就已經足以抵銷一整年的費用。

計算的另一半是快照。在執行高風險操作前建立快照，可以把糟糕的結果從「還原我的整個工作環境」變成「回復到先前狀態，再嘗試不同的提示」。你目前用來工作的筆記型電腦無法提供這個選項，因為你不能在使用電腦工作的同時，為它建立快照。

截至 2026 年 7 月的現況

對於「agent 應該在哪裡執行」這個問題，有 3 個務實答案。它們取捨的都是同樣 2 件事：隔離邊界有多強，以及你能接受多少設定工作。

本機 micro VM。這類工具會在你自己的硬體上啟動真正的虛擬機器，將儲存庫掛載其中，並讓 agent 在虛擬機器內取得 root 權限。clawk 是目前的範例，其主張正是本文的核心論點：為 coding agent 提供可丟棄的 Linux VM，而不是你的筆記型電腦。截至 2026 年 7 月，它的目標平台是 Apple silicon 上的 macOS 14 及後續版本，也可透過 Firecracker 實驗性支援 Linux，並使用 brew install clawkwork/tap/clawk 安裝。在儲存庫內執行 clawk 可啟動 sandbox 並連結 agent，執行 clawk down 可停止它，執行 clawk destroy 可移除它。這裡的隔離邊界是 hypervisor，強度很高。限制是 VM 仍在你隨身攜帶的電腦上執行，因此會占用記憶體；合上螢幕時也會停止。

容器。Docker 是大多數人已經安裝的選項，而且確實很實用。

docker run --rm -it -v "$PWD:/work" -w /work --network none ubuntu:24.04 bash

--rm 會在結束時刪除容器，--network none 則完全停用其網路連線，這對建置或測試執行來說是很好的預設值。必須清楚了解它的限制：容器與主機共用 kernel，因此 kernel 漏洞可能成為逃逸途徑；一旦加入 --privileged，或掛載 /var/run/docker.sock 讓 agent 能夠「使用 Docker」，隔離邊界就會消失。將 Docker socket 掛載到容器中，等同於讓該容器取得主機上的 root 權限。

可重建的普通 VPS。不需要新增工具，具備真正的 kernel 隔離邊界，支援 provider snapshot，而且在你關閉筆記型電腦後仍會持續執行。本指南其餘內容說明的就是這種模式。它也最適合長時間執行的 agent，因為需要 4 小時的工作不會因為你下班回家而受到影響。

VPS 做法：讓 agent 使用專用帳號

先從已強化的主機開始。新 VPS 的前 10 分鐘涵蓋與 agent 無關的項目：更新、非 root 登入、僅限金鑰的 SSH，以及防火牆。

接著建立一個只供 agent 使用的帳號。這樣即使帳號內部發生錯誤，也不會影響伺服器上的其他內容。

sudo adduser --disabled-password --gecos "" agent
sudo install -d -m 700 -o agent -g agent /home/agent/work
sudo -u agent -H bash -lc 'id; ls -la ~'

--disabled-password 表示沒有可供猜測的密碼。你必須使用 sudo -u agent 或 SSH 金鑰登入該帳號。請注意，agent 刻意不屬於 sudo 群組。具備 sudo 的 agent 擁有 root 權限，而 root 可以讀取其他使用者的所有檔案，因此剛建立的隔離只會流於形式。如果 agent 確實需要安裝套件，這表示應該提供一台由它獨占的完整伺服器，而不是在共用伺服器上授予它 sudo。一般規則請參閱 VPS 上 Linux 使用者的最小權限原則。

在信任它之前，先確認隔離邊界。使用 agent 帳號，嘗試讀取屬於自己帳號的檔案：

sudo -u agent cat /home/you/.ssh/id_ed25519

你應該會看到 cat: /home/you/.ssh/id_ed25519: Permission denied。如果看到的是金鑰資料，表示家目錄的模式為 755，隔離尚未真正生效。請使用 sudo chmod 700 /home/you 修正。

完全不要將憑證放在機器上

如果將正式環境的 secret 複製到一次性機器上，就失去了使用這類機器的目的。規則很簡單：該機器上的任何內容，都不應包含讓你不願意在今天下午輪替的憑證。

使用 git 時，請轉送 SSH agent，不要複製金鑰。私密金鑰會留在筆電上，只有簽章請求會通過連線傳送。

ssh -A agent@203.0.113.10
ssh -T git@github.com

第二個命令應該會回覆 Hi yourname! You've successfully authenticated, but GitHub does not provide shell access.。這證明 git push 在伺服器上沒有金鑰檔案時仍可運作。接著在該機器上執行 ls -la ~/.ssh，確認其中沒有私密金鑰。

Agent forwarding 有一項實際的風險，必須明確說明：在你連線期間，伺服器上任何擁有 root 權限的人，都能使用轉送的 socket 以你的身分進行驗證。如果伺服器上唯一的其他使用者就是你，這是可接受的取捨。在共用機器上則不可接受，此時最好使用只限於單一 repository 的 deploy key。相關選項請參閱 SSH 金鑰管理基礎。

對於 API 金鑰，請為 agent 建立專用金鑰，設定獨立的消費上限，並將其儲存在由 agent 使用者擁有且權限為 600 的檔案中。機器銷毀後，請撤銷該金鑰，不要再猜測它是否已經外洩。逐一查看每個金鑰的模型消費量，也是讓 VPS 上的 AI agent 成本控制中的數字維持可預測性的方式。

限制代理程式可連線的網路範圍

檔案系統隔離只構成邊界的一半。另一半是輸出流量控管，也就是限制程序可連線的對象。Linux 可以依建立連線的使用者篩選輸出流量，正好符合這個模式。

sudo iptables -A OUTPUT -m owner --uid-owner agent -o lo -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -p udp --dport 53 -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -p tcp --dport 443 -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -j REJECT

規則會依序讀取，因此最後的 REJECT 會攔截前面規則未允許的所有流量。請以代理程式的身分測試：

sudo -u agent curl -sS -m 5 http://example.com

這應會因 curl: (7) Failed to connect to example.com port 80: Connection refused 而失敗，因為 reject 規則會立即回應，不會讓連線持續等待。對同一主機發出的 HTTPS 請求仍應成功。

有兩項限制必須說明。第一，除非儲存規則，否則下次重新開機時規則會遺失；可使用 sudo apt install -y iptables-persistent，再使用 sudo netfilter-persistent save。第二，這只能篩選連接埠和位址，不能篩選名稱。允許連接埠 443 就代表允許連線到網際網路上的所有 HTTPS 主機。這足以連線到模型 API，也同樣足以連線到 pastebin。真正的網域允許清單必須讓流量通過能讀取要求主機名稱的代理伺服器，但對多數單人開發環境而言，這需要的機制過於複雜。請只宣稱你實際具備的能力：在一台你已做好遺失準備的機器上，控管連接埠層級的輸出流量。

在各工作之間還原為乾淨狀態

每項工作都維持乾淨狀態，是一項常被低估的好處。某個 agent 花了三個小時處理上一張工單，留下已安裝的套件、套用一半的 migration、過期的 node_modules，以及一個沒有人審查過變更的 git working tree。下一項工作會繼承這些內容，而你得耗用審查時間，釐清哪些混亂屬於哪次執行。範圍較小的 agent 一開始就會留下較少內容，因此將可丟棄的機器搭配促使 agent 採用能運作的最小變更的技能，就能讓 diff 與殘留狀態都小到足以審查。

較簡單的做法，是為每項工作建立新的 checkout。

sudo -u agent -H bash -lc 'rm -rf ~/work/repo && git clone git@github.com:you/repo.git ~/work/repo'

更完整的做法，是在機器設定完成且尚未有任何 agent 使用之前，先建立一次 provider snapshot。還原該 snapshot 後，整個系統及其套件都會回到已知狀態。多數 provider 是在控制面板或透過 API 提供這項功能，而不是在機器上提供命令，因此確切步驟取決於你的 provider。重點是在機器仍處於未變更狀態時建立 snapshot。

請將所有重要資料存放在可丟棄機器之外。這通常表示推送 branches，而不是將它們留在本機。如果機器確實存放了你不希望遺失的內容，請使用VPS 上的 restic 備份正確備份。只有在銷毀機器確實不會造成問題時，可銷毀的機器才真正有用。

如果你想要多個彼此隔離的環境，又不想支付多台伺服器的費用，可以讓一台較大的 VPS 直接代管 guest VMs。VPS 上的巢狀虛擬化說明其運作方式，也包含如何確認 provider 是否允許這項功能。這裡的隔離具有雙面性。如果你希望同一台機器上的兩個 agent 彼此協作，而不是完全隔離，那麼一個 Claude Code 工作階段可以直接將文字傳送給另一個，不必讓每次交接都經過你。

在具備適當防護的情況下，筆電確實可以使用

這點必須如實說明，因為過度宣稱隔離效果，會讓人不再採信相關建議。

如果您會在每個命令執行前逐一檢查，使用筆電就沒有問題。權限提示確實是一項有效的控制措施，而在伺服器上安全執行 Claude Code的重點，就是了解每個權限層級實際會阻擋哪些操作。如果您的工作只涉及單一儲存庫，且機器上完全沒有任何正式環境憑證，潛在影響範圍本來就很小。如果 agent 工作階段時間短且有人監督，暴露時間也會相對縮短。

一旦略過提示，情況就會改變。現在尤其值得注意，因為auto mode 將在 14 August 2026 成為 Claude Code 的預設模式，全新安裝不再於修改檔案或執行命令前詢問。無人值守的執行、夜間工作，以及核准計畫後離開的任何工作流程，都會移除原本負責限制操作的人工檢查。此時就必須改由機器執行限制。同樣的情況也適用於任何會擴大 agent 操作範圍的做法，包括在 VPS 上執行 coding agent，同時處理多個儲存庫。

這項決策真正關注的，不是您有多信任模型，而是模型出錯時，旁邊有哪些系統與資料會受到影響。

FAQ

容器是否足以為程式碼代理程式提供隔離？

對大多數工作而言可以，但必須符合兩個條件。容器不得以 --privileged 執行，也不得將 /var/run/docker.sock 掛載其中，因為其中任一項都會讓程序取得通往主機 root 的路徑。容器會共用主機核心，因此其隔離邊界比虛擬機器弱。如果代理程式會執行從網際網路取得的不受信任程式碼，請優先使用真正的虛擬機器或獨立伺服器。

代理程式需要伺服器上的 sudo 嗎？

不需要。授予 sudo 會破壞你建立的隔離，因為 root 可以讀取伺服器上其他所有帳戶的資料。建立不具 sudo 權限的代理程式使用者，並只授予它自身工作目錄的寫入權限。如果工作確實需要安裝套件，請給代理程式一台由它獨占的完整機器，而不是在共用機器上授予 root 權限。

如何讓代理程式推送至 git，又不將我的 SSH 金鑰放在伺服器上？

連線時使用 ssh -A 轉送 SSH agent。簽章要求會透過連線傳送，私密金鑰則留在你的筆記型電腦上，因此 ssh -T git@github.com 可進行驗證，git push 也能運作，伺服器上不需要私密金鑰。但要注意，你連線期間，該伺服器上的 root 可以使用轉送的 socket。因此，在與他人共用的任何機器上，請使用限定特定 repository 的 deploy key。

代理程式需要多大規模的 VPS？

代理程式的工作主要是編輯檔案、執行建置與執行測試，因此應依建置需求決定機器規模，而不是依模型需求決定。託管模型會在供應商的硬體上執行，只會增加網路流量，幾乎不會增加本機負載。腳本工作可先從 2 GB RAM 開始；如果 repository 會建置容器或編譯大型程式，再提升至 8 GB。

應多久摧毀並重建一次機器？

當機器狀態變得無法解釋時就應重建；至少在機器上的任何憑證可能已遭暴露時重建。任務之間使用新鮮的 checkout 即可處理日常狀態漂移，而在代理程式第一次執行前建立 snapshot，則能提供可返回的乾淨系統映像。如果重建成本看起來很高，表示某些重要資料正存在於你原本稱為可拋棄式的機器上。