Mirage：把 S3、Slack、Redis、GitHub 都伪装成文件，给 Agent 一个虚拟终端
阅读时间: 大约 8 分钟
Mirage：把 S3、Slack、Redis、GitHub 都伪装成文件，给 Agent 一个虚拟终端
MCP 火了之后，整个行业都在想「Agent 接外部世界的更优雅姿势」。Strukto 的 Mirage 给了一个取巧的答案：既然 LLM 早就学会了 bash，那就把所有外部服务都伪装成文件。S3、Google Drive、Slack、Gmail、Redis、Postgres、GitHub 全部挂到同一个根目录下，Agent 用熟悉的 ls、grep、管道、重定向就能跨服务操作。本文基于其官网做分析。
一、核心思路：一切皆文件
Mirage 自称「世界第一个面向 AI Agent 的虚拟终端」。它不是再发明一套工具调用协议，而是把异构后端统一成一个 Unix 风格文件系统：
const ws = new Workspace({
'/tmp': [new RAMResource(), MountMode.EXEC],
'/redis': [new RedisResource({ url: redisUrl }), MountMode.WRITE],
'/slack': [new SlackResource({ token: slackToken }), MountMode.EXEC],
}, { runtimes: [buildRuntime('monty', { captures: ['python'] }), 'vfs'] })
await ws.execute('grep -rln session /redis /tmp') // 一条 grep 扫所有源
await ws.execute('python3 /slack/report.py > /redis/report.txt') // Slack 里的脚本，输出写进 Redis于是一个挂载的 Slack 频道可以像目录一样被 grep，它的输出重定向进 Redis，再由一个虚拟 CLI 读回来——全在一行 Agent 本来就会写的 shell 命令里。
二、四层架构
官网把它拆成四块：
- 统一 VFS：S3、Google Drive、Slack、Gmail、Redis 等并排挂在一个根下，Agent 用
ls/grep/find/jq访问；脚本和虚拟运行时里的 Python 看到的是同一个根； - 虚拟 CLI：
git、slack、ntn等命令注册在 workspace 里而不是装在机器上，Agent 不用装任何东西就能驱动各服务；同一个工具还能虚拟化出多份、各自带不同凭据； - 虚拟运行时：命令不固定在哪跑——Python 可以用 Monty 在进程内跑，
kubectl可以经 SSH 发到远程机器，甚至每行命令由一个脚本化的 runtime router 动态决定在哪执行； - Shell 是胶水：把虚拟 CLI、文件系统操作、管道/重定向/变量/作业/历史绑成一条命令行。
三、安全：策略引擎挡在每条命令前面
因为 Agent 能读写 Redis、Slack、Gmail，放开就是灾难。Mirage 的做法是一个脚本化策略引擎，跑在虚拟终端里每条命令之前：
- 决定哪些命令允许、哪些要询问、哪些直接拒绝；
- 决定这条命令路由到哪个运行时执行；
- 依据是命令本身、它触碰的路径、以及这些路径背后的虚拟文件系统。
配合挂载时的 MountMode（EXEC/WRITE 等）与 profiles（不同 Agent/环境套不同配置），它试图把「Agent 能碰什么、在哪跑」做成可审计、可拒绝的边界。
四、必须自己想清楚的代价
「伪装成文件」有性能与语义代价。Koala 点评点到了：把 Slack 消息列表目录化、把 Redis key 映射成路径，意味着每次
grep背后是一串 API 调用，不是真的本地文件 IO。跨服务grep -r可能触发大量 API 请求、撞上限流、烧 token。文件语义和服务 API 语义之间的缝隙（Slack 的频道 ≠ 目录）会在边界 case 上咬人。运维复杂度。一个统一虚拟终端听起来优雅，但底下要管 N 个凭据、N 个运行时、一套策略 DSL、以及工作区快照/克隆/回滚（官网支持工作区像 Git 一样快照、打包 tar 跨主机迁移）——这本身就是个不小的系统。
和 MCP 的关系待厘清。它是「用 shell 代替 MCP 工具」的路线，优点是 Agent 即插即用（LLM 懂 bash），缺点是把结构化的工具调用降级成了文本 shell，错误处理与参数校验不如类型化 MCP 工具。这是个设计取舍，不是免费午餐。
项目早期：官网 3.7K star，npm 包分 node/browser 两版，生态与文档仍在完善；作为 Agent 的「手脚」，它的稳定性直接决定 Agent 能不能放心用。
五、适用与不适用场景
适合： 想让 Agent 用 shell 统一跨 S3/Slack/Redis/GitHub 操作、不想为每个服务接一套 MCP 的团队；已经在用 bash 驱动 Agent、追求「零学习成本接入外部世界」的人；需要按命令粒度做权限审批与运行时路由的场景。
不适合： 跨服务大查询、对 API 调用成本敏感的（虚拟 grep 会放大请求）；需要强类型、结构化工具调用的严肃 Agent 编排；不想维护一套虚拟终端 + 策略引擎的轻量场景。
六、客观分析：优势与意义
优势： 把异构服务统一成 Unix 文件系统 + shell，最大化复用 LLM 已有的 bash 能力；虚拟 CLI 与虚拟运行时让「在哪跑、用什么凭据」都可配；策略引擎在每条命令前拦截，安全边界清晰；工作区可快照/迁移。
局限： 文件抽象带来性能与语义缝隙；运维复杂度高；用 shell 降级了结构化工具调用；项目早期。
Mirage 的真正洞察是：MCP 让每个服务成为一个「工具」，而 Mirage 赌的是「让所有服务成为一个文件系统」更符合 LLM 的心智模型。Agent 不必为每个服务记一套工具 schema，只要会 cd、grep、重定向。这条路线能不能跑通，取决于它能否在「易用」与「性能/安全」之间找到平衡——目前看，它更适合作为 Agent 的一个低门槛手脚，而不是替代 MCP 的全部。