AI Agent Infrastructure 为什么需要 Agents Filesystem 与 Versioned Control Filesystem

2026年4月21日Lin Ivan

核心要点

  • AI agent infrastructure 的瓶颈不只是模型能力,而是上下文、工具、文件、权限、执行环境和回滚能力。
  • Cloudflare 的内部 AI 工程栈展示了生产级 agent 系统的形态:统一认证、MCP servers、沙盒执行、AGENTS.md、服务目录和 AI code review。
  • 大多数团队不需要立刻复刻完整平台,但需要先补上一层:让 agent 能安全读写企业上下文的 Agents Filesystem。
  • Versioned Control Filesystem 的价值在于把版本控制下沉到文件层。agent 每次写入都应该有身份、diff、历史、回滚和审计。
  • puppyone 可以作为这层基础设施:把 SaaS 数据、项目资料、agent 产物转成可治理、可版本化、可通过 MCP 或沙盒挂载访问的文件工作区。

Cloudflare 给出的信号:agent 有用之前,周围的基础设施要先存在

Cloudflare 最近发布了它们内部 AI 工程栈的文章:The AI engineering stack we built internally。这篇文章有意思的地方不在于“用了什么模型”,而在于它把 AI agent adoption 当成基础设施问题。

文章里出现的关键层包括:Zero Trust 认证、统一 LLM routing、MCP Server Portal、沙盒执行、长运行 agent session、Backstage 服务目录、AGENTS.md、工程规范和 AI code reviewer。

这些层分别解决不同的生产问题:

生产问题基础设施回应
工程师使用不同 AI client 和模型提供商统一 routing、模型策略、成本追踪
agent 需要调用内部工具MCP servers 和 portal 层
agent 需要安全执行代码沙盒运行环境
agent 需要理解 repo 约定AGENTS.md 和工程规范
agent 需要组织级知识服务目录、依赖图、owner 信息
agent 产物需要被审查与工程标准绑定的 AI code review

这就是生产级 AI agent infrastructure 的真实形态:不是一个更长上下文窗口的聊天机器人,而是一套让 agent 找到正确上下文、调用正确工具、在正确边界内行动,并留下可审查痕迹的运行环境。

为什么“接上 MCP”还不够

MCP 很重要。官方 Model Context Protocol documentation 把它定义为模型连接工具和数据源的通用接口。它解决的是“agent 如何调用外部能力”。

但 MCP 并不自动解决存储、版本、审计和恢复问题。

如果所有东西都只是 live API call,团队仍然会遇到这些问题:

  • tool schema 占掉大量上下文窗口;
  • agent 没有稳定位置存放 plan、scratch、报告、转换后的数据和中间文件;
  • 两次运行之间的变更无法直接 diff;
  • 每个 SaaS、repo、数据库都需要额外胶水;
  • agent 产物留在聊天线程、临时目录或没有治理的本地文件夹里。

MCP 是访问协议,不是记忆层、文件层、权限层、审计层和恢复层。

用 puppyone 为 agent 构建可治理的上下文层Get started

Agents Filesystem 到底是什么

Agents Filesystem 是为 AI agents 设计的文件工作区。

传统文件系统默认附近有一个人类来判断什么安全、什么最新、什么该提交、什么该忽略。agent 不是这样工作的。它会读取可见内容,写入允许路径,并把文件当作推理和执行的一部分。

一个生产级 Agents Filesystem 至少需要五个能力:

能力为什么重要
统一上下文agent 应该通过一个文件空间访问 SaaS 数据、repo 文档、ticket、spec 和历史产物。
范围化权限每个 agent 只能看到允许读写的路径,敏感文件不应该意外进入上下文。
原生 agent 接口同一份上下文应该能通过 Bash、MCP、REST、CLI 或 sandbox mount 访问。
持久写入plan、scratch、报告、生成代码和转换数据不能随着 session 消失。
操作痕迹read、write、diff、permission denied 都应该可见,方便调试和治理。

这和普通共享文件夹不一样。Dropbox、S3、Git、本地磁盘和向量数据库各自解决一部分问题,但它们通常不同时具备 agent 身份、per-agent 权限、MCP 分发、沙盒挂载和自动版本历史。

如果你想看文件权限的底层设计,可以读这篇:filesystem design for AI agents

为什么版本控制必须进入文件系统层

agent 不只是检索上下文,它会修改上下文。

它会总结会议、生成迁移计划、改写文档、转换数据集、创建报告、打开 PR、更新任务文件。只要 agent 开始写文件,系统就必须有恢复模型。

这就是 Versioned Control Filesystem 的意义。更自然的英文说法可能是 version-controlled filesystem,但这里的重点是:版本控制不能依赖 agent 自己记得 commit,它必须成为存储层的一部分。

在面向 agent 的 Versioned Control Filesystem 里:

  • 每次写入都创建版本;
  • 每次变更都归因到 agent、用户、Access Point 或 workflow;
  • 每个 diff 都可审查;
  • 每个目录都能回滚到已知状态;
  • 高风险操作前可以创建 checkpoint;
  • 权限边界可以被审计。

如果 agent 误删文件、覆盖策略、污染数据集,团队可以 inspect、diff、rollback。Git 已经证明了 diff 和 rollback 对工程协作的价值。agent infrastructure 需要把类似语义带到上下文文件,而不只是代码仓库。

一个实用的 AI agent infrastructure 分层

生产级 agent stack 可以这样分层:

用户或业务请求
  -> agent client / orchestration
  -> model routing 与策略层
  -> MCP 与工具访问层
  -> Agents Filesystem
       - 同步后的 SaaS 上下文
       - repo 与项目上下文
       - agent 生成产物
       - per-agent 权限
       - version history 与 audit logs
  -> sandbox 执行层
  -> review、approval、deployment

Agents Filesystem 位于中间,因为上下文在这里变成可操作对象。它连接数据源、MCP、sandbox 和 review。没有这一层,团队往往会拼出一堆碎片:本地文件夹、向量索引、若干 MCP server、wiki、对象存储和审计表格。demo 阶段能跑,多个 agent、多个团队、多条权限边界进来后就会变脆。

puppyone 在这里的位置

puppyone 是面向多 agent 协作的文件工作区。用这篇文章的话说,它提供 AI agent infrastructure 中的 Agents Filesystem 和 Versioned Control Filesystem 层。

它的核心思路是:连接 agent 需要的上下文,把它表示成文件,用路径和 agent 身份治理访问,并通过 agent 已经使用的接口暴露出去。

具体来说:

  • Notion、GitHub、Google Drive、Gmail、Airtable、Linear、数据库等来源可以同步进统一 Context Space;
  • 上下文以 Markdown、JSON、文件夹和原始文件形式呈现;
  • Access Point 定义每个 agent 可读写的路径;
  • MCP endpoint 让 Claude、Cursor 等 MCP client 访问同一份受控文件空间;
  • Sandbox mount 只挂载授权文件;
  • 版本历史和 rollback 让 agent 写入可检查、可恢复;
  • audit logs 记录谁在何时访问或修改了什么。

这不是替代 Cloudflare 文章里的所有层。你仍然需要模型策略、runtime isolation、CI、review workflow 和组织自己的工程标准。但有了 Agents Filesystem,其他层会更容易组合,因为上下文和产物不再散落在各处。

延伸阅读:MCP in Agentic AIAI audit best practices for secure agent deployments

如何检查你的 agent stack 是否缺这一层

问题如果答案是否
每个 agent 都能不用复制粘贴找到所需上下文吗?你需要上下文接入和标准化。
每个 agent 只能访问被授权的文件和工具吗?你需要范围化权限和策略执行。
agent 生成的文件能在 session 结束后保留吗?你需要持久化 artifact storage。
能看出两次 agent run 之间改了什么吗?你需要 versioned filesystem history。
agent 写错后能回滚吗?你需要 checkpoint 和 restore。
sandbox 只能挂载授权上下文吗?你需要 filesystem-aware access control。
人类能审查文件产物,而不是翻聊天记录吗?你需要文件化 workflow 和 audit trail。

这才是 ai agent infrastructure 背后的真实搜索意图:让 agent 安全地读、写、执行、协作和被审查。

在可版本化文件工作区上构建 agent infrastructureGet started

FAQs

Q1: Agents Filesystem 和 MCP 是一回事吗?

不是。MCP 是 agent 连接工具和数据源的协议。Agents Filesystem 是保存文件、产物、权限、版本和审计记录的上下文层。两者互补:MCP 可以暴露文件系统,文件系统负责持久状态和治理。

Q2: 它和向量数据库有什么区别?

向量数据库适合语义检索,但通常不提供可读写文件工作区、路径级权限、rollback、diff、sandbox mount 或 Git 风格协作语义。生产栈里常常两者都需要。

Q3: 为什么要强调 Versioned Control Filesystem?

因为 agent 会写错、删错、覆盖错。版本控制应该内建在 agent 使用的文件系统里,而不是依赖 agent 记得提交。

Q4: 团队什么时候该引入这一层?

当 agent 从实验变成共享 workflow 时:多个 agent、多数据源、敏感文件、长运行任务、可复用产物或人工 review。只要 agent 输出在聊天窗口关闭后仍然重要,就需要可持久、可版本化的上下文层。