尧图网站建设 
HEAR面向智能体大模型服务的编排器‑推理引擎双向通信协议原文网页https://arxiv.org/html/2610.06597v1PDF链接https://arxiv.org/pdf/2610.06597v1arXiv编号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缓存双向协议编排器调度优化多智能体服务系统目录引言相关工作HEAR协议设计3.1 适用范围与执行模型3.2 四大消息语义类别3.3 交互语义区分规则3.4 策略集成范式实验4.1 实验环境4.2 感知缓存的运行时协同策略4.3 能力感知执行模式选择策略4.4 实验总结结论参考文献附录简要说明1 引言大模型智能体依靠多轮规划、工具调用、多智能体协作完成复杂任务。智能体编排器负责工作流编排、上下文维护、工具交互vLLM、SGLang等推理引擎负责模型执行、请求批处理、KV缓存管理。端到端效率不只取决于单次模型调用加速更需要跨工作流对请求与可复用KV状态做协同调度。协同优化存在根本障碍决策所需信息分散在两个系统层。编排器掌握请求依赖、上下文生命周期、应用目标看不到引擎侧缓存驻留、请求队列、资源压力。推理引擎观测缓存、队列、硬件负载不理解上层智能体工作流依赖、未来上下文复用意图。信息割裂会造成典型问题引擎在KV缓存即将被再次使用时将其驱逐触发代价高昂的重新预填充编排器不知道哪些上下文已经驻留在缓存可能优先调度冷请求而缓存就绪的请求反而延后执行。执行模式选择同样存在矛盾需要结合编排器看到的负载特征以及引擎侧的效率‑质量权衡。因此需要一套双向接口实现两层信息交换、联合决策。现有相关工作已经验证工作流信息、运行时反馈对智能体服务的价值但缺少通用的控制平面抽象。各类优化方案各自定义跨层信号、控制语义、生命周期策略与特定编排器、推理引擎强耦合可移植性差难以组合复用。本文提出HEAR双向协议将每条交互消息关联到对应请求、上下文版本、服务实例消息划分为四大语义类别。编排器输出执行描述与意图、执行约束与控制引擎回传状态与能力、执行结果。定义消息作用力与操作生命周期区分描述与指令、偏好与硬性要求、观测与保证、接收确认与执行完成。协议只定义交互语义不绑定具体优化策略策略决定交换什么信息、采取什么动作协议定义消息如何被解析处理。HEAR协调现有工作流的请求调度不修改任务选择逻辑不改动模型本身语义。本文实现两套不同时间尺度下的协同策略感知缓存的运行时协同编排器传递等待约束、未来复用意图引擎回传KV驻留状态与队列信息联合调度请求优先级、控制缓存保留策略。角色专属推理配置粗粒度策略把智能体角色、输入输出、并发特征映射到引擎支持的推理模式。本文主要贡献提出HEAR编排器‑引擎双向协议将跨层交互绑定请求与上下文划分四大语义类别定义消息作用力与操作生命周期。实例化两套执行协同策略在线缓存感知运行协同、角色感知推理模式配置同一套交互契约同时支持运行时调度、缓存决策与粗粒度执行模式选择。在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 四大消息语义类别类别消息方向代表内容执行描述与意图Execution Description and Intent编排器 → 引擎智能体角色、阶段工作流依赖、就绪状态请求规模、输出上限上下文生命周期已知未来复用预测执行约束与控制Execution Requirements and Control编排器 → 引擎调度偏好、等待时间硬约束缓存准备/保留/释放请求允许的执行配置、服务目标状态与能力State and Capabilities引擎 → 编排器可复用前缀、缓存驻留层级可分配容量、队列状态、资源压力支持的控制与配置预估执行开销执行结果Execution Outcomes引擎 → 编排器推理/控制请求状态接收、完成、拒绝、不支持、失败实际生效配置、缓存复用情况延迟、资源占用、重试、错误信息说明类别代表语义用途不是网络数据包格式单条消息可以包含多个类别内容实现可只实现自身需要的字段能力报告让编排器动态发现支持能力而不是假设引擎实现全部控制接口。3.3 交互语义区分规则协议定义四组关键语义区分避免策略把描述当成命令、观测当成资源预留、接收确认等价于执行完成。区分维度协议释义意图 vs 控制描述与预测仅提供决策上下文只有显式控制请求才要求接收方执行动作。例如告知“该上下文会被复用”不等于要求引擎保留KV缓存。偏好 vs 硬性要求偏好是尽力而为的提示硬性要求约束合法执行。优先级提示可以重排就绪请求但不能覆盖强制等待保护条件不满足硬性要求必须拒绝或者走显式降级逻辑。观测 vs 保证状态、能力报告只描述当前运行条件、支持的操作不会预留资源不保证未来请求一定可以被准入。GPU缓存驻留反馈用于调度参考不等于对前缀做资源预留。接收确认 vs 执行完成接收确认代表操作进入处理队列完成确认代表目标效果真正达成。例如缓存准备请求被接收不代表KV已经就绪结果必须区分接收、完成、拒绝、不支持、执行失败。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消息语义不需要改写核心算法。本文实现两套典型策略在线缓存感知协同动态变化缓存、队列状态控制请求排序与KV保留在SCBench、Mooncake评测。能力感知配置选择相对静态负载描述结合引擎能力画像选择角色专属推理模式在BrowseComp‑Plus、DeepResearchBench评测。4 实验4.1 实验环境硬件与模型SCBench、MooncakeQwen3‑8BSCBench使用RTX PRO 6000 96GiBMooncake使用H100‑80G。BrowseComp‑Plus / DeepResearchBenchGLM‑4.7‑Flash主智能体、Reader子智能体分开H100。基线FCFS引擎原生先来先服务调度Cache‑Aware缓存感知调度Cache‑AwareGuard‑W增加等待保护阈值WSession‑Aware会话感知KV缓存保留策略。推理模式候选集合{vLLM,OmniKV}×{vLLM,H₂O,SnapKV}。评测基准SCBenchKV缓存相关长上下文对话基准Mooncake线上生产真实流量回放追踪BrowseComp‑Plus深度搜索智能体评测DeepResearchBench研究型智能体基准。控制变量全部实验模型、prompt、工作流、工具预算、硬件完全一致策略参数在正式评测前冻结每个实验组服务状态独立初始化统计包含全部失败与重试。完整实现、参数见附录A、B。4.2 感知缓存的运行时协同策略SCBench实验结果配置TTFT‑P50(s)TTFT‑P95(s)TTFT‑MAX(s)批处理总耗时(s)KV缓存复用率(%)FCFS63.174.279.048119.2Cache‑Aware4.675.893.922487.6Cache‑Aware Guard‑4028.351.165.029966.1Cache‑Aware Guard‑604.564.080.423084.7Cache‑AwareGuard‑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‑AwareGuard组合最优会话延迟最低、吞吐最高。100%高负载Cache‑Aware调度策略在P50延迟、吞吐表现更优Session‑Aware改善尾延迟与缓存复用。HEAR协议本身不随负载改变只需要上层策略根据引擎回传状态动态切换调度逻辑。4.3 能力感知执行模式选择策略BrowseComp‑Plus208条样本、DeepResearchBench100条样本固定主智能体、Reader子智能体推理模式组合。主引擎Reader引擎BrowseComp‑PlusDeepResearchBench总耗时(h)P95端到端(min)准确率(%)总耗时(h)P95端到端(min)RACE指标(%)vLLMvLLM5.6940.046.155.9339.840.6OmniKVvLLM5.3740.347.126.1739.941.1vLLMH₂O4.6239.646.632.7615.640.5OmniKVH₂O4.9837.243.272.4215.841.1vLLMSnapKV4.8340.444.232.8517.740.0OmniKVSnapKV5.2940.643.752.7618.340.5BrowseComp‑Plus最优配置vLLMH₂O1.23倍端到端加速任务准确率基本无损。DeepResearchBench最优配置OmniKVH₂O2.45倍端到端加速RACE指标无退化。归因Reader/子智能体侧切换H₂O带来最大性能收益主智能体最优模式取决于工作流输出token长度。如果全局强制同一套配置会造成其中一个基准性能退化7.8%‑14.0%证明需要基于工作流负载做角色专属选择。4.4 实验总结缓存感知调度HEAR双向交互编排器传入意图约束引擎回传缓存、队列状态SCBench实现1.61倍批加速中位TTFT降低2.23倍Mooncake证明负载变化时策略可以利用同一套协议适配。角色感知推理配置利用工作流角色描述结合引擎能力画像为不同智能体角色选择推理模式两套研究智能体基准分别实现1.23×、2.45×加速任务质量不下降。HEAR协议作为底层交互契约上层策略可以灵活替换协议本身不需要改动。5 结论本文提出HEAR编排器‑推理引擎双向配对协议打通上层智能体工作流意图与推理引擎运行时状态、硬件能力、执行结果协议将交互语义与优化策略解耦不改动工作流逻辑与模型语义。基于HEAR实现两套策略缓存感知运行时协同、角色专属推理模式配置。评测表明SCBench批处理加速1.61倍中位TTFT降低2.23倍BrowseComp‑Plus、DeepResearchBench分别取得1.23倍、2.45倍端到端加速任务质量没有退化。HEAR提供一套策略无关的可复用协同底层实际收益取决于服务栈向外暴露的信息与控制能力。伦理与可复现说明本研究不涉及人类受试者不采集个人敏感数据协议交换运行时元数据部署时应当做好访问控制、租户隔离本方法只提升推理效率不解决底层模型输出安全可靠性。实验全部配置、选择器实现、回放脚本见附录代码开源至匿名仓库。6 参考文献完整参考文献查阅原始arXiv网页https://arxiv.org/html/2610.06597v1附录简要说明附录A协议与选择器完整实现、校准脚本、角色映射冻结流程。附录B基准回放方案、全部超参数、完整细分实验数据表、负载消融。 HEAR：面向智能体大模型服务的编排器‑推理引擎双向通信协议
HEAR面向智能体大模型服务的编排器‑推理引擎双向通信协议原文网页https://arxiv.org/html/2610.06597v1PDF链接https://arxiv.org/pdf/2610.06597v1arXiv编号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缓存双向协议编排器调度优化多智能体服务系统目录引言相关工作HEAR协议设计3.1 适用范围与执行模型3.2 四大消息语义类别3.3 交互语义区分规则3.4 策略集成范式实验4.1 实验环境4.2 感知缓存的运行时协同策略4.3 能力感知执行模式选择策略4.4 实验总结结论参考文献附录简要说明1 引言大模型智能体依靠多轮规划、工具调用、多智能体协作完成复杂任务。智能体编排器负责工作流编排、上下文维护、工具交互vLLM、SGLang等推理引擎负责模型执行、请求批处理、KV缓存管理。端到端效率不只取决于单次模型调用加速更需要跨工作流对请求与可复用KV状态做协同调度。协同优化存在根本障碍决策所需信息分散在两个系统层。编排器掌握请求依赖、上下文生命周期、应用目标看不到引擎侧缓存驻留、请求队列、资源压力。推理引擎观测缓存、队列、硬件负载不理解上层智能体工作流依赖、未来上下文复用意图。信息割裂会造成典型问题引擎在KV缓存即将被再次使用时将其驱逐触发代价高昂的重新预填充编排器不知道哪些上下文已经驻留在缓存可能优先调度冷请求而缓存就绪的请求反而延后执行。执行模式选择同样存在矛盾需要结合编排器看到的负载特征以及引擎侧的效率‑质量权衡。因此需要一套双向接口实现两层信息交换、联合决策。现有相关工作已经验证工作流信息、运行时反馈对智能体服务的价值但缺少通用的控制平面抽象。各类优化方案各自定义跨层信号、控制语义、生命周期策略与特定编排器、推理引擎强耦合可移植性差难以组合复用。本文提出HEAR双向协议将每条交互消息关联到对应请求、上下文版本、服务实例消息划分为四大语义类别。编排器输出执行描述与意图、执行约束与控制引擎回传状态与能力、执行结果。定义消息作用力与操作生命周期区分描述与指令、偏好与硬性要求、观测与保证、接收确认与执行完成。协议只定义交互语义不绑定具体优化策略策略决定交换什么信息、采取什么动作协议定义消息如何被解析处理。HEAR协调现有工作流的请求调度不修改任务选择逻辑不改动模型本身语义。本文实现两套不同时间尺度下的协同策略感知缓存的运行时协同编排器传递等待约束、未来复用意图引擎回传KV驻留状态与队列信息联合调度请求优先级、控制缓存保留策略。角色专属推理配置粗粒度策略把智能体角色、输入输出、并发特征映射到引擎支持的推理模式。本文主要贡献提出HEAR编排器‑引擎双向协议将跨层交互绑定请求与上下文划分四大语义类别定义消息作用力与操作生命周期。实例化两套执行协同策略在线缓存感知运行协同、角色感知推理模式配置同一套交互契约同时支持运行时调度、缓存决策与粗粒度执行模式选择。在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 四大消息语义类别类别消息方向代表内容执行描述与意图Execution Description and Intent编排器 → 引擎智能体角色、阶段工作流依赖、就绪状态请求规模、输出上限上下文生命周期已知未来复用预测执行约束与控制Execution Requirements and Control编排器 → 引擎调度偏好、等待时间硬约束缓存准备/保留/释放请求允许的执行配置、服务目标状态与能力State and Capabilities引擎 → 编排器可复用前缀、缓存驻留层级可分配容量、队列状态、资源压力支持的控制与配置预估执行开销执行结果Execution Outcomes引擎 → 编排器推理/控制请求状态接收、完成、拒绝、不支持、失败实际生效配置、缓存复用情况延迟、资源占用、重试、错误信息说明类别代表语义用途不是网络数据包格式单条消息可以包含多个类别内容实现可只实现自身需要的字段能力报告让编排器动态发现支持能力而不是假设引擎实现全部控制接口。3.3 交互语义区分规则协议定义四组关键语义区分避免策略把描述当成命令、观测当成资源预留、接收确认等价于执行完成。区分维度协议释义意图 vs 控制描述与预测仅提供决策上下文只有显式控制请求才要求接收方执行动作。例如告知“该上下文会被复用”不等于要求引擎保留KV缓存。偏好 vs 硬性要求偏好是尽力而为的提示硬性要求约束合法执行。优先级提示可以重排就绪请求但不能覆盖强制等待保护条件不满足硬性要求必须拒绝或者走显式降级逻辑。观测 vs 保证状态、能力报告只描述当前运行条件、支持的操作不会预留资源不保证未来请求一定可以被准入。GPU缓存驻留反馈用于调度参考不等于对前缀做资源预留。接收确认 vs 执行完成接收确认代表操作进入处理队列完成确认代表目标效果真正达成。例如缓存准备请求被接收不代表KV已经就绪结果必须区分接收、完成、拒绝、不支持、执行失败。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消息语义不需要改写核心算法。本文实现两套典型策略在线缓存感知协同动态变化缓存、队列状态控制请求排序与KV保留在SCBench、Mooncake评测。能力感知配置选择相对静态负载描述结合引擎能力画像选择角色专属推理模式在BrowseComp‑Plus、DeepResearchBench评测。4 实验4.1 实验环境硬件与模型SCBench、MooncakeQwen3‑8BSCBench使用RTX PRO 6000 96GiBMooncake使用H100‑80G。BrowseComp‑Plus / DeepResearchBenchGLM‑4.7‑Flash主智能体、Reader子智能体分开H100。基线FCFS引擎原生先来先服务调度Cache‑Aware缓存感知调度Cache‑AwareGuard‑W增加等待保护阈值WSession‑Aware会话感知KV缓存保留策略。推理模式候选集合{vLLM,OmniKV}×{vLLM,H₂O,SnapKV}。评测基准SCBenchKV缓存相关长上下文对话基准Mooncake线上生产真实流量回放追踪BrowseComp‑Plus深度搜索智能体评测DeepResearchBench研究型智能体基准。控制变量全部实验模型、prompt、工作流、工具预算、硬件完全一致策略参数在正式评测前冻结每个实验组服务状态独立初始化统计包含全部失败与重试。完整实现、参数见附录A、B。4.2 感知缓存的运行时协同策略SCBench实验结果配置TTFT‑P50(s)TTFT‑P95(s)TTFT‑MAX(s)批处理总耗时(s)KV缓存复用率(%)FCFS63.174.279.048119.2Cache‑Aware4.675.893.922487.6Cache‑Aware Guard‑4028.351.165.029966.1Cache‑Aware Guard‑604.564.080.423084.7Cache‑AwareGuard‑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‑AwareGuard组合最优会话延迟最低、吞吐最高。100%高负载Cache‑Aware调度策略在P50延迟、吞吐表现更优Session‑Aware改善尾延迟与缓存复用。HEAR协议本身不随负载改变只需要上层策略根据引擎回传状态动态切换调度逻辑。4.3 能力感知执行模式选择策略BrowseComp‑Plus208条样本、DeepResearchBench100条样本固定主智能体、Reader子智能体推理模式组合。主引擎Reader引擎BrowseComp‑PlusDeepResearchBench总耗时(h)P95端到端(min)准确率(%)总耗时(h)P95端到端(min)RACE指标(%)vLLMvLLM5.6940.046.155.9339.840.6OmniKVvLLM5.3740.347.126.1739.941.1vLLMH₂O4.6239.646.632.7615.640.5OmniKVH₂O4.9837.243.272.4215.841.1vLLMSnapKV4.8340.444.232.8517.740.0OmniKVSnapKV5.2940.643.752.7618.340.5BrowseComp‑Plus最优配置vLLMH₂O1.23倍端到端加速任务准确率基本无损。DeepResearchBench最优配置OmniKVH₂O2.45倍端到端加速RACE指标无退化。归因Reader/子智能体侧切换H₂O带来最大性能收益主智能体最优模式取决于工作流输出token长度。如果全局强制同一套配置会造成其中一个基准性能退化7.8%‑14.0%证明需要基于工作流负载做角色专属选择。4.4 实验总结缓存感知调度HEAR双向交互编排器传入意图约束引擎回传缓存、队列状态SCBench实现1.61倍批加速中位TTFT降低2.23倍Mooncake证明负载变化时策略可以利用同一套协议适配。角色感知推理配置利用工作流角色描述结合引擎能力画像为不同智能体角色选择推理模式两套研究智能体基准分别实现1.23×、2.45×加速任务质量不下降。HEAR协议作为底层交互契约上层策略可以灵活替换协议本身不需要改动。5 结论本文提出HEAR编排器‑推理引擎双向配对协议打通上层智能体工作流意图与推理引擎运行时状态、硬件能力、执行结果协议将交互语义与优化策略解耦不改动工作流逻辑与模型语义。基于HEAR实现两套策略缓存感知运行时协同、角色专属推理模式配置。评测表明SCBench批处理加速1.61倍中位TTFT降低2.23倍BrowseComp‑Plus、DeepResearchBench分别取得1.23倍、2.45倍端到端加速任务质量没有退化。HEAR提供一套策略无关的可复用协同底层实际收益取决于服务栈向外暴露的信息与控制能力。伦理与可复现说明本研究不涉及人类受试者不采集个人敏感数据协议交换运行时元数据部署时应当做好访问控制、租户隔离本方法只提升推理效率不解决底层模型输出安全可靠性。实验全部配置、选择器实现、回放脚本见附录代码开源至匿名仓库。6 参考文献完整参考文献查阅原始arXiv网页https://arxiv.org/html/2610.06597v1附录简要说明附录A协议与选择器完整实现、校准脚本、角色映射冻结流程。附录B基准回放方案、全部超参数、完整细分实验数据表、负载消融。