做 Agent 记忆方案选型时，准确率、成本、延迟——这三个指标之间的取舍，比想象中复杂。
三个指标的取舍
做过 RAG 方案选型的人都知道一个现实：准确率、成本、延迟，这三个指标你很难同时优化到一个理想状态。
想要高准确率？通常意味着更复杂的检索策略、更多的上下文注入，Token 成本直线上升。想要低成本？那就得精简上下文，但准确率随之下降。想要低延迟？检索链路必须短，但短了就容易漏掉关键信息。
我们做 ContextDB 的时候，就是冲着同时优化这三个指标去的。做之前说实话心里没底——这三个东西互相牵制，能不能做到，做到什么程度，只能靠数据说话。
我们测下来的数据
直接看在 LOCOMO 基准测试上的结果：
准确率：我们测下来在 79% 左右
在 Agent 记忆和检索场景下，准确率很关键。一条错误的记忆可能导致 Agent 生成完全偏离需求的代码，一个错误的检索结果可能让 Agent 做出错误的决策。
我们测到的准确率是 79.32%。作为对比，业界常用的 LightRAG 方案大约在 65% 左右，差了大概 14 个百分点。实际使用中这意味着每 10 次检索能多对 1-2 次。对于高频使用的 Agent，这个差异会累积。
不过要说明，准确率这个指标和测试集的选择关系很大。LOCOMO 侧重的是长期对话中的记忆和检索，和纯代码生成场景还是有差距的。
Token 成本：大概是 LightRAG 的三分之一
这个指标我自己比较看重。
传统 RAG 方案为了提升准确率，往往会"大水漫灌"——把尽可能多的相关文档都塞进上下文，Token 消耗量很高。
我们的三层记忆架构（原子事实 → 记忆实体 → 记忆图谱）让 Agent 不需要获取一堆原始文档片段，而是直接获取结构化的、聚合好的知识实体。同样的任务，Token 消耗大概只有 LightRAG 的三分之一。
按日均 1000 次检索来算，一年下来节省的 Token 成本还是比较可观的。不过这个倍数关系在不同使用模式下会有波动，重度使用场景下差距会更明显一些。
检索延迟：1.64 秒
在 Coding Agent 的使用场景下，1.64 秒的检索延迟可以接受。开发者在等 Agent 生成代码时，本身就有几秒钟的等待预期。我们的检索在这个时间窗口内完成，不会拖慢体感。
但如果是对延迟特别敏感的场景（比如实时对话机器人），这个数字可能就不够了。这一点我们没有特别去优化。
跨数据集稳定性
我们在四个不同领域的基准数据集上做了测试：
| 数据集 | 领域 |
| FinanceBench | 金融 |
| SyllabusQA | 教育 |
| Qasper | 学术论文 |
| ClapNQ | 开放域问答 |
四个数据集上表现都比较稳定，没有出现某个领域特别好、某个领域特别差的情况。至少说明不是针对某个特定领域做了 overfitting。
Mem0 兼容迁移的一个意外发现
很多团队已经在用 Mem0 做 Agent 记忆。我们专门测了一下兼容迁移场景：
- 保持 Mem0 协议不变
- 仅将 endpoint 切换过来
- 其他配置不做任何修改
结果准确率从 20% 到了 78%。
说实话这个提升幅度我们自己也有点意外。同样的记忆条目，底层怎么存、怎么索引、怎么检索——这些"基础设施"层面的差异能带来这么大的效果差距，说明记忆管理这个环节的质量确实被低估了。
当然，20% 这个基线数字低得有点出乎意料。可能是我们的测试集和 Mem0 的默认配置之间有什么不匹配的地方，不排除换一套配置 Mem0 的表现会更好。这个数据仅供参考。
对于已经在用 Mem0 的团队来说，至少协议兼容这一点降低了迁移门槛：
# 只需要修改 endpoint 配置，协议完全兼容 curl -fsSL 'https://context-database-client.oss-cn-hangzhou.aliyuncs.com/install.sh' | bash -s -- --agent <agent> --api-key <api-key>
目前支持的 Agent 包括：Qoder、Claude Code、Codex、OpenClaw、OpenCode、Hermes、QoderWork。
架构上为什么能做到
准确率高、成本低、延迟可接受——怎么做到的？关键在架构设计。
传统 RAG 的问题
传统 RAG 的典型流程是：
用户提问 → Embedding → 向量检索 Top-K → 全部塞进上下文 → LLM 生成
这个流程有几个问题：
- Top-K 检索是"暴力"的——不管相关信息有多少，一律取 K 条。K 设大了，Token 浪费；K 设小了，信息不全。
- 检索结果是"原始片段"——一段文档、一段代码。LLM 需要自己从中提取关键信息，增加了推理负担。
- 没有知识的结构化组织——所有信息都是扁平的，无法进行关联推理。
我们的三层架构
我们的做法不同：
用户提问 → 意图识别 → 图谱遍历 → 精准定位实体 → 聚合相关知识 → 注入上下文 → LLM 生成
原子事实（Atomic Fact）。 从每次交互中提取最小知识单元，每条带置信度和时间戳。不是存原始文本，而是提炼出"事实"。
记忆实体（Entity Card）。 相关的原子事实聚合为实体。比如"项目技术栈"这个实体，聚合了框架、语言、数据库等多条事实。Agent 获取的不是零散的文档片段，而是完整的实体画像。
记忆图谱（Memory Graph）。 实体之间建立关联，形成知识网络。检索时不仅获取目标实体，还能沿着图谱获取关联知识。
这种架构定位更精准——通过图谱遍历而非暴力 Top-K；注入的是结构化的知识实体而非原始文本片段；Token 消耗也更少。
知识生命周期管理也在帮忙
除了检索架构，知识生命周期管理也在帮忙降成本：
- 自动去重：相似的知识条目自动合并，避免冗余
- 冲突消解：矛盾的信息自动消解，减少噪音
- 置信度衰减：过时的信息置信度自动降低，不会被优先检索
这些机制保证了知识库的"信噪比"始终维持在较高水平，避免了传统 RAG 中"知识库越大、噪音越多"的问题。
知识治理：AI 筛选 + 人工拍板
最后说一个设计上的选择。
很多 Agent Memory 方案采用"全量自动入库"策略——Agent 产生的所有信息都自动存入记忆。这种做法看似省事，但记忆库会快速膨胀，充斥着噪音和低质量信息。
我们选了另一条路：AI 筛选 + 人工拍板。
- AI 先对候选知识做初步筛选，过滤明显的噪音和重复信息
- 对于高价值知识，可以设置人工评审流程，由人来决定是否正式入库
- 记忆可以"晋升"为知识——经过验证的记忆条目，可以升级为正式的项目知识
Agent 的记忆直接影响它的行为。让 AI 独自决定"记住什么"，我觉得风险太大。"AI 做初筛、人做终审"的模式，虽然牺牲了一些自动化程度，但在准确性上更可控。
当然这也意味着需要人参与——对于人手紧张的小团队来说，这个额外的人工环节是个需要考虑的成本。
回到开头的取舍
回到开头的问题：准确率、成本、延迟能不能同时优化？
我们的体会是：通过更好的架构设计，三个指标确实可以同时改善，但不是无限的。比如我们的检索延迟 1.64 秒在 Coding Agent 场景够用，但如果要做到百毫秒级，架构可能需要大改。再比如 79% 的准确率在大多数场景够用，但对于安全敏感的场景（比如医疗、金融合规），可能还差得远。
这不是一个"已经解决了"的问题，更像是一个"我们找到了一个比之前更好的平衡点"。Agent 的上下文管理是一个很大的领域，我们才刚开始做，还有很多要验证的东西。
如果你正在做 Agent 记忆和知识管理的方案选型，可以把 ContextDB 作为一个参考选项。一条命令接入，用数据说话。
参考链接
