第1章：Agent Memory 为什么需要分离式内存

Agent 系统从”问答机器人”走向”长任务智能体”,最先撞墙的不是模型能力,是支撑它的记忆系统。一段长会话产生几十 K 中间数据,几十个工具的定义占满 prompt,千亿向量底库下 50ms 内召回 top-k——这三件事每一件单独看都像”工程优化”,但放进同一个生产 Agent 里,它们之间互相挤压,用任何一种单机方案都解不透。本章讲清三个问题:Agent Memory 系统当前撞的三类墙具体长什么样?为什么单机内存 / 单机 SSD 这两条路径都到了天花板?分离式内存(RDMA / CXL / UB 这一新型硬件)恰好填了哪一段曲线? 最后概览鲲鹏 2026 公开方案是怎么把这三件事用”同一个底座”串起来的——这是后面 5 章详细复盘的总入口。

📑 目录

• 1. Agent Memory 系统当前的工程画像
• 2. 挑战 1:准确率
• 3. 挑战 2:上下文过载
• 4. 挑战 3:检索瓶颈
• 5. 单机方案的天花板
• 6. 分离式内存的”中间档”价值
• 7. 鲲鹏 2026 路线的三件套
• 8. 后续章节怎么看
• 自我检验清单
• 参考资料

---

1. Agent Memory 系统当前的工程画像

1.1 一个真实的 Agent 任务消耗了什么

   Agent 接到任务:"帮我做一份本月项目进度汇报"
                │
                ▼
   ┌─────────────────────────────────────────┐
   │ 1. 加载工具集(可能 50+ 个 MCP 工具)      │ ──> prompt 几十 K tokens
   │ 2. 召回历史上下文(向量库)                │ ──> 几 GB 索引
   │ 3. 调用 search → 找文档(返回 MB 级)      │ ──> 写进 prompt
   │ 4. 调用 db_read → 拉数据(返回几千行)     │ ──> 写进 prompt
   │ 5. 调用 BI_chart → 出图(返回大表)        │ ──> 写进 prompt
   │ 6. 总结 → 生成报告                       │
   │ 7. (这个会话结束后留下的"长记忆")         │
   └─────────────────────────────────────────┘

🌟 关键事实:这个任务的 token 消耗 80% 不在最终输出,而在工具定义和中间数据的来回搬运里。Agent 框架(LangGraph / LangChain / OpenClaw 等)在 token 经济学上的”摊销效率”普遍很低。

1.2 用户期望的 SLO

场景	用户期望	实际经常出现
客服对话	<1 秒响应	工具加载延迟 + 几次大模型调用 = 几十秒
风控决策	<50ms 召回	千亿底库精确检索 = 数秒
BI 查询	立刻出图	中间表来回经过 LLM 重传 = 资源浪费
长记忆陪聊	记住一周前的偏好	长上下文塞 prompt = token 成本爆炸

⭐ 观察:用户对 Agent 的延迟容忍度比对传统 LLM 推理低一个量级——他们不再原谅”一段话还得等几秒”。

1.3 三个不可调和的工程痛点

把上面种种现象抽象成三类核心问题(本章后续每节细讲):

• 准确率不稳:语义偏差、上下文相关性误判、噪声拉低召回
• 上下文过载:工具定义 + 中间数据塞满 prompt,token 经济学崩
• 检索瓶颈:千亿底库下,延迟和成本同时爆炸

🧠 关键判断:这三个痛点共享同一个底层根因——内存(显存 + 主存)容量与速度的不匹配在 Agent 场景下被几个数量级放大。这就是为什么”硬件层换思路”是值得探的方向。

---

2. 挑战 1:准确率

2.1 三类”偏差”

类型	体现	对存储侧的要求
语义偏差	”上次讨论的方案” → 关键词匹配找不到正确历史	需要语义索引(向量),非关键词索引
上下文相关性	同一段记忆在不同场景下相关性权重不同	检索时要有动态打分,非静态 ranking
噪声干扰	寒暄、错字、重复 → 召回 top-k 里大部分无用	需要前置过滤 / rerank / 时间衰减

2.2 准确率与硬件的关系

直觉上”准确率是算法问题”,但深挖会发现硬件强相关:

• 向量库规模 决定能不能用全局图索引(HNSW 整图)还是被迫用分片索引(各自局部)。分片几乎必然牺牲全局召回质量——这正是鲲鹏路线第二个创新(全局向量检索)切入的痛点
• rerank 的精细度 受限于”愿不愿在拉了 top-1000 后再做一次精排”——这个精排涉及二阶段访问,需要存储侧低延迟随机读
• 多路召回融合 需要把多个索引的结果都拉到内存做 merge——单机内存装不下时只能砍候选数量

🌟 结论:准确率不是纯算法问题,是”算法 + 存储能力”的耦合问题。存储一升级,算法上限就上一档。

2.3 当前主流补救手段

• 重要性评分模型 + token-level 评分
• 知识图谱化的结构化检索
• LLM-as-Judge 的事后筛选

📍 代价:这些手段都需要额外的算力或存储开销——治标不治本。本质问题没解决:底库太大,搜不动。

---

3. 挑战 2:上下文过载

3.1 工具定义过载

主流 Agent 框架的默认做法是把所有可用工具的定义一次性灌进 prompt。让我们看一组公开数据(鲲鹏团队 2026 报告整理):

服务	工具数	Token 消耗
GitHub	35	~26K
Slack	11	~21K
Sentry	5	~3K
Grafana	5	~3K
Splunk	2	~2K
合计	58	~55K

🌟 关键事实:工具定义吃掉 ~55K tokens——而 GPT-4 / Claude 3.5 主流上下文 128K-200K,工具定义占了 1/4-1/3,真正用来推理的预算被严重挤压。

3.2 中间数据过载

更严重的是多步工具调用之间的中间数据搬运:

   Agent → search → 返回 50 KB 文档列表(进 prompt)
   Agent → db_read(基于上一步结果) → 返回 500 KB 数据表(进 prompt)
   Agent → chart_gen(基于上一步) → 返回 200 KB 图表 metadata(进 prompt)
                                            │
   每一步的中间结果都要被 LLM "看一遍" ─────┘
   即使下一步根本不需要 LLM 介入决策

🍎 直觉比喻:这就像让大老板把每张快递单都过目一遍才能让快递员去下一站——大老板的时间(LLM 上下文窗口)比快递员的时间(工具调用)贵几个量级。

3.3 token 经济学的具体代价

按主流大模型每 1M token 约 $5-15 计:

• 一次重型 Agent 任务(60+ 步,每步 1-2K tokens 中间数据)平均消耗几 M token 输入
• 单任务输入成本 = 几美元到几十美元——只有少数高价值场景能 justify

⭐ 观察:token 经济学是 Agent 落地的隐性天花板——技术能跑,但跑不起。

3.4 现有缓解路线快览

路线	思路	局限
上下文压缩	摘要 / 重要性评分 / 结构化	信息有损,复杂推理掉精度
渐进式披露	分层加载工具 / 按需展开	静态信息友好,大规模中间数据无解
Programming Tool Call	让 LLM 写代码调工具,中间结果走变量	模型必须有强代码能力
中间数据搬出 LLM 上下文	数据存外面,prompt 只放引用	本模块第 4 章鲲鹏路线核心

🌟 关键判断:前三条都没绕开”中间数据要进 LLM 视野”这个根本假设。鲲鹏路线第一个创新是把这个假设打破——这正是 Ch4 要详细复盘的。

---

4. 挑战 3:检索瓶颈

4.1 当代 Agent 向量库的规模

随着 Agent 长记忆能力被认真使用,向量库底库迅速从”千万级”涨到”千亿级”:

场景	典型规模	物理大小(768 维 × fp32)
单个企业知识库	千万-亿级	几十 GB - 几百 GB
多租户 SaaS	十亿级	TB 级
巨型平台 / 社交 / 电商	千亿级	数百 TB

⭐ 关键挑战:数百 TB 量级远超主流单机内存上限(单机 DDR5 通常 1-3 TB,极端配置才到 6 TB)。

4.2 时延与成本的双重压力

• 时延:50 ms 是金融、风控、工业 Agent 的硬要求,千亿底库精确搜索通常需要秒级 → 必须用近似算法 + 索引
• 成本:全部塞内存对于”不那么烫的”数据是巨大浪费——但纯下盘方案延迟又不够

4.3 现有解法的天花板

算法	适用规模	局限
HNSW	<十亿(千维)	主体进 RAM,大规模放不下
DiskANN	十亿+	索引部分仍要 RAM,大规模仍然贵
分片 HNSW	任意规模(用机器拼)	全局图被切碎,召回易陷局部最优
聚类索引(IVF/SPANN)	十亿+	召回稳定性受簇划分质量影响

🌟 核心矛盾:“大规模 + 高召回 + 低延迟 + 低成本” 四个目标在单机内存框架内不可同时满足——必须从硬件层破局。这正是分离式内存进场的位置。

---

5. 单机方案的天花板

把上面三类挑战放进同一个坐标系:

   纵轴:数据规模
       PB ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
                        ❌ 单机塞不下                           ┃
       TB ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┃
                        ⚠️  分片 → 局部最优                     ┃
                        ⚠️  下盘 → 延迟爆炸                     ┃
       100GB ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┃
                        🟡 极限单机内存                         ┃
       10GB ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┃
                        ✅ HNSW 单机舒适区                       ┃
       1GB ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
              纯内存       纯下盘     分片         分离式池
                                    (局部最优)    (新出路)
   ────────────────────────────────────────────────────────►
   横轴:架构选择

5.1 纯内存方案

• 优点:延迟极低,算法选择丰富(HNSW 等)
• 限制:单机内存上限即业务上限——百 GB 是天花板,千 GB 极端配置勉强

5.2 纯下盘方案

• 优点:容量随 SSD 扩展,接近无限
• 限制:P99 抖动严重(SSD random IO 4K ~100 µs 量级),50ms SLO 紧张
• DiskANN 这类磁盘友好算法已经把这条路压榨到极致,但索引部分仍要全部进 RAM

5.3 分片方案

• 优点:水平扩展能力强
• 限制:HNSW 全局图被切成碎片,每个分片各自跑只能拿到局部最优解——召回质量上限被压住

🧠 关键洞察:单机的三条路都到了顶——再走这些路,最多再压榨 20-30% 性能,挤不出数量级。需要从硬件层换路径。

---

6. 分离式内存的”中间档”价值

6.1 它在性能-容量曲线的位置

   延迟(纵) vs 容量(横)
   ↑
ns │ ████ HBM
   │  
   │     ████ 本地 DRAM
   │  
µs │           ████ 分离式内存(RDMA / CXL / UB)  ← Agent Memory 缺的就是这一档
   │  
   │  
ms │                      ████ NVMe SSD
   │  
   │                                  ████ 对象存储
s  │
   └────────────────────────────────────────────►
      GB    数 GB  数十 GB    TB+   PB+    容量

🌟 核心观察:分离式内存填的是 µs 级延迟 × TB+ 容量这一块”性能-容量黄金中段”——HBM 太贵装不下,SSD 太慢撑不住,分离式内存正好压在 Agent Memory 的最大痛点上。

6.2 三条互联协议的特性

协议	主战场	时延	带宽	容量	现状
RDMA(IB / RoCE)	跨节点 KV pool / KV-Cache	几 µs	100-400 Gbps	节点池累加	商用成熟
CXL 2.0/3.0	同机房短距 + memory pooling	< 200 ns	极高(PCIe 5.0/6.0 量级)	TB 级单池	2024-2026 量产爬坡
UB(华为统一总线)	鲲鹏 / 昇腾超节点共享域	接近本地 DRAM	极高	PB 级共享池	鲲鹏路线核心

⭐ 特别说明 UB:统一总线(Unified Bus) 是华为为超节点设计的内部高速互联——把多台服务器的 CPU / GPU / 内存通过 UB 链接成”一个大节点”,从 GPU 视角看远端内存接近本地访问。这给了”一份完整 HNSW 整图存在 PB 级共享内存里” 的硬件可行性,这正是鲲鹏路线第二个创新的物理基础。

6.3 给 Agent Memory 的三个新可能

可能	对应解决哪个挑战
中间数据搬到分离式池,不进 LLM 上下文	上下文过载(工具定义 + 中间数据)
HNSW 整图驻留分离式池,跨节点共享	检索瓶颈(全局召回 vs 分片局部最优)
量化压缩 + 分离式池冷数据	检索成本(内存占用降数量级)

🧠 关键判断:这三个可能正好对应 Agent Memory 三大挑战中的两个半(准确率被全局图索引带动,上下文过载被中间数据池化解决,检索瓶颈被量化压缩 + 池化解决)——分离式内存是当前看得见的最系统的破局路径。

---

7. 鲲鹏 2026 路线的三件套

把鲲鹏团队 2026 年公开方案抽象成三个互相耦合的工程模块:

7.1 模块 1:上下文缓存系统

核心思路:中间数据存进缓存系统(支持数据库 / 内存对象 / 内存文件三种语义),通过数据引用而不是数据本身在 LLM 上下文里流动,工具间直接基于引用调用,真实数据由 Host 在调用瞬间解引用。

   传统:
   Tool A 返回 大数据 ──> LLM 看一遍 ──> Tool B 输入 大数据

   鲲鹏路线:
   Tool A 返回 大数据 ──> 写进 cache,得到 引用 ID
                        ──> LLM 看 引用 ID(几个 token)
   ──> Tool B 输入 引用 ID ──> Host 解引用 ──> Tool B 拿到 大数据

🌟 公开收益数字(基于 GLM-4.5-Air 在 SWE Benchmark 280 个 case 上):

• 平均输入 token 从 1653K 降到 968K(约 -40%)
• 平均轮次从 60 增到 71(细粒度交互更多)
• 正确率持平

⭐ Ch4 详细复盘。

7.2 模块 2:基于 UB 内存池的全局向量检索

核心思路:通过 UB 把 M 个节点连成大共享内存池(百 TB 级),让 HNSW 整图驻留这个池。检索时只需要在一个节点跑算法,通过 UB 内存语义访问其它节点的数据,而不是每次请求都让所有节点本地搜索后再合并。

   传统分片:
   Query ──> 路由到所有 N 个节点 ──> 各节点本地 search ──> 合并 top-K
   ❌ 全局图被切碎,召回易陷局部最优
   ❌ 每个请求都要 N 节点参与,算力消耗大

   UB 共享池:
   Query ──> 路由到 1 个节点 ──> 通过 UB 内存语义访问全图 ──> 返回 top-K
   ✅ 全局完整 HNSW
   ✅ 单请求只占 1 个节点算力,QPS 上得去

⭐ Ch5 详细复盘。

7.3 模块 3:超低内存混合介质向量检索

核心思路:RabitQ + PCA 多重量化 做粗排(SIMD 友好),SIMD 紧凑化索引结构 整合量化编码与图结构,全数据下盘 把内存占用降到极致。

🌟 公开收益数字(基于亿级 1024 维数据集,鲲鹏 920 芯片):

算法	Cores	QPS	内存	SSD	Recall@10
DiskANN	16	2619	~12 GB	800 GB	95.00
鲲鹏方案	16	5578	~100 MB	800 GB	95.12

内存降 99%+,QPS 提升 ~2.1×,召回率持平。

⭐ Ch6 详细复盘。

7.4 三件套之间的相互支撑

   上下文缓存(模块 1)
        │ 解决:中间数据搬出 LLM 上下文
        │ 用到:UB 内存池作为缓存底座
        │
        ▼
   全局向量检索(模块 2)
        │ 解决:大底库 + 全局召回
        │ 用到:UB 内存池存完整 HNSW 整图
        │
        ▼
   超低内存量化检索(模块 3)
        │ 解决:成本爆炸
        │ 配合 模块 2 减少底库本身的内存占用

🧠 关键观察:三个模块共享同一个底座(UB 内存池)——这是它工程上的原创性。其它学术 / 工业方案要么只解上下文(Skill / 渐进式披露),要么只解检索(DiskANN / SPANN),很少有把两件事用同一种新硬件统一解决的。

⭐ Ch7 会详细对照分析鲲鹏路线和我们项目第一/二模块在抽象层级、可移植性、生产工程性等维度的差异。

---

8. 后续章节怎么看

Ch1(本章)  ── 为什么需要 + 总览路线
   │
Ch2 ── 三大挑战的工业实证(token 解剖 / 延迟分布 / 成本结构)
   │
Ch3 ── 业界主流路线综述(压缩 / 渐进披露 / DiskANN / HNSW)
   │
   ├── Ch4 鲲鹏路线 1:上下文缓存
   ├── Ch5 鲲鹏路线 2:基于 UB 的全局向量检索
   └── Ch6 鲲鹏路线 3:超低内存混合介质检索
                     │
                     ▼
Ch7 ── 与项目第一/二模块的对照分析
                     │
                     ▼
Ch8 ── 端到端实战参考(OpenClaw / OpenViking 拼装路径)

🌟 阅读建议:

• 时间紧:Ch1 + Ch7(对照视角)直接给 takeaway
• 想入门:Ch1-Ch3 完整看
• 做工程:Ch4-Ch6 重点读
• 写论文:Ch7 是腹地

---

✅ 自我检验清单

• 三大挑战:能用一段话讲清”准确率 / 上下文过载 / 检索瓶颈”各自的工程具体表现
• token 数字:能说出”58 个工具占 ~55K tokens”的数量级冲击,并解释这意味着什么
• 千亿向量规模:能粗算 “千亿 × 768 维 × fp32 ≈ 数百 TB” 的量级
• 单机三条路的天花板:纯内存 / 纯下盘 / 分片 各自的瓶颈是什么
• 分离式内存定位:能在性能-容量曲线上指出它的位置
• 三种互联协议:能区分 RDMA / CXL / UB 的特性差异
• 鲲鹏三件套:能默写三个模块各自解决什么挑战 + 共享什么底座
• 公开收益数字:能复述上下文缓存 token 降幅 (~40%) 和量化检索内存降幅 (99%+)
• 后续阅读路径:能根据自己角色选合适的章节顺序

---

📚 参考资料

主线参考方案

• 鲲鹏 Agent Memory 创新方案(华为鲲鹏团队 2026 公开发表):上下文缓存 + 全局向量检索 + 超低内存混合介质检索
• OpenClaw + OpenViking + 鲲鹏端到端 Agent 实践 —— 公开案例

上下文管理路线

• Anthropic Skill / Programming Tool Call / Tool Search Tool —— 渐进式披露代表
• MCP(Model Context Protocol) —— 工具调用标准

经典 ANN 算法

• HNSW(Malkov & Yashunin, TPAMI 2018)
• DiskANN(Microsoft NeurIPS 2019)
• SPANN(Microsoft NeurIPS 2021)
• RabitQ(2024) —— 旋转 + 二值化量化算法
• PCA(经典统计降维) —— 配合 RabitQ 用作粗排

互联硬件

• InfiniBand / RoCE 规范 —— RDMA 主流实现
• CXL 2.0/3.0 规范 —— Compute Express Link 联盟
• 华为 UB(统一总线) —— 鲲鹏 / 昇腾超节点核心

综述

• Towards Efficient Generative LLM Serving: A Survey(CMU 2023)
• A Survey on Vector Database Management Systems(2024)
• Memory in the Age of AI Agents(2025)

本系列其它模块

• 模块五 Agent Memory —— 上层语义记忆框架
• 模块十三 新型互联与远程内存 —— RDMA / CXL 硬件底座
• 模块十四 长记忆大模型系统 —— LMObject 跨层级管理框架
• 模块十六 学习路线