Tilde.run：將交易式檔案系統帶入 AI 代理沙盒環境

將自主 AI 代理部署到生產環境長期以來一直受到一個根本性的恐懼所阻礙：所謂的「流氓代理」情境。無論是意外刪除關鍵資料、未授權的網路呼叫，或是導致資料外洩的提示注入攻擊，賦予大型語言模型寫入檔案系統的權限所帶來的風險都相當重大。

Tilde.run 旨在透過將每一次代理執行視為類似資料庫的交易來解決此問題。結合隔離運算與具版本化、可組合的檔案系統，Tilde 讓開發者能在真實資料上釋放代理，同時保有可保證的復原路徑。

核心架構：可組合與版本化

Tilde 的核心是一個 Versioned Composable Filesystem。與提供空白環境或簡單卷掛載的傳統沙盒不同，Tilde 允許使用者將不同的資料來源——GitHub 倉庫、AWS S3 儲存桶與 Google Drive 文件——掛載到單一、統一的 ~/sandbox 目錄中。

這不僅僅是掛載的集合；它是一層具版本化的層級。每個檔案自首次提交起即具版本，任何代理的執行都能即時回滾。此做法利用了 lakeFS 的基礎，提供大型資料湖所使用的相同資料版本化功能，卻重新構想以符合 AI 代理快速、迭代的特性。

交易式執行

Tilde 將每一次代理執行視為一筆交易。當代理在全新、隔離的容器中啟動時：

1. Staging（暫存）: 所有檔案寫入皆先暫存。代理與真實的 POSIX 檔案系統互動，意味著它可以使用任何工具或語言，無需特定 SDK。
2. Atomic Commit（原子提交）: 在正常結束時，變更會以原子方式提交。
3. Rollback（回滾）: 若代理失敗或產生不理想的結果，整個執行將被丟棄。無需手動清理或還原備份。

安全性與治理

除了檔案系統之外，Tilde 實施多層次的安全策略，以防止自主代理最常見的失敗模式。

網路隔離

為防止資料外洩與憑證濫用，Tilde 預設阻擋雲端 metadata 服務、私有網路與未授權的主機。每一個外發請求皆會經過政策檢查與記錄，讓管理者能精確看到哪些 API 呼叫被允許或拒絕（例如，允許 api.openai.com 同時阻擋 evil-exfil.io）。

代理優先 RBAC

Tilde 引入細緻的基於角色的存取控制（RBAC）系統，將代理視為第一級公民。代理不再繼承啟動者的全部權限，而是透過可讀的 DSL 指派具範圍的權限。例如，分析師代理可能被授予對 CSV 的 READ 存取與對報告的 WRITE 存取，但明確 DENY 取得機密金鑰，且某些操作需經過人工批准。

技術討論與社群回饋

Tilde 的發布在開發者社群中引發了關於此類系統必要性與實作方式的激烈討論。

「標準工具」論點

一些批評者認為 Tilde 所提供的功能可以透過標準 Linux 工具來複製。正如某位使用者所指出的，許多此類防護措施可以利用 Linux 虛擬機與 chattr 設定資料夾為唯讀來實作。其他人則指出 S3 與 Git 已具備版本化功能，質疑統一層的額外價值。

狀態管理挑戰

一個反覆被提及的爭議點是檔案系統層級版本化的限制。雖然 Tilde 能回滾檔案變更，卻無法回滾外部 API 呼叫或遠端資料庫的變更。正如一位評論者所觀察到的：

"If the agent is not mutating state the change can be checked in. If it is mutating external state, version control won't save you."

永續性 vs. 暫時性

在代理工作流程中，對持續性狀態有明顯需求。一些開發者表示需要讓代理擁有一台具備持久儲存的「電腦」，能在多個會話間保持一致，而非僅限於交易式執行。這凸顯了絕對安全（暫時性交易）與類人持久性（有狀態環境）之間的張力。

功能概述

功能	Tilde 方法
檔案系統	可組合（GitHub、S3、Drive）且具版本化
執行	隔離容器，具原子提交/回滾
網路	預設拒絕政策，並審計外發請求
權限	代理專屬 RBAC，具人為審核
稽核	完整變更時間線，關聯特定代理或人員