## 一、先澄清一点：它们不是同类竞品

打开这三个项目的 README，你会看到三个看似相似的关键词：检索、记忆、上下文。但如果只看词就下结论，选型必然出错。三者的真实位置是这样的：

- **zvec-grep**(命令名 `zg`，zvec-ai 出品，底座是阿里开源的嵌入式向量库 zvec)是一个**本地优先的混合代码搜索引擎**。它把 ripgrep 式正则搜索、BM25 词法排序和向量语义检索合并进一个命令，解决的是"当次会话里怎么快速找到代码"。它没有记忆，索引删了可以随时重建。
- **TencentDB Agent Memory**(下称 TAM，腾讯云出品)是一个**团队级记忆中枢服务**。它把对话、文档、代码蒸馏成四类可治理的记忆资产，解决的是"这个用户、这个团队、这个项目，之前学到过什么"。
- **OpenViking**(下称 OV，字节跳动火山引擎 Viking 团队出品)是一个**上下文数据库**。它用 `viking：//` 虚拟文件系统统一管理 Agent 的一切上下文——记忆、资源、技能——解决的是"上下文怎么组织、怎么省着往窗口里装"。

用一张图说清楚：

![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-12376604/ee2713f48a9b2a858567db95366a5428.png)


所以真正的同赛道对撞只有一场：**腾讯 TAM vs 字节 OV**的大厂 Agent Memory 之争。zg 与它们更多是互补——完全可以一个管找代码、一个管记事情，同时挂在 Agent 上。

下面逐个拆。

---

## 二、zvec-grep： 让 Agent 更会"找代码"

### 问题：Agent 的搜索账单

用过 Claude Code 或 Codex 的人都有体感：Agent 找代码靠的是连环 `grep → read → grep → read`。纯 grep 只能精确匹配，不知道哪个匹配更重要；语义检索能按意图找，但对函数名、常量名这类精确标识符又不可靠。更要命的是每一轮 read 都把大段源码塞进上下文——**Agent 应用的成本中心，早已经从模型调用转移到了上下文管理**。

zg 的主张很简单：一次调用、三路证据、结果带 `file：line` 定位和紧凑预览，直接砍掉后续的 read 轮次。

### 技术：三路路由 + 代码感知索引

zg 的查询面实际上有四条路由：`--hybrid`(默认，意图+词法锚点混合)、`--fts`(精确词项)、`--vector`(纯语义相似)、`--rg`(托管 ripgrep，穷举正则)。语义负责发现，词法锚定标识符，正则负责验证——各司其职，不迷信单一信号。

![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-12376604/547243d6b7f810b5238b17abf46d86df.png)


真正拉开差距的是**代码感知索引**。对 C/C++、Go、Java、JS/TS、Python、Rust 七门语言，zg 用结构化提取器索引"符号、签名、面包屑及周边源码"；Markdown 按标题分节；`.vue`/`.svelte` 抽取 script 块；对不同类型进行大小感知限制(代码 1 MiB、文本 256 MiB、结构化数据 16 MiB)。

索引放在项目根的 `.zvec-grep/` 里，零服务、零配置。嵌入模型默认是本地 32M 参数的 `potion-retrieval-32m`(model2vec 系)，也支持 llama.cpp 和 Transformers.js——**数据可以全程不出本机**，远程嵌入需要显式 opt-in。

### 底座：zvec 值得单独一提

zg 背后的 zvec(alibaba/zvec，约 16k stars)是阿里内部 battle-test 过的**进程内向量数据库**：C++ 核心，WAL 持久化，索引从内存到磁盘全谱系(HNSW、DiskANN、IVF-RaBitQ)，RaBitQ 量化在运行时按 CPU 自动分发 AVX2/AVX-512 路径。它继承了 SQLite 对 MySQL 的历史路线——**嵌入式对客户端-服务器**——进入了向量数据库时代。v0.7.0 起，zvec 官方将 zg 纳入生态，同时新增了 ReMe 集成做 agent memory。

### 数据：最硬的价值主张

官方基准 SWE-QA-Bench(挂载 Claude Code + Claude Opus 5，高推理档)上，zg 相比基线：**工具调用减少超过一半，输入 token 减少近一半，评审分还提升了 1.50**。另一个基准 BrowseComp-Plus(Codex，gpt-5.6-sol)上，在 98.67% 的基线准确率上进一步提升。

这些数字的聪明之处在于定位：zg 不试图让 Agent"更聪明"，而是**让同样的 Agent 花一半的钱跑完任务**——一种可测量、可复现的朴素价值。当然，官方也注明它最适合"证据分散多文件、目标位置未知"的问题；已知精确字符串时，直接 grep 依然更快。


---

## 三、TencentDB Agent Memory：团队的记忆中枢

### 理念：记忆是团队资产

TAM 的记忆观刻意宽泛："记忆 = 任何能帮助下一个 Agent 避免重新发明的信息"，不止于对话历史。它把一切蒸馏成四类资产：

1. **Chat Memory**——对话记忆，走 L0–L3 渐进蒸馏(下详)；
2. **Skill**——带版本的技能资产，附触发边界、执行步骤、校验规则，有完整的生命周期管理(版本化、乐观并发、归档)；
3. **Wiki**——Karpathy 式"LLM 维护的知识 artifact"，层级文档 + 链接图，而非切块 RAG；
4. **CodeGraph**——预索引的符号、调用关系、影响面图谱，能回答 callers/callees/impact 类查询——这是三件武器中唯一的代码结构分析能力。

这套资产模型直指一个真实痛点：团队的 AI 使用经验散落在每个人的会话历史里，人走了经验就没了。

### 架构：五模块与 L0–L3 蒸馏

TAM 由五个模块组成：MemoryProxy(透明代理，：8096)、MemoryCore(记忆引擎，：8420)、MemoryPanel(Web 治理面板，：8125)、MemoryKnowledge(离线 Wiki/CodeGraph 构建器)、以及可嵌入的 sdk。存储层支持 SQLite/Postgres + 向量库 + COS/Redis 五种后端组合。

记忆的核心是分层蒸馏管线：

| 层 | 内容 | 生成方式 |
|---|---|---|
| L0 Conversation | 原始对话，全量保留 | 直接采集(溯源用) |
| L1 Atom | 原子事实/偏好/约束/事件 | LLM 抽取，跨窗口去重 |
| L2 Scenario | 场景知识块 | L1 按团队/项目聚类归纳 |
| L3 Core/Persona | 长期稳定画像 | 稳态合并 |

整条管线**全异步**：队列 + 带退避的 worker，写入不阻塞主链路；结果受"条目数/字符预算/超时"三重护栏约束，防止记忆撑爆上下文。检索同样是分层的：常态用 L2/L3 快速引导，需要具体事实时回退到对 L1/L0 的 BM25 + 向量 + RRF 混合检索。

### 最精巧的设计：KV-cache 友好的注入

这是我认为整个 TAM 里最值得单独讲的工程细节。

MemoryProxy 是一个透明 LLM 代理：Agent(比如 Claude Code)只需把 `ANTHROPIC_BASE_URL` 指过去，**零代码改动**就获得记忆。请求流经八个阶段：鉴权 → 会话初始化(team→agent→task)→ 按 ACL 查资产 → 注入 → 限流 → 转发上游 → 异步抽取回写(L0 + Skill 候选)→ 上报可观测(Opik/Langfuse/ClickHouse)。

关键在注入策略：**L2/L3(稳定的画像和场景知识)注入 system prompt；L0/L1(逐轮变化的对话和事实)降级为只读工具，Agent 需要时再调**。

![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-12376604/85ff9dbe93db965aad17050e819cea86.png)


为什么这样切?因为如果每次都把新记忆拼进 system prompt，**上游的 KV-cache 前缀缓存就会逐轮失效，token 账单不降反升**——这是所有朴素记忆系统的隐藏成本，也是"记忆系统反而更贵"这一反直觉现象的根源。让易变内容走工具调用、让 system prompt 保持稳定，是对 LLM 服务端缓存机制的深刻理解。

### 治理：团队级卖点

可见性四级(private/team/restricted/agent)，绑定模型(Fixed Binding + Priority + Usage Mode：inject/reference/hint)，组合出 16 种 ACL 形态；角色体系(Owner/System Admin/Team Admin/Member)齐备。典型绑定：发布技能绑给发布 Agent，架构 Wiki 绑给全体开发 Agent，CodeGraph 绑给 coder + reviewer。

官方数据：PersonaMem 基准 48% → 76%(长期交互用户理解度，相对提升 59%)；官方实测长任务最高**省 61.38% token、通过率提升 51.52%**。

### 代价

学习曲线陡(16 种 ACL 组合)、部署重(3 服务 + DB，五选一的存储后端)、Wiki/CodeGraph 冷启动要等离线构建、蒸馏质量强依赖所配 LLM——这是一套需要认真规划的内部基础设施，不是装完就用的工具。

---

## 四、OpenViking：上下文即文件系统

### 定位：不是向量库，不是 RAG

OV 的自我划界非常清楚：它不是又一个向量数据库，也不是 RAG 框架，而是——"给 Agent 知道的一个文件系统"。针对三大痛点：上下文碎片化、检索效果差、不可观测。

### viking：//：可导航、可检查、可编辑

OV 把 Agent 的一切上下文组织成虚拟文件系统：

```
viking：//resources/                  # 项目文档、代码仓库、网页
viking：//user/{user_id}/memories/    # 偏好、经验(如 writing_style、coding_habits)
viking：//user/{user_id}/skills/      # 技能(如 search_code、analyze_data)
viking：//user/{user_id}/peers/       # 协作对象上下文
```

Agent 用最熟悉的文件原语访问：`ls`、`tree`、`read`、`write`、`grep`、`find`、`search`。

这个隐喻一次解决了四个问题：**组织**(目录结构天然分层)、**检索**(语义搜索可以按目录子树圈定范围，而非对平铺向量池全局搜)、**可观测**(人类可以直接 cat 检查 Agent"记了什么")、**人机协同**(直接用编辑器改)。对比"黑盒向量池 + 治理面板"的 TAM 路线，这是两种世界观：记忆到底是数据库里的资产，还是文件系统里的文档?

![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-12376604/0c26bdc5eb3f4a7c408bf66df0000045.png)


### L0/L1/L2：用计算换 token

OV 最出名的机制是分层加载。每个经语义处理的目录自动生成两份派生文件：

| 层 | 文件 | 内容 | 使用时机 |
|---|---|---|---|
| L0 | `.abstract.md` | 一句话摘要 | 快速判断相关性 |
| L1 | `.overview.md` | 核心信息 + 使用场景 | 规划阶段 |
| L2 | 原文 | 完整内容 | 确实需要时才加载 |

Agent 先读 L0 判断"要不要看"，再看 L1 决定"怎么用"，最后才拉 L2 全文。**摘要在写入时离线生成，加载时只付摘要的钱**——本质是用离线计算换在线 token，直接打击传统 RAG"检索回来一大段全塞进窗口"的浪费。配合目录递归检索(逐层浏览收窄范围)替代平铺检索，这套设计可在 ICDE 论文 TrieHI(目录感知向量查询)查看。

### 生态与数据

组件相当完整：openviking-server、`ov` CLI(npm + Rust 双版本，CLI 是 Apache-2.0)、Python/Go/TS SDK、Web Studio、桌面 App beta、VikingBot 框架、`ov compile` 编译知识图谱。Provider 支持 Volcengine/OpenAI/Kimi/GLM/Codex OAuth/本地 Ollama——**可以全本地**。集成面三者最广：Claude Code(Hooks + MCP 双通道)、Codex、Cursor、TRAE、OpenClaw、Hermes、OpenCode、DeerFlow、LangChain 等。学术侧有三篇论文压阵：VikingMem(VLDB 2026，事件驱动记忆)、TrieHI(ICDE)、VikingRAG。

基准(豆包 2.0 Pro VLM + Doubao-embedding-vision)：LoCoMo 上各集成准确率从原生的 24–57% 提升到 **80–83%**(如 OpenClaw 原生 24.20% → 82.08%)，输入 token **-34% ~ -91%**，延迟 -58% ~ -66%；tau2-bench 上任务成功率零售 +6.87pp、航空 +11.87pp。

### 代价

两个硬伤。其一，**AGPL-3.0**：主体协议的网络服务条款意味着闭源商用集成基本出局(除非采购火山引擎的 SaaS/BYOC 商业版，或只用 Apache-2.0 的 CLI 部分)。其二，对于非文本语料**硬依赖 VLM**(而非仅 embedding)：摘要生成质量决定 L0/L1 层的判断质量，若无法识别图片文件，摘要失真会级联误导整个分层加载体系，自托管成本也随之上浮。

---

## 五、正面对比：五个决定选型的维度

### 5.1 总览

| 维度 | zvec-grep | TAM | OpenViking |
|---|---|---|---|
| 层次 | 检索工具层 | 记忆服务层 | 上下文数据库层 |
| 数据模型 | 代码索引(可重建) | 四资产(Chat/Skill/Wiki/CodeGraph) | memories/resources/skills |
| 检索 | 三路混合 + fuse | 分层引导 + BM25/向量/RRF | 目录子树语义检索(TrieHI) |
| 部署 | 零服务(npm) | Docker 多服务 | Python server + 组件 |
| 模型依赖 | 仅嵌入(可 32M 本地) | LLM 必填 | embedding + VLM |
| 集成 | MCP 一键装 | **透明代理零改造** | 原生集成最广 |
| 团队协作 | 无 | **ACL + Panel** | 目录隔离，治理弱 |
| 许可证 | Apache-2.0 | **MIT** | **AGPL-3.0** |
| 主语言 | TS + Rust | Node.js | Python + Rust |

### 5.2 两种"L 分层"，本质不同

TAM 的 L0–L3 与 OV 的 L0–L2 常被混为一谈，其实是正交的两件事：TAM 分层的是**信息加工程度**(原始对话 → 原子事实 → 场景知识 → 画像，回答"检索时优先信哪层")；OV 分层的是**同一内容的投影**(摘要/概览/原文，回答"往窗口里装多少")。理论上完全可以组合——一个决定"记什么"，一个决定"取多少"。zg 没有分层，靠三路检索的排序融合达到类似的经济性。

![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-12376604/15bafcd919d790f9f35dd0ec7673d620.png)


### 5.3 检索哲学：平铺融合 vs 导航收窄

zg 和 TAM 走"混合检索 + 融合排序"路线，在平铺空间上多信号投票；OV 走"导航 + 限定"路线，先用目录结构收窄空间再做语义检索。工程直觉是：**代码和文档这类天然有目录语义的数据，OV 路线潜力更大；对话与事实类记忆，TAM 管线更自然。**有趣的是，zg 专注代码却仍是平铺索引——它用代码感知提取弥补了结构的缺失。

### 5.4 token 经济学：三种省钱机制

这是三家共同的第二战场，但机制完全不同：

- **zg 削减轮次**：一次调用三路证据，SWE-QA 上调用 -50%+、token ≈-50%；
- **TAM 保护缓存**：易变记忆降级为工具，system prompt 稳定，KV-cache 命中率不降；
- **OV 门控加载**：一切上下文过 L0/L1 摘要门，LoCoMo 上 token -34~91%。

三者不冲突，甚至可以叠加。

---

## 六、选型建议

按场景直接给结论：

- **个人开发者，想让 Claude Code/Cursor 更会找代码，数据不出本机** → **zg**。五分钟接入，token 直接省一半，Apache-2.0 无顾虑。
- **团队要多 Agent 共享记忆，要权限、审计，且不想改 Agent 一行代码** → **TAM**。透明代理改个 base URL 完事，MIT 许可商用无忧。
- **全资源上下文管理 + 极致 token 效率，且想直接读改 Agent 的记忆** → **OV**。纯 Markdown 的记忆体，人机协同治理最顺手。
- **商用闭源产品想嵌入记忆能力** → **TAM(MIT)**。AGPL 让 OV 基本出局，除非买商业授权。
- **代码结构影响面分析(callers/callees)** → **TAM 的 CodeGraph**，三家中独此一家。

而且这从来不是三选一。推荐的组合是：

![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-12376604/f836a3376dcb7dc9dad7df88096cfdaa.png)


zg 与 OV/TAM 无任何架构冲突：一个优化"检索便宜"，一个优化"记忆持久"。TAM 的 CodeGraph 与 zg 也能共存——结构查询与语义发现，互补而非替代。

想低成本验证的话：zg 在任一真实仓库 `npm i -g @zvec/zvec-grep && zg index`，跑三个日常查询就有手感；OV `pip install openviking` 后重点看 L0/L1 摘要质量(它决定一切)；TAM 起 Docker 栈、Claude Code 指过去，跑一周看"记性"和账单的变化。

---

## 参考

- zvec-grep：https：//github.com/zvec-ai/zvec-grep
- zvec 底座：https：//github.com/alibaba/zvec
- TencentDB Agent Memory：https：//github.com/TencentCloud/TencentDB-Agent-Memory
- OpenViking：https：//github.com/volcengine/OpenViking · https：//openviking.ai
- 腾讯云官方开源公告：cloud.tencent.com/developer/article/2668579
- zg 开源公告(知乎/ModelScope/CSDN，2026-09-01)；TAM 架构深度解析(xuqi2024.github.io，2026-08-15)；OpenViking 解析(most.tw、blog.xlap.top、CSDN，2026-08~09)

一、先澄清一点：它们不是同类竞品 打开这三个项目的 README，你会看到三个看似相似的关键词：检索、记忆、上下文。但如果只看词就下结论，选型必然出错。三者的真实位置是这样的： zvec-grep(命令名 zg，zvec-ai 出品，底座是阿里开源的嵌入式向量库 zvec)是一个本地优先的混合代码搜索引擎。它把 ripgrep 式正则搜索、BM25 词法排序和向量语义检索合并进一个命令，解决的是"

Agent 的记忆之争：阿里、腾讯、字节方案的深度对比

人工智能

云计算

架构设计

zvec-grep、TencentDB Agent Memory（TAM）与OpenViking并非同类竞品：zg专注本地代码混合搜索，TAM是团队记忆中枢，OV则提供上下文文件系统。三者在检索、token节省及部署上各有优劣，可互补组合使用。选型取决于场景：个人开发者选zg，团队协作选TAM，全资源管理选OV。

结构化数据

向量数据库

文件系统

知识图谱

数据库

服务器

路由

SQLite

Python

OAuth

Redis

Agent

MySQL

SaaS

Java

2026上云采购 | AI焕新·智启新局

对象存储COS新用户低至1元！


tchousec

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Agent 的记忆之争：阿里、腾讯、字节方案的深度对比-腾讯云开发者社区-腾讯云

Agent 的记忆之争：阿里、腾讯、字节方案的深度对比

Agent 的记忆之争：阿里、腾讯、字节方案的深度对比

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐