运行时渐进披露与上下文访问路径¶

核心校准¶

本页保留“多级上下文”的工程经验，但不再把 L0-L5 当作知识形态分层。

Evidence 原始证据层
  -> Ontology 本体层
  -> Runtime Projection 运行时投影层

原始资料统一属于 Evidence；Markdown、ADR、实验报告、Skill、权限视图和知识卡片都属于 Ontology 中的对象或制品；搜索索引、MCP、Connector、企业微信消息和主动询问属于 Runtime Projection 的实现手段。

因此，本页只回答一个问题：Agent 在运行时应该如何渐进披露上下文。

运行时访问路径¶

步骤	作用	内容形态	主要工具
D0 当前任务上下文	当前问题、目标、计划、最近证据、正在编辑的文件	会话上下文、临时 artifact	Codex / Claude 当前会话
D1 入口索引	告诉 Agent 该读什么、用什么 Skill、受什么规则约束	`AGENTS.md`、导航页、task skill manifest	runtime 原生上下文、Skill 触发
D2 稳定知识制品	人和 Agent 都可读的高价值知识表达	Site、Knowledge wiki、ADR、实验报告、runbook	`rg`、文件读取、Obsidian、MkDocs
D3 检索投影	大规模资料的候选召回、排序、rank log 和成本观测	BM25 / FTS / vector / metadata index	SearchConnector、Postgres、OpenSearch/ES
D4 证据读取	按权限回查原始资料或业务系统对象	raw source、网页快照、业务对象、代码仓库	Connector、MCP、API、Tool Gateway
D5 主动补充	证据不足时询问人或系统，并把回复沉淀回本体	ask event、callback、knowledge card	Ask Router、企业微信、Callback Ledger

D0-D5 是运行时访问路径，不是知识价值排序。比如原始证据在运行时可能较晚读取，但它始终是证据底座；Skill 在运行时可能先触发，但它属于本体中的可执行知识对象。

旧 L2/L3/L4 不是被废弃¶

旧口径里的 L2/L3/L4/L5 仍然对应一组真实技术难点：

L2 的 Markdown / docs / vault 能力，变成 Ontology artifact 的生产、review、发布和 D2 运行时读取问题。
L3 的 ES / OpenSearch / Postgres / embedding 能力，变成 D3 检索投影的 adapter、rank log、权限过滤、stale projection 和成本问题。
L4 的源系统和原始材料，变成 Evidence 保真、provenance、Connector 回查、权限裁剪和 D4 证据读取问题。
L5 的人与组织网络，变成 owner registry、Workspace Topology、Ask Router、节流、回调和 D5 主动补充问题。

新模型只是把“知识形态”和“运行时访问顺序”拆开，避免把搜索索引误当事实源，或把原始资料误放到某个更高的资料层。

为什么不是单一 RAG¶

单一 RAG 容易把所有问题都变成：

chunk -> embedding -> top-k -> prompt

这会限制 Codex / Claude Code 这类强 runtime 的探索能力。更自然的 Agent 工作方式是：

先看入口规则和任务 Skill
  -> 读稳定知识制品
  -> 搜索候选
  -> 回查证据原文
  -> 对比来源和权限
  -> 发现 gap
  -> 必要时主动询问
  -> 把补充信息写回 Evidence / Ontology

Harness 的价值不是替代底层 runtime，而是提供组织级本体、权限、索引、工具边界、主动补充和评测闭环。

什么时候用入库¶

入库不是 search 的同义词。入库是把外部资料或原始上下文进入 Evidence / Ontology / Runtime Projection 的处理过程，包括清洗、结构化、抽取、本体映射、索引和 review。

适合入库的材料：

数量大，人工无法逐个阅读。
来源多，需要统一 metadata、权限和 provenance。
需要跨文档模糊召回。
需要按部门、项目、人员、时间和权限过滤。
需要重复查询、评测和审计。

不适合直接提升成正式知识的材料：

临时群聊。
未 review 的会议结论。
权限不清楚的业务记录。
仍在变化的项目判断。
强依赖上下文的个人口头判断。

这些材料可以先进入 Evidence 和 inbox，再由本体抽取、人工 review 和运行反馈决定是否提升为 Markdown、Skill、ADR、知识卡片或索引对象。

知识提升流程¶

推荐流程：

Evidence 原始证据
  -> capture 到 workspaces/variai/evidence/inbox 或 workspaces/variai/evidence/raw
  -> normalize / clean / metadata / permission
  -> extract ontology objects / relationships / rules / actions
  -> 形成 Markdown、ADR、实验报告、Skill、knowledge card 等本体制品
  -> review 后发布到 Site 或进入可检索索引
  -> Runtime Projection 按任务和权限组合最小上下文包
  -> 使用中发现 gap，再回到 Evidence / Ontology

这个流程保留两种能力：

大规模材料可以先通过入库建立可搜索投影。
高价值知识最终沉淀成本体制品，让人和 Agent 都能审查、复用和渐进披露。

对当前技术路线的影响¶

第一，workspaces/variai/site/ 和 workspaces/variai/knowledge/ 不是临时发布产物，而是本体层的可读知识制品。它们应该保持可读、可链接、可审查。

第二，任务技能包不是 L1/L2 旁支，而是本体层的可执行知识对象。它们需要 manifest、gotchas、验证命令、适用边界和使用日志。

第三，OpenSearch/ES、Postgres + pgvector/FTS 是 D3 检索投影，不是最终事实源，也不应该替代 Evidence 和 Markdown。

第四，Dify、RAGFlow、Docling、MinerU 一类工具更适合承担解析、入库和检索投影，不应该取代 Harness 的本体、权限、知识提升和 runtime 编排。

第五，Context Router 的职责不是“一律路由到 ES”，而是根据本体、权限和任务判断当前问题应该停留在 D1/D2，还是下探到 D3/D4/D5：

先查入口规则、Skill 和稳定知识制品
  -> 不足再查检索投影
  -> 仍不足再读取原始证据或业务系统
  -> 仍不足再走主动询问

第六，原始资料不再被描述成“L4 层”。原始资料始终属于 Evidence；D4 只是运行时回查 Evidence 或业务系统的动作。

下一轮实验¶

已有 context_layer_benchmark 比较三种工作流：

工作流	描述	重点指标
渐进披露优先	`Site/Knowledge + rg + read`，模拟 Codex / Claude Code 原生探索	工具调用数、token、证据质量、是否能发现 gap
预入库 RAG 优先	先从索引 top-k 取证据，再回答	Recall、误召回、过早摘要损失、权限风险
分层混合	先 D1/D2，必要时 D3/D4/D5 下探	成本、准确率、可解释性、更新成本

下一步要把实验指标从“层级是否命中”升级为“本体投影是否正确”：

投影出的上下文是否最小充分。
是否能从 Markdown、Skill、SearchConnector 命中追溯到 Evidence。
是否能在权限变化、删除、supersede、项目归档后阻断 stale projection。
是否能把主动询问回复写回 knowledge card、review、registry 和索引。

当前结果见：Context Layer Benchmark：多级上下文访问对照实验。