做多智能体系统久了你会发现一个特别反直觉的现象整套系统最慢的环节往往不是单个模型的推理而是多个智能体之间互相“传话”。这里的“传话”说的是现在主流多智能体框架里最常见的一种通信方式Agent A 把结论组织成一大段文本交给 Agent BAgent B 拿到手把这整段文本拼进自己的上下文再从头预填充一遍重新“理解”一遍。一次两次还能忍协作一长、上下文一涨“传话”的成本立刻变成整个系统的瓶颈。所以当 C2C 这个概念出现时很多做多智能体的人都眼前一亮与其让 A 先把结论一个字一个字地写出来再让 B 一个字一个字地读进去不如直接让 A 把推理过程中已经算好的 KV-Cache 交接给 B。省掉书写省掉重读理论上就是接近 2.5× 的加速。但真往深里做你会发现这 2.5× 是有代价的。C2C 把整个模型的“工作记忆”直接搬过去听着很美实际上牵出了五个非常棘手的死结上下文对齐、可信度验证、隔离失效、缓存一致性还有异构模型兼容。这篇文章我就把这五个坑一个一个掰开讲清楚。1. 先算一笔账智能体之间“说话”的成本到底贵在哪1.1 “话”不是白说的从 A 写到 B 读两次独立开销以最典型的协作开发场景为例Agent A 扮演需求分析师Agent B 扮演程序员。A 花了几十个来回的对话、工具调用最终产出一份两千字的需求文档。按照现在的框架设计A 要把这份文档作为自己的最终输出框架再把它作为一条消息塞给 B。B 拿到文档后首先要做的是把 A 的整份文档都编码进自己的上下文——这个编码过程不是简单的字符串拼接Transformer 必须对每个 token 都做一遍 attention 计算才能在“内部状态”里建立起对文档的语义理解。换句话说A 把结果从“内部表示”转成文本生成/解码B 再从文本转回自己的“内部表示”预填充/prefill。一来一回同一个信息在向量空间和符号空间之间走了两遍。这是两套完全独立的高开销过程还偏偏是串行依赖的B 必须要等 A 完全生成完毕才能开始自己的理解。我见过不少团队把多智能体系统的延迟问题归咎于单模型推理太慢其实仔细 profiling 之后会发现在长上下文协作场景下agent 间的文本生成加重读开销经常占到端到端耗时的 40% 以上。这个比例在上下文越长、协作轮数越多的时候越夸张。1.2 KV-Cache 到底是什么模型的工作笔记要理解 C2C 在做什么先得清楚 KV-Cache 是什么。Transformer 在做自回归生成时每生成一个新的 token注意力层都要拿这个新 token 的 Query 去跟前面所有 token 的 Key 做匹配再根据匹配结果聚合对应的 Value。如果每一步都重新计算前面所有 token 的 Key 和 Value计算量会随序列长度二次增长谁也扛不住。所以业界普遍的做法是算过的 Key 和 Value 就不再丢存下来后面每一步只对新 token 计算 K/V然后追加到缓存里。这个缓存就是 KV-Cache。打个比方这就像一个学生在做一道很长的证明题不是每一步都从公理重新推导而是把中间结果记在草稿纸上。KV-Cache 就是模型的草稿纸。还有一点值得注意这个缓存不是抽象的“知识”它跟当前已经处理过的 token 序列严格绑定。换一个字、改一个标点后面的 K/V 向量都会不一样。这一点在后面的死结一里会反复出现。1.3 Prefill 和 Decode 的不对称账单业界通常把一次模型推理分成两个阶段prefill 阶段处理整个 prompt 前缀并行地生成所有输入 token 的 K/V和 decode 阶段逐个 token 生成输出。有趣的是这两个阶段的成本结构完全不同。prefill 是计算密集的但是可以并行decode 是串行的每一步都依赖上一步延迟天然被乘上输出 token 数。一个 2000 token 的输出意味着至少 2000 次串行的 decode 步骤哪怕单步只有几十毫秒总时长也是不可忽略的。所以在多智能体协作里“A 写文本给 B”这笔账是由 A 的 decode 和 B 的 prefill 两部分构成的。而 KV-Cache 恰恰把这两部分都指向了“可绕过的重复劳动”A 的 K/V 已经是算好的B 为什么还要重新算一遍这里其实也是 C2C 的直觉根源两个 agent 如果共享了同一段工作记忆就不需要在符号层反复搬运。接下来我们看看 C2C 具体是怎么操作的以及那个 2.5× 是从哪些开销里省出来的。2. C2C 实际在做什么从“传递结论”变成“交接工作记忆”2.1 不再传文本而是传矩阵C2CCache-to-Cache的核心动作说起来很简单Agent A 在完成自己的推理任务之后不再只输出一段文本结论而是把自己当前上下文对应的 KV-Cache或者其中与任务相关的一段切片导出直接交给 Agent B。B 拿到这份缓存后不需要再对 A 的长篇输出做一次完整的 prefill而是把这份缓存当成自己上下文的一部分直接开始后续推理。听起来很美。但我必须提醒第一次接触这个概念的人KV-Cache 不是一段“干净的结论”它是 A 在处理完整对话期间逐步累积的全部中间状态。它既包含了 A 真正想传达的结论也包含了 A 的思考链、工具返回、纠错痕迹甚至还有 A 的私有系统提示。C2C 这一步交接本质上是在两个智能体之间做了一次“工作记忆移植”。如果处理不好B 继承的就不只是结论还有 A 的一堆私货和噪声。2.2 2.5× 加速的来源与边界那 2.5× 是怎么来的简化地说它主要省下了两笔开销第一笔是 A 的 decode 成本。A 不需要把完整结论逐 token 生成出来这是最耗时的串行过程它只需要生成一个“交接标记”或者直接导出当前缓存。第二笔是 B 的 prefill 成本。B 不需要把 A 的全部输出重新编码进自己的 KV-Cache省掉了对几千甚至上万 token 的重复计算。两者加在一起在“长消息、单轮交接”的场景下端到端延迟减少 60% 左右并不夸张对应约 2.5× 的加速。有些实验场景更高有些更低取决于消息长度、缓存大小、传输带宽。不过有笔账别漏算KV-Cache 本身是要搬运的。一个 8B 模型在 4K 上下文下fp16 的 KV-Cache 大约在 0.5 到 1GB 量级上下文到了 32K那就是好几个 GB。如果 Agent A 和 Agent B 跑在同一台机器、共享显存或内存这笔搬运还算可控一旦跨机传输网络带宽可能直接把优化收益吃掉。所以 2.5× 这个数字不是白拿的它是一个在“缓存传输成本可控”前提下的理想值。2.3 本质上C2C 把通信问题变成了架构问题我在做方案评审的时候经常跟团队讲一句话C2C 表面上是个性能优化方案实际上是一个架构约束方案。因为它对参与者的要求远比“文本消息”严格得多。文本消息只要双方都懂同一种语言就行KV-Cache 交接要求双方模型结构一致、上下文前缀一致、信任域一致、生命周期策略一致。这些要求就是接下来五个死结的源头。下面我们进入正题把这五个死结挨个拆开。3. 第一个死结上下文对齐——你的草稿纸页码和我对不上3.1 Cache 是“前缀绑定”的不是自由的记忆KV-Cache 最容易被忽略的性质是它和前缀严格绑定。K/V 向量是由一个 token 经过多层 Transformer 变换得到的而这个变换强烈依赖该 token 之前的所有 token。你只要在前面的对话历史里多加一句话、改变一下工具返回的顺序后面所有 token 的 K/V 数值都会发生蝴蝶效应式的变化。因此一个 Cache 并不是“通用的记忆”它是“特定前缀下的记忆快照”。Agent A 手里的 Cache记录的是 A 的完整上下文而 Agent B 如果直接把它塞进自己的上下文B 实际得到的并不是“A 的结论”而是“A 的上下文”。如果 B 自己的 system prompt、历史记录和 A 不一致这两套上下文根本没法对齐轻则效果变差重则直接产出矛盾结果。3.2 多智能体场景里的对齐有多难在多智能体协作里上下文对齐的难度被进一步放大。每个 agent 通常都有自己的 system prompt角色设定、工具描述、输出格式要求、自己的对话历史、自己的工具调用日志。你让一个 C2C 框架把 A 的缓存原封不动传给 B相当于让 B 突然继承了 A 的全部历史上下文而 B 自己那套上下文还没处理完。结果就是 B 的注意力被大量无关信息干扰推理质量反而下降。我见过有人在 C2C 实验里遇到一个经典问题A 的上下文里有一段私密的思考链比如“我先假设 X再排除 Y”B 拿到缓存后直接把这段思考链当成了任务背景最后给出的答案带着 A 的犹豫和中间噪声逻辑反而混乱了。这不能简单说是 C2C 不行而是根本没有做“对齐设计”。3.3 工程出路共享前缀 缓存切片目前比较务实的做法有两个方向。一个是“共享前缀”让所有参与 C2C 的 agent 使用同一个公共的 system prompt 前缀、统一的序列化格式比如共享上下文全部用固定的 JSON 结构表示、统一的工具调用日志顺序。这样至少在公共前缀这段双方的 Cache 是可以无缝衔接的。一旦某个 agent 在前缀里多加了一行角色描述后续所有交接的 Cache 全部作废——这不是我危言耸听而是前缀绑定特性决定的硬约束。另一个方向是“缓存切片”不要把整段 Cache 交出去只导出“结论证据”对应的那一段 token 的 K/V。这需要在导出时记录 token 的起始位置和长度接收方把这些切片当作一段“外部记忆”挂在公共前缀后面。这样做能明显降低上下文污染但代价是实现复杂度上来了你不能再把 Cache 当成一整块数据而要能精确控制切片边界。导出前还需要对公共前缀做一次哈希校验确认两边前缀一致否则切片接上去位置语义就是错的。4. 第二个死结可信度验证——你拿到的 Cache 里有没有“私货”4.1 文本能验货张量不能传统的文本消息至少有一个好处可审计。你可以对文本做关键词过滤、做引用检查、甚至让人肉眼看一遍。KV-Cache 不是这样的——它是一堆浮点张量。你可以把它 dump 出来但没有人能直接“看出”这堆数字里隐藏着什么。这引出一个非常现实的安全问题如何验证一个 Cache 是可信的多个智能体协作时A 可能是协作方也可能是被攻破的一方。一个恶意智能体完全可以构造一个看起来正常的 Cache让 B 在不知不觉中按照它预设的方向输出。这和 prompt injection 原理类似但危害要高一个量级——因为注入的内容不再是可读的字符串而是“向量级注入”。4.2 投毒有多隐蔽一个不可见的 payload具体一点说恶意构造者可以改变某段上下文对应 K/V 的数值使得接收方模型在后续推理时对某些指令的敏感度被放大或者在答案中夹带攻击者想要的信息。由于这些操作发生在高维浮点空间中常规的文本检测手段全部失效。更麻烦的是KV-Cache 通常直接保存在显存或内存里同一进程内的多个 agent 如果共享了内存池理论上任何一方都能读写同一块缓存区域。一次看似普通的协作完全可能把恶意内容带进整条 agent 链路。我自己的经验是凡是涉及外部输入的多智能体场景第一个要问的问题不是“怎么加速”而是“这份中间结果我能验货吗”。验不了货的加速在生产环境里就是一颗定时炸弹。4.3 工程出路签名、哈希与抽样验证目前做 C2C 的团队一般会加三道保险。第一道是“缓存签名”导出 Cache 时连同对应的上下文前缀一起做哈希并对哈希做数字签名接收方导入时先验证前缀哈希是否匹配不匹配就拒绝。第二道是“抽样验证”接收方从传来的 Cache 里随机抽取一小段位置用自己的模型重新 prefill 相同的 token对比两者在最后一层输出的 logits 是否接近。如果差得远说明 Cache 大概率被动过手脚。第三道是“信任边界”跨进程或跨机器的缓存传输最好走受信任执行环境或加密通道避免中间人篡改。这三道保险没有一道是零成本的尤其抽样验证本身就引入了额外的 prefill 开销等于把 C2C 省下来的一部分收益又还了回去。所以实际落地时一般只对关键交接做验证普通协作轮次靠前缀哈希就够了。5. 第三个死结隔离失效——Cache 比聊天记录泄露得更多5.1 KV-Cache 是上下文的“指纹”很多人第一次接触 KV-Cache 时默认它是一个抽象的内部状态不会泄密。这个直觉是错的。K 和 V 是由上下文中每个 token 经过线性变换得到的它们本质上携带了 token 的语义信息。在模型结构兼容、层数对齐的前提下分析 K/V 数值是有机会反推出上下文里出现过哪些内容方向的——学术上这个方向叫 embedding/activation inversion已有大量研究表明中间层激活和缓存并不是安全的黑盒。C2C 的问题在于它把这种“指纹”直接从 A 完整地移交给了 B。B 不仅能读到 A 的文本输出还能顺带接近 A 的全部中间状态。在一个多智能体开发团队里这意味着需求分析 Agent 的对话历史、项目里的敏感细节、代码 Agent 读过的私有文件理论上都可能随着一次 Cache 交接进入另一个 Agent 的上下文。5.2 更隐蔽的风险绕过安全对齐还有一个极少被讨论但非常要命的问题C2C 会绕过模型自身的对齐与安全过滤。A 在生成文本时通常会经过系统级的内容过滤和模型自身的对齐微调但当 A 把 Cache 传给 B 时Cache 是纯数值A 的安全层完全没有机会参与最后一道校验。B 直接拿着 A 的“原始记忆”继续推理等于把 A 在推理前做过的一切安全兜底全部架空了。这一点在可信多智能体系统里几乎是致命的。你可以想象一个主 Agent 被植入了恶意缓存下游所有 Agent 都会基于这个被污染的“记忆”行动而整个链条里没有任何一环能看到文本形式的可疑 payload。如果系统设计时没有给缓存交接加隔离层这种风险就是结构性的不是靠加一两个过滤器能补上的。5.3 工程出路上下文最小化与信任域隔离目前可行的缓解措施本质上都是“少传一点、传得谨慎一点”。一是上下文最小化交接前强制裁剪只保留与任务直接相关的结论和证据不传全量历史。二是信任域隔离C2C 只在同一个受信任的 agent 集群内部使用跨信任域比如接外部模型或第三方 Agent时强制降级为文本消息。三是在隐私敏感场景下对将要交接的 Cache 做扰动给部分 K/V 注入受控噪声让窃取方只能拿到近似信息代价是下游推理精度会略降。从成本收益看上下文最小化是最优先做的因为它同时缓解了死结一里的“上下文污染”和这个死结里的“隐私泄露”。只传必要的结论和证据C2C 的收益虽然会打点折但系统整体风险能降一大截。6. 第四个死结缓存一致性与生命周期——快照终究会变成旧闻6.1 Cache 是一张会过期的快照多智能体系统不是静态的。Agent A 可能在给你导出 Cache 之后又收到新的工具返回、新的用户指令或者自己在后台更新了上下文记忆。你手里那份 Cache严格来说只是 A 在 T 时刻的一次快照。等 B 真正用到它时A 可能已经走远了。这跟分布式系统里的缓存一致性问题是同构的数据源变了副本却不自知。在文本消息时代这个问题相对温和——A 发给 B 的是一份已经定稿的文本文本自带时间戳而在 C2C 时代B 继承的是“活的内部状态”它没有年龄概念B 也不知道这份记忆是否过期。于是 B 可能基于一份陈旧快照给出理直气壮但完全不符合现状的答案。6.2 级联失效是最难处理的部分我在实际推演多智能体 C2C 架构时发现最痛苦的不是单跳传递而是级联失效A 的缓存给 BB 基于它产出计划再传给 CC 又传给 D……只要 A 的上下文在某个时刻更新了一处旧快照就会沿着下游依赖链四处扩散。你需要一本“账”记录每个 agent 当前持有的缓存版本、依赖关系、失效通知。否则整个系统会出现大量“明明每个环节都正确但最终答案却过时”的诡异错误而且这类错误极难定位因为每一步的输出在本地看都是自洽的。我自己在推演时经常把这类问题画成依赖树但真正落地的复杂度远超理论模型。比如 A 更新了一处结论B 引用了旧结论并且基于它做了代码修改C 又根据 B 的代码写了测试——这个时候要回滚的不只是缓存还有所有下游已经产生的“新上下文”。所以我一贯的建议是不要让 C2C 缓存跨越太多跳数。6.3 工程出路只追加、版本化、按需失效我比较看好的做法是三条。第一把协作缓存设计成“不可变追加”的形式。每个 agent 产生的结论就是一个带版本号的提交记录类似 Git 的 commit。下游 Agent 引用的永远是某个明确的提交而不是一个会变的全局状态。第二给每次 Cache 导出打上版本号和依赖链信息。一旦上游有更新就沿依赖链广播失效通知下游可以决定是重新拉取还是继续用旧快照并明确标注“基于过期上下文”。第三不是所有协作都值得做 C2C——如果某个环节的上下文高频变化、且要跨多跳传递不如退回到文本消息加清晰的引用编号避免级联失效带来的复杂度爆炸。7. 第五个死结异构模型兼容——把大象塞进冰箱冰箱得够大7.1 结构不匹配KV-Cache 的形状就是硬约束KV-Cache 的形状由模型结构直接决定层数、注意力头数、每组头数GQA/MQA、隐藏维度、精度类型任何一个不同缓存都没法原样搬运。最朴素的情况A 是 8B 模型B 是 70B 模型层数差好几倍KV-Cache 的 shape 完全对不上数学上根本不存在“直接传给 B”的可能。哪怕层数相同如果头数不同比如 A 是 GQA 分组 4B 是分组 8K/V 的维度组织也不一致。所以真实的 C2C 项目里大家几乎都会做一个看起来很“不酷”的决定所有参与协作的 agent 统一使用同一个基座模型。想要角色差异就通过不同的 LoRA 适配器或者不同的系统提示来实现。这等于为了缓存可迁移放弃了模型多样性但这是绕不开的硬约束。7.2 位置编码一个容易翻车的小细节就算你实现了“同基座模型”还有一个细节专门等着你踩位置编码。现在主流模型大多用 RoPE旋转位置编码位置信息是叠加在 Q 和 K 向量上的。如果两个模型用了不同的 RoPE 配置——旋转维度不同、频率基数不同、甚至只是 tokenizer 不同导致同一句话的 token 切分不同——那么同一位置的 K 向量代表的语义位置就完全对不上。传过去的 Cache 看似 shape 正确实际位置语义已经错乱下游推理结果直接乱套。这个细节很坑因为它不会在报错信息里出现。shape 全部匹配forward 也能跑就是效果崩了。我见过不止一个团队花了很久排查最后发现是两个 agent 微调时用了不同版本的 tokenizer 文件导致同一段公共前缀被切分成不同的 token 序列所有后续 Cache 全部作废。这类问题在文本消息时代根本不存在是 C2C 独有的心智负担。7.3 工程出路统一规范 低秩适配想在工程上落地至少要做到统一基座模型版本、统一 tokenizer、统一 RoPE 配置、统一公共前缀模板并把每一次模型升级都当成一次“缓存协议变更”来对待。角色的差异化尽量用 LoRA 适配器承载。这里的原则是主体结构必须完全一致个性差异全部留在可以“剥离/挂载”的旁路里。这样做虽然牺牲了混编不同厂商模型的自由但换来的是 C2C 可以成立。如果你预期的系统里必须混用多个不同架构的模型那基本可以提前给 C2C 判死刑了。8. 串起来看实践建议与我的判断8.1 什么样的场景才值得上 C2C把五个死结串起来看C2C 并不是所有多智能体场景的银弹。我判断一个项目适不适合上 C2C一般会看四条是不是长上下文高频协作文本传递的账单足够大是不是同一信任域Agent 之间可以互相信任、共享密钥模型是否统一可控能接受只用同一个基座任务链路是否短且清晰不太需要跨多跳级联失效管理。四条都满足C2C 才值得认真做否则建议先用文本消息加普通上下文缓存把系统跑稳再考虑逐步引入。8.2 一个务实的渐进路线如果你所在团队想试探 C2C我不建议一上来就全量传递 KV-Cache。可以先做“混合模式”主体仍然是文本协作但对最昂贵的那一跳比如生成长报告再让下游从头读的高频交接做缓存级优化。先加公共前缀和 Cache 切片再加签名校验再考虑版本化。每一步都只解决一个死结验证收益后再往下走这样不至于把架构复杂度一次性推到不可维护的程度。8.3 最后想说的话从纯性能数字看2.5× 的加速确实诱人。但我把五个死结拆开之后更深的感受是C2C 与其说是一种加速技巧不如说是一种沟通协议的重新设计。它逼着我们把“谁可以知道什么、谁可以信任谁、模型之间如何保持一致”这些问题前置到架构层面。以我目前的实践经验真正能从 C2C 里稳定获益的团队通常都是先在文本协作层面把协议、版本、信任模型理得很清楚的团队。性能优化的前置条件往往不是调参而是把约定做对。这个方向很有前景但我还想多说一句不管未来 C2C 的协议怎么演进“能退回到文本”始终应该作为降级方案保留。缓存交接一旦出问题排查难度远超文本消息。留下这个逃生通道你在生产环境里才敢真正压上性能。 
长河君 · 2026/11/4 14:38:31 · 阅读 1.2k C2C缓存交接：多智能体通信加速的五大死结与工程出路
做多智能体系统久了你会发现一个特别反直觉的现象整套系统最慢的环节往往不是单个模型的推理而是多个智能体之间互相“传话”。这里的“传话”说的是现在主流多智能体框架里最常见的一种通信方式Agent A 把结论组织成一大段文本交给 Agent BAgent B 拿到手把这整段文本拼进自己的上下文再从头预填充一遍重新“理解”一遍。一次两次还能忍协作一长、上下文一涨“传话”的成本立刻变成整个系统的瓶颈。所以当 C2C 这个概念出现时很多做多智能体的人都眼前一亮与其让 A 先把结论一个字一个字地写出来再让 B 一个字一个字地读进去不如直接让 A 把推理过程中已经算好的 KV-Cache 交接给 B。省掉书写省掉重读理论上就是接近 2.5× 的加速。但真往深里做你会发现这 2.5× 是有代价的。C2C 把整个模型的“工作记忆”直接搬过去听着很美实际上牵出了五个非常棘手的死结上下文对齐、可信度验证、隔离失效、缓存一致性还有异构模型兼容。这篇文章我就把这五个坑一个一个掰开讲清楚。1. 先算一笔账智能体之间“说话”的成本到底贵在哪1.1 “话”不是白说的从 A 写到 B 读两次独立开销以最典型的协作开发场景为例Agent A 扮演需求分析师Agent B 扮演程序员。A 花了几十个来回的对话、工具调用最终产出一份两千字的需求文档。按照现在的框架设计A 要把这份文档作为自己的最终输出框架再把它作为一条消息塞给 B。B 拿到文档后首先要做的是把 A 的整份文档都编码进自己的上下文——这个编码过程不是简单的字符串拼接Transformer 必须对每个 token 都做一遍 attention 计算才能在“内部状态”里建立起对文档的语义理解。换句话说A 把结果从“内部表示”转成文本生成/解码B 再从文本转回自己的“内部表示”预填充/prefill。一来一回同一个信息在向量空间和符号空间之间走了两遍。这是两套完全独立的高开销过程还偏偏是串行依赖的B 必须要等 A 完全生成完毕才能开始自己的理解。我见过不少团队把多智能体系统的延迟问题归咎于单模型推理太慢其实仔细 profiling 之后会发现在长上下文协作场景下agent 间的文本生成加重读开销经常占到端到端耗时的 40% 以上。这个比例在上下文越长、协作轮数越多的时候越夸张。1.2 KV-Cache 到底是什么模型的工作笔记要理解 C2C 在做什么先得清楚 KV-Cache 是什么。Transformer 在做自回归生成时每生成一个新的 token注意力层都要拿这个新 token 的 Query 去跟前面所有 token 的 Key 做匹配再根据匹配结果聚合对应的 Value。如果每一步都重新计算前面所有 token 的 Key 和 Value计算量会随序列长度二次增长谁也扛不住。所以业界普遍的做法是算过的 Key 和 Value 就不再丢存下来后面每一步只对新 token 计算 K/V然后追加到缓存里。这个缓存就是 KV-Cache。打个比方这就像一个学生在做一道很长的证明题不是每一步都从公理重新推导而是把中间结果记在草稿纸上。KV-Cache 就是模型的草稿纸。还有一点值得注意这个缓存不是抽象的“知识”它跟当前已经处理过的 token 序列严格绑定。换一个字、改一个标点后面的 K/V 向量都会不一样。这一点在后面的死结一里会反复出现。1.3 Prefill 和 Decode 的不对称账单业界通常把一次模型推理分成两个阶段prefill 阶段处理整个 prompt 前缀并行地生成所有输入 token 的 K/V和 decode 阶段逐个 token 生成输出。有趣的是这两个阶段的成本结构完全不同。prefill 是计算密集的但是可以并行decode 是串行的每一步都依赖上一步延迟天然被乘上输出 token 数。一个 2000 token 的输出意味着至少 2000 次串行的 decode 步骤哪怕单步只有几十毫秒总时长也是不可忽略的。所以在多智能体协作里“A 写文本给 B”这笔账是由 A 的 decode 和 B 的 prefill 两部分构成的。而 KV-Cache 恰恰把这两部分都指向了“可绕过的重复劳动”A 的 K/V 已经是算好的B 为什么还要重新算一遍这里其实也是 C2C 的直觉根源两个 agent 如果共享了同一段工作记忆就不需要在符号层反复搬运。接下来我们看看 C2C 具体是怎么操作的以及那个 2.5× 是从哪些开销里省出来的。2. C2C 实际在做什么从“传递结论”变成“交接工作记忆”2.1 不再传文本而是传矩阵C2CCache-to-Cache的核心动作说起来很简单Agent A 在完成自己的推理任务之后不再只输出一段文本结论而是把自己当前上下文对应的 KV-Cache或者其中与任务相关的一段切片导出直接交给 Agent B。B 拿到这份缓存后不需要再对 A 的长篇输出做一次完整的 prefill而是把这份缓存当成自己上下文的一部分直接开始后续推理。听起来很美。但我必须提醒第一次接触这个概念的人KV-Cache 不是一段“干净的结论”它是 A 在处理完整对话期间逐步累积的全部中间状态。它既包含了 A 真正想传达的结论也包含了 A 的思考链、工具返回、纠错痕迹甚至还有 A 的私有系统提示。C2C 这一步交接本质上是在两个智能体之间做了一次“工作记忆移植”。如果处理不好B 继承的就不只是结论还有 A 的一堆私货和噪声。2.2 2.5× 加速的来源与边界那 2.5× 是怎么来的简化地说它主要省下了两笔开销第一笔是 A 的 decode 成本。A 不需要把完整结论逐 token 生成出来这是最耗时的串行过程它只需要生成一个“交接标记”或者直接导出当前缓存。第二笔是 B 的 prefill 成本。B 不需要把 A 的全部输出重新编码进自己的 KV-Cache省掉了对几千甚至上万 token 的重复计算。两者加在一起在“长消息、单轮交接”的场景下端到端延迟减少 60% 左右并不夸张对应约 2.5× 的加速。有些实验场景更高有些更低取决于消息长度、缓存大小、传输带宽。不过有笔账别漏算KV-Cache 本身是要搬运的。一个 8B 模型在 4K 上下文下fp16 的 KV-Cache 大约在 0.5 到 1GB 量级上下文到了 32K那就是好几个 GB。如果 Agent A 和 Agent B 跑在同一台机器、共享显存或内存这笔搬运还算可控一旦跨机传输网络带宽可能直接把优化收益吃掉。所以 2.5× 这个数字不是白拿的它是一个在“缓存传输成本可控”前提下的理想值。2.3 本质上C2C 把通信问题变成了架构问题我在做方案评审的时候经常跟团队讲一句话C2C 表面上是个性能优化方案实际上是一个架构约束方案。因为它对参与者的要求远比“文本消息”严格得多。文本消息只要双方都懂同一种语言就行KV-Cache 交接要求双方模型结构一致、上下文前缀一致、信任域一致、生命周期策略一致。这些要求就是接下来五个死结的源头。下面我们进入正题把这五个死结挨个拆开。3. 第一个死结上下文对齐——你的草稿纸页码和我对不上3.1 Cache 是“前缀绑定”的不是自由的记忆KV-Cache 最容易被忽略的性质是它和前缀严格绑定。K/V 向量是由一个 token 经过多层 Transformer 变换得到的而这个变换强烈依赖该 token 之前的所有 token。你只要在前面的对话历史里多加一句话、改变一下工具返回的顺序后面所有 token 的 K/V 数值都会发生蝴蝶效应式的变化。因此一个 Cache 并不是“通用的记忆”它是“特定前缀下的记忆快照”。Agent A 手里的 Cache记录的是 A 的完整上下文而 Agent B 如果直接把它塞进自己的上下文B 实际得到的并不是“A 的结论”而是“A 的上下文”。如果 B 自己的 system prompt、历史记录和 A 不一致这两套上下文根本没法对齐轻则效果变差重则直接产出矛盾结果。3.2 多智能体场景里的对齐有多难在多智能体协作里上下文对齐的难度被进一步放大。每个 agent 通常都有自己的 system prompt角色设定、工具描述、输出格式要求、自己的对话历史、自己的工具调用日志。你让一个 C2C 框架把 A 的缓存原封不动传给 B相当于让 B 突然继承了 A 的全部历史上下文而 B 自己那套上下文还没处理完。结果就是 B 的注意力被大量无关信息干扰推理质量反而下降。我见过有人在 C2C 实验里遇到一个经典问题A 的上下文里有一段私密的思考链比如“我先假设 X再排除 Y”B 拿到缓存后直接把这段思考链当成了任务背景最后给出的答案带着 A 的犹豫和中间噪声逻辑反而混乱了。这不能简单说是 C2C 不行而是根本没有做“对齐设计”。3.3 工程出路共享前缀 缓存切片目前比较务实的做法有两个方向。一个是“共享前缀”让所有参与 C2C 的 agent 使用同一个公共的 system prompt 前缀、统一的序列化格式比如共享上下文全部用固定的 JSON 结构表示、统一的工具调用日志顺序。这样至少在公共前缀这段双方的 Cache 是可以无缝衔接的。一旦某个 agent 在前缀里多加了一行角色描述后续所有交接的 Cache 全部作废——这不是我危言耸听而是前缀绑定特性决定的硬约束。另一个方向是“缓存切片”不要把整段 Cache 交出去只导出“结论证据”对应的那一段 token 的 K/V。这需要在导出时记录 token 的起始位置和长度接收方把这些切片当作一段“外部记忆”挂在公共前缀后面。这样做能明显降低上下文污染但代价是实现复杂度上来了你不能再把 Cache 当成一整块数据而要能精确控制切片边界。导出前还需要对公共前缀做一次哈希校验确认两边前缀一致否则切片接上去位置语义就是错的。4. 第二个死结可信度验证——你拿到的 Cache 里有没有“私货”4.1 文本能验货张量不能传统的文本消息至少有一个好处可审计。你可以对文本做关键词过滤、做引用检查、甚至让人肉眼看一遍。KV-Cache 不是这样的——它是一堆浮点张量。你可以把它 dump 出来但没有人能直接“看出”这堆数字里隐藏着什么。这引出一个非常现实的安全问题如何验证一个 Cache 是可信的多个智能体协作时A 可能是协作方也可能是被攻破的一方。一个恶意智能体完全可以构造一个看起来正常的 Cache让 B 在不知不觉中按照它预设的方向输出。这和 prompt injection 原理类似但危害要高一个量级——因为注入的内容不再是可读的字符串而是“向量级注入”。4.2 投毒有多隐蔽一个不可见的 payload具体一点说恶意构造者可以改变某段上下文对应 K/V 的数值使得接收方模型在后续推理时对某些指令的敏感度被放大或者在答案中夹带攻击者想要的信息。由于这些操作发生在高维浮点空间中常规的文本检测手段全部失效。更麻烦的是KV-Cache 通常直接保存在显存或内存里同一进程内的多个 agent 如果共享了内存池理论上任何一方都能读写同一块缓存区域。一次看似普通的协作完全可能把恶意内容带进整条 agent 链路。我自己的经验是凡是涉及外部输入的多智能体场景第一个要问的问题不是“怎么加速”而是“这份中间结果我能验货吗”。验不了货的加速在生产环境里就是一颗定时炸弹。4.3 工程出路签名、哈希与抽样验证目前做 C2C 的团队一般会加三道保险。第一道是“缓存签名”导出 Cache 时连同对应的上下文前缀一起做哈希并对哈希做数字签名接收方导入时先验证前缀哈希是否匹配不匹配就拒绝。第二道是“抽样验证”接收方从传来的 Cache 里随机抽取一小段位置用自己的模型重新 prefill 相同的 token对比两者在最后一层输出的 logits 是否接近。如果差得远说明 Cache 大概率被动过手脚。第三道是“信任边界”跨进程或跨机器的缓存传输最好走受信任执行环境或加密通道避免中间人篡改。这三道保险没有一道是零成本的尤其抽样验证本身就引入了额外的 prefill 开销等于把 C2C 省下来的一部分收益又还了回去。所以实际落地时一般只对关键交接做验证普通协作轮次靠前缀哈希就够了。5. 第三个死结隔离失效——Cache 比聊天记录泄露得更多5.1 KV-Cache 是上下文的“指纹”很多人第一次接触 KV-Cache 时默认它是一个抽象的内部状态不会泄密。这个直觉是错的。K 和 V 是由上下文中每个 token 经过线性变换得到的它们本质上携带了 token 的语义信息。在模型结构兼容、层数对齐的前提下分析 K/V 数值是有机会反推出上下文里出现过哪些内容方向的——学术上这个方向叫 embedding/activation inversion已有大量研究表明中间层激活和缓存并不是安全的黑盒。C2C 的问题在于它把这种“指纹”直接从 A 完整地移交给了 B。B 不仅能读到 A 的文本输出还能顺带接近 A 的全部中间状态。在一个多智能体开发团队里这意味着需求分析 Agent 的对话历史、项目里的敏感细节、代码 Agent 读过的私有文件理论上都可能随着一次 Cache 交接进入另一个 Agent 的上下文。5.2 更隐蔽的风险绕过安全对齐还有一个极少被讨论但非常要命的问题C2C 会绕过模型自身的对齐与安全过滤。A 在生成文本时通常会经过系统级的内容过滤和模型自身的对齐微调但当 A 把 Cache 传给 B 时Cache 是纯数值A 的安全层完全没有机会参与最后一道校验。B 直接拿着 A 的“原始记忆”继续推理等于把 A 在推理前做过的一切安全兜底全部架空了。这一点在可信多智能体系统里几乎是致命的。你可以想象一个主 Agent 被植入了恶意缓存下游所有 Agent 都会基于这个被污染的“记忆”行动而整个链条里没有任何一环能看到文本形式的可疑 payload。如果系统设计时没有给缓存交接加隔离层这种风险就是结构性的不是靠加一两个过滤器能补上的。5.3 工程出路上下文最小化与信任域隔离目前可行的缓解措施本质上都是“少传一点、传得谨慎一点”。一是上下文最小化交接前强制裁剪只保留与任务直接相关的结论和证据不传全量历史。二是信任域隔离C2C 只在同一个受信任的 agent 集群内部使用跨信任域比如接外部模型或第三方 Agent时强制降级为文本消息。三是在隐私敏感场景下对将要交接的 Cache 做扰动给部分 K/V 注入受控噪声让窃取方只能拿到近似信息代价是下游推理精度会略降。从成本收益看上下文最小化是最优先做的因为它同时缓解了死结一里的“上下文污染”和这个死结里的“隐私泄露”。只传必要的结论和证据C2C 的收益虽然会打点折但系统整体风险能降一大截。6. 第四个死结缓存一致性与生命周期——快照终究会变成旧闻6.1 Cache 是一张会过期的快照多智能体系统不是静态的。Agent A 可能在给你导出 Cache 之后又收到新的工具返回、新的用户指令或者自己在后台更新了上下文记忆。你手里那份 Cache严格来说只是 A 在 T 时刻的一次快照。等 B 真正用到它时A 可能已经走远了。这跟分布式系统里的缓存一致性问题是同构的数据源变了副本却不自知。在文本消息时代这个问题相对温和——A 发给 B 的是一份已经定稿的文本文本自带时间戳而在 C2C 时代B 继承的是“活的内部状态”它没有年龄概念B 也不知道这份记忆是否过期。于是 B 可能基于一份陈旧快照给出理直气壮但完全不符合现状的答案。6.2 级联失效是最难处理的部分我在实际推演多智能体 C2C 架构时发现最痛苦的不是单跳传递而是级联失效A 的缓存给 BB 基于它产出计划再传给 CC 又传给 D……只要 A 的上下文在某个时刻更新了一处旧快照就会沿着下游依赖链四处扩散。你需要一本“账”记录每个 agent 当前持有的缓存版本、依赖关系、失效通知。否则整个系统会出现大量“明明每个环节都正确但最终答案却过时”的诡异错误而且这类错误极难定位因为每一步的输出在本地看都是自洽的。我自己在推演时经常把这类问题画成依赖树但真正落地的复杂度远超理论模型。比如 A 更新了一处结论B 引用了旧结论并且基于它做了代码修改C 又根据 B 的代码写了测试——这个时候要回滚的不只是缓存还有所有下游已经产生的“新上下文”。所以我一贯的建议是不要让 C2C 缓存跨越太多跳数。6.3 工程出路只追加、版本化、按需失效我比较看好的做法是三条。第一把协作缓存设计成“不可变追加”的形式。每个 agent 产生的结论就是一个带版本号的提交记录类似 Git 的 commit。下游 Agent 引用的永远是某个明确的提交而不是一个会变的全局状态。第二给每次 Cache 导出打上版本号和依赖链信息。一旦上游有更新就沿依赖链广播失效通知下游可以决定是重新拉取还是继续用旧快照并明确标注“基于过期上下文”。第三不是所有协作都值得做 C2C——如果某个环节的上下文高频变化、且要跨多跳传递不如退回到文本消息加清晰的引用编号避免级联失效带来的复杂度爆炸。7. 第五个死结异构模型兼容——把大象塞进冰箱冰箱得够大7.1 结构不匹配KV-Cache 的形状就是硬约束KV-Cache 的形状由模型结构直接决定层数、注意力头数、每组头数GQA/MQA、隐藏维度、精度类型任何一个不同缓存都没法原样搬运。最朴素的情况A 是 8B 模型B 是 70B 模型层数差好几倍KV-Cache 的 shape 完全对不上数学上根本不存在“直接传给 B”的可能。哪怕层数相同如果头数不同比如 A 是 GQA 分组 4B 是分组 8K/V 的维度组织也不一致。所以真实的 C2C 项目里大家几乎都会做一个看起来很“不酷”的决定所有参与协作的 agent 统一使用同一个基座模型。想要角色差异就通过不同的 LoRA 适配器或者不同的系统提示来实现。这等于为了缓存可迁移放弃了模型多样性但这是绕不开的硬约束。7.2 位置编码一个容易翻车的小细节就算你实现了“同基座模型”还有一个细节专门等着你踩位置编码。现在主流模型大多用 RoPE旋转位置编码位置信息是叠加在 Q 和 K 向量上的。如果两个模型用了不同的 RoPE 配置——旋转维度不同、频率基数不同、甚至只是 tokenizer 不同导致同一句话的 token 切分不同——那么同一位置的 K 向量代表的语义位置就完全对不上。传过去的 Cache 看似 shape 正确实际位置语义已经错乱下游推理结果直接乱套。这个细节很坑因为它不会在报错信息里出现。shape 全部匹配forward 也能跑就是效果崩了。我见过不止一个团队花了很久排查最后发现是两个 agent 微调时用了不同版本的 tokenizer 文件导致同一段公共前缀被切分成不同的 token 序列所有后续 Cache 全部作废。这类问题在文本消息时代根本不存在是 C2C 独有的心智负担。7.3 工程出路统一规范 低秩适配想在工程上落地至少要做到统一基座模型版本、统一 tokenizer、统一 RoPE 配置、统一公共前缀模板并把每一次模型升级都当成一次“缓存协议变更”来对待。角色的差异化尽量用 LoRA 适配器承载。这里的原则是主体结构必须完全一致个性差异全部留在可以“剥离/挂载”的旁路里。这样做虽然牺牲了混编不同厂商模型的自由但换来的是 C2C 可以成立。如果你预期的系统里必须混用多个不同架构的模型那基本可以提前给 C2C 判死刑了。8. 串起来看实践建议与我的判断8.1 什么样的场景才值得上 C2C把五个死结串起来看C2C 并不是所有多智能体场景的银弹。我判断一个项目适不适合上 C2C一般会看四条是不是长上下文高频协作文本传递的账单足够大是不是同一信任域Agent 之间可以互相信任、共享密钥模型是否统一可控能接受只用同一个基座任务链路是否短且清晰不太需要跨多跳级联失效管理。四条都满足C2C 才值得认真做否则建议先用文本消息加普通上下文缓存把系统跑稳再考虑逐步引入。8.2 一个务实的渐进路线如果你所在团队想试探 C2C我不建议一上来就全量传递 KV-Cache。可以先做“混合模式”主体仍然是文本协作但对最昂贵的那一跳比如生成长报告再让下游从头读的高频交接做缓存级优化。先加公共前缀和 Cache 切片再加签名校验再考虑版本化。每一步都只解决一个死结验证收益后再往下走这样不至于把架构复杂度一次性推到不可维护的程度。8.3 最后想说的话从纯性能数字看2.5× 的加速确实诱人。但我把五个死结拆开之后更深的感受是C2C 与其说是一种加速技巧不如说是一种沟通协议的重新设计。它逼着我们把“谁可以知道什么、谁可以信任谁、模型之间如何保持一致”这些问题前置到架构层面。以我目前的实践经验真正能从 C2C 里稳定获益的团队通常都是先在文本协作层面把协议、版本、信任模型理得很清楚的团队。性能优化的前置条件往往不是调参而是把约定做对。这个方向很有前景但我还想多说一句不管未来 C2C 的协议怎么演进“能退回到文本”始终应该作为降级方案保留。缓存交接一旦出问题排查难度远超文本消息。留下这个逃生通道你在生产环境里才敢真正压上性能。