idevlab's Blog
如果只看最近几年的 AI 工程进展，很容易生出一种幻觉：我们正在以惊人的速度解锁新能力。新模型、新 Agent、新协议，一波接一波，热闹得像基础设施已经完成了交接。
但真正值得写下来的，往往不是热闹，而是热闹下面那条更硬的线。
那条线是：我们在用 20 世纪 90 年代的”下水道工程”，来承载 21 世纪的通用人工智能。
全世界最顶尖的大脑在训练拥有千亿参数的语言大模型，却在工程落地的最后一公里，要求这些”数字天才”去死记硬背成千上万个粗制滥造的 API 和杂乱无章的工具调用协议。结果显而易见：系统脆弱不堪，Agent 难以自治，开发者在无尽的胶水代码中疲于奔命。
这不是 API 本身的问题。这是一个更深层的架构困境：我们在用静态、统一的协议去适配动态、复杂的现实需求。复杂性无法消除，只能被转移——而我们一直在错误的地方转移它。
是时候停止打补丁了。让我们回溯计算机科学 50 年前的巅峰智慧，用极其克制、优雅的 Unix 哲学，为下一代 Agent 打造真正的”操作系统”。
一、现状的困局：三座难以逾越的大山
第一座山：语法方言的诅咒
AWS CLI 采用冗长的动宾结构（aws ec2 describe-instances）；Google Cloud 坚持主谓宾（gcloud compute instances describe）；Kubernetes 走向极简陈述句（kubectl get pod）。
每家都有自己的”方言”，每家都觉得自己的设计是对的。
这对大模型意味着极高的”上下文税”。为了让 Agent 准确执行操作，开发者必须把几十 KB 的文档塞进上下文。即便如此，大模型依然容易把 --region 和 --zone 搞混，导致执行流瞬间中断。
第二座山：鉴权孤岛
每家 CLI 都有独立的”鉴权宇宙”。AWS 找 ~/.aws/credentials，GitHub 找 ~/.config/gh/hosts.yml。更致命的是 Token 生命周期的断裂——当 OAuth Token 过期时，有的系统弹出浏览器授权窗口，有的直接抛出 401。
Agent 根本无法处理这些互不兼容的刷新逻辑。它不是不够聪明，而是这个问题本来就不该由它来处理。
第三座山：I/O 阻抗
CLI 工具为人类优化，输出漂亮的 ASCII 表格和彩色状态码。但大模型必须浪费算力去”阅读”这些。即使强制使用 --format=json，仍有大量工具将错误日志与正常数据混杂在一起。
这就像让一个数学家每天用手抄方程式，而不是给他一块白板。
根本问题：静态协议无法适配动态需求
为了解决碎片化问题，业界寄希望于模型上下文协议（MCP）。但这个尝试暴露了一个根本性的悖论：用静态、统一的协议去适配动态、复杂的现实需求。
MCP 的核心逻辑是让模型在调用工具前”充分了解”所有工具。如果接入 20 个 SaaS 工具，MCP 会在对话开始前强行把数万 Tokens 的 Schema 塞进上下文。这带来了高昂的 API 成本和严重的”上下文中毒”。而且，这些 Schema 是静态的——当 API 行为因权限变化或系统状态转移而改变时，Schema 无法反映这些动态变化。
复杂性是不可消除的，只能被转移。 问题是：我们应该把它转移到哪里？
二、回归 Unix：万物皆文件
Unix 操作系统的设计者们早就给出了答案：无论你是读取硬盘文档、向显示器输出像素，还是通过网络发送数据流，在底层，统统只需要 open(), read(), write(), close()。
这才是 AI Agent 应该生存的物理世界：万物皆挂载的虚拟文件系统（VFS - Virtual File System for Agents）。
我们不再给大模型提供 send_feishu_message() 这种生硬的函数。我们将整个 SaaS 世界挂载到 Agent 的工作区中：/mnt/feishu/、/mnt/github/、/mnt/aws/。
对于 AI 来说，发送飞书报警不再是组装 HTTP POST 请求，而是：
1 | echo "线上 CPU 负载超标，请排查！" > /mnt/feishu/channels/dev_ops/send |
底层的 VFS 驱动会捕获这个文件写入，自动翻译成 API 请求。
如何解决第一座山：语法方言的诅咒
在 VFS 体系中，所有操作都统一为文件操作。无论是飞书、Slack、AWS 还是 GitHub，Agent 都用同样的语法操作它们：
1 | # 读取任何系统的数据 |
世界上只剩一种语法——POSIX 标准指令，这已经刻入 LLM 训练数据的 DNA。大模型不需要在上下文中存储数万 Tokens 的 Schema，也不需要学习不同系统的语法差异。它只需记住一个简单规则：所有外部系统都是文件树，所有操作都是文件操作。
“上下文税”，就这样被消掉了。
如何解决第二座山：鉴权孤岛
我们引入 Auth Broker——一个授信的中转站，类似于现代的密码管理器（1Password、Bitwarden 那种）。它的使命是统一管理所有的鉴权凭证，代理 Agent 与各个 SaaS 系统之间的身份验证。
Auth Broker 的核心职责包括三个方面：
第一，凭证存储与管理。所有的 API Key、OAuth Token 等敏感凭证都加密存储在 Auth Broker 中，Agent 永远看不到。
第二，动态 Token 生成。当 Agent 需要访问某个 SaaS 系统时，Auth Broker 不是直接返回存储的 Token，而是根据当前上下文（Agent 的身份、权限、时间、环境等）动态生成一个临时的、受限的 Access Token。这个临时 Token 有明确的有效期（通常只有几分钟）和权限范围，大大降低了泄露风险。
第三，鉴权流程的统一。不同的 SaaS 系统有不同的鉴权方式（API Key、OAuth 2.0、SAML 等），Auth Broker 屏蔽了这些差异，向 Agent 提供统一的接口。
当 Agent 尝试访问一个挂载的目录时，流程是这样的：
- Agent 执行文件操作：
cat /mnt/feishu/channels/dev_ops/messages - VFS 驱动拦截，识别 Agent 身份和目标资源
- VFS 驱动向 Auth Broker 查询：能否为这个 Agent 生成临时凭证？
- Auth Broker 验证权限和上下文，生成临时凭证
- VFS 驱动代表 Agent 向 API 发送请求
- 结果返回给 Agent（Agent 始终看不到凭证）
Agent 不需要知道不同系统的鉴权方式，也不需要处理 Token 刷新逻辑——这一切都由 Auth Broker 在后台自动处理。鉴权孤岛，就这样被填平了。
如何解决第三座山：I/O 阻抗
VFS 驱动在转换数据时，自动将 API 的 JSON 响应转换为文件系统的语义。Agent 读取的永远是纯净的、结构化的数据，而不是为人类优化的表格或彩色输出。
1 | # Agent 读取的是纯 JSON，不是漂亮的表格 |
VFS 驱动确保了数据与控制的分离。复杂的交互通过目录结构来表达，而不是混杂在输出中。Agent 不再需要浪费算力去解析为人类设计的输出格式。
三、权限与多租户
权限：用 Unix 的语言说清楚
在 VFS 体系中，权限管理遵循 Unix 文件系统的经典设计——读（r）、写（w）、执行（x）三种权限，应用于所有者、群组、其他人三个维度。
读权限（r） — 允许 Agent 获取信息
写权限（w） — 允许 Agent 修改状态和执行操作
执行权限（x） — 允许 Agent 进入目录或触发特殊操作
这个模型天然地防止了 Agent 访问不应该看到的数据，也防止了它执行不应该执行的操作。不需要引入新的权限语言，Unix 的那套已经够用了。
多租户：账号即目录
当 Agent 需要同时管理多个账号时，VFS 采用物理目录隔离：
1 | /mnt/feishu/account_work/ |
当需要切换身份时，Agent 只需：
1 | ln -sfn /mnt/feishu/account_bot /workspace/current_env |
上下文的切换，被轻量化为一次文件系统指针的重定向。
四、诚实面对：这条路上还有几块绊脚石
任何架构都不是银弹。VFS 方案的思路足够优雅，但在真正落地之前，有几个问题值得坦诚地摆在桌面上。
网络 I/O 与大资源的爆炸问题
文件系统的心智模型建立在一个隐含假设上：ls 是廉价的，cat 是即时的。但 SaaS 世界的资源并不遵守这个约定。
当 Agent 对一个大型 S3 存储桶执行 ls，或者试图 cat 一个拥有数万条记录的 GitHub Issue 列表时，背后是真实的网络请求——可能触发分页、可能超时、可能返回几十 MB 的 JSON。这与本地文件系统的直觉完全背离，甚至可能让 Agent 的上下文直接爆炸。
可能的思路：VFS 驱动可以引入**惰性加载（Lazy Loading）**机制——ls 只返回资源的元数据摘要，真正的内容在 cat 时才按需拉取；同时强制实现分页语义，将大资源切分为 /mnt/github/issues/page_1、/mnt/github/issues/page_2 这样的虚拟分页目录。驱动层内置缓存，避免重复的网络请求。这些机制在 FUSE 层完全可以实现，只是需要精心设计。
复杂操作难以表述
read 和 write 足以覆盖大多数场景，但 SaaS 世界里有些操作天然是复杂的。比如：发起一个需要多步骤确认的 GitHub Pull Request、在飞书中创建一个带有富文本卡片和交互按钮的消息、执行一个需要事务保证的数据库批量操作。
这些操作的语义远比”写一个文件”复杂。强行用文件写入来表达，要么需要一个极其复杂的 JSON 结构，要么需要多次写入不同的控制文件——这反而让 Agent 的负担更重，也让驱动层的实现更加脆弱。
可能的思路：VFS 并不需要覆盖所有场景。对于这类复杂操作，可以采取分层混合的策略：简单的 CRUD 操作走 VFS，复杂的事务性操作保留为专用的命令脚本（存放在 /mnt/feishu/scripts/ 下），由 Agent 调用执行。这样既保留了 VFS 的统一心智，又不强迫所有复杂性都挤进文件操作的语义里。
事件无法监听
文件系统是一个**拉取（Pull）模型——你主动去读，才能得到数据。但真实世界里大量的场景是推送（Push）**的：飞书消息到来、GitHub 触发 Webhook、AWS CloudWatch 发出告警。
一个只会轮询文件的 Agent，要么需要不断地 cat 同一个文件来检查是否有新消息（浪费算力，且实时性差），要么根本无法感知外部世界的变化，自治能力大打折扣。
可能的思路：Linux 内核早已给出了答案——inotify。VFS 驱动可以在底层订阅 SaaS 系统的 Webhook 或 WebSocket 推送，当事件到来时，将其写入一个特殊的事件队列文件（如 /mnt/feishu/events/stream）。Agent 只需用 tail -f 监听这个文件，就能以完全原生的方式感知实时事件。推送模型被优雅地转换为了文件系统的 inotify 语义，Agent 的心智模型依然保持统一。
这三个问题都不是无解的。它们更像是工程上的硬骨头，而不是架构上的致命缺陷。Unix 哲学本身就是在数十年的工程实践中不断打磨出来的——我们有理由相信，VFS for Agents 同样会在真实的落地中找到自己的答案。
尾声：现实已经在投票了
就在本文写完的前一天，2026 年 4 月 7 日，AWS 悄悄发布了一个东西：Amazon S3 Files。
官方将其描述为「S3 二十年来最大的更新」。它能做什么？将 S3 存储桶挂载为原生文件系统，提供亚毫秒级文件访问，原生支持 POSIX 权限（UID/GID），让 Lambda、EC2、EKS 直接连接——消除了对 s3fs 或数据暂存的需求。
官方的那句话值得原文引用：
Your AI agents can read/write to S3 like a local disk, while your data team access the same objects via API.
这不是某个独立博客的思想实验。这是全球最大的云厂商，用一次产品发布，在现实层面为「万物皆文件」投了一票。
不止 AWS。Vercel Labs 同期开源了 just-bash，副标题直接写着 “Bash for Agents”——一个完全用 TypeScript 实现的内存虚拟 Bash 环境，支持完整的 Unix Shell 语义、可挂载的文件系统、管道与重定向，专门为 AI Agent 设计。它甚至提供了自定义命令接口，让开发者可以把任意 SaaS 操作挂载成 Shell 命令，Agent 用 Bash 脚本就能调用。
两家公司，两条独立的技术路线，同时走向了同一个方向：给 Agent 一个原生的文件系统和 Shell 环境，而不是一堆 API。
方向对不对，市场会给出答案。
回到原点
我们正处于计算架构演进的奇点。
如果继续在 API 泥潭里打滚，我们能做出来的，顶多是一个稍微智能一点的 RPA 工具。它会被日益膨胀的复杂性压垮，就像所有没有真正解决根本问题的工程方案最终都会被压垮一样。
真正值得做的，是打破这种虚假的繁荣。承认 API 地狱的现状，放弃教导模型学习人类方言的执念。
拥抱**”以智能体为本（Agent-First）”**的底层重构。将庞大、复杂的 SaaS 世界降维成纯粹的字节流和文件树；将繁杂的协议转换和密钥轮转，毫不妥协地压进操作系统的底层驱动中。
给大模型提供一个最干净、最原生、最符合它数学直觉的”物理世界”。在这个世界里，AI 不再是笨拙调用外部工具的提线木偶，而是熟练敲击着 Bash 脚本、游刃有余掌控全局的极客。
不要去掩盖复杂，去转移复杂；不要去对抗 AI 的天性，去顺应它的天性。
回归 Unix，一切皆文件。