架构总览

OKS 不是一个单独的“记忆插件”。它是一套让 用户、Agent、文件化知识、收录能力和交付能力各自做对的事的工作架构。

OKS 三段式架构：来源经过能力选择、证据片段、Manifest 和 raw-commit，进入 Raw Bundle、Candidate、人工审核和 Wiki；中段是 profiles、raw、drafts、wiki、mail 五个桶与 settings、_meta、security、Trace；下段是 6+1 因子召回与上下文注入，飞书和 Office 为可选入口与交付能力。

怎样读这张图

先看第一段摄入流水线：Source 经过模态判断、Provider、EvidenceFragment、Manifest 和 raw-commit，才形成可追溯的 Raw Bundle；Agent 可以据此提出 Candidate，但只有人审核后才进入 Wiki。

第二段是文件工作区和运行时：

profiles/ 放稳定的用户、项目、Recipe 和 Goal；
raw/ 放原始来源与机械提取结果；
drafts/ 放 Agent 的 Candidate；
wiki/ 只放人审后的可复用知识；
mail/ 与 Trace 留下协作和执行证据，但不冒充长期知识；settings/、_meta/ 和 security/ 提供配置、Schema 与脱敏边界。

oks CLI 负责文件操作、召回和状态，不在核心中调用模型 API；Agent 根据 Recipe、Provider 和 Capability 选择网页、PDF、Office、图片、音视频等处理能力。明确要交付文件时，Office 工作流才会接手 Word、PDF、PPT 或 Excel。飞书的 Base、表单与 IM 审核是可选参考实现：它可以承担采集和移动审核入口，但不属于 CLI 核心，也不会绕开人审门。

第三段是召回与注入：Query 先经过 scope / goal 约束，再由 6+1 因子评分、搜索后端、过滤去重，最终把已审核的 wiki/ 和必要的 raw/ 注入下一次任务。相关性只能影响排序，不能把材料升级为事实。

需要深入时

这张图把系统层级和实际能力放在一起，但没有展开协议字段与评分公式。需要进一步实现或排障时：

想收集不同类型的材料，阅读收集来源。
想理解审核和晋升，阅读审核候选。
想了解召回如何选择知识，阅读召回与注入。
维护者需要完整文件桶、只读 VFS、Hooks 与可选飞书集成时，阅读宪法（A1-A5）和参考手册。

架构边界

Raw 不等于 Wiki：Raw 保留材料和机械提取；Wiki 是经人审核、能在后续任务中复用的知识。
VFS 不是新知识桶：oks:// 只提供受限的只读访问视图，不会绕开文件治理。
Hooks 和飞书是可选入口：它们可以改变收集或反馈的位置，但不会取消人工审核。
信任来自证据和审核：[verified] 只应来自 Trace 证据或 human_reviewed_at，而不是使用次数。