sqlite-graph-memory

sqlite-graph-memory：基于你自己的 Markdown 笔记，为 Claude Code、Cursor 和 Codex 提供持久记忆

为编码 Agent 提供长期记忆，内容存放在你已有的笔记中：它既是一个 MCP 服务，也是一个用于任意 Markdown 文件夹（包括 Obsidian 库）的命令行工具。只需 pip install，指定文件夹，Claude Code、Cursor、Codex 或任何其他 MCP 客户端就能从中检索信息。

你的 Agent 会忘记每次会话中的所有内容，而普通向量搜索只会返回彼此无关的平面片段。这个工具能从你自己的 Markdown 笔记中实现关联式检索：向量搜索找到入口，你已经写好的 [[wikilinks]] 就构成了图。只需一个 SQLite 文件，无需图数据库、ETL 流程或服务。

三条命令

pip install 'sqlite-graph-memory[embeddings]'
sgm-index ./notes
sgm-ask --ab "In which programming language is the tool behind Project Ouzel written?"

./notes 可以是任何 Markdown 笔记文件夹。若要获得以下完全相同的输出，请使用此仓库中的 202 条笔记合成库（它不包含在 pip 包中）：

git clone --depth 1 https://github.com/tonydzi/sqlite-graph-memory && cp -R sqlite-graph-memory/bench/vault ./notes

实际输出，共 12 条中的前 5 条：

--- DIRECT memory (vector) ---
 1. [  1.66] project-ouzel
 2. [ -1.33] project-avocet
 3. [ -1.79] tool-cobbleset
 4. [ -2.44] meeting-2025-10-21-lighthouse-sync
 5. [ -2.70] person-severin-ibarrondo

--- ASSOCIATIVE memory (vector+graph) ---
 1. [  1.66] project-ouzel
 2. [  1.14] tool-lanternfish  <== +graph
 3. [ -1.33] project-avocet
 4. [ -1.79] tool-cobbleset
 5. [ -2.44] meeting-2025-10-21-lighthouse-sync

答案位于 tool-lanternfish 中（“Lanternfish 是用 Elixir 编写的”）。问题中从未提到 Lanternfish，因此向量检索完全没能将它排进前 12 条。project-ouzel 链接到了它，所以沿图跳转一次就能将它排到第二位。

如果这次跳转找到了向量搜索遗漏的内容，点一颗星标，能帮助其他拥有笔记文件夹的人找到此仓库。sgm-ask --ab 只会在每台机器上于终端中询问一次；设置 SGM_NO_STAR_PROMPT=1 可关闭提示。

一个查询就能展示这个思路，但它并非在所有情况下都更胜一筹。在同一个笔记库中，纯向量模式整体排名优于图模式；数据见 bench/。使用 --ab 可以测试哪种模式在你自己的笔记上效果更好。

适用于任何 MCP 客户端（Claude Desktop、Cursor、Zed、Windsurf）：安装上述内容后运行 sgm-mcp，或者运行 uvx --with 'sqlite-graph-memory[embeddings]' sqlite-graph-memory。将 BRAIN_INDEX_DIR 设置为 sgm-index 写入的 index 文件夹。配置示例：examples/mcp-config.json。Claude Code：运行 claude mcp add sqlite-graph-memory -e BRAIN_INDEX_DIR=/path/to/index -- sgm-mcp。Codex：在 ~/.codex/config.toml 中添加 [mcp_servers.sqlite-graph-memory] 表，并设置 command = "sgm-mcp"。先读取文件的 Agent：llms.txt。

它是什么

面向 AI Agent、基于 SQLite 的 Graph RAG——这是一个可用的试点项目，并非框架。它是个人“第二大脑” Agent 配置中提取出来的记忆层：向量搜索找到入口，你手动写下的 [[wikilinks]] 构成图，交叉编码器会对图跳转引入的内容重新排序。 SQLite 是唯一使用的数据库（schema.sql）。

状态：试点项目。这个说法并非随意使用：它在一个真实配置中每日运行（索引约 2.8 万条精选笔记、约 9.3 万个片段，每晚从由 Claude Code 驱动的约 27 万个文件的 Obsidian 库中重建），但它刻意保持精简，并不试图适用于所有场景——详见有意缺少的内容，其中说明了测试覆盖不均的问题。 该项目作为一篇即将发布的轻量级 Agent Graph RAG 文章的配套代码发布；目前已完成的唯一设计说明是 docs/bitemporal.md。

为什么

大多数 Graph RAG 技术栈都假设使用图数据库、ETL 管道和实体抽取流程 — HippoRAG（arXiv:2405.14831）就是这样构建其 KG 的，而 Graphiti/Zep 则维护一个时间图。 对于基于 Markdown 知识库的单用户 Agent 来说，这三者都过于复杂：

• 图已经存在 — Obsidian/Logseq/纯 Markdown 用户会手动整理 [[wikilinks]] 边，brain_ask.py 只需解析它们。 无需抽取流程，而且边的质量胜过模型能挖掘出的任何结果。
• SQLite 已经够用 — 唯一值得持久化的是派生状态（每轮一个 ledger）和遥测数据，两者都定义在 schema.sql 中。 一个文件，标准库驱动，无需运维。
• RAG 质量中最耗费资源的是重排器，而非图基础设施 — 请参阅 brain_ask.py 中的重排步骤。

因此，这个试点的设想是：用向量检索获取入口，用手工整理的 wikilinks 建立关联，用交叉编码器确保偶然发现的结果可靠，用 SQLite 存储所有必须持久化的内容。 四个步骤都按此顺序放在一个文件 brain_ask.py 中。

架构

三个层级，三个故障隔离组件：

markdown notes (with [[wikilinks]])
        │
        ├── index_notes.py      chunk + embed (e5-base) → .npy/.pkl index
        │
        ├── brain_ask.py        recall pipeline:
        │       1. dense retrieve  top-60 chunks, dedup by file
        │       2. --graph         +1-hop wikilink neighbours of top-15 hits (max 40)
        │       3. rerank          cross-encoder → top-12
        │       4. --ab            run vector-only AND vector+graph, diff,
        │                          log the delta to SQLite (ab_recall)
        │
        └── turnstate_hook.py   agent Stop-hook: after every assistant turn,
                                parse the transcript tail and append one row
                                (ask, summary, files, tools, commands, decisions)
                                to SQLite (turns). 0 LLM tokens, pure stdlib.
                                turnstate_show.py = read-only viewer.

schema.sql 记录了两张表。图不会在 SQL 中实体化： brain_ask.py 会在查询时从笔记中解析边，范围限制为 1 跳 / 40 个邻居。 这样图就能始终与笔记保持同步，且维护成本为零；只有在跳数深度或语料库规模有需要时，才实体化边表。

经受现实检验后保留下来的设计选择

• 图扩展用于生成候选项，而非排序（brain_ask.py）。邻居会与向量检索结果 一起进入同一个重排器候选池，因此不相关的链接笔记会被排到后面。 这就是为何可以放心开启 1 跳扩展。
• 实体门控（brain_ask.py 中的 looks_like_entity）。A/B 遥测表明，图 扩展有助于主题查询（“Agent 记忆方法”），但会影响名称/工具 查询（“NotebookLM”）：一个名称卡片会链接到所有内容，因此跳转会带来噪声。 brain_ask.py 中的启发式规则刻意保持保守，只会在查询呈现名称特征时关闭图功能。
• 将崩溃安全作为策略。 图跳转（brain_ask.py）和 Stop-hook （turnstate_hook.py）都进行了封装，因此任何故障都会退化为先前的行为： 仅使用向量进行召回，不写入 ledger 行。 记忆层绝不能让 Agent 的表现差于完全没有记忆层。
• 用测量代替轻信。 --ab 会针对每个真实查询运行两条管道，并将图将多少篇笔记提升到前 N 名的 数量记录到 schema.sql 中的 ab_recall。 “联想记忆”是否有价值，可以通过每周运行 SQL 查询来判断，而不是凭感觉。

有意未包含的内容

• 没有实体通道。生产环境还有一个针对人物/项目卡片的额外检索通道； 它与个人数据纠缠过深，因此无法公开。
• 没有增量索引（已记录在问题列表中）。自 v0.3.0 起提供打包方式（pip install sqlite-graph-memory）。现在确实有评测套件了 — 请参阅 在替换前先测量 — 但它通过 wikilink 派生的黄金标准评估检索效果，这种监督信号较弱，而且文档也明确说明了这一点。测试覆盖并不均衡： index_notes.py、brain_ask.py 和 mcp_server.py 有单元测试，而 turnstate_hook.py 有写入路径覆盖。运行 pytest -q 查看当前数量， 不要相信此处用文字写出的数字 — 正因为如此，本文件曾声称“没有测试”，实际上却有七项测试通过。 上方的状态行特意标明了试点。

快速入门

# Indexing and reranking need the embedding stack; the base install leaves it out
# so that `pip install sqlite-graph-memory` stays small instead of pulling ~2 GB
# of torch. Ask for it explicitly:
pip install 'sqlite-graph-memory[embeddings]'

# 1. index a folder of markdown notes
sgm-index /path/to/notes

# 2. ask, three ways
sgm-ask "how do I think about agent memory"
sgm-ask --graph "how do I think about agent memory"
sgm-ask --ab    "how do I think about agent memory"   # logs the diff to SQLite

# 3. inspect the A/B telemetry
sqlite3 turnstate.db "select ts, query, new_in_top, promoted_via_graph from ab_recall order by id desc limit 10"

在基础安装上运行其中任意一个命令，它们会告诉你缺少哪个额外依赖，而不会引发 ModuleNotFoundError——tests/test_optional_extra.py 覆盖了这条路径。

要在 Claude Code 中启用每轮账本，请注册 Stop hook（具体配置块见 examples/claude-code-stop-hook.json，它会调用 sgm-turnstate-hook），然后：

sgm-turnstate-show --stats

如果你是从克隆的仓库而非安装包开始使用，pip install -e '.[embeddings]' 会提供相同的四个命令，并且这些模块仍可通过 from sqlite_graph_memory import brain_ask 导入。

配置仅通过环境变量进行，所有变量都列在 .env.example 中；所有内容默认位于当前目录。如果存在 CUDA 版 torch 构建，会自动使用 GPU；对于小型语料库，CPU 也完全够用。

--ab 的效果

在一个由 4 条笔记组成的玩具语料库上运行 brain_ask.py 并使用 --ab 的输出（实际运行使用约 28k 条笔记 / 约 93k 个分块的索引）：

A/B RECALL: how should agent memory work
(Direct=4 vector / Associative=+0 graph; Associative promoted 0 new notes into top-12, 0 of them via graph)

--- DIRECT memory (vector) ---
 1. [  4.11] agent-memory
 2. [ -6.50] graph-rag
 3. [ -8.66] sqlite-ledger
 4. [ -9.73] cooking

--- ASSOCIATIVE memory (vector+graph) ---
 1. [  4.11] agent-memory
 2. [ -6.50] graph-rag
 3. [ -8.66] sqlite-ledger
 4. [ -9.73] cooking

在这么小的语料库上，图谱没有带来任何增益——所有笔记本来就都在候选池中。有意思的差异会在规模扩大后显现，这正是 schema.sql 中的 ab_recall 表要积累证据的内容。

公开基准测试 — bench/

下一节中的所有数据都来自我们的私人知识库，因此实验室以外的人无法验证。bench/ 提供了可复现的部分：一个关于虚构实验室、由程序生成的 202 条笔记的知识库，分属七类的 91 个问题（包括 22 个答案不在知识库中的问题），以及三个对 Agent 记忆很重要的指标：支持笔记的 recall@k、逐字引用，以及在事实缺失时弃答。

python bench/run.py --system bm25          # one command, stdlib only
python bench/validate.py                   # what CI runs on every result file

我们的基线结果发布在排行榜上，并明确列出了薄弱环节：对于“当前截止日期是什么”这类问题，系统能检索到两个决策（R@5 为 1.00），但 6 次中有 6 次引用了已被取代的决策；在这个知识库上，仅使用向量的模式排名高于图谱模式（R@5 为 0.88 对 0.85）。其他记忆系统（mem0、Letta、Khoj、plain RAG）只需一个适配器文件和一个拉取请求即可加入排行榜：bench/CONTRIBUTING.md。CI 会根据每个问题的输出重新计算所有提交的数据，因此手动填写的数据无法登上排行榜。

健康检查 — sgm-stats

只需四个数字即可了解链接图谱本身的状况，无需模型或索引。它使用与 recall 相同的过滤器和相同的 [[wikilink]] 解析器读取笔记，因此测量的是 --graph 实际遍历的图谱。阈值遵循 second-brain-os 指标；每个阈值都对应一个 --threshold-* 标志。退出码 0 表示正常，1 表示警告，2 表示失败，因此可以在 cron 中运行。

$ sgm-stats bench/vault --today 2026-10-20
202 pages in bench/vault

FAIL  orphan_rate       26.2%   53 of 202 pages have no inbound link
OK    avg_degree         4.65   940 resolved links over 202 pages
OK    main_component   100.0%   202 of 202 pages; 1 component
WARN  stale_concepts   100.0%   12 of 12 concept pages older than 90 days (as of 2026-10-20)

合成基准测试知识库未通过孤立笔记检查，原因很简单：其中 40 条会议笔记和 12 条决策笔记都有外链，却没有任何笔记链接回它们。--json 会提供相同的报告，并列出首个孤立笔记和过时页面的名称。

先衡量，再替换 — eval/

RAG 流水线中每一项“显而易见”的升级——更新的嵌入模型、更强的重排器、混合 BM25、不同的分块器——都是一个假设。如果没有基于你自己的语料得出的数据，贸然替换就只是带着变更日志的迷信。eval/ 是我们能构建出的最简洁可靠的标尺，而且无需标注预算，也无需调用大模型：你已经写下的维基链接就是相关性标签。

python eval/run_eval.py --selftest                       # metrics only: no model, no index
python eval/build_gold.py /path/to/notes --n-per-class 60   # -> eval/gold-<today>.jsonl (freeze it)
python eval/run_eval.py --gold eval/gold-<today>.jsonl --sqlite

四类问题分别探测流水线的不同环节：title（笔记自身的标题应该能找到它），body（笔记的首段应该能找到它），bridge（笔记的首段应该能检索出它用 [[links]] 链接到的笔记——这正是图的用途），以及 temporal（过时笔记的标题应该能检索出替代它的新笔记，通过 superseded_by: "[[newer-note]]" frontmatter 字段指定）。每个问题都会在纯向量和向量+图两种模式下评分，因此“图有没有帮助？”不再是见仁见智的问题。

run_eval.py 会导入 brain_ask.py 并调用 Agent 使用的同一组函数——load_index、retrieve_candidates、expand_1hop、rerank_candidates——所以你衡量的就是实际运行的内容。重新实现流水线的评估，衡量的只是重新实现的版本。--sqlite 会将每种类别和模式各一行追加到 gold_eval 表中，这样六周后运行的结果就能与今天的结果进行比较。

我们为此付出的代价

来自家庭知识库的数据（约 2.4 万个分块，俄语+英语，2026-09-16），使用一套固定的 184 个问题黄金集（60 个标题 / 60 个正文 / 60 个桥接 / 4 个时间问题），向量+图模式：

标题和时间类别的 nDCG 数据是修正后的，而这项修正是本页最有用的内容。审查该模块的外部评审组发现，ndcg_at 在排名中同一文件名出现两次时，会将黄金笔记计分两次——而维基链接通过文件名标识笔记，因此只要两个文件夹里都存在一个 foo.md，就会发生这种情况。我们立即复现了这个问题：ndcg_at(['foo','foo'], ['foo']) 返回 1.63，超过了该指标的最大值。这影响了 184 个问题中的 4 个，将标题 nDCG 抬高了 0.031，将时间类别抬高了 0.108。Recall@12 和 MRR 从未受影响（前者基于集合计算，后者在首次命中时停止），而且由于同样的四个问题抬高了两次运行的分数，所有前后差值保留到了小数点后第四位：标题 +0.0056 变成 +0.0055。因此，下文的合并和回退决策依然成立——但我们原本会引用的绝对值是错的，而没人挑战的评估结果只会一直礼貌地错下去。

有两项改动为我们带来了这一发现。清理索引中的重复快照副本（27 095 -> 24 216 个分块），使指标恰好变动了 0.0000——从标尺上看毫无收益，却能防止过期副本占用检索位置；正因为数字为零，这一点才值得确切知晓。真正带来变化的改动，是让图对排序而非候选集产生影响：对维基链接图运行个性化 PageRank，再通过 RRF 与重排器融合，同时保护重排器排名前 5 的位置。我们通过测量而非猜测找到了根本原因：正确的 bridge 答案中有 97% 已经在候选池里，却被交叉编码器丢弃了，因为这种关系是结构性的，而非文本性的。扩大检索范围这个显而易见的修复方案，完全不会起作用。 该路径随软件包一同发布，位于 src/sqlite_graph_memory/ppr.py，默认关闭：使用 SGM_PPR=1 或 sgm-ask --ppr 开启，并使用 python eval/run_eval.py --gold ... --ppr 评测；这会在 vector 和 graph 之外增加第三种模式。上面的数据是在图池上测得的，因此对应的命令是 sgm-ask --graph --ppr；单独使用 --ppr 会重新排序向量池，而 --ab 会排除该路径，使其 A/B 日志仍然只比较 vector 和 graph。该路径发生任何故障时，都会回退到重排器的顺序，与图跳转的处理方式相同。请明确这些数据复现的是什么：上面的桥接数据来自维护者的个人知识库和本地工作流，测于 2026-09-16，尚未使用已发布的软件包重新运行。代码采用相同算法和常量（alpha 为 0.85、10 个 PPR 文件、保护排名前 5 的结果），但你的知识库会得出自己的数据，而且 bench/ 目前还不会评测这条路径。

另外七项改动也依据同一把标尺被否决，并且事先定下了同一条规则： 任何类别的 nDCG@12 回退超过 0.01，就撤销该改动。

这些结论都不是在评价模型，而是在评价这个语料库使用这把标尺的结果。这是决定是否替换时唯一真正需要的结论；而这段代码放在此处而非博客文章中的原因，正是你的语料库会与我们的不同。

这项评测无法告诉你什么

维基链接标注属于弱监督：有链接的邻居未必就是能回答问题的笔记。bridge 是根据链接构建的，因此任何遍历链接的方法在那里都会显得更好——它测量的是“工作流能否沿着关联继续查找”，而不是“这条关联是否正确”。一次运行评测的是一个索引的一个版本；如果在两次运行之间重建标注集，两组数据就无法比较，这是评测悄然开始说谎的方式。在 60 个问题上，±0.02 的 nDCG 差异仍处于噪声范围内：我们观察同一工作流的两个候选冻结版本在 184 个问题中有 33 个结果不一致后，才明白这一点。

这项指标可以被故意破坏。EVAL_MUTANT=1 会让 nDCG 对所有结果都返回完美的 1.000，而在该设置下，pytest tests/test_eval.py 必须报错失败。如果指标已损坏而测试套件仍然全绿，就说明它从未真正测试过该指标。

路线图

现在 — 最新版本（截至 2026-10-19，PyPI 和 MCP Registry 上的版本为 v0.3.1）。 当前每日运行的试点：检索流水线、逐轮账本和 A/B 遥测，全部位于 brain_ask.py 和 turnstate_hook.py 中，另有双时态设计说明。已知缺陷记录在 跟踪器中，而不是这里的脚注里； 本文件有意不提及任何问题编号：问题会被关闭，相关文字却不会随之更新，而这种偏差正是本段过去重复出现两次的缺陷。

接下来：

• 公开基准测试现已推出，位于 bench/（bench-v0.1）：包含一个由 202 条笔记构成的合成库、91 个问题、其他系统也能参与的排行榜，以及可复现这些数据的 CI。仍缺少完整的消融矩阵（跳数 × 种子上限 × 邻居上限 × 重排候选池 × 门控策略）。bench/ 已包含前两个实验单元：0 跳和 1 跳。真正有意思的问题从来不是“图是否有帮助”，而是对哪些查询类别有帮助；eval/ 会按类别作答，而不是凭直觉判断。
• 双时态边 — 设计说明 docs/bitemporal.md。当你选择将图物化，而不是在查询时解析它，就应为每条边赋予有效时间窗口（valid_from / valid_to / observed_at），这样重建时会关闭已被取代的事实，而不是将其删除：历史得以保留，召回优先考虑当前事实，as_of 查询则能还原过去。通过置信度衰减实现非破坏性老化。第一天的 A/B 结果——上下文大小基本不变，检索到的候选项按平均年龄计算新鲜度提高约 60%——及其注意事项已记录在 docs/bitemporal.md 中：数量上的优势需要纵向观察，因此这只是单个语料库上单日的结果，并非基准测试。
• 关于这一模式（“无需图提取的 Graph RAG”）的文章正在撰写中。

每项值得关注的更改都会随新版本发布，因此要判断“试点”是否已不再是恰当的称呼，请查看版本发布动态，而不是提交记录图。

模型

• 嵌入模型：intfloat/multilingual-e5-base（多语言；主要语料为 RU+EN）
• 重排模型：cross-encoder/mmarco-mMiniLMv2-L12-H384-v1

两者都作为常量（E5_MODEL、RERANK_MODEL）定义在 brain_ask.py 中，体积小到可在笔记本电脑 GPU 上运行；可以自由替换，因为流水线中的任何环节都不依赖这些特定模型。

维护者

• Anton Dziatkovskii（@tonydzi）：检索流水线、账本、基准测试、版本发布。
• Vardhman Gupta（@Kaap10）：MCP 服务（sgm-mcp、PR #8、#10、#14）及其测试；针对 mcp_server.py 的审查会通过 CODEOWNERS 分配给他。

AI 贡献者

本项目由人类 + AI 团队构建，git 日志也记录了这一点：Claude 编写大部分代码，Codex 和 Grok 负责审查，Gemini 提供研究支持。只有当 AI 的输出改变了某次提交的内容时，才会在该提交中注明它的贡献——不做装饰性署名。实验室范围内的政策，每个仓库均以此文件为准： AI-CONTRIBUTORS.md。

引用本项目

关于该系统的论文——涵盖检索设计、试点遥测和按查询类别分层的评估协议——现已发表：DOI 10.5281/zenodo.22639718（预印本，CC BY 4.0）。机器可读的引用信息：CITATION.cff（GitHub 的“引用此仓库”按钮）。学术身份：Anton Dzyatkovsky 以 Anton Dziatkovskii 为名发表作品（ORCID 0000-0001-7408-3054）。

许可证

MIT

联系方式

有问题、经验分享，或者想在自己的设备群上运行它：

• 👤 作者：Anton Dziatkovskii — Telegram @tonydzi · WhatsApp +1 341 222 9178 · X @Tony_Stef_
• 📣 频道：@ClawRus（RU）· @ClawEng（EN）
• 🌐 palo-alto.ai · Palo Alto AI Research Lab
• 🧪 工程师：想试用这套配置吗？ 给我发消息——我会向参与测试并反馈的工程师免费提供入门种子。

告诉我们缺少什么

你在自己的笔记上试用了它，却发现缺少某些内容或运行出错。这是最有用的反馈。

• 你开始尝试了，但没能运行： 填写这个 3 个问题的表单（你尝试了什么、哪里出错、使用哪台机器）。
• 不确定这是 bug，还是只是一个想法： Discussions → Ideas。

这个软件包不会向外发送任何信息。这里没有遥测功能，所以我们只知道你告诉我们的内容。

欢迎贡献者——目前有待处理事项

标记为 accepted 的问题范围明确、可以直接认领，目前无人处理。评论 “claiming this”——无需许可—— 然后该问题就归你处理 7 天。刚来？从 good first issue开始。

你保留代码的版权。 永远不需要 CLA，也无需转让版权——你的贡献将遵循本仓库现有的许可证，与我们的代码适用相同条款。我们会在 48 小时内回复每个 issue 和 PR，包括“不同意，原因如下”；如果我们没有回复，那就是我们的疏忽，请在讨论串中提醒我们。

完整说明：CONTRIBUTING.md

🧩 可运行系统中的一部分

这个仓库是从一个实际运行的系统中拆分出来的一部分：一位工程师管理着一组机器，借助 Claude 作为实现协作者构建而成；这些机器彼此达成共识，只有涉及资金或不可逆操作时才会唤醒人类。它经受过生产环境的考验后才被提取出来，并非为演示而编写——而且它可以独立运行：这里的任何内容都不会向系统的其他部分发送信息。

了解整个系统如何协同工作 → SYSTEM.md

它在记忆层最接近的项目：second-brain-starter-kit · voice2brain

与 AI 一起阅读

只需点击一次，Agent 就会读取代码库，提取其中的模式，并帮助你将其应用到自己的工作中。

Read this repo: https://github.com/tonydzi/sqlite-graph-memory (“sqlite-graph-memory” - Graph RAG on SQLite for AI agents: vector retrieval + hand-curated wikilink graph + cross-encoder rerank, with a zero-token per-turn memory ledger. Working pilot). Work out what problem it actually solves, pull out the reusable patterns and help me apply them to my own setup. Start by asking what I am working on.

_{— TonyDzi，Palo Alto AI Research Lab · 第二大脑、Agent 协作、持久记忆：github.com/tonydzi}