过去几年，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 的重点方向归纳为三类：
-
Sandbox Store：面向 Agent 沙箱运行环境，提供本地环境 rootfs 挂载、快照、启动恢复、状态保存等能力；
-
Artifact Store：面向 Agent 执行过程中的镜像、程序包、脚本、模型、输入输出文件和任务产物，提供持久化、共享、分发和访问能力；
-
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 时代的存储基础设施重构 | AI工具大全&导航
相关文章
