企业官网建设流程全解析

HEAR：面向智能体大模型服务的编排器‑推理引擎双向通信协议

原文网页：https://arxiv.org/html/2610.06597v1
PDF链接：https://arxiv.org/pdf/2610.06597v1
arXiv编号：arXiv:2610.06597v1 [cs.AI]，提交日期：2026‑10‑05

摘要
大模型智能体执行复杂工作流，涉及多轮推理、工具调用、多智能体协同，端到端高效服务需要横跨两层系统做联合决策：智能体编排器（Harness）掌握工作流依赖关系、上下文生命周期、执行目标；推理引擎观测请求队列、KV‑Cache状态、资源压力、执行能力。现有接口无法系统化打通两层视图，难以实现感知工作流的调度执行。
本文提出HEAR，一套编排器‑引擎双向配对通信协议（Harness‑Engine pAiRing Protocol），标准化编排器向引擎传递工作流意图与执行约束，同时引擎回传运行时状态、硬件能力与执行结果。协议将语义定义与优化策略解耦，在不改动工作流与模型语义的前提下，支持多种多样协同策略。
本文基于HEAR实现两类协同策略：感知缓存的运行时协同、面向智能体角色的负载感知执行模式选择。在4套对话与研究型智能体基准、内存受限并发服务场景下开展实验：SCBench基准实现1.61倍批处理加速，首token中位生成时间降低2.23倍；Mooncake基准证明，工作流意图与引擎实时状态在不同负载下可以形成互补增益；在BrowseComp‑Plus、DeepResearchBench基准上，面向负载的角色专属配置分别取得1.23倍、2.45倍端到端加速，且任务质量没有发生退化。实验证明HEAR可作为可复用协同底层，实现高效智能体大模型服务。

关键词
大模型智能体；推理服务；KV缓存；双向协议；编排器；调度优化；多智能体；服务系统

目录

1. 引言
2. 相关工作
3. HEAR协议设计
   • 3.1 适用范围与执行模型
   • 3.2 四大消息语义类别
   • 3.3 交互语义区分规则
   • 3.4 策略集成范式
4. 实验
   • 4.1 实验环境
   • 4.2 感知缓存的运行时协同策略
   • 4.3 能力感知执行模式选择策略
   • 4.4 实验总结
5. 结论
6. 参考文献
7. 附录简要说明

1 引言

大模型智能体依靠多轮规划、工具调用、多智能体协作完成复杂任务。智能体编排器负责工作流编排、上下文维护、工具交互；vLLM、SGLang等推理引擎负责模型执行、请求批处理、KV缓存管理。端到端效率不只取决于单次模型调用加速，更需要跨工作流对请求与可复用KV状态做协同调度。

协同优化存在根本障碍：决策所需信息分散在两个系统层。

• 编排器：掌握请求依赖、上下文生命周期、应用目标；看不到引擎侧缓存驻留、请求队列、资源压力。
• 推理引擎：观测缓存、队列、硬件负载；不理解上层智能体工作流依赖、未来上下文复用意图。

信息割裂会造成典型问题：引擎在KV缓存即将被再次使用时将其驱逐，触发代价高昂的重新预填充；编排器不知道哪些上下文已经驻留在缓存，可能优先调度冷请求，而缓存就绪的请求反而延后执行。执行模式选择同样存在矛盾：需要结合编排器看到的负载特征，以及引擎侧的效率‑质量权衡。因此需要一套双向接口，实现两层信息交换、联合决策。

现有相关工作已经验证工作流信息、运行时反馈对智能体服务的价值，但缺少通用的控制平面抽象。各类优化方案各自定义跨层信号、控制语义、生命周期，策略与特定编排器、推理引擎强耦合，可移植性差，难以组合复用。

本文提出HEAR双向协议：

1. 将每条交互消息关联到对应请求、上下文版本、服务实例；消息划分为四大语义类别。编排器输出：执行描述与意图、执行约束与控制；引擎回传：状态与能力、执行结果。
2. 定义消息作用力与操作生命周期，区分描述与指令、偏好与硬性要求、观测与保证、接收确认与执行完成。协议只定义交互语义，不绑定具体优化策略；策略决定交换什么信息、采取什么动作，协议定义消息如何被解析处理。HEAR协调现有工作流的请求调度，不修改任务选择逻辑，不改动模型本身语义。

本文实现两套不同时间尺度下的协同策略：

1. 感知缓存的运行时协同：编排器传递等待约束、未来复用意图；引擎回传KV驻留状态与队列信息，联合调度请求优先级、控制缓存保留策略。
2. 角色专属推理配置：粗粒度策略，把智能体角色、输入输出、并发特征映射到引擎支持的推理模式。

本文主要贡献

1. 提出HEAR编排器‑引擎双向协议，将跨层交互绑定请求与上下文，划分四大语义类别，定义消息作用力与操作生命周期。
2. 实例化两套执行协同策略：在线缓存感知运行协同、角色感知推理模式配置；同一套交互契约同时支持运行时调度、缓存决策与粗粒度执行模式选择。
3. 在SCBench、Mooncake、BrowseComp‑Plus、DeepResearchBench开展受控评测；融合编排器意图与引擎状态，对话服务效率提升；研究型智能体工作流取得1.23‑2.45倍端到端加速，任务质量无退化。
   

2 相关工作

2.1 智能体编排框架

AutoGen、AgentScope、LangGraph、Deep Agents等智能体Harness，支持多智能体通信、状态流控制、模型调用、上下文管理与工具调用。这类框架决定智能体执行逻辑、请求就绪时机，但无法直接访问推理引擎内部运行状态：请求队列、批处理、KV缓存驻留、GPU资源压力。HEAR打通边界，把工作流意图传递给引擎，并将引擎状态回传给编排器。

2.2 LLM推理系统

vLLM的PagedAttention、SGLang的RadixAttention、LMCache多级预取、H₂O / SnapKV / OmniKV / KIVI各类KV缓存压缩、选择性保留方案。这些都属于引擎内部机制，没有标准化接口向上暴露给上层编排器。HEAR并不替换现有调度器与缓存管理器，而是提供双向契约，传递上下文生命周期、未来复用意图、执行约束；查询引擎能力、观测执行结果。

2.3 面向智能体服务的跨层协同

Parrot、Agentix、KVFlow、PBKV、InferCept、Continuum、CONCUR、Helium、Pythia、Pie等系统，实现了应用结构与运行反馈结合的定向优化。但是现有设计大多将跨层信号和特定策略、特定执行环境强耦合。
HEAR区别：标准化编排器‑引擎双向交互契约，不指定具体策略，不迁移应用逻辑，不新增独立运行时层。工作流描述、控制指令绑定请求与上下文；引擎回传状态、能力、执行结果；策略可以保留自身决策规则，复用统一跨层交互语义。

3 HEAR协议设计

HEAR是智能体编排器与推理引擎之间的双向执行协同协议。协议定义跨层消息含义与处理规则，具体交换什么信息、执行什么动作交由上层策略决定。

3.1 适用范围与执行模型

• 编排器Harness：管理智能体角色、依赖关系、请求就绪状态、上下文生命周期（工作流语义）。
• 推理引擎Engine：负责模型执行、请求队列、KV缓存、硬件资源。

HEAR用于协同请求准入、请求排序、缓存准备与保留、执行配置选择。只对已经由工作流选出的请求做服务调度，不会修改任务选择逻辑，不会放宽依赖约束，不改动模型语义。
工作流可以动态演进，不需要预先完整预知；每条交互消息绑定对应的请求、上下文版本、服务实例，将上层工作流需求和引擎状态结果一一关联。

示例追踪流程：4个智能体A/B/C/D随时间推进，编排器发送工作流描述与控制指令（蓝色），引擎回传运行状态、执行结果（橙色），形成调度与KV缓存管理反馈闭环。KV缓存状态分为：解码中、驻留内存、准备中、空。

3.2 四大消息语义类别

说明：类别代表语义用途，不是网络数据包格式；单条消息可以包含多个类别内容；实现可只实现自身需要的字段；能力报告让编排器动态发现支持能力，而不是假设引擎实现全部控制接口。

3.3 交互语义区分规则

协议定义四组关键语义区分，避免策略把描述当成命令、观测当成资源预留、接收确认等价于执行完成。

3.4 策略集成范式

联合信息决策形式化：
d i = π ( h i , s j ) d_{i}=\pi (h_{i},s_{j})di​=π(hi​,sj​)

• h i h_ihi​：决策时刻T i T_iTi​编排器侧工作流、请求信息
• s j s_jsj​：最新可用引擎状态更新
• π \piπ：策略函数，输出执行安排/配置决策d i d_idi​

引擎更新s j s_jsj​和编排器决策时刻可以异步，不需要严格同步。策略可以运行在编排器侧或者引擎侧；只使用编排器信息等价d i = π ( h i ) d_i=\pi(h_i)di​=π(hi​)；只使用引擎信息等价于只能看到请求本地状态。
现有PBKV、Pythia等跨层优化可以通过适配器，把原有预测、调度逻辑映射到HEAR消息语义，不需要改写核心算法。
本文实现两套典型策略：

1. 在线缓存感知协同：动态变化缓存、队列状态，控制请求排序与KV保留；在SCBench、Mooncake评测。
2. 能力感知配置选择：相对静态负载描述结合引擎能力画像，选择角色专属推理模式；在BrowseComp‑Plus、DeepResearchBench评测。

4 实验

4.1 实验环境

硬件与模型

• SCBench、Mooncake：Qwen3‑8B；SCBench使用RTX PRO 6000 96GiB；Mooncake使用H100‑80G。
• BrowseComp‑Plus / DeepResearchBench：GLM‑4.7‑Flash；主智能体、Reader子智能体分开H100。
  基线

1. FCFS：引擎原生先来先服务调度；
2. Cache‑Aware：缓存感知调度；Cache‑Aware+Guard‑W：增加等待保护阈值W；
3. Session‑Aware：会话感知KV缓存保留策略。
   推理模式候选集合：{vLLM,OmniKV}×{vLLM,H₂O,SnapKV}。
   评测基准
4. SCBench：KV缓存相关长上下文对话基准；
5. Mooncake：线上生产真实流量回放追踪；
6. BrowseComp‑Plus：深度搜索智能体评测；
7. DeepResearchBench：研究型智能体基准。

控制变量：全部实验模型、prompt、工作流、工具预算、硬件完全一致；策略参数在正式评测前冻结；每个实验组服务状态独立初始化；统计包含全部失败与重试。完整实现、参数见附录A、B。

4.2 感知缓存的运行时协同策略

SCBench实验结果

Cache‑Aware+Guard‑40对比FCFS：批处理加速1.61倍，中位TTFT降低2.23倍，P95 TTFT降低1.45倍。
无保护的Cache‑Aware可以大幅提升缓存复用、降低中位延迟，但会恶化最大尾延迟；增加等待保护约束平衡收益与尾延迟。

Mooncake不同负载下结果

50%、75%、100%会话负载下，没有单一策略全局最优。

• 低负载50%：队列压力小，Session‑Aware会话感知缓存保留收益最大，复用率由19.5%提升至31.9%。
• 75%中等负载：Session‑Aware + Cache‑Aware+Guard组合最优，会话延迟最低、吞吐最高。
• 100%高负载：Cache‑Aware调度策略在P50延迟、吞吐表现更优；Session‑Aware改善尾延迟与缓存复用。

HEAR协议本身不随负载改变；只需要上层策略根据引擎回传状态动态切换调度逻辑。

4.3 能力感知执行模式选择策略

BrowseComp‑Plus（208条样本）、DeepResearchBench（100条样本），固定主智能体、Reader子智能体推理模式组合。

• BrowseComp‑Plus最优配置vLLM+H₂O：1.23倍端到端加速，任务准确率基本无损。
• DeepResearchBench最优配置OmniKV+H₂O：2.45倍端到端加速，RACE指标无退化。

归因：Reader/子智能体侧切换H₂O带来最大性能收益；主智能体最优模式取决于工作流输出token长度。如果全局强制同一套配置，会造成其中一个基准性能退化7.8%‑14.0%；证明需要基于工作流负载做角色专属选择。

4.4 实验总结

1. 缓存感知调度：HEAR双向交互，编排器传入意图约束，引擎回传缓存、队列状态；SCBench实现1.61倍批加速，中位TTFT降低2.23倍；Mooncake证明负载变化时策略可以利用同一套协议适配。
2. 角色感知推理配置：利用工作流角色描述结合引擎能力画像，为不同智能体角色选择推理模式；两套研究智能体基准分别实现1.23×、2.45×加速，任务质量不下降。
3. HEAR协议作为底层交互契约，上层策略可以灵活替换，协议本身不需要改动。

5 结论

本文提出HEAR，编排器‑推理引擎双向配对协议，打通上层智能体工作流意图与推理引擎运行时状态、硬件能力、执行结果；协议将交互语义与优化策略解耦，不改动工作流逻辑与模型语义。
基于HEAR实现两套策略：缓存感知运行时协同、角色专属推理模式配置。评测表明：SCBench批处理加速1.61倍，中位TTFT降低2.23倍；BrowseComp‑Plus、DeepResearchBench分别取得1.23倍、2.45倍端到端加速，任务质量没有退化。
HEAR提供一套策略无关的可复用协同底层；实际收益取决于服务栈向外暴露的信息与控制能力。

伦理与可复现说明

1. 本研究不涉及人类受试者，不采集个人敏感数据；协议交换运行时元数据，部署时应当做好访问控制、租户隔离；本方法只提升推理效率，不解决底层模型输出安全可靠性。
2. 实验全部配置、选择器实现、回放脚本见附录；代码开源至匿名仓库。

6 参考文献

完整参考文献查阅原始arXiv网页：https://arxiv.org/html/2610.06597v1

附录简要说明

• 附录A：协议与选择器完整实现、校准脚本、角色映射冻结流程。
• 附录B：基准回放方案、全部超参数、完整细分实验数据表、负载消融。