# 面向Agent时代，存储基础设施如何重构？ Agent正在将AI从“回答问题”推向“完成任务”，存储也随之从“提供容量、承载文件”的资源层，升级为贯穿Agent运行、协作与持续优化的关键底座。火山引擎存储团队以Storage Agent Infra为载体，围绕Sandbox Store、Artifact Store、Agent观测&评测三大能力方向，重新组织存储能力，支撑Agent时代的真实业务。 过去几年，AI应用的形态正在快速变化。从早期的模型调用，到对话式助手，再到具备工具调用、任务执行、环境交互和长期记忆能力的Agent，AI系统正在从“回答问题”走向“完成任务”。这种变化不仅改变了上层应用的交互方式，也对底层基础设施提出了新的要求。 结合AI Agent场景的快速成熟和发展，AI驱动的数据Workload也在快速发生着演变。可划分为三个阶段： * **Training（训练）阶段，数据Workload特点是海量、大规模、高吞吐** * 海量Dataset数据集在对象存储中汇集，一个成熟模型在预训练阶段依赖的数据集规模可达到百PiB~EiB级别；Dataset中的数据类型依据模型特点所决定，例如各类高精度生图生视频模型会更依赖高质量的多模态数据素材； * 训练启动前会将Dataset从存储向上加载至GPU，训练启动后会周期性高频产生CKPT写入至存储，加载和写入都会跨越到TB/s级别的带宽；存储需要保障上述过程的性能和时效性，否则会导致训练GPU空转。 * **Inference（推理）阶段，数据Workload特点是低时延、高并发、KV化、高吞吐** * 推理服务面向用户实时交互，极致低时延是刚性指标，毫秒甚至微秒级的推理IO延迟都会直接影响端侧性能表现； * KVCache成为关键负载，每轮token的生成都会关联依赖KVCache。KVCache的命中率和时延会直接影响推理响应的TTFT和TBT；围绕超大规模的推理服务，KVCache的吞吐也会线性提升，重依赖KVCache在分布式扩展性、分层架构方面的落地能力。 * **Agent（智能体）阶段，数据Workload特点是场景多元化、批量高负载、可观测/自进化** * 相较于训练、推理的标准化算力负载场景，Agent应用阶段完全面向真实生产业务，场景碎片化、多元化特征突出，核心围绕智能体真实落地、业务闭环执行展开，所有负载能力均服务于Agent生产环境稳定运行与迭代进化； * 具备高频动态的环境沙箱与工作区读写需求，需要频繁创建、切换、销毁独立沙箱工作环境，产生大量临时性、场景化的环境数据、任务缓存、操作快照数据，对存储的灵活隔离、快速启停、轻量化读写能力要求极高； * 任务运行会持续生成文件、多模态Output数据，这类产物不再局限于单沙箱独立使用，存在极强的跨沙箱复用、共享、流转、公网访问需求，需要统一存储底座实现产物持久化留存； * 依赖全链路Trace观测与日志存储，Agent多轮对话、工具调用、逻辑决策、任务执行的全流程需要完整溯源记录，并支撑Agent的进化。 基于上述AI Workload的变化，也驱动了存储范式的演进： * **Content Storage** 面向Dataset、文档、图片、视频、日志等数据，核心命题是海量、持久化、冷归档与分发，目标是“把内容保存好”，对应过去十年围绕对象存储、并行文件系统和冷热分层建立起来的成熟范式； * **State Storage** 则面向Checkpoint / Optimizer State、KVCache / Embedding、Environment / Memory / Trace等执行状态，核心命题是短生命周期张量与上下文的高速流转、秒级恢复和低成本分叉，目标是“把系统状态维持住”。 上述两种范式的变化，并非简单的数据规模差异，而是在数据形态（文件 vs 数百MB~数十GB的短生命周期状态块）、IO模式（带宽敏感的顺序批扫 vs 延迟敏感的随机流转）、SLO要求（秒级可用 vs 毫秒/微秒级不可失）与成本结构（可冷热分层 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的重点方向归纳为三类： 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时代，技术平权，开发方式在变化，借助大模型、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时代，数字世界交互方式也在被重构——人与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承担了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运行、协作与自我进化中不可或缺、且越用越智能的基础设施。**