AI Infra：数据库没有过时，只是被 Agent 推动重构
最近，智能体（Agent）概念热度极高，其影响力之大，以至于各类基础软件若未能与之结合，便仿佛面临被时代淘汰的风险。一种典型论调随之涌现：“在 Agent 时代，传统数据库与存储系统将被彻底颠覆。”
我持不同观点：传统数据库与存储不会消失，但将经历一次从“档案馆”到“作战指挥室”的职责重构。
过去二十年，数据库与存储系统主要服务于“人找数据”的场景：用户提交SQL查询，系统返回结果。这是一种静态的“Human → Data”交互模式。
未来十年，这些系统必须服务于Agent执行任务的闭环：Agent所需的不再是孤立的原始数据，而是能够指导其下一步行动的上下文（Context）。其运作模式演变为动态闭环：“Agent → Context → Action”。
这意味着数据基础设施的设计目标发生了根本性转变，不是简单叠加向量插件或支持MCP协议所能实现。
若以粗粒度表格勾勒代际演进，可归纳如下：
| 时代 | 数据库的核心任务 | 存储系统的核心任务 |
|---|---|---|
| Web（互联网） | 持久化业务数据，支撑高并发访问 | 存储文件，满足低成本与基本可用性 |
| Cloud（云原生） | 弹性计算与数据管理，存算分离成为标配 | 海量对象存储，数据湖雏形初现 |
| AI（智能体） | 保存可计算的上下文（Context） | 保存推理工作集与运行状态（State） |
一、数据库的职能转型：从数据存储引擎到上下文引擎
在传统开发范式下，数据库主要回答“数据是什么”的问题——例如订单金额的数值。而在Agent时代，核心关切转变为：“发生了什么？下一步应执行什么操作？”
二者差异如同查阅字典与进行阅读理解。为回答后者，数据库必须承载大量“运行状态（State）”。以销售Agent为例：
传统数据库仅需三张核心表：
Customer（客户）、Order（订单）、Product（产品）
这些记录是静态“事实”。未来，为驱动Agent，数据库还需记录：
Customer Intent（客户意图）、Conversation Memory（对话记忆）
Task State（任务状态）、Workflow State（工作流状态）
Reasoning Result（推理结果）、Tool History（工具调用历史）
Observation（观察记录）、Plan（行动计划）
数据库不再仅存储业务对象，而是维护Agent从创建到消亡的完整生命周期。基于此，未来数据库将解锁四种关键能力：
1.1 State（状态）成为一等公民
传统OLTP系统的核心操作为insert、update、delete。而Agent的运转核心是高频的状态流转。单个Agent实例的记录形式更接近日志流：
Agent A：
目标：完成Q3销售报告
计划：拉取→分析→生成
异常：查询超时
行动：重试并通知
此类状态的更新频率极高，操作模式转变为append（追加）、merge（合并）、checkpoint（检查点）和rollback（回滚）。数据库需以原生方式处理这种流式状态，而非简单的行级修改。
1.2 Memory（记忆）的原生支持
坦率而言，当前Memory的实现方案普遍较为初步：短期记忆依赖Redis，长期记忆则存入JSON文件或Milvus等向量数据库。未来，Memory应像Datetime或String一样，成为数据库的原生数据类型。
它应直接支持Merge（合并）、Compression（压缩）、Aging（老化）和Retrieval（检索）等操作。Memory不应是外挂补丁，而应内置于数据库基因之中。需特别指出：本文反对“记忆数据库”作为一个独立品类存在，因为Memory仅是新的复杂数据模型，不足以构成独立的数据库物种。
1.3 Context（上下文）作为返回对象
未来数据库的返回内容将不再限于一条条记录，而是可计算的业务上下文——它将对象、关系、规则和流程打包为结构化的整体。
以供应链链路为例：客户→订单→发票→付款→物流。当Agent询问“为何此订单失败？”时，数据库应返回包含因果链、异常节点及修复建议的诊断报告，而非数十行SQL结果。
1.4 Reasoning Native（推理过程的可观测性）
Agent在推理过程中产生的“思考”具有极高价值。数据库应开始原生保存Decision Trace（决策轨迹）和Reasoning Trace（推理轨迹），类似于Git保存代码提交历史。未来，这些轨迹可用于审计、错误排查及性能优化。
二、存储系统的蜕变：从数据仓库到 AI/Agent runtime
相较于数据库，存储系统的变革可能更为激进。过去存储的是静态的“结果文件”，未来存储的将是频繁访问、持续变化的推理工作集。
2.1 KV Cache——最具成本敏感性的“热数据”
在大模型推理过程中，KV Cache扮演着关键角色，可类比为CPU的L1/L2缓存。当前，GPU频繁访问的最昂贵数据即为此类缓存。未来存储系统的核心任务之一，便是围绕KV Cache的共享、分层、压缩与预取进行优化。我们预计将出现专为此设计的推理存储（Inference Storage），作为GPU显存的廉价、大容量扩展层。
2.2 存储系统的“内存化”趋势
传统数据路径：硬盘→SSD→内存。
未来瓶颈所在：GPU显存 ↔ 外部存储。
延迟必须压缩至微秒级。借助CXL、RDMA等技术，存储系统将具备类似内存的访问速度，而非慢速的“文件柜”。
2.3 GPU直连的专属数据流水线
过去，数据传输需经CPU多次搬运，效率低下。未来，通过GDS、NVLink、NVMe-oF等协议，数据路径将优化为 GPU → Storage，绕开CPU，使存储直接成为GPU的流水线。
2.4 Checkpoint——Agent运行的“保命”机制
Agent任务可能持续数小时甚至数天。中途中断后的重启成本不可接受。存储系统必须支持类似于虚拟机快照的 Agent Snapshot 功能，允许随时创建检查点、恢复、迁移，甚至完整复刻Agent的运行现场。
三、融合还是再分工？
许多人预言数据库与存储将最终融合。我的判断是：这不是融合，而是边界重塑。二者不会变成同一系统，而是下沉自身能力，使对方更“理解”自身状态。
过去的简单堆栈为：存储 → 数据库 → 应用。
未来的演化方向为：AI Storage → State Engine → Context Engine → Reasoning Engine → Agent。
- AI Storage：理解KV Cache、Embedding、Checkpoint等结构，成为GPU的“弹夹”。
- State Engine（数据库）：维护Task、Memory、Workflow的运行状态，提供高可靠的日志化状态管理。
- Context Engine：封装业务逻辑、知识图谱与权限模型，为Agent提供可读可写的业务世界。
边界清晰，职责分明，配合紧密。
四、未来五年的合理架构分层
摒弃“数据库 vs. 存储”的过时分类，Agent时代数据基础设施可以分成五层架构：
| 层级 | 核心问题 | 核心对象 | 确定性评估 |
|---|---|---|---|
| Agent Runtime | “如何执行？” | Task, Tool, Workflow | 高（LangGraph等已成为标准） |
| Context Layer | “在何处执行？” | Object, Ontology, Policy | 中高（业务理解的关键要素） |
| Runtime Database | “状态如何？” | State, Memory, Checkpoint | 高（传统数据库的升级方向） |
| AI Storage | “工作集何在？” | KV Cache, Embedding | 高（针对AI负载的优化方向） |
| Object Storage | “冷数据何在？” | Dataset, Archive | 极高（S3地位稳固） |
结语：一个大胆的猜想
最后，提出一个对未来产品形态的判断：数据库与存储，并非Agent时代的最高抽象层级。
真正的最高抽象，可能是 Workspace（工作空间）。
想象Workspace如同Agent的“数字办公室”：它天然集成了业务上下文、运行状态、长期记忆、可用工具、知识库及协作记录。数据库负责结构化状态，存储负责对象与工作集，Runtime负责执行逻辑。
若将这些组件完美组合，便构成一个可持续演化的 Agent操作系统。
届时，竞争的焦点将不再是“谁存储的数据更多”，而是 “谁能持续维护并供应高质量的上下文与运行状态”。模型负责生成Token，而Workspace负责组织一切。