文件优于工具：用虚拟文件系统重构AI Agent架构

引言：Agent 架构的一次范式反思

近年来，AI Agent（智能体）已成为大模型应用的核心方向。绝大多数 Agent 框架都遵循同一套设计哲学：为模型定义一系列离散的"工具"（tools），每个工具对应一个函数调用，例如 search_web、read_database、send_email。模型根据任务选择合适的工具，通过结构化的函数调用（function calling）来完成操作。

**函数调用（Function Calling）**是现代大模型的核心能力之一，最早由 OpenAI 在 2023 年 6 月随 GPT-3.5/GPT-4 API 正式引入。其工作原理是：开发者以 JSON Schema 格式向模型描述可用函数的名称、参数类型和用途，模型在推理时若判断需要调用某函数，则输出一段结构化的 JSON 而非自然语言，应用层解析该 JSON 并实际执行对应函数，再将结果回传给模型继续推理。这种设计将模型的"意图"与"执行"解耦，使 LLM 能够可靠地与外部系统交互。然而，每个工具的 JSON Schema 描述少则数十 token，多则数百 token，当工具数量超过 30–50 个时，仅工具定义本身就可能消耗数千 token 的上下文窗口，直接挤压模型用于实际推理的空间。

然而，这种"工具优先"（tools-first）范式并非没有代价。随着任务复杂度上升，工具数量激增，模型需要在几十甚至上百个工具定义之间做选择，上下文被工具描述占满，调用出错率也随之攀升。一篇在 Hacker News 上引发广泛讨论的文章《Files over Tools》提出了一个反直觉的观点：与其给 Agent 提供越来越多的专用工具，不如给它一个虚拟文件系统和一个 bash 环境。

从"工具"到"文件"：核心思路

文章的核心主张可以概括为一句话——Agent 真正需要的不是更多工具，而是一个通用的操作环境。

工具膨胀的困境

在传统架构中，开发者需要为每一个可能的操作预先定义工具接口。这带来了三个根本性问题：

上下文占用：每个工具的 JSON Schema 定义都消耗 token，工具越多，留给实际任务推理的空间越少。
组合性差：工具之间难以自由组合。若要把某个工具的输出作为另一个工具的输入，往往需要额外的编排逻辑。
表达力受限：预定义工具只能覆盖开发者预想到的场景，遇到边缘情况便束手无策。

虚拟文件系统作为统一抽象

《Files over Tools》提出的方案是引入一个虚拟文件系统（virtual filesystem），让 Agent 通过 bash 命令与之交互。在这套设计中：

数据不再通过工具返回值传递，而是以文件形式存在于文件系统中；
Agent 通过 ls、cat、grep、sed、管道等熟悉的 Unix 工具来读写和处理文件；
复杂操作可以通过 shell 脚本自由组合，无需为每种组合单独定义新工具。

这种"一切皆文件"的理念，本质上是把 Unix 哲学移植到了 AI Agent 架构中。

Unix 哲学由贝尔实验室的 Ken Thompson 和 Dennis Ritchie 在 1970 年代构建 Unix 操作系统时奠定，后由 Doug McIlroy 总结为几条核心原则："让每个程序只做好一件事""让程序的输出成为另一个程序的输入"。其中最具影响力的设计决策是"一切皆文件"——无论是普通文件、目录、硬件设备、网络套接字还是进程间通信，都通过统一的文件描述符接口访问。管道（pipe）机制则让多个小工具可以通过 | 符号自由串联，使简单命令组合出极其复杂的数据处理能力。这套哲学让 Unix/Linux 在服务器领域统治至今，而 bash shell 作为这套哲学的主要交互界面，拥有数十年沉淀的生态和用法示例。

为什么这套设计更符合模型的"直觉"

一个关键洞察是：现代大模型在预训练阶段见过海量的 Unix 命令、shell 脚本和文件操作代码。相比于每个项目各不相同的自定义工具 API，bash 和文件系统是模型早已「精通」的领域。

现代大语言模型（如 GPT-4、Claude、Llama 系列）的预训练数据集通常包含数万亿 token，其中涵盖 GitHub 上的大量代码仓库、Stack Overflow 的问答内容、Linux 文档、技术博客等。据估计，GitHub 公开仓库中包含数十亿行 shell 脚本、Makefile 和命令行示例，这意味着模型对 grep、awk、sed、xargs、find 等 Unix 工具的语法和惯用法拥有极其丰富的先验知识。相比之下，每个 Agent 框架的自定义工具 API 几乎不可能出现在预训练数据中，模型必须完全依赖提示词中的文档说明才能正确使用。

这意味着：

模型使用 bash 的成功率天然更高，因为它见过无数真实的命令行示例；
无需在提示词中详细解释每个工具的用法，模型自带充分的先验知识；
面对多步处理任务时，模型可以像真实工程师一样，用管道和脚本把简单命令串联成复杂流程。

换句话说，这套设计让 Agent 更接近一个开发者在终端里工作的方式，而不是一个受限于固定按钮的操作面板。

虚拟文件系统的工程价值

将文件系统"虚拟化"是这套方案的另一大亮点。虚拟文件系统并不直接对应宿主机的真实磁盘，而是一个受控的沙箱环境，带来三个重要工程收益：

安全隔离

Agent 执行的所有 bash 命令都被限制在虚拟环境内，无法触碰宿主系统的敏感文件，有效降低任意代码执行带来的安全风险。

允许 AI Agent 执行任意 bash 命令是一把双刃剑，安全隔离因此成为工程实现的核心挑战。业界主流的沙箱方案分为几个层次：容器级隔离（如 Docker）通过 Linux 的 namespace 和 cgroup 机制将进程限制在独立的文件系统和网络空间内；更严格的方案使用 gVisor 或 Firecracker 等轻量级虚拟机技术，在容器与宿主内核之间再加一层隔离；系统调用级过滤（seccomp）则可以白名单方式限制进程能够执行的内核调用。OpenAI 的 Code Interpreter、Anthropic 的 Claude 工件执行环境，以及 E2B、Modal 等专门的代码沙箱服务，都在工程上解决了这一问题。《Files over Tools》所提倡的虚拟文件系统方案，需要在这些沙箱技术之上构建，才能真正做到安全可用。

状态可持久化

任务的中间结果以文件形式保存，Agent 可以在多个步骤之间保持状态。即便某一步出错，也能基于已有文件重新尝试，而不必从头开始。

可观测与可调试

对开发者而言，文件系统的状态是完全透明的。你可以随时检查 Agent 生成了哪些文件、内容是什么，这比追踪一串抽象的工具调用要直观得多。

权衡与争议：并非银弹

尽管这套思路颇具吸引力，但从工程实践角度看，仍有几处值得权衡：

精确控制 vs 自由度：预定义工具的优势在于行为可预测、可约束。开放 bash 权限意味着 Agent 可能执行超出预期的操作，需要更完善的沙箱与权限管理机制。
确定性接口的场景：调用外部 API、需要严格参数校验时，结构化工具调用仍更可靠。文件与 bash 更适合数据处理、文本操作等「胶水」类任务。
错误处理挑战：shell 命令的错误信息有时晦涩难懂，Agent 需要具备解析报错并自我纠正的能力。

因此，更务实的做法或许是混合架构：用文件系统和 bash 处理灵活的数据操作，同时保留少量关键的结构化工具来对接外部服务。这一思路在业界已有落地先例——Anthropic 为 Claude 设计的 Computer Use 功能让模型可以直接操作桌面环境，同时保留结构化 API 调用能力；OpenAI 的 Assistants API 同样支持将 Code Interpreter（本质上是一个 Python 执行沙箱）与自定义 Function Calling 混合使用。在开源社区，LangChain 的 ShellTool、smolagents 框架以及 OpenHands（前身为 OpenDevin）项目都探索了以 bash 执行为核心、辅以少量结构化工具的 Agent 架构。混合设计的核心原则是：凡是需要与外部服务建立稳定契约（如支付 API、数据库写操作）的场景，使用结构化工具以保证参数校验和错误处理的可靠性；凡是属于数据处理、文本变换、文件操作等"胶水"类任务，则交给 bash 和文件系统处理，充分发挥模型的先验知识优势。

结语：回归通用抽象

《Files over Tools》的价值不在于提供一个现成的框架，而在于挑战了当前 Agent 设计中"堆砌工具"的惯性思维。它提醒我们：最强大的抽象，往往是最通用的抽象。

Unix 以"一切皆文件"和"小工具组合"的哲学统治操作系统世界数十年，如今这套理念在 AI Agent 领域重新焕发生命力，或许并非偶然。当模型足够聪明，能够像人一样使用终端时，我们要做的可能不是给它更多专用按钮，而是给它一个足够开放、足够熟悉的工作台，然后放手让它去做。

对于正在构建 Agent 的开发者来说，这至少是一个值得认真考量的方向：在增加下一个工具之前，先问问自己——这个操作，能不能只用一个文件和一行 bash 来完成？