# The LLM Wiki: 3 Months of Letting Agents Run My Second Brain
**作者**: Sebastian Kehle
**日期**: 2026-07-21T06:26:27.000Z
**来源**: [https://x.com/sebastiankehle/status/2079452931489702369](https://x.com/sebastiankehle/status/2079452931489702369)
---
my obsidian vault is at 454 pages, about 445,000 words, and 7,388 wikilinks. i wrote almost none of those pages by hand.
since early april i run it as an llm wiki. i curate sources and ask questions. coding agents do every other job the vault has: they write the pages, link them, index them, lint them, and commit them to a private git repo.
the premise behind the setup is simple. hand-maintained second brains die the same death every time: the value lives in the maintenance, and the maintenance is exactly what you stop doing after 3 weeks. the notes stay, the currency goes, and 6 months later you have an archive you don't trust. an llm removes the maintenance cost. it does not get bored, it does not skip a week, and it will happily fix 40 broken links on a tuesday night.
so the design question changes. it is no longer "how do i organize my notes". it is "what structure lets an agent maintain knowledge without wrecking it".
a second brain works when you stop being its librarian.
this is the full system, with 3 months of numbers behind it. everything here transfers to any markdown-based setup. obsidian is just where mine happens to live.
split ownership before anything else
the first decision matters more than any folder layout: who owns what.
my vault has two layers.
raw/ is mine. it holds source documents: 341 web articles and clips, 20 transcripts, plus notes, design references, and a few journal entries. when i read something worth keeping, it gets saved there as plain markdown. agents may clean formatting or strip noise, but they never rewrite the substance. my journal entries they read and never touch.
wiki/ belongs to the agents. every page in it is llm-generated and llm-maintained. i read it and i correct it in conversation, but i do not edit it by hand. the agent can create, rewrite, merge, and delete pages as it sees fit, as long as it follows the schema.
knowledge flows one way: raw to wiki, never back. a source document is evidence. a wiki page is the current compiled understanding of that evidence. when they disagree, the fix happens in the wiki, not in the source.
this split is what makes the maintenance delegatable. as long as human notes and agent notes live in the same files, every agent edit is a potential overwrite of something you meant, and you end up reviewing everything, which is the librarian job again. separate the layers and the review problem shrinks to one question: is the compiled understanding faithful to the sources.
whatever tool you use, i would copy this before anything else: one layer you own, one layer the agent owns, flow in one direction.
organize by use, not by type
the folders map to situations, not to note types. no "fleeting notes", no "permanent notes", no zettelkasten numbering.
- raw/ : source documents. yours.
- wiki/ : generated and maintained by agents. inside it:
- index.md : root index, a directory of directories
- work/ : one workspace per job or company you operate
- content/ : what you publish, plus its analytics
- topics/ : durable concepts and syntheses
- ideas/ : things you might build, incl. killed ones
- companies/ : external companies, grouped by why they matter
- tools/ : software you use or study, one page each
- procedures/ : repeatable runbooks
- personal/ : life strategy, operating model, lists
- people/ : contacts, plus public figures you learn from
- meta/ : health reports and audits of the vault itself
the test for a folder is not "what kind of object is this". it is "in which situation do i reach for it". a competitor and a tool are both companies, but i open them in different modes, so they live apart. my vault did not start this way. it took a full reorganization in week 5, and the commit messages from that day read like a thesis: "grow by use instead of vague buckets".
two conventions carry most of the retrieval weight.
hierarchical indexes. the root index.md stays under 25 lines. it points to area indexes, which point to pages. 66 of my 525 markdown files are pure navigation. an agent answering a question reads the root index, picks an area, reads that area's index, then opens 2 or 3 pages. it never scans the tree. that caps the token cost of finding anything at roughly 3 reads, no matter how big the vault gets.
one template for every page. frontmatter with type, created, updated, sources, tags. a title, a one-line definition, the content, a related-pages list, a sources list at the end. my type field allows exactly 14 values and the linter rejects a 15th. the useful trick inside the type system is a question heuristic: a concept answers "what is this idea", a synthesis answers "what does this mean for me across many sources", a playbook answers "how do i actually do this". when a draft page starts growing numbered action steps, it wants to be a playbook.
uniformity here is not pedantry. agents write what they read. every page that follows the template teaches the next page to follow it too, and every exception you tolerate becomes a pattern the model will happily reproduce 50 times.
the rules live in files, not prompts
everything the agents know about the vault comes from files inside it. no pasted prompts, no custom app, no plugin. if a rule is not in a file, it does not exist.
three files govern, in descending scope:
a global file on the machine teaches every agent session, in any directory, how to file things into the wiki. mine documents a small cli, about 150 lines of bash wrapping obsidian's local REST api, with 4 verbs: read, write, append, search. when i tell a coding session in some unrelated repo "file this decision in the wiki", it reads the root index over the api, writes the page, updates the index, done. capture has to work from anywhere, or it stops happening.
AGENTS.md at the vault root is the constitution: 246 lines covering the directory tree, the page template, the source rules, and the index system. CLAUDE.md next to it is literally one line, @AGENTS.md, a shim so claude code auto-loads the same file that codex and any other AGENTS.md-aware tool reads. one schema, every agent. write it once and every model change inherits it.
a schema page inside the wiki is the enforcement layer: the page-type table, a new-page checklist, and a registry of canonical owner pages.
four rules from those files do most of the work, and they transfer to any agent-maintained knowledge base:
every claim traces to a source or gets flagged as unverified. never invented.
a chat is not a source. save a cleaned excerpt as a file first, then cite the file.
every volatile fact has exactly one owner page. every other page links to it instead of copying it.
every mention of a known entity is a link. an unlinked fact is invisible to the graph and to retrieval.
the second rule sounds bureaucratic until you hit the alternative. "user said so in chat, 2026-06-03" kept showing up in my source lists, and it is a citation you can never reopen. provenance that cannot be re-read is decoration.
the third rule turned out to be the most load-bearing line in the whole system, and it gets its own section under learnings.
define a closed set of operations
an agent with a vault and no defined operations invents a new workflow every session. one day it merges duplicates, the next day it creates them, and both times it can justify itself.
so every interaction with my vault is one of 6 named operations, each written down as a skill file the agent loads when triggered. the skill files live once, in one directory, and are symlinked into each agent's config, so every tool runs the same procedures.
ingest
runs when new files land in raw. turns sources into wiki pages and dedupes against existing ones.
update
runs on "file this". applies a stated fact to the canonical owner page.
query
runs on "what do we have on X". index-first navigation, answers with citations.
lint
runs weekly or on "health check". two-layer integrity check, mechanical plus semantic.
enrich
runs on "complete this page". fills gaps from sources, repos, and web research.
reorganize
runs on "split this" or "merge these". structural moves with a mapped plan and confirmation.
the operations are less interesting than the guardrails inside them, because each guardrail generalizes:
your reading list is an attack surface. the ingest skill treats instructions embedded in source documents as untrusted content. an article that says "ignore your previous instructions" gets ingested as an article that says that. it cannot authorize changes to the schema, the skills, or the hooks in the same pass. the moment agents write to the files that instruct agents, prompt injection through saved content becomes a real path, and most people wiring this up have not thought about it once.
"not found" needs a floor. the query skill has an efficiency budget, 3 to 5 pages per question, but also a hard floor: the agent may not claim the vault lacks information until a full-text search comes up empty. without that line, "i did not find it in the index" quietly becomes "it does not exist", and you start distrusting the vault for gaps that were never real.
structure changes need a reviewable plan. the reorganize skill demands a complete old-to-new file mapping and explicit confirmation before anything moves, and it must use git mv, never a global search-and-replace. i did not write that from theory. every line in these skills is a scar from a session that got creative.
put a deterministic gate under the model
this layer is why i trust the vault, and it is the layer most setups skip.
agents respect a failing gate and drift past a written guideline. you can write "always keep indexes in sync" into the rulebook and watch it decay within a week. or you can make an out-of-sync index fail a check that blocks the commit, and the problem disappears permanently.
my gate is a linter: 1,671 lines of python, standard library only, 20 checks, about 2 seconds per full run. structural problems are errors: broken wikilinks, missing or malformed frontmatter, index entries pointing at files that do not exist. drift problems are warnings: orphaned pages nothing links to, index counts that no longer match reality, pages untouched for 90 days, pages over 600 lines, deadlines that have passed.
the checks that earn their keep are the specific ones:
- the passed-deadline check parses german as well as iso dates, because my client offers phrase deadlines as "bis ende" plus a month name. a deadline the linter cannot read is a deadline nobody rechecks. whatever language your commitments hide in, the linter has to speak it.
- company and tool pages are fact cards, and a regex enforces the boundary: headings like "lessons for my business" or prose like "we should" are flagged on those pages. facts about the world and interpretation for your situation live on different pages. that way a strategy change never requires editing 40 company profiles, and a company update never silently rewrites your strategy.
- shipped posts and dated reports are exempt from the staleness check, because their age is their identity. a 90-day-old status page is a problem. a 90-day-old snapshot is an archive. staleness rules need that distinction or they train you to ignore them.
the gate sits in a pre-commit hook 13 lines long: run the linter's own tests, then the linter in strict mode, where warnings block the commit too. nothing enters git history below the bar, and since a vault edit only counts as done once it is pushed, the bar applies to everything.
while drafting this article the gate caught the draft. i had written the german deadline example out literally, and the linter read it as a lapsed deadline inside the article. the example citation stamp registered as a source missing from the source list. both had to be rephrased before the commit went through. the gate reads everything, including articles about the gate.
above the mechanical pass sits a semantic one, and the division of labor is the transferable idea:
links, counts, naming, dates, existence: the script.
contradictions, staleness judgment, merge decisions: the model.
taste, priorities, what gets killed: you.
a script finds a broken link in milliseconds, for free, every time. a model asked to "check the links" finds most of them, differently each run, for tokens. every check i moved down that list made the system cheaper and more reliable at the same time.
run a light daily and a heavy weekly
the maintenance rhythm has two tiers, and the asymmetry is deliberate: near zero daily cost, one real session a week.
daily is 5 minutes, some days zero. in the morning i open one page, an execution tracker: current priorities, active workstreams, dated checkpoints. scan, pick what moves today, close it. no daily note, no template, no boxes to tick. in the evening, if something changed state, the agent updates the owner page. if nothing changed, nothing gets written. the vault records state changes, not attendance.
one convention does quiet work here: tracker pages must not contain sections named "today". everything is either a stable priority queue or an absolute date. a page built around "today" is wrong by tomorrow morning. a page built on absolute dates is merely older. that one rule is why the tracker survives a skipped week without lying.
weekly is 30 to 45 minutes, with the agent at the keyboard. mine runs on sundays, 7 steps: run the health check and file a dated report. close the week's priorities as done, missed, or moved, and write next week's, 5 items maximum. pull the week's metrics into a dated page. sweep the source folder for anything dropped in and never processed. file the week's unfiled decisions. append the recurring logs. write a 10-line summary.
two mechanisms in the weekly do more than the rest combined:
deltas beat absolutes. the metric pages exist so that each sunday can compare against the last one. any number moving the wrong way 2 weeks in a row becomes a named item for the coming week. a snapshot tells you where you are, which you already roughly knew. the series tells you which way you are drifting, which you reliably do not.
regression signals. a priority missed 2 sprints running, or a workstream with no movement for 2 consecutive weeks, gets flagged automatically by the protocol. the flag solves nothing by itself. it converts slow drift, the kind you rationalize daily, into a discrete event you have to look at on a schedule.
and the weekly reports accumulate into the only honest record of whether the system works, which is where the numbers in the next section come from.
what 3 months taught me
1. a healthy knowledge base sometimes shrinks.
page counts from my weekly reports: 188 in mid-april, 279 in early may, then down to 263. up to 479 by early july, then down to 430. the two contractions were consolidation passes that folded duplicate and thin pages into their owners, and they were the healthiest weeks in the log.
unmaintained knowledge bases only grow. if your page count has never gone down, nobody is tending the garden.
2. duplication is the default failure mode, and ownership fixes it, not merging.
a full-vault audit in june found one pricing table restated on 4 different pages and one project's story told 3 times at paragraph length. every copy was correct when written. every copy was also a future lie, because the next change would be applied to one of them and missed on the rest.
merging the pages would have been the obvious fix and the wrong one. small, single-topic pages are the right shape for agent retrieval. the fix was ownership: a registry that names exactly one owner page per volatile fact, a rule that every other page links instead of copying, and a repair convention that rewrites a stale copy in place rather than stacking dated corrections on top.
the same audit found zero hard factual contradictions across 400-plus pages. not because the model is careful. because the structure leaves contradictions nowhere to live.
3. every rule should trace to a failure.
my rulebook grew like a changelog of things going wrong. instruction files turned up blanked to 0 bytes one morning, so the vault moved out of file sync into git with a commit gate. crm-style records started polluting knowledge pages, so records moved out of the vault entirely and only the playbook stayed. untraceable chat citations kept appearing, so chats were banned as sources. warnings kept getting waved through, so warnings became blocking.
i did not design a governance model up front, and i think that is the only reason the rulebook works. write the rule the week its absence costs you something, and not before. the corollary: rules you cannot trace to a real failure are noise, and 50 speculative rules up front is how instruction files turn into mud that agents learn to skim.
4. move everything deterministic out of the model.
three months of tuning collapsed into one direction: whenever a judgment could become a check, it became a check. structure, naming, counts, dates, and existence moved into the script. contradiction-finding and merge decisions stayed in the model. taste stayed with me. cost went down and reliability went up at every single step. the model is the most expensive and least repeatable component you have. spend it only on judgment.
5. test with a scorecard, not a graph view.
the june audit introduced the best evaluation trick i know for a knowledge base: write down the 15 questions you most need it to answer, ask them cold, and score each answer as single-clear or scattered. mine came back 13 single-clear. the 2 that scattered were both about my own taste, what i consider clean code, what i consider good design.
that failure is instructive. facts about the world compile easily. taste externalizes last, because it lives in decisions you never wrote down and the sources never contained. and the pretty graph view tells you none of this. whether the system answers your actual questions in one hop is the metric.
what is still broken
retrieval quality. when i posted about the vault in may i wrote that access is solved and retrieval quality is what i am unsure about. still true. the agent always finds a plausible page. i cannot always tell whether it found the right one, and wrong-but-plausible is worse than a miss because nothing looks broken. my working position: under roughly 10,000 pages, keyword search over well-structured markdown is right-sized, and an embedding layer is not worth the machinery. at 454 pages i am nowhere near the line. but "the structure carries retrieval" is a bet, not a solved problem.
tag sprawl. 662 distinct tags across 454 pages. my own schema warns about exactly this failure mode, and it happened anyway, one plausible tag at a time, because agents generate plausible tags for free. i now suspect tags are the wrong tool once wikilinks and indexes exist. either a hard normalization pass or an honest admission that nothing retrieves through tags anyway.
staleness never stops costing. the audit flagged around 30 pages as authoritative but stale. the countermeasures, inline "as of" date markers on time-sensitive claims plus the 90-day lint warning, contain the problem without solving it. a knowledge base that compiles sources into current understanding pays the currency cost forever. there is no point where it stays fresh on its own.
writing outran reading. a reading-first second brain typically holds 2 or 3 raw sources per synthesized page. mine ran at 0.68 sources per page in april: the system was writing faster than it was reading. the ratio climbed back toward 0.9 as ingest caught up, but i read it as a warning for the whole category. when writing costs nothing, unsourced pages become the path of least resistance, and the no-hallucination rule is the only thing standing between a knowledge base and a very organized pile of assertions.
if you build one
the idea is older than the tooling. vannevar bush described the memex in 1945, a personal store of knowledge navigated by associative trails, and the part he could not solve was who does the maintenance. karpathy sketched the llm-wiki answer in a gist: many small markdown pages, heavy linking, a model as the maintainer. google shipped an open knowledge format in june 2026, markdown bundles with typed frontmatter, that matches this layout almost field for field. i take the convergence as evidence the shape is right, not that anyone involved is clever.
the build order i would use, having done it in the wrong order once:
1. two folders and a direction. a layer you own for sources, a layer the agent owns for compiled pages, flow one way. this split alone beats most note systems.
2. one rulebook file. under 250 lines: the tree, the page template, the no-invention rule, the one-owner-per-fact rule. add a one-line shim so every agent tool loads it.
3. a linter before a second folder. even 10 checks in 100 lines change agent behavior, because a failing gate teaches what a guideline cannot. wire it into pre-commit, make warnings blocking.
4. git from day one. private repo, commit after every session. the day a file turns up empty, history is the difference between an incident and a loss.
5. indexes when navigation hurts. around 50 pages, add per-folder index files and keep the root index tiny.
6. a weekly ritual that produces a dated page with numbers on it. the report series becomes your only honest record of whether any of this works.
and one thing to skip: the governance model. run the loop, let it fail, and turn each failure into the one rule that would have prevented it. my 246-line rulebook is 3 months of specific scars, and that specificity is the only reason agents actually follow it.
3 months in, the trade is this: i gave up writing my own notes, and i got a knowledge base that is current, linted, indexed, and queryable by every agent i run, for 5 minutes a day and one sunday session a week. 880 commits since may. the linter said 20/20 checks clean this morning.
still looking at mem0 and the dedicated memory layers to see what they add past 10,000 pages. if you are running an llm wiki at 10x my size, i want to read that article.
## 相关链接
- [Sebastian Kehle](https://x.com/sebastiankehle)
- [@sebastiankehle](https://x.com/sebastiankehle)
- [3.8K](https://x.com/sebastiankehle/status/2079452931489702369/analytics)
- [@AGENTS](https://x.com/@AGENTS)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [2:26 PM · Jul 21, 2026](https://x.com/sebastiankehle/status/2079452931489702369)
- [3,884 Views](https://x.com/sebastiankehle/status/2079452931489702369/analytics)
- [View quotes](https://x.com/sebastiankehle/status/2079452931489702369/quotes)
---
*导出时间: 2026/7/22 08:40:14*
---
## 中文翻译
# LLM Wiki：让智能体运营我第二大脑的 3 个月
**作者**： Sebastian Kehle
**日期**： 2026-07-21T06:26:27.000Z
**来源**： [https://x.com/sebastiankehle/status/2079452931489702369](https://x.com/sebastiankehle/status/2079452931489702369)
---
我的 Obsidian 仓库目前有 454 个页面，约 44.5 万字，7,388 个 wikilink。这些页面几乎没有一个是我手写的。
从四月初开始，我把它当作一个 LLM wiki 来运营。我负责筛选资料和提问。仓库里所有其他工作都由编程智能体完成：它们撰写页面、建立链接、编制索引、进行 lint 检查，并提交到私有 git 仓库。
这套设置背后的前提很简单。手动维护的第二大脑每次都会以同样的方式死掉：价值在于维护，而维护恰恰是你三周后就不再做的事情。笔记还在，时效性没了，六个月后你面对的是一个你不再信任的档案库。LLM 消除了维护成本。它不会厌倦，不会偷懒跳过一周，而且会很乐意在某个周二晚上修复 40 个失效链接。
所以设计问题变了。不再是我该如何组织我的笔记”，而是什么样的结构能让智能体维护知识而不把它搞砸”。
当你不再做第二大脑的图书管理员时，第二大脑才能真正运转。
这是一个完整的系统，背后有 3 个月的数据支撑。这里的一切都适用于任何基于 Markdown 的设置。Obsidian 只是我的仓库碰巧所在的地方。
首先划分所有权
第一个决定比任何文件夹布局都重要：谁拥有什么。
我的仓库有两层。
raw/ 是我的。它存放源文档：341 篇网页文章和剪藏、20 份转录文本，外加笔记、设计参考和一些日记。当我读到值得保留的内容时，就以纯 Markdown 的形式保存在那里。智能体可以清理格式或去除噪音，但绝不改写实质内容。我的日记它们可以读，但绝不能碰。
wiki/ 属于智能体。其中每个页面都是 LLM 生成并由 LLM 维护的。我会阅读它，并在对话中纠正它，但我不会手动编辑。智能体可以自行决定创建、重写、合并和删除页面，只要遵循 schema 即可。
知识单向流动：从 raw 到 wiki，绝不反向。源文档是证据。wiki 页面是对这些证据的当前编译理解。当两者不一致时，修正发生在 wiki 里，而不是源文档里。
这种划分使得维护可以委托出去。只要人类笔记和智能体笔记存在于同一批文件中，智能体的每一次编辑都可能覆盖你的本意，你最终就得审查一切，这又变回了图书管理员的工作。把两层分开后，审查问题就缩减为一个问题：编译后的理解是否忠实于源文档。
无论你用什么工具，我都会建议你首先复制这一点：一层你拥有，一层智能体拥有，单向流动。
按用途组织，而非按类型组织
文件夹对应的是场景，而不是笔记类型。没有“闪念笔记”、没有“永久笔记”，也没有 Zettelkasten 编号。
- raw/ ：源文档。属于你。
- wiki/ ：由智能体生成和维护。其中：
- index.md ：根索引，目录的目录
- work/ ：你经营的每份工作或公司对应一个工作区
- content/ ：你发布的内容及其分析数据
- topics/ ：持久的概念和综合
- ideas/ ：你可能构建的东西，包括已放弃的
- companies/ ：外部公司，按其重要性的原因分组
- tools/ ：你使用或研究的软件，每个一页
- procedures/ ：可重复的操作手册
- personal/ ：人生策略、运营模式、清单
- people/ ：联系人，以及你学习的公众人物
- meta/ ：仓库本身的健康报告和审计
判断一个文件夹的标准不是这是哪类对象”，而是我在什么场景下会用到它”。竞争对手和工具都是公司，但我打开它们的模式不同，所以它们分开存放。我的仓库一开始并不是这样。它在第 5 周经历了一次彻底重组，那天的提交信息读起来像一篇论文：按用途增长，而不是模糊的分类”。
两个约定承担了大部分检索工作。
层级索引。根索引 index.md 保持在 25 行以内。它指向各领域索引，领域索引再指向页面。我 525 个 Markdown 文件中有 66 个纯粹用于导航。智能体回答问题时会读取根索引，选择一个领域，读取该领域的索引，然后打开 2 到 3 个页面。它从不扫描整棵目录树。这将查找任何内容的 token 成本上限控制在约 3 次读取，无论仓库有多大。
每个页面使用同一个模板。frontmatter 包含 type、created、updated、sources、tags。一个标题、一行定义、正文内容、相关页面列表，末尾是来源列表。我的 type 字段恰好允许 14 个值，linter 会拒绝第 15 个。类型系统里一个有用的技巧是问题启发法：concept 回答“这个想法是什么”，synthesis 回答“跨多个来源看，这对我意味着什么”，playbook 回答“我具体怎么做”。当一个草稿页面开始出现带编号的行动步骤时，它想成为一个 playbook。
这里的统一性不是迂腐。智能体照着它们所读的去写。每一个遵循模板的页面都会教会下一个页面也遵循模板，而每一个你容忍的例外，都会变成模型乐于复制 50 次的模式。
规则存在于文件中，而不是提示词里
智能体对仓库所知的一切都来自仓库内部的文件。没有粘贴的提示词，没有定制应用，没有插件。如果一条规则不在文件里，它就不存在。
三个文件进行管理，按作用范围从大到小排列：
机器上的一个全局文件教会每个 agent 会话，无论在哪个目录，如何把内容归档进 wiki。我的这个文件记录了一个小型 CLI，约 150 行 bash，封装了 Obsidian 的本地 REST API，有 4 个动词：read、write、append、search。当我在某个不相关的代码仓库里对一个编码会话说“把这个决策归档进 wiki”时，它会通过 API 读取根索引，写入页面，更新索引，完成。捕获必须能在任何地方进行，否则它就会停止发生。
知识库根目录的 AGENTS.md 是宪法：246 行，涵盖目录树、页面模板、来源规则和索引系统。旁边的 CLAUDE.md 实际上只有一行：@AGENTS.md，一个垫片，让 claude code 自动加载与 codex 和任何其他识别 AGENTS.md 的工具读取的同一个文件。一个模式，所有 agent。写一次，每次更换模型都自动继承。
wiki 内部的一个模式页面是执行层：页面类型表、新建页面清单，以及权威归属页面的注册表。
这些文件中的四条规则承担了大部分工作，而且它们可以迁移到任何由 agent 维护的知识库：
每条论断都要能追溯到来源，否则就被标记为未验证。绝不凭空捏造。
聊天记录不是来源。先把清洗后的摘录保存为文件，再引用那个文件。
每个易变的事实只有一个归属页面。其他所有页面都链接到它，而不是复制它。
对已知实体的每次提及都是一个链接。未链接的事实对图谱和对检索来说都是不可见的。
第二条规则听起来很官僚，直到你遇到它的反面。“用户在聊天中说过，2026-06-03”不断出现在我的来源列表里，而那是一种你永远无法重新打开的引用。无法重新阅读的出处只是装饰。
第三条规则被证明是整个系统中承重最多的一条，在 learnings 部分下有它自己的小节。
定义一个封闭的操作集合
一个拥有知识库但没有定义操作的 agent，每次会话都会发明新的工作流。今天它合并重复项，明天它制造重复项，而且两次它都能为自己辩护。
所以我与知识库的每一次交互都是 6 个命名操作之一，每个操作都写成一份 skill 文件，agent 在被触发时加载。skill 文件只存在一份，放在一个目录中，并通过符号链接进入每个 agent 的配置，这样每个工具都运行相同的流程。
ingest
当新文件落入 raw 时运行。把来源转化为 wiki 页面，并与现有页面去重。
update
在“归档这个”时运行。将陈述的事实应用到权威归属页面。
query
在“我们有什么关于 X 的资料”时运行。索引优先的导航，带引用作答。
lint
每周运行或在“健康检查”时运行。两层完整性检查，机械层加语义层。
enrich
在“补全这个页面”时运行。从来源、代码仓库和网络研究中填补空白。
reorganize
在“拆分这个”或“合并这些”时运行。带映射计划和确认的结构性移动。
这些操作本身不如其中的防护栏有趣，因为每条防护栏都可泛化：
你的阅读清单是一个攻击面。ingest skill 把嵌入在来源文档中的指令视为不可信内容。一篇写着“忽略你之前的指令”的文章，会被当作一篇写着那句话的文章被摄入。它不能在同一次处理中授权对模式、skills 或 hooks 的修改。一旦 agent 能写入那些指导 agent 的文件，通过保存的内容进行提示词注入就成为一条真实的攻击路径，而大多数搭建这套系统的人从未考虑过这一点。
“未找到”需要一个底线。query skill 有一个效率预算，每个问题 3 到 5 个页面，但也有一个硬性底线：在全文搜索返回空结果之前，agent 不得声称知识库缺少信息。没有这条线，“我在索引里没找到它”就会悄悄变成“它不存在”，而你会开始因为那些从未真实存在的缺口而不信任知识库。
结构变更需要一个可审查的计划。reorganize skill 要求在任何东西被移动之前提供完整的旧到新文件映射和明确确认，并且必须使用 git mv，绝不用全局查找替换。我不是从理论出发写下这条的。这些 skill 里的每一行都是某次会话自作聪明留下的伤疤。
在模型之下放一道确定性的闸门
这一层是我信任知识库的原因，而这也是大多数搭建方案会跳过的一层。
agent 会尊重一道失败的闸门，却会漂移越过一条写下来的准则。你可以把“始终保持索引同步”写进规则手册，然后看着它在一周内失效。或者你可以让一个失去同步的索引触发一道检查、阻止提交，问题就永久消失了。
我的闸门是一个 linter：1,671 行 Python，只用标准库，20 项检查，每次完整运行约 2 秒。结构性问题是错误：失效的 wikilink、缺失或格式错误的 frontmatter、指向不存在文件的索引条目。漂移问题是警告：没有任何链接指向的孤立页面、与实际不符的索引计数、90 天未动的页面、超过 600 行的页面、已经过期的截止日期。
真正物有所值的检查是那些具体的：
- 过期截止日期检查除了 ISO 日期外还解析德语日期，因为我的客户把任务截止日期表述为“bis ende”加上月份名。linter 读不懂的截止日期就是没人会复查的截止日期。无论你的承诺藏在哪种语言里，linter 都必须会说那种语言。
- 公司页面和工具页面是事实卡片，一个正则表达式强制执行这条边界：这些页面上的“对我的业务的启示”之类的标题或“我们应该”之类的行文会被标记。关于世界的事实和针对你处境的解读放在不同的页面上。这样一来，一次策略变更永远不需要编辑 40 份公司档案，而一次公司信息更新也永远不会悄悄改写你的策略。
- 已发布的文章和带日期的报告豁免于陈旧检查，因为它们的年龄就是它们的身份。一个 90 天前的状态页面是个问题。一个 90 天前的快照是一份档案。陈旧规则需要这种区分，否则它们会训练你去无视它们。
门槛就在一个 13 行的 pre-commit hook 里：先运行 linter 自身的测试，然后以严格模式运行 linter，在该模式下警告也会阻止提交。低于标准的任何东西都进不了 git 历史，而且由于一次 vault 编辑只有被推送后才算完成，这个标准适用于一切。
撰写本文时，这道门槛就拦下了我的草稿。我把那个德国截止日期的例子原样写了出来，linter 将其解读为文章内部一个已过期的截止日期。那个示例引用的时间戳被识别为源列表中缺失的来源。两者都必须改写之后提交才能通过。这道门槛会读取一切，包括关于这道门槛的文章。
在机械性检查之上还有一层语义检查，而这种分工才是可迁移的核心思想：
链接、计数、命名、日期、存在性：脚本。
矛盾、陈旧判断、合并决策：模型。
品味、优先级、什么该砍掉：你。
一个脚本能毫秒级找出坏链接，免费，每次都是。让模型"检查链接"能找出大部分，但每次运行结果不同，还要花 token。我沿着这个清单每往下移一项检查，系统就同时变得更便宜、更可靠。
每天轻量运行，每周重度运行一次
维护节奏分两个层级，这种不对称是刻意的：日常成本接近零，每周一次真正的会话。
每日流程 5 分钟，有时是零。早上我打开一个页面，一个执行追踪器：当前优先级、活跃工作流、带日期的检查点。扫一遍，挑出今天要推进的事项，关掉。没有每日笔记，没有模板，没有要打勾的框。晚上，如果有东西状态变了，agent 会更新其所属页面。如果什么都没变，就什么都不写。vault 记录的是状态变化，不是出勤。
这里有一个约定在默默发挥作用：追踪页面不得包含名为"今天"的章节。所有内容要么是稳定的优先级队列，要么是绝对日期。围绕"今天"构建的页面到第二天早上就错了。建立在绝对日期上的页面只是更旧而已。正是这条规则让追踪器在跳过一周后依然不说谎。
每周流程 30 到 45 分钟，agent 在键盘前操作。我的安排在周日，共 7 个步骤：运行健康检查并归档一份带日期的报告。将本周的优先级标记为完成、错过或顺延，并写下下周的，最多 5 项。把本周的指标汇总到一个带日期的页面。清扫源文件夹，处理任何被丢进来却从未处理过的东西。归档本周未归档的决策。追加循环日志。写一份 10 行的总结。
每周流程中有两个机制比其余所有加起来还重要：
增量胜过绝对值。指标页面的存在是为了让每个周日都能与上一次对比。任何连续 2 周朝错误方向移动的数字都会成为下周的一个具名事项。一份快照告诉你你在哪里，而这你已经大致知道。一个时间序列告诉你你正在往哪个方向漂移，而这你是肯定不知道的。
回归信号。一个连续 2 个迭代被错过的优先级，或者一个连续 2 周没有任何进展的工作流，会被协议自动标记。标记本身解决不了任何问题。它把缓慢的漂移——那种你每天为自己找借口的漂移——转化为一个你必须按计划审视的离散事件。
而周报会累积成关于系统是否有效的唯一诚实记录，这正是下一节中那些数据的来源。
这 3 个月教会了我什么
1. 一个健康的知识库有时会缩小。
来自我周报的页面数：4 月中旬 188，5 月初 279，随后降到 263。到 7 月初升至 479，然后降到 430。两次收缩都是合并整理，把重复的、单薄的页面归并进其所属页面，而它们是日志中最健康的两周。
无人维护的知识库只会增长。如果你的页面数从未下降过，就没有人在打理这座花园。
2. 重复是默认的失败模式，而修复它靠的是所有权，不是合并。
6 月的一次全库审计发现一张定价表在 4 个不同页面上被重述，一个项目的故事被讲了 3 遍，每次都有段落那么长。每一份副本在写下时都是正确的。每一份副本也都是未来的谎言，因为下一次变更只会应用到其中之一，而漏掉其余的。
合并页面看似显而易见的修复方案，却是错误的方案。小而单一主题的页面才是适合 agent 检索的形态。真正的修复是所有权：一个为每个易变事实指定唯一所属页面的注册表，一条所有其他页面只链接而不复制的规则，以及一个就地重写过时副本而非堆叠带日期修正的修复约定。
同一次审计在 400 多个页面中发现了零个硬性事实矛盾。不是因为模型小心。而是因为这种结构让矛盾无处容身。
3. 每条规则都应该能追溯到一次失败。
我的规则手册像是一份"出错记录"的更新日志。有一天早上，指令文件被发现清空成了 0 字节，于是 vault 从文件同步迁移到了 git，并加上了提交门槛。CRM 式的记录开始污染知识页面，于是记录被彻底移出 vault，只留下操作手册。无法溯源的聊天引用不断出现，于是聊天被禁止作为来源。警告不断被放过，于是警告变成了阻断项。
我没有预先设计一个治理模型，我想这正是规则手册有效的原因。在缺失某条规则会让你付出代价的那一周写下它，不要更早。推论是：无法追溯到真实失败的规则都是噪音，而预先写 50 条臆测性的规则，正是让指令文件变成一团泥浆、让 agent 学会略读的原因。
4. 把一切确定性的事情从模型中移出去。
三个月的调优坍缩成一个方向：凡是能变成检查项的判断，都变成了检查项。结构、命名、数量、日期和存在性都移进了脚本。矛盾发现和合并决策留给模型。品味留在我这里。每一步成本都在下降，可靠性都在上升。模型是你拥有过的最昂贵、最不可复现的组件。只把它花在判断上。
5. 用记分卡测试，而不是图谱视图。
六月的审计引入了据我所知对知识库最好的评估技巧：写下你最需要它回答的 15 个问题，冷启动提问，然后把每个答案评为“单一清晰”或“分散零乱”。我的结果是 13 个单一清晰。那 2 个分散的问题都是关于我自己的品味——什么算干净代码，什么算好设计。
这个失败很有启发。关于世界的事实很容易编译。品味最后才外化，因为它存在于你从未写下的决策里，而来源中从来不包含这些。而且漂亮的图谱视图什么也告诉不了你。系统能否一跳之内回答你的真实问题，这才是指标。
还有什么没修好
检索质量。五月我发布关于知识库的文章时写道，访问已解决，而检索质量是我不确定的部分。现在依然如此。智能体总能找到一个看起来合理的页面。我无法总是判断它找到的是否正确，而“错误但合理”比完全找不到更糟，因为看起来没有任何东西坏掉。我的当前立场：在大约一万页以下，对结构良好的 markdown 做关键词检索是恰当规模的，嵌入层不值得引入那套机制。在 454 页的规模下，我离那条线还远得很。但“结构承载检索”是一个赌注，而不是已解决的问题。
标签蔓延。454 页上有 662 个不同的标签。我自己的 schema 恰恰警告过这种失败模式，但它还是发生了，一次一个合理的标签，因为智能体生成合理标签是零成本的。我现在怀疑，一旦 wikilink 和索引存在，标签就是错误的工具。要么做一次硬性规范化，要么诚实地承认反正没有任何东西通过标签来检索。
陈旧性永远在持续产生成本。审计标记了大约 30 个权威但陈旧的页面。对策——对时效性声明加上内联的“截至”日期标记，外加 90 天的 lint 警告——只是控制了问题而没有解决它。一个把来源编译成当前理解的知识库，永远在支付这种货币成本。不存在它自行保持新鲜的节点。
写作跑赢了阅读。一个“阅读优先”的第二大脑，通常每个综合页面对应 2 到 3 个原始来源。我的系统在四月时是每页 0.68 个来源：系统写作的速度超过了阅读的速度。随着摄取赶上进度，这个比例回升到接近 0.9，但我把它视为对整个品类的警告。当写作毫无成本时，没有来源的页面成为阻力最小的路径，而无幻觉规则就是知识库和一堆井井有条的断言之间唯一的屏障。
如果你要搭一个
这个想法比工具更古老。Vannevar Bush 在 1945 年描述了 memex，一个通过联想式路径浏览的个人知识库，而他无法解决的部分是谁来维护。Karpathy 在一个 gist 里勾画了 LLM-wiki 的答案：许多小的 markdown 页面，重度链接，用一个模型作为维护者。Google 在 2026 年 6 月发布了一种开放知识格式——带类型化 frontmatter 的 markdown 打包——与这个布局几乎逐字段吻合。我把这种趋同视为“这个形态是对的”的证据，而不是其中任何人有多聪明。
在我按错误顺序做过一次之后，我会采用的搭建顺序：
1. 两个文件夹和一个方向。一个你拥有的层放来源，一个智能体拥有的层放编译后的页面，单向流动。仅这个拆分就胜过大多数笔记系统。
2. 一个规则文件。250 行以内：目录树、页面模板、禁止编造规则、每条事实单一所有者规则。加一个单行 shim，让每个智能体工具都加载它。
3. 在建第二个文件夹之前先建 linter。哪怕 100 行里的 10 项检查也会改变智能体的行为，因为一个会失败的关卡能教会指南教不了的东西。把它接进 pre-commit，让警告变成阻塞。
4. 从第一天起就用 git。私有仓库，每次会话后提交。当某个文件被发现是空的时，历史记录就是“一次事故”和“一次损失”之间的区别。
5. 在导航变痛时建索引。大约 50 页时，添加每个文件夹的索引文件，并保持根索引精简。
6. 一个每周仪式，产出一份带数字的、有日期的页面。这份报告系列是你判断这一切是否有效的唯一诚实记录。
还有一件事可以跳过：治理模型。先跑循环，让它失败，然后把每次失败变成一条本可以阻止它的规则。我那 246 行的规则书是三个月里具体的伤疤，而正是这种具体性让智能体真正遵守它。
三个月下来，这笔交易是这样的：我放弃了自己写笔记，换来的是一个新鲜、经过 lint、有索引、可被我运行的每个智能体查询的知识库，代价是每天 5 分钟和每周一个周日会话。五月以来 880 次提交。今天早上 linter 报告 20/20 项检查全部通过。
仍在关注 mem0 和那些专门的记忆层，看它们在一万页以上能带来什么。如果你正在运行一个规模十倍于我的 LLM wiki，我想读那篇文章。
## 相关链接
- [Sebastian Kehle](https://x.com/sebastiankehle)
- [@sebastiankehle](https://x.com/sebastiankehle)
- [3.8K](https://x.com/sebastiankehle/status/2079452931489702369/analytics)
- [@AGENTS](https://x.com/@AGENTS)
- [升级到 Premium](https://x.com/i/premium_sign_up)
- [2026年7月21日 下午2:26](https://x.com/sebastiankehle/status/2079452931489702369)
- [3,884 次浏览](https://x.com/sebastiankehle/status/2079452931489702369/analytics)
- [查看引用](https://x.com/sebastiankehle/status/2079452931489702369/quotes)
---
*导出时间: 2026/7/22 08:40:14*
