用Swift替換Bash：AI工具鏈的演進

近日，一位開發者在其個人AI代理框架（AI Harness）中進行了一項有趣的實驗：用Swift語言替換原本的Bash指令碼作為工具執行引擎。這一想法源於對TypeScript成為智慧體程式語言主流的不滿，以及對Swift潛力的堅信。

此前，該框架已用Bash替代了檔案工具箱，以簡化與系統互動的方式。而現在，更進一步地，作者希望讓模型直接編寫Swift程式碼，而不是Shell指令碼。

最直接的實現方式是保留原有框架，僅將Bash工具替換為Swift工具，讓模型編寫頂層Swift程式碼，然後透過編譯器執行。但這種方法存在明顯缺點：每次執行都需要啟動編譯器，速度較慢，且與Bash類似存在安全問題。此外，編譯過程會引入模組快取等複雜行為，不夠輕量。

因此，作者選擇了另一個方案——使用SwiftScript。這是一個樹遍歷（tree-walking）的Swift直譯器，可以作為庫嵌入到應用中，無需編譯步驟。透過將其嵌入框架，Swift工具不再是一個子程序，而是框架本身的一部分。

為了控制執行環境，作者引入了另一個庫ShellKit。ShellKit允許嵌入者自定義Shell的輸入輸出、工作目錄和沙箱策略。在執行Swift程式碼時，直譯器的輸出透過ShellKit的橋接層路由到自定義的stdout/stderr，檔案操作受限在指定目錄內，且無法訪問.git等敏感檔案。

這種設計比Bash更安全。因為執行模型從“提供一個Shell，隨意執行”轉變為“提供一個由我們託管的直譯器，並暴露我們選擇的執行時環境”。框架可以精細控制模型能做什麼，例如只能讀寫工作區、使用者級技能目錄和臨時目錄，允許網路請求，但禁止訪問.git或任意系統路徑。

當然，這並不意味著完全消除了安全風險。ShellKit的沙箱是程序內策略層，並非作業系統強制執行的沙箱。作者也考慮過將直譯器放入獨立程序，然後用Seatbelt包裝，但為了保持學習框架的簡單性，暫時未採用。

實際測試中，該方案表現良好。模型可以呼叫Swift工具執行計算、讀取檔案、檢視目錄內容等。例如，執行print(40 + 2)輸出42，或者透過Foundation框架獲取工作區檔案資訊。當嘗試逃逸沙箱（如寫入../escape.txt）時，會收到“file URL is outside the Swift tool sandbox”的錯誤，這正是期望的行為。

儘管SwiftScript由個人開發，某些API尚不完整，但已足以證明概念：Swift作為模型可使用的“單一工具”語言，比Bash更受控、更安全。作者總結道，這次實驗並非完美答案，但它誠實地展示了Swift的優勢和不足，以及沙箱問題的現狀。