多级上下文存储与渐进披露架构¶
核心判断¶
组织知识不应该只用一种形态承载。
更合理的模型类似存储层级：热数据直接进入当前上下文，稳定知识沉淀成 Markdown，较大规模材料进入搜索索引，超大规模或强权限业务数据保留在源系统，通过 Connector 按需读取。
Codex SDK、Claude Code SDK 这类底层 runtime 已经很擅长：
- 读文件。
- 搜索代码和文档。
- 调用工具。
- 多轮探索。
- 渐进披露。
- 发现信息缺口。
Harness 不应该复刻这些能力，而应该给这些 runtime 提供组织级上下文层级、权限边界、检索工具、知识提升流程和评测闭环。
上下文层级¶
| 层级 | 类比 | 内容形态 | 主要工具 | 适合解决的问题 |
|---|---|---|---|---|
| L0 当前任务上下文 | CPU register | 用户问题、当前计划、最近证据、正在编辑的文件 | Codex / Claude 当前会话 | 当前任务的即时推理 |
| L1 项目指令与工作记忆 | L1 cache | AGENTS.md、CLAUDE.md、任务规则、短期 memory |
runtime 原生上下文、配置、skills | 稳定工作方式和团队约束 |
| L2 编译后的 Markdown 知识 | L2 cache | docs/、vault/20-wiki/、ADR、索引页 |
rg、文件读取、链接跳转、Obsidian、MkDocs |
高价值、稳定、可审查知识 |
| L3 搜索索引与检索缓存 | L3 cache | BM25 / FTS / vector / metadata index | OpenSearch/ES、Postgres FTS/pgvector、rerank | 大规模文档、模糊查询、跨源召回 |
| L4 原始材料与业务系统 | disk / object store | 企微、GitHub、CRM、财务、项目系统、BI、原始文档 | Connector、MCP、API、ETL、权限视图 | 权威事实、实时状态、受控业务对象 |
| L5 人与组织网络 | external system | 负责人、审批人、项目 owner、群聊上下文 | 企微/飞书主动询问、组织目录 | 知识缺口、责任归属、未文档化判断 |
层级越靠上，越适合直接进入 Agent 上下文；越靠下，越需要索引、权限过滤、按需读取和审计。
为什么不是单一 RAG¶
单一 RAG 容易把所有问题都变成：
text
chunk -> embedding -> top-k -> prompt
这会限制强 runtime 的探索能力。Codex / Claude Code 风格的 agent 更自然的工作方式是：
text
先看目录和规则
-> 搜索关键词
-> 读相关文件
-> 换关键词再搜
-> 读取原文
-> 对比证据
-> 发现 gap
-> 必要时调用工具或询问人
所以 Harness 的知识层不应该只提供“一个 RAG 答案”，而应该提供一组层级化工具：
list_sources：知道有哪些上下文库。search：宽搜候选。grep/fts：精确查术语、编号、人名。semantic_search：查同义表达和模糊描述。read：读取原文、章节、对象详情。explain_rank：解释为什么命中。report_gap：把缺口写入维护流程。ask_owner：在权限和频率控制下主动询问相关人。
什么时候用摄取¶
摄取不是错，问题是不能把摄取当成唯一入口。
适合摄取的材料：
- 数量大，人工无法逐个阅读。
- 来源多，需要统一清洗和 metadata。
- 需要跨文档模糊召回。
- 需要按权限、时间、部门、项目过滤。
- 需要重复查询和评测。
不适合直接摄取成最终知识的材料：
- 临时群聊。
- 未 review 的会议结论。
- 权限不清楚的业务记录。
- 仍在变化的项目判断。
- 强依赖上下文的个人口头判断。
这些材料应该先进入 raw / inbox，再经过编译、review、提升，最后才进入 wiki、docs 或正式索引。
知识提升流程¶
推荐流程：
text
L4 原始来源 / L5 人的补充
-> capture 到 vault/00-inbox 或 vault/10-raw
-> normalize / clean / metadata
-> L3 index cache，便于搜索和发现
-> Agent 或人编译为 L2 Markdown wiki / ADR / project page
-> review 后发布到 docs
-> runtime 通过渐进披露优先读 L1/L2，必要时下探 L3/L4/L5
这个流程保留两种能力：
- 大规模材料可以先通过摄取建立可搜索缓存。
- 高价值知识最终沉淀成 Markdown，让 Codex / Claude 通过渐进披露稳定读取。
对当前技术路线的影响¶
第一，docs/ 和 vault/ 不是临时发布产物，而是 L2 编译知识层。它们应该保持可读、可链接、可审查。
第二，OpenSearch/ES、Postgres + pgvector/FTS 是 L3 检索缓存和索引层，不是最终事实源，也不应该替代 Markdown wiki。
第三，Dify、RAGFlow、Docling、MinerU 一类工具更适合承担 L3/L4 的解析、摄取和检索能力，不应该取代 Harness 的组织权限、知识提升和 runtime 编排。
第四，Codex SDK / Claude Code SDK 是 L0-L2 的强执行者。Harness 应该让它们优先使用目录、Markdown、搜索和原文读取，而不是只喂 top-k chunk。
第五，Context Router 的职责不是“一律路由到 ES”，而是决定当前问题应该停留在哪一层，还是逐级下探：
text
先查 L1/L2
-> 不足再查 L3
-> 仍不足再调用 L4 Connector
-> 仍不足再走 L5 主动询问
下一轮实验¶
后续 benchmark 应比较三种工作流：
| 工作流 | 描述 | 重点指标 |
|---|---|---|
| 渐进披露优先 | docs/vault + rg + read，模拟 Codex / Claude Code 原生探索 |
工具调用数、token、证据质量、是否能发现 gap |
| 预摄取 RAG 优先 | 先从索引 top-k 取证据，再回答 | Recall、误召回、过早摘要损失、权限风险 |
| 分层混合 | 先 L1/L2，必要时 L3/L4/L5 下探 | 成本、准确率、可解释性、更新成本 |
目标不是证明某一层永远最好，而是找出每一层的适用边界和切换条件。