我们每个人或多或少都有看到好内容顺手收藏的习惯，一种情况是看了内容觉得很不错进行点赞收藏，另一种情况是看了标题和大致内容但是还来及细看，想回头空闲下来再细读一番。
但其实绝大部分收藏后的内容都不会被再打开，一方面是因为散落各地找起来很麻烦，它大概率永远雪藏在 /浏览器/X/小红书/小绿书 等收藏夹里面；另一方面或多或少会有收藏即看过的心理暗示，导致后面基本上不会重新想起。
即使你克服了惰性，收藏也仅仅完成了知识的“收集”，后续如何分类、互联、更新和检索，是一项极其反人性的苦力活，靠纯手工维护几乎没人能长期坚持。
但是这个事情，如果让 Agent 来做，那就省事多了，因为它极擅长结构化地处理内容，只要给它设定好规则，它不仅能 24 小时全天候处理内容，还能不知疲倦地为你维护一座“活”的知识库。
🎯 本文核心导读
很多人的知识收藏之所以越攒越“死”，是因为缺乏持续互联、校正与复用的机制。接下来，我将为你深入拆解 Hermes Agent 是如何真正落地 Karpathy 提出的 LLM Wiki 概念的。我们将看到它如何通过
会话恢复+三层架构+ingest/query/lint的自动化循环，成功将“吃灰”的一次性收藏，爆改成了一套可自我维护、持续生长的知识闭环。
先看下 hermes llm wiki 使用效果
一、知识收藏的三个致命诅咒
大部分人的知识收藏，最终都逃不过这三种“死亡”结局：
-
1. 一次性（存即死）： 丢进收藏夹后就被遗忘，绝大多数资料永远不会被二次打开。
-
2. 无关联（成孤岛）： 即使偶尔重读，知识依然是孤立的。它无法与你之前的阅读产生联系，不能互相印证，也无法标记矛盾。
-
3. 零复用（总重来）： 当遇到实际问题时，想不起曾经学过的方法论，最终只能重新搜索、重新学习一遍。
传统的浏览器收藏和笔记软件，本质上只解决了**“中心化搬运”**——信息被收进来了，但依然是散落的点，最多贴个标签，无法自己长成结构。
Hermes 的 LLM Wiki 设计，正是为了打破这三个诅咒。与偏向“查询时才去检索拼接”的传统 RAG 思路不同，LLM Wiki 的核心理念是：一次性编译，持续性维护。
Hermes Agent 做的不是“给你多建一个收藏夹”，而是把一次性的收藏行为，彻底改造成一条可编译、可互联、可复用的知识工程链路。
具体是怎么做到的？
二、Wiki 文件树：职责分明的三层架构
Hermes 的 wiki 不是简单的文件夹，而是一套有明确职责边界的三层架构：
wiki/
├── SCHEMA.md # Layer 3: 约定、结构规则、领域配置
├── index.md # 分段内容目录，带单行摘要
├── log.md # 按时间顺序的操作日志
├── raw/ # Layer 1: 不可变源材料
│ ├── articles/ # 网络文章、剪报
│ ├── papers/ # PDF、arxiv论文
│ ├── transcripts/ # 会议记录、访谈
│ └── assets/ # 源材料引用的图片、图表
├── entities/ # Layer 2: 实体页面（人物、组织、产品、模型）
├── concepts/ # Layer 2: 概念/主题页面
├── comparisons/ # Layer 2: 对比分析
└── queries/ # Layer 2: 存档的查询结果
三层架构的核心设计原则：
-
• Layer 1 — Raw Sources（
raw/）：不可变。Agent 只读，永不修改；修正结论写在 Layer 2，不写在raw/。 -
• Layer 2 — The Wiki（
entities/+concepts/+comparisons/+queries/）：Agent 创建、更新、互联；所有提炼、分析、对比都在这一层完成。 -
• Layer 3 — The Schema（
SCHEMA.md）：知识库的“宪法”，定义领域范围、文件命名规范、YAML frontmatter 标准、标签分类法、页面阈值和更新策略。
为什么文件树要设计得这么“复杂”？
因为 wiki 要解决的不只是“存文章”，而是让知识变得可操作。
-
• 实体页（
entities/）记录“谁 / 什么”，概念页（concepts/）记录“是什么 / 为什么” -
• 对比页（
comparisons/）记录“A 和 B 哪个更好” -
• 查询存档（
queries/）记录“这个问题的答案值不值得保存”
每个目录对应一种知识类型，Agent 依据类型决定读写策略。
三、会话恢复：每次对话开始的第一件事
这是 LLM Wiki最容易被忽视、也最关键的机制。每次会话恢复时，Agent 都必须先做三件事，才能开始工作：
# 关键定位读取——每次会话必须执行
WIKI="${wiki_path:-$HOME/wiki}"
read_file "$WIKI/SCHEMA.md" # ① 理解领域范围、约定、标签分类法
read_file "$WIKI/index.md" # ② 了解现有页面和它们的一行摘要
read_file "$WIKI/log.md" offset=<last 30 lines> # ③ 了解近期操作记录
为什么这是 CRITICAL？ 仓库里的 SKILL.md 把这一步标成了重点，因为它能防止四类退化：
这意味着：即使 Hermes agent 昨天刚为你入库了 10 篇文章，今天对话一开始，它也需要重新读一遍 SCHEMA + index + log。 只有这样，新工作才会建立在已有知识库之上，而不是另起炉灶。
四、核心操作循环：ingest → query → lint
LLM Wiki 有三个核心操作，对应三种不同的 Agent 行为模式。
4.1 Ingest：入库
当用户提供一个 URL、文件或文本时，触发 ingest：
当你丢给 Agent 一篇文章或链接时，它会在后台丝滑地完成一套“知识消化”连招：
📥 无损落袋：无论是网页、论文还是纯文本，Agent 首先将其原封不动地存入 raw/ 目录，作为不可篡改的源文件。
🧠 盘点家底与连锁更新：这是 Wiki 和普通收藏夹的本质区别！Agent 会先扫描 index.md 查阅“现有家底”。旧概念有了新进展？直接更新已有页面；出现相反观点？在元数据里标明矛盾；仅当一个概念在多处反复出现时，才为其创建独立页面。
🕸️ 强制织网：新知识绝不能是孤岛。遵循“每页至少 2 个双向链接（[[wikilinks]]）”的铁律，Agent 甚至会主动修改老页面，让它们反向链接到你刚存入的新知识。
📝 登记造册：最后，将新动作同步至总目录（index.md）和操作日志（log.md），并向你发送一份干净利落的变更报告。
4.2 Query：查询
当用户提问且已有 wiki 存在时，触发 query：
查询策略：精准定位，让知识自动“反刍”
🔍 分级检索：提问时，Agent 不会像无头苍蝇一样全文搜索，而是先读取 index.md 找相关页面精准打击；只有当 Wiki 极其庞大时，才会动用关键词覆盖。
💡 高光提炼与回写（Write-back）：这是最精妙的一环。如果 Agent 综合多个页面为你生成了极具价值的深度答案或对比分析，它不会“阅后即焚”，而是自动将其沉淀到 queries/ 或 comparisons/ 目录中。你向它提问的过程，本身就是知识库自我生长的过程。
4.3 Lint：质量检查
定期健康检查，核心至少看这 9 项审计：
知识库的自动化“全身体检”
纯手工维护知识库最大的痛点，就是久而久之会产生大量“死链”和“垃圾”。Agent 会定期扫描所有页面，并执行三大维度的隐患排查：
🕸️ 连通性体检：揪出没有被任何人引用的“孤立页面（Orphan）”，以及指向错误的“死链（Broken links）”。
📐 规范性体检：核对 index.md 目录是否漏记了文件、页面标签是否超出了 SCHEMA 的约定、元数据（Frontmatter）是否缺失。
🧠 内容健康度体检：排查长期未更新的过时内容、建议拆分过长的页面，甚至能自动检测出同一个主题下互相矛盾的结论（Contradictions），并提醒你介入。
体检完成后，Agent 会生成一份按严重程度分级的报告写进日志。知识库再大，也不会腐化。
五、Wiki 页面规范：frontmatter 与 wikilinks
5.1 YAML frontmatter（每页必须有）
每个 wiki 页面都以标准 YAML frontmatter 开头：
---
title: Multi-Agent Patterns
created: 2026-04-14
updated: 2026-04-14
type: concept
tags: [ai-architecture, multi-agent, collaboration]
sources: [raw/articles/multi-agent-collaboration-patterns-2026.md]
---
字段说明：
|
字段
|
必填
|
说明
|
| :-- | :-- | :-- |
| title |
✅
|
页面标题
|
| created |
✅
|
创建日期，格式为 YYYY-MM-DD
|
| updated |
✅
|
最后更新日期，每次修改都要更新
|
| type |
✅
| entity / concept / comparison / query / summary |
| tags |
✅
|
来自 SCHEMA.md taxonomy 的标签
|
| sources |
✅
|
引用来源，如 [raw/articles/...]
|
| contradictions |
⚠️
|
有矛盾时才加
|
5.2 Wikilinks：知识互联的核心
## 相关概念
- [[generator-verifier]] — 生成-验证循环，最简单也最广泛
- [[orchestrator-subagent]] — 层级制调度
两个强制规则：
wikilinks 不是装饰，它们是真实的关系记录。 当你说“链接到 generator-verifier”，wiki 里的关系网就会多一条边。积累足够多之后，再问“所有跟协作模式相关的内容”，Agent 直接从这张网里提取，不需要每次都重新检索全文。
六、示例展示：一篇多智能体协作文章，如何被编译进 Wiki
6.1 Step 1：会话恢复（每次必须）
Hermes 新会话开始
→ 读取 SCHEMA.md（领域：AI 行业观察、自媒体创作...）
→ 读取 index.md（现有 9 个页面：multi-agent-patterns、prompt-caching...）
→ 读取 log.md（最近：ingest | hermes-agent-closed-learning-loop）
→ 确认：multi-agent-patterns 已在 wiki 中，本次是更新 / 完善
6.2 Step 2：原始抓取
微信文章场景（私有扩展示例）：
来源：https://mp.weixin.qq.com/s/UowaONlXJb5mXQaPANB8vA
《多智能体协作指南：五种主流模式怎么选、怎么用？【译】》
抓取方式：
自建微信抓取器 / 私有 skill → urllib 脚本
→ 标题、正文字符数约 7,681
→ 保存至 raw/articles/multi-agent-collaboration-patterns-2026.md
这里要分清楚两层：上游默认实现是 web_extract，微信文章只是一个部署侧扩展示例。 文章里用它，是为了说明同一套 wiki 闭环怎么接不同来源，而不是说 Hermes 官方默认就内置了这条微信抓取链。
6.3 Step 3：分析与讨论
Skill 文档约定 vs 我们实际做法：
仓库里的 Skill 文档写的是“Discuss takeaways with the user”，也就是先和用户讨论要点。但在 Hermes 的飞书 / Telegram 场景下，这个环节被省略，改为 Agent 自动完成 5 维度分析：
|
维度
|
内容
|
对 wiki 的意义
|
| :-- | :-- | :-- |
| 选题 |
多智能体协作模式选型
|
确定是否入库，是否满足 Page Thresholds
|
| 结构 |
总述 + 五种模式分述
|
提炼成 concepts/ 的骨架
|
| 风格 |
实践指导，模式对比
|
学习写作手法，写入 comparison 页
|
| 亮点 |
五种模式完整覆盖 + 选型决策树
|
核心知识，写入 concepts/
|
| 可学习 |
维度设计 + 方法论
|
补充到相关页面的交叉引用
|
6.4 Step 4：写入 Wiki（分层存储）
concepts/multi-agent-patterns.md（frontmatter + wikilinks）：
---
title: Multi-Agent Patterns
created: 2026-04-14
updated: 2026-04-14
type: concept
tags: [ai-architecture, multi-agent, collaboration, patterns]
sources: [raw/articles/multi-agent-collaboration-patterns-2026.md]
---
# Multi-Agent Patterns（多智能体协作模式）
## 五种模式总览
| 模式 | 核心机制 | 适用场景 | 协作复杂度 |
| --- | --- | --- | --- |
| Generator-Verifier | 生成 → 验证 → 迭代 | 质量敏感、有明确评估标准 | 低 |
| Orchestrator-Subagent | 中央调度 → 子任务分配 | 任务可拆解、子任务边界清晰 | 中 |
| Agent Teams | 成员池 → 抢单 / 分配 | 并行处理、长时间运行 | 中 |
| Message Bus | 发布-订阅 → 事件驱动 | 流水线作业、系统持续扩展 | 高 |
| Shared-State | 共享黑板 → 读写锁 | 高度协作、实时共享发现 | 高 |
## 选型决策树
你的场景更看重输出质量、有明确评估标准？
└─ 是 → Generator-Verifier
任务可并行、互不依赖、需要长时间运行？
└─ 是 → Agent Teams
事件驱动流水线、智能体还在不断扩增？
└─ 是 → Message Bus
需要高度协作、实时共享发现、消除单点故障？
└─ 是 → Shared-State
以上都不符合 → Orchestrator-Subagent（最通用起点）
## 核心方法论
从最简单、最能先跑通的模式开始，观察瓶颈在哪里，再逐步升级。
## 相关概念
- [[generator-verifier]] — 生成-验证循环
- [[orchestrator-subagent]] — 层级制调度
- [[agent-teams]] — 成员自主模式
- [[message-bus]] — 发布-订阅模式
- [[shared-state]] — 共享黑板模式
6.5 Step 5：更新导航
index.md 更新：
## Concepts
<!-- alphabetical -->
- [[multi-agent-patterns]] — 五种多智能体协作模式的选型维度汇总
- [[generator-verifier]] — 生成-验证循环：生成 → 验证 → 迭代的质量保障
- [[orchestrator-subagent]] — 调度-子代理：中央调度式的任务分解
...
log.md 追加：
## [2026-04-14] ingest | 多智能体协作指南：五种主流模式
- Source: https://mp.weixin.qq.com/s/UowaONlXJb5mXQaPANB8vA
- Files created:
- raw/articles/multi-agent-collaboration-patterns-2026.md
- concepts/multi-agent-patterns.md（更新：新增 5 个 wikilinks）
- Index updated: Total pages: 10
6.6 Hermes Agent 回复标准格式
✅ 文章已入库完成！
📥 抓取结果
标题：多智能体协作指南：五种主流模式怎么选、怎么用？【译】
来源：公众号
主题：AI 架构 · 多智能体协作模式选型
字数：约 7,681 字
📚 Wiki 入库文件
/root/.hermes/wiki/
├── raw/articles/multi-agent-collaboration-patterns-2026.md ← 原始文章
├── concepts/
│ ├── multi-agent-patterns.md ← 五种模式总览
│ ├── generator-verifier.md ← 模式1：生成-验证者
│ ├── orchestrator-subagent.md ← 模式2：调度-子智能体
│ ├── agent-teams.md ← 模式3：智能体团队
│ ├── message-bus.md ← 模式4：消息总线
│ └── shared-state.md ← 模式5：共享状态
├── index.md ← 已更新
└── log.md ← 已追加记录
创建页面：6个（5个概念页 + 1个总览页），所有页面通过 [[wikilinks]] 互相链接。
🧠 文章核心要点
核心提炼：多智能体协作根据任务特性（可拆分 / 并行 / 质量评估）选择匹配模式，不存在“最优模式”。
选型决策树：Generator-Verifier → Agent Teams → Message Bus → Shared-State → Orchestrator-Subagent（通用起点）
实战建议：从 Orchestrator-Subagent 开始，先跑起来，观察瓶颈再升级
这里的核心价值，并不在于 Hermes 输出了一段多么漂亮的“入库报告”。它的核心壁垒在于：仅凭一次指令触发，Agent 就在后台静默且精准地包揽了源文件归档、知识提取、索引重写以及交叉互联的全套工程动作。正是这一连串的自动化处理，将知识从传统的“被动存档”模式，强行拉升成了跨会话、可延续的“系统状态”。
七、方案对比： LLM Wiki 与传统笔记、普通 RAG 的本质区别
表面看它也像“收藏 + 问答”，但真正把它和普通收藏夹、Notion 知识库、甚至一层薄 RAG 拉开差距的，是知识有没有被写回成跨会话可延续的系统状态。
八、Obsidian 集成：让 Wiki 可视化
llm-wiki 与 Obsidian 的深度集成让知识库可视化变得简单直观,wiki 目录可以直接作为 Obsidian vault 打开：
-
•
[[wikilinks]]会原生渲染为可点击链接。 -
•
Graph View可以可视化整个知识网络。 -
• YAML frontmatter 可以直接配合 Dataview 查询，例如：
TABLE tags FROM "entities" WHERE contains(tags, "ai-architecture") -
•
raw/assets/文件夹可以存放图片，引用格式为![[image.png]]。
服务器场景的无头同步方案：
对于无显示器的服务器，可使用 obsidian-headless 方案进行同步
服务器：Hermes 写入 ~/wiki
→ obsidian-headless --continuous 实时同步
本地：Obsidian 桌面版打开同一 vault
→ 查看 Graph View / 写新笔记 / 做知识梳理
→ 变更通过 Obsidian Sync 推回服务器
安装和配置
# 安装和配置
npm install -g obsidian-headless
ob login --email <email> --password '<password>'
ob sync-create-remote --name "LLM Wiki"
cd ~/wiki
ob sync-setup --vault "<vault-id>"
ob sync --continuous
九、总结：让知识系统真正产生“复利”
Karpathy 在构想 LLM Wiki 时，有一个极其核心的理念：
只有当这次执行里留下的有效经验，下一轮还能继续发挥作用，知识系统才会开始形成复利。
Hermes Agent 把这个 LLM Wiki 概念进行了落地，彻底跑通了从“信息收集”到“知识调用”的闭环：
-
1. 状态可延续（会话恢复）：告别“聊完即焚”。每次开启对话，Agent 都会自动加载知识库状态，确保所有的新工作都建立在已有知识的基石之上。
-
2. 读写有边界（三层架构）：
raw层作为护城河保障源材料绝对客观，Layer 2 承载分析与提炼，而SCHEMA则是约束一切的最高宪法。 -
3. 网络可生长（强制关联）：用“每页至少 2 个
wikilinks”的铁律拒绝知识孤岛，让知识图谱随着每一次入库自动编织、生长。 -
4. 重编译轻检索（超越传统 RAG）：不再是每次提问时临时去“大海捞针”，而是把思考前置。一次编译、持续维护，让系统的每次回答都反映知识库的最新生命状态。
这里面最具有革命性的思路转变是：知识的收集、整理、回链和更新，终于不再是一项考验人类意志力的反人性苦力活，而是交接给了一个拥有持续进化能力、且不知疲倦的 Agent。
收藏是死的。知识联网，才是活的。
参考信息
AI趣实验 出品 （全平台同名）
