Tilde 关停记：把 Agent 每次执行做成"事务"的沙箱，为什么被 lakeFS 收回
阅读时间: 大约 10 分钟
Tilde 关停记：把 Agent 每次执行做成”事务”的沙箱，为什么被 lakeFS 收回
在 Agent 基础设施这一波创业潮里，“给 Agent 一个安全的执行环境”几乎是所有人都在讲的故事。但绝大多数产品停留在”给你一个隔离的虚拟机/容器”。Tilde 走得更远一步：它把每一次 Agent 执行本身建模成一个数据库意义上的”事务”——所有改动要么原子提交，要么整体回滚，失败可以瞬时复原。这个由 lakeFS（数据版本控制公司）团队做出来的产品，在上线约一年后，于 2026 年 7 月 1 日正式宣布关停（tilde.run 现已 301 跳转到 lakeFS 的关停公告）。本文基于其关停公告、koala-oss 项目库与 lakeFS 官方文档，复盘它解决了什么问题、为什么没独立活下去，以及它的能力最终落到了哪里。
一、它到底想解决什么问题
Tilde 的出发点在关停公告里被一句话讲透：“给 Agent 一个 prompt 很容易；给它正确的文件、凭证、工具、上下文和执行环境，并且安全、可重复地给——这才难。”
具体来说，生产环境跑 Agent 有几个反复出现的痛点：
- Agent 需要同时碰到多源数据：代码在 GitHub、业务数据在 S3、文档在 Google Drive，跨系统复制来复制去既慢又容易漏；
- Agent 的写入不可控：它可能改错文件、写脏数据，而传统容器沙箱只做进程隔离，不帮你”撤销这次改动”；
- Agent 用的是用户的身份和凭证，权限过大，且出站网络完全放开，容易触发越权调用或数据外泄；
- 每次执行的状态不可复现，跑完一次实验换台机器就对不上了。
Tilde 给的答案是：把这些 concerns 全部收进一个统一的、带版本控制的沙箱文件系统里。
二、核心机制：事务化沙箱
根据 koala-oss 项目库对 Tilde 的记录，它的设计有四根支柱：
- 统一挂载的
~/sandbox：把 GitHub 代码仓库、S3 数据桶、Google Drive 文档统一挂载到一个本地~/sandbox路径下，Agent 像操作本地文件一样操作所有数据源，且整个挂载面带版本控制； - 事务语义：每次 Agent 执行是一个事务——期间所有文件改动、配置变更、中间产物都被记录；成功则”提交”，失败或人工判断不对则”整体回滚”到执行前状态，号称瞬时复原；
- 默认阻断的网络层：出站请求默认全部拦截，按策略（allowlist）放行，并完整记录每一次外部调用，用于审计；
- 最小权限凭证 + 审批门：给 Agent 单独发放 scoped（受限范围）凭证，不复用用户身份；关键高危操作还可挂人工审批。所有修改都带时间戳与归属，可查 diff、可回滚。
这套设计本质上是把 Git/数据库事务那一套”分支—提交—回滚”的心智模型，搬到了 Agent 的运行环境上。
三、为什么关停：教训是”文件系统比想象中更重要”
关停公告里 lakeFS 团队给出的反思相当坦诚，值得原文对照：
“最重要的教训是，状态（也就是文件系统！）比人们预期的重要得多。Agent 需要的不只是对象存储，它们需要快速的本地访问、可复现的状态、隔离、版本化，以及在不反复拷贝一切的前提下组合数据、代码、配置和中间产物的能力。”
于是团队决定：不再把 Tilde 作为独立产品运营，而是把这一年积累的经验折进 lakeFS Mount——一个为 Agent 工作负载设计的、agent-native 的可组合文件系统。换句话说，Tilde 不是被”做垮了”，而是被判断为”不该作为独立壳层存在，应该长在数据控制面里”。
四、继承者 lakeFS Mount：能力与口径边界
Tilde 的思想继承者是 lakeFS Mount（内部代号 Everest）。根据 lakeFS 官方文档，它是一个与 lakeFS 配套的二进制，能把远端 lakeFS 仓库虚拟挂载到本地目录或 Kubernetes 环境里，挂载后任何工具、库、框架都像访问本地文件一样访问数据。它针对 Agent 的运行特征做了优化：
| 维度 | lakeFS Mount 的官方口径 |
|---|---|
| 数据获取 | 惰性拉取（lazy fetch）：仓库即使有 PB 级，也不必预加载，Agent 像操作本地目录一样按需读 |
| 版本能力 | 复用 lakeFS 的 branch / commit / merge，Agent 在自己的分支上读写，可复现、可治理 |
| 结构化数据 | Enterprise 版提供 Iceberg REST catalog，表和 namespace 与文件一起版本化 |
| 部署形态 | 本地挂载二进制 + Kubernetes CSI driver（私有预览、只读） |
| 授权 | 仅面向 lakeFS Enterprise（cloud 或自管）客户，需联系销售开通 |
这里必须点出官方自己标注的口径偏差，避免被宣传话术带偏：
- “事务/可回滚”在 Tilde 时代是产品主打，但落到 lakeFS Mount 后，它的底层保证是数据版本控制（branch/commit/merge）层面的可复现与可回退，并不是传统数据库那种跨多步、强一致的 ACID 事务。Agent 在分支上写脏了，你可以丢弃分支重来，但这不等于”每次执行自动原子提交”；
- Kubernetes CSI driver 官方明确写着 private preview 且只读——也就是说在 K8s 里让 Agent 通过 CSI 做写入回滚，目前还不是 GA 能力；
- Mount 不是开源产物，属于 lakeFS Enterprise 商业组件，需要联系销售、签订企业协议才能拿到二进制。这与 Tilde 当年作为独立开发者产品的开放性不是一回事。
五、客观评价
价值：
- 它最早把”Agent 的执行环境”当作一个带版本与事务语义的数据对象来设计，这个判断在事后被证明是对的——今天 lakeFS、E2B 等都在往”给 Agent 一个版本化文件系统”上走；
- 默认阻断出站 + scoped 凭证 + 审批门，是 Agent 安全从”讲原则”到”有产品形态”的一次具体落地；
- 关停公告本身是高质量的工程复盘，公开承认”文件系统才是核心”，对整个 Agent infra 赛道有参考意义。
局限：
- 产品已不可用：tilde.run 已关停，现在没有任何新用户能”用 Tilde”，本文的价值在于复盘而非推荐选型；
- 独立产品形态被证明撑不住——约一年即收回，说明”在对象存储/数据版本控制之上再套一层通用 Agent 沙箱壳”的独立市场空间有限；
- 继承者 Mount 是 Enterprise 闭源组件，中小团队想获得类似能力，只能退而求其次用 E2B、Docker + 快照、或 lakeFS 开源核心自行拼装，体验打折。
六、适合谁看
- 正在设计 Agent 运行时/沙箱的基础设施团队：Tilde 的四根支柱（统一挂载、事务回滚、出站管控、scoped 凭证）是一份现成的 checklist；
- 需要把 Agent 接进企业数据治理体系的人：lakeFS Mount 代表”版本控制即 Agent 安全边界”的路线，值得与 E2B、Modal、Daytona 等横向对比；
- 关注 Agent infra 商业逻辑的研究者：一个”方向对但独立产品没跑出来、最终被收进数据控制面”的样本。