代理控制環應置於沙盒之外

背景

隨著 AI Agent 技術的快速發展，開發者對於「Agent Harness」（代理控制環路）的架構設計產生了分歧。所謂的 Harness 是驅動大語言模型的循環機制，負責發送提示詞、解析工具調用並回傳結果。本文探討了將 Harness 置於沙盒內部與外部的兩種架構，並主張在多用戶環境下，將 Harness 移至沙盒外能提供更好的安全性、憑證管理與資源調度效率。

社群觀點

在 Hacker News 的討論中，社群對於「Harness」的定義與必要性展開了激烈的辯論。部分開發者認為這個術語本質上就是早期的「編排層」或「REPL」概念，只是在 Agent 時代被重新包裝。支持者如 aluzzardi 指出，Harness 就像是除去模型後的代理軀幹，包含工具、記憶與轉向控制，將其移出沙盒是為了應對模型能力的快速演進，讓模型能自主驅動工作流而非被困在沉重的硬編碼代碼中。

然而，安全性是爭議的核心。反對者認為將 Harness 置於沙盒外會模糊安全邊界，若 Harness 本身存在漏洞，LLM 可能會誘導 Harness 執行非預期的操作。有觀點指出，開發者不應信任 Harness 超過信任 LLM，理想的架構應該是將安全約束交給一個獨立的「安全層」或類似虛擬機監視器的機制，而非依賴 Harness 自身的邏輯。此外，對於將 API 調用移出沙盒的作法，部分留言者表示擔憂，認為這可能導致憑證洩漏或被濫用，主張應該建立多層沙盒：一層用於執行實驗性代碼，另一層用於工具調用，並透過防火牆限制 Agent 的請求權限。

在多用戶協作與狀態一致性方面，社群也提出了質疑。原文提到的共享記憶體雖然解決了分佈式文件系統的問題，但留言者指出，多個 Agent 同時寫入共享數據庫可能導致混亂與衝突。有人認為「狀態過時」在某些場景下反而是種保護機制，類似 Git 的分支管理，能強制執行衝突解決流程，而非讓 Agent 隨意覆蓋彼此的記憶。此外，對於追求開發效率的個人用戶來說，過於複雜的沙盒架構可能被視為過度工程，因為 Agent 的強大之處往往在於其能直接存取現有的開發環境。

延伸閱讀

在討論中，開發者提到了幾個值得關注的工具與資源。Inngest 被用於處理長達數小時的 Agent 循環任務，確保在伺服器重啟時能實現持久化執行。Blaxel 則被提及用於解決沙盒冷啟動問題，能提供極速的恢復時間。此外，exe.dev 的 Shelley 被作為另一種架構參考，它將 Agent 運行在 Linux 虛擬機中，並透過 SQLite 管理對話歷史。對於想要深入了解 Harness 概念演進的人，Mitchell Hashimoto 關於此主題的論述也被視為重要的行業參考。