技术原理

引言：为什么 Agent 需要向量数据库 当我们谈论 AI Agent 的"记忆"时，实际上在谈论一个多层次的存储系统。短期记忆存在于上下文窗口中，随着对话结束而消散；长期记忆则需要持久化存储，并能在新对话中被检索和调用。向量数据库就是实现长期记忆检索的核心基础设施。 一个典型的 Agent 记忆系统包含以下环节： 记忆写入：将对话片段、事实、决策等编码为向量嵌入并存储 记忆检索：将当前查询编码为向量，在存储的向量中找到语义最相似的记录 记忆管理：遗忘、合并、更新过时或冗余的记忆条目 记忆整合：将检索到的记忆与当前上下文融合，指导 Agent 行为 向量数据库的性能、功能和易用性直接决定了记忆系统的质量。本文将从 Agent 记忆系统的实际需求出发，系统对比当前主流的向量数据库方案。 一、Agent 记忆系统对向量数据库的核心需求 在进行选型之前，我们需要明确 Agent 记忆系统的特殊需求，这些需求与传统的推荐系统或搜索引擎有所不同： 1.1 实时写入与即时检索 Agent 在对话过程中需要实时写入新记忆并立即检索。这意味着向量数据库必须支持低延迟的写入操作，且写入的数据能立即被检索到，不能有同步延迟。 1.2 元数据过滤 Agent 的记忆通常需要附带丰富的元数据：时间戳、对话 ID、记忆类型（事实/偏好/事件）、重要性评分等。高效的元数据过滤能力对于精准检索至关重要。 1.3 动态更新与删除 记忆不是一成不变的。Agent 需要更新过时的记忆（如用户偏好变化）、删除无效的记忆（如临时信息）、合并重复的记忆。向量数据库需要支持高效的向量更新和删除操作。 1.4 规模弹性 个人 Agent 的记忆可能只有数千条，但服务大量用户的生产系统可能需要存储数十亿条记忆。向量数据库需要能平滑扩展，且在不同规模下保持性能稳定。 1.5 混合检索 纯向量检索在精确匹配场景（如特定 ID 查询、精确关键词）上表现不佳。Agent 记忆系统通常需要向量检索与传统关键词检索的结合，即混合检索能力。 二、主流向量数据库深度对比 2.1 Pinecone 架构定位：全托管云原生向量数据库 核心优势： 零运维：完全托管的服务，无需关心基础设施管理 低延迟：优化的查询引擎，P99 延迟通常在 50ms 以内 Serverless 架构：最新版本采用 Serverless 架构，按使用量计费，无需预配置资源 混合检索：原生支持稠密向量和稀疏向量的混合检索 命名空间隔离：通过命名空间实现多用户/多 Agent 的记忆隔离 核心劣势： 数据驻留：数据存储在 Pinecone 云上，无法本地部署，对数据敏感场景不友好 成本随规模增长：当向量数量超过百万级时，费用增长显著 灵活性限制：不支持的索引类型和距离度量方式有限 网络依赖：作为云服务，网络波动直接影响 Agent 响应延迟 Agent 记忆场景适用性： ...

引言 用户在发出一个深层推理问题后，等待智能体输出的那几秒钟，往往决定了产品的第一印象。2025 年以来，几乎所有主流的 AGI 智能体产品都标配了"打字机效果"——字符逐字出现，推理过程可见。但这背后的流式响应架构，远比表面上看起来复杂。 智能体流式响应不只是一个 UI 层面的锦上添花，它直接决定了系统的感知延迟、错误恢复能力和可扩展性。本文将围绕 AGI 智能体流式响应架构的设计展开系统讨论。 一、流式响应的核心技术路径 1.1 SSE：轻量级的首选 Server-Sent Events（SSE）是目前智能体流式响应中最广泛使用的传输协议。与 WebSocket 不同，SSE 天然运行在 HTTP 之上，浏览器原生支持 EventSource API，无需复杂的握手和心跳维护。 在典型架构中，LLM 推理引擎以 token 级别粒度产生输出，经由反代层封装为 SSE 事件流，逐帧推送到前端渲染缓冲区。SSE 的优势在于： 部署成本极低：直接复用现有的 HTTP 负载均衡和鉴权中间件 自动重连：浏览器内置断线重连能力 服务端推送天然单向：符合"模型输出→用户"的单一数据流向 但在多智能体协作（Multi-Agent）场景中，SSE 的单向特性成为瓶颈——当我们需要聚合多个子智能体并行产出的流时，SSE 的连接管理复杂度迅速上升。 1.2 WebSocket：双向互动的基石 WebSocket 在需要双向并行数据流的场景中不可替代。典型的例子是 Agent+Tool 的迭代式推理： 用户提问 → Agent 分析 → 调用搜索工具 → 等待结果 → 整合输出 在这个过程中，Agent 需要一边接收工具的返回数据，一边逐步向用户透传推理进度。WebSocket 的全双工特性让"一边等待工具响应、一边输出推理日志"成为可能。 我们团队在实践中采用的是一种分层混合架构： 外层 SSE + 内层 WebSocket：前端流量入口统一使用 SSE，隐藏后端的复杂性与容错逻辑；而在 Agent Engine 内部，各组件之间以 WebSocket 进行实时通信。 这既保持了前端接入的简洁性，又为内部高并发消息交换保留了灵活性。 ...

Flash Attention 系列回顾 Flash Attention 1：IO-Aware 的革命 标准注意力计算的问题是显存访问过多。标准实现： # 标准注意力（显存不友好） def standard_attention(Q, K, V): # Q, K, V: (batch, heads, seq, dim) # 需要 O(N^2) 显存访问来生成 attention matrix S = Q @ K.T # (N, N) 矩阵，需要全部存储在 HBM P = softmax(S) # 需要读取整个 S 矩阵 O = P @ V # 需要读取 V 和 P # 总 HBM 访问：O(N^2 * d) 只读，O(N^2) 写 return O HBM（High Bandwidth Memory）的带宽约 3 TB/s，而 SRAM（L2/L1 缓存）的带宽约 19 TB/s。Flash Attention 的核心洞察是：减少 HBM 访问，尽可能在 SRAM 中完成计算。 Flash Attention 1 通过 tiling 策略，将注意力分解为若干块，使每个块能放进 SRAM： ...

1. 长上下文的挑战 大语言模型的上下文长度直接决定了其处理长文档、多轮对话和复杂推理的能力。然而，扩展上下文长度面临三重挑战： 位置编码外推：RoPE 等位置编码在超出训练长度后性能急剧下降 注意力计算复杂度：标准注意力的 O(n²) 复杂度在长序列下不可接受 训练成本：长序列训练的显存和时间成本线性甚至二次增长 训练长度 4K 的模型在不同上下文长度下的表现: ┌──────────────┬──────────┬─────────────────────────┐ │ 上下文长度 │ 困惑度 │ Passkey Retrieval 准确率 │ ├──────────────┼──────────┼─────────────────────────┤ │ 4K (训练内) │ 5.82 │ 100% │ │ 8K (2x) │ 7.31 │ 12% │ │ 16K (4x) │ 12.44 │ 0% │ │ 32K (8x) │ 28.71 │ 0% │ └──────────────┴──────────┴─────────────────────────┘ 问题根源: RoPE 在超出训练范围后，旋转角度超出模型见过的范围 2. 位置插值（Position Interpolation） 2.1 核心思想 Chen 等人 (2023) 提出的 Position Interpolation (PI) 是最简单直接的方案：将推理时的位置索引压缩到训练范围内。 ...

固定深度的问题 标准 Transformer 的每一层都要处理每一个 token。无论是简单的"the"还是复杂的数学推导，都要经过全部 N 层的计算。 这合理吗？ 研究表明：不同 token 需要的计算量差异巨大。简单 token 在前几层就已经"完成"了表示学习，后面的层只是冗余计算。 Token "the" → Layer 1 ✓ → Layer 2 (冗余) → ... → Layer 32 (冗余) Token "integral" → Layer 1 → Layer 2 → ... → Layer 32 ✓ (需要全部层) 实验证据： 移除 50% 的浅层 token 处理，性能几乎不变（Elhoushi et al., 2024） 不同 token 的"最优层数"分布从 4 到 32 不等 约 40% 的前向计算是冗余的 Mixture of Depths 原理 核心思想 MoD（Raposo et al., 2024）借鉴了 Mixture of Experts（MoE）的思路，但不是在"专家"间路由，而是在层间路由： ...

1. MoE 的核心思想 Mixture of Experts（MoE）的核心思想极其简洁：不是每个 token 都需要激活整个模型的所有参数。传统稠密模型中，每个输入 token 都会与全部参数交互，而 MoE 引入了"专家"的概念，让每个 token 只激活一部分参数子集。 这种稀疏激活带来的直接好处是：可以用更少的计算量驱动更大的参数量。一个拥有 8×7B 参数的 MoE 模型，每次推理只激活约 7B 参数，却拥有 47B 的知识容量。 # 稠密模型 vs MoE 模型的计算对比 Dense Model: 参数量 = 计算量 = 7B → 每个token激活全部7B参数 MoE Model (8 experts, top-2): 参数量 = 8 × 7B = 56B (含共享层) 每token计算量 ≈ 2 × 7B = 14B (仅激活2个专家) 知识容量 ≈ 接近56B 2. MoE 的数学形式化 2.1 基本定义 给定输入 $x \in \mathbb{R}^d$，MoE 层的输出为： ...

长上下文的显存困境 大模型上下文窗口从 4K 扩展到 1M，最大的障碍不是计算量，而是 KV Cache 的显存。 以 Llama-3-70B 为例，fp16 精度下： 上下文长度 KV Cache (单序列) 单卡 80GB 够吗？ 8K ~1.5 GB 是 32K ~6 GB 是 128K ~24 GB 勉强 1M ~192 GB 需要多卡 如果 batch_size > 1，显存需求成倍增长。单卡无法装下百万 token 的 KV Cache，必须将注意力计算分布到多张卡上。 分布式注意力的三种方案 1. Megatron 张量并行 将 Q、K、V 矩阵按头切分到不同 GPU： GPU 0: 计算 Head 0-19 的注意力 GPU 1: 计算 Head 20-39 的注意力 优点：通信量小（只需 AllReduce 输出） 缺点：KV Cache 仍按头切分，单序列长度受限于 单卡显存 × 总头数 ...

为什么需要对齐？ 预训练后的 LLM 只是"下一个 token 预测器"，它学会了互联网上的所有文本模式——包括有害内容、错误信息和不符合人类价值观的回答。 对齐（Alignment） 的目标是：让模型的行为符合人类期望。 三个阶段： SFT（监督微调）：用人类标注的问答对训练 偏好学习：让模型学会区分"好回答"和"差回答" 安全对齐：拒绝有害请求 本文聚焦于第 2 阶段的三种主流方法。 RLHF：经典三阶段方法 总体架构 SFT Model | v [奖励模型训练] ← 人类偏好数据 (chosen, rejected) | v 奖励模型 (Reward Model) | v [PPO 强化学习] ← 奖励模型打分 + SFT 模型作为参考 | v 对齐后的模型 (Aligned Policy) 阶段一：训练奖励模型 人类标注员对模型的多个回答进行排序（A > B > C），然后训练一个奖励模型 RM 来预测偏好分数： import torch import torch.nn as nn class RewardModel(nn.Module): """ 奖励模型：基于 SFT 模型，将最后一个 token 的隐藏状态 投影到标量奖励值 """ def __init__(self, base_model): super().__init__() self.base_model = base_model # 通常是 SFT 模型 self.value_head = nn.Linear( base_model.config.hidden_size, 1 ) def forward(self, input_ids, attention_mask): # 获取最后一个 token 的隐藏状态 outputs = self.base_model( input_ids, attention_mask=attention_mask, output_hidden_states=True ) hidden = outputs.hidden_states[-1] # (B, L, D) # 取最后一个非 padding token seq_lens = attention_mask.sum(dim=1) - 1 # (B,) last_hidden = hidden[torch.arange(hidden.size(0)), seq_lens] # 投影到标量 reward = self.value_head(last_hidden) # (B, 1) return reward.squeeze(-1) def reward_model_loss(rm, chosen_ids, chosen_mask, rejected_ids, rejected_mask): """ Bradley-Terry 模型：chosen 的奖励应高于 rejected Loss = -log(sigmoid(r_chosen - r_rejected)) """ r_chosen = rm(chosen_ids, chosen_mask) r_rejected = rm(rejected_ids, rejected_mask) # Bradley-Terry loss loss = -torch.nn.functional.logsigmoid(r_chosen - r_rejected).mean() # 准确率 acc = (r_chosen > r_rejected).float().mean() return loss, acc 阶段二：PPO 强化学习 用奖励模型作为奖励函数，通过 PPO 算法优化策略模型： ...

1. 为什么 Tokenizer 如此重要 Tokenizer 是大语言模型与文本世界的接口。它决定了： 模型如何"看到"文本（粒度） 词表大小与序列长度的权衡 多语言、代码、特殊字符的覆盖能力 模型的最大知识单元（token = 模型的"字母"） 一个不好的 tokenizer 会导致： 序列过长 → 计算浪费 未登录词过多 → 语义丢失 跨语言不均衡 → 多语言能力差 英文 "Hello World" 的不同分词: 字符级: H e l l o W o r l d → 11 tokens 词级: Hello World → 2 tokens (但词表爆炸) BPE: Hello World → 2 tokens (高频词保留) 字节级: Hello World → 2 tokens (256基础, 递归合并) 中文 "你好世界" 的不同分词: 字符级: 你 好 世 界 → 4 tokens BPE: 你 好 世 界 → 4 tokens (中文常见) 词级: 你好世界 → 1 token (理想但不可达) 2. BPE (Byte Pair Encoding) 2.1 算法原理 BPE 最初是一种数据压缩算法，被 Sennrich 等人 (2016) 引入 NLP。核心思想：从字符级开始，迭代合并最高频的相邻 token 对。 ...

为什么我们需要超越 Transformer？ 自 2017 年 Transformer 问世以来，它几乎统治了所有序列建模任务。但 Transformer 有一个根本性缺陷：注意力机制的复杂度是 O(N²)，其中 N 是序列长度。当上下文窗口从 2K 扩展到 1M 时，计算和内存开销呈平方级增长。 序列长度 注意力矩阵大小 显存占用(近似) 2,048 4M ~16 MB 32,768 1B ~4 GB 131,072 17B ~68 GB 1,048,576 1T ~4 TB 这意味着：百万级 token 的上下文窗口在标准 Transformer 中几乎不可行，除非借助分布式注意力（如 Ring Attention）或近似方法。 研究者们提出了三类替代方案： 状态空间模型（SSM）：S4、S5、S6/Mamba 线性注意力/RNN 混合：RWKV、RetNet、Linear Attention 混合架构：Jamba（Mamba+Transformer）、Zamba 状态空间模型（SSM）：从 S4 到 Mamba SSM 的数学基础 状态空间模型源自控制理论，用一组隐状态 h(t) 来压缩历史信息： h'(t) = A·h(t) + B·x(t) # 状态方程 y(t) = C·h(t) + D·x(t) # 输出方程 离散化后变为递推形式： ...