寫於 2026 年 8 月 17 日，9 月才上線（部落格的發佈額度在 8 月中用完了，稿子積壓了三週）。文中的版本號與「目前」都指 8 月 17 日的狀態，Claude Code 更新很快，你讀到時可能已經又改過了。

先問你一個問題，答錯的話後面整篇都不用看：你的團隊有在用 cloud session 嗎？

如果你不確定這個詞指什麼，那答案幾乎肯定是「沒有」，而這篇對你的價值就只剩下背景知識。官方文件把這件事放在很前面，講得比我客氣但意思一樣直接：

If your team doesn’t use cloud sessions, there’s nothing here to configure: sessions in a terminal or IDE always run on the developer’s own machine.

你在終端機打 claude、或用 VS Code 擴充跑的那些 session，本來就在你自己的電腦上執行。它們的檔案在你硬碟裡，指令在你的 shell 跑。這件事從來沒有變過，也不需要任何設定。

cloud session 是哪些 session

會跑在別的地方的，是這幾種：從 claude.ai 網頁開的、從手機 App 和桌面 App 開的、在終端機打 claude --cloud 送出去的、以及排程 routine 自己啟動的。這些統稱 cloud session，定義就是「跑在開發者機器以外的地方」。預設情況下，它們在 Anthropic 的機器上跑。

自架環境要換掉的就是這個預設。同一批 session 改成在你的網路裡執行。

這裡有一個很容易走錯的岔路。如果你想要的是「讓 Claude Code 跑在我自己那台常開的電腦上，然後我用手機操控它」，那不是自架環境要解的問題，那是 Remote Control，而且 Pro 和 Max 方案就有。自架環境是給另一種需求的：一組由平台團隊維運的共用機器，公司裡任何人的 cloud session 都可以被送去那裡跑。

兩者的差別在文件裡寫得很清楚：Remote Control 的 session 綁在跑 claude 的那個人身上，他的機器停了 session 就結束；自架環境跑在共用基礎設施上，誰都能用。

三個零件，跟自架 CI runner 是同一個形狀

自架環境有三個部分，官方自己用了一個好類比：runner 的概念跟 self-hosted CI runner 一樣。

Environment 是一個有名字的目的地，在 claude.ai 的管理設定裡建立，它的作用是把一群 runner 歸成一組。Runner 是跑在你網路內主機上的程式，真正執行 session 的就是它。Session 就是開發者交出來的一個任務。

跑起來的順序是這樣：開發者要開 cloud session 的時候，啟動畫面會出現一個環境選單，Anthropic 託管的環境和你們自己建的環境並列在上面。他選了你們的，Anthropic 的 control plane 就把這個 session 放進你們環境的佇列。你的 runner 認領它、把開發者選的 repo clone 下來、然後在你的主機上開一個 Claude Code 行程去跑。

有個細節值得記住，因為它決定了你要準備幾台機器：一個 runner 一次只服務一個使用者。runner 認領第一個 session 的時候就被鎖到那個人的帳號，之後只跑那個人的工作。文件把結論直接寫出來了：

The minimum fleet size is therefore the number of users you expect to be active at once.

同時有五個人在用，你至少要五個 runner。這是架構限制，調參數繞不過去。

它怎麼隔離不同人的程式碼

這段是我覺得整份文件裡最漂亮的設計，也是最值得單獨拿出來看的。

問題是這樣：一台 runner 剛剛幫 A 跑完，硬碟上留著 A 的 repo checkout、可能還有 build 產物和暫存的憑證。現在要讓它服務 B，怎麼確保 B 看不到 A 的東西？

直覺的答案是「跑完把檔案刪掉」。刪檔案這件事出名地難做對：你要列舉所有該刪的路徑，漏一個就漏一個，而且 A 的建置過程可能在你沒想到的地方寫了東西。

它選的作法不是刪，是整個丟掉。--drain-grace-sec 這個參數預設值是 0，意思是 runner 手上的 session 一跑完就直接退出，不再去撈新工作。然後由你的 orchestrator（例如 Kubernetes）用一顆乾淨的磁碟重新啟動一個。文件的說法是：

This lifecycle isolates each user’s checked-out code without requiring the runner to delete disk state between users.

用行程的生命週期換掉清理邏輯。不洗盤子，換一個新盤子。這招之所以成立，是因為在容器化的環境裡，「重建一個」比「清乾淨一個」既便宜又可靠得多，而且它沒有「漏刪」這種失敗模式。你要驗證的東西從「清理腳本有沒有覆蓋所有路徑」變成「新 runner 是不是真的拿到新磁碟」，後者好驗證太多了。

如果你希望 runner 別急著退、繼續服務同一個人，把 --drain-grace-sec 設成正數，它就會繼續撈那個帳號的佇列那麼多秒才退出。

還有一個健康檢查機制：runner 靠 polling 去撈工作，而 polling 同時就是心跳。它停止 polling 大約 60 秒，伺服器就會把 session 重新排回佇列給別的 runner 接手。心跳沒有另外做一套，是搭在既有的 polling 上，這也是同一種省法。

至於機器會在固定時間被回收的情況（spot instance、有生命週期上限的 sandbox），有 --retire-at 可以傳一個 epoch 秒數，設在被砍之前幾分鐘。到時間它會停止接新工作、把手上的 session 逐一釋放掉，讓它們在別的 runner 上接續。沒設這個參數而機器被無訊號砍掉的話，control plane 分不出這是主動釋放還是崩潰，只會記成 lost worker。

網路方向只有一個，這件事比想像中重要

runner 和它跑的 session 會往外開幾種連線，往內的一個都沒有：撈佇列、送 session 的事件流、以及模型推論，全部是往 api.anthropic.com 的 outbound HTTPS。文件裡有一句話值得抄下來給你的網路團隊看：

Anthropic never connects into your network.

你不需要開任何 inbound 規則、不需要打洞、不需要放一台對外的機器。企業的 egress proxy 也支援，runner 跟選用的 autoscaling orchestrator 都會讀 HTTPS_PROXY、NO_PROXY 這些環境變數，session 從 runner 繼承。有一個限制要注意：session 的串流走的是 HTTPS 上的 server-sent events，所以路徑上的 proxy 不能緩衝回應，會卡住。

唯一的 WebSocket 是選用的 orchestrator SCM connector，不用那個功能就一條都沒有。

現在講留在你家的是哪一半

前面都是機制。這一段是我認為動手前非讀不可的部分，因為它決定了自架這件事到底解決了你的什麼問題。

留在你機器上的：repository checkout、build 產物、secrets，以及 session 建立或修改的任何檔案。

會出門的：對話本身。文件寫得毫不含糊：

The conversation itself, including prompts, responses, and tool results, goes to api.anthropic.com for model inference, and Anthropic stores the session transcript so you can resume the session from another supported surface.

拆開來看是三件事。第一，prompt 和回應會送出去，這是推論的必要條件，任何不是自己跑模型的方案都一樣。第二，tool results 也算對話的一部分，而 tool result 裡包含 Claude 讀過的程式碼內容。所以「repo checkout 留在你家」跟「程式碼不出門」是兩件不同的事，它讀了什麼就會送出去什麼。第三，transcript 會被儲存，這樣你才能從別的裝置接續同一個 session。

control plane 也還是 Anthropic 的：session 的調度、佇列、claude.ai 介面全部在他們那邊跑。自架環境搬走的是「執行」，不是「協調」。

所以這個功能的正確描述是「把 session 的執行搬進你的網路」，不是「把資料留在你的網路」。前者能換到三樣東西：session 跑在你網路裡，因此連得到內部服務、資料庫、私有 registry，而這些東西不必曝露到公網；你可以在 runner image 裡預裝編譯器、SDK、內部 CLI，讓每個 session 一開始就能建置；以及 checkout 和 build 產物確實留在你控制的機器上。

官方連 compliance 那一條都自己補了限定句：Session content still goes to api.anthropic.com for model inference.

那個最反直覺的限制

啟用了 Zero Data Retention 的組織不能用自架環境。

第一次讀到會覺得矛盾。最在意資料留存的組織，反而用不了這個把執行搬回自家的功能？

想清楚機制就合理了，而且是必然的。ZDR 的承諾是 Anthropic 不保留你的資料。而自架環境的體驗依賴 Anthropic 保存 session transcript，那正是你能從手機接續電腦上開的 session 的原因。這兩件事在機制層面直接打架，功能定義本身互斥，跟願不願意開放無關。

這也順便告訴你怎麼判斷這類公測功能的邊界：看它的便利性建立在什麼之上。跨裝置接續很好用，代價就是要有個地方存著那段對話。你不可能同時要那個便利和「什麼都不留」。

還有幾個限制一起記：推論一定走 Anthropic API，不能繞去 Amazon Bedrock、Google Cloud 的 Agent Platform、Microsoft Foundry 或你自己的 LLM gateway，因為 session 用的是 Anthropic 發的、綁該 session 範圍的 OAuth token。repo 只支援從 GitHub checkout。Claude Tag、Claude Security 和 Code Review 產生的 session 目前還不會被路由到自架環境。計費跟託管環境一樣，照樣吃你們組織的 Claude Code 用量，自架不會讓它變便宜。

開啟方式：Team 和 Enterprise 的公測，預設關閉，要 Owner 或 admin 去 Cloud environments 管理頁打開「Allow self-hosted environments」，而且組織得先啟用 Claude Code on the web。

一個會讓你查文件查到火大的小事

在 API 欄位、token claims 和 metric 名稱裡，environment 這個東西叫 pool，environment ID 叫 pool_id。文件有一份對照表把兩種拼法對起來，也列了已經 deprecated 的 pool 系列參數名。

這是重新命名留下的痕跡。看到 pool_id 不要以為是別的概念，它就是 environment。

另外，runner 拿來認證註冊的那個共用憑證叫 environment secret，建立環境的時候只顯示一次，而且管理介面上標的是「environment key」。同一個東西三個名字，抄的時候小心。

我的建議，不騎牆

絕大多數團隊不該自架。這句話直接引自官方文件：Most teams are better served by Anthropic-hosted environments, which need no infrastructure to run or maintain.

會讓自架變成對的選擇的，只有一種情況：你的 session 非得連到公網碰不到的東西。內網資料庫、私有 registry、只在公司網路裡解析得到的服務。這個需求沒有替代方案，而自架環境剛好解得很乾淨。

以下這幾種動機我建議你直接排除。想讓程式碼不外流的，前面那段已經說明它做不到，tool result 照樣出門。是 ZDR 組織的，功能層面用不了。想省錢的，計費一模一樣，你只是多養了一批機器。想讓 Claude Code 跑在自己電腦上並從手機操控的，去用 Remote Control，Pro 和 Max 就有。

還有一個不是技術問題但更常勸退人的：這東西的營運責任是實實在在的。你要建 runner image、要維護它、要更新 runner、用 on-demand 模式的話還要顧一個 orchestrator 行程，以及管好整個 fleet 的網路。文件建議指派平台、開發者體驗或開發者生產力團隊來負責。你團隊裡沒有這種角色，就不要從這裡開始。

誠實邊界

我沒有 Team 或 Enterprise 方案，也沒有跑起來過一個 runner。這篇裡每一句對行為的描述都出自 8 月 17 日的官方文件，我只讀了文件。實際部署起來 60 秒 requeue 在網路不穩時會不會誤判、--retire-at 的邊界抓多少分鐘才夠、乾淨磁碟重啟在 Kubernetes 上實際的週轉時間，這些我沒有第一手資料可以說。

要動手的話，官方把頁面按「你在做什麼」分好了：Quickstart 是建環境、起第一個 runner；Deploy to production 講安全強化、網路 egress、git 憑證、Kubernetes 和 Compose 的範例，以及已知問題；Customize sessions 講每個 session 的憑證包裝腳本、生命週期 hook、on-demand runner、MCP 與權限；Testing 給一個上線前驗 runner image 的 CI smoke test；Reference 是所有 CLI 參數、環境變數、metric 和健康檢查端點。

參考來源