Blaxel Agent Drive

Hey everyone! 我是 Nico，Blaxel 的联合创始人之一。

智能体在文件里干实际活。两个沙箱需要共享这些工作时，尴尬就来了。团队经常要把产物搬到对象存储里，在每次运行之间重建上下文，或者再搞一个交接层。

我们做了 Agent Drive，给智能体一个共享的工作空间。

Agent Drive 是一个分布式文件系统，多个沙箱可以同时挂载它，并支持并发读写。一个编码智能体写产物，另一个审查智能体从别的沙箱读取它，两者都把这个 drive 当成文件系统里的普通路径。

演示展示了核心工作流程：
1. 创建一个 drive。
2. 挂载到两个沙箱。
3. 在一个沙箱里写文件。
4. 从另一个沙箱读取它。

底层上，Agent Drive 使用优化过的 FUSE 客户端，并内置了复制功能。你可以把 drive 附加到已经在运行的沙箱上，文件独立于任何单个沙箱会话持续可用。

Agent Drive 目前处于私有预览阶段。针对 Product Hunt，我们开放一个限量预览组。申请时告诉我们你的智能体需要共享什么。我们会在发布当天审核申请，并优先处理使用企业邮箱注册、有活跃多智能体工作流的团队。

我们特别希望听到那些跨智能体共享工具输出、数据集、代码产物、依赖缓存或上下文历史的团队的反馈。你们现在的智能体在尝试交接什么？

恭喜发布。你们怎么处理版本控制？如果下一次写入搞坏了，能轻松撤销并回退到上一个工作版本吗？

共享文件系统是智能体协作中不性感但正确的答案——大多数团队最终会用对象存储和拷贝步骤笨拙地重新发明一遍。对我来说，决定实际可用性的问题是并发语义：两个智能体写同一个文件时会发生什么？最后写入者胜出、类 POSIX 锁、还是类似 CRDT 的东西？多智能体管道的成败取决于下一个智能体是否可能读到半写文件。恭喜发布。

写入冲突前面已经提了，那我就说说我们遇到的那个问题。编码智能体会产生大量微小的 stat 和 readdir 调用，当我们把智能体工作区移到网络挂载上后，在一个中等规模 repo 上跑 ripgrep 直接从不到一秒变成每次都能感受到延迟。drive 前面有没有每个沙箱的读缓存，还是每次打开都会走到分布式层？

有意思。跨多个沙箱的并发读写访问，这种功能听起来简单，但两个智能体同时碰同一个文件时就麻烦了。如果一个编码智能体正在写产物，而审查智能体早了一点点打开同一个文件，那审查智能体实际看到的是什么——部分写入？一个让它等待的锁？还是 Agent Drive 能保证某种原子可见性，确保没人读到半成品文件？

另外也对失败情况好奇：如果挂载了 drive 的沙箱在写入过程中崩溃或被杀死，FUSE 层会不会干净地回滚那次写入，还是有可能会留下一个损坏或部分刷新的文件，等着下一个挂载它的沙箱读到？

多个智能体可以并发读写的共享文件系统，通常是靠 S3 加各种锁定 hack 手搓出来的，所以能把它做成一个原生功能挺棒的——当两个智能体同时修改同一个文件时，你们怎么处理写冲突？用乐观锁还是最后写入者胜出？另外我也好奇，相比单智能体场景下直接挂载本地卷，这个方案的延迟开销大概是多少。