AI Agent 的终极形态不是单个 Agent 多强，是一群 Agent 怎么协作，以及它们共同积累的知识怎么不丢失。
Hermes 解决知识积累用的是 LLM Wiki 模式——用 LLM 做蒸馏引擎，把原始信息压成可检索的结构化知识。解决多 Agent 协作用的是 Maestro-Worker 架构——一个指挥、多个干活、共享记忆。解决存量系统兼容用的是混合架构——Hermes 和 OpenClaw 并行，各管擅长的。
这篇讲这三件事的工程实现。
LLM Wiki：Ripgrep + LLM 的知识蒸馏管道
核心思路
传统知识管理靠人手动整理笔记。LLM Wiki 把这个过程自动化：原始信息进来 → LLM 阅读并提取 → 生成结构化蒸馏笔记 → 存入 Obsidian vault → 下次 ripgrep 全文搜索即可检索。
没有向量数据库，没有嵌入模型，没有语义搜索。Karpathy 说过，规模 <200 篇时 ripgrep 就够用，规模大了再上向量检索。
三层文件结构
wiki/
├── entities/ # 实体页：概念定义、核心属性
│ ├── Hermes-Agent.md
│ └── OpenClaw.md
├── sources/ # 原始源：RSS 文章、技术文档的摘要
│ ├── 2026-04-22-Hermes-Agent上手指南.md
│ └── 2026-04-23-Hermes构建第二大脑.md
└── analysis/ # 分析页：交叉蒸馏后的深度内容
├── 2026-04-20-Hermes-Agent中高阶白皮书.md
└── 2026-04-23-AI-Agent生态跃迁白皮书.md
entities/ 是概念定义，每个实体一个文件，200-500 字。sources/ 是原始信息的摘要版本，保留关键信息但不做深度分析。analysis/ 是交叉蒸馏——综合多个 sources 后形成的新洞察。
蒸馏工作流
输入（RSS/网页/对话） → 阅读 → 分类 → 提取 → 写入
↓
entities/ 或 sources/
↓
定期交叉分析 → analysis/
具体操作：把一篇长文发给 Hermes，告诉它"蒸馏到 wiki"。Agent 自动判断是新建 entity 还是更新已有 source，还是生成 analysis。
实体交叉污染检测
Wiki 维护中最隐蔽的问题是实体交叉污染——sources 页面内容指向实体 A，但 wikilink 关联到实体 B。
典型案例：一篇关于公有云 API（openapi.gs-robot.com）的文档，被错误关联到私有云 Iris 实体。根因是缺少公有云的独立实体页。
检测方法：对比内容中的域名/API 路径与 [[]] 关联指向的实体是否一致。修复：新建缺失的实体页 + 更新被污染页面的关联。
资讯学习流：从信息到知识的管道
LLM Wiki 的输入端是资讯学习流。三级管道：
RSS 抓取 → 关键词过滤 → 优先级分级 → 蒸馏入库 → 周报输出
rss-monitor skill 抓取 RSS 源，白名单/黑名单过滤，优先级自动分级（A/B/C），SQLite 去重。A级直接蒸馏入库，B级进周报，C级丢弃。
输出端有两个：
1. 即时蒸馏——A级内容直接生成 wiki 笔记
2. 周报汇总——rss-weekly-writer skill 从周内所有内容中提炼值得记住的链接，生成高密度中文周报
多 Agent 协作：Maestro-Worker 架构
架构图
┌──────────────┐
│ Maestro │
│ (主 Agent) │
│ 记忆 + 调度 │
└──────┬───────┘
│
┌───────────┼───────────┐
│ │ │
┌───▼───┐ ┌───▼───┐ ┌───▼───┐
│Worker1│ │Worker2│ │Worker3│
│ 代码 │ │ 研究 │ │ 写作 │
└───────┘ └───────┘ └───────┘
Maestro 是主 Agent，拥有完整的记忆和上下文。Worker 是子 Agent，独立终端、独立上下文、只返回最终结果。
委派机制
# 单任务委派
hermes delegate --goal "研究 x86 SIMD 指令集最新发展" --toolset "web,terminal"
# 批量并行（最多 3 个同时跑）
hermes delegate \
--tasks '[
{"goal": "研究主题A", "toolset": ["web"]},
{"goal": "研究主题B", "toolset": ["web"]},
{"goal": "研究主题C", "toolset": ["terminal","web"]}
]'
子 Agent 没有主会话的记忆。所有必要信息必须通过 context 字段传递。子 Agent 也不能创建新的子 Agent——防止任务爆炸。
共享记忆方案
多个 Agent 之间需要共享记忆时，用 mem0：
Agent A (Claude Code) → Stop Hook → 写入 mem0 → Qdrant Collection
↓
Agent B (Hermes) → 启动时 → 读取 mem0 → 获得上下文
每个 agent 对共享记忆都有读写权限。Claude Code 的 Stop Hook 在每次对话结束时自动把关键信息写入 mem0，Hermes 在后续会话中读取。
安全边界：Camel 模型
多 Agent 环境下的安全模型用 Camel 架构：
Agent
权限
限制
Maestro
全部工具 + 记忆
不能委派超过 3 层
Worker
指定 toolset
无记忆、无 delegate_task、无 clarify
Cron Agent
独立会话
无对话上下文、不能创建新 Cron
Worker 不能主动向用户提问——它只干活返回结果。如果任务不明确，Worker 做它能做的部分，Maestro 拿到结果后自己判断是否补充信息再派第二轮。
混合架构：Hermes + OpenClaw 并行
Hermes 和 OpenClaw 不是替代关系，是互补关系。
各自擅长的
能力
Hermes
OpenClaw
自进化学习
✓ 核心能力
✗ 需手动维护
记忆治理
小而精（3.5KB）
大而全（35000+ 条）
工具生态
51 个内置，按需加载
44000 个社区 Skill
多通道通信
Telegram/Discord/飞书
同 + Slack/微信
知识蒸馏
LLM Wiki 内建
无
社区规模
早期
成熟
混合部署模式
用户消息 → 路由层 → ┬→ Hermes（学习型任务、知识管理、内容创作）
└→ OpenClaw（工具链集成、社区 Skill 调用）
路由规则：
- 涉及"学""记""写""分析"的 → Hermes
- 涉及"调用工具""连接服务""自动化流程"的 → OpenClaw
- 不确定的 → 两个都试，对比结果
共享知识库
两个 Agent 可以共享 Obsidian vault 作为知识库。Hermes 的 LLM Wiki 写入 vault，OpenClaw 通过文件系统 hook 读取。
但记忆系统不要混用。Hermes 的 MEMORY.md 和 OpenClaw 的 CLAUDE.md 格式不同、治理逻辑不同，混在一起两边都会困惑。
从零到第二大脑：30 天路线图
周
目标
具体动作
第 1 周
基础配置
搭完五套系统，跑通 3 个 Skill
第 2 周
记忆调优
调 nudge_interval，手动初始化 USER.md
第 3 周
知识管道
配 RSS 学习流，蒸馏 10 篇 wiki 笔记
第 4 周
多 Agent
跑通 Maestro-Worker，配置 mem0 共享记忆
第 4 周结束时回头看：Agent 自动积累了 10+ 个 Skill，wiki 里有 20+ 篇蒸馏笔记，Cron 任务自动运行着日报/周报。这些不是你手动维护的——是 Agent 在工作中自己长出来的。
这是 Hermes Agent 系列第三篇。第一篇讲自进化原理，第二篇讲实战配置。
三个系统的核心逻辑：记忆管好不丢失，技能自我迭代不停滞，知识蒸馏不靠人。Hermes 不是最强的 Agent，是活得最久的 Agent——30 天后它比你刚装好时强得多，这件事不需要你做任何事。