用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的优势和不足，以及沙箱问题的现状。