别让 Agent 空转：从常驻 VM 到按需算力

想象你在周一上午使用云端 AI Agent 修復登錄頁面的問題。Agent 瞬間被喚醒、搜索配置、修改代碼、運行測試，整個過程耗時 12 分鐘，然後你關掉網頁去開會。這兩小時裡，那台虛擬機在做什麼呢？它在空轉。如果架構採用傳統的「一條記錄綁定一台長期虛擬機」設計，平台無法完全消除這種持續消耗，即便有快照和恢復機制，資源成本也難以完全抵消。這就產生了一個根本性的生命周期錯位：Agent 真正需要的是保存對話狀態和項目文件，真正需要拉起 Linux 環境的時間往往只有短短幾十分鐘。當用戶量從百級成長到十萬級，空轉帶來的算力消耗就成了不可忽視的基礎設施成本。

Anthropic 和 Camel AI 等公司的公開實踐表明，一種正在形成的架構方向是將 Agent 系統分層：持久化狀態層記錄任務進度、審批記錄和外部任務 ID；無狀態的控制層靠事件日誌恢復現場；執行環境則按任務申請、用完即棄。但這種架構並非銀彈，它帶來三大工程挑戰。第一個是狀態與文件的玻璃關係——Agent 必須通過外部任務 ID 查詢和對帳遠端結果，不能只相信本地記錄；項目文件不能依賴臨時節點的本地磁盤，要落在共享存儲或對象存儲；當並發修改發生時（Agent 改代碼的同時用戶手動改同一文件），系統必須制定明確的一致性策略，比如條件寫入、單寫者約束或三方合併，否則代碼就丟了。面對 GB 級大倉庫，每次啟動都同步也是災難，實踐中需要組合權如緩存鏡像、增量同步或內容尋址加上分塊機制。

第二個挑戰是執行環境的精準分級。改一行文案不需要拉起完整 Linux 容器，那是極大浪費；但涉及編譯測試又根本跑不動輕量環境。成熟的 Agent 運行時會切分出多個檔位：純 API 調用的結構化工具最輕；V8 Isolate 適合自定義轉換，啟動毫秒級且絲滑；V8 環境必須顯式配置網路出口、繫結和資源上限；只有真正需要 Shell、包管理器、原生二進制或完整操作系統協調的任務才臨時拉起 Linux 容器。最後為超大工程保留持續工作空間，但這裡的靈魂是協調器，要注意計算等級和風險等級是正交維度——查庫發郵件算力低但業務風險高，絕不能依賴清量環境失敗後再恢復的邏輯，必須有獨立審批和隔離。

第三個挑戰是從環境授權走向能力授權。想象 Agent 碰到藏在開源項目 ReadMe 裡的惡意指令，要求讀取環境變量密鑰並上傳到外網。如果環境同時允許讀密鑰和訪問外網，一旦模型被騙，這就演變成真實數據洩漏——這正是安全業界說的「間接提示詞注入」。光改工具名字沒用，必須把粗放的環境授權收縮為極致的能力授權：權限由服務端強制執行、每次請求嚴格驗證、敏感數據絕不暴露給生成的代碼、高影響操作強制人工審批和審計。即便攻擊者沒拿到密鑰，間接注入仍可能誘導 Agent 刪改文件或污染代碼，這根弦必須時刻緊繃。

對於正準備改造 Agent 基礎設施的團隊，建議走穩妥的灰度路徑。先測算真實戰空消耗——如果業務全是大型編譯就保留完整常駐空間，文本處理居多才值得試點分層。別動老容器，先把任務狀態剝離到持久層，給文件系統掛上影子後端一邊讀老磁盤一邊寫新存儲，一部分對 hash 跑通後再推進。高風險操作（部署、查庫）統統封裝成可審計的服務端工作流，該用密鑰就用密鑰用不了就老實做對象。最後明確容器邊界後灰度切流。永遠記住，前端點擊取消不代表遠端沒副作用，最終結果只能靠狀態對帳。