Tilde.run：将事务型文件系统引入 AI 代理沙箱

将自主 AI 代理部署到生产环境长期受到一个根本性担忧的阻碍：所谓的“流氓代理”情景。无论是意外删除关键数据、未经授权的网络调用，还是导致数据外泄的提示注入攻击，赋予大型语言模型（LLM）对文件系统的写入权限所带来的风险都非常显著。

Tilde.run 旨在通过将每一次代理运行视为类似数据库的事务来解决此问题。通过将隔离计算与具备版本控制且可组合的文件系统相结合，Tilde 让开发者能够让代理在真实数据上自由操作，同时保持有保障的恢复路径。

核心架构：可组合且具备版本控制

Tilde 的核心是一种 具备版本控制的可组合文件系统。不同于提供空白环境或简单卷挂载的传统沙箱，Tilde 允许用户将不同的数据源——GitHub 仓库、AWS S3 存储桶以及 Google Drive 文档——挂载到单一的统一 ~/sandbox 目录中。

这不仅仅是挂载的集合；它是一个具备版本控制的层。每个文件从首次提交起即拥有版本，任何一次代理运行都可以瞬间回滚。此方法基于 lakeFS 的底层技术，提供了大型数据湖使用的相同数据版本控制能力，但重新构想以适应 AI 代理快速、迭代的特性。

事务性执行

Tilde 将每一次代理执行视为一次事务。当代理在全新、隔离的容器中启动时：

1. 暂存（Staging）： 所有文件写入都会被暂存。代理与真实的 POSIX 文件系统交互，这意味着它可以使用任何工具或语言，而无需特定的 SDK。
2. 原子提交（Atomic Commit）： 在干净退出时，变更会原子性提交。
3. 回滚（Rollback）： 如果代理失败或产生不良结果，整个运行将被丢弃。无需手动清理或恢复备份。

安全与治理

除了文件系统之外，Tilde 实施了多层安全策略，以防止自主代理最常见的失效模式。

网络隔离

为防止数据外泄和凭证滥用，Tilde 默认阻止云元数据服务、私有网络以及未经授权的主机。每个出站请求都会进行策略检查并记录，管理员可以准确看到哪些 API 调用被允许或拒绝（例如，允许 api.openai.com 而阻止 evil-exfil.io）。

代理优先的 RBAC

Tilde 引入了细粒度的基于角色的访问控制（RBAC）系统，将代理视为一等公民。代理不再继承启动它们的用户的全部权限，而是通过可读的 DSL 分配范围化的权限。例如，一个分析员代理可能被授予对 CSV 的 READ 访问和对报告的 WRITE 访问，但明确 DENY 对机密密钥的访问，并且某些操作需要人工审批。

技术讨论与社区反馈

Tilde 的发布在开发者社区中引发了关于此类系统的必要性和实现方式的激烈讨论。

“标准工具”论点

一些批评者认为 Tilde 提供的功能可以使用标准 Linux 工具复制。正如一位用户所指出的，许多此类防护措施可以通过 Linux 虚拟机和 chattr 将文件夹设为只读来实现。还有人指出 S3 和 Git 已经具备版本控制，质疑统一层的附加价值。

状态管理挑战

一个反复出现的争议点是文件系统级别版本控制的局限性。虽然 Tilde 能回滚文件更改，但无法回滚外部 API 调用或远程数据库的变更。正如一位评论者所观察到的：

“如果代理没有改变状态，则可以提交更改。如果它在改变外部状态，版本控制也帮不了你。”

持久性 vs. 短暂性

在代理工作流中对持久状态有明确需求。一些开发者表达了希望代理拥有一个带有持久存储的“计算机”，能够在多个会话之间保持一致，而不仅仅是事务性运行。这凸显了对绝对安全（短暂事务）与类人持久性（有状态环境）之间的矛盾。

能力概览

特性	Tilde 方法
Filesystem	可组合（GitHub、S3、Drive）且具备版本控制
Execution	隔离容器，具备原子提交/回滚
Network	默认拒绝策略，审计出站调用
Permissions	针对代理的 RBAC，带有人为审批环节
Audit	完整的变更时间线，关联特定代理/人员