OMem 本地工作记忆

要解决什么问题

工程师日常上下文散落在邮件、日历、本地文件夹、Teams Loop 等渠道里。用户问「上周和 Alice 关于供应商续约定什么了」「Acme 合同里 SLA 违约金具体是多少」时，模型若没有本地工作记忆，只能猜或让用户自己翻记录。

OMem 把这些工件抽象成统一的本地 wiki，Agent 查的是索引后的页面，而不是逐个打开原始应用。

技能如何工作

何时调用：问题涉及同事/项目/会议/文档/「当时怎么定的」等与工作历史相关的内容时，优先 omem query；天气、通用编程、公开常识则不必调用。不确定时宁可查一次——空结果成本低，漏查成本高。

四级渐进披露（够用即停）：

• L0：omem query "..." --format json --limit 20，约 2k token，先看摘要池
• L1：omem page get <page_id>，wiki 正文，多数问题在此结束
• L2：omem raw get <page_id> --parsed 再 Read parsed.md，补表格行、合同条款等细节
• L3：原始文件路径，仅在二进制格式必须保留时使用

后端 score 只做候选排序，Agent 应读完约 20 条 abstract 后自行 rerank，再拉 1～3 个最相关页面。列举类需求（如「上周所有会议」）用 omem wiki ls 加 --kind / --since / --search，与模糊检索的 query 分工不同。

回答须标注来源：[source: <page_id>] 或 raw 路径。

边界与注意

不要执行 omem setup、ingest、index rebuild 等会改环境的命令；若报错，转述给用户自行处理。不要编造 page_id；不要跳过 L1 直接读 parsed；跨后端不要比较绝对分数，只看单次查询内的排序。