openJiuwen协同昇腾打造智能体「算力亲和」技术，首token时延砍半，推理存储占用下降25%

机器之心发布

给 Agent 一个任务，它会自己规划、调用工具、读文件、反思修正，一干就是几十分钟甚至数小时；任务再复杂些，还需要多个 Agent 分工协作。任务越长、协作的 Agent 越多，推理过程中产生的 KV Cache 就越庞大，推理时延越久。

问题在于，传统推理引擎只看得到请求和缓存，却看不懂 Agent 正在做什么：子任务已经结束，缓存可能还停留在显存里；会话暂时挂起，缓存却继续占着最贵的位置；会话即将恢复，引擎又要等请求到来才开始加载。

这背后的核心断层是：Agent 掌握任务状态，引擎掌握算力资源，两者之间缺一条传递语义的通道。

近期我们了解到，由华为 2012 实验室、华为云、计算、终端等团队联合打造的 openJiuwen 开源智能体平台构建了智能体 "算力亲和" 能力 —— 一套打通 Agent 框架、推理引擎与底层算力的全链路协同机制，让 Agent 的任务状态转化为算力可理解、可执行的调度信号，使 KV Cache 从被动管理走向主动协同。

一、推理引擎的困境：

看得见缓存，看不懂任务

模型推理过程中，会把已经算过的中间结果（Key/Value）缓存下来（即 KV Cache），生成每个新 token 时就不必把全部历史上下文重算一遍。代价是，上下文越长、并发会话越多，KV Cache 占用的显存就越多 —— 而显存，恰恰是 GPU、NPU 这类 AI 加速芯片上最贵的地方。

当前推理引擎主要依赖 LRU 等通用策略管理 KV Cache，但 Agent 执行过程中的上下文状态变化，远比一问一答复杂 ——

一个任务里，推理、工具调用、等待、恢复反复切换；
上下文会增长、压缩，甚至回退到历史检查点；
多个子 Agent 各有独立上下文，又共享系统提示词、工具定义这些公共前缀；
会话 "暂时不用" 和 "彻底结束"，需要不同的资源处理方式。

如果推理引擎无法区分这些状态，就只能依赖超时或通用淘汰策略被动处理缓存：该释放的缓存释放得不够及时，该保留的缓存又可能被误淘汰。结果是，一边存在无效占用，另一边又在重复计算；显存容量、首 token 时延和系统吞吐同时承压。

openJiuwen协同昇腾打造智能体「算力亲和」技术，首token时延砍半，推理存储占用下降25%图2

因此，Agent 推理优化不能只停留在引擎内部，也不能只在应用侧压缩上下文。

真正的突破口，是打通 Agent 任务状态与底层资源调度。

二、openJiuwen 算力亲和：

在 Agent 与推理引擎间建立语义协同

openJiuwen 的解法听起来并不复杂：既然 Agent 本来就掌握任务状态，当状态发生变化时，实时同步给推理引擎。这就是 Agent Hint——Agent 与推理引擎的 "状态契约"。

它不是一次额外的 API 调用，也不是插在中间的一套新系统，而是给推理引擎下发的一段语义 —— 告诉引擎：我是哪个会话、隶属于哪个父任务、我这段缓存接下来会怎样。

Agent 在关键状态变化时发出 Hint，引擎据此执行对应的缓存动作。这套协同围绕三个动作展开：

openJiuwen协同昇腾打造智能体「算力亲和」技术，首token时延砍半，推理存储占用下降25%图3

驱逐、卸载、预取，共同构成 KV Cache 的生命周期闭环：缓存不再只有 "留在显存" 或 "排队等淘汰" 两种命运，而是随任务节奏在存储层级间主动流动。

落到接口上，一条带 Hint 的请求大致长这样：

"agent_hint": {  "session_id": "sub-1",              // 我是哪个会话  "parent_session_id": "main-0",      // 隶属于哪个父任务  "context_management": {             // 主动发起的缓存操作    "edits": [{ "type": "offload", "target": "tools" }]  }}

三、一次蜂群任务里，

缓存如何跟着任务走一圈

机制讲完，看它在一次典型的多 Agent 任务里如何运转。

openJiuwen协同昇腾打造智能体「算力亲和」技术，首token时延砍半，推理存储占用下降25%图4

任务规划：Leader 接到任务、完成拆解。系统提示词、工具定义这些所有成员都要用的公共前缀被算好并缓存，供后续子 Agent 复用。

子 Agent 调用：多智能体协同过程中，各子 Agent 可能会存在分步执行，每次再被调起前，JiuwenSwarm 提前发出 Prefetch 信号，把上一轮的缓存取回显存。

工具执行：某个子 Agent 调用外部工具、进入等待，它的 KV Cache 从 HBM 卸载，为活跃任务腾出显存；工具结果一返回，框架抢在下一次推理请求之前发起预取，恢复推理时缓存已经回到显存。

上下文压缩：长任务中，每个 Agent 都可能压缩、裁剪自己的上下文。被移出上下文的部分同步发出卸载信号，对应缓存随之下移到低成本存储。

结束会话：任务完成，仍需复用的缓存转入低成本存储，确认不再需要的直接驱逐；整个蜂群任务结束时，所有关联资源沿会话边界统一回收。

恢复会话：已结束的会话也可能被重新唤起。框架在恢复前发出预取信号，转存的缓存被提前取回显存，任务接着上次的进度继续。

回头看，调度的依据已经变了：不再是 "哪块缓存最久没被访问"，而是 "哪个任务正在跑、哪个只是暂停、哪段上下文马上要用"。这使 KV Cache 管理从通用的访问热度判断，升级为面向 Agent 执行工作流的语义级调度。

四、三层协同：从蜂群智能体，到昇腾算力

算力亲和并非一个孤立功能，而是 openJiuwen 联合昇腾专家团队打造的一套从 Agent 延伸到本地显存和池化存储的协同架构。以 openJiuwen 社区打造的典型 JiuwenSwarm 蜂群智能体为例：

openJiuwen协同昇腾打造智能体「算力亲和」技术，首token时延砍半，推理存储占用下降25%图5

JiuwenSwarm 感知上下文与生命周期。它本来就掌握消息流转、工具调用、上下文压缩、子 Agent 创建与销毁的全部状态 —— 对 Agent 来说这是任务流程，对推理系统来说，这些就是现成的调度信号。框架把资源状态归成三类：正在使用的保护好，暂时不用的挪下去，不再使用的放掉。

SAM 精细管理本地 KV Cache。推理引擎内新增的 SAM（Session-Aware Manager，会话感知管理器），把无状态的前缀缓存升级为会话感知的管理与调度：它维护会话与缓存的归属关系，为活跃的长会话保住思考过程、工具中间结果这些独有前缀，为已结束的会话沿清晰边界快速回收 —— 本地显存的每一次分配与淘汰，都带上了会话语义。

SPM 协同管理池化缓存。到了多实例部署，业界已经开始把 KV Cache 汇入 Mooncake 这类分布式缓存池，但远端存储并不认识 "会话"——SPM（Session-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%。