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 很重要。官方 Model Context Protocol documentation 把它定义为模型连接工具和数据源的通用接口。它解决的是“agent 如何调用外部能力”。
但 MCP 并不自动解决存储、版本、审计和恢复问题。
如果所有东西都只是 live API call,团队仍然会遇到这些问题:
MCP 是访问协议,不是记忆层、文件层、权限层、审计层和恢复层。
用 puppyone 为 agent 构建可治理的上下文层Get startedAgents 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 误删文件、覆盖策略、污染数据集,团队可以 inspect、diff、rollback。Git 已经证明了 diff 和 rollback 对工程协作的价值。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 是面向多 agent 协作的文件工作区。用这篇文章的话说,它提供 AI agent infrastructure 中的 Agents Filesystem 和 Versioned Control Filesystem 层。
它的核心思路是:连接 agent 需要的上下文,把它表示成文件,用路径和 agent 身份治理访问,并通过 agent 已经使用的接口暴露出去。
具体来说:
这不是替代 Cloudflare 文章里的所有层。你仍然需要模型策略、runtime isolation、CI、review workflow 和组织自己的工程标准。但有了 Agents Filesystem,其他层会更容易组合,因为上下文和产物不再散落在各处。
延伸阅读:MCP in Agentic AI 和 AI audit best practices for secure agent deployments。
| 问题 | 如果答案是否 |
|---|---|
| 每个 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 安全地读、写、执行、协作和被审查。
不是。MCP 是 agent 连接工具和数据源的协议。Agents Filesystem 是保存文件、产物、权限、版本和审计记录的上下文层。两者互补:MCP 可以暴露文件系统,文件系统负责持久状态和治理。
向量数据库适合语义检索,但通常不提供可读写文件工作区、路径级权限、rollback、diff、sandbox mount 或 Git 风格协作语义。生产栈里常常两者都需要。
因为 agent 会写错、删错、覆盖错。版本控制应该内建在 agent 使用的文件系统里,而不是依赖 agent 记得提交。
当 agent 从实验变成共享 workflow 时:多个 agent、多数据源、敏感文件、长运行任务、可复用产物或人工 review。只要 agent 输出在聊天窗口关闭后仍然重要,就需要可持久、可版本化的上下文层。