基于 KV-Cache 通信的多智能体系统模块化设计:Agent Primitives 技术解析
本文解析 ICML 2026 论文《Agent Primitives》,提出将多智能体系统(MAS)解耦为 Review、Voting & Selection、Planning & Execution 三种可复用原语,通过 KV-Cache 直接拼接实现智能体间潜在层通信。相比自然语言通信的 MAS,该方法在 Qwen3-8B 上准确率提升 16.5 个百分点,Token 用量与单智能体基本持平,跨模型底座稳定性更强,但要求所有智能体共享同一模型参数与 RoPE 编码方案。
业务痛点:手搭多智能体系统为何又贵又不稳
今天大部分多智能体系统(MAS)的开发方式,本质上还是"手工作坊":针对某个任务设计几个角色,为每个角色写一套提示词,规定好谁先发言、谁做裁判、消息怎么传。换一个任务,这套架构往往要推倒重来。这带来两个直接的工程成本:架构复杂度随任务复杂度线性甚至超线性增长,团队里没有一套可复用的"标准件"。
更隐蔽的问题出在通信层。绝大多数 MAS 靠自然语言在智能体之间传递信息,这样做的好处是人类可读、便于调试,但代价是长上下文、多轮交互中的信息衰减。论文用两组压力测试量化了这一点:把一条辅助指令插入到长文本的中间位置时,用自然语言通信的方案指令遵循率从两端的 80%+ 骤降到 15.6%;在数学推理任务中逐步注入无关推理片段作为噪声,注入 25 句无关内容后,自然语言通信方案的准确率从 100% 跌到 40%。也就是说,智能体之间用自然语言传话,传得越多、传得越久,出错概率越高——这对任何依赖多轮智能体协作的生产系统都是实打实的可靠性风险。

作者:Haibo Jin, Peng Kuang, Ye Yu, Xiaopeng Yuan, Haohan Wang(伊利诺伊大学香槟分校) · 发表:ICML 2026(PMLR 306)
链接:https://arxiv.org/abs/2602.03695
核心思路:三种可复用原语 + KV-Cache 直接通信
论文的核心思路是把神经网络设计中"用残差块、注意力头这类可复用组件搭建复杂模型"的思路,平移到多智能体系统架构设计上。作者观察到,现有 MAS 架构虽然千差万别,但内部的计算模式可以归纳为少数几种反复出现的结构单元,并据此实例化了三种 Agent Primitive(智能体原语):
- Review Primitive(评审原语):一个 Solver 和一个 Critic 构成的迭代自我批评回路,Critic 只给反馈、不直接改答案。
- Voting and Selection Primitive(投票选择原语):多个 Solver 并行产生候选方案,一个 Selector 在潜在表示层面(而非文本层面)做聚合选择。
- Planning and Execution Primitive(规划执行原语):一个 Planner 生成结构化的潜在计划,一个 Executor 据此执行,不重新设计计划。
每个原语内部的智能体之间不通过自然语言传话,而是直接拼接 KV-Cache(键值缓存),把前一个智能体处理完序列后留下的键值张量,通过 RoPE 位置重编码后拼接到下一个智能体的系统提示词 KV-Cache 之后,让后者在此基础上直接续写。这样做的前提是所有参与的智能体必须共享同一套模型参数和位置编码方案。
三个原语对外都暴露和标准 LLM 智能体一样的接口,因此可以像积木一样即插即用、任意组合。为了让系统自动化,论文引入一个 Organizer(默认用 GPT-5.2 担任)根据输入查询自动选择并编排原语,背后由一个收录了 45 条已知 MAS 结构(含 Multi-Agent Debate、DyLAN、Self-Refine、AFlow、MAS-GPT 等经典方案)的 Knowledge Pool 提供检索式结构参考。

评测维度:性能、效率、稳定性、成本归一化效率与消融分析
作者设计的评测体系覆盖三个任务大类、8 个基准、5 个开源模型底座(Qwen3-4B/8B/14B,DeepSeek-R1-Distill-Qwen-32B/Llama-70B),对比维度包括:
- 性能:准确率(%),相对单智能体基线的提升幅度。
- 效率:Token 用量、单次查询平均推理耗时(秒)。
- 成本归一化效率:每 0.01 美元花费对应的准确率百分点(cost-normalized efficiency)。
- 稳定性:跨模型底座(Qwen 系 vs LLaMA 系 vs DeepSeek 蒸馏系)的方差表现。
- 消融:Organizer 选择(GPT-5.2 vs Claude-4 vs 随机)、Knowledge Pool 有无、RoPE 位置重编码有无。
选择这套维度组合的用意是:准确率提升必须叠加效率数据一起看,否则"更高分"很可能只是"更贵"的另一种说法,这正是自然语言 MAS(TextMAS)长期被诟病的地方。
验证结果:准确率、效率与稳定性的综合优势
在 Qwen3-8B 底座上,Primitives-based MAS 平均准确率达到 75.3%,相对单智能体基线(58.8%)提升 16.5 个百分点;对照组 TextMAS 的平均提升只有 7.3 个百分点,且方差明显更大。在最难的 AIME25/AIME24 上,小模型(Qwen3-4B)的提升幅度甚至达到 20-26.7 个百分点。
在统一使用 Llama-3-70B-Instruct 的设定下,作者对比了 LLM-Debate、Self-Refine、Quality-Diversity、SPP、AgentVerse、GPTSwarm、DyLAN、MAS-GPT 共 8 个代表性 MAS 基线:
| 方法 | MATH | GSM8K | HumanEval+ | GPQA |
|---|---|---|---|---|
| 单智能体 | 50.60% | 92.40% | 75.80% | 36.70% |
| MAS-GPT(此前最优) | 68.70% | 93.40% | 78.90% | 37.60% |
| Primitives-based MAS | 72.40% | 93.80% | 82.30% | 53.20% |
GPQA-Diamond(研究生水平知识问答)上的优势最为悬殊:53.2% 对比此前方法普遍在 33.6%-40.2% 区间,超出接近 13 个百分点。
效率数据:真正的差异化优势
以 Llama-3-70B-Instruct 为例,TextMAS 的输出 token 用量普遍是单智能体的 2-6 倍,而 Primitives-based MAS 的 token 用量与单智能体基本持平甚至更低(例如 GSM8K 上 934 → 1,017 token);跨全部 5 个模型底座统计,Primitives-based MAS 相对 TextMAS 的 token 用量和推理延迟均降低约 3-4 倍,相对单智能体推理仅增加 1.3-1.6 倍开销。
值得一提的是 LatentMAS(另一种同样使用 KV-Cache 通信的对照方法)在 token 效率上有时甚至优于 Agent Primitives,但代价是稳定性——在 DeepSeek-R1-Distill-Llama-70B 上,LatentMAS 相对单智能体基线平均准确率下降了 10.1%。这组对比揭示了本文方法的定位:它是"保守但稳健"的 KV-Cache 通信策略,用适度的效率让渡换取跨模型底座的稳定性。
消融实验:RoPE 重编码是硬约束
去掉 RoPE 位置重编码后,Qwen3-8B 上的 Primitives-based MAS 在 AIME25 上从 73.3% 跌到 60.0%;而在 DeepSeek-R1-Distill-Llama-70B 上跌幅更为剧烈,AIME25 从 56.7% 跌到 26.7%,HumanEval+ 从 85.3% 跌到 31.1%,降幅超过一半。这说明 KV-Cache 拼接时的位置重编码不是可选的工程细节,而是保证跨智能体潜在通信有效性的必要条件。
另外,移除 Knowledge Pool 后,Qwen3-8B 在 AIME25 上准确率下降约 10 个百分点;即便是训练/检索池中完全没有出现过的分布外任务(ARC-Challenge),Organizer 仍能带来 +2.3% 至 +2.5% 的提升,且引入检索池后再提升约 1.2 个百分点——说明这套机制具备一定的跨任务迁移能力,不完全依赖记忆库覆盖度。
相关工作对比:原语抽象与通信机制的一体化设计
在"潜在通信"这一细分方向,论文明确对比了三条并行路线:ThoughtComm(Zheng et al., 2025)用可训练的编解码器学习共享潜在空间,需要额外训练;Cache-to-Cache(Fu et al., 2025)研究跨模型的语义投影转移,试图解决 KV-Cache 无法跨模型迁移的问题;Latent-MAS(Zou et al., 2025)同样传递 KV-Cache 但采取更激进的分块压缩策略。Agent Primitives 与这三者的关键差异在于:它不是单纯优化"信息怎么传得更好",而是用 KV-Cache 通信直接实现原语内部的计算结构本身,通信机制和架构抽象是一体的。
在"自动化 MAS 构建"这条脉络上,AFlow、ADAS、MAS-GPT 等工作已经在探索用 LLM 自动生成任务专属的智能体架构,但它们生成的仍然是"智能体级别"的手工设计产物;Agent Primitives 的 Organizer 是在"原语级别"做选择和编排,粒度更粗、复用性更强,这也是论文反复强调的"关键差异"(Key Differences)所在。
适用边界与局限性
硬约束:只支持同构模型底座。KV-Cache 通信生效的前提是"输入-输出对齐假设"——参与通信的智能体必须共享相同的模型参数和位置编码方案,论文明确表示实验"仅限于使用同一 LLM 的智能体"。这意味着如果企业级系统需要混合调用不同厂商模型(比如同时接入 GPT、Claude、Qwen 智能体),本文的核心通信机制无法直接套用,需要退回自然语言通信,或等待跨模型语义迁移技术(如 Cache-to-Cache)进一步成熟。
Organizer 质量直接决定系统上限。随机选择原语组合会导致准确率下降 5-12.4 个百分点,开源 Organizer(Qwen3-32B)也明显弱于闭源模型;这意味着 Organizer 本身是一个不可忽视的成本项和潜在单点故障。
原语集合固定为三种,不覆盖去中心化协商、动态拓扑演化等更复杂的协作模式——这是一个有意为之的简化,作者聚焦的是"可复用的最小计算单元",而不是"覆盖所有 MAS 模式的通用框架"。
验证任务集中在数学、代码、问答,这类任务天然有明确的正确性判据,Voting/Review 这类原语容易发挥作用;对开放式生成、创意写作等缺乏明确对错标准的任务,原语设计的适配效果本文未做验证。
技术与商业价值
对已经在同一模型底座上运行多智能体链路的团队而言,这篇论文提供了一条同时降本、提速、还提升准确率的具体路径:3-4 倍的 token/延迟降低,加上两位数的准确率提升,这在生产环境里是少见的"双赢"而非"性能换成本"的权衡。GPQA 这类高难度知识问答上超出 13 个百分点的提升,也说明该方法对"需要深度推理"的高价值查询场景收益更为明显,值得优先在这类场景试点。
更长远的价值在于给"多智能体系统工程化"提供了一个类比坐标系:用残差块、注意力头类比原语,意味着未来的 MAS 平台设计可以像深度学习框架一样,沉淀出一套标准算子库,而不是每个任务都从零手搭。对正在做企业级智能体平台的团队来说,这个类比本身就值得纳入架构设计的参考框架。
选型与落地建议
- 同构模型底座、成本敏感、任务偏推理密集型(数学/代码/知识问答)的场景:这是 Agent Primitives 最合适的落地场景,建议直接对标论文的三种原语实现,评估从 TextMAS 迁移过来的收益。
- 多厂商、多模型混合部署的场景:KV-Cache 通信机制目前不适用,建议关注 Cache-to-Cache 一类跨模型语义迁移技术的进展,短期内仍以自然语言通信为主,但可以借鉴"Review / Voting / Planning-Execution"这三种结构抽象来精简手工设计的智能体角色数量,降低架构复杂度,即便通信层暂时无法升级为潜在表示。
- 已有大量历史 MAS 设计沉淀的团队:Knowledge Pool 的构建方法值得复用——45 条结构的检索式指导已经证明能带来 5-12 个百分点的增益,如果团队内部积累了更多历史工作流设计,扩大检索池规模是一个低成本的优化方向。
- Organizer 选型:论文的成本归一化分析显示,用相对便宜的 Llama-3-70B 做 Organizer,在 MATH 上的成本效率(258.6 分/0.01美元)反而高于用昂贵的 GPT-5.2(129.3 分/0.01美元),这提示在准确率要求不是极端严苛的场景下,Organizer 不必用最贵的模型,值得做一次针对自身任务分布的成本-性能扫描再定型。
JOTO 企业落地观察
- 企业若已在单一模型底座上部署多智能体链路,可将 Review、Voting、Planning-Execution 三种原语视为标准算子库进行封装与复用,显著降低新任务接入的架构设计成本,避免重复造轮子。
- KV-Cache 通信对模型同构性的强依赖,意味着当前阶段企业若采用多厂商模型混合架构,需在“通信效率”与“模型灵活性”之间做出取舍;短期内可保留自然语言通信层,但将原语结构抽象下沉为角色设计规范,实现架构层面的轻量标准化。
- Organizer 的性能敏感性表明,其不应被简单视为调度胶水,而应作为关键基础设施纳入可观测性与容灾体系;企业需建立 Organizer 的效果监控闭环,并考虑在闭源模型受限场景下,用检索增强+规则兜底的方式构建轻量 Organizer 替代方案。
立即咨询 JOTO
JOTO 提供覆盖企业智能体规划与搭建、AI 平台私有化部署、RAG 知识工程、AI 安全治理、FDE 驻场共创及持续运营优化的全周期 AI 落地服务,帮助企业把验证中的 AI 能力转化为安全、可控、可持续迭代的生产力。 联系 JOTO 获取 AI 落地咨询
想把这些做法用到你的业务里?
留下你的场景和痛点,我们帮你判断从哪一步开始。
联系我们


