让Hermes Agent自己维护知识库，一套可落地的多智能体自动化方案

原文链接：https://mp.weixin.qq.com/s/m85bEzxSeu0QOXljXkZKfQ

通过看板实现多Agent协作工作流

今天发现一个开源的一套Hermes Agent多 Agent 工作流模板，它提供了一些脚本和配置，可以用来生成搭建多Agent工作流所需的命令（建立profile、看板等）。下面以多Agent工作流自动抓取、更新知识库为例使用这个模板可以实现的效果。

一、为什么需要一个会”自我更新”的知识库

如果你长期跟踪某个快速迭代的技术领域——比如 Hermes Agent——你一定有过这样的感受：

昨天看的文档，今天可能已经过时了。每次启动新任务都要让 Agent 重新”学”一遍背景知识，既浪费 Token 又容易出错。手动整理 Release Notes、社区讨论、官方文档，费时费力，还容易遗漏。

这就是 LLM Wiki（也叫知识库，Karpathy 风格）的用武之地。它是一个结构化的 Markdown 知识图谱，把散落在 GitHub、官方文档、社区帖子里的信息，统一整理成供 Agent 快速检索的”大脑外挂”。

但问题来了：知识库一旦建好，谁来维护它？

答案是：再来一套多 Agent 工作流，让 AI 帮你维护 AI 的知识库。

二、整体思路：看板 + 多 Agent 协作

2.1 Hermes 看板是什么

Hermes 的 Kanban Board（看板）是一个可视化的任务调度中心。每张卡片代表一个待执行的任务，Agent 从看板上认领任务、执行、再把结果写回看板，驱动整条流水线向前推进。

这种机制天然适合多 Agent 协作：各 Agent 各司其职，通过共享看板传递信息，而不需要直接”对话”。共享看板是整套系统能够运转的基础设施。

2.2 设计核心：判断循环 + 人工审核

整套工作流有两个关键设计：

判断循环（Judgment Loop）：并非所有新信息都值得写入知识库。Orchestrator（编排器）会对每条信息打分，只有分数超过阈值的才会进入后续流程，避免知识库被垃圾信息稀释。

人工审核（Human Gate）：在执行写入操作前，系统会暂停并向人类发送一份”变更提案”，由人来判断是否执行。这一步防止了大量 Token 被花费在明显错误的任务上，也让整个系统保持可控。

三、Agent 角色分工

这套多 Agent 工作流由五类角色组成，分工明确、各有侧重。

Scout（侦察员）

持续监控外部信息源，侦测 Hermes Agent 的新动态。监控 GitHub 官方仓库的 Release，抓取官方文档更新，扫描 YouTube 视频字幕、社区帖子等非正式渠道。模型选择上，可使用 Grok 等具备实时搜索能力的模型，以便同步检索 X（Twitter）等社交平台上的最新讨论。

Scout 的核心价值在于广度——它的任务不是分析，而是尽可能全面地发现”发生了什么新鲜事”。

Orchestrator（编排器）

整条流水线的大脑，负责判断、路由和调度。接收 Scout 的情报，用评分标准判断是否值得处理。对通过筛选的信息进行路由：是新建页面、还是更新已有页面？是否存在冲突？并行启动 Researcher 的两条子任务。在人工审核后，规划具体的写入方案。最终执行 Git Commit，将变更提交到版本库。

Orchestrator 是整个系统中对模型能力要求最高的角色，推荐使用较强的通用模型（如 GPT 系列）。

Researcher（研究员）

以两个并行实例运行，分别负责：

• 验证实例：确认该信息在知识库中是否已存在，做好去重工作

• 定位实例：找出知识库中受此次更新影响的具体页面

两项任务全部完成后，Orchestrator 才会进入下一阶段。这种并行设计在保证质量的同时显著缩短了流程总耗时。

Ingestor（写入器）

将信息真正”消化”并写入知识库。写入不是简单地复制粘贴 Release Notes——Ingestor 的工作是：

• 阅读原始信息并理解其含义

• 提炼摘要、抽取核心概念与实体

• 按照 Wiki 的页面结构组织内容，确保新内容与已有体系无缝融合

• 根据任务类型，决定是新建页面还是在现有页面中追加或修改

当多个 Ingestor 实例并行运行时，系统会自动检测并发写入冲突——若两个实例试图同时编辑同一文件，后者会暂停等待前者提交完成后再继续，避免内容覆盖。

Linter（校验器）

在 Ingestor 提交内容之后启动，对整个知识库进行扫描。格式校验、链接存活检测、章节完整性检查，以及此次更新之后是否有内容已经变成过时信息——若有则主动标记或删除。

四、完整的工作流管道

将上述五类 Agent 串联起来，完整的流水线如下：

`[Scout 侦察]
 v 发现新信息
[Orchestrator 评分]
 v 分数 ≥ 阈值（否则丢弃）
[Researcher × 2 并行验证]
 +-- 验证去重
 +-- 定位受影响页面
 v 两条任务均完成
[Orchestrator 路由规划]
 +-- 新建页面
 +-- 更新已有页面
 +-- 判定冲突/忽略
 v 生成变更提案
[人工审核]
 +-- 批准 -> 继续
 +-- 搁置 -> 流程终止
 v
[Ingestor 写入知识库]
 v
[Linter 全量校验]
 v
[Orchestrator Git Commit]
 v 推送至主分支（再次确认）
[完成]`

每个阶段的状态变更都会实时反映在 Hermes 看板上，形成可视化的进度追踪。与此同时，系统会通过 Telegram 向人类发送关键节点的通知，即便你不在电脑前，也能随时掌握流水线的运行情况。

五、评分机制：什么样的信息值得写入？

Scout 采集到信息之后，Orchestrator 并不会无脑处理——它会用一套多维评分标准对信息打分：

• 新颖性：该信息是否与知识库现有内容存在实质性差异

• 相关性：是否涉及 Hermes Agent 的核心功能、配置或架构

• 可靠性：信息来源的权威程度（官方 > 社区 > 个人）

• 时效性：信息的发布时间及其对现有内容的影响程度

只有综合分数超过预设阈值（例如 80 分），Orchestrator 才会将任务推进到 Researcher 阶段。

这一机制在实际运行中展现出了不错的效果：测试时，系统成功识别出某个版本的更新实际上已经被手动写入了知识库，因此自动跳过了该任务——节省了一次不必要的 Token 消耗，也验证了去重机制的可靠性。

六、从模板开始：如何把它改造成 LLM Wiki 维护流水线

开源仓库地址：tonbistudio/hermes-multi-agent-workflow

这个模板预置了一个完整的工作示例（发现 AI Agent 用户痛点 -> 构建修复工具或制作解说视频），你要做的是把这套框架重新对准你的领域。好消息是：整个适配过程基本上不需要碰任何 Python 代码。

6.1 仓库结构一览

`triage.yaml <- 你的整个流水线定义，改这里
AGENTS.md <- 给 AI 编码助手的上手指南
engine/ <- 通用引擎，几乎不需要动
 config.py 加载并校验 triage.yaml
 engine.py TriageEngine，所有确定性逻辑
 scoring.py 评分（LLM 模式 + 确定性模式）
 routing.py 分类器 -> 路径映射
 dedup.py 去重（token-cosine，可升级到 embedding）
 item_vault.py 每个条目一个 Markdown 文件
 kanban_store.py 写入 Hermes 看板
paths/ <- 每条路径的模板文件（改这里）
 rails/ scope 边界（写什么、不写什么）
 specs/ 交付物规格
 proposals/ 人工审核的提案格式
skills/templates/ <- Scout + Orchestrator 的 SKILL.md 模板（改这里）
cli/triage.py validate / scaffold / init / install
scripts/cost_report.py 每个条目的 Token 开销报告`

核心设计原则：引擎通用，领域在配置。 engine/ 是业务无关的，你的 LLM Wiki 逻辑一行都不应该写进 .py 文件——全部放进 triage.yaml 和它指向的 Markdown 模板里。

6.2 四条命令，先跑起来

`pip install -r requirements.txt # 只需要 PyYAML
python -m cli.triage validate # 校验配置是否合法
python -m unittest discover -s tests # 跑 12 个通用测试
python -m cli.triage scaffold # 打印 Hermes 环境搭建计划`

validate 和测试通过后，再按 scaffold 输出的计划去创建 Hermes profiles、绑定看板、注册 cron job，最后上线。

6.3 改造 triage.yaml：为 LLM Wiki 重新定义流水线

整个适配的核心就是编辑这一个文件。以下是针对 LLM Wiki 维护场景的关键改动思路。

重命名 pipeline 并绑定专属看板

`name: llm-wiki-maintenance
board: wiki-kb # 与其他工作看板隔离，避免任务混淆
workspace_root: ./work
cost_gate_usd: 2 # 超出预算则暂停并通知，避免意外消耗`

定义 Scout 信息源

sources 里每一项都是一个挂在 cron 上的 Scout。模板原版用的是 X 和 Web 搜索，改造为 Wiki 场景后：

`sources:
 - id: github
 profile: scout-github # 绑定到有 GitHub 访问权限的 Hermes profile
 skill: triage-scout-github
 schedule: "0 9 * * *" # 每天上午 9 点执行
 query: |
 检索 NousResearch/hermes-agent 的最新 Release、Changelog 和 Issue，
 找出有实质性功能变更或 API 变更的条目，附上链接和一句话摘要。
 跳过仅修复 typo 的补丁。

 - id: youtube
 profile: scout-youtube
 skill: triage-scout-web
 schedule: "0 10 * * *"
 query: |
 搜索近一周发布的关于 Hermes Agent 的 YouTube 视频字幕或文章，
 找出包含新用法、新集成方案或官方未收录技巧的内容。`

注意：Scout profile 必须在 Hermes 中启用 kanban 工具集，否则 Scout 写完报告却无法往看板上创建 intake 任务，会静默失败——这是实际踩过的一个坑。

定义条目结构（item_schema）

这决定了 Scout 产出每条候选信息时需要填写哪些字段，也是后续评分和路由的依据：

`item_schema:
 fields:
 - title
 - claim # 一句话说明：这条信息的核心是什么
 - sources # 来源链接
 - wiki_category # 归属哪个 Wiki 分类（如 memory、skills、config）
 - change_type # new_feature / behavior_change / deprecation / fix
 - affected_pages # 预估影响知识库的哪些页面`

设置评分标准（rubric）

引擎会让 LLM 对每个维度打分，总分超过阈值才进入研究阶段：

`rubric:
 threshold: 60 # 满分 100，60 分以上才推进
 dimensions:
 - {key: novelty, max: 30, hint: "与现有 Wiki 内容有实质差异的程度"}
 - {key: relevance, max: 25, hint: "是否涉及核心功能、配置或架构"}
 - {key: reliability, max: 25, hint: "来源权威性：官方 > 社区维护者 > 个人"}
 - {key: freshness, max: 20, hint: "信息发布时间及其改变现有结论的程度"}`

配置并行研究通道（research_lanes）

两条 lane 并行跑，都完成后 Orchestrator 才汇总路由：

`research_lanes:
 role: researcher
 lanes:
 - verify_in_kb # 在知识库中检索，确认是否已存在，做去重
 - find_affected_pages # 找出受影响的具体页面列表
 classifier_lane: find_affected_pages # 该 lane 的输出结果决定路由走向`

路由映射（route）

根据 find_affected_pages 的判断结果，把任务分配到不同路径：

`route:
 classifier: find_affected_pages.change_scope
 map:
 new_concept: ingest_new # 需要新建页面
 page_update: ingest_update # 更新已有页面
 minor_patch: shelve # 改动太小，不值得写入`

定义路径（paths）

这是人工审核门前后的具体执行步骤。以 ingest_update 为例：

`paths:
 ingest_update:
 prep:
 - {stage: plan_changes, role: researcher} # 列出受影响页面及改动计划
 propose:
 {role: orchestrator, template: paths/proposals/ingest.md}
 fulfill:
 - {stage: write_pages, role: ingestor} # 写入/更新 Wiki 页面
 - {stage: lint_kb, role: linter} # 全量校验知识库
 - {stage: commit_changes, role: orchestrator} # git commit + 通知人类
 workspace_subdir: wiki-updates
 scope_rails: paths/rails/wiki.md # 写什么、不写什么的边界说明

 ingest_new:
 prep:
 - {stage: plan_new_pages, role: researcher}
 propose:
 {role: orchestrator, template: paths/proposals/ingest.md}
 fulfill:
 - {stage: write_new_pages, role: ingestor}
 - {stage: lint_kb, role: linter}
 - {stage: commit_changes, role: orchestrator}
 workspace_subdir: wiki-new

 shelve:
 auto: true`

审核通知渠道（gate）

`gate:
 channel: telegram
 approve: [approve]
 shelve: [shelve]
 modify: [modify]`

这里有一个必须注意的细节：Telegram 把以 / 开头的消息识别为命令，因此回复时直接发 approve wiki-slug-2024，不要加 /，否则审核指令会被 Telegram 拦截而无法触达 Hermes。

6.4 同步修改 Markdown 模板

改完 triage.yaml 之后，还需要同步更新它指向的三类 Markdown 文件：

• paths/rails/wiki.md——Scope 边界，告诉 Ingestor 哪些内容可以写、哪些不能写，防止 LLM 越界操作知识库文件系统。

• paths/proposals/ingest.md——人工审核门的提案格式，决定你收到 Telegram 通知时看到的是什么内容。建议包含：变更原因、受影响页面列表、来源链接，让你能在 30 秒内做出 approve 或 shelve 的判断。

• skills/templates/ 下的 Scout 和 Orchestrator SKILL.md——这里的内容会被注入到对应 Agent 的系统提示词里，控制它们在执行任务时的具体行为边界。

6.5 验证并上线

`python -m cli.triage validate # 确保 triage.yaml 语法无误
python -m unittest discover -s tests # 通用引擎测试保持绿色
python -m cli.triage scaffold # 查看需要在 Hermes 中创建哪些 profiles`

按照 scaffold 输出的清单，在 Hermes 的 ~/.hermes/config.yaml 里为每个角色创建 profile、绑定模型和工具集，再把 Scout 的 cron 注册到 Gateway，整套系统就可以上线运行了。

七、实战效果观察与避坑指南

一次完整的端到端运行，有几个值得重点关注的细节。

去重机制有效：系统在处理 Hermes v15 的大版本更新时，发现知识库中已存在相关内容（尽管操作者本人已记不清曾手动写入过），自动跳过，避免了重复工作——LLM 的记性确实比人好。

并发写入保护：当两个 Ingestor 实例同时尝试写入同一页面时，系统自动暂停后到的实例，等待先到的实例完成提交后再继续，解决了并发写入冲突问题。这背后依赖的是引擎在 fulfill 阶段强制使用持久化 dir workspace 而非临时 scratch 目录——如果改成 scratch，任务之间的文件状态会被清空，交付阶段就无从找到之前写入的内容。

多模型协同无碍：各角色分别使用不同厂商、不同规格的模型（Scout 用 Grok 实时搜索，Researcher 用 Neotron Ultra，Ingestor 用 MiniMax M3），整条流水线运行顺畅，整次运行总成本约 0.95 美元。

写入质量可控：Ingestor 产出的不是 Release Notes 的机械复制，而是经过理解和提炼的结构化知识，可以直接用于后续的 Agent 检索。

接下来几个坑是 AGENTS.md 里专门列出的”从真实系统里调试出来的经验”，值得在动手之前认真看一遍。

Scout profile 必须开启 kanban 工具集。Scout 是通过 cron 触发运行的，不经过 Hermes 的 dispatcher，因此看板工具不会被自动加载。如果忘记手动启用，Scout 会正常完成搜索和报告写入，但静默失败于创建 intake 任务这一步——你盯着空看板找半天原因，日志里却什么报错也没有。

状态字段不等于通知。Orchestrator 是无头后台进程，仅仅把任务状态改成 done 不等于给你发了消息。需要在 skill 里显式调用 hermes send --to telegram 才能让通知真正到达你手上。

审核指令不加斜杠。Telegram 把 /approve 这类以斜杠开头的消息识别为命令而拦截，正确的回复格式是 approve wiki-slug，不带任何前缀。

审核后第一个任务状态必须是 ready。人工批准后触发的 fulfill 任务链，其第一个任务不能设置为阻塞父任务的 todo 状态，否则它会因为等待一个永远不会完成的前置条件而卡住。

八、扩展方向

当前的实现是一个稳固的起点，还有不少值得探索的方向。

• 拓宽信息源：接入 微信公众号、知乎、X（Twitter）的实时搜索、Reddit 社区、Discord 频道等，覆盖更多非正式但高价值的信息

• 定时自动触发：配置 Cron Job，让 Scout 每天或每周自动运行，真正实现无人值守的知识库维护

• 覆盖更多领域：这套工作流的框架是通用的，只需替换信息源和评分标准，就可以为任何快速迭代的技术领域构建类似的自维护知识库

• Linter 增强：在格式和链接校验之外，加入语义一致性检查，确保不同页面对同一概念的描述保持统一

九、总结

这套多 Agent 工作流的本质是一条自动化的知识工程流水线：Scout 负责发现，Orchestrator 负责判断，Researcher 负责验证，Ingestor 负责写入，Linter 负责校验，而贯穿全程的人工审核则确保了系统始终在人类的掌控之内。

它解决的核心问题是：如何让一个知识库在无需大量人力投入的前提下，保持长期的准确性和新鲜度。

对于任何正在维护大型技术知识库、或者需要在复杂多变的信息环境中持续作业的团队来说，这套框架都有直接的参考价值。最重要的是，它已经过实际运行的验证——不是一个概念，而是一个可以今天就开始使用的工具。

Github开源项目：tonbistudio/hermes-multi-agent-workflow

适配入口是 triage.yaml，把它给你的 AI 编码助手，让它读完 AGENTS.md 再动手，通常十几分钟就能跑通一个新领域的流水线。

---

💬 本文评论区已开启，但暂无读者留言。

本文转载自微信公众号，如有侵权请联系删除。