智能體也需要一張回程票

筆記本合上了，智能體還在工作。聽起來只是省了一點麻煩，直到你追問：跟着它搬到雲端的，究竟是什麼？

代碼？沒做完的任務？讀取倉庫的權限？還是發佈成果的權力？這些是不同的乘客。給它們同一張登機牌，可能換來一筆意外昂貴的糊塗賬。

結論很簡單：智能體也需要一張回程票。 遷移長任務之前，先說明它到達目的地後擁有什麼權限、權限如何終止，以及哪些證據必須帶回來。有價值的產品，是在約定邊界內產出的可審閱成果。連續工作了多少小時，單獨看並沒有那麼大的解釋力。

Docker在9月24日發佈Cloud Sandboxes，讓這個問題變得及時。公司將其描述為運行在Docker託管算力上的microVM環境，可通過與本地相同的命令行界面使用。這是廠商的產品說明，不是我出具的安全認證。Docker announcement

行李箱與護照

想象一家小軟件公司，只有一位創始人，外加一個熱情十足的編程智能體。任務很普通：更新公開演示項目，運行測試，準備補丁。創始人想合上電腦去喫飯，智能體想安裝三十樣東西。雙方的訴求都可以理解。

在筆記本上，一些邊界可能早已藏在環境配置裏。智能體只能看到特定工作目錄；某些憑證在它夠不到的地方；本地服務有熟悉的地址。創始人可以隨時中斷進程、檢查文件。任務搬走後，這些假設成立的環境也跟着變了。

行李箱裝的是任務狀態：源文件、中間結果、日誌，以及恢復工作所需的上下文。護照代表授權：能用哪些資源、能產生哪些實際效果、授權有效多久。行李完好抵達，並不能證明護照在目的地仍然有效。

Docker的對比文檔給出了具體區別：本地與雲端沙箱使用不同的祕密存儲和網絡策略，本地策略不會自動複製過去；雲端任務也無法訪問主機路徑。因此，界面相同，並不能證明實際訪問能力相同。Local and cloud comparison

這個區別對買家很有用。它把模糊的遷移承諾，變成一個能回答的問題：請展示這個目的地，在這套配置下，究竟能接觸哪些資源。

權限裏必須有動詞

目的地地址只是權限的一部分。讀取倉庫、提出修改、刪除倉庫，都可能發生在同一個服務上。如果權限審查只寫下服務名稱，最有後果的那部分決定就可能消失了。

回到想象中的演示項目。讀取公開文檔符合任務；在臨時工作區裏準備補丁，也符合任務。以公司身份發佈一個版本，則是另一個實際效果。下午工作得很出色，並不會讓智能體自動從研究員升任發佈負責人。

我會用允許產生的效果來描述任務：獲取指定公開輸入，修改任務專屬副本，交回補丁和測試報告。這個返回包就是產品。如果還要對外發布，就應有對應的既有授權，明確目的地和發佈程序。

Docker的Kit Specification v3公告介紹瞭如何把智能體環境與聲明的能力打包成OCI鏡像，示例可以區分HTTP方法與路徑。聲明讓審閱者有具體內容可看；適用的策略，仍需由實際運行環境執行。Kit specification announcement

由此可以養成一個操作習慣：比較兩臺機器之前，先比較兩份授權。搬遷一個只需要更少權限的任務，可以很容易。搬遷一個悄悄繼承更多權限的任務，也可能容易得令人誤判。

沒聽見告別的進程

委託最有意思的部分，往往出現在歡迎儀式之後。有人取消任務、撤銷憑證，或發現原來的授權太寬。問題從“智能體能否開始”，變成“它現在還能不能行動”。

Docker的9月21日版本說明披露了一項已修復問題：OAuth或API-key憑證被撤銷後，正在運行的代理仍可能保留授權，直到沙箱重建。這裏說的是歷史缺陷及廠商報告的修復，既不能據此認定當前版本仍有同一問題，也不能聲稱我們已測試所有撤權路徑。Release notes

這個教訓容易被忽略，因為兩個屏幕可以很客氣地各說各話。管理界面顯示權限已經結束，另一處的進程卻仍持有可用授權。整潔的設置頁面，此時更準確地描述了意圖，而非真實行為。

如果做驗收，我會先讓一個無害請求在測試服務上成功，再沿正常控制路徑撤銷測試授權，隨後讓同一個仍在運行的工作進程重試。關鍵觀察是：撤權之後，它實際上還能做什麼。先把一切重啓，再測一次，回答的就是另一個問題了。

這只是擬議測試，我沒有對Docker執行它。測試需要可丟棄憑證，以及專為無害檢查設計的服務。拿生產密鑰來試，等於給一場討論如何限制實驗邊界的談話，額外塞進一個完全沒必要的實驗。

成果必須有路回家

雲端是執行工作的地方，不應成為所有者唯一能夠查明發生了什麼的地方。在這個例子裏，創始人最終要的是補丁、準確的起始版本、真正執行過的測試，以及仍未解決的限制。一句“一切順利”，只是附信。

回程票，就是關於這些證據的一份小合同。開始之前，說明預期文件及接收目的地；結束之後，驗證收到的文件就是約定成果。如果任務在交付前終止，執行或許結束了，價值卻還懸着。

Docker雲端文檔說明，這項支持仍處於實驗階段，需要有效訂閱和雲端專用憑證。文檔也提醒，沙箱到期時，可恢復的沙箱可能被停止，其他沙箱可能被刪除。因此，要依賴無人值守任務，先弄清留存規則。Cloud documentation

這引出一個更普遍的設計選擇。只在最後導出，意味着全部成果都押在最後一步上。長任務可以用中間檢查點降低恢復成本。檢查點應保存任務證據，排除不必要的憑證；把整個環境複製回來，反而違背了縮小返回包範圍的初衷。

成果還需要一個讀者。一千頁日誌可能在技術上可訪問，在運營上卻幾乎不可用。簡短結果、一條可復現的驗證命令、一項說清楚的例外，往往是更好的交接，詳細記錄則保留在後面供查閱。

回執應把什麼分開

我會給這個虛構項目列五行狀態：輸入已確定、工作已執行、檢查已通過、成果已收到、發佈已獲授權。每行回答不同的問題。分開記錄，才能避免一次測試成功，被說成用戶已經收到結果。

例如，補丁可以已經完成，而測試因公開依賴不可用，尚無定論。正確回執應保存補丁，並指出缺的是哪項檢查。扔掉補丁，會丟失有用工作；宣佈全部通過，則會虛構有用工作。

另一個情況更微妙。工作進程完成測試並導出文件包，接收方卻發現它基於另一版代碼。雙方可能都正常運轉，卻在討論不同的工作。回執需要輸入和輸出的身份標識，讓所有者能定位分歧。

Docker的使用指南列出了文件傳輸與沙箱生命週期操作。這些機制是交付的組成部分，卻不會替某家公司決定成果是否達到驗收標準。這個判斷應寫進任務合同。Cloud usage guide

下圖是我的概念框架，刻意保持簡單：確定目的地授權，執行有邊界的任務，帶回可識別的成果，再驗證它。撤權與到期留存始終要考慮在內。圖中沒有任何實測的廠商性能結論。

無人值守工作的真實價格

智能體演示中最吸引人的數字，往往是連續工作且不被打斷的時長。創始人需要另一個數字：拿到一個合格成果的總成本，包括算力、模型調用、人工審閱、失敗嘗試及恢復。長時間執行，可能有生產力，可能浪費，也可能只是還沒做完。

假設兩套虛構安排產出同樣合格的補丁。一套很快結束，卻需要花很久追查文件從哪來；另一套慢一些，卻清楚列出相對已知起始版本的變化。如果不計審閱和恢復，第一套就可能因為錯誤的原因顯得便宜。

這裏還有排隊問題。啓動許多工作進程，只有在有人或某個機制能評估其輸出時纔有用。如果審閱能力固定，輸出卻越來越快，公司可能積累大量尚未驗收的工作。屏幕上的任務徽章一片綠，創始人的晚上卻被標籤頁塞滿。

這些分析沒有證明雲端執行比本地更貴。它們說明比較需要怎樣做：使用相同任務、相同驗收條件，以相同方式計算失敗嘗試，並計入獲取和理解證據的時間。否則，比較的是不同產品。

投資人對應要問的是廠商的持久價值：服務是否降低客戶的總監督負擔？是否讓困難工作變得可行？客戶是否因為合格成果改善而續約？發佈公告無法獨自回答這些問題，方便的遷移界面也只是其中一環。

一個小型驗收練習

這位虛構創始人不需要複雜試驗，也能學到有用的東西。選一個公開倉庫，安排一項正確性容易檢查的有限修改，明確起始版本、允許的輸入、可寫輸出目錄、預期補丁，以及一條確定性的測試命令。無須客戶信息。

比較環境之前，先凍結驗收條件。正常執行必須交回預期成果、輸入身份及實際測試結果。被拒絕的目的地應繼續不可訪問。測試授權撤銷後，已運行的進程必須在事先聲明的操作時限內失去對應能力。時限應預先選定並實際測量，這篇文章沒有虛構任何耗時結果。

然後，一次只引入一種中斷。讓操作員斷線；在一次可丟棄的測試中，讓任務觸及留存期限；中斷返回傳輸，再檢查接收方是否能分清半成品與完整包。這些是不同故障，立刻混在一起，只會讓證據更難解釋。

記錄每個嘗試，包括失敗和根本未能運行的情況。兩種環境使用相同工作與審閱規則。如果試驗需要超出任務範圍的權限，就停止。一個有用結論也可能只是清楚的限制：這類流程能順利遷移，那個依賴則需要另一種設計。

這項提案尚未執行。我閱讀了所引文檔，並形成驗收規格；沒有衡量遷移可靠性，沒有運行雲端任務，沒有開通付費賬戶，也沒有測試生產憑證。這些邊界很重要：好問題本身就有價值，無須假裝成已完成的實驗。

出發前，先把合同說清

下一個有用里程碑並不宏大：工作進程帶着具名任務出發，在可審查的目的地授權範圍內運行，交回所有者能夠驗證的成果。權限結束時，它應失去對應行動能力；執行結束時，證據應按約定留存。

隨着這個市場發展，我會觀察四件事：聲明是否變成真正的運行時控制，撤權是否觸及現有進程，成果能否經受中斷交接，以及每個合格成果的總成本是否改善。每一項都需要自己的證據，成功展示其中一項，不能替其他項結案。

對創始人，眼下的行動是在選擇遷移路徑之前保存這張驗收卡。對評估供應商的讀者，請對方展示一次完整旅程，包含返回過程和一次受控失敗。答案應說明哪裏成功、哪些資源仍不可訪問，以及什麼還需要人作決定。

理想的未來其實很普通：筆記本合上，智能體工作，可審閱的成果送達。創始人安心喫飯，無須順手接管一個看不見的運維部門。這個目標比讓機器忙整夜更好，也足夠明確，可以拿來測試。

分類與關鍵詞

分類： 智能體基礎設施；系統工程；企業軟件。

關鍵詞： 雲端沙箱；有效權限；憑證撤銷；成果返回；合格成果。

Hashtags: #AgentInfrastructure #SystemsEngineering #EnterpriseAI #IAmRobin