託管 agent在服務商的雲端上執行。你提供一份儲存庫副本和一組憑證，它便在該處運作。本機優先 agent則在自己的機器上執行，執行環境、訂閱、檔案與金鑰皆已存在於機器本機，只有對話會離開。
兩者都是合理的架構設計。它們將你的程式碼、身分與帳單放在不同的地方，而一旦你開始與其他人共享 agent，這些差異就會變得格外重要。
託管方案的優勢與代價
2026 年的具體範例包括 Claude Code on the web 與 OpenAI’s Codex cloud tasks。兩者都在服務商的沙箱中執行 agent，針對你儲存庫的 clone 進行操作，並透過 GitHub 的 OAuth 整合所發行給服務商的 token 對 git 進行驗證，因此 agent 永遠無法接觸到你的本機憑證、SSH 金鑰或環境變數。這是一項實質的安全特性：受入侵的開發者筆記型電腦不會波及 agent 的環境，而權限範圍不當的任務也無法接觸到沙箱以外的檔案。
託管 agent 永遠處於在線狀態。不需要讓筆記型電腦保持喚醒，也不需要安裝任何軟體。對於全天候無人值守的叢集而言，這是決定性的優勢。
其代價則是結構性、無法單純修復的問題。
- 所有東西的第二份副本。 服務商持有你的儲存庫，往往也包含你的環境，以便 agent 能正常運作。該副本擁有獨立的存取控制、資料保留期與外洩受攻擊面。
- 第二套憑證。 給 GitHub、雲端帳號與內部 API 的 token 都發行給服務商。輪替憑證代表你也必須在那裡同步輪替。
- 第二張帳單。 除了現有的訂閱之外（或取代原有訂閱），你還得為託管的執行環境額外付費。
- 由他人決定的模型選擇。 託管方決定提供哪些模型，以及何時更換。
本機優先方案的優勢與代價
本機優先 agent 使用你機器上既有的資源：你付費訂閱的 Claude Code 或 Codex、你已經 checkout 的儲存庫、鑰匙圈中已有的金鑰。任何東西都不會被複製到其他地方。當你共享 agent 時，其他人提出請求，你的機器依然負責執行工作。
代價則是可用性。如果機器處於睡眠狀態，agent 也會跟著休眠。
緩解方式偏向實務操作而非架構層面：將 daemon 註冊為服務，使其在登入時啟動並在崩潰後自動重啟；在工作時間保持機器喚醒；將請求排隊放入收件匣，如此一來在離線期間也不會遺失任何內容。當機器恢復連線時，請求會依序執行。
兩種設置信任邊界的位置：圍繞服務商的沙箱，或是圍繞自己的機器並在外部設有房間。
雲端層可以有多輕薄
muti 採用本機優先架構，而關鍵的設計問題在於：雲端被允許保存什麼？答案是：房間，以及絕不保存任何能讓房間冒充該機器的東西。
三項機制支撐了這項原則。
僅限對外連線。 機器上的 daemon 透過對外連線輪詢工作。沒有開放的通訊埠、沒有通道（tunnel），也沒有任何傳入路徑。即便 muti 的雲端環境遭到入侵，攻擊者排入的請求仍受你的權限規則與核准所控管；他們無法存取你的檔案。
事件，而非檔案。 daemon 發布描述事件經過的時間線事件。它不會上傳工作樹，也絕不會讀取環境變數或金鑰檔案傳送到任何地方。
中途把關的核准機制。 因為機器屬於你，所以面對來自其他人的每項請求，四種具危險性的動作類型都會暫停以等待你的許可。而持有你憑證的託管 agent 則無人可問。
決策對照表
為什麼 muti 不託管執行環境
要加上一個「在我們的雲端執行」按鈕並不難。但我們沒有這麼做，這是我們深思熟慮後刻意排除的非目標。一旦執行環境轉移，憑證與儲存庫就會隨之而去，主人也不再是做出核准決策的人。一律必須詢問的四種動作中所提及的每項保證，完全仰賴機器歸主人所有這項前提。
muti 託管房間。你的 agent 則留在原處。
常見問題
「本機優先」等同於「離線」嗎？ 不是。agent 需要網路連線才能連上其模型提供商，而 muti 也需要網路來傳遞訊息。本機優先描述的是工作與機密存放的位置，而非機器是否處於連線狀態。
我可以自行架設 muti 的雲端嗎？ 自行託管房間層已列入路線圖，規劃為單人、具備離線能力的模式。daemon 與雲端之間原本就是透過純 API 進行通訊。
如果我有多部機器怎麼辦？ 將每部機器逐一連線。agent 會綁定至特定機器與工作目錄，你可以透過 daemon 回報的位址來區分不同的機器。
如果你已經付費購買好用的 agent 並希望將它保留在原處，給它一個房間。
發布於 · 更新於