飞书文档、Notion、Confluence——一开始大家很兴奋：项目纪要往里扔，方案往里写，新人入职也能自己查。过半年你再打开，十有八九已经死了：页面过时、链接失效、关键结论还停留在三个版本以前。没人敢信它，最后所有人回到微信/飞书里互相问。
死掉的原因很简单。难的从来不是「把东西写进去」，而是维护：一份需求改了，你得改摘要、改相关页面、改交叉引用，还得核对会不会跟旧结论打架。这种活没人愿意干，最终还是回到跟人不断沟通对齐。
什么是 Agent Wiki
2026 年上半年，DeepWiki、AutoWiki、OpenWiki、GBrain 四家前沿 AI 技术公司几乎同时在做一件事：用大模型读取原始内容（sources），「编译」成一套持续维护的 Markdown 页面。原始内容变，编译结果跟着更新。Agent 在回答问题的时候就不用每次从原始内容从头梳理，可以直接获取处理后的结果。这种方法被越来越多人叫做 Agent Wiki。
举个例子：你做一个项目，材料散得到处都是——飞书里的需求文档、会议纪要、客户微信聊天、几份改了又改的方案。过两个月再问 AI：「这个项目为什么最后选了方案 B？」它只能临时翻一堆原文，现场拼答案。问完就散，下次再问，还得重来一遍。Agent Wiki 干的事，相当于有人一直帮你维护一份「项目说明书」：新材料进来就更新相关页面，旧结论不对了就改掉。你再问同样的问题，AI 读的是整理好的说明书，不是每次从聊天记录和纪要里从头抠。
核心思想：内容输入是处理
不同于 RAG 在查询时处理，Agent Wiki 的核心思想是在输入时处理/编译。RAG 的一般流程是这样的：上传文档，分块和向量化，使用的时候捞出相关分块给 AI 参考，然后 AI 给出结论。
RAG 不是不能用，但是有结构性缺陷。同一个问题问 1 万次，还是重复捞出这些分块给 AI，AI 重复回答，没有任何改进，花费同样的 token、时间和算力。
Agent Wiki 刚好相反，它在输入时处理。每次有新内容输入时，Agent 会主动更新相关内容，并且把相关更新都持久化成文档。
Agent Wiki 怎么用
Agent Wiki 一般有三层结构：
- Raw：原始内容，Agent 会读这些内容，但是不会修改。
- Wiki：Agent 维护的 Markdown 内容，你不应该去手动修改。生成的内容包含摘要信息，人、公司、项目、客户这样的对象信息，还有抽象概念（concept）的文档——比如
验收标准.md、RAG.md这些概念定义相关内容，还有交叉引用（cross-references）。 - Schema：告诉 Agent 怎么使用这套模式，一般写到
AGENTS.md、CLAUDE.md这些文件中。模型会自动读取这些文件，从而知晓怎么维护 Agent Wiki。
Agent Wiki 上日常只跑三件事：接入（ingest）——新材料进来，更新所有受影响的页面；提问（query）——对着 Wiki 回答，好答案也可以写回成新页，让探索本身复利；体检（lint）——定期排查矛盾、过时结论和没人引用的孤儿页。
人维护的知识库为什么必死
公司 Wiki 几乎都会死。开始用起来很爽，一段时间后，一份新材料进来，往往要动十几页——交叉引用、摘要、新旧结论对账。这活没尽头、不出彩。没人愿意真的花时间在这个上面，内容一烂，信任崩掉，Wiki 就真死了。最后变成了一个纯粹在线文档协作工具。
但 AI 不一样，它会不厌其烦地帮你整理，仔细检测不一致的地方，这几乎磨平了之前的维护成本。
存在的问题
扩展
如果不引入 RAG，超过几百个 Wiki 页之后，靠本地 index 文件来索引会占用太多 Agent 的 context，所以在到达一定规模后需要引入 RAG。
信息丢失
接入时处理，意味着早期摘要可能悄悄漏掉原文某个细节，而之后每一次回答都会继承这份丢失。
信息过时
编译 Wiki 页的真实度，最多等于上次刷新那一刻。如果 raw 材料已经更新，但是 Wiki 还没更新，信息就会不同步。
费用
模型来整理文档需要消耗 Token。
总结
Agent Wiki 解决的，是一个卡了人类八十年的问题。
1945 年，Vannevar Bush 提出过 Memex：一套个人知识库，文档之间用联想路径相连。想法不复杂，却卡在最不起眼的一环——谁来维护这些路径？这个问题缺席了八十年。不是没人想过，是没人愿意干。
维护知识库，难的从来不是读，也不是想，是改：改链接、改摘要、拿一份新材料去和几十页旧文档对账。这种活没尽头、不出彩。
Agent Wiki 真正的贡献，是把「改」这件事的成本几乎压到零。模型不嫌烦，不忘改链接，一次能动十几页。知识库第一次有机会活下去。人没变勤奋，维护的活换人干了。
它当然有边界：大了要加检索，摘要会丢细节，不刷新就过时，跑起来要花 token。但这些都是工程问题，不是方向问题。