前言
最近阿里云在 Agent 开发中提出了一个概念：Agent Wiki / Agentic 知识库。很多同学第一反应是："这又是一个新的存储引擎？要取代向量数据库了？"
并不是。
它并不是要"杀掉"向量数据库，而是给出了一套让 AI Agent 更聪明地使用多种存储的方法论和实践架构。本文将从传统 RAG 的痛点出发，渐进式地讲解 Agentic 知识库到底是什么、它解决了什么问题，以及它是如何把 MD、向量数据库、图数据库、Wiki 有机融合在一起的。
一、传统 RAG 知识库：临时检索，孤岛严重
我们最熟悉的 RAG（Retrieval-Augmented Generation）知识库，通常长这样：
- 上传一堆文档（PDF、Word、MD）
- 切块 → 向量化 → 存入向量数据库
- 用户提问 → 向量检索 Top-K → 拼接 Prompt → LLM 生成
这种模式存在几个硬伤：
| 痛点 | 表现 |
|---|---|
| 知识碎片化 | 每个文本块是孤立的，无法体现概念之间的关联 |
| 语义"似而非" | 向量检索找的是"意思相近"，但可能逻辑矛盾或张冠李戴 |
| 无法处理复杂关系 | 问"A 依赖 B，B 依赖 C，A 依赖谁？"这种多跳问题，向量检索几乎失效 |
| 没有知识沉淀 | 每次问答都是从头检索，不会把交互中的新知识记下来 |
于是，Agentic 知识库 应运而生。
二、Agentic 知识库的核心思想：多模态存储 + Agent 自主路由
Agentic 知识库不是一个单一的存储系统，而是一个 让 Agent 学会"根据问题类型，动态选择最合适的存储" 的智能架构。
它内部同时维护多种存储，各司其职：
| 存储类型 | 扮演角色 | 适合解决什么问题 |
|---|---|---|
| Markdown / Wiki | 编译后的核心知识库 | 权威定义、经过验证的知识、Agent 的"长期记忆" |
| 向量数据库 | 语义搜索引擎 | "是什么"、"怎么做"等开放性问题 |
| 图数据库 | 实体关系网络 | 多跳关系查询（依赖、归属、关联） |
| 文档原文 | 溯源备份 | 必要时回溯原文，防止 LLM 幻觉 |
关键点 ：Agent 会像一个聪明的图书管理员，接到问题后先做"任务规划"，然后去正确的书架取书，甚至能把不同书架上的信息融合起来。
三、为什么不是"替代"而是"互补"？
因为没有任何一种存储能解决所有问题。
- 图数据库 擅长精确关系，但不擅长开放语义联想。
- 向量数据库 擅长模糊匹配，但回答"张三负责哪个模块"这种精确实体问题时，可能召回一堆不相关的结果。
- Wiki/MD 适合存静态、高质量的知识，但无法实时更新动态依赖关系。
举个例子：
用户问："小李在 xx 项目里负责的前端模块，有没有依赖老张的日志服务？"
- 只用图数据库 → 能查出"小李 → 模块A"、"模块A → 日志服务"这些关系，但拿不到"日志服务怎么用"的具体文档内容。
- 只用向量数据库 → 可能搜到其他项目里叫"小李"的人，或者搜到一堆和"日志"相关但与本项目无关的片段。
- Agentic 方案 ：
先用图数据库理清实体关系链，再用向量数据库从技术文档中检索"日志服务"的具体配置与用法，最后把两者整合成一段既有逻辑骨架又有丰满细节的回答。
这就是互补------1+1>2。
四、怎么实现？------一个简化的代码例子
下面用伪代码/逻辑示例，展示 Agentic 知识库如何协调三种存储。
4.1 数据摄入阶段
python
# 初始化三种存储
wiki_store = MarkdownWikiStore("./core_wiki/") # 核心编译知识
vector_db = DashVectorCollection("my_kb") # 向量检索
graph_db = Neo4jGraphDB("bolt://localhost:7687") # 图谱关系
def ingest_document(file_path):
chunks = split_document(file_path)
# 1. 写入向量库（语义检索）
embeddings = embed(chunks)
vector_db.insert(chunks, embeddings)
# 2. 抽取实体关系，写入图库
triples = extract_entities_relations(chunks)
for sub, pred, obj in triples:
graph_db.create_relationship(sub, pred, obj)
# 3. 编译核心知识，写入 Wiki
compiled = agent_compile_to_wiki(chunks, vector_db, graph_db)
wiki_store.save(file_path + ".compiled.md", compiled)4.2 问答阶段：多路检索 + 融合
python
def ask_agent(question):
# Agent 规划：该用什么存储？
plan = agent_plan(question) # 可能同时返回 graph / vector / wiki
contexts = []
if plan.use_vector:
contexts += vector_db.search(question, top_k=5)
if plan.use_graph:
contexts += graph_db.query_related(question)
if plan.use_wiki:
contexts += wiki_store.find_relevant(question)
# 反思：信息够了吗？
if not enough(contexts, question):
contexts += agent_retry_optimized(question)
return llm_generate(question, contexts)注意：
agent_plan可以是一个小型的 LLM 调用，也可以是一个经过微调的路由分类器。
4.3 知识回写：自进化
python
# 用户纠正了 Agent
user_correction = "不对，GraphRAG 是向量 + 图索引，不是取代向量库。"
def update_knowledge(correction):
# 1. 分析修正内容
# 2. 更新核心 Wiki
wiki_store.update("concepts/GraphRAG.md", correction)
# 3. 同步更新图谱
graph_db.update_entity("GraphRAG", description = "vector + graph index")
# 4. 重新向量化（可选）
vector_db.upsert(embed(correction), id="graphrag_def")这样就形成了一个闭环：摄入 → 检索 → 反思 → 回写 → 进化。
五、阿里云的具体落地
这套思想在阿里云已经有实际产品支撑：
- AnalyticDB PostgreSQL 版（及AgenticDB）：原生支持向量 + 图混合存储，一个库搞定多模态。
- 百炼平台（Agentic 知识库服务）：提供从文档解析到图谱构建再到 Agent 编排的一站式方案。
- Spring AI Alibaba + DTS RAGFlow：方便 Java 开发者集成。
你不需要自己去搭 Neo4j + Milvus + MinIO，云服务已经把它们整合好了。
六、总结
| 维度 | 传统 RAG 知识库 | Agentic 知识库 |
|---|---|---|
| 存储 | 单一向量库 | MD + 向量库 + 图库 + Wiki，各司其职 |
| 检索 | 一次性语义检索 | 多步规划 + 路由 + 融合 |
| 推理 | 不支持多跳 | 图谱支持多跳，向量提供语义 |
| 进化 | 静态 | 可回写、自更新 |
| 定位 | 临时"记忆插件" | Agent 的"长期知识中枢" |
一句话总结 ：Agentic 知识库不是要干掉向量数据库，而是让 Agent 学会什么时候用向量、什么时候用图、什么时候翻Wiki 。它是一个多存储协同的认知架构，而非单一的存储引擎。
如果你正在开发企业级 Agent 应用，不妨从"多模态存储 + 自动路由"这个角度重新思考你的知识底座。
本文部分概念受阿里云百炼及 Agentic RAG 相关论文启发，代码为示意性伪代码，实际生产请参考对应云产品 SDK。
希望这篇博客能帮你理清 Agentic 知识库的真实面貌。欢迎评论区讨论交流！