跨领域融合

从 PKM 到 Brains：让知识库在规则中持续进化

将个人知识库从单纯笔记工具演进为分层 Brains 的思路与实践，包括输入层、知识层、输出层的设计与 agent 修改边界。

2026-04-13约 5 分钟阅读
#domain #PKM #LLM #wiki

年初我把 Logseq 换成 VSCode + Foam 的时候，脑子里最先冒出来的感觉是：知识库这件事变了。存储开始变便宜，判断开始变贵。这也是我把 PKM 升级成 Agentic Brains 的原因：它不再只是一个存储系统，而是一个在约束中持续进化的知识系统。

眼看 Logseq 更新越来越少、越来越慢，我原本只是想换一个更方便接入 Copilot 的地方。结果发现，要动的根本不是工具，而是整个工作流。虽然 VSCode + Foam 在 Query 和任务管理上不如 Logseq 顺手，但它让我更自然地把 AI 接进写作、整理和提炼流程。

这件事背后的变化很直接。过去做知识管理，我更关心存储、检索、关联；现在 AI 让知识获取的边际成本接近于零，重点就转成了思考、提炼和决策。比如以前我要自己摘录、整理、建双链；现在很多原始材料只要保留链接、对话或草稿，真正需要我投入的，是判断它是否值得进入知识层。

前段时间 Karpathy 的 “LLM Wiki” 在社区里很火，也正好补上了我这套系统里卡住的那一块：把“编译”这件事显式放进知识库更新流程。四处抓取的网页、AI 的聊天记录、agent 从一句话生成的内容，都只是输入层材料；它们只能在明确规则下，被编译成知识层的结果。这样知识库才会越用越准，而不是越用越乱。

Brains 的最小架构 ​

mermaid
flowchart TD
  subgraph I[输入层]
    raws[raws/]
    journals[journals/]
  end

  subgraph K[知识层]
    pages[pages/, pages/OKR/]
  end

  subgraph O[输出层]
    outputs[outputs/, outputs/blogs/]
  end

  subgraph R[规则层]
    agents[AGENTS.md]
    soul[SOUL.md]
  end

  raws --> synth[整理 / 提炼 / 选择]
  journals --> synth
  synth -->|编译后升级| pages
  pages --> outputs
  agents -.边界.-> synth
  soul -.风格.-> outputs

我现在把知识库拆成四层，这样每一层的职责都很清楚：

  • 输入层：raws/、journals/。放原始信息、随手记录、未整理材料。这里强调保真，不强调结构。
  • 知识层：pages/、pages/OKR/。放已经被提炼、合并、去重后的长期知识。这里才允许 agent 在规则内修改。
  • 输出层：outputs/、outputs/blogs/。放对外表达的内容，服务写作、分享和复用。
  • 规则层：AGENTS.md、SOUL.md。前者定义全局边界，后者定义个性化偏好，让 agent 知道“能做什么、不能做什么、应该像谁一样写”。

和 Karpathy 的思路类似，我先把原始数据和知识明确分开，再规定 agent 只能修改知识区里被授权的内容。这样做的目的在于给进化过程加护栏，避免系统被自己的自动化能力反噬。

mermaid
flowchart LR
  raw[原始材料：网页 / 聊天 / 草稿] --> compile[规则内编译]
  compile --> evidence[证据层]
  evidence --> page[长期知识页]
  rule[AGENTS.md / SOUL.md] -.约束.-> compile
  agent[agent] -.仅可写.-> page

规则怎么落地 ​

光有目录结构还不够，关键是把“谁能改什么”写成规则。我的做法很简单：输入区尽量保留原样，知识区和输出区按工作流授权修改，规则文件集中管理。

为了让这套规则易于维护，我把 agent framework 拆成三类：

  • Role / instruction：定义角色边界，说明什么能做、什么不能做。
  • Command：定义工作流，说明怎么做、输入输出是什么。
  • Skill：定义可复用能力，说明 agent 在什么场景下可以调用哪些能力。

这套拆分的好处很具体：

  • 想调整输入输出格式，改 command。
  • 想修改知识页治理规则，比如增加 expire 规则或 conflict 记录，改 instruction。
  • 想新增检索、写作或分析能力，改 skill。
  • 想统一更新全局约束或个性化偏好，改 AGENTS.md 或 SOUL.md。

我额外还要做 OKR 管理和博客写作，所以在这套框架里又补了对应的输入输出和规则。这样一来，知识库、计划系统和内容生产都落在同一个 Brains 里，只是分属不同工作面。对我来说，这样拆开以后，边界反而更清楚了。

为什么这比传统 PKM 更适合 AI 时代 ​

传统 PKM 的默认前提是：人负责整理，工具负责存储。Brains 的前提正好相反：存储和初步整理越来越便宜，真正昂贵的是判断、连接和迭代。

先说最直接的一点：AI 把实现成本压低之后，思考本身反而更值钱了。过去一个想法从出现到验证，中间隔着资料收集、方案整理、原型实现；现在很多步骤都可以先交给 AI 起草，你只需要更快判断这个方向值不值得继续，再决定怎么迭代。也就是说，瓶颈不再是“做不出来”，而是“该做什么”。

我现在碰到一个新想法，通常会先丢进 journals/ 或原始记录里，让 AI 帮我做初筛；只有它反复出现在 OKR、写作或项目里，我才会把它整理进 pages/。存储动作确实变轻了，但判断动作反而变重了。

再往下看，单纯的知识存储其实也在快速贬值。以前我们需要花很多力气把资料摘录、归档、分类，因为找不到就等于没有；现在很多信息即使不完整存档，也可以通过搜索、对话和上下文临时重建。真正稀缺的，反而是你能不能把看似无关的内容连起来。

这也是为什么跨领域链接反而更重要，因为 AI 还不会主动替你建立长期、稳定、带偏好的连接。它可以回答“这是什么”，也可以补全“下一步怎么做”，但它不会天然知道为什么我会把 OKR、博客写作、知识页治理放在同一个系统里，也不会天然知道某条原始记录为什么值得升级成长期知识。这部分仍然需要人来定义连接规则。

当然，这不等于存储不重要。对研究、合规、资料归档这类场景来说，原始材料的完整保存仍然很关键。我的判断更适用于另一类系统：需要持续提炼、持续产出、持续迭代的知识系统。

说到底，Brains 只是把一件事说清楚了：AI 负责把实现成本打下来，人负责决定什么值得留下、什么应该连接、什么可以被改。我的判断是，规则的作用就是保住知识库的方向感。