两层各掌握互补的信息
智能体服务横跨两层，而两层看到的东西并不相同。智能体 harness 了解请求依赖、上下文生命周期和应用目标；推理引擎则观察请求队列、KV 缓存驻留情况、资源压力和受支持的执行模式。论文给出的动机示例很具体：不知道未来上下文用途的引擎，可能在 KV 状态即将被复用前将其驱逐，迫使系统付出高昂的重新预填充代价；而不了解缓存驻留情况的 harness，可能在存在等价缓存驻留请求时先调度冷请求，即便两者都已就绪且可以合法重排。
论文认为这不只是缺少一项优化，而是缺少一层抽象。已有工作展示了工作流信息与运行时反馈的价值，但每项工作都定义自己的跨层信号、控制语义和操作生命周期，把策略与特定 harness 和引擎紧密绑定。HEAR 被提出作为连接工作流语义与运行时执行状态的共享控制平面抽象。
HEAR 规范消息而非策略
HEAR 把通信组织为四个语义类别。harness 提供执行描述与意图，以及执行要求与控制；引擎返回状态与能力，以及执行结果。每次交换都与相关请求、上下文版本或服务实例关联。协议还区分描述与指令、偏好与要求、观察与保证、接受与完成。
关键设计选择是把协议语义与优化策略分离。HEAR 定义交换的含义，协调策略则决定交换哪些信息、采取哪些行动。正是这种分离让多种协调策略无需改变工作流或模型语义即可使用，也让 PBKV、Pythia 等已有策略保留各自的预测器和优化规则，只需通过适配器把所需的工作流描述、引擎观察和控制经由 HEAR 暴露出来。
缓存感知调度在复用与尾延迟间权衡
第一个实例是在线缓存感知运行时协调。在每个决策点，harness 描述就绪请求、它们的上下文以及适用的执行要求（包括等待保护）；引擎返回最新的相关缓存可用性和队列状态。随后调度策略为就绪请求分配优先级。论文比较了三种执行顺序策略：FCFS 使用引擎默认调度器；Cache-Aware 把引擎报告的 KV 驻留情况转换为 harness 侧调度偏好；Cache-Aware+Guard-W 还额外防止请求等待 W 秒后被绕过或抢占。
在 SCBench 上，由于前缀重算，FCFS 对后续提示 token 的 KV 缓存复用率仅为 19.2%。Cache-Aware 把复用率提高到 87.6%，把首 token 中位延迟从 63.1 秒降到 4.6 秒，并把批量完成时间从 481 秒缩短到 224 秒。但反复推迟冷请求会抬高最大首 token 延迟。等待保护约束了这种行为：Cache-Aware+Guard-40 在 P50、P95 和最大首 token 延迟上都优于 FCFS，同时保留 1.61 倍批量加速。把阈值提高到 60 秒有利于复用和批量完成，却削弱了尾延迟保护。这里同时用到了 HEAR 的两个方向：引擎反馈识别复用机会，harness 要求则约束调度器利用这些机会的激进程度。
没有单一策略在所有负载下胜出
Mooncake Bench 显示，在 HEAR 接口保持不变的情况下，首选策略会随负载变化。在 50% 负载下，排队有限，空闲期驱逐成为复用损失的主要来源，因此 Session-Aware 优于执行顺序控制，把复用率从 19.5% 提高到 31.9%。在 75% 负载下，驱逐控制与执行顺序控制变得互补：把 Session-Aware 与 Cache-Aware+Guard 结合，得到最短会话时间、最高吞吐和最高复用。在 100% 负载下，Cache-Aware 在 P50、会话延迟和吞吐上更好，而 Session-Aware 改善尾延迟和复用。
这是论文最清晰的证据，说明工作流意图与引擎实时状态在不同负载区间提供互补收益，而非某一方占主导。Session-Aware 本身是一种 KV 保留策略：每次请求之后，harness 根据会话深度和此前的轮次间隔估计会话延续概率，并明确把该估计标记为描述性意图而非保留要求，引擎再把它与访问新近度结合。该估计只从已完成的对话更新，不使用当前回放中的未来信息。
按角色选择执行模式优于固定映射
第二个实例是面向智能体角色的负载感知执行模式选择。这里 harness 传达工作负载描述和目标，引擎提供稳定的能力画像，策略据此为每个角色选择推理模式。在 BrowseComp-Plus 和 DeepResearchBench 上，针对工作负载的配置分别带来 1.23 倍和 2.45 倍端到端加速，且未观察到任务质量下降。
角色层面的归因显示了收益来源。Reader/子智能体执行带来最大且最稳定的收益：选择 H2O 使 BrowseComp-Plus 上平均延迟降低 5.60 倍，DeepResearchBench 上降低 7.22 倍。在 BrowseComp-Plus 上，这伴随预填充 token 减少 76.2%，缓存复用率从 6.2% 提高到 80.3%；在 DeepResearchBench 上，则伴随 49.8% 的链式复用。Main 侧的首选模式取决于工作负载：BrowseComp-Plus 的 Main 请求大约生成 0.4K 输出 token，vLLM 比 OmniKV 快 1.14 倍；而 DeepResearchBench 的 Main 请求在轮次同步工作流中大约生成 4.4K token，OmniKV 比 vLLM 快 1.08 倍，因为更长的解码负载更好地摊薄了模式特有的开销。
通用映射的代价是 7.8% 到 14.0%
两种被选中的映射都不是两个工作负载上的最优解，论文量化了忽视这一点的代价。若普遍采用 OmniKV-H2O，BrowseComp-Plus 的墙钟时间会增加 7.8%；若普遍采用 vLLM-H2O，DeepResearchBench 的完工时间会增加 14.0%。因此选择必须考虑 harness 描述中传达的执行目标，而不只是总体效率。
论文还报告，总体效率与 P95 延迟偶尔会偏好不同的映射，这进一步印证了同一点：正确配置取决于工作流声明的是哪个目标。在 DeepResearchBench 上，49.8% 的链式复用把完工时间从 5.93 小时降到 2.42 小时，即 2.45 倍加速，同时 RACE 保持在 41.1% 对 40.6%。
HEAR 增加控制平面开销而非模型计算
HEAR 增加的是控制平面元数据处理，而非模型侧计算。它不引入额外的模型层或逐 token 的 GPU 算子。其在线工作包括状态更新、对象查找、策略输入构造、控制处理和执行结果上报。OmniKV、H2O 或 SnapKV 引入的计算属于相应的执行模式，而不属于协议本身。
成本核算很明确。对于缓存感知协调，引擎的 KV 事件更新 harness 维护的驻留目录；在每个调度点，harness 查询可复用前缀块、构造调度偏好并附加适用的等待要求；引擎应用这些控制并报告实际执行顺序、缓存复用、重试和错误。对于能力感知配置，候选画像、过滤、排序和验证都在开发阶段离线完成，在线路径只在工作流初始化时加载一次冻结的角色到模式映射，并在每次分发模型请求时执行一次常量规模查找。所有正式的 HEAR 启用运行都包含相应的在线控制平面路径，因此报告的端到端结果反映的是这些操作之后的净性能。
证据的适用边界
结果来自内存受限、并发服务下的四个对话与科研智能体基准，并对应特定硬件和模型：SCBench 使用 Qwen3-8B，运行在一块 RTX PRO 6000 上，配 96-GiB L2 KV 缓存；Mooncake Bench 使用 Qwen3-8B，运行在一块 H100 上，配 96-GiB L2 KV 缓存；角色特定实验使用 GLM-4.7-Flash，Main 侧与 Reader/子智能体侧推理分别放在不同的 H100 GPU 上。SCBench 缺少真实请求时间戳，因此作者构造了闭环多轮工作负载，用泊松过程模拟会话到达并采样轮次间思考时间；Mooncake 则回放生产 trace 中 50%、75% 和 100% 的会话。
有两条边界对解读很重要。第一，harness 维护的驻留视图反映的是当前观察到的缓存状态，并不构成驻留保证；当请求真正执行时，引擎会针对当前缓存状态重新检查可复用内容。第二，论文指出其方法提升推理效率，但不解决底层模型输出的安全性或可靠性问题，并且实际部署在交换执行与资源元数据时应实施访问控制、租户隔离和有界等待。报告的加速是在这些基准和配置上测得的，并未外推到其他服务栈。
让策略匹配负载与角色
论文最具决策价值的信息是：需要随条件改变的是协调策略，而不是协议。在 SCBench 上，等待保护把缓存感知调度从尾延迟问题转变为 1.61 倍批量加速，同时改善 P50、P95 和最大首 token 延迟；40 秒阈值保护尾部，60 秒阈值则偏向复用和批量完成。在 Mooncake 上，胜出策略随负载移动：50% 时是 Session-Aware，75% 时是组合策略，100% 时 Cache-Aware 在 P50、会话延迟和吞吐上更好，而 Session-Aware 在尾延迟和复用上仍更优。
在角色配置上，论文自身的比较给出了优先级顺序。Reader/子智能体模式选择带来最大且最稳定的收益，BrowseComp-Plus 上 5.60 倍，DeepResearchBench 上 7.22 倍；而 Main 侧选择取决于输出长度：约 0.4K token 的 BrowseComp-Plus Main 请求用 vLLM，约 4.4K token 的 DeepResearchBench Main 请求用 OmniKV。最值得带走的判断阈值是忽视这一点的代价：通用映射会让 BrowseComp-Plus 墙钟时间增加 7.8%，或让 DeepResearchBench 完工时间增加 14.0%。可复用的基础是 HEAR 不变的消息类别与交互语义；收益真正来自针对工作负载的策略。
本文引用的文献
Can Agent Harnesses and Inference Engines Hear Each Other? The HEAR Protocol for Agentic LLM Serving
HEAR 是一种双向 Harness-Engine 配对协议，在 SCBench 上取得 1.61 倍批量加速、首 token 中位延迟降低 2.23 倍，在 BrowseComp-Plus 与 DeepResearchBench 上端到端加速分别为 1.23 倍和 2.45 倍，且未观察到任务质量下降。