把知识库当成一个可校验、能自愈的系统来工程化而不是又一个收藏即整理的笔记 App。这篇不讲工具玄学只讲我真实仓库里跑通的架构、踩过的坑以及你可以直接复制的最小落地工件。结论先行知识库不是笔记软件是系统一句话把知识库当成一个可工程化、可校验、能自愈的系统来设计而不是又一个收藏即整理的笔记 App。我用三件套解决了这个问题Schema-as-code——用一份机器可读的规范AGENTS.md定义库长什么样、怎么动而不是散落在脑子或 App 设置里Agent 当体力劳动者——人负责获取资料和定方向Agent 负责总结、归档、建双链、跑健康检查闭环 自检——Ingest / Query / Lint 三操作形成闭环用 Lint 脚本当CIP0/P1 必须清零。效果都是我仓库里真实跑出来的不是设想IMA 个人知识库 139 条收藏已自动化摄入 12 篇逐文件落盘 0 缺失健康检查 Lint 长期P0/P1 0规范违反、断链、孤立页、索引不一致全部清零采集与吸收解耦收藏的东西先进 IMA / WeKnora 当收件箱每周定时 triage 到主题库破解收藏即读完幻觉知识可被 Agent 直接消费wiki 是结构化的、带 frontmatter 和双链的Agent 查得到、链得动、改得了。下面先说清楚为什么大多数知识库会死再展开我是怎么落地的最后给你一份能直接照做的最小搭建清单。一、先说问题为什么大多数知识库会死我见过太多人包括早期的自己的知识管理死于这五件事收藏即读完幻觉——微信文章、网页一键存存完就等于我学过了三个月后从没打开过。笔记软件绑架——数据锁死在某个 App导出困难换工具成本极高。仓库坟场——只进不出没有结构化、没有关联越攒越像垃圾堆最后连搜索都不想搜。知识无法被 Agent 消费AI 时代最致命——你的笔记是给人看的散文Agent 读不懂、链不动、改不了等于把最有价值的资产锁死了。没有自愈机制——靠自律维护断链、重复、过期全靠记得去修必崩。二、解法总览把库拆成三层 一份权威规范核心思想就一句Obsidian 是 IDEAgent 是程序员wiki 是代码库。人当产品经理只负责搞资料和定方向。架构上把仓库拆成五类目录各司其职raw/原始资料不可变文章、书、论文、播客。Agent 只读不写是 source of truth。wiki/维基站Agent 完全拥有综合、概念、实体、来源、对比。这是代码库本体。notes/个人笔记混合层人写Agent 可补双链其中blog/例外发布到 Hugo 不参与双链。inbox/收集箱未消化内容入口定期 triage。assets/附件桶。最关键的一步写一份AGENTS.md当唯一权威Schema-as-code。库的结构、frontmatter 规范、tag 规范、双链规范、目录归属原则、三个核心操作的 SOP全写进去。所有 Agent 维护时以它为准冲突时以它为准。三、怎么落地三个核心操作形成闭环知识库要活必须有可重复的工程动作。我定义了三个操作1. Ingest摄入把 inflow 来的资料变成 wiki 资产原始资料落入raw/类型/不可变生成wiki/sources/slug.md一句话总结 核心要点 对库的贡献提炼 concepts / entities建双向[[wikilink]]每新页至少 1 入站 1 出站更新wiki/index.md和wiki/log.md把来源写入去重表ima-ingested.json/processed-urls.json避免重复摄入。2. Query查询人提问Agent 综合现有页回答好答案固化为新页写成 synthesis / concepts把临时回答变成沉淀资产。3. Lint健康检查定期跑lint_check.py按严重程度分级P0规范违反必须清零根目录散落文件、raw/images 放错图P1结构/完整性必须清零frontmatter 缺字段、断链、孤立页、索引不一致、source 不可追溯、archive 滞留超 30 天P2质量/新鲜度告警不阻断lastReviewed 超 90 天、页面超 60 天未改。机械问题断链、frontmatter脚本自动修需判断的反链、矛盾标注列待办交人不直接删改内容。四、让它能自己跑连接器 自动化 版本控制光有规范不够得让维护自动发生否则还是靠自律必崩。inflow 设计我把 IMA 个人知识库「xiejava的知识库」和 WeKnora 当收集箱。随手收藏的网页/文章先进 IMA每周自动化 triage 到本地主题库。采集和吸收解耦收藏不再等于压力。每周自动化维护一个定时任务按固定顺序跑——git 基线保证可逆→ IMA 摄入上限 10 篇/周→ 本地 inbox 摄入 → 跑 Lint → 产出周报 → 邮件通知。全部无人值守。git 基线任何创建 / 移动 / 删除前先git add -A commit打基线所有操作可逆。WorkBuddy 定时自动化定时进行知识库的维护自动将ima的内容摄入到本地LLM wiki知识库。定时任务执行完后结果会自动发邮件通知真实踩坑值得所有人警惕连接器是会掉线的。我上一轮维护时IMA 和 qq-mail 一度都没连上环境里只剩 agent-mail导致 IMA 摄入整周跳过、邮件只能用 agent-mail 兜底。教训凡是依赖外部连接器的环节都要设计 fallback 或至少告警否则自动化会在你不知情时静默失效。没有 IMA 这类连接器也完全能玩用你手边任意稍后读工具Notion / 微信收藏 / Readwise当收件箱再用系统自带的定时任务cron / 计划任务触发维护即可零外部依赖的通用方案见第六节。五、效果与代价诚实清单得到的可校验Lint 当 CI规范有脚本兜底可自愈断链 / 过期自动报、机械问题自动修Agent 可消费结构化 wikiAgent 查得到、链得动、改得了可持续自动化 版本控制不靠人记。LLM wiki知识库自动维护周报代价不美化backlog 永远在IMA 库 139 条我只摄入了 12 条剩约 127 条按每周 10 篇清空要 ~13 周。这是节奏问题不是断链但提醒你别指望一次搞定。P2 陈旧债目前 80 个页面「超 60 天未改 / lastReviewed 过期」得靠月复盘批量更新。连接器脆弱外部依赖会断要有 fallback 思维。流程活在 Agent 里clone 我的仓库没用得有自己的 Agent 读AGENTS.md按 SOP 跑。六、从零动手可复制的最小落地这一节是给想真的建起来的人。四样东西目录、规范、一页样例、一个能跑的 Lint。全程不依赖任何付费/封闭连接器。第 1 步建目录5 分钟在一个空文件夹里建好这几块然后git initmy-knowledge-base/ ├── inbox/ # 收集箱新内容先放这里 ├── raw/ # 原始来源不可变 │ ├── articles/ # 网页剪藏 │ ├── books/ # 书籍 │ └── papers/ # 论文 ├── wiki/ # Agent 维护的维基站 │ ├── concepts/ # 概念页 │ ├── entities/ # 实体人/公司/产品 │ ├── sources/ # 来源总结 │ ├── synthesis/ # 综合分析 │ ├── comparisons/ # 对比表 │ ├── index.md # 目录 │ └── log.md # 操作日志 ├── notes/ # 你的个人笔记 ├── assets/ # 图片附件 └── scripts/ # lint 等脚本第 2 步写一份最小AGENTS.md在仓库根目录新建AGENTS.md下面这份可直接复制、按需增改。它就是 Agent 的职责说明书# 我的 LLM Wiki — Agent 维护规范 本文件是唯一权威所有 Agent 维护本库时以它为准。 ## 角色分工 - 人找资料、定方向、提问、判断什么重要 - Agent总结、归档、建双链、跑健康检查等体力活 ## 目录 - raw/ 原始资料不可变Agent 只读不写 - wiki/ Agent 产出并维护concepts/ entities/ sources/ synthesis/ comparisons/ - notes/ 人写Agent 可补双链 - inbox/ 收集箱定期 triage - assets/ 附件 ## 页面 frontmatter强制 --- title: 页面标题 date: 2026-09-27 type: concept # concept | entity | source | synthesis | comparison tags: [lowercase, singular] # 全小写、单数、连字符 summary: 一句话定义 lastReviewed: 2026-09-27 # concept/entity 必填 --- source 页还必须给 source_path / source_url / source_type 三者之一保证每条来源可追溯。 ## 链接规范 - 统一用 [[页面名]] 双链跨目录用 basename 简写[[cairn]] - 每个新页至少 1 条入站 1 条出站 - 要外发到博客/Hugo 的内容不用双链发布后会断 ## 三个操作 ### Ingest摄入 1) 原文落 raw/2) 建 wiki/sources/ 总结页3) 提炼 concepts/entities 4) 建双链5) 更新 index.md6) 追加 log.md7) 记入去重表。 ### Query查询 先检索 wiki 再综合回答标注来源有沉淀价值的答案固化为新页。 ### Lint健康检查 跑脚本并分级报告机械问题自动修需判断的列待办交人不直接删内容。 ## 版本控制 任何破坏性操作前先 git commit 打基线。第 3 步看一个真实 wiki 页长什么样理解为什么 Agent 能消费这种笔记看一页就懂。下面是去掉细节后的概念页骨架——结构化 frontmatter 让 Agent 不用读全文就知道这页是什么双链让 Agent 能顺着关系爬到相关页--- title: LLM Wiki date: 2026-09-27 type: concept tags: [knowledge-management, agent, wiki] summary: 把 wiki 当代码库、由 Agent 增量构建维护的知识库范式 lastReviewed: 2026-09-27 --- ## 一句话定义 LLM Wiki 是一种让 Agent 增量地、持续地构建和维护 wiki 的知识库模式 而非只在查询时做一次性检索。 ## 关键点 - 源与笔记分离原文进 raw/结构化结论进 wiki/ - 每个页面带 frontmatter每个概念靠双链织成网 ## 相关概念 - [[agent]] — 承担维护体力活的执行者 - [[second-brain]] — 这套范式服务的目标对比一段纯散文笔记差别就在Agent 能直接读type/tags/summary做路由能顺着[[]]遍历而不是去猜一段中文在讲什么。下图为LLM wiki真实 wiki 页第 4 步写一个能跑的最小 Lint 脚本不用一开始就追求我那个 400 多行的版本。把下面这份存成scripts/lint_mini.py它只做最有价值的两件事——断链检查 frontmatter 检查在仓库根目录python3 scripts/lint_mini.py即可运行有问题时退出码为 1方便接 CI / 定时任务#!/usr/bin/env python3最小 LLM Wiki Lint断链 frontmatter 两项检查。 在仓库根目录运行python3 scripts/lint_mini.py 退出码0 通过1 有问题。 importos,re,glob,sys ROOTos.getcwd()WIKIos.path.join(ROOT,wiki)REQUIRED[title,date,type,tags,summary]SKIP{index.md,log.md,README.md}defget_frontmatter(text):mre.match(r^---\n(.*?)\n---\n,text,re.S)returnm.group(1)ifmelseNone# 收集所有 wiki 页 basename用于解析双链目标pages{os.path.splitext(os.path.basename(p))[0]forpinglob.glob(os.path.join(WIKI,**,*.md),recursiveTrue)}errors[]forpinglob.glob(os.path.join(WIKI,**,*.md),recursiveTrue):ifos.path.basename(p)inSKIP:continuetextopen(p,encodingutf-8).read()nameos.path.relpath(p,ROOT)fmget_frontmatter(text)iffmisNone:errors.append(f[frontmatter]{name}缺少 frontmatter)else:forkeyinREQUIRED:ifnotre.search(rf(?m)^{key}\s*:,fm):errors.append(f[frontmatter]{name}缺字段{key})forlinkinre.findall(r\[\[([^\]|])(?:\|[^\]])?\]\],text):iflink.strip()notinpages:errors.append(f[断链]{name}- [[{link.strip()}]] 目标不存在)iferrors:print(\n.join(errors))print(f\n共{len(errors)}个问题)sys.exit(1)print(OK无断链frontmatter 完整)跑顺之后再按需逐条加孤立页检查、索引一致性、lastReviewed过期——我自己的脚本也是这么一条条长出来的。第 5 步让它定时自己跑零外部连接器用系统自带的定时任务即可。先写一个维护脚本scripts/weekly.sh#!/usr/bin/env bashset-ecd$(dirname$0)/..gitadd-Agitcommit-mbaseline$(date%F)||true# 让 Agent 按 SOP 处理 inbox换成你实际的 Agent 命令# claude -p 按 AGENTS.md 的 Ingest SOP 处理 inbox/ 下所有新内容python3 scripts/lint_mini.py再用crontab -e加一行每周日上午 10 点自动跑0 10 * * 0 cd /path/to/my-knowledge-base ./scripts/weekly.sh wiki/weekly.log 21注意上面脚本里唯一不依赖 Agent 就能跑的是git 基线 Lint摄入那行需要你有一个能执行命令的 AgentClaude Code 等。没有 Agent 也别等先手动维护把每周清单做成 checklist跑顺了再把重复动作交给 Agent。偏好云端的话把同样两步放进 GitHub Actions 定时跑也可以。七、想抄作业的人记住这几条别抄我的文件抄我的方法论先写一份你自己的AGENTS.md定义目录结构、frontmatter、tag、双链、三操作 SOP把仓库拆成raw / wiki / notes / inbox源与笔记分离写一个 Lint 脚本哪怕只有断链 frontmatter两条设成定期跑inflow 用你已有的工具关键是采集-吸收解耦 定期 triage用 git 管理破坏性操作前打基线没有 Agent 就先手写 SOP 和 checklist逐步再上 Agent。最该借鉴的不是具体文件而是把知识库当系统工程化这个范式。写在最后这套做法让我的知识库第一次活了过来新内容一句话进来就被结构化旧页面有脚本定期巡检知识之间靠双链自己织成网。它不完美——backlog 永远在、连接器会掉、80 个陈旧页等着复盘——但它可校验、可回滚、可被 Agent 接手这就比靠自律强了一个数量级。如果你也在用 Agent 维护个人知识库欢迎交流踩坑。本文的方法论、架构图与自动化流程均来自我真实运行的本地 LLM Wiki 仓库。相关阅读《让 AI 帮你养知识库LLM Wiki Obsidian Claude 的完整实践》《ClaudeCode安装教程小白版》作者博客http://xiejava.ishareread.com/