在 AI agent 从实验室走向生产环境的过程中，如何在不放弃真实数据访问权限的前提下确保行为可逆、过程可审计，成为工程化落地的核心挑战。Tilde.run 作为专注于 AI agent 沙箱的基础设施产品，将版本化存储、隔离计算与网络审计三层能力深度整合，其中事务性版本化文件系统构成了整个架构的可逆性基础。本文从实现机制出发，解析其如何为 agent 提供原子操作、回滚与快照能力，并给出关键的工程化参数建议。
事务性版本化文件系统的核心抽象
传统容器化沙箱为 agent 提供的是标准可写文件系统，agent 的所有写入操作直接作用于底层存储，一旦执行完毕或容器销毁，变更即被永久覆盖或丢失。这种模型下，agent 的破坏性操作难以被恢复，也没有结构化的历史记录可供审计。Tilde.run 的设计思路是将文件系统视为一种版本数据库而非裸存储，所有写入操作被纳入会话（Session）这一事务上下文中进行管理。
具体而言，agent 的工作目录被挂载为 /sandbox，呈现为普通的 POSIX 文件系统，但底层实现为版本化对象存储。当 agent 执行写入时，变更首先进入暂存区（staging area），形成一组差异记录（diff）。只有在显式提交（commit）时，这些差异才会作为原子操作被写入生产版本链。如果 agent 执行过程中出现异常、产生不符合预期的结果，或者人类审核者拒绝批准变更，整个会话可以被整体回滚（rollback），文件系统瞬间恢复到会话开始前的状态。这种模型与 Git 的暂存区与提交机制高度相似，但针对 AI agent 的高频、自动化操作场景进行了工程优化。
版本化存储的另一个关键特性是完整的审计链条。每一次提交都会记录执行者身份、提交时间、变更说明以及完整的差异内容。管理员可以随时回溯到任意历史版本，查看特定时间点的文件状态，或者比较不同版本之间的差异。这种能力使得 agent 的行为变得完全可追溯 —— 当生产环境出现异常时，可以快速定位是哪个 agent、在哪次执行中引入了什么变更。
原子提交与回滚的工程实现
原子提交（atomic commit）确保了一组文件变更要么全部成功应用，要么全部不应用。在 AI agent 的实际场景中，一个典型的任务可能涉及读取配置文件、修改数据、生成输出文件等多个步骤。如果在执行中途出现错误，不加控制的文件系统会留下部分写入的中间状态，导致数据不一致。Tilde.run 通过会话级事务解决了这一问题：agent 在会话内的所有写入操作被视为一个整体，只有在会话正常退出且审核通过后才会被提交；如果会话异常终止或被回滚，所有暂存的变更都会被丢弃，文件系统保持原子性。
回滚机制支持两种粒度。第一种是会话级回滚，即取消当前会话内的所有未提交变更，使文件系统恢复到会话启动时的状态。第二种是版本级回滚，即从历史提交中拣选特定版本，将其作为新的 HEAD 状态，这相当于文件系统层面的 “时间倒流”。版本级回滚常用于生产事故恢复场景 —— 当 agent 的某次提交引入了破坏性变更时，运维人员可以在几秒钟内将系统恢复到上一个健康状态，而无需手动排查哪些文件被修改、修改内容是什么。
快照（snapshot）能力是版本化存储的自然延伸。每次提交都自动生成一个不可变的文件系统快照，包含提交时刻的完整状态。快照可以被读取、克隆或用于创建新的分支会话。这种设计使得 agent 可以安全地试验风险操作：先为当前状态创建一个快照，然后在快照的基础上执行实验性任务，如果实验失败则直接丢弃快照对应的会话即可，原始版本毫发无损。
沙箱集成与可落地参数建议
事务性版本化文件系统并非独立存在，而是与沙箱计算层、网络隔离层紧密协作。在沙箱启动时，版本化存储卷被挂载到容器的 /sandbox 路径，agent 在容器内看到的是一个普通文件系统，但所有写入操作都被自动拦截并重定向到会话的暂存区。这种透明化处理意味着 agent 无需修改任何代码即可使用版本化能力 —— 无论是使用 Python 的 open()、Node.js 的 fs 模块，还是 shell 脚本的 > 重定向，操作都会被事务层拦截。
在实际部署中，以下参数值得特别关注。会话超时时间（session timeout）建议根据 agent 任务的典型执行时长设置，默认值通常为 30 分钟，但对于涉及大规模数据处理的批式任务可能需要延长至 2 小时以上，同时应配套设置最大暂存空间（staging quota）以防止恶意 agent 产生过大的暂存差异。提交前审核（pre-commit approval）开关建议在生产环境保持启用，尤其是当 agent 被授权操作真实业务数据时，人类审核者可以在变更被应用前检查差异内容是否符合预期。网络隔离策略应默认阻断所有 RFC1918 私有地址、链路本地地址以及云元数据端点，确保 agent 无法通过文件系统中的凭证访问内部服务。
对于需要与外部系统集成的场景，Tilde.run 支持将 S3、Google Cloud Storage 或 GitHub 仓库直接挂载为只读源，agent 可以在会话内直接读取这些外部数据而无需将其复制到版本化存储中。这种设计既保证了数据的新鲜度，又避免了外部系统状态被 agent 意外修改的风险。
事务性版本化文件系统为 AI agent 提供了一种从根本上可预测的执行环境。通过将每一次 agent 操作封装为可提交、可回滚、可审计的事务，基础设施层面消除了大量由 agent 不可逆行为引发的生产风险。随着 AI agent 在数据处理、代码生成、业务流程自动化等场景的深度渗透，这类具备事务语义的基础设施将从 “可选项” 演变为 “必选项”。Tilde.run 的实践表明，将成熟的版本控制理念引入 agent 沙箱，不仅在技术上可行，而且在工程上已经具备生产级可用性。
资料来源：Tilde 官方文档（https://docs.tilde.run）