插件架构

如果你想知道 OMem 到底有多能扩展——它有哪几类插件、每一类下面又发了哪些、v1.0 的边界究竟划在哪——这一页讲清楚。

插件优先,从第一天就是

OMem 从一开始就是当成平台来建的:摄入流水线的每一步,都插在一个第一天就定好的接口上,而且每个接口都至少配着一个真在跑、真发出去了的实现,没有一个是”以后再说”的空壳。这么做的意义,不是逼你非得去扩它,而是这套架构不会把你困住。你想加个 source、换个 index,或者(往后)把某个 parser 整个替掉,都不用把其余部分推倒重来。

四个扩展点——以及每一类下面的插件

扩展点一共有四类。往下滚,挨个看一遍,顺带看看 OMem 在每一类下都发了哪些具体插件:

扩展点 · source

Source 决定你的工作从哪里来。

Source 负责读取要摄入的条目。每一类工作都有一个对应的 Source——日后想接入新的来源（Slack、Jira……），无非再加一个 Source，OMem 的其余部分原封不动。

local-filesv1.0你指给它的任何文件夹——OneDrive、Box、Dropbox、iCloud、Downloads。

mail-appv1.0Apple Mail 的本地存储；每条会话聚合成一个页面。

calendar-appv1.0Apple Calendar——Exchange、iCloud、CalDAV 都从这里汇入。

loop-resolverv1.0Microsoft Loop / Fluid 会议笔记，从 SharePoint 取回。

ics-filev1.0独立的 .ics 日历文件。

outlook-classic / -web / -applescriptv1.5+接入 Outlook 邮件与日历的其他几条路径。

扩展点 · parser

一种格式一个 parser——办公里用到的格式一个都不落下。

每种格式都有专属的 parser，把它转成干净的 Markdown，留住通用转换器会丢掉的那些部分。这份覆盖广度，正是 OMem 那个不张扬却拉开差距的地方。

docxv1.0Word——标题、列表、表格、内嵌图片，还有修订痕迹和审阅批注。

pptxv1.0PowerPoint——逐张幻灯片、演讲者备注、内嵌图表。

xlsxv1.0Excel——工作表转成 Markdown 表格，内嵌图片也保留。

pdfv1.0PDF——数字版按版面解析，扫描版走 OCR。

eml / msgv1.0邮件文件，邮件头、正文、附件都在内。

htmlv1.0网页 / 邮件 HTML → 干净的 Markdown。

icsv1.0日历事件数据。

imagev1.0PNG/JPEG/HEIC/……通过 OCR 加视觉模型来描述。

plain-text / markdownv1.0直接透传，结构保留。

parser-llmv1.5+整文件交给 LLM 解析，在版面与可复现之间偏向版面。

扩展点 · index

索引是查询找到页面的方式——而且可以替换。

检索层只是覆在 wiki 之上的一种看法，从来不是真相本身。一条命令就能换；只有索引会重建，你的 wiki 原封不动。

fts5默认SQLite 全文搜索 + jieba 中文分词。快，零配置。

qmd可选BM25 + 本地向量 embedding + reranker 的混合方案，支持语义与跨语言搜索。

扩展点 · wikistore

页面存放在哪里——这一层留好了接缝，给以后用。

把话说准：接口已经存在、也很干净，但 v1.0 只发布一个实现，没有切换机制。它目前还只是纸面上的扩展点——四个扩展点里，另外三个才是你今天就能动手用的。

DiskWikiStore预留磁盘上的 Markdown 文件 + SQLite 元数据。v1.0 唯一的那个实现。

数目得说准,因为这事太容易吹过头:其中三类今天就能插拔(Source、Parser、Index),还有一类架构上定义好了、但暂作预留(WikiStore——接口很干净,可 v1.0 只发了一个实现,没留切换的口子)。说”四个扩展点”,纸面上没错;但落到能不能动手,现在能动的是三个。

这给你带来什么

加新 source,不必动核心。 一个 file / mail / calendar / loop source,说白了就是 Source 接口的一个实现。往后想接 Slack、Jira、Linear,加的也是一个新 Source,parser、index、wiki 那几层一动不动。
检索这一层是你选的,不是用来把你绑死的。 v1.0 默认发的是 fts5(SQLite FTS5 加 jieba 中文分词),是个真正好使的默认值。想要混合向量搜索?一句 omem plugin enable qmd,就换上一套 BM25 + 本地 embedding + 重排器的栈。它是把 fts5 整个换掉,不是跟它掺到一起,边界很干净,而且只重建索引,你的 wiki 半点不受影响。
解析链能往前走。 现在它是确定性的(不碰 LLM)。但接口给未来留了余地:以后可以为 file kind 插进一个 parser-llm,给那些更看重版面理解、不那么在意归档可复现的人用,而这不会动到流水线其余部分赖以工作的那份契约。

CLI 才是真正能扩展的那个面

还有第五种可扩展性,它没画进那张图,因为它在更高一层:omem CLI 才是那个说了算的接口,每一个 agent 集成,都只是它薄薄一层封装。 OMem 的 skill 不过是大约 30 行 shell,转头去调 omem query;MCP server 也一样,是给任何 MCP 客户端用的一层薄壳。agent 这一层说变就变——去年最火的 agent,明年未必还是——所以 OMem 赌的是:底下那层记忆,不该被绑死在今天这个 agent 上。这一侧的事,从 agent 查询里讲。

没什么能把你锁住

正因为 wiki 就是你磁盘上一堆纯 Markdown、每种格式都是开放的,所以这套东西除了能插拔,还顺带能搬走:备份它、给它做版本控制、手动改一页、把它指到另一台机器上,都行。扩展点让软件保持开放,Markdown 落盘这件事让你的数据保持开放。Andrej Karpathy 说过,LLM 读得懂的 wiki 是 AI 原生技术栈里的一块基本构件——设计原则 P3 正是这个想法落地的地方。

接下来

接着看设计原则——那八个想法,讲的是架构为什么长成这样,包括为什么 wiki 是真相,以及为什么解析器偏偏不用 LLM。