Agent 技术栈有个心照不宣的默契：编排层和推理引擎之间只存在一种对话——请求进去，token 流出来。10 月 5 日提交 arXiv 的 HEAR 论文（编号 2610.06597）向这个默契发难：这两层各自握着对方急需的信息，却互不打招呼，而打通它们只需要一个协议。
断裂的两层视图
论文的问题陈述写得非常清楚。Agent 编排层（harness）掌握的是工作流侧的真相：多轮推理的依赖关系、上下文的生命周期、执行目标；推理引擎（engine）观察到的是运行时的真相：请求队列、KV 缓存状态、资源压力、执行能力。两边的知识恰好互补，现有接口却不做任何系统性的连接。
后果在多智能体、多轮、并发的真实负载下被放大。编排层明明知道「这五个请求属于同一条工作流、共享同一段系统提示、十分钟后整个上下文作废」，引擎只能看见五个互不相干的请求；引擎明明知道「缓存里躺着你们要的前缀、集群已经接近内存上限」，编排层只会按部就班地发下一个请求。调度决策建立在残缺信息上，于是前缀缓存反复失效、低优先级任务堵住高优先级工作流、内存爆掉时大家一起去死。
协议长什么样
HEAR 的全称是 Harness-Engine Pairing（编排层-引擎配对），核心是双向信息交换：编排层向引擎上报工作流意图与执行要求，引擎向编排层回传运行时状态、能力与结果。上行方向携带的是工作流拓扑、上下文生命周期与截止时间这类「未来才会发生」的计划信息；下行方向携带的是缓存命中分布、队列深度、可用执行模式这类「正在发生」的状态信息。两个方向的信息时效完全不同，因此协议对消息频率和新鲜度要求也分开定义，避免高频状态上报把协议本身变成新的瓶颈。
设计上最值得称道的一点是协议语义与优化策略分离。HEAR 只标准化「交换什么」，不规定「怎么用」。论文给出了两个策略实例化：一是在线缓存感知的运行时协调——引擎拿到工作流意图后，把共享前缀的请求做亲和调度，把即将失效的上下文优先处理；二是面向 Agent 角色的工作负载感知执行模式选择——检索型请求和深推理型请求拿到不同的执行策略。同一协议底下，策略可以继续演化，这正是它能成为「可复用协调基座」的关键。
数字：不同负载下的收益分层
实验横跨四个对话与研究型 Agent 基准，全部在内存受限的并发服务场景下进行。收益可以按负载形态分三层看。
多轮对话负载（SCBench）：批处理吞吐提速 1.61 倍，中位首 token 延迟降低 2.23 倍——这是缓存亲和最直接的受益场景，多轮共享前缀的请求被黏在同一个批次里调度。
缓存池架构（Mooncake）：论文验证了工作流意图与引擎实时状态在不同负载区间提供互补收益——低负载时意图主导调度，高负载时引擎状态信号接管，两层信息缺一不可。
研究型 Agent 负载：BrowseComp-Plus 提速 1.23 倍，DeepResearchBench 提速 2.45 倍，且报告未观察到任务质量下降。最后这一点很重要——很多服务层优化的阴暗面是拿任务质量换吞吐，HEAR 的加速全部来自调度与执行模式，不碰模型输出本身。
工程意义：为什么这篇论文值得转发给你的基础设施同事
今天部署 Agent 应用的事实架构是：LangGraph 或自研编排器跑在应用层，vLLM 或 SGLang 跑在服务层，中间只有 OpenAI 兼容 API 的一道窄门。所有「我们做了智能调度」的努力都只能发生在编排层——因为引擎侧的信息根本拿不到。
HEAR 的价值是把这个问题命名并格式化了。即使协议本身没有落地，它的三个观察今天就能用：给请求贴工作流元数据，让引擎有机会做亲和调度；订阅引擎指标，把队列压力反馈进编排层的重试与限流逻辑；区分请求角色，检索、草稿、终审不必挤同一条执行路径。
从更远看，这篇论文预示的是 Agent 基础设施的下一层抽象。当单请求优化被榨干后，下一个数量级的效率提升必然来自跨层协同——类似当年数据库与应用服务器之间长出的连接池与预编译语句协议。HEAR 未必是最终标准，但它把「两层应该说话」这件事论证得足够清楚，接下来的问题只是谁来先把它塞进 vLLM 的调度器扩展点。
当然，冷静看这项工作也有边界。四个基准都是对话与研究型负载，代码生成、长周期工具编排这类含外部副作用的场景没有覆盖，而后者恰恰是 Agent 生产部署的主流形态；跨层信息交换引入的新故障面——意图上报丢失、状态回传过期——论文只字未提，真实系统里这些问题会决定协议能不能活下去。把它当作方向宣言而非落地蓝图，是当前最合适的姿势。
论文代码与基准细节见 arXiv 2610.06597，四组基准的配置表在附录里可以直接抄作业。