GitHub 趋势 · 第 57 期
9 个 Agent 记忆仓库横评：star 最多的那个，其实什么都不存
#Agent记忆#横向对比#技术选型#开源许可
先给判断：这 9 个仓库合计 305,971 star，其中 59.7% 落在唯一一个不保存任何状态的仓库上——microsoft/markitdown，它做的事情是把 PDF、Office 文档转成 Markdown，一次调用，进出之间不留任何东西。而真正给单个 agent 做长期记忆的两个（akitaonrails/ai-memory 6,562 star、jordan-gibbs/hyperresearch 2,644 star）加起来只有 9,206 star，占 3.0%。这不是说 markitdown 不好，它是每个 agent 工作流的第一步，也确实好用；问题在于 star 记录的是「这件事有多通用」，不是你该把记忆托付给谁。挑记忆层要看另外三件事：你的记忆落在哪、删掉索引它还在不在、以及官方靠什么赚钱。
给 agent 装过记忆的人都见过同一个场面：昨天聊了三个小时，今天新开一个窗口，它连你项目叫什么都要重新问一遍。上下文窗口是有限的，agent 本身是无状态的，于是「记忆」成了这一年最拥挤的赛道之一。这一期就把榜单上同一条赛道的 9 个仓库摆在一张桌子上——不比口号，只比能核实的硬字段。
先说选题。今天三张榜都抓了：日榜 16 项、周榜 23 项、月榜 23 项。逐个剔除已写过的 56 个项目、已结案的薄项和已排除项之后，三张榜的未写候选是 0。周榜与月榜零新面孔，日榜只剩两项：nab138/iloader（+50）与 jordan-gibbs/hyperresearch（+153），两个都在备选池里躺了多期，动量数字连续九期没怎么变过。上一期文末我公开预告过：如果还是零候选，就换一个主题族做合集。这一期兑现承诺，换成的主题族就是今天榜上最拥挤的那一族——Agent 的记忆与上下文。hyperresearch 正好也在这一族里，两个待办合成一件。
这 9 个为什么能摆在一张桌子上
收录标准只有一条：它得管「你的知识、或 agent 的上下文，怎么留下来」。9 个仓库分散在日榜（llm_wiki、hyperresearch、OpenResearch）、周榜（markitdown、context-mode、WeKnora）和月榜（OpenViking、semantica、ai-memory）上，定位差得很远——从一行命令装完的转换器，到 docker compose up -d 起一整套的知识平台——但都在回答同一个问题。
- ▪microsoft/markitdown：把 PDF、Office、图片转成 Markdown，微软官方，一行装完。
- ▪volcengine/OpenViking：把上下文组织成一个 viking:// 虚拟文件系统，资源和记忆都像文件一样 ls、read、write。
- ▪Tencent/WeKnora：文档进来，变成可查询的 RAG、会自己维护的 Wiki，再挂一个推理 agent。
- ▪mksglu/context-mode：给编码 agent 做上下文压缩，把会话事件写进每项目一个的 SQLite，再按平台注入路由规则。
- ▪nashsu/llm_wiki：桌面应用，把丢进去的资料自动整理成互链的 Wiki，明确跟「每次从零检索」的传统 RAG 唱反调。
- ▪semantica-agi/semantica：图原生的上下文基础设施，把「决策」本身建成图里的一等节点，配溯源与审计。
- ▪akitaonrails/ai-memory：给 agent CLI 做长期记忆，顺带解决换 agent 厂商时的交接问题，Rust 单二进制。
- ▪jordan-gibbs/hyperresearch：把 Claude Code 变成深度研究 agent，抓到的每个来源都落成一条带溯源的笔记。
- ▪alphaXiv/OpenResearch：本地优先的研究工作台，每个研究方向给一个隔离的 git worktree，实验谱系可追。
硬字段横向核了一遍。6 列全部取自 GitHub REST API 与各仓库原文，没有一个数字来自榜单页面：
| 仓库 | Star | 许可 | 语言 | 主安装通道 | 体量 |
|---|---|---|---|---|---|
| microsoft/markitdown | 182,693 | MIT | Python | pip | 4,712 KB |
| volcengine/OpenViking | 36,715 | AGPL-3.0 | Python | pip | 265,053 KB |
| Tencent/WeKnora | 22,366 | MIT | Go | docker compose | 162,591 KB |
| mksglu/context-mode | 22,218 | Elastic License 2.0 | TypeScript | 插件市场 / npm | 31,898 KB |
| nashsu/llm_wiki | 18,765 | GPL-3.0 | TypeScript | 安装包 | 40,354 KB |
| semantica-agi/semantica | 12,703 | MIT | Python | pip | 55,648 KB |
| akitaonrails/ai-memory | 6,562 | MIT | Rust | 本地二进制 / Docker | 14,764 KB |
| jordan-gibbs/hyperresearch | 2,644 | MIT | Python | pip | 1,755 KB |
| alphaXiv/OpenResearch | 1,305 | MIT | Rust | 安装脚本 | 71,298 KB |
表里有一处必须交代清楚：许可这一列有两个来源。markitdown 那一格是 API 的字段值（它的 README 正文根本没写许可证名，只写了 CLA 和商标条款）；其余八格取自各仓库自己的 README 或 LICENSE。之所以要分开说，是因为 9 个里有 3 个的 API 许可字段返回 NOASSERTION：context-mode、llm_wiki、WeKnora，而它们的 README 分别写明 Elastic License 2.0、GPL-3.0、MIT。我拉了 llm_wiki 那份 LICENSE 原文核对，是完整的标准 GPL-3.0 全文，只在第一行加了一句项目名与版权人——连标准全文都会被判成 Other。所以结论是：API 的许可字段可以用来看趋势，但商业场景下必须回到仓库里的原文。
错位一：六成的 star 给了一个不存东西的仓库
把 9 个仓库按「记忆到底落在哪」分组，star 分布是这样的：
| 记忆落在哪 | 仓库数 | 合计 star | 占比 |
|---|---|---|---|
| 不保存任何状态（只做格式转换） | 1 | 182,693 | 59.7% |
| 你自己磁盘上的 Markdown 文件 | 3 | 27,971 | 9.1% |
| 本地数据库或索引（SQLite / 本地向量） | 2 | 23,523 | 7.7% |
| 可插拔的图库与向量库后端 | 3 | 71,784 | 23.5% |
| 合计 | 9 | 305,971 | 100.0% |
四行合计 305,971，与上面那张 9 个仓库的表对得上。最扎眼的是第一行。markitdown 一个仓库吃掉 182,693 star，是这一族总量的 59.7%，而它做的是把文件转成 Markdown——README 自己的定位是 a lightweight Python utility for converting various files to Markdown for use with LLMs and related text analysis pipelines。它是一次性的、无状态的、也不需要被信任的。它是流水线的入口，不是记忆层。而真正在做长期记忆的两个，全挤在榜单末尾的量级上。
我的理解是：泛用性决定收藏量，决策成本决定使用量。markitdown 任何人 30 秒能用上；而记忆层要你先选形态、备好后端、想清楚数据会被谁看到——它在被使用之前，先要被做一次决策。收藏按钮是在决策之前按下的。所以这一族的 star 分布，量的是「多少人觉得这事该有个解法」，不是「多少人真的把记忆托付给它」。
错位二：删掉索引，记忆还在吗
这是我在这一族里发现的最大分歧，也是选型时最少被问到的问题。同样叫「记忆」，对「索引丢了怎么办」这个问题，这一族里有三个仓库给出的是同一个答案，而第四个的答案正好相反。
- ▪hyperresearch 把答案写在 README 最显眼的地方：Markdown is truth, SQLite is cache。笔记以纯 Markdown 加 YAML frontmatter 存在 research/notes/ 里，索引是可重建的，原文是 delete it and hyperresearch sync reconstructs it from the markdown。
- ▪ai-memory 把同一件事写成了目录名：<data_dir>/wiki/ # markdown source of truth, git-versioned，索引在 db/ 里。也就是说你的记忆本身是一个能 git log 的仓库——它的文档里专门有一节讲怎么从 wiki 文件把 SQLite 重建出来。
- ▪llm_wiki 干脆不藏：整个知识库就是一堆 .md 加 frontmatter，目录结构就是 Obsidian 的 vault（wiki/index.md、wiki/log.md、entities/、concepts/、synthesis/……），你可以直接拿 Obsidian 打开它，也可以直接搜。
- ▪context-mode 走的是相反方向，而且是 9 个里唯一把「记忆有保质期」写进文档的：14-day cleanup: Content databases and sources older than 14 days are removed on startup.——另一处写着 If you don’t --continue, previous session data is deleted immediately — a fresh session means a clean slate.——不续会话就直接清空，新会话等于一张白纸。
这四个里没有一个是在偷懒。context-mode 是故意的：它的定位就是把上下文压到最小，主目录下那份 per-project SQLite 加 FTS5 索引被当成缓存而不是账本，所以它有权利删。但如果你以为「装上它就有长期记忆」，14 天这条会让你在某个周一早上发现上周那个项目查不到了。
判断方法很简单：看它的 README 有没有回答「索引删了记忆还在吗」。把 Markdown 定为唯一真相、索引只当缓存的那三家，合计 27,971 star，占这一族的 9.1%。剩下六家里，两家把记忆放进可插拔的图库与向量库（换后端等于换存储），一家把它放进一整套服务端基础设施（向量库加对象存储，八种后端任选），一家不存，还有两家落在本地 SQLite 上，其中一家会定期清理。
这条不是抽象的哲学问题。你的记忆载体决定了三件事的成本：备份（是 git push 一个目录，还是备份一个数据库加一个对象存储桶）、迁移（换工具时是搬文件，还是写迁移脚本）、审查（能不能直接打开看你的 agent 到底记了什么）。
错位三：一边承诺数据不出你机器，一边在同一页摆着计费路径
这一族最常见的卖点就是「数据是你的」。但以各仓库自己 README 上写明的计费路径为准，9 个里有 5 个在同一份文档里给出了要花钱的那条路。
- ▪context-mode 的隐私承诺是这一族最硬的：Nothing leaves your machine. No telemetry, no cloud sync, no usage tracking, no account required.——许可也卡得最死：Elastic License 2.0，作者自己解释了为什么不用 MIT：MIT permits repackaging the code as a competing closed-source SaaS，条款里明写不许 offer it as a hosted/managed service。但同一份 README 的命令清单里，躺着一条 context-mode insight # opens the hosted Insight dashboard in browser。
- ▪OpenViking 主项目是 AGPLv3——你要拿它对外提供托管服务，就得开源——而同一页面上是官方的两条商业路线：火山引擎托管的 SaaS，以及需要 license key 激活的自管理版（多了分布式部署与官方支持）。
- ▪semantica 打的是 Zero Vendor Lock-In，同一页面上挂着 getsemantica.ai 的企业版：on-prem、私有云、SLA 支持、面向金融医疗法律政府这类受监管行业。
- ▪OpenResearch 写的是 Local by default，创建项目、启动实验都不会发布你的代码；同一页面上，托管算力需要注册一个 openresearch.sh 账号，而且官方 release 构建默认发送遥测（opt-out, coarse usage events，可以 orx telemetry off 关掉；从源码构建的版本不发）。
- ▪markitdown 的内置转换器在对照表里标着 Local compute only，但同一张表里，接 Azure 的两条路径标着 Billable Azure API calls，还专门加了一句 Cost note。
五个，合计 255,634 star，占 83.5%。剩下四个——WeKnora（22,366）、llm_wiki（18,765）、ai-memory（6,562）、hyperresearch（2,644）——在我这一轮核过的 README 里没有找到计费路径。
这里要给一句公道话：这不是黑点。一个自托管项目要长期活着，得有收入来源；把托管做成生意，比把功能锁在付费墙后面体面得多——上面五个的免费版都能自己跑通全流程，付费买的是省运维和 SLA。真正值得在选型时多看一眼的，只是那条线画在哪里：免费版交付的是软件，还是软件的一个演示。（markitdown 那格要单独算：它的计费路径属于 Azure，是另一家产品，跟这个仓库本身无关。）
上手：9 条原命令
下面每一条都逐字取自各仓库 README 或官方文档，我没有改写：
# 1) microsoft/markitdown —— 只转换，不存状态 pip install 'markitdown[all]' markitdown path-to-file.pdf > document.md # 2) mksglu/context-mode —— 装进 Claude Code /plugin marketplace add mksglu/context-mode /plugin install context-mode@context-mode # 3) jordan-gibbs/hyperresearch —— 需要 Claude Code cd your-project pip install hyperresearch && hyperresearch install # 之后在 Claude Code 里用 /hyperresearch <anything> # 4) akitaonrails/ai-memory —— 两个命令接上 agent ai-memory install-mcp --client claude-code --apply ai-memory install-hooks --agent claude-code --apply # README 的例子用 docker，Podman 主机会自动切换 # 5) semantica-agi/semantica pip install semantica semantica doctor # 5 秒自检 # 6) volcengine/OpenViking pip install openviking --upgrade openviking-server init # configure providers and models openviking-server doctor # check configuration and connectivity openviking-server # start the server # 7) Tencent/WeKnora git clone https://github.com/Tencent/WeKnora.git cd WeKnora cp .env.example .env # Edit .env as needed, see comments in the file docker compose pull # Pull the latest images docker compose up -d # Start core services # 8) alphaXiv/OpenResearch（macOS / Linux） curl -LsSf https://openresearch.sh/install.sh | sh orx up # dashboard at http://127.0.0.1:4791 # 9) nashsu/llm_wiki —— 装包，不是装库 Download from Releases: - macOS: .dmg (Apple Silicon + Intel) - Windows: .msi - Linux: .deb / .AppImage
最后一条要单独说，因为它是这一期最具体的一个坑。llm_wiki 的 README 承诺 macOS 的 .dmg 覆盖 Apple Silicon 和 Intel。我拉了 releases/latest（v0.6.11，2026-08-25，prerelease=false）的资产清单：能读到的文件里，LLM.Wiki_0.6.11_aarch64.dmg 是 macOS 侧唯一一个 dmg，而 Linux 侧 aarch64 与 amd64 的 rpm、AppImage 都齐。README 承诺的 Intel 那个 dmg，没有出现在清单里。这类「文档里写了、包里没有」的落差，比 star 更适合当判断依据。顺带一提，这个仓库最近一次推送停在 2026-08-25，而它今天仍在日榜拿 +647——榜单热度和维护节奏是两件事。
我的判断
- ▪只想解决「文件喂不进去」：markitdown。一行装完，这一层没有更省事的，而且它的作用是全局的——任何记忆层前面都得先有这一步。
- ▪给 CLI agent 一个能自己读的记忆：ai-memory 最完整——Rust 单二进制、MIT、记忆是 git 化的 Markdown、官方明说零 LLM 调用也能跑全流程；hyperresearch 同样把 Markdown 当唯一真相，但要绑定 Claude Code 和 Anthropic 模型。
- ▪要一个能给人看的知识库：llm_wiki，因为它产出的就是 Obsidian 能直接打开的 vault。注意前面那条 Intel 的坑，以及仓库已经十八天没推。
- ▪要在团队或多租户里跑一套带权限的知识平台：WeKnora 或 OpenViking。WeKnora 的默认路径是 docker compose up -d 起一整套，官方文档覆盖约 360 个 API 端点、约 150 个环境变量、9 个扩展点，而且 README 里有条安全须知：别把服务直接暴露到公网，内部或私有网络部署。OpenViking 是 AGPLv3，商用前先确认你能否接受它的传染范围。
- ▪要把「决策」本身当资产存下来、还要能审计：semantica。它的推理引擎、知识图谱构建和溯源层官方声明是确定性的，no LLM is required to use them。
反过来，四类人要绕开：
- ▪用 star 当可靠性指标的人。这一族六成的 star 在一个不做记忆的仓库上。
- ▪以为「装上就有长期记忆」的人。context-mode 的索引 14 天自动清理，不续会话就立刻清空——它是压缩器，不是账本。
- ▪不想运维的人。WeKnora 和 OpenViking 的最小可用单位是一套服务，不是一条命令。
- ▪以为自托管就等于不联网的人。llm_wiki 要你配 LLM 供应商的 key 才能建 wiki，hyperresearch 跑的是 Anthropic 模型，OpenViking 要能访问 embedding 与 VLM。不过这一族里明确写了核心链路不需要 LLM 的也有两家：ai-memory 的原文是 Everything works with zero LLM calls，semantica 的原文是 no LLM is required to use them。
如果让我给一个动作顺序：先用 markitdown 把资料变成 Markdown，再挑一个把 Markdown 当唯一真相的记忆层（ai-memory 或 hyperresearch），等你确实需要多人协作或权限隔离时，才上服务端那一档。这个顺序的理由是——前两步的记忆都是你自己的文件，随时能走；第三步之后，换工具就变成了迁移项目。
数据来源：GitHub REST API（含 search API 批量取元数据）+ 各仓库 raw README / LICENSE + GitHub Trending 官方页 · 抓取时间 2026-09-12
9 个仓库 star 合计 305,971（API 实测）。Trending 页面同期快照与 API 存在差异，本文 star 一律取 API 值，不取其一冒充唯一真相。
许可：markitdown MIT（API 字段）· OpenViking AGPL-3.0（ov_cli 与 examples 为 Apache 2.0）· WeKnora MIT（README 与徽章声明）· context-mode Elastic License 2.0· llm_wiki GPL-3.0 · semantica MIT · ai-memory MIT · hyperresearch MIT · OpenResearch MIT
体量：最大 OpenViking 265,053 KB，最小 hyperresearch 1,755 KB，相差 151 倍；9 个仓库的 archived 与 disabled 全部为 false
未关闭 issue ÷ star × 100：WeKnora 3.33 最高，ai-memory 0.11 最低，跨度 31 倍（这个指标在第 53 期当过主线，这里只列数不展开）
创建时间跨度：最早的 markitdown 是 2024-11-13，最晚的 OpenResearch 是 2026-06-07，9 个里 6 个创建于 2026 年
你现在给 agent 存记忆用的是什么——Markdown 文件、一个数据库，还是干脆不用，每次重新交代一遍？留言说一个，我会挑有代表性的整理进后面某一期。
下一期：如果榜单出现高动量新面孔，回到单项目精读；如果仍然是零候选，再换一个主题族做合集。另外提一句，「把模型塞进小设备与边缘」那一族的预告还欠着，得等榜上凑够成员才写得动。
#Agent记忆#上下文工程#横向对比#GitHub趋势