从模型焦虑到存储焦虑

AI 行业正经历一场静默的重心迁移——从“模型够不够聪明”转向“数据底座能不能扛住”。当 Agent 从单纯的模型调用演进为具备工具调用、任务执行和环境交互能力的自主系统，一个被长期忽视的基础设施短板浮出水面：文件存储。每个 Agent 需要独立的工作空间、安全的访问隔离、弹性的资源供给，而传统文件存储的设计假设是“人在使用文件系统”。当用户从人变成 Agent，规模从千级跃升到亿级，存储服务还跟得上吗?

旧范式与新现实的碰撞

文件系统是 Agent 与数据交互的主要界面。AI Agent 应用已具备工具调用、环境交互和自主决策能力，每一次任务执行都伴随着代码生成、依赖安装、中间结果写入和会话持久化。随着文件系统的用户从人转向 Agent，我们观察到三个重要的挑战：

规模天花板。 AI Agent 场景中，每个 Agent 需要独立的 Workspace 来存储状态数据，这意味着文件系统需要为每个 Workspace 分配独立的挂载点、存储配额。在典型 ToC 平台上，Agent 数量达到百万至千万级别，文件系统随之要承载同等量级的百万级挂载点、配额管理。而传统 NAS 单实例的文件数上限 10~20 亿，目录配额规模仅千级，挂载点规模同样受限，平台方不得不拆分管理数百个文件系统实例，运维复杂度指数级上升。

隔离困境。 一个异常 Agent 可能通过无限循环写入大文件耗尽整个文件系统空间，或通过高频元数据操作占满 QPS 配额，引发“雪崩效应”——同一文件系统上的所有其他 Agent 服务中断。而传统 NAS 在共享目录下无法实现 Agent 间的性能隔离和容量隔离。在多租户 Agent 平台中，这种缺乏隔离的设计等同于将稳定性交给了不可控的 AI 执行路径。

安全盲区。 Agent 的执行路径由大模型动态生成，存在被 Prompt Injection 等手段诱导走向破坏性路径的风险。传统 NAS 的权限模型粒度粗——文件系统级或目录级的 ACL 无法覆盖“每 Agent 独立安全凭证”的零信任需求。一旦攻击者突破 Agent 的执行边界，共享目录下的所有 Agent 数据都暴露在风险之中。

传统 NAS “共享目录”模式的这三大痛点的根源是同一个范式错位：传统 NAS 的设计假设是“少数用户共享文件系统”，而 Agent 时代的真实场景是“百万 Agent 各有独立空间”。旧范式已难承 AI 之重。

AgenticFS 的架构升维

AgenticFS 的核心设计思路可以用一句话概括：从“一个文件系统里划目录”变为“每个 Agent Workspace 对应一个独立的存储空间”。

在传统 NAS 中，每个 Agent 的 Workspace 被映射为一个目录，所有 Agent 共享同一实例的元数据分区、配额系统和性能资源。AgenticFS 将映射关系彻底重构——每个 Agent Workspace 对应一个独立的 AgenticSpace(拥有独立 inode 空间、独立挂载点、独立配额和独立性能资源)，大规模的 AgenticSpace 实例共同组成一个逻辑的 AgenticFS。

这一映射变化的技术效果是根本性的：元数据规模和性能随实例数线性扩展，软件层面无上限;实例间的天然故障域隔离使爆炸半径收敛到最小粒度;每个 Workspace 的容量配额、权限控制和 QoS 独立生效，互不干扰。

AgenticFS 的四大核心能力构成了完整的 Agent 存储解决方案：

入口统一：Region 级超级文件系统

作为 Region 级逻辑资源，AgenticFS 采用跨可用区、跨物理集群的分布式编排架构，把分散在多个集群上的百万至亿级 AgenticSpace 实例聚合为一个统一的逻辑文件系统对外暴露。

Region 级与 AZ 级分层的设计方案，让平台方只需管理一个文件系统，即可在统一视图下管理所有 Agent Workspace——AgenticSpace 配置自动继承 AgenticFS 顶层策略，容量与配额随集群扩容线性增长，平台方不必为每个 Agent 重复设置策略。

单 AgenticFS 支持管理亿级 AgenticSpace，元数据操作 QPS 达到亿级，这一规模承载能力来自跨集群分布式编排而非单实例扩容，从根本上规避了单分区元数据瓶颈。

平台方挂载 AgenticFS 根目录后，即可只读访问全部 AgenticSpace 数据，为备份、日志分析、合规审计等运维场景提供统一的数据入口——平台方无需逐个挂载百万 AgenticSpace 即可完成全平台数据洞察。

图1：AgenticFS 的 Region 级分布式编排架构

空间分治：Agent 独立工作空间

每个 AgenticSpace 拥有独立的 inode 空间和管理能力，这种独立性不是配置层面的隔离，而是元数据层面的彻底分治。容量与文件数双维度配额(最大 1PiB / 10 亿文件)让平台方既能限制单 Agent 的存储容量防止“存储薅羊毛”，又能限制其文件数防止元数据爆炸。

性能隔离覆盖吞吐、IOPS、元数据 QPS 三个维度，即使某个 Agent 触发异常高频元数据操作或大文件写入，也不会挤占同 AgenticFS 下其他 Agent 的资源配额。

每个 AgenticSpace 支持独立的挂载点(Access Point)和安全凭证，挂载卸载 QPS 达到 10 万级，端到端挂载延迟收敛至秒级，满足 Agent Sandbox 等秒级弹性场景的严苛要求。

AgenticSpace 独立的数据和元数据分区，让单实例故障的影响半径收敛到最小粒度——只波及单个 Agent Workspace，不再触发跨租户的雪崩效应。

图2：AgenticSpace 支持独立工作空间

零信任访问：轻量级安全凭证体系

AgenticFS 采用“平台方代理鉴权”模型，平台方用一个阿里云账号即可管理百万级终端用户——AgenticFS 只认“平台方代某 Agent 申请访问某 AgenticSpace”，不感知终端用户身份，大幅简化了百万级用户的鉴权复杂度。

每个 AgenticSpace 配备独立的安全凭证和挂载点，杜绝跨 Agent 凭证泄露，即便攻击者突破某个 Agent 的执行边界，也无法横向移动到其他 AgenticSpace。

基于 STS 和零信任的临时凭证机制，凭据签发过程轻量无状态、可水平扩展，提供 10 万级 QPS，完全匹配百万级 Agent 并发挂载场景。临时凭证自动轮转机制使攻击窗口收敛至最小，密钥不落盘——即使凭证被截获，有效窗口也短到难以利用，从机制层面把“长期凭证泄露”这种传统存储最常见的安全事故类别彻底消除。

图3：传统的长期凭证升级成零信任临时凭证

管控面即数据面：与数据面同构的水平扩展能力

传统存储架构中，管控面与数据面分离部署，管控面往往成为大规模场景下的性能瓶颈——单点 RDS 难以支撑百万级创建、删除、挂载的高并发请求。

AgenticFS 把管控系统与数据面 co-locate，使管控面达到和数据面相同的水平扩展性——只要数据面能扩展，管控面就跟着扩展，不再受单点瓶颈约束。这种架构直接带来 AgenticSpace 创建删除、挂载卸载 10 万级 QPS 的支撑能力，意味着即便百万级 Agent 在数秒内集中创建或唤醒(Agent Sandbox 启动和唤醒等典型场景)，管控面也能从容承载。

图4：AgenticFS 与数据面同构的管控架构

Agent 技术栈中的存储基座

AgenticFS 不是孤立的存储产品，而是阿里云面向 Agent 时代的存储基座。它的全部价值在嵌入完整的 Agent 技术栈后能释放出来。

向上：对接多元计算形态，定义“Workspace 即服务”

Agent 时代的计算层不再是单一的 ECS 或容器，而是分化出多种适配 Agent 工作负载的形态——ACS Agent Sandbox 提供 MicroVM 级别的隔离运行环境，FC 云沙箱提供云端隔离运行环境。这些计算形态的共同诉求是：在 Sandbox 启动时动态申请并挂载一个专属目录，存放 AI 生成的代码、依赖库、临时文件和运行结果。

AgenticFS 把这种“动态申请 + 独立挂载 + 独立隔离”的能力产品化——平台方调用 CreateAgenticSpace OpenAPI，秒级即可为 Agent 分配一个独立的 Workspace，具备独立的 inode、配额、AP 和性能 QoS。对于 Agent Sandbox 这种秒级弹性场景，AgenticFS 的端到端秒级挂载延迟，满足办公智能体等客户对 Sandbox 总唤醒时间的严苛要求。

图5：AgenticFS 对接多元计算形态，定义“Workspace 即服务”

向下：复用成熟的盘古存储底座与文件存储服务

AgenticFS 的存储层不是从零搭建，而是直接复用阿里云文件存储服务能力，后端物理集群采用全闪机型，基于盘古文件系统的分布式机制保障数据持久性。

盘古文件系统作为阿里云统一存储底座，在多副本冗余、数据强一致等核心能力上已经过多年规模化验证，AgenticFS 直接复用这套底座，意味着其稳定性、可靠性、数据持久性从第一天起就达到了与成熟云产品同等的水准。

文件存储服务在云服务特性上的积累——共享访问、弹性伸缩、POSIX 兼容性——也以 AgenticSpace 粒度继承下来，让 Agent 数据从进入 AgenticFS 的第一天起，就拥有完整的云服务能力，而非等待多年迭代才能补齐。

所以，AgenticFS 并非重新造一遍存储底座的轮子，而是在阿里云存储已有的成熟底盘之上，叠加 Agent 场景所需的规模、隔离、零信任能力。

图6：AgenticFS 基于已有存储服务构建 Agent 原生存储能力

横向：与阿里云基础服务深度集成，构建全链路可观测、可审计、可恢复体系

AgenticFS 不是封闭系统，而是与阿里云既有的安全、监控、备份服务深度耦合。

安全侧，与 RAM、STS、零信任深度集成，将平台级身份治理能力直接延伸到每个 Agent 工作空间——AgenticSpace，经由临时凭证签发、自动轮转、到期回收，纳入阿里云统一的安全审计与合规链路，无需平台方额外搭建鉴权体系。

监控侧，与云监控、SLS 集成，在 AgenticFS 和 AgenticSpace 两个粒度上交付容量监控、性能监控、元数据 QPS 监控和客户端粒度性能监控——支持 IOPS、吞吐、延迟、元数据操作 QPS 等核心指标，让 Agent 行为可分析。

备份侧，与 Cloud Backup 集成，提供 AgenticSpace 级别和 AgenticFS 级别的备份能力，支持不可变备份，防止 Agent 运行程序将备份也删除的极端场景。审计侧，与日志服务集成，交付完整的日志审计能力，支持合规溯源和 Agent 操作追踪。

AgenticFS 在阿里云 Agent 全栈图谱中的定位，可以用一句话归纳：它不是另一个孤立的存储产品，而是阿里云面向 Agent 时代的基础设施拼图中，负责“Agent 数据底座”那一块的关键拼图。 向上承接 Agent Runtime 的弹性存储需求，向下复用盘古和文件存储的成熟能力，横向打通云安全、监控、备份、审计服务——这是 AgenticFS 区别于其他存储产品的生态定位。

存储服务决定 Agent 落地平稳度

当文件系统的用户从人变成 Agent，变化的不仅是交互方式，更是整个存储范式的重构。规模从千级跃升到亿级，隔离粒度从文件系统级细化到目录级，安全模型从静态凭证演进到零信任——传统存储的“被动适配”已经走到了尽头。

存储服务跟上了，Agent 产业落地的齿轮才能转得更快。AgenticFS 的答案是：Agent 时代的存储不应是被动适配，而应是原生设计——让每个 Agent 都拥有独立、安全、弹性的工作空间，让 AI Agent 的产业落地真正站稳脚跟。