瓶颈已经移动：当推理、数据库、版本控制开始说同一件事

2026年5月4日 · 587 字 · 3 分钟 · 状态管理 Ai-Agent 基础设施 Kv-Cache 数据库

如果我告诉你,内存带宽、数据库运行时、“git”,这三件看起来毫不相关的事,正在被同一个力量重塑——你可能觉得牵强。

但我想先给这个"力量"一个精确的定义,再来看证据。否则"状态"这个词会变成一个什么都能装的筐。

先定义"状态"

“kv-cache” 里的状态是计算图的中间张量——推理必须依赖的历史上下文。数据库里的状态是持久化的业务数据——会话、配置、工作流进度。“git” 里的状态是文件系统的版本快照——谁在什么时候改了什么。

三种状态,层次不同,但有一个共同结构：状态是系统在某一时刻的可重建视图。可以恢复、可以追溯、可以传递——关键在于可重建性,而非完整性。

不同层次的状态,重建路径本身也不同。“kv-cache” 是直接存储在 GPU 显存里的中间张量,是即时可用的热数据。“git” 的历史状态需要重放 commit 序列才能重建。两者都是"状态",重建机制完全不同——这个差异在后面选型时很关键。

三层压力传导

过去十年,我们设计系统时的默认优先级是：计算 > 存储。一个系统慢,优先想计算够不够强、算法能不能优化。存储是辅助,是"把东西放那儿"的地方。

这个假设在推理场景下正在失效。原因不是一个,是三层压力同时传导。

推理层：算力瓶颈变成内存瓶颈

Transformer 的推理过程,每生成一个 token,都需要访问此前所有 token 的 Key-Value 矩阵。这个矩阵就是 “kv-cache”。上下文从 4K 扩展到 1M,模型的计算能力足够处理,但 “kv-cache” 体积同比膨胀。以 Llama 3.1 70B 为例,128K context 下单请求的 “kv-cache” 约 40GB（BF16 精度）1——而模型权重本身以 INT4 量化后约 35GB。把这些数据从 HBM 加载到计算单元,受制于内存带宽上限,不受制于 FLOPS。

推理延迟 = max（计算时间,内存加载时间）。当上下文足够长,内存加载时间必然成为主导项。MatX 的测量数据表明,在解码阶段,加载 “kv-cache” 的等效计算成本可以超过前向计算本身的 20 倍2。

这里有一个值得厘清的概念：“kv-cache” 不是"用空间换时间"的优化,是推理机制本身的物理必要条件。没有 “kv-cache”,Transformer 无法在合理时间内生成 token。它不是可以权衡取舍的设计选项,是约束。

一个具体信号：各家推理框架在过去两年最核心的工程进展,几乎全部围绕 “kv-cache” 管理展开。vLLM 的 PagedAttention（2023,SOSP）3 把 “kv-cache” 拆成固定大小的内存页按需分配,解决了碎片化问题,实测吞吐量比此前方案提升 2～4 倍。SGLang 的 RadixAttention4 用前缀树自动复用 “kv-cache”,在 Agent 场景下可达 5 倍以上吞吐量提升。算力之外,状态管理能力正在成为推理系统的核心竞争力。

数据层：被动存储试探协调角色

传统数据库的设计假设是：客户端主动查询,数据库被动响应。这个假设在 CRUD 应用里成立。在 Agent 工作流里开始失效——Agent 工作流是事件驱动的,状态变更需要触发下游行为,轮询是低效的,批处理有延迟,只有实时推送才能满足需求。

四个信号表明变化正在发生：

Cloudflare Durable Objects5 把计算、状态、网络绑定到单实例。每个 Durable Object 自带嵌入式 SQLite 数据库,Agent 的状态不在外部数据库里,Agent 本身就是有状态的运行时单元。Cloudflare 的 Agents SDK 直接建构在 Durable Objects 之上。

嵌入式数据库本地化：PGlite、libSQL 让每个 Agent 实例内嵌一个完整数据库。状态所有权归 Agent 自身,同步变成 Agent 间的协议问题,而非中心数据库的查询问题。

持续物化计算：Materialize、RisingWave 把数据库从"查询时计算"变成"变更时持续计算",主动维护状态的物化视图,而不是等 Agent 来拉取。

实时订阅成为标配：Supabase Realtime、Redis Streams 让数据库能推送变更,而非只能被拉取。

这些试探的共同方向是：数据库从"被动的数据源"走向"主动的状态协调者"。但距离"主动驱动工作流"还有明显差距——真正的编排逻辑还在应用层或专用框架里。趋势是真实的,“数据库变成运行时"目前是方向,不是现状。

协作层：多 Agent 同步的协议空缺

“git” 被借用来做多 Agent 协作,本身就说明了一件事：专门为这个场景设计的协议,还不存在。

“git” 解决了三个核心问题：状态时间线（commit history）、冲突检测（merge conflict）、版本回滚（checkout/revert）。这三个问题在多 Agent 协作里同样存在,所以有团队直接把 “git” 当作 Agent 状态同步协议来用——Agent A 提交变更,Agent B 拉取继续。“git” 的真实优势是：成熟、可靠、审计链完整。

但 “git” 的设计假设和 Agent 运行时需求存在根本错配：

维度 “git” 实时状态协议所需
冲突处理 手动 merge,用户介入 自动解决（CRDT / OT）
更新方式 显式 commit + push 无感同步（增量推拉）
数据模型 DAG of snapshots 连续操作日志或可变状态
适用场景 低频率、高语义（代码 / 文档） 高频率、低语义（运行时状态）

还有一个更深的错配：多 Agent 协作中的冲突比 “git” 面对的更复杂。“git” 合并的是文本——两个开发者改了同一行代码,冲突是字节级的。但 Agent 场景下,冲突往往是语义级的。Agent A 预订了最后一间会议室,Agent B 也预订了同一间——合并的不是两行文本,是两个相互矛盾的意图。文本合并策略在这里完全无效。

因此,“git” 适合一类特定场景：知识版本管理——代码、文档、配置、Prompt 模板的版本追踪。它不适合管理运行时状态——会话上下文、实时内存、跨 Agent 的动态协作。

Anthropic 的 MCP（Model Context Protocol）定义了 Agent 如何连接工具和数据源——Resources、Tools、Prompts 三种操作。MCP 解决了工具发现和调用问题,是重要的基础设施。但 MCP 明确不处理状态：Agent 之间怎么传递上下文？状态版本怎么管理？冲突怎么合并？这是设计哲学,不是遗漏——类似于 HTTP 不规定 session 同步,保持协议简洁,状态交给底层基础设施处理。但这也意味着,多 Agent 状态协议目前是一个空位,各个团队在用不同方案（“git”、数据库、消息队列、自定义协议）各自解决。这个空位,是下一代 Agent 基础设施真正的竞争焦点。

状态管理是复杂度,只在必要时引入

在讨论怎么管理状态之前,先回答一个前提：是否真的需要状态管理？

无状态函数（Lambda、Webhook 处理器）请求结束就丢弃状态,强行持久化只增加延迟。纯计算管道（ETL、矩阵运算）中间结果可以重新计算,不需要持久化时点状态。只读的 RAG 查询仅检索知识库,不产生内部状态变更。

判断标准只有一个：状态是否需要跨越多次请求、或在两个以上 Agent 之间共享？ 如果否,不需要往下看。如果是,才需要认真设计状态生命周期。

状态生命周期：七个阶段,大多数工具只覆盖两个

确认需要状态管理之后,下一个问题是：状态从哪里来,到哪里去,中间经历什么。

大多数工具只解决了创建和存储,把其余的留给开发者自己处理。

创建：Agent 启动时,初始状态从哪里来？继承上一个会话？从模板初始化？绑定身份和权限？大多数框架假设"每次从零开始”,没有继承机制。

存储：放内存还是持久化？KV 结构还是关系型？选错了,后面所有阶段都受限。

粒度是关键决策：字段级（细粒度）冲突少但事件多,对象级（粗粒度）简单但合并难。“git” 是文件级——粗粒度,适合沉淀不适合实时。“kv-cache” 是 token 级——极细粒度,适合推理不适合存储。

存储阶段还需要回答两个约束：RPO（最多允许丢失多少状态）和 RTO（恢复需要多快）。这两个数字决定分层策略,也决定后面的恢复机制。

不同时效性的状态,应该落在不同的存储层：

状态类型 示例 时延要求 一致性模型 典型技术
热状态 “kv-cache”、活跃会话 token 毫秒级 最终一致 GPU 显存、本地内存
温状态 Agent 任务进度、工作流上下文 秒～分钟级 顺序一致 Redis、嵌入式数据库
冷状态 审计日志、历史对话、代码版本 永久保留 强一致可审计 对象存储、“git”

热状态成本最高——以 Llama 3.1 70B 为例,128K context 的 “kv-cache” 单请求约 40GB 显存1,而且这个数字随并发请求线性叠加。没有正确分层,要么推理成本失控,要么丢失上下文。

同步：多个 Agent 并发访问同一状态,怎么处理？冲突检测是自动的吗？合并策略是什么？这是当前工具链最薄弱的地方。

治理：谁有权改这个状态？冲突谁说了算？两个 Agent 同时读取、各自修改、然后写回——谁赢？这些问题没有标准答案,但必须有人回答。

四种常见治理模式,适用场景不同：

  • 无锁乐观并发（版本号 + CAS）：低冲突场景,冲突时重试。Redis Watch 用这个模式。
  • 悲观锁（租约）：高冲突强一致,但会阻塞。ZooKeeper 临时节点用这个模式。
  • CRDT 自动合并：高冲突且无需人工裁决,无锁但状态膨胀。Figma 协同编辑用这个模式。
  • 最后写入获胜（LWW）：简单但丢数据,适合可覆盖的监控指标。

Agent 场景通常需要混合策略：同一状态的元数据用租约,内容字段用 CRDT。但有一个边界必须说清楚：CRDT 保证的是结构一致性,不保证语义正确性。 两个 Agent 各自预订了同一间会议室,CRDT 能让两次写入都成功落地——数据结构完好,但物理世界无法执行。这类语义冲突,CRDT 解决不了,需要 Saga 模式加补偿事务来处理。更进一步,冲突的裁决逻辑本身也可以是状态的函数：低风险操作自动合并,高风险操作触发人工审批。静态的治理模式是起点,分级裁决才是终点。

迁移：Agent A 的上下文怎么传给 Agent B？不是简单地把内存序列化传过去,而是哪些状态该传、以什么形式传、传多少。传太多是噪音,传太少是信息丢失。

恢复：Agent 崩溃后,能从哪个点继续？每个状态变更有日志吗？能审计"谁在什么时候改了什么"吗？没有这个能力,Agent 工作流就无法在生产环境可靠运行。

这里有一个现成的参考实现：Temporal.io。它把每个状态变更记录为 Event,恢复时重放 Event History 重建完整状态——完整可审计、可从任意点恢复、支持长时间运行的工作流。Temporal 不是 Agent 框架,但它对恢复阶段的处理方式,是目前最完整的工程参考。

Temporal 与 LLM 的结合方式值得单独说清楚。Temporal 的重放依赖工作流代码的确定性,但 LLM 本身不是确定性系统——Temporal 官方文档明确指出 ,LLM 调用必须放在 Activities（而非 Workflow 代码）里执行6。这样 ,LLM 的每次输出都作为外部事件被记录进 Event History。崩溃恢复时,系统重放已记录的 LLM 输出,而不是重新调用模型——既保证了确定性,又避免了重放产生不同结果的问题。这个设计区分了"编排层的确定性"和"执行层的非确定性",是目前处理 LLM 非确定性与事件溯源之间张力的最成熟方案。

事件溯源有成本：变更频繁的系统,存储会爆炸。判断尺度是 RPO 和审计需求的交叉——高频变更、低审计需求,快照优先；低频变更、高审计需求,事件优先。大多数 Agent 场景需要混合策略。

终止：任务完成后,状态保留多久？归档策略是什么？历史状态能被复用或分析吗？大多数框架对这个阶段几乎没有系统性设计。

当前大多数 Agent 框架覆盖了创建和存储,部分覆盖了同步,对治理、迁移、恢复、终止几乎空白。

选型检查清单

使用前先判断：状态是否需要跨越多次请求、或在两个以上 Agent 之间共享？如果否,不需要往下看。

存储

  • 状态分层策略：热 / 温 / 冷 分别落在什么存储？
  • 最小变更单元：字段级 / 对象级 / 文件级？
  • RPO 是多少？RTO 是多少？

同步

  • 多 Agent 并发访问,冲突检测是自动还是手动？
  • 合并策略是什么？

治理

  • 写入权属于哪个 Agent？
  • 多 Agent 同时写入时,裁决规则是什么？（最后写入获胜 / 显式锁 / 合并函数 / Saga 补偿）
  • 冲突是否需要分级裁决？（低风险自动合并 / 高风险人工审批）
  • 租约时长和续期机制是什么？
  • 权限是否分层？（只读 / 建议 / 强制写入）

恢复

  • 快照策略：间隔多久？
  • 状态变更是否可审计？
  • 能否回滚到任意历史版本？
  • LLM 调用结果是否作为外部事件记录？（决定恢复时是精确复现还是需要重新调用模型）

终止

  • 归档策略：保留多久？
  • 历史状态能否被复用？

评估任何 Agent 工具时,用这三个问题：

一、覆盖了状态生命周期的几个阶段？ 只覆盖存储 → 基础工具。覆盖存储 + 同步 → 中等工具。覆盖完整周期含治理 → 状态基础设施。

二、状态粒度是什么？ 细粒度（字段 / token 级）→ 事件多,灵活,适合高频协作。粗粒度（文档 / 对象级）→ 简单,冲突多,适合低频沉淀。“git” 是文件级（粗）,“kv-cache” 是 token 级（极细）。

三、状态重建机制是什么,成本可以接受吗？ 无重建 → 出错就丢失（RPO = 全部,RTO = 即时）。快照重建 → 快照间隔内状态丢失（RPO = 快照间隔,RTO = 秒级）。事件驱动重建 → 完整可审计（RPO ≈ 零,RTO = 分钟～小时级）。事件驱动的存储成本最高,选之前先确认审计需求是否真的需要这个级别。

下一代竞争的三个方向

状态时间线：每个状态变更都可追溯、可审计、可回滚。时间线的价值不仅在于可回滚,更在于可诊断——当多 Agent 决策出问题时,能不能回溯到根源。这是生产环境可靠运行的基础,也是当前工具链最普遍缺失的能力。

多 Agent 状态协议：“git” 提供了概念启发——版本化、冲突检测、回滚能力。但 “git” 的数据模型（DAG、显式 commit、手动 merge）与实时优先本质冲突。真正的实时状态协议需要完全不同的数据结构：CRDT 处理结构层的自动合并,OT 处理操作转换,Saga 处理语义层的补偿回滚。三者各司其职,没有哪一个单独够用。不是"把 “git” 加速",是重新设计。这个协议目前还不存在,是真正的空位。

状态容错：Agent 出错后自动恢复状态的能力。会话崩溃后,能从上一个稳定状态继续。这不是锦上添花,是 Agent 工作流进入生产环境的入场券。但在多 Agent 并发写入共享状态的场景下,“上一个稳定状态"本身没有全局定义——恢复的粒度是全局 snapshot 还是 per-agent snapshot,取决于底层的一致性模型,这是状态容错在分布式场景下尚未有标准答案的部分。

算力和状态,不是替代关系

这篇文章不是在说算力不重要。

训练侧的算力竞赛远没有结束,Blackwell、GB200 的发布节奏说明头部玩家还在押注这个方向。更强的模型仍然会带来真实的能力提升。

但在推理和部署层,当模型能力足够处理大多数任务时,系统性能的主要瓶颈已经迁移——从"模型够不够强"变成"状态能不能被有效管理”。

这两件事并行发生,不是零和竞争。只是大多数讨论还集中在算力和模型,状态管理的重要性被系统性低估了。

“kv-cache”、数据库协调层、Agent 状态协议——每一个都有明确的工程问题等待解决。

瓶颈已经移动。大多数人还没转过头去看。

引用注释

  1. Spheron Blog / Morph LLM,Llama 3.1 70B 在 128K context 下 “kv-cache” 单请求约 40GB（BF16）。计算公式：2 × num_layers × num_kv_heads × head_dim × seq_length × bytes_per_element,随并发线性增长。 ↩︎ ↩︎

  2. MatX Research,“Optimize for inference too, not just training FLOPs”（2025）。以 Llama 3 8B、128 序列、8192 context 为例,“kv-cache” 加载的 FLOP 等效成本约为前向计算的 20 倍。 ↩︎

  3. Kwon et al.,“Efficient Memory Management for Large Language Model Serving with PagedAttention”,SOSP 2023（arXiv:2309.06180）。vLLM 相比 FasterTransformer 和 Orca 吞吐量提升 2～4 倍。 ↩︎

  4. Zheng et al.,“Efficiently Programming Large Language Models using SGLang”（arXiv:2312.07104）。RadixAttention 在多种工作负载下吞吐量提升最高 5 倍以上。 ↩︎

  5. Cloudflare Durable Objects 官方文档（developers.cloudflare.com/durable-objects）及 Cloudflare Agents SDK 文档（developers.cloudflare.com/agents）。 ↩︎

  6. Temporal 官方文档及 Temporal Blog,“Of course you can build dynamic AI agents with Temporal”（2025）。LLM 调用在 Temporal 中应放入 Activities,使输出作为外部事件被记录,而非 Workflow 代码本身,以保证编排层确定性。 ↩︎