当 AI Agent 重新发明文件系统：从"一切皆文件"到"一切皆上下文"

引子：谁在管理 Agent 的 RAM？

Andrej Karpathy 在 2023 年提出过一个精妙的类比：LLM 是 CPU，context window 是 RAM，prompt 是程序。这个比喻迅速成为行业共识，但很少有人追问下一步：谁管理这块 RAM？谁决定什么进出？当程序执行完毕，状态保存在哪里？

在真实的计算机里，答案是操作系统。操作系统管理进程调度、内存分配、文件系统、设备驱动。CPU 和 RAM 只是执行层，OS 才是让一切有序运转的底座。

那么 Agent 的"操作系统"在哪里？

2025 年下半年开始，几个信号表明行业在认真对待这个问题。

LlamaIndex 创始人 Jerry Liu 公开表示，Agent 架构正在"从数百种工具转向文件系统加 5-10 种工具"。LlamaIndex 打出的口号更直白，"Files Are All You Need"。差不多同一时间，LangChain 也在做类似转向：用文件系统做上下文工程，而不是在框架层堆砌越来越多的抽象。

这不是两个框架公司的产品策略。推导链是这样的：Agent 框架最初把所有状态塞在 context window 里，但窗口很快不够用。框架开始在应用层做状态管理，每个框架发明自己的方案，代码复杂度急剧上升。当 LlamaIndex 和 LangChain 同时转向文件系统，背后的判断是：与其在每个框架里重复实现状态管理，不如依赖一个已有的、被验证过的抽象层。但文件系统的设计假设（人类用户、4KB 块、树状目录）和 Agent 的实际需求之间存在系统性矛盾。框架选择文件系统是因为它是"现有的最接近的抽象"，不是因为文件系统真的合适。这意味着矛盾会很快暴露，底层存储架构需要适配 Agent 的工作模式。

从信息管理的视角看，正在发生的是一次范式迁移：从"一切皆文件"（everything is a file），走向"一切皆上下文"（everything is context）。

这不是预测。FMS 2026（Future of Memory and Storage，8 月 4-7 日，圣克拉拉）官方议程里，IBM 在讲 Cognitive File System，NVIDIA 在讲 Storage-Next 架构，Anthropic 的 Managed Agents 已在生产环境运行一种全新的状态持久化模式。这些方案的共同点：重新定义 Agent 和数据之间的接口。

---

一、为什么 POSIX 文件系统不够用

1.1 上下文窗口 ≠ 记忆

Karpathy 的 CPU/RAM 类比藏着一个陷阱：RAM 是易失性的。断电即丢失。

Agent 的 context window 也是如此。一个 Agent 在一次会话中处理了 50 个工具调用、读了 20 份文档、写了 3 段代码，全部在 context window 里。会话结束，window 清空，一切消失。

Agent 因此面临一个经典的计算机科学问题：工作内存（context window）和持久存储之间存在一道鸿沟。 工作内存快但小且易失，持久存储慢但大且可靠。中间需要一层管理系统来决定什么放在哪里、什么时候搬运、什么时候丢弃。

在传统计算中，这层管理是操作系统内核做的事，虚拟内存、页面调度、mmap、swap。在 Agent 计算中，这层管理目前几乎不存在。多数 Agent 框架的做法是：要么全塞进 context window（直到超长），要么写一个 JSON 文件到磁盘（下次启动时读回来）。没有中间层。

1.2 Agent vs 传统文件系统设计假设

Unix "一切皆文件"诞生于 1969 年，针对人类用户和批处理工作负载。具体来看这些设计假设在 Agent 场景下怎么失效：

树状目录路径：人类靠目录层级组织文件，是因为人类靠"在哪里"来记忆和检索。Agent 的检索方式完全不同，它靠语义相关性找信息（"我上一步调用 search API 返回的结果"），不靠路径。给 Agent 一个 /home/user/agents/instance-42/step-23/tool-output.json 的路径，它并不"理解"这个路径，它需要的是内容本身和内容与其他状态片段的关联。

4KB 块粒度：OS 页大小和 HDD 扇区的产物。Agent 状态片段典型大小 512B-1KB，远小于一个块。写一个 512B 片段，SSD 要读出整个 4KB 块、修改其中 512B、重新编码纠错码、写回去，相当于为了改一个字擦写整页纸。

POSIX 语义：open/read/write/close 是为人类编程模型设计的接口。Agent 的状态访问模式是 append（追加新事件）、snapshot（周期性快照）、replay（从某点重放），和 open/read/write 并不对应。

强一致性：多进程协同需要所有进程同一时刻看到同一状态。但 100 个并发 Agent 各自更新自己的独立状态，强一致性引入的全局排序开销是不必要的。

1.3 IO 粒度翻转：4KB → 512B

传统 AI 推理的 IO 模式单一：启动时加载模型权重（大块顺序读），推理时偶尔读取输入。存储行业优化方向一直是带宽（GB/s）。

Agent 打破了这个模式。一个 Agent 循环（观察环境 → 推理决策 → 调用工具 → 获取结果 → 更新状态），每一步都产生与传统推理不同的 IO：

多 Agent 并发执行时，这些操作叠加成大量细粒度随机 IO。

FMS 2026 上，Microchip 技术 Fellow Peter Graumann 给出精确量化：

当前 SSD 按 4KB 块边界操作，但 AI 工作负载在 512B 或 1KB 粒度操作。

这个数字来自 FMS 2026 Microchip 演讲。从第一性原理也可以验证：Agent 的典型状态片段是一个工具调用的返回值或一个推理中间结果，JSON 序列化后通常在 200-800 字节范围。这与 4KB 的存储块之间形成了 4-8 倍的粒度差。

SSD 的 FEC（前向纠错）以 4KB 为最小单元，NAND 闪存物理页大小和纠错算法的设计基线。Agent 要写一个 512 字节状态片段，SSD 实际需要读出整个 4KB 块、修改其中 512 字节、重新编码纠错码、再写回去。写放大在 Agent 工作负载下急剧恶化。

跨越这个 8 倍的粒度差，需要重新设计 SSD 块结构。

---

二、四条技术路线

路线 1：POSIX 文件系统直接给 Agent 用

设计哲学：不重新发明轮子。Agent 就是一个程序，程序用文件系统天经地义。

代表实践：Claude Code、Cursor、OpenClaw、大多数 Agent 开发框架。

目前最主流的模式。Agent 运行在标准操作系统环境里，通过 read/write/exec 系统调用操作文件。Agent 框架在文件系统之上叠加自己的抽象，但底层完全依赖 POSIX。

优势：零基础设施成本；生态兼容（git、grep、make 都能用）；开发者熟悉。

劣势：状态管理完全依赖应用层，每个框架做法不同，没有标准；高频小文件写对 SSD 的 WAF（写放大因子）不友好；多 Agent 协作时无隔离或一致性保障。

判断：务实的短期方案，但把所有复杂性推给应用层。具体会在哪里 break：当 Agent 从单机走向分布式——两个节点上的 Agent 实例需要共享状态文件，POSIX 的 NFS locking 机制（fcntl/lockf）在广域网下的延迟和可靠性都不足以支撑 Agent 的交互频率（每秒数十次状态读写）。当 Agent 从短时走向长时运行，单个 Agent 产生数万个状态文件，文件系统的目录项索引在大规模小文件场景下的查找性能急剧下降（ext4 的 htree 在单目录超过 10 万文件后查找延迟非线性增长）。这些都是实际部署中已经碰到的墙。

路线 2："一切皆上下文"文件系统

设计哲学：文件系统不被替代，而是被抽象掉。Agent 直接消费的是上下文，文件形态被隐藏在抽象之下。

代表实践：arXiv 论文《Everything is Context》；LlamaIndex 的实践方向。

Agent 消费信息的方式不是"打开文件、读取内容"，而是"获取一段上下文、纳入推理"。Agent 不关心信息来自文件、数据库还是 API，它关心的是这段信息和当前任务的相关性。

技术要点：内容寻址存储（数据块用 hash 标识）；自动版本化（每个 Agent step 是一个 commit）；上下文组装器（Context Assembler），根据推理需求从存储池检索相关片段，动态组装成 context window 内容。

优势：最贴合 Agent 信息消费模式。

劣势：纯学术概念，缺少生产级实现；上下文组装延迟可能不可接受；退出 POSIX 兼容意味着现有工具链失效。

判断：最激进的路线，正确指出 Agent 需要的不是"文件"而是"上下文"。更可能的情况是核心思想被其他路线吸收。

路线 3：Cognitive File System

设计哲学：改造文件系统本身，让它具有"认知"能力。

代表实践：IBM Cognitive File System（FMS 2026 正式提案）。作者 Viacheslav Dubeyko，IBM 员工、Linux 内核开发者。

Dubeyko 2019 年在 arXiv 发表前作《File System in Data-Centric Computing》。FMS 2026 提案是这个思路在 Agent 时代的延伸。

IBM 在 FMS 2026 议程中的关键表述：

"AI agents become a new customer of digital data."

"completely new technological foundation for computation offloading in storage space, adopting ML models for data analysis/processing, and provide a flexible interface for more efficient interaction among AI agents and data."

其余设计要点：用户可以照存原始数据流，不需要给文件起名字。认知子系统自动检测数据流中的重复模式，建立关系字典，让不同数据流之间像关系数据库一样互相关联。这些能力被放在 Computational Storage Track，说明 IBM 认为认知文件系统与计算型存储是一体的。

核心技术主张：

1. 去掉文件名作为必需寻址方式。Agent 可存储数据流而不必分配名字。系统通过模式识别组织和检索数据。直接挑战 Unix 文件系统五十年来的基本假设。

2. 认知子系统自动发现重复模式。系统持续分析流入数据，检测重复模式，建立"关系字典"。模式成为连接不同数据流的关键词。文件系统自己做特征工程和关联分析。

3. 存储空间内做计算卸载。不只存数据，还在数据所在位置执行计算，用 ML 模型分析、提取特征、返回结果。

4. 为 AI Agent 和数据之间提供新接口。不同于 POSIX 的 open/read/write，提供 AI-native 的数据访问接口。

优势：内核级方案，对 Agent 透明；文件系统自己做数据分析，减少数据搬运。

劣势：改造文件系统内核是最慢路径，从提案到生产可能 3-5 年；认知子系统本身的计算开销是否可接受尚不清楚；目前处于概念验证阶段。

判断：长期路径。价值在于指出正确方向，文件系统应该理解它存储的数据。短期内更可能启发其他方案的架构设计。

路线 4：绕过文件系统，日志、沙箱、microVM

设计哲学：放弃改造文件系统，直接绕过它。Agent 状态管理需要的是事件日志、快照、隔离。

代表实践：Anthropic Managed Agents（已在生产环境运行）。

由三层组成：

Session 作为 Append-Only Durable Log：Agent 的每次操作，每个 tool call、每次推理结果、每次状态变更，被 append 到持久化事件日志。这是持久化存储上的 append-only log。

和传统文件系统的根本差异：传统 FS 支持随机读写，append-only log 只能尾部追加。听起来是限制，实际上是好处：

• 不可变性：已写入事件不会被修改，天然支持回放（replay）。出错时可从日志任意位置重新开始。
• 因果顺序：日志顺序即事件发生顺序，天然满足因果一致性。
• 简化崩溃恢复：不需要 fsync、journal、fsck，崩溃后从最后一个 checkpoint 重放日志。

Harness ， 无状态执行器：完全无状态。每次执行：接收 sessionId → 从日志 replay 到最近 checkpoint → 加载到 context window → 执行 → 结果 append 到日志。任何 Harness 实例可执行任何 Agent 会话，不存在状态亲和性。调度灵活性等于无状态微服务。

Sandbox ， 每次工具调用一个全新 microVM：用完即焚。无状态泄漏，无跨调用文件系统污染，无权限残留。沙箱只有只读磁盘，工具调用结果被序列化后写回 Session 日志。

效果：据 Anthropic 2026 年 4 月 Claude Managed Agents 发布博客，相比自建 Agent 基础设施（无 Session 日志、无沙箱隔离的裸调用模式），p50 首 token 延迟降低 60%，p95 降低 90%。Anthropic 将改善归因于 runtime 层的优化（Session 日志避免了重复加载历史状态，microVM 沙箱避免了冷启动中的依赖初始化），而非模型本身变快。这些数字是 Anthropic 自己的 A/B 对比，不是第三方独立测试。

判断：目前最接近生产级 Agent 存储架构的方案。核心洞察是 Agent 状态本质是事件流而非文件，可能成为未来 Agent Runtime 的设计基线。

四条路线对比

---

三、NVIDIA 的存储野心：Storage-Next 与 ICMS

前面四条路线还是技术社区的探索。NVIDIA 的动作说明 GPU 厂商不再只做 GPU，开始定义存储架构。

3.1 Storage-Next：新存储层规范

FMS 2026 议程中，群联演讲标题"Enabling Ultra-High-IOPS Storage-Next SSDs with AI-Enhanced LDPC"透露关键信号：NVIDIA 已正式定义 "Storage-Next" 存储架构规范。

GPU-initiated I/O：传统架构中 GPU 需要数据时，CPU 先发 read 请求，数据从 SSD 经 PCIe 到 CPU 内存，CPU 再通过 GPU 驱动把数据拷贝到 GPU 显存。这条路径有两次跳转：SSD → CPU 内存（受 PCIe 带宽限制，PCIe 5.0 x16 约 63 GB/s），CPU 内存 → GPU 显存（受 NVLink/C2C 带宽限制）。每次跳转增加 1-5μs 的桥接延迟，CPU 还要消耗算力做 buffer 管理。

Storage-Next 让 GPU 通过 SCADA 协议直接发起 NVMe 读请求，数据从 SSD 直达 GPU 显存，跳过 CPU 内存中转。对于 KV Cache offload 场景（GPU 需要从 SSD 取回一段 10-50MB 的 KV Cache），减少一次跳转可以节省数十微秒。在高并发推理中，每秒数千次这样的读取，累计节省的延迟直接转化为 Token 吞吐提升。

SCADA™ 软件栈：NVIDIA 为 Storage-Next 定义的存储软件栈名称（NVIDIA 官方商标，非工业领域的 SCADA 通用术语）。GPU 厂商定义存储软件栈，意味着 NVIDIA 在试图掌控从 GPU 到存储介质的完整垂直栈。

3.2 CMX / ICMS：KV Cache 的专用存储平台

来源：NVIDIA 官方页面（nvidia.cn/data-center/ai-storage/cmx/）+ NVIDIA 新闻稿 2026-03-16

ICMS（Inference Context Memory Storage Platform）在 2026 GTC 上正式升级为 NVIDIA CMX™ 上下文记忆存储品牌，面向长上下文、多轮次和代理式 AI 推理的 AI 原生上下文层。

核心架构由三个组件构成：

STX 参考架构（Storage-Next 的产品化）性能目标：Token 吞吐最高 5x、能效最高 4x、数据摄入 2x。早期采用者：CoreWeave、Crusoe、Lambda、Mistral AI、Oracle Cloud、Vultr。存储合作伙伴已扩展到 17+ 家。

Micron 在 FMS 2026 明确提到："sessions become multi-turn or agentic, KV cache size expands rapidly"。KV Cache 已是有独立生命周期的持久化对象，会话结束后可能被保留用于 prefix 复用，多个 Agent 可能共享同一段 KV Cache，读写模式是随机与顺序混合。

NVIDIA 为 ICMS 拉入的存储厂商阵营：

AIC、Cloudian、DDN、Dell、HPE、Hitachi Vantara、IBM、Nutanix、Pure Storage、Supermicro、VAST Data、WEKA

12 家以上，几乎所有一线企业级存储公司。

3.3 铠侠三条产品线

XL-FLASH 是什么？铠侠基于 BiCS FLASH 3D 技术的存储级内存（SCM），填补 DRAM 和传统 NAND 之间的性能缺口。关键规格：16-plane 架构（传统 NAND 通常 4-8 plane），裸介质读取延迟 <5μs，SLC/MLC 模式，第二代已量产。已产品化为 FL6 系列 SSD：1.5M random read IOPS，SSD 端到端读取 29μs（含控制器、FTL 和 PCIe 协议栈开销，裸介质延迟 <5μs），写入 8μs，60 DWPD，800GB-3.2TB（数据来源：铠侠官网 FL6 产品规格页）。

XL-FLASH Gen2 的 10M IOPS @ <25W：不显著增加功耗前提下，单盘 IOPS 提升一个数量级。Emulator 进展：Phase 1（2025年8月）在 GH200 上生成 140M IOPS；Phase 3 运行在 SCADA 上（需 GH/GB 系统；x86 平台受限于 PCIe TLP 处理吞吐和中断处理开销，单 host IOPS 上限约 10-15M，无法达到 100M）。Gen3 的 100M IOPS 直接对标 Storage-Next 的 200M IOPS/GPU 目标（指每 GPU 连接的存储子系统聚合 IOPS，不是单盘数字，需多条 NVMe SSD 聚合）。

3.4 判断：GPU 厂商在定义存储层

对存储厂商：NVIDIA 的 AI 工厂采购模式是"参考架构"驱动的。它定义好从 GPU 到网络到存储的完整 BOM，客户按参考架构采购。如果不跟进 Storage-Next/ICMS 规范，意味着不在 NVIDIA 的参考架构供应商名单上。CoreWeave、Crusoe、Lambda 这些 NVIDIA 的大客户会优先从名单内采购。这不是理论推断。NVIDIA 过去在 GPU 网络领域用同样的模式把 Mellanox/InfiniBand 做成了 AI 集群的事实标准，存储领域的 ICMS 阵营已经有 Dell、HPE、IBM、Pure Storage 等 12+ 家厂商加入，说明市场判断跟进的收益大于独立的风险。

对 SSD 控制器厂商：512B 粒度和 200M IOPS 要求控制器从架构层面重新设计——这不是换一个更大的 DRAM buffer 或调高 GC 线程优先级能解决的，需要 FTL 的映射粒度从 4KB 改到 512B，FEC 从 4KB 块改为分层纠错。芯片流片周期 12-18 个月，现在不开始就赶不上 2027 的采购窗口。

对用户：Agent 基础设施采购决策可能进一步向 NVIDIA 生态靠拢。

更深层：GPU 厂商定义存储规范，意味着存储行业话语权正在转移。过去是 SNIA 定义标准，各厂商跟进。现在 NVIDIA 用 GPU 生态影响力直接绕过传统标准化组织，拉着自己的存储厂商阵营走。传统存储巨头不加入，就可能被边缘化。

---

四、SSD 控制器的 Agent 时刻

IO 粒度从 4KB 到 512B，对 SSD 主控厂商来说，是 NAND 物理架构和纠错算法层面的根本改变。

4.1 FEC 架构的挑战

SSD 的 FEC（前向纠错）通过冗余编码（通常是 LDPC 码）纠正 NAND 读写过程中的比特错误。传统 FEC 最小处理单元是 4KB，匹配 NAND 物理页大小。

FMS 2026 上 Microchip 指出：AI 工作负载的 512B-1KB 粒度与 4KB FEC 块之间存在根本矛盾。Microchip 提出的方案是 novel block structure + 多层解码：

1. Fast small block reads：高信噪比页面用轻量级硬判决解码（hard-decision），只检查奇偶校验位，延迟极低。
2. Hard-decision fallback：硬判决失败时升级到软判决解码（soft-decision），多次读取和迭代。
3. Multi-read soft decoding：极端情况做多次读取 + 软信息融合 + LDPC 迭代解码。

核心思想：不是每个 512B 块都需要完整的 4KB 级纠错，分层解码让大部分小块读取走快速路径，只有少部分触发重量级纠错。

4.2 群联 NN-LDPC：神经网络辅助纠错

群联在 FMS 2026 的演讲中展示了更激进的方案：用神经网络辅助 LDPC 纠错。

传统 LDPC 解码使用固定的迭代算法和固定的置信度传播规则。但这些规则是在"通用错误模式"下优化的，不是针对特定 NAND 闪存的错误特征。群联的思路：用 DNN 学习特定 NAND 芯片的错误分布，动态调整解码策略，在 512 字节小块场景下实现极低延迟纠错。

这是 NVIDIA Storage-Next-ready 的控制器方案，群联明确将其定位为面向 Storage-Next 架构的产品。

4.3 铠侠 DNN-based Read Flow

铠侠在 FMS 2026 的另一场演讲（Ballroom F，Flash Technology Track）中展示了 DNN-based Read Flow：用深度神经网络逐行动态调整 NAND Flash 读取阈值。

传统方案：全局统一的读取阈值电压（reference voltage）。但不同区域、不同磨损程度、不同温度下的最优阈值是不同的。铠侠用 DNN 逐行学习最优阈值，替代全局统一参数。

信号：AI 不只是存储的"消费者"，AI 正在改造存储控制器本身的固件设计。SSD 主控的差异化竞争维度正在从"谁容量大、谁带宽高"转向"谁在 512B 小块场景下 IOPS 更稳、纠错更强、p99 更低"。

4.4 Agent 工作负载下的 SSD 新约束

Agent 场景对 SSD 主控提出了几个新的优化约束：

这些不是调参能解决的，需要控制器架构的重新设计。原因在于：FTL 的映射表（LBA → PBA）以 4KB page 为最小粒度，改成 512B 意味着映射表条目增加 8 倍，DRAM 占用从典型 1GB/1TB 涨到 8GB/1TB。这要么需要更大的 FTL DRAM，要么需要改用多级映射（增加查找延迟）。FEC 的奇偶校验矩阵也是按 4KB 设计的，512B 纠错需要新的编码方案。这些都是芯片和固件层面的结构性改动。

当前成熟度判断：上述三项技术（Microchip 512B FEC、群联 NN-LDPC、铠侠 DNN Read Flow）都处于工程验证阶段。群联的 NN-LDPC 已有 silicon 演示（基于 FMS 演讲内容推断），Microchip 的分层 FEC 架构有仿真数据，铠侠的 DNN Read Flow 仍在实验阶段。距离量产可能还需要 12-18 个月，但方向已经明确：SSD 控制器正在从"通用信号处理器"变成"AI 辅助的专用信号处理器"。

---

五、KV Cache：从数据结构到存储对象

KV Cache 的演进是理解 Agent 存储架构变革的最佳切入点。它的角色变化折射出整个行业对"推理状态管理"认知的根本转变。

5.1 三个阶段

阶段一：KV Cache = 推理引擎内部数据结构（2023-2024）

vLLM 的 PagedAttention 把 KV Cache 当作"GPU 显存内的虚拟内存"来管理，消除碎片化、提升并发。此时 KV Cache 100% 在 HBM 里，存储行业完全不关心。FMS 2024：零提及。

阶段二：KV Cache 溢出压力（2024H2-2025H1）

上下文窗口从 32K 膨胀到 128K 甚至 1M。以 Llama 2 70B 为例（GQA，8 KV heads，head_dim=128），FP16 下每 token KV Cache 约 320KB；128K 上下文单请求约 40GB，1M 上下文达 320GB（FP8 量化后约 160GB）。GPU HBM 80-192GB 容量远远不够。

第一反应：量化压缩（FP8 KV Cache）。第二反应：CPU offload。第三反应：往 SSD 推。这些还都在"引擎内部"解决。

阶段三：KV Cache 变成系统级存储对象（2025H2-2026），转折点

当 Prefix Cache 出现，系统发现多个请求共享相同前缀（system prompt、长文档）时，KV Cache 变成了可复用资产。这立刻引出三个存储系统级问题：

1. 命名：怎么标识一段 prefix KV Cache？
2. 寻址：它在 HBM、DRAM 还是 SSD 上？怎么在需要前搬运？
3. 生命周期：什么时候驱逐？跨节点怎么共享？

KV Cache 在这一刻从数据结构变成了存储对象。FMS 2026 用 7 场主题演讲讨论 KV Cache，不是空谈。

5.2 SanDisk：KV Cache 复用的真正复杂度

FMS 2026 上 SanDisk 的演讲揭示了 KV Cache 复用远比"前缀匹配"复杂。现有系统只支持最长前缀匹配（longest prefix match），但实际工作负载中大量存在：

• Partial overlap：两段 KV Cache 中间有部分相同
• Shifted overlap：相同内容出现在不同偏移量位置
• Suffix overlap：结尾部分相同
• Mid-span overlap：中间某一段相同，首尾不同

这些场景在 conversational AI、RAG、templated prompts 中非常普遍。

SanDisk 提出三层索引架构来解决任意复用检测。先理解为什么传统最长前缀匹配不够：在对话 AI 中，用户 A 和用户 B 的 system prompt 相同（前缀复用），但各自的对话历史不同。在 RAG 场景中，不同请求可能引用同一份文档但提问不同（中间一段 KV Cache 相同）。在模板化 prompt 中，few-shot examples 可能只是顺序不同（shifted overlap）。这些场景的共同点是：可复用的 KV Cache 片段不在头部。

三层架构的推理过程：

三层过滤的设计逻辑是"先粗筛再精匹配"：第一层 segment tree 在 O(log n) 时间内排除大部分不可能有复用的段；第二层做精确的位置匹配，只对第一层筛出的候选段做操作；第三层做最终校验。效果：30% 降低 prefill 延迟，2× KV 复用——这个数字意味着三分之一的新请求可以从已有 KV Cache 池中找到可复用片段，避免重复计算。

5.3 Micron：实测数据

Micron 在 FMS 2026 分享了 KV Cache offload 的实测数据（measured evidence，不是 PPT）：

• KV Cache 定义为"attention memory LLMs build during prefill"
• 明确提到 "agentic sessions" 导致 KV Cache 膨胀
• KV Cache IO 模式是"随机和顺序混合"
• 分层内存系统 + 低成本快速持久存储层可以实质性改善性能和 CapEx 回报

这是少数几场有实测数据的演讲。Micron 的措辞值得注意，drive-level 优化针对 KV Cache IO 的混合访问模式，说明 SSD 厂商已经开始在固件层面适配 Agent 工作负载。

---

六、长时运行 Agent 的五种架构模式

Agent 从"单次问答"走向"长时运行"（long-running），状态持久化成为核心挑战。以下五种模式代表了当前的解决方案空间。

模式 1：Checkpoint-and-Resume

核心思路：定期将 Agent 状态写入持久存储，崩溃后从最近 checkpoint 恢复。

实践：例如每处理 30 份文档落一次盘。Agent 执行 1000 步任务时，最多丢失 30 步的进度。

状态持久化策略：周期性全量快照。每次 checkpoint 是 Agent 完整状态的序列化（context + plan + intermediate results）。

优劣势：简单直接；但 checkpoint 间隔是性能和安全性的 trade-off，太频繁影响吞吐，太稀疏丢失进度多。全量快照在高频场景下产生大量写入。

模式 2：Delegated Approval（Human-in-the-Loop）

核心思路：Agent 在关键决策点暂停，等待人类审批后继续。

状态持久化策略：在暂停点冻结状态，持久化到外部存储。人类审批通过后解冻。

优劣势：安全性高，适合高风险场景（金融交易、代码部署）；但人类审批是同步阻塞，会显著拉长 Agent 任务执行时间。需要状态在冻结期间不失效。

模式 3：Session-as-Event-Log

核心思路：见路线 4（Anthropic 模式）。Agent 状态即"历史事件序列"。当前状态 = 从起始点重放所有事件的结果。

状态持久化策略：Append-only event log + 周期性 checkpoint（用于快速恢复，不是唯一真源）。

优劣势：崩溃恢复简单（重放日志）；天然审计（日志即记录）；但长会话的日志体积会线性增长，replay 时间也会增长。

模式 4：Sandbox Isolation

核心思路：Agent 的每次工具调用在独立沙箱中执行。

代表实践：E2B（开源 Agent 沙箱平台，冷启动数据来自 E2B 官方文档）、腾讯 Agent Runtime（60ms 冷启动沙箱，数据来自腾讯云 2026 年技术分享）、Anthropic Managed Agents（每次 tool call 一个全新 microVM）。

状态持久化策略：沙箱本身无持久化。执行结果被序列化后写回外部存储（通常是 event log 或 checkpoint）。沙箱只负责计算隔离，不负责状态保持。

优劣势：安全性极高（沙箱用完即焚）；弹性好（无状态实例可任意调度）；但沙箱启动开销是关键约束。腾讯做到 60ms 冷启动，E2B 也在百毫秒级别，Anthropic 的 microVM 方案延迟数据未公开但 p50/p95 首 token 延迟改善显著。

模式 5：Google Agent Runtime（7 天状态保持）

核心思路：Agent Runtime 在服务器端保持 Agent 进程持续运行最长 7 天，状态在内存中保持，不需要每次从头恢复。（7 天上限来自 Google Cloud 2026 年 Agent Engine 文档。）

状态持久化策略：运行时内存保持 + 后台定期持久化。介于纯内存和纯日志之间。

优劣势：延迟最低（不需要 checkpoint 恢复）。但 7 天内存占用是实打实的成本。Google 必然有调度策略来处理空闲 Agent（推测是后台自动持久化后释放内存），不会让资源真的空等 7 天。适合高价值长时 Agent，不适合大规模低成本场景。

五种模式对比

---

七、AIOS：Agent 操作系统的学术探索

如果 Agent 需要一个操作系统，那这个 OS 长什么样？AIOS（Agent IO System）论文给出了一个概念架构。

7.1 核心架构

AIOS 的设计直接类比传统操作系统，但每一个组件都针对 Agent 工作模式重新设计：

核心组件：

1. LLMCore：管理底层 LLM 推理引擎的调度和资源分配。类似传统 OS 对 CPU 的管理，上下文切换、时间片分配、优先级调度。
2. Agent Scheduler：决定哪个 Agent 在什么时候获得推理资源。多 Agent 并发时，调度器需要平衡延迟、公平性和吞吐。
3. Context Manager：管理 Agent 的 context window，什么内容在窗口内、什么在窗口外、什么时候做什么内容进入或离开。这本质上就是虚拟内存管理。
4. Memory Manager：管理 Agent 的长期记忆，超出 context window 的历史信息如何存储、索引和检索。
5. Storage Manager：管理 Agent 的持久化状态，checkpoint、event log、工具调用结果。
6. Tool Manager：管理 Agent 可用的工具，注册、发现、权限控制、调用执行。

7.2 与传统 OS 的根本差异

AIOS 的类比很有启发性，但也有几个根本差异需要注意：

调度粒度不同：传统 OS 调度的是指令流（微秒级时间片），AIOS 调度的是推理步骤（秒到分钟级）。调度开销本身可能不可忽略：如果推理本身只需约 500 毫秒（70B 级别模型、4K token 输入的参考量级），而 Agent 切换调度需要 50-100 毫秒（Agent 状态保存、context window 重载、工具连接重置），开销比就达到了 10-20%。

"内存"语义不同：传统 OS 的内存管理基于固定大小的页（4KB），AIOS 的 context 管理面对的是变长的语义片段。不能简单套用页面调度算法。

"文件"的生命周期不同：传统文件一旦创建就持久存在直到被删除。Agent 的很多状态是中间产物，有效期内有用，过期后就是垃圾。AIOS 需要内置的状态生命周期管理，不能依赖用户手动清理。

7.3 局限性

AIOS 目前是概念验证阶段，开源在 github.com/agiresearch/AIOS。它的价值不在产品级实现，在于提供了一个系统性的框架来思考"Agent OS 应该长什么样"。这个框架对后续的技术发展有参考意义，即使最终的工业实现可能和论文完全不同。

---

八、产业格局：谁在做什么

Agent 存储架构的变革正在重塑存储产业的价值链。不同类型的玩家从不同角度切入，每类的动机和能力边界不同。

8.1 存储系统巨头

代表：Dell、Pure Storage、NetApp、VAST Data、IBM

核心动机：从"训练时代的盒子"升级为"Agent 工作流平台"。

动作：Dell 和 Pure Storage 已加入 NVIDIA ICMS 阵营。VAST Data 在做数据治理一体化方案，不只是存数据，还要管理数据的生命周期、血缘、权限。IBM 除了加入 ICMS，还在推 Cognitive File System。

真实进度：数据治理一体化方案已交付，但 Agent 场景部分偏早期。这些巨头的优势是渠道和客户关系，劣势是软件迭代速度。

8.2 SSD / 主控厂商

代表：Samsung、Kioxia、Phison（群联）、Micron、SanDisk、Microchip

核心动机：Agent 随机 IO = IOPS 新卖点。从带宽竞争转向延迟和 IOPS 竞争。

动作一览：

判断：SSD 主控厂商的差异化竞争维度正在转移。过去比谁容量大、带宽高，现在开始比谁在 512B 小块场景下 IOPS 更稳、纠错更强、p99 更低。这给了群联这样的主控专业公司弯道超车的机会。

8.3 GPU 厂商

代表：NVIDIA

核心动机：存储生态主导权。把存储拉进自己的推理全栈。

动作：Storage-Next + ICMS + SCADA 软件栈。NVIDIA 在做的不只是定义存储规范，是在定义"AI 推理时代的数据中心架构"。GPU、DPU、网络、存储，全栈。

8.4 Agent 平台

代表：Anthropic、Google

核心动机：Runtime 级状态管理。Agent 的状态管理不应该由应用层负责，应该是 Runtime 的内置能力。

动作：Anthropic 的 Managed Agents（Session-as-Event-Log + microVM Sandbox）已在生产环境运行。Google 的 Agent Runtime 支持 7 天状态保持。

判断：Agent 平台公司在做存储系统公司该做的事：状态管理。传统存储公司没有能力也不应该去做 Agent 级别的状态管理。最终形态可能是 Agent 平台做状态管理抽象，底层调用存储系统厂商提供的基础设施。

8.5 中国

代表：腾讯 Agent Runtime

动作：60ms 冷启动沙箱。这个数字值得注意，如果 Agent 的每次 tool call 都需要启动沙箱，60ms 的冷启动意味着单次 tool call 的沙箱开销可以接受（对比 Anthropic 的 microVM 方案，延迟改善数据间接印证了类似的量级）。

中国存储厂商的位置：在 FMS 2026 的 ICMS 阵营中没有看到中国存储厂商的名字。这不意味着中国厂商没有参与 Agent 存储的机会——中国市场有全球规模最大的开源模型推理部署（DeepSeek、Qwen、GLM 等的推理服务覆盖数亿用户），这些推理服务正在快速演化出 Agent 化的工作负载，市场需求是实打实的。但在标准定义和生态主导权层面，中国厂商目前是跟随者。

---

九、判断与风险

9.1 已经在发生的

KV Cache 从引擎内数据结构变成跨层级存储对象。Prefix Cache 的出现是分水岭。NVIDIA 的 ICMS、Micron 的实测数据、SanDisk 的复用索引，这些都通过了产品级验证。FMS 2026 用 7 场演讲讨论 KV Cache 不是空谈。

SSD IO 粒度正在改变。Microchip 的 512B FEC 提案、群联的 NN-LDPC、铠侠的 DNN Read Flow，这些都是芯片和固件级别的工程实现。

Agent Runtime 的状态管理模式正在收敛。Anthropic 的 Session-as-Event-Log + Sandbox 模式已经在生产环境运行，Google 的 7 天状态保持也在运行。腾讯做到 60ms 冷启动沙箱。模式在收敛，不是发散。

9.2 正在被讲述但尚未完全发生的

Cognitive File System。IBM 的提案方向正确，但从 FMS 议程到生产部署有很远的距离。目前放在 Computational Storage Track，说明行业关注度还有限。

NVIDIA Storage-Next 全面落地。规范已定义，合作伙伴已就位，铠侠的 GP Series 2026 年才出评估样品。从规范到大规模部署通常需要 2-3 年。

CXL 在 Agent 场景的大规模部署。技术逻辑成立，CXL 2.0 协议层事务延迟约 20-40ns（对比 PCIe 5.0 约 100ns），含 root complex 开销的端到端延迟约 170-250ns。字节寻址，load/store 语义。NVIDIA Vera CPU 已原生支持 PCIe Gen6 / CXL 3.1（88 核 Olympus，1.5TB LPDDR5X，NVLink-C2C 1.8TB/s），CPU 端成熟这个前提正在被满足。但 Agent 框架的 CXL-aware 数据放置策略仍然缺失，仍需 1-2 年验证。

9.3 风险

Capex 回调风险。分析师 Jim Handy 在 FMS 2025 上对超大规模数据中心资本支出不可持续的警告仍然有效。如果 AI 基础设施投资在 2026 下半年进入回调期，Agent 存储叙事可能经历"PPT 先行、部署滞后"的尴尬窗口。

Agent 部署的实际节奏。目前 Agent 在生产环境的部署规模远小于推理（inference），大量 Agent 还在 POC 阶段。存储行业的 Agent 叙事热度可能领先于实际部署需求 1-2 年。

标准化碎片。NVIDIA 用 Storage-Next + ICMS + SCADA 定义自己的标准。IBM 推 Cognitive File System。SNIA 在推 Computational Storage 标准。如果没有统一标准，存储厂商可能面临"选哪个阵营"的困境，增加市场碎片化。

NVIDIA 生态锁定。如果 NVIDIA 成功定义了从 GPU 到存储介质的完整栈，用户的选择空间会被压缩。今天选择 NVIDIA 存储生态，明天退出成本可能极高。

---

十、结尾：从"一切皆文件"到"一切皆上下文"

Unix 在 1969 年提出"一切皆文件"。这个设计哲学极为成功，它提供了一个统一的接口来访问文件、设备、网络、进程信息。半个世纪以来，几乎所有操作系统都采用了某种形式的"一切皆文件"。

但 Agent 不是 Unix 的用户。

Agent 不需要路径，需要内容。不需要文件名，需要模式。不需要目录，需要相关性。Agent 的工作模式，持续观察、多步推理、工具调用、状态追踪，和人类用户的信息消费方式根本不同。

从"一切皆文件"到"一切皆上下文"，这是信息管理范式的迁移。

这个迁移正在以多条路线并行推进：Anthropic 用事件日志和 microVM 绕过了文件系统；IBM 试图从内核改造文件系统本身；NVIDIA 用 GPU 的生态影响力定义新存储层；学术研究者提出了"一切皆上下文"的理论框架。

这些努力的方向是同一个：让存储系统理解它存储的数据，让 Agent 高效地消费它需要的信息。

当 Karpathy 说 LLM 是 CPU、context window 是 RAM 时，他少说了一句：每个 CPU 都需要一个操作系统来管理它的 RAM。Agent 的操作系统正在被发明。它可能不叫"操作系统"，不长得像 Linux，甚至不是今天任何一家公司的产品。但它会出现。

因为问题就在那里。谁管理 Agent 的 RAM？谁决定什么进出？当 Agent 停止运行，它的记忆保存在哪里？

它会出现，而且可能比预期更快，因为 GPU 厂商、存储厂商和 Agent 平台已经在分头建造它的不同部件。

---

信息来源

一手来源（FMS 2026 官方议程）：

• Session: "Hierarchical Span Indexing for Generalized KV Cache Reuse" — SanDisk (Vishwas Saxena, Mukesh Kumar)
• Session: "Optimizing KV Cache Offload for Scalable, Cost-Efficient AI Inference" — Micron (Rohan Mehta)
• Session: "SSD Error Correction Optimization for AI Workloads" — Microchip (Peter Graumann)
• Session: "Enabling Ultra-High-IOPS Storage-Next SSDs with AI-Enhanced LDPC" — Phison (Sean Lin)
• Session: "Cognitive File System" — IBM (Viacheslav Dubeyko)
• Session: "DNN-based Read Flow for NAND Flash Controllers" — KIOXIA (Eyal Nitzan)
• Session: "Fixed Function Compute Standardization" — KIOXIA (Devesh Rai)
• Session: "Enhancing Enterprise Drive Reliability by Joint LDPC & XOR Decoding" — SanDisk (Alex Bazarsky)
• Session: "High-Density SSD Design in Supply-Constrained Deployments" — Solidigm (Tahmid Rahman)
• FMS 2026 官方议程：https://www.terrapinn.com/conference/future-memory-storage/agenda.stm

企业公开信息：

• NVIDIA Storage-Next / ICMS / SCADA：铠侠 FMS 演讲材料
• Anthropic Managed Agents：Anthropic 官方技术文档
• 铠侠 GP Series / CM Series / LC Series：铠侠产品路线图
• IBM Cognitive File System：Viacheslav Dubeyko, "File System in Data-Centric Computing," arXiv 2019；FMS 2026 提案

行业信号：

• LlamaIndex: "Files Are All You Need"（Jerry Liu 公开演讲）
• LangChain Agent 架构转向
• arXiv: "Everything is Context"
• AIOS: github.com/agiresearch/AIOS

分析参考：

• Jim Handy (Objective Analysis), "11 Key Changes Coming," FMS 2025
• 铠侠, "Optimizing AI Infrastructure Investments with Flash Memory," FMS 2025
• deephub: "Long-Running Agent Architecture Patterns"

---

趋势综述见姊妹篇《当存储变成 Agent 的工作记忆：FMS 三年风向迁移》。

不构成投资建议。数据截至 2026 年 7 月 17 日。FMS 2026 尚未召开（8 月 4-7 日），议程分析基于官方预览信息。NVIDIA CMX/STX 数据来自 NVIDIA 官方页面和 2026-03-16 新闻稿。铠侠 XL-FLASH/FL6 数据来自铠侠官网产品规格页。CXL 延迟数据来自 CXL 联盟规范及公开技术分析。Vera CPU 数据来自 NVIDIA developer blog（2026-01-05）。