A08 | 我用了一个工具,第一次觉得AI Agent真正在＂统一＂了

干了6年代码，有个感受特别深。

就是这两年 AI Agent 的工具，真的多到让人头皮发麻。

光我自己日常接触的，就有什么 MCP Server、Function Calling、OpenAI 的 Agents SDK、LangChain 的 Tool、还有各种国产的 agent 框架。每家都说自己生态好、接入快、兼容强。

结果呢？

你真正想做一个跨服务的自动化流程，比如"从 GitHub 拉代码，到 S3 查日志，再到 Slack 发个通知"，你得写三套完全不同的接入代码，学三套不同的 API 逻辑，对接三个不同的认证体系。

小脑想想也知道，这不是在用 AI，这是在给 AI 当保姆。

PART 01

挖到一个新项目：统一虚拟文件系统

我最近挖到一个项目，解决的就是这个问题。

GitHub 上 5 月 6 号才创建，两周不到，2144 颗星。

strukto-ai/mirage。

名字很梦幻，中文叫"海市蜃楼"。但它做的事一点都不虚，它给 AI Agent 建了一个统一虚拟文件系统。

虚拟文件系统，这个概念程序员应该不陌生

简单说，就是操作系统里那个

/Users/xxx/

/C/Program Files/

的树状结构，你所有东西都挂在同一个根目录下面，访问方式统一用一套语义。

Mirage 把这个概念搬到了 AI Agent 层面。

你可以在一个 Workspace 里，同时挂载 S3 的桶、本地磁盘、Google Drive、Slack、GitHub、Redis、MongoDB，甚至 Gmail。

挂上去之后，AI Agent 怎么访问这些数据？

用你熟悉的 bash 命令。

await ws.execute(&#x27;grep alert /slack/general/*.json | wc -l&#x27;)await ws.execute(&#x27;cat /github/mirage/README.md&#x27;)await ws.execute(&#x27;cp /s3/report.csv /data/local.csv&#x27;)

看清楚了，Slack 的消息、GitHub 的文件、S3 的对象存储，在 Agent 眼里全是同一个文件树里的路径。

grep、cat、cp、find，这些你天天用的 Unix 命令，现在可以直接跨服务操作。

Agent 不需要知道背后是哪个 API，不需要学哪套 SDK，它只需要懂 bash。

这才是真正的"零学习成本"。

我以前也喜欢收集工具

说实话，走了很多弯路。

作为一个 14 年健身的老油条，我太懂这种感觉了。健身房刚开业的时候，我买过弹力带、哑铃、杠铃、TRX 吊绳、龙门架、战绳。每种都说自己"功能全面"，结果呢，衣柜里堆了一堆，后来只用哑铃和杠铃。

工具多了不是好事，管理成本上来了，使用率反而下去了。

AI Agent 生态现在就是这个状态。

MCP 有 MCP 的协议，OpenAI 有 OpenAI 的格式，LangChain 有 LangChain 的定义。每家都在建自己的"工具生态"，但拼在一起的时候，碎片化严重得要命。

Mirage 干的事，就是在这个碎片化的生态上面，铺一层统一文件系统。

你不用管底层是什么，Agent 看到的永远是一个树状的虚拟目录。

这是它跟其他方案最大的区别。

其他方案是在做"更好的工具集成"，Mirage 是在做"更统一的使用界面"。

方向不一样，味道就不一样。

PART 02

实际跑了一下，说说感受

我本地装了 Python 版，跑了个简单的场景。

需求是这样的：我想让 Agent 帮我从 S3 读一个 CSV 文件，过滤出有问题的日志行，然后总结一下写回到本地。

用 Mirage 之前的做法，我得写一个 Python 脚本，先用 boto3 连 S3，再处理 CSV，再写本地文件。中间还得管凭证、管异常、管重试。

用 Mirage 之后，三行代码。

from mirage import Workspacefrom mirage.resource.s3 import S3Resource, S3Configws = Workspace({"/data": ..., "/s3": S3Resource(S3Config(bucket="my-bucket"))})await ws.execute("grep ERROR /s3/data/log.csv > /data/error.csv")

grep ERROR /s3/data/log.csv

这个命令，Agent 执行的实际上是在 S3 的对象存储里做筛选，结果直接流式写到了本地的

/data/error.csv

。

整个过程，代码层面零感知底层差异。

而且它还自带缓存层。

第一次访问 S3 文件，会走网络把数据拉下来，同时在本地 RAM 或者 Redis 里建索引和文件缓存。下次再访问同样的路径，直接从缓存读，零网络开销。

我测了一下，连续读同一个 S3 文件 100 次，第二次开始基本是毫秒级响应。

这个设计很程序员思维，先缓存，再计算。

PART 03

它不是银弹，但方向对了

说清楚局限性。

第一，环境限制

目前只支持 macOS 和 Linux，因为用到了 FUSE 做文件系统挂载。Windows 用户想用，得装 WSL2。这个短期内改不了，是底层依赖的问题。

第二，API覆盖深度不一致

支持的服务虽然多（S3、GDrive、Slack、GitHub、Redis、MongoDB 都在），但每个服务的 API 覆盖深度不一样。复杂操作还是得看官方文档，不是所有功能都能映射成 bash 命令。

第三，不是所有场景都适配

有些场景下，bash 语义不是最优解。比如 Gmail 的邮件线程逻辑，用

grep

就不太优雅，得配合更复杂的过滤条件。

但这些局限性不影响一件事：它解决的是框架层面的问题，而不是功能层面的问题。

框架层面的问题，就是"跨服务的统一访问"。

这个问题不解决，AI Agent 在企业场景里永远是半成品。

PART 04

方向对了，路就不远

说回那句"给 AI 当保姆"

我现在的状态，就是这样。

一个早上，光配置各种 API 凭证、研究各家的接入文档，就得花半小时。等真正开始让 Agent 干活，时间反而没剩多少了。

Mirage 不能帮你跳过这些配置工作，但它能让你配置一次，之后所有的 Agent 都用同一套语义来访问这些服务。

你不再需要为每个 Agent 重写一遍接入逻辑。

这才是"效率"两个字真正该有的样子。

搞过健身的人都知道，装备不是越多越好，能坚持下来的计划才是好计划。

AI Agent 也是一样，能真正落地使用的方案，才是真正有价值的方案。

工具太多是诅咒，能统一的工具才是祝福。

Mirage 做的就是这件事，让碎片化的 Agent 工具，重新统一到一个文件系统下面。

方向对了，路就不远。

理一——脑袋光光的琦玉老师 | 连续6年4点起床的程序员 | 注册营养师 | 14年健身老油条欢迎关注公众号「四点半的理一」