渐进式披露

如果你纳闷过,为什么 omem query 回你的是一小段摘要而不是整篇文档;又或者你正打算把某个 agent 接到 OMem 上,还想让它别乱烧 token——这一页就是写给你的。我们会讲清 OMem 对外提供的四个细节层级,以及什么时候该用哪一层。

“全都给我”行不通

要把工作上下文喂给 agent,最省事的想法就是把整篇文档塞进它的 prompt。可这招根本撑不大:一份 PPT 动辄 8,000 token,一条邮件往来 5,000,一张表格 10,000。你只是想问一句”上季度预算定得怎么样”,一个不动脑子的系统为了从里头挑出真正相关的那份,会把十份文档一股脑全加载进来——agent 还没来得及想,80,000 个 token 就先烧没了。

为了判断一篇文档相不相关,就得把它从头读到尾——agent 本不该这样干活。它应该先扫一眼,只把真正用得上的那份打开。这就是渐进式披露。

四层,从最省钱的那层开始

OMem 把每一页都拆成四个细节层级对外提供。agent 从最便宜的一层起步,问题需要多深,它才往下钻多深。点开每一层,看看各自花多少、又给你什么:

L0 视图

Q3 预算已签署：利润率 12%（从 9% 上调）；Bob 同意。

每条命中给一句话摘要。agent 扫一眼就能判断相不相关，什么都不用打开。

大多数问题,在 L0 加 L1 这两层就解决了,加起来也就 2,000 token 上下。agent 先扫一遍 L0 摘要,锁定那一页,在 L1 把它打开,答案就出来了。L2 和 L3 留着应付那些”整理好的页面确实不够看”的场合:agent 要的是表格里某一行确切的数据、某张图的细节,或者干脆就是原生格式的原始文件。

这套思路借鉴了字节跳动的 OpenViking——是它最早把”分层加载上下文”用到了 agent 身上:先扫 L0,在 L1 想清楚,真要用了才加载完整内容。OMem 把同一套规矩搬到了办公数据上:用不到的深度,就别为它花钱。

为什么 L0 几乎不要钱

你可能会担心:给每一页都配一句话摘要,不也得调一次 LLM 吗?确实要,但这笔钱早就花掉了。那句 L0 摘要,是生成 L1 wiki 页的同一道整理工序里顺手写下来的。那会儿完整文档本就摆在 prompt 里,再捎一句”另外给我一句话总结”,几乎不多花什么。等你真去查的时候,L0 已经是数据库里现成的一个字段,不用读文件,也不用调 LLM。

没有 L3 的时候

不是每一类工作都有”原始文件”可言。一个 file 页(比如一份 .docx、一份 .pdf)有,L3 就把原件打开给你。可一个 mail、calendar 或 loop 页,磁盘上压根没有单独一个文件能打开。这时候,L3 会自动退回到 L2:解析出来的那份 Markdown 就是手头能拿到的最完整视图,而且它也确实够用——整条往来、整场日程,连图里的内容都已经描述进去了。

这是故意这么设计的。agent 对一封邮件去要 L3,OMem 不会报错,也不会两手一摊,而是把现存最丰富的那一层递给它。agent 永远不会撞上死胡同。

这几层是怎么来的

渐进式披露不是后来硬塞进去的功能,它是 OMem 存储方式自然长出来的结果。底下那三个存储层(raw/ 归档 → 整理后的 wiki/ → 各种索引)几乎跟披露的这几层一一对上:

L0 和 L1 都在 wiki 里(摘要是页面上的一个字段,页面本身就是那个文件)。
L2 是解析器的产物,躺在不可变的 raw/ 归档里。
L3 就是原始来源,在你磁盘上它本来待的地方。

所以等你读到 wiki 即真相和摄入生命周期时,把这层对应关系记在心里:存储怎么分层,披露就怎么分层,本来就是同一件事。