给 Agent 一个任务它会自己规划、调用工具、读文件、反思修正一干就是几十分钟甚至数小时任务再复杂些还需要多个 Agent 分工协作。任务越长、协作的 Agent 越多推理过程中产生的 KV Cache 就越庞大推理时延越久。问题在于传统推理引擎只看得到请求和缓存却看不懂 Agent 正在做什么子任务已经结束缓存可能还停留在显存里会话暂时挂起缓存却继续占着最贵的位置会话即将恢复引擎又要等请求到来才开始加载。这背后的核心断层是Agent 掌握任务状态引擎掌握算力资源两者之间缺一条传递语义的通道。近期我们了解到由华为2012实验室、华为云、计算、终端等团队联合打造的openJiuwen 开源智能体平台构建了智能体算力亲和能力——一套打通 Agent 框架、推理引擎与底层算力的全链路协同机制让 Agent 的任务状态转化为算力可理解、可执行的调度信号使 KV Cache 从被动管理走向主动协同。实测表明这套机制能够让首Token时延减半推理存储占用峰值下降25%。一、推理引擎的困境看得见缓存看不懂任务模型推理过程中会把已经算过的中间结果Key/Value缓存下来即 KV Cache生成每个新 token 时就不必把全部历史上下文重算一遍。代价是上下文越长、并发会话越多KV Cache 占用的显存就越多——而显存恰恰是 GPU、NPU 这类 AI 加速芯片上最贵的地方。当前推理引擎主要依赖 LRU 等通用策略管理 KV Cache但 Agent 执行过程中的上下文状态变化远比一问一答复杂——一个任务里推理、工具调用、等待、恢复反复切换上下文会增长、压缩甚至回退到历史检查点多个子 Agent 各有独立上下文又共享系统提示词、工具定义这些公共前缀会话暂时不用和彻底结束需要不同的资源处理方式。如果推理引擎无法区分这些状态就只能依赖超时或通用淘汰策略被动处理缓存该释放的缓存释放得不够及时该保留的缓存又可能被误淘汰。结果是一边存在无效占用另一边又在重复计算显存容量、首 token 时延和系统吞吐同时承压。因此Agent 推理优化不能只停留在引擎内部也不能只在应用侧压缩上下文。真正的突破口是打通 Agent 任务状态与底层资源调度。二、openJiuwen 算力亲和在 Agent 与推理引擎间建立语义协同openJiuwen 的解法听起来并不复杂既然 Agent 本来就掌握任务状态当状态发生变化时实时同步给推理引擎。这就是 Agent Hint——Agent 与推理引擎的状态契约。它不是一次额外的 API 调用也不是插在中间的一套新系统而是给推理引擎下发的一段语义——告诉引擎我是哪个会话、隶属于哪个父任务、我这段缓存接下来会怎样。Agent 在关键状态变化时发出 Hint引擎据此执行对应的缓存动作。这套协同围绕三个动作展开会话状态调度动作解决的问题会话结束、上下文确认失效Evict驱逐及时释放不再需要的缓存减少无效占用会话挂起、上下文暂时不用Offload卸载缓存从 NPU HBM 迁往 CPU 内存等低成本存储保留复用可能会话将恢复、子 Agent 即将启动Prefetch预取在下一次推理前提前加载缓存减少等待与重复计算驱逐、卸载、预取共同构成 KV Cache 的生命周期闭环缓存不再只有留在显存或排队等淘汰两种命运而是随任务节奏在存储层级间主动流动。落到接口上一条带 Hint 的请求大致长这样agent_hint:{session_id:sub-1,// 我是哪个会话parent_session_id:main-0,// 隶属于哪个父任务context_management:{// 主动发起的缓存操作edits:[{type:offload,target:tools}]}}三、一次蜂群任务里缓存如何跟着任务走一圈机制讲完看它在一次典型的多 Agent 任务里如何运转。任务规划Leader 接到任务、完成拆解。系统提示词、工具定义这些所有成员都要用的公共前缀被算好并缓存供后续子 Agent 复用。子 Agent 调用多智能体协同过程中各子Agent可能会存在分步执行每次再被调起前JiuwenSwarm提前发出Prefetch信号把上一轮的缓存取回显存。工具执行 某个子Agent 调用外部工具、进入等待它的 KV Cache 从 HBM 卸载为活跃任务腾出显存工具结果一返回框架抢在下一次推理请求之前发起预取恢复推理时缓存已经回到显存。上下文压缩 长任务中每个 Agent 都可能压缩、裁剪自己的上下文。被移出上下文的部分同步发出卸载信号对应缓存随之下移到低成本存储。结束会话任务完成仍需复用的缓存转入低成本存储确认不再需要的直接驱逐整个蜂群任务结束时所有关联资源沿会话边界统一回收。恢复会话 已结束的会话也可能被重新唤起。框架在恢复前发出预取信号转存的缓存被提前取回显存任务接着上次的进度继续。回头看调度的依据已经变了不再是哪块缓存最久没被访问而是哪个任务正在跑、哪个只是暂停、哪段上下文马上要用。这使 KV Cache 管理从通用的访问热度判断升级为面向 Agent 执行工作流的语义级调度。四、三层协同从蜂群智能体到昇腾算力算力亲和并非一个孤立功能而是openJiuwen联合昇腾专家团队打造的一套从 Agent 延伸到本地显存和池化存储的协同架构。以 openJiuwen 社区打造的典型 JiuwenSwarm 蜂群智能体为例JiuwenSwarm 感知上下文与生命周期。它本来就掌握消息流转、工具调用、上下文压缩、子 Agent 创建与销毁的全部状态——对 Agent 来说这是任务流程对推理系统来说这些就是现成的调度信号。框架把资源状态归成三类正在使用的保护好暂时不用的挪下去不再使用的放掉。SAM 精细管理本地 KV Cache。推理引擎内新增的 SAMSession-Aware Manager会话感知管理器把无状态的前缀缓存升级为会话感知的管理与调度它维护会话与缓存的归属关系为活跃的长会话保住思考过程、工具中间结果这些独有前缀为已结束的会话沿清晰边界快速回收——本地显存的每一次分配与淘汰都带上了会话语义。SPM 协同管理池化缓存。到了多实例部署业界已经开始把 KV Cache 汇入 Mooncake 这类分布式缓存池但远端存储并不认识会话——SPMSession-Aware Pooling Manager会话感知池化管理器把会话语义继续传到池化层活跃会话持续保活会话结束即交还将恢复时提前预取。昇腾算力承载多级流动。在昇腾平台上这套机制复用了推理引擎既有的缓存加载与池化接口降低了系统改造成本缓存的跨层级迁移借助昇腾灵渠总线的高速互联在 NPU HBM、鲲鹏 CPU 的 DDR 内存、SSD 与远端缓存池之间快速流动——Hint 负责调得准灵渠总线负责流得快。一句话总结JiuwenSwarm 识别任务状态Agent Hint 负责传递语义SAM 与 SPM 负责精准调度灵渠总线为跨层级、跨设备的数据流动提供高速通道。任务启动缓存提前准备任务暂停缓存有序让位任务恢复缓存及时回归任务结束资源随即释放。五、这么做能换来什么算力亲和带来的价值最终体现在整个 Agent 系统的运行效率上。更高的缓存利用效率。已结束或闲置的会话不再长期占用 NPU HBM省出的高速存储可以服务更多活跃上下文。更稳定的多轮推理。活跃会话的独有前缀得到针对性保护减少因误淘汰导致的缓存失效和重复计算与 prefill。更快的会话恢复。预取把缓存加载前移到任务状态切换阶段降低恢复后的首轮等待。更强的多 Agent 承载能力。Leader 与多个 Teammate 并行工作时缓存随任务活跃度动态进出高速存储同等硬件承载更复杂的协作流程。更可控的工程成本。方案通过标准接口和事件机制衔接 Agent 与推理系统兼容既有缓存管理链路。openJiuwen 基于 SWE-bench Verified 数据集做了一组对比测试覆盖 Bug 修复、功能开发、代码重构等典型场景模拟 10 个用户并发使用 JiuwenSwarm 执行任务对比开启与不开启算力亲和的效果。结果显示开启算力亲和后首 token 时延TTFT降低 57.46%模型请求端到端E2E时延降低 27.61%Prefix Cache 命中率提升 33%池化缓存使用量峰值降低 25.24%。结语让算力从响应请求走向理解任务面向 Agent 的缓存策略必须理解一个任务是正在执行、暂时等待还是已经结束。只有让应用层的语义真正进入资源调度长上下文、多会话、多 Agent 并发带来的存储压力才能从被动应对变成主动管理。openJiuwen 算力亲和给出的协同范式落在工程上是两个方向向上以开放的 Agent Hint 接口规范承接任务语义向下把从本地显存到分布式缓存池的整条缓存调度链路升级为会话感知。归结成一句话Agent 读懂任务算力读懂 Agent。同样的硬件、同样的任务首 token 时延降低57%以上推理存储峰值直接省出约25%当前这套能力即将开源感兴趣的开发者可以关注 openJiuwen 开源社区尝鲜与体验GitHub: https://github.com/openJiuwen-aiAtomGit: https://atomgit.com/openJiuwen