---
title: llm-wiki-obsidian-wiki-gbrain-self-organization-self-evolution
source_url: https://mp.weixin.qq.com/s/48XpgAMHeaKYj26PrJK-hw
publish_date: 2026-05-13
tags: [wechat, article, claude, openai, agent, harness, rag, coding, llm, kiro, openclaw, gemini]
review_value: 7
review_confidence: 7
review_recommendation: neutral
ingested: 2026-05-16
sha256: 07092d9bd205dd1b43801d05800466d27ddd15de052fa6d6f9ca8fa3db2560bf
---
深度解析LLM Wiki / Obsidian-Wiki / GBrain：Agent时代知识的"自组织"与"自进化"
飞樰 阿里云开发者
2026年5月13日 08:30 浙江
阿里妹导读
本文是「项目深度解析」系列的第4篇，系列文章为《深度解析OpenClaw》、《深度解析Claude Code》、《深度解析Hermes Agent》。（文章内容基于作者个人技术实践与独立思考，旨在分享经验，仅代表个人观点。）
背景
不知不觉，本文已经是深度解析系列的第四篇了。上一篇解析文章《深度解析 Hermes Agent 如何实现"自进化"及其 Prompt / Context / Harness 的设计实践》在发布后，引发了许多同学的讨论和关注。大家关注的焦点非常集中，主要围绕在"自进化"这个概念，包括"Skill 的自动沉淀"以及"RL（强化学习）训练"这两个核心维度上。
其实，关于RL训练这一块，我在之前的文章里有提到，官方也明确说过，这更多是面向AI研究人员或者算法同学所设计的。如果你的目标是在某个特定领域的垂直任务，或者在特定的 Benchmark 上追求极致的性能效果，那么通过 RL 进行深度训练，确实是让模型突破瓶颈、获得更好效果的有效路径。但对于大多数工程落地场景而言，这种方式的门槛和成本都相对较高。因此，除了RL这条"重资产"路线外，另一种更轻量、更具普适性的方式，就是通过"Skill"的机制来实现 Agent 的自进化。
然而，仅仅是通过Skill自动更新来解决 Agent 的"自进化"，其实还是有点不够的，也有很多人反映真正在用 Hermes Agent 的时候，也没感觉到明显的变聪明，或者看到自动沉淀的比较好的 Skill。这是因为，自动沉淀 Skill 的机制很多时候还是取决于模型自己的判断和决策，这种判断和决策的触发时机和可控性相对就比较低了。因此，通过人给予Agent更多的"知识"来提升 Agent 的能力，甚至存放知识的这个"知识库"如果能"自动梳理"、"自动组织"、"自动更新"甚至"自动进化"，那就更好了，从而就能推动 Agent 的不断"自进化"。
所以，今天的这个深度解析文章就特殊一点，我不按照之前的结构去分析Prompt、Context、Harness这些维度了，我将会从 Knowledge Engineering（知识工程）的角度展开，但知识的效果也是影响Prompt、Context、Harness 非常重要的一部分，并且也是我们的主线话题"如何构建一个好的Agent"中非常重要但提及较少的一个部分。
从"知识堆积"到"结构化记忆"
前几天，Andrej Karpathy（OpenAI联合创始人）开源了一个名为"LLM-Wiki"的项目[1]，核心其是就一个 Markdown文件，目标是指导大模型Agent进行知识的更新与结构化，整个过程如下图所示[2]。这个项目的本质，其实是解决了一个长期困扰我们的痛点：如何让 Agent 自动将非结构化的资料转化为 "AI能理解"、"有结构"的知识库。另外，今天还会介绍一个项目叫做"Gbrain"[3]，它是由 Y Combinator 总裁兼 CEO Garry Tan 构建的，一个思想和 LLM-Wiki 类似但更工程化一点的知识库项目。
这背后折射出的，是人类在知识管理上的天然短板。人类其实非常擅长"无脑堆积"知识——看到好的文章就收藏，遇到有用的文档就保存（此刻，可以打开看下你的网页收藏夹、各类APP的收藏夹，以及混乱的电脑桌面文件，是不是有很多已经"落灰"很久了，哈哈哈~）。这说明人类很不擅长"组织"知识。要把这些零散的信息梳理成体系化的结构，不仅耗时耗力，更因为缺乏统一的整理标准而变得很困难，容易拖延，拖着拖着就算了。无论是从个人层面看，收藏信息、文件是真的杂乱；还是从企业层面看，以我在阿里云售后做智能客服相关算法多年的经验，企业级知识库的维护成本更是非常之高，这主要体现在两个维度：
时效性与动态维护。知识是有生命周期的，它会随着产品迭代、业务变更而过时或失效。如何精准识别并剔除失效知识，同时无缝接入新知识，本身就是一个巨大的挑战。
组织结构的复杂性。知识该如何分类？以我们阿里云的服务领域来看，是按产品维度？问题场景维度？还是按关键词维度？比如，"镜像"主要集中在ECS、轻量应用服务器这些产品，而OpenClaw的相关知识就可能横跨多个产品线，简单的树状层级结构很难刻画这种复杂的网状关系。这种多维度的交叉关联，使得人工构建和维护一个完美的类似知识图谱之类的方案几乎成为不可能完成的任务。
而在 AI 时代，尤其是对于 Agent 而言，知识的质量直接决定了效果的上限。正如我在前文中说过的，Context 不仅仅包含当前的对话指令和历史记录，更核心的组成部分是外部注入的知识。这里的"知识"是一个广义的概念，它主要包含经验性知识，也就是完成特定任务所需的策略、步骤和隐性经验；事实性知识，比如领域内的客观信息、文档、FAQ 等静态数据。
以 AI Coding 场景为例，当我让 Agent 去写代码时，我期望它遵循的不仅仅是一个语法正确的结果，而是一套完整的"编码习惯"。比如：我喜欢用什么样的命名规范、注释风格？是应该先设计接口再实现细节，还是先跑通 Demo 再重构？优先使用哪些成熟的库或框架？写完代码后，是否自动进行单元测试或静态检查？
这些隐性的、带有个人色彩的经验法则，其实就是典型的经验性知识。在 Hermes Agent 或 OpenClaw 的体系中，我们将这类经验封装为 Skill。Skill 本质上是一种结构化的经验沉淀，它告诉 Agent "在这个特定场景下，应该按照什么步骤、用什么工具、遵循什么标准去行动"。
另一类事实性知识，就比较通俗易懂了。比如：某个概念、术语的定义是什么？某个报错原理背后的机制是怎样的？针对某类常见问题的最佳实践解决方案有哪些？甚至是网上最新的技术博客摘要。这些信息构成了 Agent 回答问题的基础素材。
如果说 Prompt Engineering 是在教模型"完成什么样的任务"，那么 Knowledge Engineering（知识工程）就是在教模型"应该知道什么"以及"如何运用已知信息"。Karpathy 的 LLM-Wiki 思路之所以具有突破性，是因为它突破了传统 RAG "每次查询从头检索"的局限。通过 Schema 文件指导 LLM 主动维护结构化的 Markdown Wiki，它将原始资料"编译"为带有交叉引用、矛盾标注的持久化知识体。
在这种设计下，知识不再是静态的死水，而是随着使用持续累积、增厚的活体，避免了重复推导带来的算力浪费。在这个新范式下，人类的角色发生了转变：我们只需专注于"提问题"和"堆知识"，而将繁琐的维护工作交给大模型。再配合上 Obsidian 这类知识维护的 IDE，Agent 就成为了那个不知疲倦的知识管理助手，可以自动完成知识的清洗、去重与结构化整合。
大家在使用各类 Agent 工具的过程中，尤其是在"养虾🦞"（OpenClaw）的时候，大家会深刻体会到这 Skill 的重要性。但是，这里存在一个明显的痛点：Skill 的编写是有门槛的。虽然市面上有很多教程教你怎么写出一个高效的 Prompt 或 Skill，但这依然需要开发者对业务逻辑有深刻的理解，并且要花费大量时间去调试和优化指令。对于普通用户而言，手动将隐性经验转化为显性的、机器可执行的 Skill，成本依然很高。
这正是 Hermes Agent 引入"自进化"机制的价值所在——它试图通过自动化生成的方式，降低这一门槛。Agent 不再仅仅被动地接收人类编写的 Skill，而是能够在交互过程中，自动从历史对话、成功/失败的案例中提取模式，自动生成或优化新的 Skill。这种从"人工编写 Skill"到"Agent 自动生成 Skill"的转变，才是实现真正意义上"知识自进化"的关键一步。
Skillify：渐进式披露式的"知识形态"
无论是Andrej Karpathy 的 LLM Wiki，还是Garry Tan 的 GBrain。这两个项目在某种程度上都对 "Skill" 这个概念进行了泛化。
传统意义上的 Skill，往往被固化为一个特定的 SKILL.md 文件或指令集，大模型读取它来掌握某项特定技能。但 LLM Wiki 和 GBrain 的核心创新在于：它们将 Skill 泛化为一种知识组织形态。在这种范式下，Skill 不再局限于某种固定格式，它可以是任何 Markdown 文件、文档片段甚至是零散的笔记。关键在于，通过定义清晰的元数据（Metadata）或 Schema，描述清楚"在什么场景下应该调用哪些文件"，从而实现知识的渐进式披露（Progressive Disclosure）。
GBrain 的创始人 Garry Tan 甚至使用了一个词叫"Skillify"，指的是去写 Skill 或者像 Skill 一样去组织和加载知识。这种机制允许各类 Agent 接收各类文件、文本、链接，然后自动将其"编译"并归档到一个统一的个人知识库中。你可以把这个知识库想象成一个巨大的、结构化的 "Skill 包"。
我回顾一下阿里云智能客服的发展历程，其实知识体系的演进大致也经历了三个阶段：
第一个就是"传统智能知识库时代"，从2016~2022年，早期的智能客服基本上就是面向搜索引擎的知识库。知识必须由人工进行严格的分类、打标和归档，形成树状或标签体系。
到了后面就是2023年，随着大模型的兴起，进入到了"RAG时代"，RAG成为主流技术。但存在几个问题：模型能力断层、搜索独立性（每次独立检索）、知识未沉淀。
在第三个阶段"Agent时代"，LLM Wiki 和 GBrain 的核心优势就在于"一次学习，永久可用"：消除重复搜索、全链路大模型参与、知识的累积效应。
简而言之，如果说 RAG 是让大模型"带着书本进考场"，那么 Skillify 则是让大模型"把书读透并记成整理后的笔记"。
LLM Wiki：三层架构的知识闭环
LLM Wiki 的三层架构：
1. 原始资料层（Raw Sources）：只读的存档区，存放未经处理的原始输入
2. Wiki层（The Wiki）：中间层，按照主题、人物、概念等维度组织起来的结构化知识页面
3. 索引层（The Schema）：顶层逻辑，定义整个系统如何运行、如何更新以及如何校验知识的元指令
其工作流程形成了一个完整的闭环：
摄入（Ingest）：当一个新的知识源被添加时，LLM Wiki 执行深度处理：阅读原始资料，提取关键要点，生成摘要页面，并自动更新全局索引及相关实体页面。一个单一来源往往能联动更新 10-15 个相关 Wiki 页面。
查询（Query）：用户提问时，LLM 先定位相关 Wiki 页面，阅读后综合出带引用的答案。高质量答案可归档为新页面，实现知识的自我累积与反哺。
维护（Lint）：定期让 LLM 进行健康检查：识别事实矛盾、清理过时声明、发现无入链的"孤儿页面"以及补全缺失的交叉引用。
LLM Wiki 还设计了两个特殊的 Markdown 文件来帮助导航：
index.md（面向内容）：Wiki 中所有页面的目录，按类别组织。
log.md（面向时间）：什么时候发生了什么的追加记录。
为什么这种模式有效？维护知识库的繁琐部分不是阅读或思考，其实是"记账"。更新交叉引用、保持摘要最新、注意新数据何时与旧声明矛盾。人类放弃 Wiki 是因为维护负担增长得比价值更快。但是 LLM 并不会觉得无聊，也不会忘记更新交叉引用，可以一次性处理 15 个文件。
Obsidian-Wiki：从想法到系统的工程化实现
Obsidian-Wiki 是一个基于 Skill 的多 Agent 框架，并且实现了 Andrej Karpathy 的 LLM Wiki 模式。它的核心设计理念是：
- Agent 无关：支持 9+ 种 Agent（比如Claude Code、Cursor、Windsurf、Codex、OpenClaw、Hermes、Gemini CLI、Kiro 等等）
- Skill 驱动：所有操作通过标准化的 Markdown Skill 文件定义
- Obsidian 原生：利用 Obsidian 的 wikilink、图谱视图、Dataview 等功能
Obsidian-Wiki的架构增强
Delta 追踪（差异追踪）：使用.manifest.json 文件跟踪所有已摄入的知识来源，每个来源用 SHA-256 哈希追踪。
来源可信度边界：来源文档被视为不可信的，LLM 永远不应该执行来源中的命令。这防止了通过恶意文档注入指令的攻击（prompt injection through documents）。
溯源标记系统：每条知识都标记其来源可靠性，比如^[extracted]是直接从来源提取；^[inferred]是基于来源推断；^[ambiguous]是存在歧义或多种解释。
可见性标签：支持 visibility/internal 和 visibility/pii 标签，允许在查询时过滤敏感内容。
hot.md 热缓存：一个 500 字的语义快照，记录最近活动。这为 LLM 提供了快速上下文感知。
GBrain：混合检索架构与图谱关系演进
如果说 LLM Wiki 是知识管理的"极简主义哲学"，那么 GBrain 则是在此基础上引入了更厚重的"工程化实践"。它保留了 LLM Wiki 的核心精髓，基于文件系统的存储和渐进式披露（Progressive Disclosure）原理，但在其之上构建了一层复杂的中间件。
GBrain的架构哲学还可以用一句话概括：Thin Harness, Fat Skills。也就是建议把Harness做的薄一些，主要精力在丰富Skills上。
潜在空间 vs 确定性
GBrain认为最差的Agent系统总是会把错误的工作放在错误的一边，它的设计思路是：让LLM 决定"做什么"，让代码保证"在哪里"和"如何做"。它把LLM可以做的事情叫"潜在空间"（Latent Space），代码来做的事情叫"确定性"（Deterministic）。
混合检索架构：向量过滤 + 文件披露
GBrain 的检索过程是一个精心设计的分层过滤与渐进式披露的流程："Chunk 确认 → 整页加载 → 分层呈现"。
当用户发起查询时，系统首先执行混合搜索（Hybrid Search），结合关键词匹配与语义向量相似度，从海量数据中快速筛选出相关的文本片段（Chunks）。一旦确认相关性，系统就会加载完整页面。最后，GBrain 按照优先级进行结构化组装，优先提供"编译真相"：即当前最新的综合摘要或结论性信息。
图谱构建Pipeline：从文本到图结构
GBrain 的图谱构建过程分为四个步骤：
1. 实体抽取（Entity Extraction）：利用正则表达式和关键词模式匹配，从文本中抽取出人名、公司名、会议等关键实体
2. 页面生成（Page Generation）：为每个识别出的实体自动生成对应的 Markdown 页面
3. 关系分类（Relation Classification）：通过关键词匹配判断实体间的关系类型
4. 反向链接强制化（Backlink Enforcement）：如果 A 提到了 B，系统会自动在 B 的页面上添加一条指向 A 的反向链接
总结
LLM Wiki 和 GBrain 代表了两种不同的技术路径：前者追求极致的轻量与透明，适合个人和小规模场景；后者追求工程化的稳健与扩展，适合复杂数据和大规模应用。
技术选型从来不是非此即彼的单选题。通常的最佳实践是混合架构：利用向量检索、关键词索引等轻量级技术进行快速初筛；同时也保留大模型对高价值知识的深度阅读、渐进式披露以及离线自我迭代能力。
References
[1] LLM-Wiki：https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
[2] AI Maker：How I Took Karpathy's LLM Wiki and Built an AI-Powered Second Brain in Obsidian
[3] GBrain：https://github.com/garrytan/gbrain
[4] Obsidian-Wiki：https://github.com/ar9av/obsidian-wiki
[5] Medium：LLM Wiki: From Storing Knowledge to Compiling Understanding