# 面向Agent时代，存储基础设施如何重构？ Agent正在把AI从“回答问题”推向“完成任务”。存储也随之升级，从“提供容量、承载文件”的资源层，变为贯穿Agent运行、协作与持续优化的关键底座。 火山引擎存储团队以**Storage Agent Infra**为载体，围绕三大能力方向重新组织存储能力。这三大方向是：**Sandbox Store、Artifact Store、Agent观测&评测**。它们共同支撑Agent时代的真实业务。 ## AI应用形态快速变化，数据Workload加速演变 过去几年，AI应用的形态正在快速变化。从早期的模型调用，到对话式助手，再到具备工具调用、任务执行、环境交互和长期记忆能力的Agent。AI系统正在从“回答问题”走向“完成任务”。 这种变化不仅改变了上层应用的交互方式，也对底层基础设施提出了新的要求。 结合AI Agent场景的快速成熟，AI驱动的数据Workload也在快速演变。可划分为三个阶段： ### 训练阶段：海量、大规模、高吞吐 * **海量数据集**：在对象存储中汇集。一个成熟模型在预训练阶段，依赖的数据集规模可达百PiB~EiB级别。数据集中的数据类型依据模型特点决定。例如，各类高精度生图生视频模型，会更依赖高质量的多模态数据素材。 * **高频CKPT写入**：训练启动前，会将Dataset从存储向上加载至GPU。训练启动后，会周期性高频产生CKPT写入至存储。加载和写入都会跨越到TB/s级别的带宽。存储需要保障上述过程的性能和时效性，否则会导致训练GPU空转。 ### 推理阶段：低时延、高并发、KV化、高吞吐 * **极致低时延**：推理服务面向用户实时交互。极致低时延是刚性指标。毫秒甚至微秒级的推理IO延迟，都会直接影响端侧性能表现。 * **KVCache成为关键负载**：每轮token的生成都会关联依赖KVCache。KVCache的命中率和时延，会直接影响推理响应的TTFT和TBT。围绕超大规模的推理服务，KVCache的吞吐也会线性提升，重依赖KVCache在分布式扩展性、分层架构方面的落地能力。 ### Agent阶段：场景多元化、批量高负载、可观测/自进化 * **场景碎片化、多元化**：相较于训练、推理的标准化算力负载，Agent应用阶段完全面向真实生产业务。核心围绕智能体真实落地、业务闭环执行展开。所有负载能力均服务于Agent生产环境稳定运行与迭代进化。 * **高频动态的沙箱读写需求**：需要频繁创建、切换、销毁独立沙箱工作环境，产生大量临时性、场景化的环境数据、任务缓存、操作快照数据。对存储的**灵活隔离、快速启停、轻量化读写**能力要求极高。 * **产物跨沙箱复用与共享**：任务运行会持续生成文件、多模态Output数据。这类产物不再局限于单沙箱独立使用，存在极强的跨沙箱复用、共享、流转、公网访问需求。需要统一存储底座实现产物持久化留存。 * **全链路Trace观测与日志存储**：Agent多轮对话、工具调用、逻辑决策、任务执行的全流程，需要完整溯源记录，并支撑Agent的进化。 ## 存储范式演进：从Data Lake走向State Lake 基于上述AI Workload的变化，存储范式也驱动了演进。主要分为两种范式： ### Content Storage：把内容保存好 * 面向Dataset、文档、图片、视频、日志等数据。 * 核心命题是**海量、持久化、冷归档与分发**。 * 目标是“把内容保存好”。 * 对应过去十年围绕对象存储、并行文件系统和冷热分层建立起来的成熟范式。 ### State Storage：把系统状态维持住 * 面向Checkpoint / Optimizer State、KVCache / Embedding、Environment / Memory / Trace等执行状态。 * 核心命题是**短生命周期张量与上下文的高速流转、秒级恢复和低成本分叉**。 * 目标是“把系统状态维持住”。 **这两种范式的变化，并非简单的数据规模差异。** 而是在四个维度上的数据范式进化： 1. **数据形态**：文件 vs 数百MB~数十GB的短生命周期状态块。 2. **IO模式**：带宽敏感的顺序批扫 vs 延迟敏感的随机流转。 3. **SLO要求**：秒级可用 vs 毫秒/微秒级不可失。 4. **成本结构**：可冷热分层 vs 无“冷”态可退。 存储的角色因此**从“数据底座”升级为“状态底座”**，**从Data Lake走向State Lake**。 火山存储围绕AI Workload的驱动变化，已布局了从Training到Inference到Agent，从Data Lake走向State Lake完整的产品能力规划和落地。本文重点围绕火山存储在Agent应用领域，从Data Lake走向State Lake的落地之路。 ## 一、Agent应用生态整体架构 ### Agent应用的多层次抽象 从工程视角看，Agent应用可以抽象为多个层次： * **底层**：算力、控制面和环境接入面。 * **中间层**：运行时引擎、工具路由、记忆管理和控制循环。 * **上层**：具体的Agent应用、工作流和产品封装。 在这个体系中，**存储能力贯穿多个关键环节**。 ### Storage Agent Infra三大方向 围绕火山引擎客户各类Agent应用的运行特点，火山引擎存储团队将Storage Agent Infra的重点方向归纳为三类： 1. **Sandbox Store**：面向Agent沙箱运行环境，提供本地环境rootfs挂载、快照、启动恢复、状态保存等能力。 2. **Artifact Store**：面向Agent执行过程中的镜像、程序包、脚本、模型、输入输出文件和任务产物，提供持久化、共享、分发和访问能力。 3. **Agent观测&评测**：面向Agent执行过程中的日志、Trace、Session、评测数据和实验结果，支撑观测、评测和持续优化闭环。 这三个方向分别对应Agent生命周期中的不同阶段： * **Sandbox Store**：关注Agent“在哪里运行”以及“如何快速、稳定地恢复运行环境”。 * **Artifact Store**：关注Agent“读写什么数据”以及“任务产物如何保存、共享和分发”。 * **Agent观测&评测**：关注Agent“运行得怎么样”以及“如何基于数据持续改进”。 它们共同构成了Storage Agent Infra的基本框架。 ## 二、Storage Agent Infra的三大能力方向和存储智能化 ### 2.1 Sandbox Store：让Agent沙箱更快启动、更好恢复 Agent的一个重要特点，是需要在受控环境中执行任务。在代码生成、数据处理、模型评估、多模态任务等场景中，Agent往往需要一个相对完整的运行环境。它要能够安装依赖、执行脚本、读取输入、生成输出，并在必要时进行回滚、恢复或并行探索。 这使得沙箱不只是一个“计算环境”，其背后的状态保存、数据共享与会话通信，共同构成了Agent Infra中非常关键的一层。同时，沙箱在多种业务状态下的数据Workload变化，也推动Sandbox Store增加对各种Data State的支持。Sandbox Store也逐步扮演为沙箱视角下的State Lake。 #### 业务诉求 在业务需求上，Sandbox Store面临几类典型诉求： * **启动要快**：沙箱启动时延通常需要控制在较低水平，以保证Agent交互和任务执行体验。 * **状态要能保存**：在pause / resume、checkpoint、模型评估、任务重试等场景中，需要通过快照等机制保存沙箱状态。 * **容量要可控**：不同类型Agent对单沙箱容量的需求不同，但整体需要兼顾成本、密度和弹性。 * **隔离要清晰**：多租户场景下，需要在存储边界、权限、容量和性能上提供隔离能力。 * **恢复要灵活**：在跨机器、跨机房或批量调度场景中，恢复能力直接影响资源利用率和任务连续性。 * **通信中枢**：不同沙箱中的Agent协作、复杂任务长会话、高并发请求、海量租户隔离场景，通信机制更为关键。 #### 技术方案组合 围绕这些需求，Storage Agent Infra在Sandbox Store方向上重点规划了基于**EBS、EFS和MQ**的能力组合。 **通用沙箱rootfs场景** * 云盘**EBS**更适合作为基础方案。通过快照、延迟加载（Lazyload）、批量创盘和挂载优化等能力，支持沙箱快速启动、批量创建、pause / resume以及数据保护。 * EBS支持大规模高频快照、超长快照链、极速克隆。让Agent能随时存下当前状态、回退到任意一步。例如，在模型评估场景中，Agent可以在每一步推理或实验后保存快照。如果某一步结果不理想，就可以基于前序快照重新拉起沙箱，调整模型参数或实验配置，从而支持更高效的并行探索和对比评估。 **多Agent并行实验、共享工作区和弹性容量等场景** * **EFS**可有效补齐EBS在共享与协同场景下的能力边界。它提供高性能、弹性扩展的共享存储空间，具备完整POSIX语义，以及目录级访问隔离、目录级配额、目录级数据流动和共享挂载等能力。能够更好承载多沙箱、多Agent并行实验过程中，对共享数据集、工作目录和中间结果的统一访问与管理需求。 **通信中枢需求** * **MQ LiteTopic**：会话级隔离与强顺序。为每一个Agent会话分配独立的消息主题，确保会话隔离，同时保持上下文严格顺序，为模型提供高质量交互源。 * **海量并发与高效调度**：百万级LiteTopic动态创建与自动释放机制，支持海量会话并发的弹性。基于优先级消息，实现异步调度、支撑Multi-Agent协作、长会话任务的高效准确的调度。 **这套组合的本质，不是选择某一种存储介质，而是按Agent沙箱的运行状态特征做分层协同：** * **EBS**：承载沙箱本地状态，聚焦快速启动、快照恢复与强隔离。 * **EFS**：补齐共享、弹性与POSIX文件能力，支撑多沙箱协作。 * **MQ LiteTopic**：打通会话通信，以会话级隔离和弹性调度支撑长会话、高并发的交互链路。 三者分别覆盖沙箱的“状态、共享、通信”三个面，共同构成Sandbox Store的数据底座。 ### 2.2 Artifact Store：承载Agent的输入、输出与任务产物 如果说Sandbox Store解决的是Agent的运行环境问题，那么**Artifact Store**解决的就是Agent执行过程中的数据流转问题。 Agent在执行任务时，会持续消费和生成各类文件。它可能读取用户上传的文档、图片和数据集，也可能生成代码包、报告、模型结果、多媒体文件或中间产物。这些内容既需要在Agent内部被访问，也需要在用户、团队和其他系统之间共享。 #### 业务需求特点 从业务需求看，Artifact Store具有几个明显特点： * 文件大小通常集中在**KB到MB级**，部分任务类场景会产生更大的文件。 * 吞吐需求整体不一定持续很高，但会出现**任务型burst**。 * 多数场景不需要pause / resume，但需要**多租户挂载、公网上传和分发**。 * 在Coding、轻量数据库、小文件密集修改等场景中，会出现**POSIX语义诉求**。 * 产物需要支持**用户访问、团队协作、智能检索和长期保存**。 #### 两类技术路径 围绕这些特征，Storage Agent Infra在Artifact Store方向上形成了两类路径： **第一类：面向强POSIX语义和高性能读写诉求的场景** * **强文件语义**：**EFS**天然适合承载对文件系统POSIX语义、并发访问性能和本地目录体验要求较高的Agent业务。存储在EFS中的文件可通过标准目录树统一管理，使用体验与本地文件系统保持一致。同时，EFS提供接近完整的POSIX语义兼容能力，支持rename、文件锁、软硬链接、Close-to-Open一致性等关键语义，能够更好适配依赖标准文件系统能力的Agent工具链。 * **高性能**：EFS能够应对Agent业务高并发、强波动的访问特征。针对性能下限保障，EFS支持配置预置带宽，确保业务在关键阶段获得稳定的数据访问能力。针对突发性并发访问，EFS面向Agent场景提供突发带宽能力，在千万级Agent并发访问时最高可获得**2TB/s**访问带宽。对于git clone、tar解压等典型小文件密集读写场景，EFS可提供**亚毫秒级时延**和最高**3000万IOPS**，帮助提升Agent启动、依赖拉取、任务执行和产物生成效率。 * **数据流动与降本**：在数据生命周期管理上，EFS的数据流动能力可以同时满足Agent产物的降本与分发需求。Agent产物在生成阶段和高频访问阶段需要高性能文件访问，但长期不访问后会带来不必要的存储成本。通过数据流动，冷数据可自动淘汰至TOS，释放EFS存储成本。同时，淘汰后的文件仍可通过EFS路径直接访问。对于需要立即通过URL访问的产物，也可以通过数据流动的沉降能力，即时写入TOS后，通过TOS API完成分发和公网访问。 **第二类：面向无强POSIX需灵活的数据分发生态的场景** 对象存储天然适合承载任务产物、模型文件、脚本包和多模态文件的存储、分发和公网访问。 火山引擎**TOS**面向Agent产物“数量爆发、形态多样、访问不均”的特征，提供海量、弹性、低成本的存储能力： * **海量**：采用扁平的对象命名空间与近乎无上限的横向扩展架构。单桶即可承载从千万到亿级乃至更高规模的对象，轻松容纳Agent在长期运行中持续生成的多模态文件与中间产物。开发者无需为容量规划和分库分桶操心。 * **弹性**：存储容量与吞吐按实际用量自动伸缩。天然契合Agent产物生成“平时平稳、任务型突发（burst）”的访问特征。高峰时可弹性支撑大规模并发读写与分发，低谷时不产生额外资源占用，避免了为峰值预留容量带来的浪费。 * **低成本**：以按量付费和规模效应显著摊薄单位存储成本。配合多档存储类型（标准/低频/归档/冷归档），可将不同访问热度的产物匹配到相应价位的存储层。在保证可用性的同时，把长期留存成本降到最低。 * **易运维**：TOS在可运维性上，同样为海量产物的长期治理提供了完善能力。通过生命周期，可按前缀、标签、创建时间等条件自动执行存储类型转换和删除，让冷、热产物在无人干预的情况下持续、自动地流转和清理。结合版本管理、事件通知、访问权限与审计等能力，Agent产物的写入、访问与回收得以形成闭环治理。 #### 面向亿级Agent用户的统一基建 在上述两类场景基础上，另一个变化也在快速发生。 Agent时代，技术平权，开发方式在变化。借助大模型、Serverless架构，可快速搭建AI Agent。但从demo迈向“生产级应用”，用户数演进到万级、百万级甚至亿级时，存储管理复杂度指数级提升。多租隔离、权限、Quota管理等变成难题。 火山存储Artifact Store整体会以**Agent Bucket**为统一基建，为亿级Agent用户时代的到来做好充足的准备。 Agent Bucket是火山引擎TOS推出的**亿级Agent原生存储桶**，也是火山引擎在国内存储领域又一引领业内趋势的前瞻性布局。Agent Bucket通过在传统Bucket → Object两层模型中引入AI原生资源层级**ObjectSet**，让Agent时代的“开发者”无需自建复杂中间层，即可为亿级终端用户提供安全、隔离、Quota、管理的专属存储空间，助力Agent从“demo”走向“生产级应用”。 #### 多模态产物与上下文支持 **进一步，TOS针对多模态产物、Agent上下文场景，推出了SenseFlow、ContextBucket功能。** * **SenseFlow多模态理解与处理引擎**：让产物从“存下来”，进一步走向“被理解”。数据不出桶，即可感知与处理。预置模板与算子编排，支持多模态处理、内容理解、智能检索与生成链路，并与TOS权限和事件通知天然打通。这使得任务产物不再只是静态文件，而是可感知、可检索、可加工、可消费的数据资产。 * **ContextBucket**：面向Agent的记忆与工作区诉求。把Agent的长期记忆与工作区收敛到同一个底座上，做到“记得住、找得到、带得走”。它让上下文与中间状态得以跨任务、跨会话持续沉淀。Agent在长周期任务和多轮协作中，可以随时回到既有记忆和工作区，而不必每次从零构建。 #### 专为Agent与人协同而生：ADrive — Agentic智能网盘 Agent时代，数字世界交互方式也在被重构。人与Agent之间的协作与共享，呼唤全新的基础设施。火山引擎推出**ADrive — Agentic智能网盘**，专为Agent与人协同而生。 ADrive是为Agent平台提供**可挂载、可访问、可管理、可共享**的持久化存储层，解决四个核心问题： * **Agent产物持久化与共享**：代码、报告、图片、数据文件等Agent产出，不再散落在临时工作目录中。ADrive自动持久化每一份产物，让它们可追溯、可检索、可共享，构建持续积累的个人知识库。 * **Agent存储管理与多租户隔离**：支持将ADrive Space映射/挂载为Agent工作目录或存储扩展，支撑海量租户（千万级至亿级）的隔离。每个Agent实例拥有独立的存储空间，安全可控。 * **Agent & 人无缝协同**：打通跨Agent产品挂载同一空间、本地盘符挂载同步、客户端与CLI/Skill多端访问。Agent读取与生成，人查看、编辑、分享与审计。统一的工作空间闭环，让人与Agent真正协作。 * **Agent数据智能检索与再创作**：用户或Agent以自然语言检索文件，系统快速返回匹配结果与内容概览。AI助手基于Agent产出文件进行摘要、改写与二次创作。基于知识库内容智能问答，答案精准溯源至原始文件。 **这意味着，Artifact Store并不只是一个“文件存储服务”。** 它是在Agent与人、Agent与Agent、Agent与平台之间，提供统一的数据承载、理解与记忆入口。产物既存得下、又理解得了、还记得住。 ### 2.3 Agent观测&评测：让Agent形成持续优化闭环 Agent系统与传统应用的一个重要差异在于：它的运行结果并不总是可以通过固定规则判断。一次Agent任务是否完成得好，可能取决于中间推理路径、工具调用结果、上下文使用方式、模型输出质量以及最终用户反馈。 要持续提升Agent的能力，就必须对执行过程进行记录、观测、分析和评测。因此，Storage Agent Infra将观测到评测的闭环作为重要方向之一。 #### TLS AgentLoop：从黑盒结果到可观测数据资产 **TLS AgentLoop**承担了Agent观测、数据飞轮平台能力，并打通评测进化。它可以围绕Agent执行过程，提供： * 观测数据接入 * Trace调用链/Session分析/监控大盘等观测数据 * 数据处理与Trace回流 并与Cozeloop合作，打通评测集/评估器管理/评估实验。 TLS AgentLoop，将Agent的运行过程，从“黑盒结果”转化为“可观测、可分析、可评测”的数据资产。 * **对于研发团队**：这可以帮助判断不同版本Agent的效果变化。 * **对于平台团队**：这可以帮助发现系统瓶颈、工具调用异常和任务失败原因。 * **对于业务团队**：这可以帮助持续优化Agent的任务完成质量。 更进一步，围绕**Ops Agent**的规划也体现了类似思路：通过日志、指标和观测数据，支持异常巡检、智能分析、问题诊断、修复建议和Runbook联动，推动企业运维工作向Agent化演进。 ### 2.4 从存储系统到Agentic Teammate Storage Agent Infra的另一个重要方向，是让存储团队自己也成为这套基础设施的使用者。 在规划中，火山引擎存储团队提出了**Storage Agent Family**的思路：围绕TOS、EBS、TLS、EFS、MQ等存储和中间件产品，逐步建设面向用户和工程师的智能助手能力。 #### 智能助手能力 这些Agent可以提供预置专家能力，包括： * 存储运维 * 方案选型 * 洞察分析 * 知识库问答 * 日志与报表总结 #### 安全与扩展 * **安全围栏**：默认内置安全围栏，在高危操作中引入Human in the loop或直接拦截，保证Agent运行始终处于业务安全范围内。 * **自定义能力**：支持用户自定义技能和自定义知识库，适配不同产品与用户场景。 Storage Agent还支持**记忆进化能力**。Agent回复后，用户确认对/错，可选择将其沉淀为记忆/知识，方便后续自动复用。 **这代表了一个更长期的方向：** 存储系统不只是被Agent使用，也可以通过Agent化能力提升自身的可用性，让你的Agent越用越“聪明”。 换句话说，**Storage Agent Infra既是Agent应用的底层存储基础设施，也是存储产品走向智能化、助手化和协作化的重要支点。** ## 三、三个真实场景：能力如何落地 Storage Agent Infra的前三大能力方向落到业务一线，会变成更具体的工程问题。推理链路需要反复快照、Input/Output需要资产化管理、人与Agent的协作空间需要产品化。下面通过三个典型场景，看这些能力如何组合起来支撑真实的Agent业务。 ### 场景一｜研发测试类Agent 在单次开发调试链路中连续记录快照，支持基于任一历史状态回滚、切换分支/依赖并重跑。这依赖基于**EBS高频快照**所实现的版本回溯能力，以及沙箱的pause / resume机制作为底层支撑。 ### 场景二｜多模态创作类Agent Input素材先预处理再入库，Output素材生成后沉淀、回传，并支持公网访问。对应**Agent Bucket on TOS**、Input/Output资产库与分发能力。 ### 场景三｜智能办公类Agent 用户素材留在User空间，Agent协作内容进入Claw空间，团队共享访问并用AI Search检索。背后依赖**ADrive智能网盘**的双空间、协作与检索能力。 三个场景把Sandbox对启动、快照、恢复的即时要求，与Artifact对多租、共享、分发、检索的持续要求同时压实。 ## 四、面向Agent时代，重新理解存储基础设施 Agent带来的真正变化，不只是新增一类负载，而是**重塑存储的服务对象与价值边界**。当AI从“回答问题”走向“完成任务”，存储要承接的已不再是静止的文件，而是持续流动的任务、状态、上下文与产物。 存储的价值坐标，也因此从“提供了多少容量”，转向“托住了多少状态、参与了多少闭环”。**它从被动的数据底座，成长为主动的状态底座。** 这也意味着，衡量一套存储基础设施是否面向Agent，标准不再是单点的容量、带宽或时延。而是它能否在Agent的完整生命周期中始终在场： * **环境**：要能秒级拉起与恢复。 * **产物**：要能被理解、被检索、被记忆。 * **运行过程**：要能被观测、被评测、被反哺。 Storage Agent Infra的意义正在于此。火山存储以**Sandbox Store、Artifact Store、Agent观测&评测**三条主线为骨架，把EBS、EFS、TOS、ADrive、TLS、MQ等能力按Agent的运行状态特征重新编排。让离散的存储介质凝聚为一个“理解任务、承接状态、参与闭环”的有机整体。 更进一步，当存储团队让自身也成为这套基础设施的使用者，存储便完成了一次角色跃迁：**从被Agent调用的资源，变为与人和Agent并肩协作的Teammate**。存储不再只是任务链路末端的落点，而是能感知、会分析、可进化的一环，在使用中持续变得更聪明、更可靠。 这正是“从Data Lake走向State Lake”的深层含义：**存储的终局，不是更大的湖，而是更懂业务的底座。** **面向Agent时代，火山引擎存储团队将沿着这一方向持续演进，让存储真正成为Agent运行、协作与自我进化中不可或缺、且越用越智能的基础设施。**