給 AI coding agent 一台可摧毀的 VM

為什麼可拋棄 VM 勝過筆記型電腦

給 coding agent 一個可拋棄的 VM，它最嚴重能造成的損害，就是摧毀一台你可在 10 分鐘內重建的機器。agent 仍可取得 root 權限、安裝套件，以及執行測試套件，不必每個步驟都要求核准。差異在於損害發生的位置。在筆記型電腦上，agent 會與你的 SSH 金鑰、瀏覽器設定檔、.env 檔案，以及你曾經複製的所有其他儲存庫共用家目錄。在一次性伺服器上，它只有 shell、checkout，以及其他不值得竊取的內容。

這就是完整的論點，而這個論點談的是不對稱性，不是機率。幾乎每次，謹慎的 agent 在謹慎管理的筆記型電腦上都不會有問題。真正出問題的那一次，代價不是錯誤的 commit。如果你有備份，代價是從備份還原。

先界定影響範圍，再討論風險

影響範圍是指某個程序可以存取的所有項目。對於以一般使用者身分在一般電腦上執行的代理程式而言，這個範圍通常比多數人想像的更大。

其中包括 ~/.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 金鑰、輪替個人存取權杖，以及重新複製 20 個儲存庫所需的時數。再將結果與供應商提供的最小型伺服器 12 個月的費用比較。損益平衡點是數年內少於 1 次事故，而且事故不必很嚴重就能超過這個門檻。僅因本機環境損毀而損失一個下午，就已經足以支付一整年的費用。

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

截至 2026 年 7 月的現況

對於「代理程式應在哪裡執行」有 3 個合理答案，而它們都在權衡同樣的 2 件事：隔離邊界的強度，以及您能接受多少設定工作。

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

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

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

--rm 會在結束時刪除 container，--network none 則完全停用其網路。對建置或測試執行而言，這是很好的預設值。但請清楚了解其限制：container 共用 host kernel，因此 kernel 漏洞可能成為逃逸途徑；加入 --privileged 或掛載 /var/run/docker.sock 讓代理程式「使用 Docker」後，隔離邊界就會消失。將 Docker socket 掛載到 container，等同於讓該 container 在 host 上取得 root 權限。

可重建的純 VPS。 不需要新增工具，具備真正的 kernel 隔離邊界、有 provider snapshot，並且在您關閉筆電後仍會持續執行。本指南其餘內容說明的就是這種模式。它能承受代理程式長時間執行，因為需要 4 小時的工作不會因為您下班回家而停止。

VPS 模式：為代理程式建立專用使用者

先從已強化的伺服器開始。新 VPS 的前 10 分鐘涵蓋與代理程式無關的項目：更新、非 root 登入、僅使用金鑰的 SSH，以及防火牆。

接著建立僅供代理程式使用的帳戶，讓其中的錯誤無法影響伺服器上的其他內容。

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 的代理程式即可取得 root 權限，而 root 能讀取其他所有使用者的檔案，因此您剛建立的隔離只是表面上的隔離。如果代理程式確實需要安裝套件，這表示它應該使用一部專用伺服器，而不是在共用伺服器上授予它 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 修正。

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

如果將正式環境的機密複製到一次性機器上，就失去了使用一次性機器的意義。規則很簡單：該機器上不應存放任何會讓你不願意在今天下午輪替的憑證。

使用 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，以你的身分進行驗證。如果伺服器上的其他使用者只有你自己，這是可接受的取捨。在共用機器上則不可接受，此時最好使用僅限於單一儲存庫的 deploy key。相關選項請參閱 SSH 金鑰管理基礎。

至於 API 金鑰，請為 agent 建立專用金鑰並設定專用支出上限，將其儲存在由 agent 使用者擁有且權限為 mode 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。真正的網域允許清單需要讓流量通過能讀取要求主機名稱的 proxy；對多數單一開發人員的環境而言，這需要過多額外機制。請只宣稱你實際具備的能力：在一台你已做好遺失準備的機器上，提供連接埠層級的輸出流量控制。

在工作之間重設為乾淨狀態

每個工作都維持乾淨狀態，這項好處常被低估。某個代理程式花了三小時處理上一張工單，留下已安裝的套件、只套用一半的遷移、過時的 node_modules，以及沒有人審查過變更的 git 工作樹。下一項工作會繼承這些內容，而你必須耗用審查時間，釐清哪些問題屬於哪次執行。

較簡單的做法是每項工作都使用新的 checkout。

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

更穩妥的做法是，在設定好機器且任何代理程式尚未操作機器後，立即建立一次 provider snapshot。還原該 snapshot 後，整個系統會恢復到已知狀態，套件也包含在內。多數 provider 會在控制面板或透過 API 提供此功能，而不是讓你在該機器上執行命令，因此確切步驟取決於你的 provider。關鍵是在機器仍處於未變更狀態時建立 snapshot。

請將重要資料存放在可拋棄機器之外。這通常表示推送分支，而不是將分支堆積在本機。如果機器確實存有你會在意的資料，請使用 VPS 上的 restic 備份 妥善備份。只有在銷毀機器確實不會造成問題時，可銷毀的機器才有用。

如果你想要數個隔離環境，但不想支付數台伺服器的費用，可以讓一台較大型的 VPS 直接託管 guest VM。VPS 上的巢狀虛擬化 說明其運作方式，也包括如何確認 provider 是否允許此功能。

筆記型電腦確實足夠安全的情況

請如實看待這點，因為過度宣稱隔離效果，會讓人不再相信這些說法。

如果您會在每個命令執行前加以檢查，使用筆記型電腦就足夠了。權限提示是真實的控制措施，而 在伺服器上安全地執行 Claude Code 會說明每個權限層級實際封鎖的內容。如果您的工作只涉及單一存放庫，而且電腦上完全沒有任何正式環境憑證，潛在影響範圍本來就很小。如果您的代理程式工作階段時間短且有人監督，暴露時間也同樣很短。

只要您略過提示，情況就會改變。無人值守的執行、夜間工作，以及任何核准計畫後便離開的工作流程，都會移除原本負責遏制風險的人工作業。此時必須改由電腦執行這項控制。任何會擴大代理程式存取範圍的情況也一樣，包括同時在多個存放庫中 於 VPS 上執行程式碼代理程式。

這項決策真正關注的，不是您有多信任模型，而是模型出錯時，旁邊有什麼控制措施。

FAQ

容器是否足以為 coding agent 提供隔離？

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

agent 需要伺服器上的 sudo 嗎？

不需要。授予 sudo 會破壞你建立的隔離環境，因為 root 可以讀取該主機上的所有其他帳戶。建立不具 sudo 權限的 agent 使用者，並只授予其自身工作目錄的寫入權限。如果工作確實需要安裝套件，請提供一台由 agent 專用的完整機器，而不是在共用機器上授予 root 權限。

如何讓 agent 推送至 git，又不將我的 SSH 金鑰放在主機上？

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

agent 需要多大規模的 VPS？

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

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

當機器狀態變得無法說明時，或至少在主機上的憑證可能遭到暴露時，請進行重建。工作之間執行全新的 checkout 可處理日常狀態漂移；在第一次 agent 執行前建立 snapshot，則可提供乾淨的系統映像，以便還原。如果重建成本看似過高，表示有重要資料正存放在你原本視為可拋棄的機器上。