不是再做一个知识库，而是给 Agent 建一套会生长的知识操作系统

摘要：三篇公众号文章放在一起看，讲的其实不是 Skills、LLM Wiki、GBrain 或 Harness 这些热词。它们共同指向一个更大的转向，Agent 时代真正值钱的东西，正在从工作流转向知识，从临场检索转向长期沉淀，从会调用工具转向会积累经验。

关键词：Agent、RAG、Skill、LLM Wiki、GBrain、Harness Engineering、知识工程、AI Coding

适合读者：正在做 Agent 项目、AI Coding 工具、个人知识库、团队知识沉淀，或者想理解 Agent 时代知识工程机会的人。

导读

这篇文章会围绕一个问题展开。

当所有人都有强模型、都有工具调用、都有工作流以后，什么东西还能真正形成长期壁垒？

我的答案是，知识。

但这里说的知识，不是收藏夹，不是普通文档，也不是把资料塞进向量库以后做问答。而是一套能被 Agent 稳定读取、稳定执行、稳定校验、持续演化的知识操作系统。

你会读到四件事：

• 为什么 RAG 解决了检索问题，却没有完全解决长期记忆问题。
• 为什么 Skill 不是更长的提示词，而是 Agent 的知识执行接口。
• LLM Wiki、GBrain、Harness Engineering 放在一起看，真正启发是什么。
• 如果要基于这些思路做一个新项目，最小可行产品应该从哪里切。

---

一、这三篇文章其实在讲同一件事

我一开始看这三篇文章的时候，第一反应是，它们好像分别在讲三个东西。第一篇讲 Skills 编程，第二篇讲 LLM Wiki、Obsidian-Wiki、GBrain，第三篇讲 Harness Engineering 和团队知识沉淀。

但顺着读完以后，我觉得它们其实在讲同一件事。

Agent 的下一阶段，不是把工作流搭得更花，而是把知识变成它能稳定读取、稳定执行、稳定校验、持续演化的基础设施。

这个判断很重要。

因为过去一年，很多人做 Agent 项目，第一反应都是搭工作流。搞一个 Planner，搞几个 Worker，搞一个 Review Agent，再接一个浏览器、一个 Git、一个数据库、一个 Slack。看起来很完整，很像一个自动化团队。

但跑几次就会发现一个很尴尬的问题。

它每次都像第一天上班。

上一次踩过的坑，下次继续踩。上一次跟它解释过的业务规则，下次还得重新解释。上一次好不容易找到的代码入口，下次又在项目里乱翻。更糟的是，它有时候不是不知道，而是拿着过期知识非常自信地做错。

这才是三篇文章共同指向的痛点。

不是模型不够强，不是工具不够多，也不是流程不够复杂，而是 Agent 没有真正拥有团队的长期记忆。它没有一套能被不断维护的知识层。没有这个东西，再华丽的 Harness 都只是一次性管道。

原文配图 1：面向 Skills 编程，用领域知识工程驱动 Code Agent

原文配图 2：LLM Wiki / Obsidian-Wiki / GBrain 深度解析

原文配图 3：Harness 不是目的，知识才是护城河

第一篇文章的起点很工程。团队在复杂业务项目里做重构，遇到的不是代码读不懂，而是知识断层。某个分支为什么存在，某个字段为什么这样处理，某条老链路到底还在不在用，文档不是没有，就是过期。人看代码已经痛苦了，Code Agent 更痛苦。

于是它走到一个很关键的结论，业务知识不能只是写在文档里，必须被工程化。更具体一点，必须被组织成 Agent 能用的知识形态。这里的重点不是把文档喂给 Agent，而是把知识拆成全局索引、模块 Skill、引用详情，并且显式映射到代码流程、文件、函数、输入输出和变更检查点。

这一步非常关键。

很多团队做 AI Coding，会犯一个看起来很合理的错误，就是让 Agent 自己去理解代码。理论上，Code Agent 可以搜索，可以读文件，可以找引用，可以跑测试。那为什么还需要人写知识？

因为代码只告诉你系统现在长什么样，不告诉你它为什么长成这样。

一个废弃分支可能还没删，是因为历史兼容。一个看似奇怪的字段可能不能动，是因为下游系统依赖。一个函数名可能已经和真实业务含义错位。你让 Agent 只读代码，它会把所有代码都当成同等可信的事实。问题是，真实项目里，代码不是事实本身，代码是历史妥协的化石层。

第二篇文章把这个问题从工程项目推到了更大的知识管理层面。LLM Wiki 的思路很漂亮，它不是把资料存起来等查询时再检索，而是让 LLM 把资料持续整理成一个结构化、相互链接、可维护的 Markdown Wiki。GBrain 则更进一步，加上混合检索、图谱关系、实体链接和更工程化的流水线。

你会发现，它们都在反抗同一件事，知识的无脑堆积。

收藏夹里有一千篇文章，但你下次写东西还是想不起来。团队 Confluence 里有五百页文档，但新人还是要问老员工。RAG 里塞了一堆 PDF，但回答仍然忽高忽低。这些东西的共同问题是，资料被存下来了，但没有被真正编译成知识。

第三篇文章则把矛头指向 Harness Engineering。它承认工作流重要，但更强调，工作流是可替换的，知识是可累积的。今天你用状态机，明天可能换 DAG，后天模型厂商把 Planner 内置了。但团队知道的那些业务规则、架构决策、事故教训、踩坑经验，不会因为工具链更新而自动消失。

所以三篇文章合起来看，形成了一个很完整的判断链。

三篇文章的共同指向

1. Skills 编程

• 表面主题：Code Agent 如何读懂复杂项目。
• 真正问题：业务知识没有和代码流程形成显式映射。
• 对新项目的启发：知识必须变成 Agent 的执行接口。

2. LLM Wiki / GBrain

• 表面主题：Agent 时代的自组织知识库。
• 真正问题：资料堆积不会自动变成长期记忆。
• 对新项目的启发：知识需要被编译、索引、链接、校验。

3. Harness 与知识沉淀

• 表面主题：AI 工程交付团队的知识实践。
• 真正问题：工作流没有知识闭环就会一次性消耗。
• 对新项目的启发：项目机会在知识生命周期管理。

图 1：从工具热潮到知识基础设施

坦率地讲，这个方向让我兴奋的地方就在这里。它不是再做一个知识库，也不是再做一个 RAG 系统，而是把知识变成 Agent 的基础设施。

这就是一个新项目的起点。

这一节的小结：三篇文章表面上分别讲 Skill、Wiki、Harness，但底层都在讲同一件事，Agent 需要一套可维护、可执行、可演化的知识层。

---

二、RAG 为什么不够了

不是说 RAG 没用了。RAG 当然有用，而且会长期有用。问题是，只靠 RAG 来做 Agent 的长期记忆，天然会遇到稳定性问题。

RAG 的基本逻辑是，先把文档切块、索引，用户提问时检索相关片段，然后把片段塞进上下文，让模型生成答案。

这个方式解决了一个大问题，就是模型不知道外部资料怎么办。你把资料放进向量库，它至少能找到一些相关内容。

但你仔细想想，RAG 的动作其实很像临场翻书。

考试的时候，老师允许你带一堆资料进考场。你每遇到一个问题，就在资料堆里翻，翻到几段看起来相关的内容，然后现场组织答案。这个模式可以工作，但它每次都在重新理解，重新拼接，重新判断。

LLM Wiki 这条线想做的是另一件事。

它不是让模型每次临场翻书，而是让模型提前把书读过，把重点摘出来，把概念之间的关系连起来，把矛盾标出来，把新的理解写进 Wiki。下次再问相关问题，它读的是已经整理过的知识体，而不是一堆原始碎片。

这就是文章里那个很有力量的类比，RAG 更像解释执行，LLM Wiki / Skillify 更像提前编译。

RAG，查询时临场组装

适合海量资料快速召回，适合问答、客服、文档检索。短板是每次都要重新检索和拼接，知识之间的关系很难稳定沉淀。

Wiki / Skill，摄入时提前编译

适合长期研究、项目知识、团队经验和 Agent 记忆。重点不只是找得到，而是已经被整理、关联、验证，并且能继续更新。

图 2：RAG 和 Skillify 的差别

这里面最容易误解的一点是，很多人会以为 LLM Wiki、GBrain、Skills 是在取代 RAG。

我不这么看。

更准确的理解是，RAG 是找资料的能力，Skillify 是组织知识的能力。一个负责召回，一个负责沉淀。一个解决「现在我要读什么」，一个解决「我已经学会了什么」。

这个差别在个人知识管理里很明显。

你今天读了十篇关于 AI Agent 的文章。如果只是存在收藏夹里，下一次你要写文章，还是要重新翻。如果放进 RAG，下一次你可以问，它也许能召回几段。但如果你让 Agent 把这十篇文章整理成 Wiki，形成概念页、人物页、项目页、争议页、时间线页，下次你问「GBrain 和 LLM Wiki 到底差在哪」，它不需要从十篇文章里现场重新猜，而是直接读取已经沉淀好的对比页。

这就是知识复利。

在工程团队里，这个差别更大。

你把代码仓库丢给 Agent，它可以搜索代码。但如果你提前维护了模块 Skill，里面写清楚什么需求该读这个 Skill、业务不变量是什么、代码入口在哪里、哪些函数不能随便改、改完要跑哪些检查，那 Agent 的行为会稳定得多。

不是因为它突然变聪明了，而是因为你把它需要临场推理的东西，提前变成了结构化约束。

这句话我觉得特别关键。

Agent 系统的工程化，本质上就是把不该交给模型临场猜的东西，从概率空间搬到确定性结构里。

这一节的小结：RAG 更像临场翻书，Skillify / LLM Wiki 更像提前编译。前者解决「找资料」，后者解决「学会并复用」。

---

三、Skill 不是提示词，是知识的执行接口

很多人第一次听到 Skill，会把它理解成一个更长的 Prompt。这个理解太浅了。Prompt 是一次性的指令，Skill 更像一个可被路由、可被按需加载、可被复用、可被版本化的知识模块。

Anthropic 的 Agent Skills 文档把 Skill 描述为一种把专业能力打包给 Agent 使用的机制，典型结构是一个带元数据的 SKILL.md，再加上必要的脚本、模板和参考资料。OpenAI Codex 这边则有 AGENTS.md，用于给代码仓库中的 Agent 提供项目级指令和上下文。MCP 则从工具协议角度，把外部能力以 Tools、Resources、Prompts 等形式暴露给模型。

这些东西看起来属于不同生态，但放在一起看，方向很一致。

大家都在做一件事，让 Agent 不再只靠系统提示词和当前对话，而是能读取一套外部的、可维护的、结构化的运行环境。

只是分工不同。

几种机制的分工

AGENTS.md

• 解决什么问题：告诉 Agent 当前仓库的规则、结构、命令、注意事项。
• 更像什么：项目说明书和入口路由。
• 局限：如果写太长，会变成又一个没人维护的大文档。

Skill

• 解决什么问题：把某个领域任务的流程、经验、模板、工具封装起来。
• 更像什么：专家手册 + 可执行工具包。
• 局限：如果缺少触发边界和防腐机制，会越积越乱。

LLM Wiki

• 解决什么问题：把长期资料整理成结构化、可链接、可维护的知识体。
• 更像什么：由 Agent 维护的第二大脑。
• 局限：规模变大后，纯文件索引会遇到定位压力。

GBrain

• 解决什么问题：在 Wiki 基础上加入混合检索、图谱、实体关系和自动化流水线。
• 更像什么：工程化的知识中间件。
• 局限：系统复杂度提高，需要治理和边界。

MCP

• 解决什么问题：标准化模型和外部工具、数据源的连接方式。
• 更像什么：Agent 的外设协议。
• 局限：它负责连接，不自动解决知识质量。

第一篇公众号文章里最有价值的地方，是它没有停在「我们写了一些 Skill」这里，而是继续往前走了一步。

它发现，只写业务规则没用。

比如你写，「广告创意审核需要先机审再人审」。这句话对人有用，对 Agent 也有一点用，但还不够。因为 Agent 真正要改代码的时候，它还要知道，机审在哪里触发，人审状态存在哪个字段，状态转换在哪个函数里，下游通知在哪里发，测试应该跑哪一组。

所以好的 Skill 不是百科词条。

好的 Skill 应该同时回答四个问题。

• 什么需求应该触发我，什么需求不应该触发我。
• 这个领域有哪些概念、规则和不变量。
• 这些规则对应到代码里的哪些入口、流程、文件、函数。
• 改动时应该怎么判断影响面，怎么验证，哪些坑不能踩。

这就是为什么我说，Skill 不是提示词，是知识的执行接口。

图 3：一个工程 Skill 应该长什么样

把一句业务知识改造成 Agent 可执行知识

普通文档写法

广告预算扣减要避免并发超扣。

Agent 友好写法

当需求涉及预算扣减、投放状态变更、并发消费、余额回滚时，先读取预算模块 Skill。核心不变量是同一广告计划的可用预算不能被并发请求扣成负数。代码入口是 BudgetService.debit()，并发保护在 BudgetLock.lua，失败回滚由 DebitRollbackJob 补偿。改动后必须补充并发测试，至少覆盖同计划 100 个请求同时扣减、部分失败回滚、重复消息幂等三种情况。如果本次 diff 修改了扣减入口、锁逻辑、余额字段或回滚任务，需要同步更新预算 Skill 的代码锚点和不变量说明。

你看，同样一条知识，后者明显不是给人看的普通文档，而是给 Agent 执行任务时用的导航系统。

这个例子里有一个非常重要的变化。

知识不再只是「知道什么」，而是「在什么场景下读取什么，读完以后去哪里改，改完以后怎么验证」。

这才是 Agent 时代知识工程最核心的跃迁。

这一节的小结：Prompt 解决一次性表达，Skill 解决可路由、可复用、可验证的执行知识。

---

四、LLM Wiki 和 GBrain 的真正启发

LLM Wiki 最打动我的地方，不是它用了 Markdown，也不是它推荐 Obsidian，而是它把知识库重新定义成了一个会被 LLM 持续维护的代码库。

Karpathy 那篇 LLM Wiki 的核心想法非常朴素。原始资料是只读的，Wiki 是 LLM 生成和维护的结构化知识层，Schema 则规定这个知识层应该怎么组织、怎么摄入、怎么查询、怎么巡检。

你把资料丢进去，不是为了以后搜索它，而是为了让 LLM 阅读、提炼、归档、关联、更新。一个新来源进来，可能会影响十几个已有页面。人物页要更新，概念页要更新，时间线要更新，索引要更新，矛盾要标出来，日志要补一条。

这件事人类当然也能做。

只是人类大多数时候不会做。

这就是知识管理最大的尴尬。我们不是不懂整理知识的重要性，而是维护成本太高。收藏很容易，整理很痛苦。写一篇笔记很容易，维护一套互相链接、互相引用、持续更新的知识系统很难。尤其当知识规模变大以后，真正压垮人的不是阅读，而是记账。

交叉引用要补，重复概念要合并，旧结论要修订，新证据要挂上去，孤儿页面要找出来。这些动作非常琐碎，但对知识系统的质量极其重要。

LLM 刚好适合做这件事。

它不会嫌烦。

GBrain 的启发则更工程化一点。纯 Markdown Wiki 很轻，但规模一大，模型靠 index.md 和 grep 找东西会吃力。所以 GBrain 引入混合检索和图谱，让代码负责确定性的定位、链接、验证，让 LLM 负责语义判断、总结和抽象。

这个分工非常值得记下来。

让 LLM 判断「这条信息应该怎么理解」，让代码保证「它被放在哪里、如何链接、格式是否正确、引用是否有效」。

这其实也是做 Agent 项目的一个大原则。

不要让模型做所有事情。它擅长语义判断、归纳、对比、抽象、写作、解释。它不擅长稳定执行那些可以由代码确定完成的事情。比如文件命名、哈希对比、反向链接、索引更新、引用格式、敏感信息过滤、权限边界，这些就应该交给确定性程序。

图 4：LLM Wiki / GBrain 的三层架构

这个架构对我们做新项目的启发很直接。

如果我们只是做一个聊天机器人，让用户上传资料，然后问答，那已经太普通了。这个方向上有无数产品，而且很容易被平台功能吃掉。

更有价值的是做一个知识编译器。

它接收原始资料，但不止索引资料。它会把资料编译成 Agent 能用的知识形态。比如一篇技术文章进来，它不只是生成摘要，而是判断它涉及哪些概念、哪些工具、哪些人物、哪些争议、哪些可执行经验。然后它更新对应 Wiki 页面，写入来源，标注置信度，发现与旧知识冲突时提醒人 review。

如果资料来自代码仓库，它会更进一步，把知识锚定到代码位置。哪个模块、哪个函数、哪个配置、哪个测试命令、哪个架构决策。最后输出给 Codex、Claude Code、Cursor 这类工具可以直接读取的 AGENTS.md、Skill 文件和模块知识页。

这不是知识库。

这是 Agent 的知识操作系统。

这一节的小结：LLM Wiki 和 GBrain 的关键不在形式，而在分工，让模型负责语义理解，让代码负责确定性治理。

---

五、Harness 不是护城河，知识闭环才是

第三篇文章里最值得警惕的观点，是别把 Harness 本身当成终点。工作流当然重要，但工作流迟早会商品化。真正能累积的，是工作流流过以后留下来的知识。

这两年 Agent 产品最容易让人兴奋的部分，就是自动化流程。你可以设计一个从需求分析到代码实现到测试到 Review 到发布的链路。每一步都有 Agent，每一步都有产物，每一步都有状态。

看起来很爽。

但如果流程跑完以后什么都没留下，或者只留下了一堆临时对话和日志，那这个工作流其实没有变聪明。下一次任务还是重新开始。

这就是文章里讲的知识沉淀比工作流更重要。

我自己的理解是，一个好的 Harness 至少要做三件事。

• 在任务开始时，把已有知识按需注入给 Agent。
• 在任务执行中，记录 Agent 引用了哪些知识、发现了哪些矛盾、补充了哪些经验。
• 在任务结束时，把本次产生的新知识提取出来，经过人或规则校验后沉淀回知识库。

只有这样，工作流才不是一次性管道，而是一台知识采矿机。

图 5：从一次性工作流到知识闭环

再往细了讲，知识闭环至少要有四道防线。

第一道，使用时反向校验

Agent 读了 Skill，再去读代码。如果发现 Skill 说的流程和代码现实不一致，它应该立刻标出来。比如 Skill 说状态流是 A 到 B 到 C，但代码已经变成 A 到 C，那就不能假装没看见。

这个动作几乎不增加成本，因为 Agent 本来就要读知识和代码。顺手做一致性检查，是最自然的防腐机制。

第二道，沟通中补缺

很多知识不是文档里缺，而是在对话里出现。你给 Agent 解释了一遍为什么某个接口不能改，为什么这次需求只影响某条产品线，为什么某个测试数据很特殊。如果对话结束这些知识就消失了，那太浪费了。

好的系统应该在沟通后自动总结新增知识，提示你是否沉淀到对应 Skill 或 Wiki 页面。

第三道，提交前 diff-check

代码变了，知识可能就要变。尤其当 diff 命中关键文件、状态机、接口定义、数据库模型、核心业务流程时，系统应该主动检查相关知识是否需要更新。

这比事后补文档靠谱得多。

第四道，定期全量巡检

即使前三道都做了，也一定会漏。知识系统需要像代码一样定期 lint。孤儿页面、失效链接、过期接口、冲突结论、长期未引用知识、缺少来源的判断，都应该被扫出来。

这就是知识的生命周期管理。

知识闭环的四道防线

反向校验

• 触发时机：Agent 使用知识时。
• 解决的问题：存量知识和现实代码不一致。
• 产物：差异报告、修正建议。

沟通补缺

• 触发时机：需求澄清和开发沟通后。
• 解决的问题：隐性知识没有沉淀。
• 产物：新增知识条目、候选 Skill 更新。

diff-check

• 触发时机：提交前或 PR 前。
• 解决的问题：代码变更造成知识腐化。
• 产物：受影响知识清单、更新补丁。

全量巡检

• 触发时机：周期性或版本发布后。
• 解决的问题：长期积累的遗漏和衰减。
• 产物：健康报告、归档建议、冲突队列。

你看，这已经不是写文档了。

这是在给知识做 DevOps。

这一节的小结：Harness 本身会被商品化，真正能积累的是每次任务完成后沉淀下来的知识。

---

六、真实例子，一个复杂项目怎么被知识救回来

为了让这个事情更具体，我们可以想象一个很常见的工程场景。一个团队有个运营后台，代码 20 万行，核心热代码只有 2 万行，历史产品线三四条，很多逻辑已经没人敢动。

这个项目里有一个需求，给广告创意增加一个新的审核豁免规则。

如果没有知识系统，Agent 会怎么做？

它会先搜「审核」，找到一堆文件。里面有旧审核、有新审核、有历史 AB 实验、有废弃产品线、有测试 mock、有运营工具。它可能会读到一个旧函数，以为那是主流程，然后在错误的位置加逻辑。它也可能找到了正确入口，但不知道某个状态不能跳过，因为下游结算依赖这个状态变化。

于是你开始手动补上下文。

不是这个文件。不是这条链路。这个状态不能动。那条产品线已经废弃。这个字段虽然叫 review_type，但真实含义不是审核类型。你看 CreativeAuditPipeline，再看 AuditResultMapper，然后跑这几个测试。

你说完这些以后，Agent 终于做对了。

但下次呢？

如果这些解释没有沉淀，下次还是从头来。

有知识系统以后，这个流程会变成另一种样子。

需求进来

系统根据关键词和代码范围判断，这个需求命中「创意审核」Skill，同时可能关联「投放状态」和「素材合规」两个相邻 Skill。

Agent 读取 Skill 主文件

它先看到业务不变量，审核豁免只能影响前置判定，不能跳过状态记录，不能绕过审计日志，不能影响历史产品线。

Agent 定位代码锚点

Skill 直接告诉它入口在 CreativeAuditPipeline，规则聚合在 AuditPolicyRegistry，状态映射在 AuditResultMapper，旧链路只读不改。

Agent 制定方案

方案里不仅有代码改动，还有影响面检查、测试命令、是否需要更新知识的判断。

提交前 diff-check

系统发现新增了一个审核规则，于是提示更新「审核规则清单」和「豁免规则说明」，并把本次需求中的新约束补进 Skill。

这个过程里，Agent 并不是单纯变强了。

它只是少猜了很多东西。

对复杂系统来说，少猜就是生产力。

再换一个个人知识场景也一样。

你现在把三篇公众号文章投喂给我，让我帮你思考一个新项目。如果没有知识系统，这次对话结束以后，我们的理解大概率就沉在聊天记录里了。下次再聊，你可能要重新发链接，重新说方向，重新解释你想做什么。

但如果我们现在有一个个人 Agent Knowledge OS，它应该自动做几件事。

• 把三篇原文存进 raw sources，保留 URL、标题、发布时间、作者信息。
• 生成一页「Agent 知识工程」主题页，沉淀核心观点。
• 建立「Skillify」「LLM Wiki」「GBrain」「Harness Engineering」「知识防腐」几个概念页。
• 把今天这次讨论整理成「新项目方向」页面，记录我们已经排除什么、倾向什么。
• 生成一个可执行的下一步，询问你要优先做个人工作台、工程团队工具，还是通用基础设施。

这就是从聊天变成知识。

也是我觉得这个项目有意思的原因。

这一节的小结：复杂项目里，Agent 最大的问题不是不会读代码，而是不知道哪些代码该信、哪些历史不能碰、哪些规则必须遵守。

---

七、如果我们要做新项目，应该做什么

看到这里，最自然的问题来了。既然方向这么清楚，那我们到底要做一个什么东西？

我先给一个粗暴判断。

不要从大而全平台开始。

大平台听起来爽，个人知识、团队知识、代码知识、Agent 记忆、浏览器插件、Obsidian、Git、MCP、向量库、图数据库，全都想做。最后很容易做成一个架构图很好看但没人每天打开的东西。

这个方向最重要的不是功能完整，而是真实闭环。

所以我会建议从一个非常具体的切口开始。

先做一个给你自己用的 Agent 知识工作台，把「投喂资料到形成可执行项目知识」这条链路跑通。

它不需要一开始就支持所有格式。先支持网页链接、Markdown、PDF、本地笔记、聊天记录就够了。它也不需要一开始就做复杂图数据库。先用文件系统、Markdown、索引文件、manifest、少量本地搜索就够了。

关键是它必须有几个和普通知识库不一样的能力。

能力一，资料摄入不是摘要，而是编译

用户投喂一篇文章，系统不能只生成「本文讲了什么」。它要判断这篇文章对现有知识体系产生什么影响。

它应该问，新增了什么概念？强化了哪个旧观点？和哪个旧结论冲突？适合沉淀成事实知识、经验知识，还是行动指南？有没有值得变成 Skill 的流程？有没有可以成为项目假设的洞察？

这一步做对了，产品就和普通阅读器、收藏夹、RAG 问答拉开距离。

能力二，知识输出要面向 Agent，而不是面向人类收藏

同样是沉淀知识，人类喜欢长文、笔记、标签。Agent 需要的是路由、边界、锚点、检查清单、引用来源、更新规则。

所以每个知识页都应该有两层。

人看的解释层，讲清楚这个概念是什么，为什么重要，有哪些例子。

Agent 用的执行层，讲清楚什么时候调用、调用前读什么、调用后产出什么、哪些约束不能违反、知识过期时怎么发现。

能力三，所有知识必须有来源、置信度和生命周期

没有来源的知识，不能进入核心索引。没有置信度的判断，不能直接喂给 Agent 当事实。长期不被引用的知识，应该降级。被新证据冲突的知识，应该进入 review 队列。

这听起来麻烦，但这是知识从「笔记」变成「基础设施」的分界线。

能力四，输出要能喂回现有 Agent 工具

我们不应该一开始就做一个封闭 Agent。更好的做法是成为 Codex、Claude Code、Cursor、OpenClaw、Hermes 的知识层。

也就是说，它可以生成或更新这些文件。

AGENTS.md
.codex/skills/xxx/SKILL.md
docs/knowledge/index.md
docs/knowledge/concepts/skillify.md
docs/knowledge/projects/agent-knowledge-os.md
docs/knowledge/log.md
docs/knowledge/manifest.json

这样我们就不用和现有 Agent 工具抢入口，而是站在它们下面，给它们提供更好的知识燃料。

能力五，必须有知识健康检查

这件事不能后补。

知识一旦开始沉淀，就一定会腐化。页面会失效，概念会重复，旧判断会被新事实推翻，项目方向会变化。没有健康检查，知识越多越危险。

所以 MVP 里就应该有一个很简单的 lint。

• 扫描没有来源的知识。
• 扫描长期未引用的知识。
• 扫描互相矛盾的结论。
• 扫描没有入链的孤儿页面。
• 扫描应该生成 Skill 但还没有 Skill 的高频流程。

图 6：一个可落地的 MVP 形态

产品名先不重要。可以叫 Agent Knowledge OS，可以叫 SkillForge，可以叫 Memory Compiler，可以叫 Knowledge Harness。

重要的是定位。

它不是笔记软件。

不是 RAG 问答。

不是自动化工作流平台。

它是把原始资料、对话、代码、项目经验，编译成 Agent 可调用知识资产的系统。

这一节的小结：不要从大平台开始，先把「投喂资料到生成可执行项目知识」这条链路跑通。

---

八、风险，边界，和我自己的判断

这条路当然不轻松，而且有几个坑必须一开始就看见。

第一个坑，知识越多不一定越好

很多人做知识库，天然会有一种囤积冲动。什么都想存，什么都想整理，什么都想链接。最后系统越来越慢，索引越来越大，Agent 读取成本越来越高。

知识系统不是仓库，应该更像操作系统的内存管理。

热知识在前，冷知识归档。高置信度知识进入核心索引，低置信度知识留在证据层。经常被调用的知识提升成熟度，长期不用的知识自动衰减。

如果没有这个机制，知识越多，Agent 越容易被噪声淹没。

第二个坑，自动沉淀不能完全相信模型

让 Agent 自动从对话里总结 Skill，很诱人。但模型会过度概括，会把一次性经验写成普遍规则，也会把人的临时偏好当成长期约束。

所以自动沉淀最好分两步。

第一步，模型生成候选知识。

第二步，人或规则做确认，至少在关键知识进入核心层之前要有 review。

这不是保守，而是必要的安全边界。

第三个坑，别一开始就迷恋图谱

知识图谱听起来很高级。节点、边、实体、关系、推理，很容易让人兴奋。但对早期项目来说，最重要的不是图谱多复杂，而是知识页是否真的有用，Agent 是否真的能少猜，用户是否真的每天用。

先用 Markdown 链接和 manifest 跑起来。等页面数量、实体数量、查询复杂度真的上来，再引入更强的图结构。

别为了架构正确，牺牲使用闭环。

第四个坑，知识系统必须和真实工作流绑定

如果知识沉淀是额外动作，它一定会失败。

人类不爱补文档。这不是道德问题，是工作流问题。需求做完以后，人的注意力已经去下一个需求了。你让他回头整理知识，他当然不愿意。

所以知识沉淀必须嵌进真实动作里。

读文章时顺手沉淀。聊需求时顺手补缺。提交代码前顺手检查。项目结束时顺手归档。只有这样，它才可能持续。

我的判断 未来两年，Agent 工具的通用能力会快速趋同。真正拉开差距的，不是哪个工具多一个按钮，而是谁拥有更好的私域知识编译层。个人如此，团队也如此。

回到最开始的问题。

这三篇文章给我的最大启发，不是「我们应该学习怎么写 Skill」，也不是「我们应该搭一个 LLM Wiki」。

更深一层的启发是，AI 时代的知识管理终于从「人类为了以后看」变成了「机器为了下一次执行」。

这件事很大。

因为过去所有知识管理工具，本质上都假设人是最终消费者。你写笔记，是为了未来的你看。你写文档，是为了同事看。你整理知识库，是为了新人搜索。

但 Agent 时代，知识的第一消费者可能变成机器。

机器要看的知识，和人要看的知识不一样。人类需要叙事、解释、背景、情绪、案例。Agent 需要边界、锚点、流程、约束、触发条件、验证方式、更新规则。

所以未来好的知识系统，一定是双层的。

上面一层给人看，让人理解、判断、修正。

下面一层给 Agent 用，让它执行、检索、验证、沉淀。

这也许就是我们要做的新项目真正的形状。

不是一个更聪明的聊天框。

不是一个更漂亮的笔记软件。

而是一套把知识变成 Agent 生产力的基础设施。

说真的，这个方向我越想越觉得有意思。

因为它不是在追一个短期热点。

它是在回答一个更长期的问题，当所有人都有强模型、都有工具调用、都有 Agent 工作流以后，什么东西还属于你自己？

答案大概率不是模型。

也不是工作流。

是你积累过、验证过、踩坑过、修正过，并且能被下一次任务直接调用的知识。

这东西，才会越用越厚。

---

参考资料与延伸阅读

本文基于三篇公众号文章，并结合公开资料做原创解读。正文没有整段搬运原文，配图仅引用少量原文图片链接作来源提示。

1. 公众号文章，面向 Skills 编程，用领域知识工程驱动 Code Agent。
2. 公众号文章，深度解析 LLM Wiki / Obsidian-Wiki / GBrain，Agent 时代知识的自组织与自进化。
3. 公众号文章，Harness 不是目的，知识才是护城河，一个 AI 工程交付团队的知识沉淀实践。
4. Andrej Karpathy，LLM Wiki gist。
5. Anthropic，Agent Skills overview。
6. OpenAI，AGENTS.md guide for Codex。
7. Model Context Protocol，Tools specification。
8. Garry Tan，GBrain GitHub repository。

/442a6bf555914893e9891c11519de94f)。
5. Anthropic，Agent Skills overview。
6. OpenAI，AGENTS.md guide for Codex。
7. Model Context Protocol，Tools specification。
8. Garry Tan，GBrain GitHub repository。