技术深度剖析
Mirage 不仅仅是一个存储抽象层；它是一个从头开始构建的专用虚拟文件系统（VFS），旨在适应 AI Agent 独特的 I/O 模式。与传统的 VFS 层（例如 FUSE、Plan 9）不同，Mirage 必须处理 Agent 工作流中典型的高频、小型随机读写操作——想象一下，Agent 读取知识库片段，将部分结果写入临时缓冲区，然后追加到日志文件中——所有这些都在单次交互回合内完成。
架构与设计
在其核心，Mirage 实现了一个统一命名空间，将多个后端（S3、GCS、本地文件系统、SQL 数据库、键值存储如 Redis，甚至是 Notion 或 Airtable 等 SaaS API）映射到单个分层目录树中。每个后端都作为根目录下的子目录挂载，例如 `/mnt/s3/`、`/mnt/notion/`、`/mnt/local/`。这种映射是透明的：Agent 使用标准的 `open()`、`read()`、`write()`、`seek()` 和 `close()` 调用，Mirage 将这些调用翻译为适当的 API 请求或 SQL 查询。
| 后端类型 | 挂载点 | 延迟 (p50) | 延迟 (p99) | 吞吐量 (ops/sec) |
|---|---|---|---|---|
| Local SSD | `/mnt/local/` | 0.1 ms | 0.5 ms | 100,000 |
| S3 (same region) | `/mnt/s3/` | 5 ms | 20 ms | 5,000 |
| Notion API | `/mnt/notion/` | 150 ms | 500 ms | 200 |
| PostgreSQL | `/mnt/db/` | 2 ms | 10 ms | 10,000 |
数据洞察： 不同后端之间的延迟差异显而易见——本地 SSD 的速度是 Notion API 的 1,500 倍。Mirage 必须实施智能缓存和预取机制，以避免 Agent 推理循环被慢速后端阻塞。
关键工程挑战
1. 一致性模型： Mirage 默认采用弱一致性模型，特定路径可选强一致性。这是一种 deliberate 的权衡：Agent 通常为了速度而容忍最终一致性，但关键操作（例如写入检查点）需要立即可见性。Mirage 暴露了一个 `sync()` 调用，将所有待处理写入刷新到后端。
2. 缓存层： 多层缓存位于 Agent 和后端之间。热数据保留在内存 LRU 缓存中（大小可配置，默认 1 GB），温数据存储在本地 SSD 上，冷数据按需获取。缓存失效通过 TTL 处理，对于一致性敏感的路径则采用写透策略。
3. 并发控制： Agent 可能会生成多个子 Agent 或工具，并发访问同一文件。Mirage 实施了带有版本号的乐观锁。如果检测到写入冲突，后来的写入将被拒绝，Agent 必须重试。这比分布式锁更简单，且符合 Agent 的重试模式。
4. POSIX 子集： Mirage 不实现完整的 POSIX 规范。它省略了硬链接、符号链接（内部使用除外）以及 `chmod`/`chown`。重点在于 `open`、`read`、`write`、`seek`、`close`、`mkdir`、`rmdir`、`unlink` 和 `rename`。这个子集覆盖了 95% 的 Agent 用例，同时保持实现精简。
开源参考
虽然 Strukto 尚未开源 Mirage，但最接近的类比是 [agentfs](https://github.com/agentfs/agentfs) 项目（1.2k stars），这是一个针对 LLM Agent 的概念验证 VFS，将文件映射到函数调用。Agentfs 更简单——它使用基于 JSON 的虚拟目录——但缺乏 Mirage 的后端多样性和性能优化。另一个相关项目是 [fsspec](https://github.com/fsspec/filesystem_spec)（3.5k stars），这是一个用于抽象文件系统的 Python 库，但它不是为 Agent 工作负载设计的，也没有内置缓存或并发控制。
要点： Mirage 的技术差异化在于其特定于 Agent 的设计：弱一致性、乐观锁以及针对高频小型 I/O 优化的 POSIX 子集。这不是一个通用的 VFS；它是专为 Agent 运行时设计的专用层。
关键参与者与案例研究
Strukto：基础设施布局
Strukto 是一家相对较新的初创公司（成立于 2024 年，从匿名投资者那里筹集了 800 万美元种子资金），此前专注于 Agent 编排框架。Mirage 是他们在观察到客户将 40% 的工程时间花在存储集成上之后，向基础设施领域的 pivot。团队包括来自 Google FUSE 团队和 AWS S3 团队的前工程师。
竞争解决方案
| 解决方案 | 类型 | 后端支持 | 延迟 | 并发 | 开源 |
|---|---|---|---|---|---|
| Mirage | 虚拟 FS | S3, GCS, local, DB, Notion, Airtable | 低 (cached) | 乐观锁 | 否 |
| LangChain's BaseStore | 抽象 | S3, local, MongoDB, Redis | 中 | 无 (单线程) | 是 |
| AutoGPT's FileManager | 工具包装 | 仅限本地 | 低 | 无 | 是 |
| CrewAI's Storage | 工具包装 | S3, local | 中 | 无 | 是 |
数据洞察： 现有解决方案要么太窄（AutoGPT、CrewAI），要么缺乏并发控制（LangChain）。Mirage 是首个将存储视为统一基础设施层而非临时工具包装的解决方案，这为 Agent 的规模化部署奠定了坚实基础。