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

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

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

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

在爭論之前，先界定影響範圍

Blast radius 是指某個程序可以存取的一組資源。對於在一般使用者帳號下、一般電腦上執行的 agent 而言，這組資源通常比多數人想像的更大。

其中包括 ~/.ssh/id_ed25519。由於你厭倦了反覆輸入 passphrase，它通常未經加密。其中包括 ~/.aws/credentials 與 ~/.config/gh/hosts.yml，這些內容原本就以純文字儲存。其中包括 ~/code 下的所有同層 repository，包括本機 env 檔案中含有 production connection string 的 repository。其中也包括 shell history，裡面可能留有你曾經貼上的 token。它還包括筆記型電腦所在的 network；這通常是家用或辦公室 network，且其中可能有未經驗證的服務。

這些情況都不需要惡意的 agent。只需要一個看似合理但實際錯誤的 command。例如，BUILD_DIR 未設定時執行 rm -rf "$BUILD_DIR"/*，會展開為 /*，並繞過 GNU rm 預設拒絕刪除 / 本身的保護；在錯誤目錄中執行 git clean -xfd；執行會一併刪除本機資料庫的 docker system prune -af --volumes；或在 home directory 上執行看似有幫助的 chmod -R 777。Agent 使用的訓練資料，來自教會所有人這些 command 的同一個 Internet。

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

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

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

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

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

截至 2026 年 10 月的現況

對於「agent 應該在哪裡執行？」有 3 個合理答案，而它們取捨的是相同的 2 件事：隔離邊界有多強，以及你能接受多少設定工作。

本機 micro VM。 這類工具會在你自己的硬體上啟動真正的虛擬機器，將 repository 掛載其中，並讓 agent 在虛擬機器內取得 root 權限。clawk 是目前的範例，其主張正是本文的核心論點：為 coding agent 提供可丟棄的 Linux VM，而不是使用你的筆電。截至 2026 年 10 月，它以 Apple silicon 上的 macOS 14 以上版本為目標平台，並透過 Firecracker 提供實驗性 Linux 支援；安裝時使用 brew install clawkwork/tap/clawk。在 repository 內執行 clawk，即可啟動 sandbox 並連接 agent；使用 clawk down 停止，使用 clawk destroy 移除。其隔離邊界由 hypervisor 提供，強度很高。限制是 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 讓 agent 能「使用 Docker」，隔離邊界就會消失。將 Docker socket 掛載到 container，等同於讓該 container 在 host 上取得 root 權限。

可重新建置的普通 VPS。 不需要新增工具，具備真正的 kernel 隔離邊界，支援 provider snapshot，且關閉筆電後仍會持續執行。本文其餘內容說明的就是這種架構。它也能應付長時間執行的 agent，因為需要 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 ls /home/you

您應該會看到 ls: cannot open directory '/home/you': Permission denied。如果看到檔案清單，表示其他使用者可以讀取您的家目錄，代理程式便能讀取其中未另外限制存取的內容，例如所有使用者都可讀取的 .env 檔案。使用 sudo chmod 700 /home/you 修正。這項測試不會保護您的私密 SSH 金鑰：如果其他使用者可以存取私密金鑰檔案，ssh 會忽略該檔案。因此，任何實際可供您使用的金鑰都已無法由 agent 讀取，不受家目錄權限模式影響。

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

如果將正式環境的 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 成本控制中的數字維持可預測性的方式。

限制 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 會攔截前面規則未允許的所有流量。以 agent 身分測試：

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

這應會立即失敗並顯示 curl: (7) Failed to connect to example.com 錯誤。後續文字會依 curl 版本而異，因為拒絕規則會立即回應，不會讓連線持續等待。對同一個主機發出的 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會說明每個權限層級實際封鎖哪些操作。如果你的工作只涉及單一 repository，且這台電腦上完全沒有 production 憑證，可能造成的影響範圍本來就很小。如果 agent 工作階段時間很短，並且有人監督，暴露時間也會相對縮短。

只要略過提示，情況就會改變。現在auto mode 已是 Claude Code 的預設模式，全新安裝後，在編輯檔案或執行命令前也不再詢問確認。無人看管的執行、隔夜工作，以及核准計畫後離開電腦的工作流程，都會移除原本負責限制影響範圍的人工作業。此時必須改由電腦執行這項控制。同樣的情況也適用於任何會擴大 agent 操作範圍的做法，包括在 VPS 上執行 coding agent，同時處理多個 repository。

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

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。因此，凡是與他人共用的機器，請使用限定於特定儲存庫的 deploy key。

agent 需要多大規模的 VPS？

agent 的工作主要是編輯檔案、執行建置與執行測試，因此應依建置需求規劃機器規模，而不是依模型規模規劃。代管模型在供應商的硬體上執行，會增加網路流量，但幾乎不會增加本機負載。agent 本身仍會設定最低需求：截至 October 20, 2026，Claude Code 的系統需求列出 4 GB RAM 為最低值。即使是腳本工作，也應從 4 GB 開始；如果儲存庫會建置容器或編譯較大型的內容，請提升至 8 GB。

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

當機器狀態變得無法解釋時，請進行重建；只要主機上的憑證可能已暴露，也至少應重建一次。工作之間使用新的 checkout 可處理日常狀態漂移，而在首次執行 agent 前建立 snapshot，則能提供可返回的乾淨系統映像。如果重建成本感覺很高，表示某些重要內容正留在你原本視為可拋棄的機器上。