📑 本文目录
从"只会存储"到"有反哺有学习"：AI Agent知识库架构升级全记录
背景：一个尖锐的问题
“我的知识库是否会将 AI Agent 获取到的所有内容都存入？存储后的知识是否会在之后的使用中得到充分利用？”
这是一个简单但致命的问题。在检查了自己的 Hermes Agent 知识库后，答案令人不安：
| 数据源 | 实际情况 |
|---|---|
| web_search（2324 次调用） | 结果仅存在 SQLite 里，用完就丢 |
| web_extract（460 次调用） | 同上，零持久化 |
| 博客文章（108 篇） | 在 wiki 里有 545 个镜像文件，纯垃圾副本 |
| 会话记录（1446 个 session） | 只有周日手动采集，覆盖率极低 |
更严重的是”存了不用”：Wiki 有 659 页知识，但 Agent 回答问题时从不主动查询——除非用户手动让 Agent 加载某个 skill。
这不是知识库，是一个墓地。
诊断：三层断裂
分析后发现知识流的三层全断了：
输入层: web搜索 → 丢弃 | 会话 → 仅周末采集 | 研报 → 只存PDF无摘要
存储层: 94页假索引(实际1257文件) | 0条wikilink边 | 0%向量覆盖
复用层: Agent不主动查Wiki | 无前置检索 | 无跨语言匹配三层中每一层都有断裂——输入不沉淀、存储无索引、复用不触发。
理论基础：三篇论文的核心思想
升级方案不是凭空设计，而是借鉴了 2025-2026 年三个前沿模式的精华：
1. Karpathy LLM Wiki — Query Synthesis
Andrej Karpathy 的个人 Wiki 有一个核心设计：Sources 只读，Wiki 可写。每次问答自身沉淀成独立页面。知识不是静态文档，而是持续生长的问答库。
2. Cognee ECL — Extract-Cognify-Load
Cognee 框架的核心理念：知识库不是直接存储原始内容，而是经过”认知化”（Cognify）处理——实体抽取、关系建图、向量化——形成多层派生结构。
3. A-Mem（NeurIPS 2025）— Memory Evolution
A-Mem 论文的关键贡献：每条新记忆入库前，先扫描相似旧记忆，由 LLM 决策是新建、合并还是覆盖。避免碎片化——同一个知识点被写 5 遍、每篇只对一半。
实施：7 层升级
升级 1：反向链接图索引（Cognee ECL 简化版）
问题：Wiki 有 659 页但零结构化索引。Agent 无法知道”可转债策略”和”风控过滤器”之间有没有关联。
方案：扫描所有 [[wikilink]]，建立 SQLite 图数据库。
pages(path, title, type, domain, tags, ref_count)
edges(src, dst, kind) -- kind: wikilink | tag | type | domain效果：
| 指标 | 修复前 | 修复后 |
|---|---|---|
| wikilink 边数 | 0 | 1036 |
| 可查询页面 | 0 | 206 |
| 孤立页发现能力 | 无 | 即时发现 432 个 |
意外收获：修了一个 bug——根目录的 log.md、index.md 等枢纽文件没被扫描，导致大量 wikilink 丢失。修复后 wikilink 从 747 跳到 1325（+78%）。
升级 2：Query Synthesis Pipeline
问题：高价值会话只存在 SQLite 里，用完就忘。
方案：每日 9 点自动扫描最近 24h 最有信息密度的 3 个会话，调 DeepSeek REST API 合成结构化 Q&A 页。
每页包含：问题陈述、核心结论、关键数据、代码摘要、相关 wikilink、遗留问题。
成本：直接调 REST API（而非启动 LLM agent），每次合成成本约为 agent 模式的 1/10。
升级 3：Memory Evolution（A-Mem 精髓）
问题：新页面入库时不检查是否与旧页重复——5 篇讲同一件事、每篇只对一半。
方案：新页写入前先做三步判定：
- Token 相似度找 top-5 候选旧页
- LLM 判定：NEW（新主题）/ MERGE（追加到旧页）/ UPDATE（覆盖旧页）
- 执行：NEW 写新文件，MERGE 追加增量段落，UPDATE 归档旧版到
.history/后覆盖
实测验证：
- 输入”S05 可转债策略 2026-07 参数调整” → LLM 精准判定 UPDATE，指向
entities/可转债低价轮动.md（而不是简单选 token 重合率最高的候选） - 输入”量子随机游走组合优化” → 判定 NEW（与已有组合优化页相似度低）
补漏 1：Web 内容自动沉淀
问题：2784 次 web_search/web_extract 调用，结果全部丢弃。
方案：每日凌晨 2:30 扫描 SQLite 里的 web_extract 工具调用记录，把有效抓取（大于 2KB、非 blocked）按域名分组存到 raw/web/。
回捞效果：首次运行回捞 39 页历史数据（516KB），涵盖东方财富研报、GitHub README、知乎专栏等。
升级流水线：raw/web 里的原始网页不是终点。每周 promote_raw.py 让 LLM 逐页判断：值得提炼的生成 200-500 字知识摘要升级到 concepts/，低价值的标记跳过。实测前 5 页全是 AI 新闻日报，LLM 正确判定为”纯新闻聚合”全部跳过。
补漏 2：对话前置检索
问题：Agent 回答问题前不查 Wiki——除非用户主动让 Agent 加载 skill。
方案：两层设计：
第一层 — Memory 入口：在 MEMORY.md 里注入一条指引，每次对话自动加载到 system prompt：
Wiki 主动检索入口：分析/决策/回忆类问题回答前先用
wiki_probe.py "关键词"探针判断是否值得深挖。
第二层 — 毫秒级探针：wiki_probe.py 只查图数据库的 title/tags 字段，80ms 返回 top-5 相关页。得分高就深读，得分低直接答。
升级 4：向量检索
问题：Token 重合率搜不到跨语言内容——“funding rate”找不到”资金费率”页。
方案：用 paraphrase-multilingual-MiniLM-L12-v2（384 维）预计算所有页面 embedding 存入 SQLite。wiki_probe 加 --semantic 选项。
跨语言验证：
| 查询（英文） | 命中（中文 Wiki 页） | 余弦相似度 |
|---|---|---|
| convertible bond | 可转债低价轮动策略(S05) | 0.58 |
| funding rate | 资金流向择时模型 | 0.51 |
升级 5：信噪比治理
问题：全库 648 页中 282 页是 IMA 外部文章镜像、160 页是研究笔记归档——全是 ref_count=0 的孤岛，拉低检索质量。
方案：将 55_外部知识库/ 和 53_量化系统/ 排除出图索引扫描范围（文件保留不删，偶发参考时仍可 grep）。同时删除 82 个自动生成的重复页（中文+英文 skill category 双份）+ 3 个过时快照页。
效果：精炼知识库从 648 → 206 页，核心层孤立率从 32.2% 降到 1.1%。
最终架构
┌─────────────────────────────────────────────────────────────┐
│ 输入层（持续沉淀） │
│ │
│ 用户对话 ──→ state.db │
│ │ │ │
│ │ 每日 09:00 │ 每日 02:30 │
│ │ Query Synthesis │ Web Harvest │
│ │ (DeepSeek API) │ (SQLite→raw/web/) │
│ ↓ ↓ │
│ queries/ raw/web/ │
│ (结构化Q&A) (原始网页) │
│ │ │ │
│ │ Memory Evolution │ 每周 promote_raw.py │
│ │ (A-Mem判定) │ (LLM提炼→concepts/) │
│ ↓ ↓ │
├─────────────────────────────────────────────────────────────┤
│ 存储层（多层派生） │
│ │
│ Sources (只读) Wiki (可写) │
│ ┌──────────┐ ┌──────────────┐ │
│ │ raw/web/ │ │ entities/ │ ← 知识实体 │
│ │ raw/ima/ │ │ concepts/ │ ← 概念方法 │
│ │ sessions │ │ comparisons/ │ ← 对比分析 │
│ └──────────┘ │ queries/ │ ← 问答沉淀 │
│ │ lessons/ │ ← 经验教训 │
│ └──────┬───────┘ │
│ │ │
│ 每周日 03:10 6步流水线 │
│ IMA→Sessions→Skills→ │
│ Index→Graph→Embeddings │
│ │ │
│ ┌──────┴───────┐ │
│ │ .graph.db │ │
│ │ pages: 206 │ │
│ │ edges: 1825 │ │
│ │ wikilinks: │ │
│ │ 1036 │ │
│ │ embeddings: │ │
│ │ 206x384 │ │
│ └──────────────┘ │
├─────────────────────────────────────────────────────────────┤
│ 复用层（主动检索） │
│ │
│ 用户提问 │
│ │ │
│ ├─→ Memory 指引 (每次对话自动注入) │
│ │ │ │
│ │ ↓ │
│ ├─→ wiki_probe.py (80ms 探针) │
│ │ ├─ token 模式: 关键词命中 + ref_count 加权 │
│ │ └─ semantic 模式: 向量余弦相似度(跨语言) │
│ │ │ │
│ │ 得分>3 → 深读页面 + wiki_query 2-hop │
│ │ 得分<1 → 直接回答(不浪费探索) │
│ │ │
│ └─→ 引用格式: [[page-name]] + confidence(high/med/low) │
└─────────────────────────────────────────────────────────────┘改进前后完整对比
| 指标 | 改进前 | 改进后 | 变化 |
|---|---|---|---|
| 存储 | |||
| Wiki 页数 | 94（假索引） | 206（精炼库） | 真实可查 |
| 实际 md 文件 | 1257 | ~712 | -43% |
| 博客镜像 | 545 文件 6.6MB | 0 | 已迁出 |
| 索引 | |||
| wikilink 边 | 0 | 1036 | 从零到千 |
| 核心层孤立率 | 未知（32.2%） | 1.1% | -97% |
| embedding 覆盖 | 0% | 100%（206 页） | 全覆盖 |
| 输入沉淀 | |||
| 会话→Wiki | 无自动机制 | 每日 09:00 自动 | 日产 1-3 页 |
| Web 搜索沉淀 | 0%（2784 次全丢） | 每日 02:30 自动 | 已回捞 39 页 |
| Web→Concept 升级 | 无 | 每周 LLM 提炼 | promote_raw.py |
| 检索 | |||
| 前置检索 | 无（Agent 不查） | 80ms 探针 | memory 自动注入 |
| 跨语言 | 不可能 | funding rate→资金费率 | 向量检索 |
| 进化 | |||
| 新页入库 | 直接写 | A-Mem NEW/MERGE/UPDATE | 防碎片化 |
| 孤立页补链 | 无 | link_orphans.py 自动 | 15 页已补 |
| 效率 | |||
| Memory 使用率 | 95% | 63% | -32pp |
| Cron 作业 | 40 | 39 | 精简 |
自动化流水线全景
| 时间 | 任务 | 模式 | 脚本 |
|---|---|---|---|
| 每日 02:30 | Web 内容回捞 | no_agent（Shell） | daily_web_harvest.sh |
| 每日 09:00 | Query Synthesis | no_agent（REST API） | daily_query_synthesis.sh |
| 每周日 03:10 | 六步全量重建 | no_agent（Shell） | weekly_wiki_ingest.sh |
| — | — | — | IMA→Sessions→Skills→Index→Graph→Embed |
三条流水线全部用 no_agent=true（纯脚本），不烧 LLM token。只有 Query Synthesis 和 promote_raw 调用 DeepSeek REST API（成本约为 agent 模式的 1/10）。
脚本清单
| 脚本 | 功能 | 耗时 |
|---|---|---|
build_wiki_graph.py | 扫描 wikilink 建图索引 | ~2s |
build_wiki_embeddings.py | 预计算 384 维向量 | ~5s（增量） |
wiki_probe.py | 毫秒级前置检索探针 | 80ms / 12s(semantic) |
wiki_query.py | 2-hop 图查询 + 孤立页诊断 | ~100ms |
wiki_page_upsert.py | A-Mem NEW/MERGE/UPDATE 决策 | ~3s/页 |
synthesize_queries.py | 会话→Q&A 页合成 | ~15s/页 |
harvest_web_extracts.py | SQLite→raw/web 回捞 | ~5s |
promote_raw.py | raw/web→concepts 提炼 | ~10s/页 |
link_orphans.py | 孤立页自动补反向链接 | ~30s |
经验总结
做对的：
- 先诊断后开方——用真实数据（2324 次 web_search 全丢弃、32% 孤立率）驱动设计，不凭感觉
- no_agent 优先——纯脚本能做的不烧 token，三条流水线全部零 LLM 成本
- A-Mem 判定比人工合并好——LLM 看到关键词就能判断 MERGE/UPDATE，比人工翻页面高效 10x
- 先建索引再清垃圾——有了图数据库才能量化”多脏”，不然只能凭感觉删
踩的坑：
- 图索引漏扫根目录——log.md/index.md 等枢纽文件不在子目录里，漏了 578 条 wikilink
- 中文文件名 slug 匹配——
[[健康优化计划]]和concepts/健康优化计划.md需要用 stem 而非 title 匹配 - 外部素材拉低信噪比——282 页 IMA 文章占全库 43% 但全是孤岛，排除后检索质量立刻提升
下一步
当前系统的已知局限：
- 向量检索首次加载慢（模型加载 12s）——需要常驻服务或用 ONNX 加速
- raw/web 提炼覆盖率低——39 页里前 5 页全是新闻，需要更多样本验证 promote 效果
- 跨领域推荐缺失——当前只找直接关联，没有”走过同一中间节点”的间接关联推荐
规划中：
- Working Memory 滚动窗口——近 7 天热点自动注入 system prompt
- Wiki 页 confidence 衰减——低 confidence 高 ref_count 的页触发人工复核
- Obsidian 可视化集成——把 .graph.db 同步到 Obsidian 的 Canvas 视图