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

机器之心发布 给 Agent 一个任务，它会自己规划、调用工具、读文件、反思修正，一干就是几十分钟甚至数小时；任务再复杂些，还需要多个 Agent 分工协作。任务越长、协作的 Agent 越多，推理过程中产生的 KV Cache 就越庞大，推理时延越久。 问题在于，传统推理引擎只看得到请求和缓存，却看不懂 Agent 正在做什么：子任务已经结束，缓存可能还停留在显存里；会话暂时挂起，缓存却继续占着最贵的位置；会话即将恢复，引擎又要等请求到来才开始加载。 这背后的核心断层是： Age nt 掌握 任务 状态， 引擎掌握算力资源，两者之间缺一条传递语义的通道。 近期我们了解到，由华为 2012 实验室、华为云、计算、终端等团队联合打造的 openJiuwen 开源智能体平台构建了智能体 "算力亲和" 能力 —— 一套打通 Agent 框架、推理引擎与底层算力的全链路协同机制，让 Agent 的任务状态转化为算力可理解、可执行的调度信号，使 KV Cache 从被动管理走向主动协同。 一、推理引擎的困境： 看得见缓存，看不懂任务 模型推理过程中，会把已经算过的中间结果（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，引擎据此执行对应的缓存动作。这套协同围绕三个动作展开： 驱逐、卸载、预取，共同构成 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。 推理引擎内新增的 SAM（Session-Aware Manager，会话感知管理器），把无状态的前缀缓存升级为会话感知的管理与调度：它维护会话与缓存的归属关系，为活跃的长会话保住思考过程、工具中间结果这些独有前缀，为已结束的会话沿清晰边界快速回收 —— 本地显存的每一次分配与淘汰，都带上了会话语义。 SPM 协同管理池化缓存。 到了多实例部署，业界已经开始把 KV Cache 汇入 Mooncake 这类分布式缓存池，但远端存储并不认识 "会话"——SPM（Session-Aware Pooling Manager，会话感知池化管理器）把会话语义继续传到池化层：活跃会话持续保活，会话结束即交还，将恢复时提前预取。 昇腾算力承载多级流动。 在昇腾平台上，这套机制复用了推理引擎既有的缓存加载与池化接口，降低了系统改造成本；缓存的跨层级迁移，借助昇腾灵渠总线的高速互联，在 NPU HBM、鲲鹏 CPU 的 DDR 内存、SSD 与远端缓存池之间快速流动 ——Hint 负责 "调得准"，灵渠总线负责 "流得快"。 一句话总结： JiuwenSwarm 识别任务状态，Agent Hint 负责传递语义，SAM 与 SPM 负责精准调度，灵渠总线为跨层