第3章：业界主流缓解路线综述

Ch2 把三大挑战在工业数据下的”待解题清单”摆出来了。这一章把当前业界对这清单的主流缓解路线全部摊开——上下文管理一侧（Skill / Tool Search / 渐进式披露 / 上下文压缩），检索一侧（HNSW / DiskANN / SPANN / RabitQ + PCA）——逐一标注它们各自能解什么、不能解什么。把这些方案的能力边界画清楚，Ch4-6 的鲲鹏路线”切的到底是哪条缝隙”就一目了然。

📑 目录

• 1. 路线地图：从问题到方案的全景图
• 2. 上下文管理一侧的四条路线
• 3. 检索一侧的四条路线
• 4. 各路线的能力对照矩阵
• 5. 留给鲲鹏路线的精确缝隙
• 自我检验清单
• 参考资料

---

1. 路线地图：从问题到方案的全景图

            Agent Memory 系统的"上下文 + 检索"问题
                            │
              ┌─────────────┴──────────────┐
              ▼                            ▼
      上下文管理一侧                    检索一侧
              │                            │
   ┌──────────┼──────────┐      ┌─────────┼─────────┐
   ▼          ▼          ▼      ▼         ▼         ▼
[路线 A]   [路线 B]   [路线 C]  [路线 D] [路线 E] [路线 F]
压缩/摘要   工具瘦身   渐进披露  HNSW    DiskANN   量化压缩
            (sub-agent) (Skill /          (磁盘    (RabitQ
                       Tool Search)        ANN)    + PCA)
   │          │          │      │         │         │
   ▼          ▼          ▼      ▼         ▼         ▼
   信息有损   流程复杂   工程实现 内存爆炸   尾延迟   量化精度
              重         成本高    (千亿)    高      与召回的
                                                    取舍

整张地图分两侧八条路线（其中量化压缩 = RabitQ + PCA 这种向量量化体系）。我们逐一过一遍，再在第 4 节给一张能力对照矩阵。

2. 上下文管理一侧的四条路线

2.1 路线 A：上下文压缩 / 摘要

最朴素的思路：当上下文塞不下时，把过去的内容摘要或重要性评分后压缩成更短的版本。

核心机制：

• 重要性评分（per-message / per-token）+ 阈值删减
• 滑动窗口 + 摘要替换被滚出的内容
• 结构化压缩（事件级 / 实体级 / 关系级）

业内代表实现：

• LangChain ConversationSummaryBufferMemory
• LlamaIndex 各种 memory 模块
• Anthropic / OpenAI 官方 cookbook 的多种”总结—保留”模板

能解决什么：

• 长会话场景下”历史 token 累积”这一层
• 中等程度地缓解 prefill TTFT

解不了什么：

• ❌ 工具定义占用——工具定义不是历史，无法被摘要
• ❌ 中间数据传递——中间结果是当前 turn 内必须用的，不能摘要后再用
• ❌ 信息有损——压缩本身就是丢信息，长期累积下用户感受为”AI 总忘事”

🌟 关键判断：上下文压缩处理的是 Ch2 三层 token 结构里最薄的一层（30%）——它对工具定义和中间数据这两个真正的大头几乎无效。

2.2 路线 B：工具瘦身 / Sub-Agent 拆解

第二条思路：既然 58 个工具吃 55K token，就别一次性灌进同一个 Agent——把工具按场景拆成多个 Sub-Agent，每个 Sub-Agent 只看自己需要的子集。

核心机制：

• 主控 Agent 只看”调度类工具” + 决策”调用哪个 Sub-Agent”
• Sub-Agent 各自看自己的工具子集（GitHub / Slack / DB 各一）
• 父子之间的数据通过结构化消息（不是裸输出）传递

业内代表实现：

• LangGraph 的多 Agent 协作
• AutoGen / CrewAI 的多角色编排
• Anthropic Sub-Agent + Skill 的混合方案

能解决什么：

• 工具定义 token 被分散到多个 Agent 上——单 Agent 上下文显著瘦身
• 任务领域清晰可拆时，工程上可读性好

解不了什么：

• ❌ 跨域任务：当任务横跨多个 Sub-Agent 领域，编排开销很大
• ❌ 子 Agent 之间的中间数据传递依然会回到主 Agent 上下文
• ❌ 工程复杂度高：调试多 Agent 拆解经常变成排查”消息丢哪了”

2.3 路线 C：渐进式披露（Anthropic Skill / Programming Tool Call / Tool Search）

第三条思路是 2025-2026 年最有方法论价值的一类：不要一次性把工具全部 declare 出来，按需”按目录索引、按需展开”。

核心机制：

• 工具集分层组织：先给一个目录级的简介（比如 5 个 SaaS 名 + 一句话描述）
• 当需要某个 SaaS 时，再 fetch 该 SaaS 的具体工具列表
• 工具的具体参数 schema 在首次调用时才被加载到上下文
• 这一切对模型是 “Tool Search” 这种专门接口，由 Harness 实现

业内代表实现：

• Anthropic Skill API（2026）—— 把”技能”作为可被按需加载的二阶段 declaration
• Anthropic Programming Tool Call（2026）—— 让模型能”先 search 工具再决定用哪个”
• Tool Search Tool（开源社区参考实现）—— 给现有 Agent Harness 加 search 接口

能解决什么：

• ✅ 工具定义 token 占用 —— 这是渐进式披露的核心痛点，效果立竿见影
• ✅ 跨 SaaS 任务能在同一 Agent 内完成
• ✅ Harness 可以给”工具的描述”做 token-efficient 优化（短描述 + 按需展开）

解不了什么：

• ❌ 中间数据传递——工具调用结果还是要回到上下文
• ❌ 检索一侧的所有问题
• ❌ 当用户任务需要密集调用很多工具时，多次”先 search 再调用”反而引入额外延迟

⭐ 关键观察：渐进式披露精确命中了 Ch2 三层 token 结构里最大的一层（30%，工具定义）——这是它的核心工程红利。

2.4 路线 D：上下文缓存（外部内存池）

第四条思路是 2025-2026 年新兴的一条——把中间数据搬到 LLM 上下文之外的”内存层”：

核心机制：

• 中间结果（search 返回 / db_read 返回）不直接放进 LLM 上下文
• 而是写到外部缓存（key 是数据 ID）
• LLM 上下文只保留”指针 + 摘要”
• 后续步骤需要原始数据时，由 Harness 按需取回来再传入相关步骤

业内代表实现：

• 学术界：multiple papers on “external memory for LLMs”（2024-2026）
• 工业界：少量 Agent 框架开始引入”intermediate cache”
• 鲲鹏路线 1（Ch4 详细展开） —— 用 UB 内存池作为缓存底座

能解决什么：

• ✅ 中间数据传递 token 占用 —— 这是另一条精确命中点
• ✅ Prefill TTFT 显著下降（不再带着冗余中间数据走平方）
• ✅ 多步工具链总成本下降

解不了什么：

• ❌ 工具定义占用（这归路线 C）
• ❌ 历史会话压缩（这归路线 A）
• ❌ 检索一侧的问题
• ❌ 需要新硬件 / 新工程协议（不是纯软件层能闭环的）

🍎 直觉比喻：路线 C 像”开会前先发一张目录，需要哪页再发”；路线 D 像”会议室角落放一个文件柜，会上引用文件号即可，不必把文件复印到每个人手上”。

3. 检索一侧的四条路线

3.1 路线 E：HNSW（Hierarchical Navigable Small World）

业界最主流的 图索引 方案。把向量组织成多层近似最近邻图，查询时从顶层稀疏图开始下钻。

核心特性：

• 召回质量高（recall@10 > 0.95 是常态）
• 延迟低（小到中规模 P50 < 10ms）
• 内存占用大（图本身约为原始向量 1.2-1.5 倍）

主要工程实现：

• hnswlib / faiss-hnsw / pgvector hnsw
• 国内主流向量库（Milvus / Vespa / 阿里 Hologres / 腾讯云 VectorDB）

能解决什么：

• ✅ 中小规模高质量召回的事实标准

解不了什么：

• ❌ 千亿规模下单机内存装不下——必须分片
• ❌ 分片后的全局 recall 下降（每个分片只看局部图）
• ❌ 没有原生的”快慢介质”分层支持（HNSW 整体设计假设全内存）

3.2 路线 F：DiskANN（Microsoft 2019）

把 HNSW 的图结构改造为对 SSD 友好的版本，让大底库可以放到磁盘上。

核心机制：

• Vamana 图（图度数受控、IO 友好）
• PQ 量化（Product Quantization）做内存常驻摘要
• 真实距离计算时从 SSD 异步读原始向量

主要工程实现：

• Microsoft DiskANN（开源）
• FreshDiskANN / Filtered DiskANN（增量更新 / 带过滤的扩展）
• AlayaDB（基于 DiskANN 的产品化）

能解决什么：

• ✅ 单机 SSD 上承载 1-10 亿规模向量
• ✅ 内存占用比 HNSW 降一个量级（约 1/10）
• ✅ P50 延迟仍然在 10-30ms

解不了什么：

• ❌ 千亿规模下单机 SSD 也放不下，仍需分片
• ❌ P99 延迟受 SSD 尾延迟波动影响（高 IOPS 下尾部不稳）
• ❌ rerank 阶段访问原始向量的延迟难压

3.3 路线 G：SPANN（Microsoft 2021）

第三条路线是面向超大规模的另一种思路——把向量先聚类，每次查询只在几个最相关的簇里做精细搜索。

核心机制：

• 离线：用 K-means 把全量向量分成 ~百万级簇
• 在线：先做”找最近 N 个簇”的粗筛（簇中心搜索）
• 在选定簇内做精细 ANN 搜索

核心特性：

• 存储成本极低（簇中心常驻内存，原始向量在磁盘）
• 可扩展性极好（支持百亿规模）
• 召回质量受聚类质量影响

能解决什么：

• ✅ 百亿到千亿规模的工程可行性
• ✅ 簇中心常驻内存，主存压力小

解不了什么：

• ❌ 召回质量比 HNSW 低（聚类导致簇间召回不连通）
• ❌ 不擅长”极小簇”或”高维空洞”的语料
• ❌ 增量更新比 HNSW / DiskANN 复杂

3.4 路线 H：量化压缩（RabitQ + PCA + SIMD）

最近一两年（2024-2025）兴起的面向超低内存的量化路线。核心想法：把每个原始向量压成几十比特的紧凑表示，配合 PCA 降维，让上 TB 量级的向量压成 GB 量级。

核心机制：

• PCA 粗排压缩：把 768 维降到 64-128 维，损失少量精度换 5-10x 压缩
• RabitQ（旋转 + 二值化）：把 float32 向量压成 1-bit 的紧凑符号
• SIMD 加速距离计算：在 1-bit 表示上用 popcount 做汉明距离
• 二阶段精排：粗排过后再回原始向量做精确距离

业内代表实现：

• 2024 年的 RabitQ 论文及配套实现
• 多个开源向量库正在集成
• 鲲鹏路线 3（Ch6 详细展开） —— 把 RabitQ + PCA + SIMD 整合进新硬件路径

能解决什么：

• ✅ 内存占用：千亿向量从 ~300 TB 压到 ~3 TB（降 99%+）
• ✅ 粗排速度：SIMD 下汉明距离极快
• ✅ 冷数据成本：压缩后能放进相对便宜的介质

解不了什么：

• ❌ 量化精度损失需要二阶段精排来补——精排访问原始向量仍是瓶颈
• ❌ 不同语料对量化敏感度不同——通用性需要工程调参

⭐ 关键观察：路线 H 的核心红利是 “用内存换延迟” 这条曲线被显著重构——而这条曲线恰好和 Ch6 鲲鹏路线 3 的 UB + SSD 混合介质设计形成完美互补。

4. 各路线的能力对照矩阵

把上面 8 条路线在 Ch2 提出的”待解题清单”上各自的覆盖情况画一张矩阵：

待解题	A 压缩	B Sub-Agent	C 渐进披露	D 上下文缓存	E HNSW	F DiskANN	G SPANN	H 量化
工具定义 token	⚠️ 部分	✅	⭐ 强	❌	❌	❌	❌	❌
中间数据 token	❌	⚠️ 部分	❌	⭐ 强	❌	❌	❌	❌
历史会话 token	⭐ 强	❌	❌	❌	❌	❌	❌	❌
Prefill TTFT	⚠️ 部分	⚠️ 部分	⭐ 强	⭐ 强	❌	❌	❌	❌
千亿规模存储	❌	❌	❌	❌	❌	⚠️ 部分	⭐ 强	⭐ 强
高召回质量	❌	❌	❌	❌	⭐ 强	⭐ 强	⚠️ 部分	⚠️ 部分
P99 延迟	❌	❌	❌	⚠️ 部分	⭐ 强	⚠️ 部分	⚠️ 部分	⚠️ 部分
介质成本	❌	❌	❌	⭐ 强	❌	⭐ 强	⭐ 强	⭐ 强
跨节点共享	❌	❌	❌	⭐ 强	❌	❌	❌	❌
增量更新	⚠️ 部分	⚠️ 部分	⭐ 强	⭐ 强	⭐ 强	⚠️ 部分	❌	⚠️ 部分

这张矩阵传达的几个关键信号

信号 1：上下文管理一侧的 4 条路线各自命中不同 token 大头——它们是 互补的，不是替代。理想 Agent 应该 4 条都用上：

• C（渐进披露）解工具定义
• D（上下文缓存）解中间数据
• A（压缩）解历史会话
• B（Sub-Agent）解多领域协作

信号 2：检索一侧”千亿规模”+“高召回”+“低 P99”这三件事难以同时兼得——HNSW 召回好但塞不下，DiskANN 装得下但 P99 不稳，SPANN / 量化压缩规模好但召回略降。这正是 Ch5-6 鲲鹏路线想突破的死结。

信号 3：D（上下文缓存）和 G/H（检索量化）都直接受益于”中间档介质”——这是这两条路线和 RDMA / CXL / UB 内存池天然契合的地方。

5. 留给鲲鹏路线的精确缝隙

把上面所有结论收拢，2025-2026 年业界主流路线没充分覆盖的精确缝隙至少有三处：

缝隙 1：跨节点共享的”中间数据池”

路线 D（上下文缓存）方向对，但当前业内实现都是单机 / 单 Agent 进程内的缓存——多个 Agent 协作 / 多机推理时，这个缓存没有跨节点共享层。

🌟 填补：基于 UB 内存池的”跨节点上下文缓存”——Ch4 详细展开

缝隙 2：千亿规模下的”全局整图”

路线 E（HNSW）召回好但单机装不下；分片牺牲召回；DiskANN / SPANN 走的是”减容量”而不是”扩共享内存”。有没有可能”千亿规模 + 全图整库 + 高召回”同时做到？

🌟 填补：基于 UB 内存池的全局向量检索（多节点共享同一份完整 HNSW 整图）——Ch5 详细展开

缝隙 3：超低内存量化 + 中间档介质的协同

路线 H（量化）能压到 1/100 内存，但需要二阶段精排访问原始向量；如果原始向量在 SSD，精排延迟难压。有没有一种介质能让”压缩后的索引”+“完整原向量”同时在合理延迟内被访问？

🌟 填补：基于 UB + SSD 混合介质的超低内存检索——Ch6 详细展开

🎯 自我检验清单

读完本章你应该能回答：

• 上下文管理一侧的四条路线（A/B/C/D），各自命中三层 token 结构里的哪一层？为什么它们是互补不是替代？
• HNSW、DiskANN、SPANN 在”千亿规模 + 高召回 + 低 P99”这三件事上各做了什么取舍？
• RabitQ + PCA 这种量化路线的红利在哪、代价在哪？为什么它需要”二阶段精排”？
• 写出 Ch3 最后给出的”三处精确缝隙”——为什么它们恰好都需要”跨节点共享内存”这种新硬件能力？
• 如果你的项目预算有限，只能选两条路线先实施，你会选哪两条？为什么？

📚 参考资料

上下文管理路线

• Anthropic Skill API & Programming Tool Call（2026）—— 渐进式披露代表实现
• Anthropic Tool Search Tool（参考实现）
• LangChain Memory Modules（持续维护）—— 上下文压缩主流实现
• AutoGen / LangGraph / CrewAI（2024-2026）—— Sub-Agent 编排框架

检索路线

• HNSW（Malkov & Yashunin, TPAMI 2018）
• DiskANN（Microsoft NeurIPS 2019）
• FreshDiskANN（Microsoft 2021）—— 增量更新扩展
• Filtered DiskANN（2023）—— 带 metadata 过滤
• SPANN（Microsoft NeurIPS 2021）
• RabitQ（VLDB 2024）—— 旋转 + 二值化量化
• AlayaDB（2024-2025）—— DiskANN 产品化

系统综合

• OpenClaw（2026）—— 开源 Agentic AI 框架
• OpenViking（2026）—— Agent 编排平台
• 本系列模块十三 新型互联与远程内存

---

下一章预告：Ch4 进入鲲鹏路线 1 的详细复盘——基于 UB 内存池的上下文缓存系统——把”中间数据搬出 LLM 上下文”做成跨节点共享的工程底座。我们会拆开它的数据流、内存布局、典型负载下的延迟分布，并和路线 D（单机上下文缓存）做精确对照。