引言

对多数技术团队来说，代码固然重要，但更难复制的，是沉淀在里面的经验：一个需求当初为什么这么定，某个模块踩过哪些坑，一次线上故障是怎么定位又怎么恢复的。可这些经验大多散落在钉钉文档、代码评审记录里、群聊里，甚至只存在于资深员工的记忆中，始终缺一个能持续沉淀、随时调用的地方。于是同一个问题，一个人解决过，换个人还得重新摸索，同一个坑被不同的人反复踩。

过去一年，Coding Agent 的普及让这个老问题更加突出。Claude Code、Codex、Qoder、OpenCode 等工具在写代码、做重构、定位缺陷上都表现出色，却大多只活在当下这次会话里，会话一关，讨论过的需求、做出的决策、定下的约定便随之丢失。Agent 帮团队干了不少活，却几乎没给团队留下什么可以复用的积累。归根结底，这些工具不缺写代码的能力，缺的是把每一次经验沉淀成可复用知识的能力。

针对这个问题，阿里云 RDS 推出了 ContextDB 能力。它是一款面向 Agent 的企业级上下文数据库服务（Context Database Service），设计思路和传统数据库有所不同：传统存储关注的是把数据静态地保存下来，而 ContextDB 关注的是如何为 Agent 供给一份结构化、可直接使用的上下文。文本、图片、音频、视频都可以存入，取出时不再是原始数据的堆砌，而是 Agent 能读懂、可直接使用的信息。

不过，要真正理解 ContextDB 为什么这么设计，还得先回到 Agent 落地时遇到的具体问题。

01 Agent 为什么需要一个专门的上下文数据库

拿 AI Coding 这个场景来说，团队用 Coding Agent 时，通常会碰到三类麻烦。

• 一是知识分散。业务知识散落在钉钉文档、PRD、技术方案、代码评审记录里，有些仅存于资深员工的记忆中。缺少统一的沉淀之处，新人只能从零摸索，Agent 同样无从获取。
  
• 二是知识库难维护。传统知识库依靠人工建设和更新，建设成本高，建成后又往往缺乏维护，很快便会过时。归根结底，纯靠人力长期维护的知识库很难持续运转。
  
• 三是 Agent 记不住上下文。会话一旦中断，此前的对话、决策过程和任务进度全部丢失，导致错误反复出现、经验难以积累。
  

目前常见的做法是 RAG，每次对话都重新检索文档、拼接上下文，用完即弃。这种方式每次都相当于从零推导：Agent 不会因为用过一次文档，下次就更理解业务，依旧是检索、拼接、遗忘的循环。

RDS ContextDB 要解决的正是这一点。它的重点不在于把数据存下来，而在于让上下文自动流转、让知识持续积累。使用越多，Agent 对业务的理解越深，不会始终停留在初始状态。

02 五大能力，串起从数据接入到 Agent 消费的完整链路

RDS ContextDB 主要提供五块能力：上下文管理、长期记忆、知识管理、智能检索、共享与治理。这五块能力连起来，覆盖了数据接入、结构化处理、语义检索到 Agent 消费的整个链路。

这里面有个关键的设计思路：从上下文到记忆是自动的，从记忆到知识是可控的。记忆属于个体，由 Agent 在交互过程中自己积累；知识属于组织，需要经过 AI 推荐、人工确认才能沉淀下来。中间的流转遵循一个简单原则，AI 负责筛选、人负责拍板。这样既能让记忆自然生长，也能把住企业知识的质量关。

03 长期记忆：从原子事实到记忆图谱

长期记忆是 RDS ContextDB 最核心的能力之一。它把每一次交互沉淀下来，靠的是三层结构化存储。

最底层是原子性事实。系统会把上下文拆成一条条能独立成立的短句，向量化后作为主要的检索对象，召回时主要在这一层做语义命中，同时支持手动更新记忆。往上一层是记忆实体，即 Entity Card。反复出现的人、组织、项目、工具会被沉淀成一张常驻画像，带有属性、别名、重要性评分，并与后续写入的结论相关联，会话重启时无需再从头交代背景。最上层是记忆图谱，以图谱形式组织和展示记忆之间的关联，便于进行更复杂的关联推理。

这些记忆并非存入后就固定不变，而会随着使用不断演进。系统设有相似度阈值：语义相近的记忆会提升置信度，实现去重；语义相反的会触发更新，消解冲突；再结合时间权重和召回次数计算置信度，长期不用的记忆逐渐衰减，重要记忆则由 Entity Card 保留。

但长期记忆只是基础，ContextDB 的价值不止于此，它更进一步解决了个人经验如何沉淀为组织知识的问题。

04 知识管理：把个人经验沉淀成组织的知识资产

长期记忆解决的是单个 Agent 越用越懂你，知识管理要解决的，则是怎么把个人经验变成整个团队都能用的资产。记忆和知识的边界也在这儿：记忆是个人的，是 Agent 在交互里自己攒下来的；知识是组织的，是团队认可、可以共享和治理的。

要让知识真正沉淀、并长期可用，一套知识系统必须回答四个问题：知识怎么进来、怎么把关、怎么保鲜、怎么被用上，分别对应知识的启动、准入、演进与分发。RDS ContextDB 把这四步都做进了产品里。

先看知识怎么启动，也就是让知识进得来。分为热启动和冷启动两条路。

• 热启动面向已经有沉淀的团队：ContextDB 的 sync 工具支持热同步钉钉文档、飞书文档和本地目录，也支持通过 Skill 一键上传，已有资料几乎无需搬运即可入库；它对文件本身的处理也做得很重，支持多模态、单个文件可达 GB 级，并针对 PPT、表格、带图 PDF、带图片链接的 Markdown 等常见格式做了加强解析，尽量不丢失原始信息。
  
• 冷启动则面向还没有成型文档的团队：ContextDB 能从 Agent 日常积累的记忆里蒸馏出知识，以文档的形式沉淀进知识库，让知识库从零长出来。
  

再看知识怎么准入。知识不是进来就算数，质量得先过关，否则低质内容反而会污染知识库。

• 对上传的文档，ContextDB 提供知识评审能力，先分析文档质量，必要时进行重写，去掉噪音、理顺逻辑，而不是原样堆进去。
  
• 对从记忆蒸馏出来的知识，则由人来做卡点，AI 生成候选文档，审核人判断是否准确、是否适合作为团队规范、哪些该沉淀、哪些不宜收录，确认后才正式入库。这正是 ContextDB 一以贯之的原则，AI 负责筛选和整理，人负责最终决策。
  

接着是知识怎么演进，也就是入库之后如何不腐化。

• 一方面，对新上传的文档，ContextDB 会校验它与知识库内已有知识是否冲突，把矛盾点标出来交由人判断，而不是静默覆盖或同时留下两份。
  
• 另一方面，ContextDB 以图谱来构建整个知识体系，入库时从内容中提取实体、关系和事实并组织成图谱，检索时不仅能做语义匹配，还能顺着实体关系做关联推理，系统也会持续处理图谱内部的矛盾与冗余，让知识体系保持自洽。在此之上，还有企业级的治理能力作为保障：可按组织边界和权限组控制共享范围，变更走审核流程，操作留有审计记录，并支持完整的生命周期管理。
  

这套从启动、准入到演进的机制，最终要落到知识库的实战效果上。我们选取金融投资、高等教育、学术研究、Wikipedia 百科四个公开评测集（FinanceBench、SyllabusQA、Qasper、ClapNQ），在同一大模型下，把 ContextDB 与 PageIndex、HippoRAG 2、LightRAG、OpenViking 等主流方案做了横向对比，准确率上，ContextDB 以 79.32% 排名第一。

更值得关注的是成本和延迟——这两项也是团队真正上生产时最在意的指标。成本方面，ContextDB 达到最高准确率的同时，单次问答的 Token 消耗约为 LightRAG 的三分之一，而 PageIndex 这类方案动辄要三万 Token，规模化部署下推理成本相差悬殊。延迟方面，ContextDB 的检索耗时为 1.64 秒，比准确率最接近的 LightRAG（1.96 秒）更快。

平均值之外，分场景的表现更能看出差距。ContextDB 在四个场景的准确率全部排在第一；而不少方案换个场景就明显失准，而 ContextDB 四类场景表现均衡，没有明显短板。

最后一步是知识怎么分发，把沉淀好的知识真正交到 Agent 手里。这一步靠的是足够低的接入门槛：一键接入各类主流 Agent，也正是下一节要讲的内容。

05 一条命令接入，几分钟对接完成

能力再强，接入门槛过高也难以落地。

RDS ContextDB 采用 Skill 加 CLI 的接入方式，几分钟即可对接 Claude Code、Codex、Qoder、OpenCode、OpenClaw 等主流 Coding Agent，业务代码基本无需改动。已经使用 Mem0 的团队迁移也很简便，ContextDB 兼容其协议，只需切换 endpoint，代码几乎不动，而记忆准确率可从 20% 出头提升至 78% 的量级。

以Qoder为例，执行下方一条命令即可接入：

curl -fsSL 'https://context-database-client.oss-cn-hangzhou.aliyuncs.com/install.sh' | bash -s -- --agent qoder --api-key <api-key>

然后重启Qoder即可生效。

06 典型落地场景

前面讲的是能力和接入，落到真实业务里，RDS ContextDB 最常见的用法可以归为三类：

• 长周期工程里的知识沉淀。
  研发项目周期长，需求决策、模块约定、改造规范散落在 Agent 对话和代码 Review 里。接入 ContextDB 后，开发者发起记忆晋升，系统聚合相关记忆生成结构化文档，审核入库后团队 Agent 都能召回。原本散落的个人经验，就此变成团队可复用的规范。
  
• Coding Agent 对接企业业务知识库，也就是把 Coding 做成一种服务。
  Agent 不清楚企业私有的业务模型和历史积累，开发者每次都得手动贴上下文，同类问题反复出现。把内部 API 文档、领域模型、架构决策记录传进知识库，Agent 写代码时自动检索业务上下文，新人第一行代码就站在团队积累之上，输出从“通用正确”变为“贴合业务”。
  
• 知识密集型的运维与技术支持。
  运维经验大量沉淀在历史工单和聊天截图里，格式乱、噪音多。ContextDB 借助多模态能力直接识别截图内容，通过知识评审把高噪音材料提炼成高质量文档，处理新问题时检索相似工单辅助定位。资深经验不再锁在少数人脑中，而是成为团队可反复调用的资产。
  

结语

从 RAG 时代用完即弃的检索，到现在能沉淀、能复用的上下文供给，Agent 的存储方式正在发生变化。RDS ContextDB 让每一次交互都沉淀下来，把有价值的个人经验持续晋升为团队共享的知识资产。同一个坑，团队的 Agent 就不用再踩第二遍。

目前 RDS ContextDB 已经启动公测，公测期间可免费使用。

点击https://help.aliyun.com/zh/rds/apsaradb-rds-for-mysql/rds-contextdb-quick-start 可了解更多。

也可用钉钉扫描如下二维码，加入「RDS ContextDB技术交流群」。