核心观点：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 的重点方向归纳为三类：
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
场景二｜多模态创作类 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 运行、协作与自我进化中不可或缺、且越用越智能的基础设施。
