1. 项目概述一个能自动构建知识库的智能代理如果你和我一样常年被各种文档、论文、笔记淹没每次想找点东西都得在文件夹里大海捞针或者对着聊天记录翻半天那你肯定理解那种“知识明明就在那里但就是串不起来”的无力感。传统的笔记工具无论是Notion、Obsidian还是Logseq本质上都是“你写它存”整理和关联的工作依然得靠你自己。而RAG检索增强生成方案虽然能帮你从文档里找答案但每次提问都得重新扫描一遍原始资料没有积累也无法形成结构化的知识网络。今天要聊的这个llm-wiki-agent项目就是冲着解决这个痛点来的。它不是一个普通的笔记工具而是一个能帮你“写”知识库的智能代理。它的核心逻辑非常清晰你只管把原始资料Markdown格式的论文、文章、读书笔记、会议纪要等扔进一个叫raw/的文件夹然后告诉代理“把这些消化掉”。接下来神奇的事情就发生了——代理会主动阅读这些文档提取其中的关键知识人物、概念、观点并自动构建一个结构清晰、页面间相互链接的维基百科式知识库。更关键的是这个知识库是持续生长的。每当你喂给它一份新资料它不会覆盖旧内容而是将其整合进现有体系更新相关页面甚至能帮你标出不同资料间的矛盾之处。想象一下你正在研究“大语言模型”。你先后导入了Transformer论文、Llama 2技术报告和几篇关于RAG的综述文章。代理会自动创建“注意力机制”、“RLHF”、“上下文窗口”等概念页面也会创建“Meta AI”、“Google Brain”等实体页面。当你问它“减少模型幻觉的主要方法有哪些”时它不再需要临时去翻那几十页的PDF而是直接基于已经梳理好的、结构化的维基页面进行综合回答并且回答中会引用具体的来源页面。这就像你拥有了一位不知疲倦的研究助理它负责阅读、整理和归档而你则专注于思考和提问。这个项目完美适配了当下流行的“个人知识管理”PKM和“第二大脑”理念但它将其中最繁琐、最需要持续投入的“整理”工作自动化了。它基于 Claude Code、Codex 或 Gemini CLI 等编码代理运行无需复杂的API配置或Python环境搭建对技术小白也相当友好。接下来我们就深入拆解它的设计思路、实操细节以及我踩过的一些坑。2. 核心设计思路从“检索”到“编译”的范式转变要理解llm-wiki-agent的价值首先要明白它和传统RAG方案的根本区别。我把它总结为从“检索式”到“编译式”的思维转变。2.1 与传统RAG的对比分析在典型的RAG工作流中当你提出一个问题时系统会执行以下步骤检索将你的问题转化为向量然后在所有文档块chunks的向量数据库中进行相似度搜索找出最相关的几个片段。生成将这些片段和问题一起塞给大语言模型让它“基于上下文”生成答案。这个过程存在几个固有缺陷无状态性每次查询都是独立的系统不“记得”上次查询的结果也不会因为多次查询而变得更聪明。知识没有积累。碎片化检索返回的是原始的、未经加工的文本片段缺乏上下文和关联性。你得到的是一堆“砖头”而不是一堵“墙”或一座“房子”。矛盾滞后如果两份资料观点相左RAG可能在一次回答中同时呈现矛盾双方或者取决于检索到的片段给出片面的答案。矛盾只有在被问到时才可能暴露。无主动整理系统不会主动去建立概念A和概念B之间的联系除非你的查询恰好同时提到了它们。llm-wiki-agent采用了完全不同的路径我称之为“编译式知识管理”预处理编译在摄入Ingest阶段代理就一次性完成深度处理。它解析文档识别实体人物、组织、项目、概念理论、方法、技术提取核心观点并生成结构化的维基页面。知识固化这些生成的页面如wiki/concepts/attention.md是永久的、可迭代的资产。它们用标准的[[维基链接]]相互关联形成了一个内在的知识图。查询即合成当你进行查询Query时代理是在这个已经编译好的、结构化的维基上工作。它综合多个相关页面的内容来生成答案答案天然具备引用和上下文。主动矛盾检测在摄入新文档时代理会主动对比新观点与维基中已有记录一旦发现矛盾立即在相关页面上打上标记。问题前置而不是等到你提问时才发现信息不一致。用一个简单的类比RAG像是一个即时翻译你每次问问题它都现场翻书找答案而llm-wiki-agent像是一位专职秘书你每给TA一摞资料TA就帮你整理归档到一本不断增厚的、有详细目录和交叉引用的百科全书中你以后随时可以查阅这本百科全书。2.2 项目架构与核心目录解析项目的目录结构清晰地反映了这一设计思想。理解这个结构是有效使用它的关键。llm-wiki-agent/ ├── raw/ # 【输入区】存放所有待处理的原始Markdown文件 ├── wiki/ # 【输出区】代理自动生成和维护的维基知识库 │ ├── index.md # 所有页面的目录每次摄入后更新 │ ├── overview.md # 跨所有源文件的“活”的综合概述每次摄入后修订 │ ├── log.md # 追加式的操作日志记录每一次摄入和查询 │ ├── sources/ # 每个源文件对应的独立摘要页面 │ ├── entities/ # 自动创建的人物、公司、项目等实体页面 │ └── concepts/ # 自动创建的理念、框架、方法等概念页面 ├── graph/ # 知识图谱可视化 │ ├── graph.json # 基于SHA256缓存的持久化图数据节点/边 │ └── graph.html # 基于vis.js的交互式图谱可直接在浏览器打开 ├── CLAUDE.md (或 AGENTS.md, GEMINI.md) # 【核心】代理的“操作手册”定义了所有工作流 └── tools/ # 可独立运行的Python脚本需API密钥核心目录职责raw/这是你的“收件箱”。任何你想纳入知识体系的Markdown文件都丢在这里。子目录如raw/papers/,raw/book/只是为了让你自己管理方便代理会递归处理。wiki/这是代理的“工作成果”也是你最终要浏览和查询的知识库。严禁手动直接修改wiki/目录下的文件所有更新都应通过代理的/wiki-ingest命令来完成否则会破坏一致性。graph/这是维基的图形化视图。graph.json是底层数据代理通过对比文件哈希来智能更新只处理变动的部分效率很高。graph.html是一个完全静态、可离线查看的交互式图谱。CLAUDE.md这是项目的“大脑”。它不是一个配置文件而是一份用自然语言写给代理的、极其详细的操作规范说明书。里面定义了什么是实体、什么是概念、页面应该用什么格式包括YAML Frontmatter、如何建立链接、如何检测矛盾、/wiki-ingest和/wiki-query命令具体要执行哪些步骤等等。不同代理Claude Code, Codex, Gemini会读取各自对应的文件。重要心得刚开始使用时最容易犯的错误就是直接去修改wiki/下的.md文件觉得“这里写得不够好我改一下”。这会导致后续摄入时代理基于你修改后的页面进行更新可能会覆盖或产生混乱。正确的做法是如果对某个页面的内容不满意去修改raw/里对应的原始资料或者添加新的补充资料然后重新运行/wiki-ingest。让代理始终作为唯一的“编写者”是维持知识库整洁和可追溯性的关键。3. 从零开始环境准备与初次运行实战理论讲得再多不如动手一试。下面我将以最常用的Claude Code为例带你完成从克隆项目到成功运行第一次知识摄入的全过程。3.1 基础环境搭建首先你需要一个能运行 Claude Code 的环境。目前这主要指的是 Claude Desktop App 或支持 Claude Code 的 IDE 插件。确保你的 Claude 订阅支持 Code 功能。接下来获取项目代码# 克隆项目仓库到本地 git clone https://github.com/SamurAIGPT/llm-wiki-agent.git # 进入项目目录 cd llm-wiki-agent此时你可以用你喜欢的代码编辑器如 VS Code打开这个目录。但更推荐的方式是直接在终端中启动 Claude Code 会话。在项目根目录下执行claude这个命令会启动 Claude Code并让它自动读取当前目录下的CLAUDE.md文件。这个文件就是代理的“圣经”它定义了所有可用的命令和规则。3.2 准备你的第一份“知识食粮”代理只“吃” Markdown 文件。在raw/目录下创建一个测试文件。例如我们创建一个关于“敏捷开发”的简单笔记# 在项目根目录下执行 mkdir -p raw/articles cat raw/articles/agile-intro.md EOF # 敏捷软件开发宣言 我们正在通过实践和帮助他人实践揭示更好的软件开发方法。通过这项工作我们建立了以下价值观 - **个体和互动** 高于 流程和工具 - **工作的软件** 高于 详尽的文档 - **客户合作** 高于 合同谈判 - **响应变化** 高于 遵循计划 也就是说尽管右项有其价值我们更重视左项的价值。 ## 核心原则摘录 1. 我们最重要的目标是通过持续不断地及早交付有价值的软件使客户满意。 2. 欣然面对需求变化即使在开发后期也一样。为了客户的竞争优势敏捷过程掌控变化。 3. 经常地交付可工作的软件相隔几星期或一两个月倾向于采取较短的周期。 4. 业务人员和开发人员必须相互合作项目中的每一天都不例外。 5. 激发个体的斗志以他们为核心搭建项目。提供所需的环境和支援辅以信任从而达成目标。 6. 不论团队内外传递信息效果最好效率也最高的方式是面对面的交谈。 ## 相关方法论 - **Scrum**一种迭代式增量软件开发框架强调团队自组织和时间盒Sprint。 - **Kanban**一种可视化工作流管理方法强调限制在制品WIP和持续改进。 - **极限编程XP**强调工程实践如测试驱动开发TDD、结对编程。 ## 关键人物 - **Kent Beck**极限编程XP的创始人之一。 - **Jeff Sutherland**Scrum的共同创造者。 - **Ken Schwaber**Scrum的共同创造者。 EOF这样我们就有了一个结构清晰的原始 Markdown 文件。3.3 执行第一次知识摄入现在在已经启动的 Claude Code 会话中输入以下命令/wiki-ingest raw/articles/agile-intro.md按下回车后Claude Code 代理就会开始工作。你会看到它逐条输出执行日志大致包括以下步骤读取规范首先确认CLAUDE.md中的指令。解析源文件读取agile-intro.md的内容。创建/更新源页面在wiki/sources/下生成agile-intro.md的摘要页面。提取实体识别出“Kent Beck”、“Jeff Sutherland”、“Ken Schwaber”并在wiki/entities/下为他们创建或更新个人页面。提取概念识别出“敏捷开发”、“Scrum”、“Kanban”、“极限编程”、“测试驱动开发”等并在wiki/concepts/下创建相应的概念页面。建立链接在生成的页面中所有提到的实体和概念都会被自动加上[[wikilink]]。更新索引和概述更新wiki/index.md和wiki/overview.md。记录日志在wiki/log.md中追加本次操作。整个过程大约需要几十秒到一分钟取决于文档长度和模型速度。完成后你可以立即去查看wiki/目录会发现里面已经 populated填充了内容。3.4 验证成果与首次查询让我们看看代理到底生成了什么。你可以用文件管理器或命令行查看# 查看生成的实体页面列表 ls wiki/entities/ # 可能会看到 kent-beck.md, jeff-sutherland.md 等 # 查看生成的概念页面列表 ls wiki/concepts/ # 可能会看到 agile-development.md, scrum.md, kanban.md 等 # 查看某个具体页面比如 Scrum cat wiki/concepts/scrum.md你会看到scrum.md是一个结构良好的 Markdown 页面包含从源文件中提取的关于 Scrum 的描述并且底部会有“提及此概念的源文件”部分链接回wiki/sources/agile-intro.md。同时在agile-intro.md的源页面里所有提到 Scrum 的地方也都被链接到了这个概念页面。现在进行第一次查询。在 Claude Code 会话中输入/wiki-query “敏捷开发有哪些主要的方法论它们之间有什么区别”代理不会再去读原始的raw/articles/agile-intro.md而是会去读取wiki/concepts/agile-development.md、scrum.md、kanban.md、extreme-programming.md这些已经结构化的页面综合它们的内容生成一个带有[[citation]]的回答。回答完成后它通常会问“是否要将此回答保存为合成页面synthesis page” 如果你回答“是”它就会在wiki/syntheses/目录下生成一个新的页面将这次查询的答案永久保存下来成为知识库的一部分。这就是“探索成果也能被积累”的体现。实操技巧文件命名与组织raw/目录下的文件命名最好具有描述性且避免特殊字符和空格。代理会使用文件名去除扩展名作为源页面的标题和文件名。例如raw/papers/attention-is-all-you-need.md会生成wiki/sources/attention-is-all-you-need.md。合理的目录结构如papers/,books/,meetings/不会影响代理处理但能让你自己管理起来更清晰。4. 核心工作流深度解析与高级用法成功运行一次基础流程后我们来深入拆解它的几个核心工作流并探索一些能提升效率的高级技巧。4.1 知识摄入Ingest不只是解析更是整合/wiki-ingest是项目的核心命令。它的工作远比简单的文本解析复杂是一个多阶段的智能整合过程。第一阶段源文档分析与摘要生成代理首先会通读整个 Markdown 文件理解其主旨、结构和关键论点。然后它会在wiki/sources/下创建一个以源文件命名的页面。这个页面不是原文的复制而是一个高度结构化的摘要通常包含元数据通过 YAML Frontmatter 记录来源、作者、摄入日期等。核心摘要用一两段话概括全文。关键要点以列表形式列出最重要的发现或论点。提及的实体与概念列出本文档中识别出的所有实体和概念并链接到它们的专属页面。第二阶段实体与概念的提取与页面管理这是最体现“智能”的部分。代理会基于CLAUDE.md中的定义从文本中识别两类对象实体具有唯一性的具体对象如人物Kent Beck、组织Google、产品iPhone 15、项目Linux Kernel。代理会为每个唯一实体在wiki/entities/下创建页面。页面内容会聚合所有提到该实体的源文档中的相关信息。概念抽象的理念、方法、技术、理论如敏捷开发、机器学习、区块链。代理会在wiki/concepts/下创建或更新概念页面。关键在于更新机制如果实体/概念页面已存在/wiki-ingest不是覆盖而是增量更新。代理会将新文档中的相关信息以逻辑连贯的方式补充到现有页面中。例如你先导入了A文章其中提到“Scrum强调迭代”。之后导入B文章提到“Scrum使用Sprint作为迭代周期”。代理在更新scrum.md时会智能地将这两点信息整合在一起形成更完整的描述。第三阶段矛盾检测与标记这是区别于普通笔记工具的杀手级功能。在整合新信息时代理会主动对比新观点与知识库中已有记录。如果发现直接矛盾例如A文章说“方法X最优”B文章说“方法X有严重缺陷”代理会在相关概念或实体页面的显著位置通常在顶部或一个独立章节添加一个矛盾警示框简要说明矛盾点并引用矛盾的双方来源。这让你在浏览知识库时就能提前发现分歧而不是在决策时被错误信息误导。第四阶段全局索引与图谱更新最后代理会更新wiki/index.md所有页面的目录重写wiki/overview.md基于当前所有知识生成的综合性概述并在wiki/log.md中记录本次操作。同时它会更新graph/graph.json数据文件为可视化图谱准备好最新的节点和边数据。4.2 知识查询Query在结构化网络上进行合成/wiki-query “你的问题”是在编译好的知识库上进行操作。其过程可以理解为问题解析与路由代理首先分析你的问题确定可能涉及的核心实体和概念。相关页面检索它不是进行向量相似度搜索而是直接查找与这些实体、概念直接相关的维基页面通过[[wikilink]]连接以及overview.md等综合页面。内容合成与回答代理读取这些相关页面的内容综合信息生成一个直接、连贯的回答。回答中会使用[[页面名称]]的形式引用来源你可以点击这些链接在Obsidian等支持WikiLink的工具中直接跳转到详细页面。答案归档提议生成回答后代理会询问你是否将此次问答保存为wiki/syntheses/下的一个新页面。如果你同意这个页面就会成为知识库的新成员未来可以被其他查询引用。这实现了“查询即生产”。4.3 知识库维护Lint主动发现知识缺口/wiki-lint是一个强大的维护工具。它会对整个维基进行静态分析生成一份“健康检查”报告通常包括孤立页面哪些页面没有被任何其他页面链接即没有入链。这可能意味着某些概念未被充分整合。断裂链接哪些[[wikilink]]指向了不存在的页面。这通常发生在你手动输入了一个链接或者实体/概念名称识别有误时。待创建页面哪些被频繁提及的术语通过简单的文本频率分析还没有对应的实体或概念页面。代理甚至会建议你寻找哪些类型的资料来填补这个知识缺口。数据稀疏警告哪些实体或概念页面内容非常单薄只有一两条引用。定期运行/wiki-lint就像给你的知识库做一次“体检”能帮助你发现薄弱环节指导你有目的地补充阅读材料。4.4 图谱可视化Graph看见你的知识网络/wiki-graph命令会基于最新的graph.json数据生成或更新graph/graph.html文件。用浏览器打开这个文件你会看到一个交互式的力导向图。节点每个维基页面都是一个节点。sources/源页面、entities/实体页面、concepts/概念页面、syntheses/合成页面通常用不同颜色区分。边有两种。实线边代表显式的[[wikilink]]链接EXTRACTED。虚线边代表代理推断出的语义关联INFERRED例如两个概念在多个上下文中被共同提及但页面间没有直接链接。边上可能标有置信度分数。社区检测图算法Louvain会自动将关联紧密的节点聚类用颜色块表示不同的“知识社区”让你一眼看出哪些主题是紧密相关的。这个可视化工具对于发现知识结构中的意外关联、核心枢纽连接数最多的节点以及孤立的子网络非常有帮助。5. 无缝集成 Obsidian打造动态个人知识中枢llm-wiki-agent生成的维基完全遵循标准的 Markdown 和 WikiLink 语法这使得它能与Obsidian这类双链笔记软件无缝集成产生“112”的效果。你可以把wiki/目录直接当作一个 Obsidian 仓库Vault来打开。5.1 基础集成直接打开最简单的方式就是直接用 Obsidian 打开llm-wiki-agent项目根目录或者只打开其中的wiki/子目录。这样所有代理生成的页面都会出现在你的 Obsidian 侧边栏并且页面间的[[链接]]会完美地显示为内部链接点击即可跳转。Obsidian 的图谱视图也会自动绘制出这些页面之间的关系。5.2 高级模式符号链接推荐如果你像我一样已经有一个庞大的、用于记录其他想法和笔记的主 Obsidian 仓库你可能不希望把代理项目整个混进去。这时符号链接Symbolic Link是最优雅的解决方案。假设你的主仓库路径是~/Documents/My-Obsidian-Vault而代理项目在~/Projects/llm-wiki-agent。在你的主仓库中创建一个目录来存放代理维基比如叫_llm-wiki加下划线可能让它排序靠前或靠后便于管理。创建符号链接将代理的wiki/目录“映射”到主仓库的这个目录下。# 在终端中执行macOS/Linux ln -sfn ~/Projects/llm-wiki-agent/wiki ~/Documents/My-Obsidian-Vault/_llm-wiki # 对于 Windows (PowerShell 或 CMD 以管理员身份运行) # 使用 mklink 命令创建目录联接 mklink /D C:\Users\YourName\Documents\My-Obsidian-Vault\_llm-wiki C:\Projects\llm-wiki-agent\wiki完成之后在你的主 Obsidian 仓库里就会出现一个_llm-wiki文件夹里面的内容实时反映着llm-wiki-agent/wiki/的更新。你可以在主仓库的其他笔记中使用[[_llm-wiki/concepts/agile-development]]这样的语法来引用代理维基中的页面实现双向链接。重要警告符号链接是单向的引用。永远不要通过 Obsidian 直接编辑_llm-wiki下的文件所有修改都必须通过代理的/wiki-ingest命令来完成。否则你会破坏代理对知识库的“单一管理权”导致后续摄入时出现不一致或覆盖你手动修改的内容。5.3 Obsidian 插件配置建议为了让集成体验更好可以配置一些 Obsidian 社区插件Dataview代理生成的页面通常包含 YAML Frontmatter如type: concept,sources: [source-a]。安装 Dataview 插件后你可以在自己的笔记中编写查询动态列出所有“类型为概念的页面”或者“所有提到某个特定源文件的页面”实现强大的自动化汇总。TABLE file.mtime AS 最后更新 FROM _llm-wiki/concepts SORT file.mtime DESCGraph View 过滤代理生成的index.md和log.md页面链接极多在图谱中会成为巨大的“引力中心”干扰视图。你可以在 Obsidian 的图谱设置中添加过滤器来隐藏它们-file:index.md -file:log.mdTemplater你可以创建模板快速向raw/目录添加格式统一的新文档比如读书笔记模板、论文摘要模板确保代理摄入时能更好地解析。5.4 自动化工作流构想结合 Obsidian 的某些插件或系统级自动化如 macOS 的 Automator、Linux 的 inotifywait你可以构建更流畅的流程使用 Obsidian Web Clipper 或简悦等工具将网页文章保存为 Markdown 到raw/inbox/目录。设置一个文件夹监控脚本当raw/inbox/有新文件时自动调用 Claude Code 执行/wiki-ingest。摄入完成后脚本将处理完的文件移动到raw/archive/并发送一个通知。这样你就实现了一个从信息收集到知识内化的半自动化流水线。6. 常见问题排查与实战经验分享在实际使用中你可能会遇到一些典型问题。以下是我在深度使用过程中总结的排查方法和经验。6.1 摄入失败或结果不理想问题表现运行/wiki-ingest后wiki/目录下没有生成预期页面或者生成的页面内容混乱、识别错误。排查步骤检查原始文件格式确保你的.md文件是纯 Markdown 格式。有时从网页复制会带有大量 HTML 标签或奇怪的换行。使用 Markdown 清理工具如pandoc预处理一下会有帮助。# 示例用pandoc清理HTML并转换为标准Markdown pandoc -f html -t markdown_strict messy_input.html -o clean_input.md检查CLAUDE.md规范代理的行为完全由这个文件定义。如果它没有正确识别“实体”和“概念”可能是规范中的定义不够清晰或与你的领域不匹配。你需要用自然语言仔细修改CLAUDE.md中关于“什么是实体”、“什么是概念”的描述并给出更具体的例子。这是高级定制最关键的一步。查看wiki/log.md每次操作都有详细日志。查看最近一次的日志看代理在哪一步出错了或者它给出了什么警告信息。分而治之如果是一篇很长的文档可以尝试先将其拆分成几个逻辑部分如摘要、方法、实验、结论分别放入raw/逐一摄入看是哪部分导致了问题。代理的“理解”能力记住代理依赖于底层大语言模型如 Claude 3的理解能力。对于高度专业、晦涩或包含大量非文本元素如图表、公式的文档识别精度可能会下降。对于这类资料在摄入前手动编写一个结构清晰的摘要性 Markdown 文件作为“源”往往比直接扔进去一个难以解析的 PDF 转换文件效果更好。6.2 图谱可视化没有更新或显示异常问题表现运行/wiki-graph后graph.html没有变化或者打开后节点堆在一起、布局混乱。解决方案确认graph.json已更新检查graph/graph.json文件的修改时间是否在最近。如果没有可能是/wiki-graph命令执行失败或者因为 SHA256 缓存机制认为没有实质变化而未更新。可以尝试先运行/wiki-lint触发一次重新分析再运行/wiki-graph。强制重建图谱你可以手动删除graph/graph.json文件然后重新运行/wiki-graph。这会强制代理从头构建整个图谱数据。浏览器缓存有时浏览器会缓存旧的graph.html。尝试强制刷新CtrlF5 或 CmdShiftR或使用隐私模式打开。图谱布局vis.js 的力导向图初始布局可能是随机的。在生成的graph.html页面中通常会有一些交互控件如果代理按照CLAUDE.md生成了的话你可以点击“稳定布局”或拖动节点进行手动调整。如果节点过多导致一团乱麻可以在CLAUDE.md中定制图谱生成的规则例如只显示concepts/和entities/不显示sources/。6.3 如何处理非 Markdown 格式的资料如 PDF、网页、视频项目本身只处理 Markdown。这是其简洁性的体现但也带来了预处理的需求。标准处理流程转换为 Markdown使用可靠的转换工具。PDFpdftotext(poppler-utils) 提取文本或用nougat、Mathpix等更高级的工具保留公式和表格结构再整理成 Markdown。网页使用readability库或浏览器插件如“简悦”、“SingleFile”提取核心内容并转为 Markdown。视频/音频先用whisper等工具转录为文本再人工或借助 GPT 整理成结构化的笔记 Markdown。清理与结构化转换后的 Markdown 往往很粗糙。你需要进行人工校对和格式化添加合适的标题# H1,## H2、整理列表、确保引用清晰。一份结构良好的原始文档是产出高质量维基页面的前提。存入raw/将最终整理好的 Markdown 文件放入raw/的相应子目录。自动化脚本思路你可以编写一个简单的 shell 脚本或 Python 脚本将上述步骤串联起来。例如一个ingest_pdf.sh脚本可以接受 PDF 路径调用pdftotext和一些文本清洗命令输出到raw/papers/然后自动调用 Claude Code 执行/wiki-ingest。这能极大提升效率。6.4 性能与成本考量速度处理一个 10KB 的 Markdown 文件通常需要 30-60 秒。处理速度取决于文档复杂度、模型响应速度以及网络延迟如果使用云端 API。对于大量文档建议分批摄入而不是一次性处理上百个文件。成本如果你使用的是 Claude Code基于 Claude 3在 Claude Desktop 应用内使用通常是包含在订阅中的没有额外的按 token 计费。但如果你使用需要调用 OpenAI API 的 Codex 代理或者通过tools/目录下的独立脚本运行需要设置ANTHROPIC_API_KEY则需要考虑 API 调用成本。每次/wiki-ingest和/wiki-query都是一次或多次与 LLM 的交互。对于大型文档成本可能不可忽视。建议从小的、高价值的文档开始验证工作流和产出质量。6.5 知识库的版本控制与备份由于整个项目包括wiki/就是一个由 Markdown 文件组成的文件夹你可以轻松地使用Git进行版本控制。cd /path/to/llm-wiki-agent git init # 如果尚未初始化 git add . git commit -m “初始提交包含首次摄入的敏捷开发资料”每次进行重要的摄入或查询生成了有价值的合成页面后进行一次提交。这样你不仅可以回溯知识库的历史状态还能清晰地看到知识是如何一步步积累和演变的。wiki/log.md文件提供了操作层面的日志而 Git 提交历史则提供了文件内容层面的快照。备份策略可以将这个 Git 仓库推送到 GitHub、GitLab 等私有仓库实现异地备份。也可以使用云盘同步工具如 Dropbox, iCloud Drive, Syncthing同步整个项目目录。