# 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 维基：让代理接管我第二大脑的三个月
**作者**: Sebastian Kehle
**日期**: 2026-07-21T06:26:27.000Z
**来源**: [https://x.com/sebastiankehle/status/2079452931489702369](https://x.com/sebastiankehle/status/2079452931489702369)
---
我的 Obsidian 仓库共有 454 个页面，约 445,000 字，以及 7,388 个维基链接。这些页面我几乎没有一个是手写的。
从四月初开始，我将其作为一个 LLM 维基来运行。我策划来源并提出问题。编码代理负责仓库的所有其他工作：它们撰写页面、链接页面、索引页面、检查代码，并将其提交到私有 git 仓库。
这一设置背后的前提很简单。人工维护的第二大脑每次都会以同样的方式消亡：价值在于维护，而维护恰恰是你三周后停止做的事情。笔记还在，时效性没了，六个月后你拥有的是一个不信任的档案。LLM 消除了维护成本。它不会厌倦，不会跳过一周，并且会很乐意在周二晚上修复 40 个损坏的链接。
因此，设计问题发生了变化。它不再是“我该如何组织我的笔记”，而是“什么样的结构能让代理在不破坏知识的情况下维护它”。
当你不再是第二大脑的图书管理员时，它才开始发挥作用。
这是完整的系统，背后是三个月的数据。这里的一切都适用于任何基于 Markdown 的设置。Obsidian 只是我恰好存放它的地方。
首先要分割所有权
第一个决定比任何文件夹布局都重要：谁拥有什么。
我的仓库有两层。
raw/ 是我的。它保存源文档：341 篇网络文章和剪报，20 份文字记录，加上笔记、设计参考和一些日记条目。当我读到值得保留的内容时，它会以纯 Markdown 格式保存在那里。代理可能会清理格式或去除噪音，但绝不会重写实质内容。我的日记条目它们只读，绝不触碰。
wiki/ 属于代理。其中的每个页面都是由 LLM 生成并由 LLM 维护的。我会阅读并通过对话纠正它，但我不会手动编辑它。代理可以创建、重写、合并和删除它认为合适的页面，只要遵循架构即可。
知识单向流动：从 raw 到 wiki，绝不回头。源文档是证据。维基页面是对该证据当前编译后的理解。当它们不一致时，修复发生在维基中，而不是在源中。
这种分离使得维护工作可以委托。只要人工笔记和代理笔记存在于同一个文件中，每一次代理编辑都可能覆盖你原本的意图，最终你会审查所有内容，这又回到了图书管理员的工作。分离层级后，审查问题缩减为一个问题：编译后的理解是否忠实于来源。
无论你使用什么工具，我都会先复制这一条：你拥有一层，代理拥有一层，单向流动。
按用途组织，而非按类型
文件夹映射到场景，而不是笔记类型。没有“ fleeting notes”（瞬时笔记），没有“ permanent notes”（永久笔记），没有卡片盒编号法编号。
- 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 次读取。
每个页面一个模板。包含 type（类型）、created（创建时间）、updated（更新时间）、sources（来源）、tags（标签）的 Frontmatter。一个标题，一行定义，内容，相关页面列表，末尾的来源列表。我的 type 字段只允许 14 个值，如果出现第 15 个，linter（代码检查器）会拒绝。类型系统中有用的技巧是问题启发法：概念回答“这个想法是什么”，综合回答“这对我在多个来源中意味着什么”，剧本回答“我实际上该如何做”。当一个草稿页面开始出现编号的行动步骤时，它就变成了一个剧本。
这里的统一性不是迂腐。代理写它们读到的东西。每一个遵循模板的页面都在教导下一个页面也遵循它，而你容忍的每一个例外都会成为模型乐于复制 50 次的模式。
规则存在于文件中，而非提示词中
代理对仓库的了解全部来自其中的文件。没有粘贴的提示词，没有自定义应用，没有插件。如果规则不在文件中，它就不存在。
三个文件进行管理，范围依次递减：
机器上的一个全局文件教会每个代理会话（在任何目录中）如何将内容归档到维基中。我的文件记录了一个小型 CLI，大约 150 行 Bash 代码，封装了 Obsidian 的本地 REST API，有 4 个动词：read（读取）、write（写入）、append（追加）、search（搜索）。当我在某个不相关的仓库中告诉编码会话“将此决定归档到维基”时，它会通过 API 读取根索引，写入页面，更新索引，完成。捕获功能必须能在任何地方工作，否则它就会停止发生。
仓库根目录下的 AGENTS.md 是宪法：246 行，涵盖目录树、页面模板、来源规则和索引系统。旁边的 CLAUDE.md 实际上只有一行，@AGENTS.md，作为一个垫片，以便 Claude Code 自动加载与 Codex 和任何其他支持 AGENTS.md 的工具读取的相同文件。一个架构，每个代理。写一次，每次模型更改都会继承它。
维基内的架构页面是执行层：页面类型表、新页面检查清单和规范所有者页面注册表。
这些文件中的四条规则完成了大部分工作，并且它们适用于任何代理维护的知识库：
每个主张都必须追溯到来源，否则标记为未经验证。绝无凭空捏造。
聊天不是来源。先保存清理后的摘录为文件，然后引用该文件。
每个易变事实只有一个所有者页面。其他所有页面链接到它，而不是复制它。
对已知实体的每次提及都是一个链接。未链接的事实对图谱和检索是不可见的。
第二条规则听起来很官僚，直到你遇到替代方案。“用户在聊天中说过，2026-06-03”一直出现在我的来源列表中，而这是一个你永远无法重新打开的引用。无法重新阅读的出处只是装饰。
第三条规则被证明是整个系统中负载最重的一条，它在“心得”部分有自己的章节。
定义一组封闭的操作
拥有仓库但没有定义操作的代理每次会话都会发明一个新的工作流。有一天它合并重复项，第二天它又创建重复项，而且两次它都能自圆其说。
因此，与我的仓库的每一次交互都是 6 个命名操作之一，每个操作都写成技能文件，代理被触发时加载。技能文件只存在一次，在一个目录中，并符号链接到每个代理的配置中，因此每个工具都运行相同的过程。
ingest（摄取）
当新文件落入 raw 时运行。将来源转换为维基页面并针对现有页面去重。
update（更新）
在“归档这个”时运行。将声明的事实应用于规范所有者页面。
query（查询）
在“我们有什么关于 X 的内容”时运行。索引优先的导航，带引用的回答。
lint（检查）
每周或在“健康检查”时运行。双层完整性检查，机械检查加语义检查。
enrich（丰富）
在“完成此页面”时运行。从来源、仓库和网络研究中填补空白。
reorganize（重组）
在“拆分这个”或“合并这些”时运行。带有映射计划和确认的结构性移动。
操作本身不如其中的护栏有趣，因为每个护栏都可以推广：
你的阅读列表是一个攻击面。ingest 技能将嵌入源文档中的指令视为不受信任的内容。一篇写着“忽略你之前的指令”的文章会被作为一篇这么说而被摄取。它不能在同一过程中授权更改架构、技能或钩子。当代理开始写入指导代理的文件时，通过保存内容进行的提示词注入就成了一条真正的路径，而大多数搭建此系统的人从未想过一次。
“未找到”需要一个底线。query 技能有一个效率预算，每个问题 3 到 5 页，但也有一个硬底线：在全文本搜索结果为空之前，代理不得声称仓库缺少信息。没有这条线，“我在索引中没找到它”就会悄悄变成“它不存在”，你会因为从未真实存在的缺口而开始不信任仓库。
结构更改需要一个可审查的计划。reorganize 技能要求在移动任何内容之前提供完整的新旧文件映射和明确确认，并且必须使用 git mv，绝不是全局搜索替换。我不是从理论上写出这条规则的。这些技能中的每一行都是在一次因发挥创意而“翻车”的会话中留下的伤疤。
在模型下设置一个确定性关卡
这一层是我信任仓库的原因，也是大多数设置跳过的一层。
代理会尊重失败的关卡，但会无视书面准则。你可以把“始终保持索引同步”写进规则手册，然后看着它在一周内腐坏。或者，你可以让不同步的索引导致检查失败，从而阻止提交，问题就会永久消失。
我的关卡是一个 linter：1,671 行 Python 代码，仅使用标准库，20 项检查，每次完整运行大约 2 秒。结构问题是错误：损坏的维基链接、缺失或格式错误的 Frontmatter、指向不存在文件的索引条目。漂移问题是警告：没有任何链接的孤立页面、不再匹配现实的索引计数、90 天未触碰的页面、超过 600 行的页面、已过的截止日期。
那些物有所值的检查是具体的检查：
- 过期截止日期检查会解析德语日期和 ISO 日期，因为我的客户提供的截止日期短语是“bis ende”加上月份名称。linter 无法读取的截止日期是没有人会重新检查的截止日期。无论你的承诺隐藏在什么语言中，linter 都必须能说这种语言。
- 公司和工具页面是事实卡片，正则表达式强制执行边界：像“对我业务的教训”这样的标题或像“我们应该”这样的散文会在这些页面上被标记。关于世界的事实和对你的情况的解释存在于不同的页面上。这样，策略变更永远不需要编辑 40 个公司简介，而公司更新也不会悄悄重写你的策略。
- 已发布的文章和带日期的报告免于陈旧性检查，因为它们的年龄就是它们的身份。一个 90 天前的状态页面是个问题。一个 90 天前的快照是档案。陈旧规则需要这种区别，否则它们会训练你忽略它们。
关卡位于一个 13 行长的 pre-commit hook（预提交钩子）中：运行 linter 自己的测试，然后以严格模式运行 linter，警告也会阻止提交。没有任何低于标准的内容进入 git 历史记录，而且由于仓库编辑只有在推送后才算完成，所以该标准适用于所有内容。
在起草本文时，关卡捕获了草稿。我按字面意思写了德语截止日期的例子，linter 将其读取为文章中已过的截止日期。示例引用印章被注册为源列表中缺失的来源。两者都必须在提交通过前重新表述。关卡读取一切，包括关于关卡的章节。
在机械检查之上是语义检查，劳动分工是可转移的想法：
链接、计数、命名、日期、存在性：脚本负责。
矛盾、陈旧判断、合并决策：模型负责。
品味、优先级、什么被否决：你负责。
脚本可以在几毫秒内免费发现一个损坏的链接，每次如此。让模型“检查链接”能找到其中的大部分，但每次运行都不同，并且消耗 token。我在这份清单上向下移动的每一项检查，都同时让系统变得更便宜、更可靠。
进行轻量级的每日维护和重量级的每周维护
维护节奏有两个层级，这种不对称是故意的：每日成本接近于零，每周进行一次真正的会话。
每天 5 分钟，有些天为零。早上我打开一个页面，一个执行跟踪器：当前优先级、活跃工作流、带日期的检查点。扫描，挑选今天要推进的事项，关闭它。没有每日笔记，没有模板，没有复选框。晚上，如果状态发生了变化，代理会更新所有者页面。如果没有变化，则什么都不写。仓库记录的是状态变化，而不是出勤。
这里有一个约定在悄悄起作用：跟踪器页面不得包含名为“今天”的章节。一切要么是稳定的优先队列，要么是绝对日期。围绕“今天”构建的页面到明天早上就是错的。基于绝对日期构建的页面仅仅是变旧了。正是这条规则让跟踪器在跳过一周后也不会撒谎。
每周 30 到 45 分钟，代理在键盘前操作。我的在周日运行，7 个步骤：运行健康检查并存档一份带日期的报告。将本周的优先级标记为已完成、已错过或已移动，并写下下周的，最多 5 项。将本周的指标汇总到一个带日期的页面。扫描源文件夹中是否有任何已放入但未处理的内容。归档本周未归档的决定。追加周期性日志。写一份 10 行的摘要。
每周机制中的两个机制比其余所有机制加起来还要有用：
差值胜过绝对值。指标页面的存在是为了让每个周日都能与上一次进行比较。任何连续两周向错误方向移动的数字都会成为下周的一个命名项目。快照告诉你你在哪里，这你已经大致知道了。系列告诉你正在向哪个方向漂移，这一点你通常不知道。
回归信号。连续两个冲刺错过的优先级，或连续两周没有动作的工作流，会由协议自动标记。标记本身解决不了问题。它将缓慢的漂移——那种你每天都在合理化的漂移——转化为你必须在计划中查看的离散事件。
而且每周报告积累成了关于系统是否有效的唯一真实记录，这也是下一节数据的来源。
三个月教会了我什么
1. 一个健康的知识库有时会缩小。
从我的每周报告中得出的页面计数：4 月中旬 188 页，5 月初 279 页，然后降到 263 页。到 7 月初上升到 479 页，然后降到 430 页。这两次收缩是整合过程，将重复和单薄的页面折叠到了它们的所有者页面中，它们是日志中最健康的几周。
未维护的知识库只会增长。如果你的页面计数从未下降，就没有人在照料花园。
2. 重复是默认的失败模式，修复它的是所有权，而不是合并。
6 月份的一次全仓库审计发现，一个价格表在 4 个不同的页面上重复出现，一个项目的故事以段落长度讲述了 3 次。每一份副本在撰写时都是正确的。每一份副本也是未来的谎言，因为下一次更改只会应用于其中一份，而错过其他份。
合并页面本应是显而易见的修复方法，但却是错误的。小的、单一主题的页面是代理检索的正确形态。修复方法是所有权：一个命名 exa 的注册表