← QQ星
AI 落地实战 · 旗舰案例

Personal Knowledge Harness

一个把自己当用户的 AI 产品——
从「知识散落、读完就忘」到「三层知识库 × 多 agent 共用记忆」

2026.04 起源 ─── v1 两层 ─── 上下文危机 ─── v2 三层重构 ─── 治理迭代 ─── 产品化

↓ 滚动进入故事
02 · 起源 · 2026.04 – 05

两条学习线,汇成一个想法

问题

课程、对话、笔记散落各处;读完就忘;复盘从不沉淀成可复用的东西。

思考

拆 Claude Code 源码 → 看懂 harness 工程:核心不是让模型更聪明,而是决定给它塞什么上下文、何时塞、塞多少。学 RAG → 掌握检索增强:知识不必全塞进去,按需检索。

决策

搭一套 Personal Knowledge Harness。目标不是「知识管理」,是「个人工作代理」:持续替我做 PRD、原型分析、竞品分析、复盘,还能发现自己哪里不够好、继续调整。

源码方法论篇
Claude Code 源码 → Harness RAG 学习 → 检索增强 个人知识 Harness
图:源码学习 × RAG 学习 → 一个产品想法
03 · v1 · 两层架构尝试

知识卡片 + 原始对话:Parent Document 的土实现

思考

都放 wiki 下,分两层:知识卡片(工作方法论 / RAG 学习)负责日常加载;claude-sessions 原始对话保底——卡片说不清时回查原文。这正是 RAG 里 Parent Document 的思想。

决策

把重复工作 skill 化(竞品分析 / PRD / 深度阅读…),知识卡片作为 skill 的上下文传入。

竞品分析 PRD skill 深度阅读 wiki / 知识卡片层 工作方法论 · RAG 学习 · 结构化沉淀 卡片不够 → 回查 wiki / claude-sessions 原始对话层 保真兜底 · 完整上下文证据 Parent Document 思想
图:skill → 卡片层 → 兜底回查原始对话
04 · 危机 · 2026.06

skill 越多、沉淀越勤,上下文越爆炸

问题

skill 涨到 73 个,每次复盘都在沉淀新卡片、新规则 → 索引退化成目录清单,规则互相打架,每次任务塞进的上下文越来越大。

思考

这不是「存」的问题,是「用」的问题——存下来 ≠ 能按需取出来。能力层正在退化成第二份知识库。

"卡片数量增长后,任务域 README 变成目录清单,召回噪音更大;规则越来越多,agent 不知道该听哪条。" —— 摘自当时的问题记录
上下文预算线 4月 5月 5月末 6月初 6月中 爆炸 ⚠ 每次任务加载的上下文体积(示意)
图:沉淀越勤,单次任务上下文越接近失控
05 · v2 · 三层重构 · 2026.06.17

加一个控制层,管住「怎么用」

决策

重构为三层:原文层保真(输入带状态流转),正式知识域复用(领域 → 任务域两级,工作只是 v0 首个领域,为理财 / 心理学 / AI 漫剧预留),能力层管加载。

"原文层保真,正式知识域复用,能力层管 agent 怎么变聪明。"
思考

两层管「存」,第三层管「用」——这层才是 harness 的本体。否掉的方案:「学习沉淀层」是加工过程、不配做长期一层;旧 wiki 不搬家,降级为 legacy 只读源,高频卡渐进迁移。

Before · 两层 知识卡片 原始对话 只解决「存在哪」 After · 三层 能力层 ★ 新增 路由索引 · 加载规则 · 沉淀确认 正式知识域 领域 / 任务域 · 可复用卡片 原文层 保真 · 待整理→已拆卡→已归档 「存」之上,多了「怎么用」的控制层
图:两层 → 三层,增量是控制层
06 · 深入 · 能力层 = 控制面

能力层解剖:agent 的操作系统

问题

三层目录只回答了「知识放哪」;「加载什么、何时加载、加载多少」仍然没人管。

思考

这正是 harness 的原始命题。能力层不是又一个装知识的文件夹,而是 agent 的操作系统层:输入进来,控制面负责路由、权限、压缩、沉淀、复盘、prompt 组装,执行层才动手。

决策

拆成六个子域:路由索引 · 上下文加载规则 · skill 工作流 · 自我成长规则 · 用户偏好与协作协议 · 工具接入与排障——个人偏好也进这层:它不是业务知识,是影响所有任务的控制规则。加载永远四级渐进、从不全量:能力层自己也可能变成污染源。

"知识库的目录只是表层,真正要搭的是控制层。" —— v2 架构设计文档
输入层 原文 · 卡片 · 用户问题 · 工具结果 控制面 ★ 由能力层承载 路由 权限门槛 压缩 沉淀 复盘 prompt 组装 执行层 skill · 检索 · 拆卡 · 写入 · 复盘生成 渐进式上下文加载 · 从不全量 常驻小内核 任务主域 触发式辅助域 沉淀路由
图:输入 → 控制面(六项职能)→ 执行;下方为四级渐进加载链
07 · 索引治理 · 2026.06.24

文件不会丢,丢的是找回的路径

问题

写入一直成功,找回越来越难——新材料、新卡、新规则,未来的 agent 只能靠记忆、全文搜索或碰巧想起路径。

思考

索引不是目录,是 agent 的加载控制面:只管路由 · 状态 · 候选 · 预算,不写全文摘要——摘要每个文件等于又造一份要维护的知识库。本质是一套 file-system RAG:目录和索引当检索器,skill 每次只带 2–5 张卡;向量库留给未来规模变大再说。

决策

三层对称的双入口:README 当门面,00-索引 当控制台;立「三层索引维护规则」:任何 skill 写任何一层,必须同步更新索引并在产出里报告。治理同时延伸到 skill 入口——prd / 竞品 / digest 等 skill 若写死旧路径,系统就会退回旧库。

四个不要:不全量搬旧库 · 不给每个目录建复杂索引 · 不把索引写成全文摘要 · 不因为学了 RAG 就上向量库 / Dify。
原文层 正式知识域 能力层 README · 门面 README · 门面 README · 门面 00-原文层索引 待整理→已拆卡 状态流 00-正式知识域索引 按问题路由到卡片 00-能力层索引 小内核 vs 按需规则 三层索引维护规则(统一) 写入任一层 → 同步更新索引 → 产出中报告 卡片级路由 · frontmatter load_when / avoid_when / priority / status
图:README 门面 + 00 控制台——最初正式知识域缺 00 索引,被一次对称性纠偏补齐
08 · 准入门禁 · 2026.06.30

架构对了还会胀:给写入加门禁

问题

三层落地后卡片仍在增长——增长本身会破坏路由和索引。

决策

写卡前先过准入五问:会复用吗?会改变判断吗?能被路由吗?已有卡能承接吗?会污染上下文吗?再定六去向;同时给加载设预算:正式卡每次 2–5 张,能力层规则 1–3 条。

候选知识(每次复盘产生) 准入五问 复用?改判断?可路由?旧卡可承接?污染上下文? 新增 追加旧卡 合并 暂缓 丢弃 留原文层 加载预算:正式卡 2–5 张 · 能力层规则 1–3 条
图:候选 → 准入五问 → 六去向 + 上下文预算
09 · 产品化 · 多 agent 共用记忆

一份记忆,所有 agent 共用

思考

知识库不该绑死某一个工具——Claude、OpenClaw、Codex 都是消费者,记忆应该是基础设施。

决策

真值源收敛到 Obsidian Vault + 共享 skill 目录;memory-loader 按任务生成 context-pack:任务 · 路由依据 · 候选 · 最终加载 · 未加载原因 · 风险。它不是第四层知识库,是用完即走的操作层。

Obsidian Vault 三层知识库 · 真值源 + 共享 skills Claude Code OpenClaw Codex context-pack ↓ ↓ context-pack
图:多 agent 连向同一记忆中枢,按需取最小 context-pack
10 · 成果 · 与下一步

数字,和一个没有终点的时间轴

73共享 skill
16正式知识卡
26能力层文档
16原文层沉淀
3agent 共用记忆
踩坑

frontmatter 一度设计过重;索引维护成本被低估——后来才补了三层索引维护规则。

认知

这套知识库不是为了让模型「知道更多」,而是让它每次只看该看的最小上下文——本质是上下文工程:塞什么、何时塞、塞多少。

v0 两层 ── v2 三层 ── 治理 ── 多 agent ── v3 …(迭代进行中)