本周 GitHub 周榜: 三个「记忆」项目
digoal约 7 分钟本周 GitHub 周榜 有三个项目。
一个把语义层建在 PostgreSQL 上,一个把用户记忆做成三路混合召回,一个把语料蒸馏成带溯源的知识库。
三个项目都指向同一件事:AI 应用的下半场,不在模型层,在记忆层。
一、NVIDIA/auto-ontology:语义层建在 PostgreSQL 上
本周涨星最猛的一个,一周 5,802,仓库才创建半年多(2026-04-27)。
它解决的是 Text-to-SQL 里最要命的那一段:Agent 写得出来 SQL,但不知道该写哪张表、哪个字段代表业务上的「活跃用户」。auto-ontology 的做法是先给数据源建一层语义本体,再让 Agent 只用本体里的东西写 SQL。
摄取流程是四步:
读源,抽 schema、列画像、样本值 逐表抽命名实体,映射到具体列 推断 join 关系和桥表 写回本体:术语、关系、以及 SQL 属性
第四步是重点。README 里管它叫 SQL 属性,原文是审核过的度量表达式(verified metric expression)。Agent 拼 SQL 时不再自己发明口径,而是直接引用这层已审核的定义。
README 的 Wide World Importers 案例里,语义化编译产出了 31 个术语,选中 Order 能看到它的描述、相关术语、映射到的列和 SQL 属性。
架构上是这么分的(端口来自 README 的组件表):
前端:Next.js 16,端口 3000 后端:FastAPI + LangChain,Text-to-SQL agent,端口 3001 摄取服务:FastAPI,摄取与语义编译,端口 3002 MCP Server:FastMCP,只读 agent 工具,端口 3003 本体与向量存储:PostgreSQL 17 + pgvector,端口 5432
README 里还写了一条运维提示:3001 和 3002 要放在私有网络里。FastAPI 信任前端转发过来的用户身份头,而摄取服务的端点(ingest、delete、reset、compile)自己没有认证,客户端统一走 3000 端口的 Web 应用进来。
回答路径上有一步值得单独说:写完 SQL 会去实际查库校验,不通过就重写。检索不到候选时,Agent 明确报告「该问题无法由此数据回答」,而不是硬凑一个 SQL 出来。
注:这里的 rerank 只在「编译阶段构建桥表 SQL 属性」时对候选表排序,不是每次提问都跑一遍重排。
对上你的哪条方向:方向一(数据库生态)最直接。这套东西的前提就是先有一个干净的 PostgreSQL 集群加 pgvector 扩展,本体表、向量表、审计过的 SQL 属性全都落在同一个库里。方向二也沾边,embedding 检索那一环本质上是把语义召回落到了数据库侧。
对做 PostgreSQL 布道的人有实际价值:它给了一个新的落地理由——不是"上 Postgres 因为稳",而是"上 Postgres 因为你的语义层和向量层要跟业务数据在同一个事务边界、同一个权限模型、同一个备份策略里"。
代价也摆在这:Apache-2.0 很干净,但项目 2026 年 4 月才建,121 个 open issue,迭代很快,接口别急着硬编码。
二、lobehub/lobehub:三路混合召回的记忆层
LobeHub 的 stars 数是这三个里最高的,85,239,forks 16,272。这个仓库值得看的不是 Agent 外壳,是它的记忆检索实现。
记忆存在 user_memories 表里,检索代码在 packages/database/src/models/userMemory/query/。一条查询同时开三条腿:
语义腿走 pgvector 余弦距离。summary 和 details 各有一份 embedding,1024 维,HNSW 索引加 vector_cosine_ops。多条查询会先用 combineEmbeddings 合并成一个向量再检索。
词法腿走 ParadeDB 的 BM25。paradedb.match 配 paradedb.boolean(should => [...]),多字段分组,conjunction_mode 控制严格还是宽松。搜出来的原始查询串会先过一遍 normalizeBm25MatchQuery 做语法消毒。
模糊腿自己实现 token Jaccard 相似度,包含关系记 0.85 分。上下文太长时自动跳过这腿,避免整段对话逐字段比对。
三路结果各自成表,在融合阶段才交叉。融合用的是 RRF 倒数排名分(1/(rank+1)),叠一层时间衰减,再叠标签和类别的相似度,最后 clamp 到 [0, 1]。时间窗口默认 7 天,短期关联场景用 3 天。
记忆还分了五层:activities、contexts、experiences、identities、preferences。
这套结构对着方向二(AI 记忆 + 混合召回)几乎是对着写的——向量、全文、模糊三种召回方式在同一个查询里并联,融合层是显式的而不是塞给模型自己判断。方向三也占,它整个 Agent 平台是 TS/Next.js 的完整产品。
一个必须提醒的点:它的 LICENSE 不是标准开源许可证。仓库里的 LICENSE 文件第一行写的是 LobeHub Community License,基于 Apache 2.0 但加了两条额外限制——你可以直接商用(不改源码地跑起来),但如果基于它做衍生作品再分发,得找厂商拿商业授权。GitHub API 也把它标成 NOASSERTION。做技术选型、给团队做合规评估时,这条得先过法务。
另一个值得看的细节:仓库里放了 LoCoMo 长对话记忆基准的测试数据(benchmarkLoCoMo.ts),说明作者是把记忆质量当正经指标在做,不是只拼功能。
三、anthropics/claude-quickstarts:语料读一次,问题问很多次
这个仓库是一堆 Anthropic 官方 quickstart 的集合。本周最值得看的是新加的 managed-agents/ 目录,Managed Agents 目前还在 beta。
managed-agents/knowledge-wiki 这个样例,把"怎么让 Agent 记住一批文档"这件事做成了一道成本题。
构建期跑一条动态工作流:extractor 逐批抽取内容并标出缺口,resolver 去补 extractor 标的缺口,analyzer 和 organizer 核对归档内容并整编,最后产出一份只读 Markdown 知识库,存在 memory store 里。
问答期就简单了:每个问题开一个 session,挂载那份知识库。
Anthropic 在 README 里给了 core 档(8 份 SEC EDGAR 归档文件,2.8 MB 文本)的实测账:
建库一次性成本,基准平均约 19 美元(notebook 里记录的那次跑批约 16 美元),官方跑批耗时 23 分钟 之后每次提问的花费约为「让大模型裸搜原始文档」的 1/15 用知识库的小模型,答题质量在 1 分以内追平「裸搜原始文档的大模型」,并且比「自己去搜文档的小模型」高约 3 分 按这个口径,大约 240 个问题回本
原文的对比对象要说清楚:基线是大模型 + 裸搜文档,不是小模型裸搜。所以这套方案省的不只是钱,还把模型档位降下来了——用的是小模型配知识库,去对标大模型裸搜。
模型档位的分法也写了:读取用 Haiku 5.5,lead agent 和裸搜基线用 Sonnet 5.5。
这套设计里最值得学的两点:
第一,溯源不是可选项。 知识库里每条事实都带出处。冲突的事实保留为冲突,被取代的口径保持过时状态,不自动合并。官方原话是不要把冲突压平成一个看起来整洁的答案。这条对做企业知识库的同理。
第二,官方 notebook 在建库前会先打印按目录价估算的花费,超预算就停。 成本闸门写进了流程,不是靠人自觉。
同一批样例里还有几个方向三(AI 应用实践)的东西:daily-brief 定时简报配了只读偏好库加可写状态库两套记忆,agent、sandbox、schedule、memory、spending cap、credential vault 六个文件用 ant apply 一次装好;docker-memory 一个 session 一个容器,记忆放服务端,容器用完就丢,官方说法是容器是 disposable 的;vault 里 Slack bot token 对 agent 只显示占位符,真 token 只在发往 slack.com 的请求上才替换;roadtrip-planner 是多 agent 串联,planner 出完草稿会 spawn 一个跑 Opus 的 reviewer agent,把草稿发过去等它挑毛病,两个 agent 的对话都在同一条事件流上。
对上你的哪条方向:方向二最直接,而且是三个项目里唯一给出完整成本模型的。方向四(投资)也有一处——这个仓库的 managed-agents/copilot-kit-ag-ui/financial-assistant 就是个金融顾问 agent,不过它是样例级代码,不是可以直接用的投研系统。
MIT 许可证,随便读随便改。
本周观察
三个项目看起来是三类东西:一个是语义层,一个是 Agent 平台,一个是 quickstart 集合。放一起看,说的是同一件事——记忆从"提示词里塞一段"变成了一个有 schema、有索引、有预算的独立工程对象。
auto-ontology 把它建模成本体表和向量表,SQL 属性是审核过的度量表达式;LobeHub 把它建模成带五层分类的表,查询要过三路召回再融合打分;Anthropic 把它建模成 memory store 里的只读 Markdown,每个问题挂一次。
三个做法形态差别很大,判断标准却一致:记忆的内容能不能被追溯到源头。auto-ontology 的溯源是本体里的术语和关系,LobeHub 的溯源是记忆的层级和创建时间,Anthropic 的溯源是文档里的引用标记和"这条被取代了"的状态标记。
三条路线里,对做数据库的人最友好的还是 auto-ontology。它的前提就是 Postgres + pgvector,本体、向量、审计过的口径全在一个库里,权限模型和备份策略天然一致。做语义层选型时,这比"要不要引入一个新的向量数据库"这个问题更值得先问。
另一个观察:这三个项目都在解决"Agent 输出的数字不可信"这个问题。auto-ontology 用查库校验和重写,LobeHub 用明确的时间衰减避免用过期记忆,Anthropic 用冲突保留和过时标记。给 AI 装记忆的同时,得给它装"我知道我不知道"的能力——这可能是这周最值得带走的一句话。