系列定位： 本文是 《从 Data Lake 到 State Lake：面向 Agent 时代的存储基础设施重构》 的续篇。上一篇讲了 Agent 时代重新组织的三条存储主线：Sandbox Store、Artifact Store、Agent 观测 & 评测。这一篇聚焦最“面向用户”的一条支线——存储产品自身的 Agent 化，我们称之为 Storage Agent Family。一位做 AI

核心观点： Agent 正在把 AI 从"回答问题"推向"完成任务"，存储也随之从"提供容量、承载文件"的资源层，升级为贯穿 Agent 运行、协作与持续优化的关键底座。火山引擎存储团队以 Storage Agent Infra 为载体，围绕 Sandbox Store、Artifact Store、Agent 观测 & 评测三大能力方向，重新组织存储能力，支撑 Agent 时代的真实业务。过去几

"Agent 进入生产环境的下半场，比拼的不再只是模型，更是 Agent 与上下文之间的关系是否被系统性组织起来。ContextBucket 的使命，是让 Agent 的记忆与工作区长在同一个底座上——记得住、找得到、带得走。"过去一年，Agent 正在从聊天 demo 走向生产系统：进入研发流水线写代码、嵌入运营平台做分析、接入客服后台处理工单。它们不再是开几轮对话就关掉的玩具，而是要在终端、协

AIGC 技术爆发促使大模型从实验阶段迈向企业级大规模应用，但它任务耗时久、算力成本高、流量波动大、智能体协作复杂这些核心特点，给底层通信和调度基础设施带来了严峻挑战，企业通常会遇到长会话连续性不佳、算力调度效率低、多智能体协作不可靠等问题。作为火山引擎消息中间件产品矩阵之一的RocketMQ，目前结合社区已有方案完成了 AI 原生能力升级，推出了 RocketMQ For AI 解决方案。该方案

当一个 OpenClaw 应用从本地 Demo 走向生产环境，Agent助手/xClaw企业的开发和运维团队面临的挑战便不再是“能不能跑”，而是“跑得稳不稳、贵不贵、出了事能不能查清”。Agent 运行过程如同一个黑盒，这导致了一系列现实问题：Token 成本不明： 无法精细化衡量不同模型、不同技能（Skill）或不同业务场景下的 Token 消耗，成本账单模糊，优化无从下手。多轮对话追踪困难：

本文主要介绍火山引擎日志服务（TLS）为 Hermes Agent 构建系统化可观测能力的完整过程，覆盖成本归因、性能拆解、稳定性监控与 Trace 链路追踪，并提供一键部署方案。在引入统一可观测方案之前，Hermes Agent 的排障手段主要依赖两类数据源：一是运行过程中产生的零散日志，二是本地的 状态数据库。零散日志的问题在于缺乏统一结构。日志内容格式不一，想做趋势统计或者根因分析时，基本

过去这一年里，火山引擎存储在产品能力、成本优化与行业实践上都交出了一份亮眼的答卷：从支撑海量视频与大模型训练的数据底座，到帮助更多企业完成从传统存储向云原生、智能化的平滑演进，我们在性能、稳定性与易用性上持续打磨，只为让每一份数据都“存得下、找得到、用得好”。本文将以年度盘点的方式，带你回顾火山引擎存储的关键里程碑与典型客户价值，并附上一支基于 Seedance 2.0 制作的小视频，用更生动的方

AI Agent 如雨后春笋般涌现的今天，开发者们正以前所未有的速度构建着充满想象力的智能应用。从能帮你编写代码的编程助手，到一句话生成一部电影的创作工具，再到时刻待命的个人智能助理，Agent 正在重塑我们与数字世界的交互方式。这股浪潮背后，一个共识日益清晰：借助 Serverless 架构（如 Lambda）、大语言模型（LLM）和云存储（如 S3、TOS），结合 Vibe Coding，任何

随着 OpenAPI 生态的日益繁荣，为了提供极致的开发体验，火山引擎对象存储 TOS 面向 Java、Python、Go、C++、Rust 等十余种主流编程语言提供了全栈 SDK 支持。然而，多语言架构与多角色协作的内生复杂性，使得 SDK 的维护工作变得异常繁杂。尤其在 OpenAPI 持续迭代的背景下，任何细微的接口变更都会在下游引发连锁反应。若无法保障功能实现、技术文档与多技术栈的一致性，

火山引擎日志服务（TLS）是 Log、Trace、Metric、Event 等泛文本数据的一站式存储分析平台，包含采集、存储、检索分析、加工、消费、投递、监控告警、可视化等功能。围绕企业在云原生服务与 AI 时代的核心需求，日志服务 TLS 作为数据分析底座，已服务多种典型业务场景：运维可观测： 统一采集存储各基础设施、网络、云产品、业务系统、应用程序、大模型、Agent 等各层面的 Log/Tr

"在云计算的下半场，向量数据库将成为 AI 基础设施的核心。谁掌握了向量数据，谁就掌握了 AI 时代的数据引力。TOS Vectors 的使命，就是让每个企业都能轻松驾驭海量向量数据，释放 AI 的无限潜能。"传统的信息检索方式，更多是依赖关键词匹配。比如你在搜索框里输入“新能源车”，搜索引擎可能会优先返回包含“新能源”和“汽车”两个关键词的页面。但是问题在于如果有人写的是“电动车”，可能就错过了

在当前的大模型、推荐系统和 AI Agent 等热门技术中，“向量”成为了实现落地的关键。传统的搜索依赖关键词匹配。例如，搜索“新能源车”可能错过提到“电动车”或“绿色出行”的内容。这种方式的局限在于检索引擎看不懂语义。而向量不同。当文本被转化为向量时，其含义被编码在高维空间中。在这个语义空间里，“新能源车”和“电动车”的向量会非常接近，即使字面上完全不同。这意味着机器第一次具备了理解“意思”的能

文件存储 vePFS，是火山引擎推出的一款并行文件存储服务，具备高吞吐、低延时、可扩展的特性。其核心优势在于拥有极致的性能表现，并且与火山引擎的各类计算产品，共同构建了成熟的配套解决方案，是 AI 大模型、自动驾驶、高性能计算（HPC）等场景的首选高性能文件系统。在 AI 大模型与自动驾驶等前沿领域，海量数据正以前所未有的速度涌入文件存储。然而，传统文件存储如同“黑箱”，管理者难以洞悉其内部运行状

在 Data+AI 时代，我们正处在一个由数据驱动创新的新纪元。尤其是在生成式 AI 和智能驾驶等前沿领域，海量数据的产生、流动与存储已成为推动技术突破的核心引擎。然而，数据的爆炸式增长也给传统的存储方案带来了前所未有的挑战，面对 AI 时代“海量容量、超大规模、并发密集”的极致需求，传统的文件存储与对象存储逐渐打破各自独立的界限，高性能文件存储与海量对象存储紧密结合、文件与对象统一访问的模式正在

在 AI 浪潮下，无论是追求技术突破的 AI 算法公司，还是致力于自动驾驶的研发团队，都面临同一"隐形杀手"——存储带宽瓶颈。这个看似不起眼的问题，却可能让你的智能化项目功亏一篑。AI 业务对数据传输的“爆发性”与“连续性”有着极高要求，带宽不足会使研发效率断崖式下降：大模型训练：在千亿参数大模型训练时，需向 GPU 集群传输百万级别的样本（单轮数据量超 10TB）。若带宽传输与算力读取速度不匹配

在 AI 浪潮中，大模型训练与推理正以前所未有的速度推动计算能力突破极限。从自动驾驶 PB 级数据洪流到生成式 AI 微秒级推理响应，算力竞速已成为科技前沿的焦点。而数据管理和访问性能，也已成为决定 AI 训练效率、推理速度的核心要素。传统文件存储在面对 AI 时代 “数据密集、并发密集、场景复杂” 的极致需求时，逐渐显露出力不从心的一面，成为制约 AI 算力释放的瓶颈。性能与容量强绑定：资源利用

JuiceFS 是一款面向云原生设计的高性能分布式文件系统，在 Apache 2.0 开源协议下发布。提供完备的 POSIX 兼容性，可将几乎所有对象存储接入本地作为海量本地磁盘使用，亦可同时在跨平台、跨地区的不同主机上挂载读写。每个 JuiceFS 客户端都有访问日志，其中详细记录了文件系统上的所有操作，如操作类型、用户 ID、用户组 ID、文件 inode 及其花费的时间。访问日志可以有多种用

EIC 作为火山引擎的分布式 KVCache 方案，通过存储-计算解耦、资源池化、分层优化三大能力，解决了大模型推理中的内存瓶颈、高并发延迟、跨节点协同等问题，其应用场景可覆盖广告推荐、文本及多模态模型等基础推理生态，通过以存代算重构大模型的算力效率体系，推动 AI 规模化应用的成本优化与性能升级。本文将全面剖析推理框架技术原理，介绍 EIC 如何突破原生推理框架限制。近年来，豆包、Kimi、De

在大模型领域，随着模型参数规模的扩大和上下文长度增加，算力消耗显著增长。在 LLM 推理过程中，如何减少算力消耗并提升推理吞吐已经成为关键性优化方向。以多轮对话场景为例，随着对话轮数增加，历史 token 重算占比持续增长。实验数据表明（如图1），当每轮输入为 8k tokens 时，运行 6 轮后，历史 token 重复计算占比超过 80%，直接导致了 GPU 算力的冗余消耗。在此背景下，构建高

在上篇中，我们对 3FS 各个组件的实现原理进行了详细分析。这些分析给我们留下一个初步的印象：3FS 团队的目标并不是要研发一个可以在方方面面达到业界一流水平的全能型产品，更多的是在追求一个限定场景下的最优解，这个限定场景就是 DeepSeek 自己的大模型训推场景。在这篇文章里，我们从 AI 场景和其他场景中提炼出一些有代表性的典型 case，在元数据面和数据面两个维度上，对 3FS 和业界典型