用Swift替換Bash：AI工具鏈的演進
開發者嘗試在個人AI代理框架中用Swift解釋器SwiftScript替換Bash腳本，實現更可控、更安全的工具執行環境，同時保留沙箱保護。
近日，一位開發者在其個人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的優勢和不足，以及沙箱問題的現狀。