llm-wiki-agent：让 Claude Code 替你维护个人知识库
A personal knowledge base that builds and maintains itself. Drop in sources — Claude (or Codex/Gemini) reads them, extracts knowledge, and maintains a persistent interlinked wiki. Works with Claude Code, Codex, OpenCode, Gemini CLI. No API key needed.
秒懂
- 它是什么？
- llm-wiki-agent 把知识库维护变成一套编码代理技能，喂进 raw/ 目录的文档会被自动提炼成互相链接的 wiki 页面。它的机制独特，但边界也很清楚，适合愿意把整理工作外包给 LLM 的人。
- 适合谁用？
- 适合的对象很明确：已经在用 Claude Code 或 Codex 做研究、读书笔记、会议记录整理，并且不介意让 LLM 替你做知识分类和交叉引用的人。它省掉的是手动建页面、补链接、查矛盾的功夫。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 2 天前。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的是笔记堆积后的整理问题
多数知识管理工具把力气花在搜索上，让你能从自己的笔记里找到东西。llm-wiki-agent 换了个思路：它不等你搜，而是让编码代理在文档进来时就替你读、替你分类、替你写页面。README 里那句描述很直接，它想让 wiki 自己维护自己，用户只管往 raw/ 目录丢文件。这个定位针对的是那种常见困境：收集了一堆 PDF 和摘录，却永远没有动力去回看。项目把整理工作从用户身上挪走，交给了会读配置文件的代理。它不是一个笔记应用，而是一套给代理用的工作流定义。
目录结构就是核心机制
项目的运转不靠后台服务，靠的是一套约定的目录和文件。raw/ 放原始材料，wiki/ 放生成结果，graph/ 放图谱数据。wiki/ 下面再分 sources、entities、concepts、syntheses 四个子目录，分别对应单篇来源的摘要、人物公司项目、思想框架方法、以及查询后归档的答案。index.md 每次摄取后更新，log.md 只追加记录。这套结构本身就是一个知识库的骨架，代理的任务就是往骨架里填肉。graph.json 用 SHA256 缓存节点和边，graph.html 是可视化的入口。整个设计没有数据库，没有服务端，就是一堆 markdown 加一个 JSON 文件。
摄取、查询、检查三个动作
使用方式分三条线。摄取是 ingest 命令，后接文件路径，支持 markdown、PDF、DOCX、PPTX、XLSX、HTML、TXT、CSV、JSON、XML、RST、EPUB 等格式。非 markdown 文件在摄取时自动用 markitdown 转换，不需要单独步骤。查询是 query 命令，让代理从已有 wiki 页面综合出答案，并可以把结果作为新页面归档到 syntheses/。检查是 lint 命令，找出孤立页面、断链、缺失的实体页和数据缺口。README 里给了例子，lint 会提示缺少 mixture-of-experts 的资料，建议补充 Mixtral 论文，也会指出某个项目出现在五个页面里却没有专属页。
安装门槛低，但依赖代理的配置读取
安装过程极简，git clone 后进入目录即可。不需要 API key，不需要 Python 环境，核心是让代理读取对应的配置文件。Claude Code 读 CLAUDE.md 和 .claude/commands/，Codex 和 OpenCode 读 AGENTS.md，Gemini CLI 读 GEMINI.md。Claude Code 还额外提供 /wiki-ingest、/wiki-query、/wiki-lint、/wiki-graph 四个斜杠命令，其他代理则用自然语言触发，效果相同。这个设计有个隐含前提：你必须已经有一个能读懂这些配置文件的编码代理。项目本身不包含任何执行逻辑，它只是给代理一套指令和目录约定。
矛盾检测与图谱是亮点，但依赖代理判断
项目声称在摄取时就标记矛盾，而不是等到查询时才发现。新来源与已有页面冲突时，代理会在摄取阶段给出提示。知识图谱方面，graph.html 把每个 wiki 页面作为节点，[[wikilink]] 作为实线边，代理推断出的隐含关系作为虚线边，还带社区检测聚类。这些功能听起来很完整，但要注意一个前提：矛盾检测和隐含关系推断都依赖 LLM 的判断质量。同一个来源，不同代理或不同模型版本处理，产出的 wiki 结构可能不同。这不是确定性程序，是启发式过程。README 没有说明如何验证代理标注的矛盾是否准确，也没有提供人工确认的流程。
适合长期研究，不适合需要精确控制的场景
项目最典型的场景是持续数周的主题研究，README 里举的例子是读论文、读一本书、记录个人习惯、整理会议记录。这些场景的共同点是材料多、周期长、需要跨来源综合。它不适合的场景也很明显：如果 wiki 页面结构需要严格遵循某种模板，或者每个页面的措辞都要人工把关，这套自动生成机制就会成为负担。另一个潜在问题是 log.md 只追加不修改，时间久了文件会膨胀，README 没有提及日志轮转或清理策略。graph.json 用 SHA256 缓存，意味着来源文件不变时图谱不会重复计算，但缓存失效和重建的触发条件在现有材料里没有详细说明。
同类工具的差异在整理时机
与 llm-wiki-agent 形成对照的是 Obsidian 配合各种 RAG 插件的方案。Obsidian 生态的做法是保留用户手动写的笔记，用向量检索或图谱插件在查询时动态关联内容，整理发生在用户写作时，检索发生在需要时。llm-wiki-agent 把整理提前到摄取阶段，文档一进来就被代理读一遍并写成结构化页面。前者尊重用户的原始表达，后者追求代理的即时结构化。另一个参照是微软的 markitdown，项目用它做格式转换，但 markitdown 只解决文件到 markdown 的转换，不涉及知识提炼和页面维护。llm-wiki-agent 的取舍是：用 LLM 的阅读能力换取手动整理的时间，代价是 wiki 内容的质量上限取决于所用模型的理解水平。
维护成本与许可
项目采用 MIT 许可，可以自由使用、修改、再分发，商用也没有障碍。维护成本主要体现在两方面。一是代理配置的跟进，Claude Code 或 Codex 更新后，CLAUDE.md 和 AGENTS.md 的指令格式可能变化，需要留意项目是否跟进。二是 wiki 目录本身的治理，随着摄取次数增加，entities 和 concepts 页面会越来越多，index.md 的规模会变大，lint 报告只能指出孤立页面和断链，不能替你做删除决定。项目最后推送时间是 2026 年 9 月，仓库没有被归档，但没有检索到正式 release 版本，意味着它可能仍处于快速变动期，目录结构或命令格式存在调整的可能。
编辑结论
适合的对象很明确：已经在用 Claude Code 或 Codex 做研究、读书笔记、会议记录整理，并且不介意让 LLM 替你做知识分类和交叉引用的人。它省掉的是手动建页面、补链接、查矛盾的功夫。不适合的人也很清楚：对 wiki 结构有强控制欲，或者要求每次输出完全可复现的人，会在这套自动维护机制里感到失控。采用前先验证三件事：一是 raw/ 里放进去的 PDF 或 PPTX 经 markitdown 转换后是否保留了你需要的版式；二是你常用的编码代理是否真的读取对应的 CLAUDE.md 或 AGENTS.md 配置文件；三是 graph.html 依赖浏览器打开，离线或内网环境能否满足。若这三关都过，它的价值在于把零散笔记变成一个持续生长的参考体系，而不是又一个只进不出的文件夹。
社区笔记