Hermes Agent 多 Agent 协作实战

一、背景

现在市面上的 AI Agent 工具很多，但大多数产品面向的是单 Agent 场景——一个模型，一段对话，完成一个任务。

对于规模稍大的任务，这个模式很快就会暴露问题。调研、写作、审核、发布这样的流程，如果全部塞给一个 Agent，它不仅要在不同角色之间反复切换，上下文也会越来越长，最终超出限制。更麻烦的是，一旦中途失败，整个会话就废了，没有恢复的手段。

Hermes Agent 提供了另一种思路。它的核心不是让一个 Agent 更强，而是让多个专职 Agent 通过一张持久化的任务板分工协作。每个 Agent 只做自己擅长的事，结果写回任务板，下游 Agent 读取后继续。这个模式接近软件工程里的流水线架构，而不是一个全能的助理。

本文基于 Hermes Agent v0.19.0，介绍多 Agent 协作的核心机制，并完整演示一个从环境配置到任务执行的实战案例。

二、多 Agent 系统的核心组件

理解 Hermes 的多 Agent 系统，需要先弄清楚四个概念的区别：Profile、Worker、Orchestrator、Dispatcher。

Profile 是角色模板，不是运行中的进程。它定义了一个 Agent 应该使用什么模型、拥有哪些工具权限、遵循什么行为准则。每个 Profile 对应 ~/.hermes/profiles/<名字>/ 目录下的一套独立配置，包括 config.yaml（模型和工具）、SOUL.md（人格和行为约束）、memories/（跨会话记忆）、skills/（技能库）。

Worker 是 Profile 被调度执行一个具体任务时产生的进程。同一个 Profile 可以先后执行多个任务，每次对应一个独立的 Worker 进程，完成后退出。

Orchestrator 是负责规划的角色，职责是将高层目标拆解成子任务图，建立任务之间的依赖关系，分配给对应的 Profile。它本身不执行具体工作，所以一般会禁用 terminal、file、web 等执行型工具，防止它越俎代庖。

Dispatcher 是调度循环，运行在 Gateway 进程内部，默认每 60 秒扫描一次任务板。它的工作很机械：检查哪些任务的上游依赖已经完成，把这些任务的状态从 todo 推进到 ready，然后通过 SQLite 原子更新认领任务，启动对应 Profile 的 Worker 进程。

所有协调通过任务板完成。Profile 之间没有直接通信，任务的状态、依赖关系、评论和工作目录是它们唯一的交接介质。

三、Kanban 任务板

Kanban 是这套系统的核心，默认数据库位于 ~/.hermes/kanban.db。

每个任务（Task）是数据库里的一行记录，包含标题、正文、负责人（assignee）、状态、工作目录类型和路径等字段。任务的状态按照以下顺序流转：

triage → todo → ready → running → done
                              ↓
                           blocked（等待人工介入）

triage 是入口状态，Orchestrator 会将其拆解成子任务图，原始任务变成父节点。子任务之间通过 Link 记录父子依赖。父任务完成后，Dispatcher 自动将子任务推进到 ready。

任务的工作目录有三种模式：scratch（临时目录，任务完成后清理）、dir:<path>（指定已有目录）、worktree（为代码任务创建独立的 git worktree）。对于多个 Agent 并行修改同一代码仓库的场景，worktree 模式让每个 Worker 在独立分支上工作，避免工作目录互相干扰。

Comment 是跨 Agent 的主要交接介质。Worker 启动时会读取完整的评论串作为上下文，人类也可以通过评论给出额外指示。一个负责任的 Worker 完成任务时，应该在评论里留下结构化的交接信息，包括修改了哪些文件、接口约定是什么、后续注意事项有哪些，而不是只写"完成"。

四、安装与配置

Hermes 的安装命令：

# macOS / Linux / WSL2
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash

# Windows（PowerShell）
iex (irm https://hermes-agent.nousresearch.com/install.ps1)

安装器会自动处理 Python 3.11、Node.js 等依赖。安装完成后重载 shell，运行 hermes doctor 检查环境。

配置模型推荐使用 Nous Portal，OAuth 登录后可以直接访问 400 多个模型，不需要分别申请 API Key：

hermes setup --portal

也可以手动配置：

hermes model   # 交互式选择提供商和模型

对于多 Agent 系统，不同角色使用不同提供商和模型是常见做法——调研任务用便宜的模型，审核或综合任务用更强的模型。Hermes 目前支持 20 余个提供商，包括 Anthropic、OpenAI、DeepSeek、Fireworks AI、DeepInfra 等，可以用 hermes model 交互切换，无需改代码。

如果不希望 API Key 存放在明文的 .env 文件里，Hermes 支持直接从 Bitwarden 或 1Password 读取密钥：

# 在 config.yaml 中配置 1Password 引用
hermes config set secrets.op_vault "my-vault"
# 之后可以用 op://vault/item/field 格式引用密钥

五、实战：搭建内容生产流水线

下面演示一个完整的场景：用多个专职 Agent 自动完成技术文章的调研、撰写和审核。

创建 Profile

首先创建四个角色。

调研员（researcher），使用成本较低的模型，限制工具范围：

hermes profile create researcher \
  --description "负责查阅文档和网络资料，产出结构化研究结论。使用低成本模型。"

researcher config set model.default deepseek/deepseek-chat
researcher tools disable browser code_execution video_analyze

为调研员写一份 SOUL.md，约束输出格式：

cat > ~/.hermes/profiles/researcher/SOUL.md << 'EOF'
你是一名技术研究员。输出必须遵循以下结构：
1. 核心发现（一句话）
2. 关键信息点（条目列表）
3. 信息来源（URL 与简述）

保持客观，不加入主观评价。
EOF

撰稿员（writer），使用写作质量更高的模型：

hermes profile create writer \
  --description "负责将研究材料整理成完整的技术文章。使用高质量模型。"

writer config set model.default anthropic/claude-fable-5
writer skills install blogwatcher

审核员（reviewer），专注于发现问题：

hermes profile create reviewer \
  --description "负责审查文章的技术准确性、逻辑完整性与信息时效性。"

cat > ~/.hermes/profiles/reviewer/SOUL.md << 'EOF'
你是一名技术编辑。审核要覆盖以下维度：
- 技术准确性：代码示例是否正确，API 名称是否准确
- 逻辑完整性：论述是否有跳跃
- 信息时效性：版本号、日期是否过时
以 checklist 格式输出审核结果。
EOF

编排员（orchestrator），只负责规划，禁用所有执行工具：

hermes profile create orchestrator \
  --description "Kanban 编排者。负责拆解写作任务，创建子任务图，建立依赖关系。"

orchestrator tools disable terminal file web browser code_execution

Orchestrator 禁用执行工具这一点很重要。如果不做限制，模型往往会忍不住自己去执行，把规划和执行混在一起，失去多 Agent 并行的意义。

初始化任务板

hermes kanban init
hermes config set kanban.orchestrator_profile orchestrator
hermes config set kanban.auto_decompose true

auto_decompose 开启后，Dispatcher 会在每个调度周期自动将 triage 状态的任务交给 Orchestrator 进行拆解。

创建任务

hermes kanban create \
  "写一篇介绍 Hermes Agent Kanban 系统的深度文章" \
  --assignee orchestrator \
  --body "目标读者是有 Python 基础的开发者。需要覆盖架构设计、核心概念和实际使用场景，字数不少于 2000 字。"

启动 Dispatcher

hermes gateway start

Gateway 内置了 Dispatcher，启动后会在后台持续运行调度循环。

观察执行过程

打开 Web 管理面板：

hermes dashboard
# 浏览器访问 http://127.0.0.1:9119

面板的 Kanban 标签会实时展示任务状态。也可以通过命令行查看：

hermes kanban list
hermes kanban show <task_id>
hermes kanban runs <task_id>   # 查看运行历史与日志

每个 Worker 运行时都会生成对应的日志文件，可以实时跟踪它的每一步工具调用和输出。日志路径通过运行记录可以查到：

# 在运行记录里找到 log_path
hermes kanban runs <task_id>

# 实时跟踪某个 Worker 的执行过程
tail -f ~/.hermes/kanban/logs/<task_id>.log

Orchestrator 启动后，会将任务拆解为：

调研（researcher）
    ↓ 完成后自动解锁
撰写（writer）
    ↓ 完成后自动解锁
审核（reviewer）

三个阶段依次自动触发，不需要手动操作。

人工介入

如果审核员发现问题，它会将任务标记为 blocked。这时可以查看原因，添加说明，然后解锁让 Agent 继续：

hermes kanban show <task_id>
hermes kanban comment <task_id> "代码示例需要补充错误处理，并说明失败时的重试策略。"
hermes kanban unblock <task_id>

这是 Kanban 里"Human-in-the-loop"的标准流程。block 不是失败，而是 Agent 在不确定时主动停下来等待人的判断。

如果需要拒绝某个具体操作，可以用 /deny 命令并附上原因，Agent 会据此在下一步自行修正，而不是反复重试同样的动作。

关于命令审批，Hermes 的默认行为是智能审批：当 Agent 要执行被标记为风险的命令时，会先由一个独立的 LLM 审查者评估，而不是每次都弹窗打断你。也可以定义永久拒绝规则，对指定命令即使在 /yolo 模式下也保持拦截。

六、并行开发场景

对于工程类任务，Kanban 的 worktree 工作目录模式特别有用。

假设要同时开发后端 API 和前端页面，可以建立带依赖关系的任务图：

BACKEND=$(hermes kanban create "实现后端登录 API" \
  --assignee coder --workspace worktree --json | jq -r .id)

FRONTEND=$(hermes kanban create "实现前端登录页面" \
  --assignee coder --workspace worktree --json | jq -r .id)

TESTS=$(hermes kanban create "编写登录集成测试" \
  --assignee tester \
  --parent $BACKEND --parent $FRONTEND \
  --workspace worktree --json | jq -r .id)

hermes kanban create "合并分支、处理冲突、全量验证" \
  --assignee integrator \
  --parent $TESTS

Dispatcher 发现 backend 和 frontend 两个任务都处于 ready 状态，会同时启动两个 Worker，分别在 .worktrees/backend-<task_id>/ 和 .worktrees/frontend-<task_id>/ 下工作。两个进程使用各自的 git worktree，在独立分支上修改文件，互不影响。

tests 任务依赖前两者，只有当 backend 和 frontend 都变成 done，它才会被解锁。最后的 integrator 任务再等 tests 完成，负责将三个分支合并，处理可能的代码冲突。

需要注意的是，worktree 解决的是工作目录隔离的问题，不能消除最终合并时可能出现的代码冲突。如果两个 Worker 都修改了同一段代码，仍然需要 Integrator 手动处理。

七、Kanban Swarm

如果任务本身不复杂，不需要手动创建任务图，可以用 swarm 命令快速生成一个 fan-out 拓扑：

hermes kanban swarm "分析 Hermes Kanban 系统的设计思路" \
  --worker "researcher:调研 Dispatcher 调度机制" \
  --worker "researcher:调研 Workspace 隔离方案" \
  --worker "researcher:调研 Profile 和 Worker 的关系" \
  --verifier reviewer \
  --synthesizer writer

这会自动创建三个并行的调研任务，全部完成后 reviewer 对结果进行审核，最后 writer 综合输出。适合需要多角度调研后汇总的场景。

八、注意事项

在实际使用中，有几点值得留意。

第一，不同 Profile 的记忆是隔离的。在 default Profile 里保存的项目信息，researcher Profile 默认看不到。解决办法是把项目规范写入仓库根目录的 AGENTS.md 文件，Hermes 启动时会自动加载当前目录的上下文文件。

第二，Orchestrator 的工具权限要严格控制。实践中最常见的问题是 Orchestrator 没有被充分约束，导致它把调研和写作都自己做了，完全没有触发下游的 Worker。确认 Orchestrator Profile 已经禁用了所有执行型工具，是调试多 Agent 系统的第一步。

第三，任务卡住时不要慌。先用 hermes kanban runs <task_id> 查看运行历史，通常能找到明确的错误信息。如果是 Profile 名称配置错误，任务会停在 ready 状态而不被认领，hermes kanban diagnostics 会给出警告。Kanban 也支持通过 CLI 管理任务附件，方便追踪调试阶段的产出物。

第四，delegate_task 和 Kanban 是两套不同的机制，适合不同的场景。delegate_task 是同步调用，父 Agent 等待子 Agent 返回后才继续，没有持久化，没有恢复机制。Kanban 是异步任务队列，任务状态持久化在 SQLite，失败可以重试，人可以随时介入。一个 Kanban Worker 内部也可以调用 delegate_task 来处理局部的并行推理任务，两者并不互斥。后台委托的子 Agent 结果会通过检查账本（ownership ledger）持久化，即使主进程中途重启，结果也会在下次启动时恢复交付，不再静默丢失。

第五，单个 Gateway 支持按频道路由到不同 Profile。一个 bot token 可以将工作群的消息路由给 work Profile，将个人频道的消息路由给 personal Profile，两个 Profile 各有独立的配置、记忆和技能，互不干扰。对于需要在同一个 bot 里维护多个用途不同的 Agent 的团队来说很实用。

九、总结

Hermes Agent 的多 Agent 系统，本质上是用持久化任务板解决了单 Agent 在长流程任务中的几个核心痛点：上下文溢出、失败无法恢复、人无法在中途介入、执行过程不透明。

整套系统建立在 SQLite 数据库和普通 OS 进程之上，没有引入额外的复杂依赖。每个 Worker 是一个独立进程，崩溃不影响其他任务；每次状态变化都记录在 task_events 表里，出了问题可以追溯。Gateway 生成的最终响应会写入持久化的交付账本，进程崩溃后重启会自动补发；后台委托的子 Agent 结果也有同等保证，不会静默丢失。

如果你正在考虑构建跨天运行、需要人工审批节点或者多角色分工的自动化流程，Hermes Kanban 是一个值得认真研究的选项。会话历史也可以通过 hermes sessions export 导出为 Markdown、HTML 或 Hugging Face trace 格式，方便归档或复盘整个流水线的决策过程。

参考资料