Yandex把KV Cache变成Agent运行时：LLM不必每次从头思考

Yandex研究团队近日提出一种值得关注的Agent系统设计：不再只把KV Cache当作推理加速缓存，而是把它提升为LLM Agent的运行时状态。这意味着，Agent的记忆、通信、并发思考和环境交互，都可以直接围绕模型内部已经形成的KV Cache展开，而不是每次通过重新拼接Prompt来驱动模型。

这不是又一个Agent框架，也不是给现有模型外挂一个向量数据库。Yandex的判断更激进：**Agent的能力不仅由模型参数和外部Harness决定，推理运行时本身也可能是一个尚未被充分利用的能力维度。**模型不一定要换，Prompt也不一定要越写越复杂，改变模型推理状态的组织方式，可能就能让同一个模型表现得更像一个持续运行的程序。

KV Cache是什么：它本来只是一次推理的中间状态

**KV Cache是Transformer在自回归生成过程中保存的Key和Value张量，用来避免模型对历史Token重复计算。**模型每生成一个新Token，注意力机制都需要访问此前上下文对应的Key和Value；如果每轮都重新计算，长上下文和多轮对话的成本会快速上升，因此推理引擎会把这些中间结果缓存下来。

传统理解中，KV Cache更像一个一次性加速器。用户发送一段Prompt后，模型先进行Prefill，把输入上下文转成KV Cache；随后进入Decode阶段，逐Token生成输出。只要历史前缀没有变化，系统就可以复用对应缓存，降低首Token延迟，也就是TTFT。

但在普通LLM服务里，KV Cache通常有三个限制：它依附于单次请求，生命周期很短；它主要服务于连续文本生成，而不是多个并行任务之间的通信；它的内部结构通常由推理引擎管理，Agent编排层很难直接操作。

Yandex试图改变的正是这层抽象。**如果KV Cache代表的不只是已经读过的文本，而是模型当前正在执行的状态，那么它就可以承担类似操作系统运行时、进程地址空间或游戏引擎世界状态的角色。**Agent不必把所有信息重新序列化成Prompt，再交给模型从头读取，而是可以直接在已有推理状态上继续、分叉、合并或异步推进。

从并行Prompt到并发执行，关键变化在哪里

**传统Agent并行化主要是并行生成多段文本，而Yandex关注的是让多个推理过程共享和操控执行状态。**这两者看上去相似，工程效果却完全不同。

以一个需要搜索、规划和执行的Agent为例，常见做法是启动多个子Agent。每个子Agent都拿到一份完整的系统指令、任务背景和历史消息，然后分别生成结果。主Agent再把这些结果拼回上下文，继续下一轮推理。

这套流程的问题在于，子Agent之间传递的是文本，而不是模型已经计算过的内部状态。上游Agent说了1000个Token，下游Agent通常仍然需要对这1000个Token重新做Prefill。多个Agent互相通信时，重复计算会迅速累积，尤其是在全连接协作、长上下文研究和实时环境控制中更加明显。

Yandex的方案则把KV Cache拆成可以被调度的状态片段。不同Agent可以共享一部分公共上下文，也可以从同一状态分叉出多个推理分支；某个分支等待工具返回结果时，其他分支不必停下来；一个Agent产生的内部状态也有机会直接提供给另一个Agent，而不是先转成自然语言消息。

这会把Agent编排从消息队列问题，部分转化为状态调度问题。过去的核心接口是发送Prompt和接收文本，未来可能变成创建状态、复制状态、追加Token、挂起状态、恢复状态以及在状态之间传递信息。

Hogwild! Inference：让多个推理过程共享状态

**Hogwild! Inference是一种通过共享推理状态实现并行协作的思路，其灵感来自允许多个计算线程直接更新共享内存的Hogwild训练方法。**Yandex此前的相关工作探索了多个推理过程如何在不严格等待彼此完成的情况下，共同推进一个任务。

在标准Agent架构里，一个子任务通常需要等待前一个子任务完成，并接收完整文本结果后才能继续。这种串行依赖很容易把一个本来可以并行的工作流变成瀑布式流程。

Hogwild式推理允许不同推理线程围绕共享上下文工作。一个线程可能负责提出计划，另一个线程补充事实，第三个线程验证风险；它们不需要等所有输出都变成最终自然语言，再重新启动下一轮推理。部分结果可以更早地进入共享状态，其他线程则根据当前可见状态继续计算。

这种设计的价值不只是降低延迟。**它还可能改变Agent的协作方式：Agent之间交换的不再只是最终答案，而是正在形成中的推理状态。**这类似多人协同编辑文档，但共享对象从文本段落变成了模型运行时中的上下文和注意力状态。

当然，共享状态也带来一致性问题。两个推理分支可能同时修改同一段上下文，某个新信息可能让另一个分支的结论失效，系统必须决定哪些状态可以覆盖、哪些状态只能追加，以及冲突发生时是否需要回滚。Yandex目前展示的是研究方向，而不是已经标准化的通用运行时协议。

AsyncReasoning：思考和通信不必互相阻塞

**AsyncReasoning的核心是将模型内部推理与外部信息交换解耦，让Agent在等待通信、工具或环境反馈时仍然能够推进其他计算。**这更接近异步I/O系统，而不是一次请求对应一次完整生成。

传统工具调用通常是同步的：模型生成工具调用，推理暂停；工具返回结果，系统把结果追加到Prompt；模型重新Prefill，再继续生成。只要工具延迟较高，模型就会处于等待状态。多个工具并发时，编排层还需要处理超时、重试、结果排序和上下文拼接。

如果推理状态可以被挂起和恢复，Agent就能在等待搜索结果时先展开其他思路，在等待游戏环境下一帧时提前准备行动候选，或者同时维护多个假设。外部信息到达后，系统只需要把信息注入相关状态分支，而不必让整个Agent从完整Prompt重新开始。

这也是Yandex把KV Cache称作运行时的原因之一。**运行时不仅要保存模型已经生成的内容，还要负责调度哪些状态继续运行、哪些状态暂停、哪些状态复制，以及何时把环境事件送入模型。**在这个视角下，LLM更像一个带有异步事件循环的程序，而不是一个被反复调用的文本函数。

多模态Agent更像异步I/O系统

**多模态Agent的瓶颈往往不是生成文本，而是持续接收并处理来自环境的异步信号。**摄像头帧、游戏状态、鼠标键盘输入、传感器数据和网页变化，都可能以不同频率到达，且不一定需要完整地写入Prompt。

在DOOM这样的交互环境中，Agent需要同时处理视觉观察、动作选择、地图理解和长期目标。若每一帧都把全部历史截图、动作记录和任务说明重新塞进模型，系统会受到三重限制：上下文越来越长，Prefill越来越慢，模型还可能因为等待完整输入而错过实时动作窗口。

Yandex展示的未来工作预览中，一个基于Qwen3.8-27B的Agent将以类似方法交互式运行DOOM环境。这里真正值得关注的不是它能否通关，而是模型如何在持续变化的环境中维持状态：观察结果是否可以增量注入，动作决策是否能与环境反馈并行，旧状态是否可以保留为可回溯分支。

如果这条路线成立，Agent运行时的优化目标就不再只是每秒生成多少Token，而是每秒可以处理多少次环境事件、状态切换和行动决策。对于机器人、游戏Agent、桌面自动化和实时语音助手而言，这个指标可能比离线问答的吞吐量更重要。

它和Prefix Cache、LMCache不是一回事

**Prefix Cache主要解决相同输入前缀的重复Prefill，而Yandex讨论的是如何把KV Cache组织成可编程的Agent状态。**两者有联系，但目标并不相同。

Prefix Cache通常会检测不同请求之间是否存在相同前缀。如果存在，系统复用此前计算出的KV Cache，从而降低TTFT。LMCache等系统进一步把KV Cache从单个推理进程中抽离，支持在显存、CPU内存、本地存储甚至远程后端之间分层保存和复用。

这些技术对长上下文、多轮对话和RAG非常有效，但它们通常仍然把KV Cache视作缓存对象：命中就复用，未命中就重新计算。Yandex的研究则试图让缓存成为Agent的执行状态，允许系统对状态进行更细粒度的切分、排序、并发和通信。

| 方向 | 主要目标 | 状态生命周期 | 典型操作 | 适用场景 | |---|---|---|---|---| | Prefix Cache | 避免重复计算相同前缀 | 请求级或会话级 | 匹配、复用 | 多轮对话、固定系统Prompt | | LMCache类系统 | 跨请求、跨实例保存KV Cache | 可持久化 | 卸载、加载、跨引擎复用 | 长上下文、RAG、生产推理 | | KVCOMM | 让多Agent之间复用或近似传递KV状态 | 多Agent工作流级 | Anchor匹配、偏移估计、回退Prefill | 多Agent协作 | | Yandex Agent Runtime | 把KV Cache作为可调度执行状态 | 持续运行级 | 分叉、共享、异步推进、状态注入 | 实时Agent、环境交互、并发推理 |

KVCOMM提供了一个相邻方向的工程参照。相关工作针对多Agent系统中重复Prefill的问题，通过Anchor Matching和KV偏移近似，为不同Agent尝试补全可复用的KV状态；如果无法可靠补全，则回退到完整Prefill。补充资料给出的一个典型对比是：8B级模型在H100上处理约3K Token Prompt时，单次Prefill约需430毫秒，多Agent全连接通信会让重复计算快速累积；在特定实验设置下，KV通信方案将TTFT最高降低约7.8倍。

这个结果不能直接等同于Yandex方案的性能数据。前者更偏向KV Cache跨上下文复用，后者更偏向推理状态的运行时编程。两者共同说明了一件事：当Agent数量增加后，真正昂贵的部分往往不是生成答案，而是让每个Agent重新理解已经被其他Agent处理过的上下文。

为什么这条路线值得关注

**Yandex方案把Agent优化从模型层和Prompt层，推进到了推理系统层。**过去开发者想让Agent更聪明，通常只有三条路：换更大的模型，设计更复杂的Prompt，或者搭建更复杂的工具和工作流。现在，推理状态的组织方式可能成为第四条路。

这条路线的第一个价值是降低交互延迟。重复Prefill被减少后，Agent可以更快响应新事件，尤其适合需要持续反馈的任务。第二个价值是提高并发度。不同推理分支可以共享公共状态，不必为每个分支都维护一份完整文本上下文。第三个价值是支持更自然的暂停和恢复，这对长时间运行的Agent至关重要。

它还可能降低模型切换成本。更换模型通常意味着重新评估Prompt、工具调用格式和任务能力，而改造推理运行时有机会在不改变基础模型的前提下改善交互效率。当然，这并不意味着运行时优化可以替代更强模型。模型本身不会做规划，KV Cache也不会凭空制造知识；它解决的是状态利用效率和执行方式问题。

从产品角度看，这条路线最有潜力的地方是实时Agent。代码Agent的文件索引、编译和测试可以异步推进；浏览器Agent可以在页面加载期间继续规划；游戏Agent可以把视觉观察、动作候选和环境反馈做成持续循环；语音Agent可以减少每轮对话都重新读取历史上下文的开销。

但它距离生产可用还有明显距离

**KV Cache作为运行时的最大障碍不是想法，而是工程复杂度和状态安全性。**KV Cache并非普通文本，它与模型架构、层数、注意力头、数据类型、RoPE位置编码和推理批处理方式紧密相关。

首先，状态可移植性有限。不同模型、不同量化方式、不同并行策略下生成的KV Cache通常不能直接互换。即使是同一模型，如果上下文位置、RoPE缩放策略或张量布局发生变化，简单复制缓存也可能得到错误结果。

其次，显存占用会迅速增长。KV Cache大小大致与层数、KV头数量、每头维度、Token数量和数据类型成正比。一个长上下文Agent如果同时维护多个分支，缓存占用可能比单请求高出数倍。将状态卸载到CPU或磁盘能够缓解显存压力，却会引入传输延迟和带宽瓶颈。

再次，状态一致性需要新的协议。共享状态意味着权限控制、版本管理、冲突解决、回滚和垃圾回收都不能缺席。一个Agent是否可以读取另一个Agent的全部状态？工具返回的敏感信息是否会被自动传播？某个错误分支产生的Token如何撤销？这些问题在传统Prompt编排里通常可以通过删除一段文本解决，在KV层面则复杂得多。

最后是可观测性。开发者现在可以查看Prompt、工具调用和最终输出，但很难直接理解一份数十亿级浮点张量代表什么。未来的KV运行时必须提供状态快照、分支追踪、命中率、显存占用、恢复耗时和异常回滚等指标，否则排查问题会比今天困难一个数量级。

对开发者的实际启发

**短期内，开发者不必立刻重写Agent框架，但应该把上下文和状态分开设计。**即使底层还不能直接操控KV Cache，也可以提前为未来的运行时优化做好准备。

可以优先做四件事：

1. **减少无意义的全量重放。**把固定系统指令、工具描述、用户偏好和任务状态分层管理，避免每次工具返回都拼接一份巨大Prompt。
2. **区分可复用状态与一次性消息。**长期规则、项目索引和稳定背景适合缓存；瞬时观察、临时假设和高频环境事件应该单独管理。
3. **让Agent工作流支持暂停、恢复和分支。**不要把每次推理都设计成不可中断的线性链路，为异步执行和部分结果提前返回留下接口。
4. **记录真实的Prefill与Decode成本。**除了统计总响应时间，还应记录TTFT、Prefill Token数、Decode速度、缓存命中率、缓存占用和工具等待时间。

这些做法不会马上把现有系统变成Yandex所说的Agent Runtime，但可以帮助团队识别真正的瓶颈：究竟是模型生成慢，还是每一轮都在为相同上下文重复付费。

判断：Agent竞争正在从Prompt编排进入状态编程

**Yandex这项工作的核心价值，不在于宣布KV Cache可以被复用，而在于重新定义了Agent运行时的边界。**当模型被视作一个持续运行的状态机后，很多过去必须通过文本和Prompt解决的问题，都可以交给推理引擎处理。

这条路线目前仍然偏研究性质。它需要模型、推理框架、显存管理、调度系统和Agent编排层共同配合，短期内不会像新增一个工具调用接口那样容易落地。但它击中了Agent系统最顽固的成本中心：重复读取、重复Prefill和同步等待。

我的判断是，KV Cache运行时不会取代Prompt、工具调用或外部记忆，而会成为它们下面的一层基础设施。Prompt负责表达语义，工具负责连接外部世界，模型参数负责提供能力，KV Runtime则负责让这些能力以更少的重复计算持续运行。

截至2026年9月7日，Yandex关于Qwen3.8-27B交互式DOOM Agent的预览仍更像方向性演示，而不是完整产品。但如果这类实验最终证明：同一个模型仅通过更好的状态调度就能获得更低延迟、更高并发和更强环境适应性，那么下一轮Agent基础设施竞争，重点可能就不再是哪个框架能拼出更复杂的DAG，而是哪套运行时能让LLM真正持续地活在任务现场。

参考来源

• Reddit：KV cache as an agent runtime：Yandex研究方向的社区讨论入口，包含官方文章链接与研究背景。
• Yandex Research：《The KV cache as an agent runtime》：本文关于KV Cache运行时、Hogwild! Inference、AsyncReasoning及DOOM Agent预览的主要信息来源。由于官方研究站点不在本文要求保留的国内可访问域名范围内，未在文末直接附外链。
• KVCOMM：Online Cross-context KV-cache Communication for Efficient LLM-based Multi-agent Systems：关于多Agent KV通信、Anchor Matching及TTFT降低约7.8倍的补充参考资料。
• Agent Memory Below the Prompt：Persistent Q4 KV Cache for Multi-Agent LLM Inference on Edge Devices：关于持久化KV Cache和边缘设备多Agent推理的相关研究方向。