Agent间停止传字符串：共享KV Cache的内存级handoff优化

现代多 Agent AI 系统在编排层往往呈现出分布式架构。Planner 生成文本，Orchestrator 将文本传递给 Researcher，Researcher 再对其进行分词（tokenize），随后模型对已处理过的上下文重新执行 prefill 计算。

这种架构在检查层面很简单，但在架构上却效率低下。当多个 Agent 共享同一个基础模型时，反复传递大型文本上下文会导致不必要的分词、内存移动和冗余的 prefill 计算。

我们应该传递的是对模型现有 KV 缓存的引用，而不是已处理的上下文文本。

为什么基于字符串的传递代价高昂

以一个标准的多 Agent 流水线为例：User → Planner → Researcher → Reviewer → Coder。

在传统实现中，每次传递都会触发一个完整周期：

1. 序列化（Serialization）：将 LLM 输出转换为文本
2. 传输（Transfer）：将文本移动到编排器
3. 重新分词（Re-tokenization）：新 Agent 将文本转换回 token
4. 冗余 Prefill：模型重新计算它已经"知道"的 token 的 Key（K）和 Value（V）张量

对于长上下文的 RAG 或复杂的推理链，重复的 prefill 可以占请求总延迟的 50%–80%。

核心概念：KV 缓存复用

在 Transformer 推理期间，模型为注意力层计算 K 和 V 张量。这些被存储在 KV 缓存中，以避免在生成过程中重复计算之前的 token。

从概念上讲，我们希望从这种方式转变：

Agent A → [Raw Text] → Agent B

到这种方式：

Agent A → [KV Block Handle] → Agent B

如果后续 Agent 共享相同的基础模型和分词器，它可以"挂载"现有 KV 状态，而不是从头开始。

架构：共享推理运行时

要实现这一点，必须将 Agent 移动到共享的推理边界中。如果 Agent A 和 Agent B 位于不同的容器中，就会面临昂贵的序列化成本，从而抵消性能提升。

推荐技术栈

运行时：使用具有高级内存管理的引擎，如 vLLM、TensorRT-LLM 或 Triton。

策略：维护一个常驻基础模型，并为特定 Agent 角色（Planner、Researcher 等）配置多个 LoRA 适配器。

更安全的上下文句柄

编排层应该停止将上下文当作字符串来处理，开始将其视为虚拟上下文记录（Virtual Context Record）：

{
  "context_id": "ctx_8f21",
  "base_model": "llama-3-8b",
  "adapter_id": "researcher-lora",
  "cache_blocks": ["block_104", "block_105", "block_106"],
  "state": "retained"
}

不可变前缀与写时复制

一个健壮的设计将共享前缀视为不可变的。这借鉴了"写时复制"（Copy-on-Write，CoW）内存管理的思路：

• 共享前缀：通用历史（Blocks A → B → C）只计算一次
• 分支：如果 Researcher 和 Coder 都从这段历史开始，它们引用相同的不可变块
• 分歧：一旦它们生成了新的、独特的 token，运行时就会分配新的、特定于分支的缓存块

实用的迁移策略

你不需要在一夜之间重写整个技术栈。按这个顺序进行：

1. 识别昂贵的传递：分析。找到反复共享最大上下文窗口的两个 Agent
2. 统一推理：共置。将两个 Agent 移到同一个推理运行时实例（如 vLLM）背后
3. 实现句柄注册：编排。修改你的编排器，传递 context_id 而不是完整的提示字符串
4. 添加缓存生命周期管理：内存安全。实现明确的 retain 和 release 逻辑，防止 GPU OOM（内存溢出）错误
5. 保留文本回退：韧性。如果 KV 缓存被驱逐或不兼容，始终回退到标准的基于字符串的提示

多 Agent 编排的未来不是关于更高效地传递更多上下文——而是关于根本不传递已经计算过的上下文。

通过将你的互操作层（文本）与推理层（KV 引用）分离，你可以显著降低复杂 Agent 工作流中的延迟和计算成本。

你是否尝试过 KV 缓存复用？如果你在缓存驱逐或适配器兼容性方面遇到问题，请在评论中告诉我！