由卡帕西创建的 LLM Wiki 现已成为 Hermes-Agent 的内置技能，点击标题不妨一试。
Hermes Agent结合Karpathy的LLM-Wiki，本质在做一件非常直接但极其关键的事情：把原本散落在笔记记录里的知识，转化为可以反复调用、持续增长的结构化资产。
Hermes Agent 现在与 Karpathy 的 LLM-Wiki 捆绑在一起，可以使用 Obsidian 创建知识库和研究库！在很短的时间内，Hermes 通过研究网络、代码和我们的论文，创建了大量的研究成果，围绕 Nous 的所有项目创建了这个知识库。
只需运行 hermes update 并输入
code/llm-wiki《research x》/code
在新消息或会话中开始:)
这个过程并不依赖复杂的魔法，而是依赖清晰的分层结构、稳定的文件约束以及可复用的操作流程，从而让知识像代码一样被管理和演化。
整个系统的关键价值在于“可复利/自我学习”。
一次检索不再只是回答问题，而是生成可以沉淀进知识库的页面；
一次总结不再只是临时输出，而是进入长期存储并参与未来推理。
这种机制直接改变使用方式：从“问一次答一次”转向“越用越聪明”，从而让研究、代码分析和资料整理形成持续积累的闭环。
三层架构逻辑：从不可修改源到可演化知识的清晰分工
这一系统的核心结构是三层架构：immutable raw sources、agent-owned wiki pages、schema config。这三层分别承担不同职责，形成清晰的数据流动路径，避免混乱和覆盖问题。第一层raw/目录只负责存放原始资料，例如论文、网页抓取内容和代码文件，这些内容必须保持原样，作为整个系统最底层的事实来源。
第二层是由Agent维护的wiki页面，这一层才是真正发生“理解”和“重写”的地方。Agent会把raw中的信息转化为结构化页面，并通过wikilinks进行连接，从而形成知识图谱。第三层schema config则定义规则，例如frontmatter字段、目录结构和命名方式，这一层相当于“语法规则”，确保整个知识库长期保持一致性，而不会随着时间演变成混乱集合。
快速启动流程：从命令执行到知识库生成的最短路径
实际操作非常直接。用户只需要运行命令更新Hermes，然后通过指令触发wiki构建流程：
hermes update
随后在新会话中输入：
/llm-wiki
系统就会开始自动执行一系列步骤，包括抓取资料、解析内容、生成页面以及建立链接结构。这一流程的关键优势在于“低门槛”，用户不需要逐步搭建知识库，而是直接触发一个完整的自动化管道。
在短时间内，Hermes可以从网页、代码库和论文中提取信息，并生成大量研究内容。这种能力特别适合需要快速建立领域认知的场景，例如研究新技术栈、分析项目结构或者整理长期学习资料。核心在于，整个过程不仅生成内容，还自动组织内容。
文件结构与知识图谱：为什么YAML和wikilinks是关键设计
系统采用YAML frontmatter和wikilinks组合，这不是随意选择，而是经过验证的高效模式。YAML frontmatter用于存储结构化元数据，例如标签、来源和时间戳，使每一页不仅是文本，还包含机器可读信息，从而支持自动化处理和筛选。
wikilinks则负责连接页面，形成图结构。这意味着知识不再是线性文档，而是网络结构。用户可以从一个概念跳转到相关概念，Agent也可以在推理过程中沿着这些连接进行扩展。更重要的是，这种结构天然适配Obsidian，使可视化图谱、搜索和关系分析几乎无需额外开发。
Query机制的关键突破：让回答变成长期资产
系统中最值得强调的一点，是Query操作中的“file valuable answers back”机制。这一机制要求Agent在回答问题时，将有价值的内容写回wiki，而不是仅仅输出在聊天窗口中。这个设计直接解决了传统对话系统的最大问题：信息无法沉淀。
通过这一机制，每一次高质量回答都会转化为知识库的一部分，从而参与未来查询。这种反馈回路形成了真正的“自增强系统”，用户提问越多，知识库越完善，后续回答也越准确。这种模式让AI从工具升级为长期协作伙伴。
数据安全约束：raw目录不可修改的重要性与风险控制
系统明确规定：Never modify files in raw/。这一规则的意义非常直接，就是保护原始数据不被覆盖。但问题在于，这只是写在说明中的规则，而不是系统层面的强制限制。如果模型行为异常或者误解指令，仍然可能修改这些文件，从而造成不可逆的数据损失。
解决这个问题的最佳方式是增加操作系统层面的保护。例如执行chmod -R a-w raw/，直接让目录变为只读状态。这样即使模型尝试写入，也会被系统拒绝。这种“从语言约束升级为系统约束”的做法，是所有严肃研究环境必须具备的基本防护。
日志系统的脆弱性：格式漂移如何破坏自动化流程
日志解析依赖固定格式，例如：
grep "^\" "$WIKI/log.md" | tail -10
这个命令的前提是日志严格遵循YYYY-MM-DD格式。但现实中，大模型很容易发生格式漂移，例如改成不同日期格式或标题层级变化。这种偏差会导致日志解析失败，从而影响整个系统的可观测性。
更稳妥的方式是使用更宽松的匹配规则，例如：
grep -E "^#+ \?0-9{4}-0-9{2}-0-9{2}" "$WIKI/log.md" | tail -10
同时需要明确一条操作规则：一旦发现日志格式偏离，应立即手动修正，而不是放任混乱累积。因为日志一旦失控，后续调试和审计都会变得极其困难。
工具调用一致性：命名错误如何导致系统失效
技能中提到的search_files工具，必须与实际工具名称完全一致。如果名称错误，例如实际叫search_file或grep_files，那么整个流程在运行时会直接失败，而且错误信息通常不直观。这种问题看起来细小，但会严重影响系统可靠性。
解决方法很简单但必须执行：在发布技能之前，逐一验证所有工具调用名称，并确保文档与实现一致。因为对于自动化系统来说，命名就是接口，一旦不一致，等于接口断裂，后续所有步骤都会失败。
Schema演化机制：如何避免知识库逐渐失控
SCHEMA.md定义了知识库结构，但随着时间推移，这个结构一定会发生变化，例如新增字段或调整目录。问题在于，旧页面不会自动更新，从而导致知识库内部出现不一致状态。
解决这一问题的关键在于Lint机制。系统需要在检查过程中识别出frontmatter不符合当前schema的页面，并标记为需要更新。这种“持续校验”机制可以保证知识库在长期演化过程中仍然保持结构一致，而不是逐渐腐化为不可维护的集合。
批量更新控制：防止一次操作破坏整个知识库
系统设置了一个重要阈值：超过10页的批量修改需要先询问用户。这一设计看似简单，但实际上是防止灾难性错误的关键措施。因为大规模自动修改一旦出错，修复成本极高。
更合理的做法是把这一规则直接嵌入Ingest流程，而不是仅放在Pitfalls中。因为大多数批量修改都发生在数据摄取阶段。如果用户在这一阶段没有看到提示，很容易直接触发大规模改写，从而带来风险。
示例流程的重要性：降低理解门槛的关键缺口
当前说明文档虽然完整，但偏抽象。对于新用户来说，缺少一个具体流程示例会增加理解成本。例如一个简单流程：用户上传论文，系统生成页面，用户提问，答案被写回wiki。这种端到端示例可以显著降低学习门槛。
增加示例的价值在于，它把“概念”转化为“操作路径”。用户不需要理解全部原理，只需要跟着流程执行，就能获得结果。这种设计对工具普及极其关键，因为大多数用户不会阅读完整文档。
总结
Hermes Agent与LLM-Wiki的组合，本质是把AI从笔记本升级为长期知识系统。通过三层架构、可写回机制和结构化组织，它解决了知识无法沉淀的问题，同时也引入了新的工程挑战，例如数据保护、格式稳定和schema演化。这套系统真正的价值，在于让每一次使用都成为未来能力的一部分。