Hermes Architecture · Multi-Agent System

多 Agent 协同方案
负载均衡批量执行 Skill

通过 Kanban 调度层 + Worker 进程池,实现 N 任务 → 多 Agent 并行执行,单一 Skill 能力全量共享
Scroll
01 / 09
01 · 问题背景

700+ 任务
29 小时 → 30 分钟

700+
政策采集任务总量
29h
单 Agent 串行执行
15
可并行 Worker 上限
30m
多 Agent 并行目标

任务串行瓶颈

单 Agent 处理 700+ 任务耗时 29 小时,无法接受。需要多 Agent 并行执行。

Skill 能力一致性

多 Agent 并行执行同一 Skill,如何确保各 Agent 拥有完全相同的 Skill 能力?

调度与负载均衡

任务数量远大于单 Agent 处理上限,需要有效的任务分发机制。

02 / 09
02 · 架构概览

整体架构

用户 / 编排者 Agent
  分析任务 → 创建任务队列 → 监控进度
            ↓ 创建 N 个任务
┌─────────────────────────────────────────────────────────────┐
│                    Kanban 调度层                             │
│  dispatch_interval_seconds: 5s     max_spawn: 15           │
│  Ready ──→ 调度器按 max_spawn 上限 Spawn Worker            │
│  Running ─→ 跟踪正在执行的任务                               │
│  Done ────→ 标记完成                                        │
│  Blocked ─→ 等待人工介入                                     │
└────────────────────────────┬────────────────────────────────┘
                             │ spawn_nowait()
                             ↓
  ┌──────── Worker 1 ────────┐  ┌──────── Worker 2 ────────┐
  │ hermes -p collector_a  │  │ hermes -p collector_b  │
  │ 加载 Skill:            │  │ 加载 Skill:            │
  │ policy-batch-collector │  │ policy-batch-collector │
  │ kanban_read_task()     │  │ kanban_read_task()     │
  │ → 执行采集逻辑          │  │ → 执行采集逻辑          │
  │ kanban_complete()      │  │ kanban_complete()      │
  └────────────────────────┘  └────────────────────────┘
                   ↓
         ┌─────────────────────────┐
         │     共享结果存储          │
         │ ~/七大政策/{城市}/...    │
         └─────────────────────────┘

任务队列化

所有批量任务进入 Kanban 队列,调度器统一分发。

Worker 池化

固定数量 Worker 进程,任务完成后立即接新任务,减少空窗期。

Skill 中心化

Skill 实体存于一处,所有 Profile 通过符号链接共享。

03 / 09
03 · Kanban 调度器

核心参数

参数推荐值
dispatch_interval_seconds5s 近乎无空窗
max_spawn15 并发上限
dispatch_in_gatewaytrue 内嵌 Gateway
failure_limit5 次后 Block
# dispatch_once()
ready = db.select(
  "status='ready'")
for row in ready:
  if spawned >= max_spawn:
    break
  claim_task(conn,row.id)
  spawn_nowait(
    "hermes -p <profile>
     kanban task <id>")
  spawned += 1

Worker 生命周期

Ready
claim_task()
spawn_nowait()
Worker 启动
执行 Skill
complete()
进程退出
下次 tick 补位
↓ kanban_read_task() → skill_view() → 执行逻辑
04 / 09
04 · Hermes Profile

Worker 身份设计

Profile = 独立配置单元。Worker 进程由 Profile 驱动,每个 Worker 拥有独立配置、独立 Skill 链接、独立 API Key。
A

collector_a

独立 ~/.hermes/profiles/collector_a/
独立 SOUL.md + Skill 链接
独立 API Key 配置

B

collector_b

独立 ~/.hermes/profiles/collector_b/
独立 SOUL.md + Skill 链接
独立 API Key 配置

C

collector_c

独立 ~/.hermes/profiles/collector_c/
独立 SOUL.md + Skill 链接
独立 API Key 配置

Worker Spawn 方式

subprocess.Popen("hermes -p <profile> chat -q work kanban task <id>")
每个 Worker 是独立 OS 进程,启动后自行读取任务、执行 Skill、标记完成。

05 / 09
05 · Skill 一致性保障

三套方案对比

方案 1

手动同步

每个 Profile 目录单独维护 Skill 副本。更新时需逐个复制。

不推荐 版本漂移风险高
方案 2

符号链接(推荐)

Skill 实体存于 ~/.hermes/skills/,各 Profile 通过 ln -s 引用。

推荐 更新一次全量生效
方案 3

共享 Skills 目录

所有 Profile 的 skills/ 配置指向同一根目录,通过 hermes skills link 关联。

备选 需配置 skills.root_path
~/.hermes/
  skills/                              ← Skill 单一来源(实体)
    policy-batch-collector/
    kanban-batch-collection/
  profiles/
    collector_a/skills/  ──ln -s──→ ../../skills/
    collector_b/skills/  ──ln -s──→ ../../skills/
    collector_c/skills/  ──ln -s──→ ../../skills/
06 / 09
06 · 负载均衡

性能估算

700
任务总量
÷15
Worker 并行数
≈47
每 Worker 任务数

性能目标

700 任务 / 15 Worker = 每 Worker 处理约 47 任务。
单任务平均耗时 2.5 分钟 → 整体完成时间 ≈ 30 分钟

策略适用
轮询任务耗时相近时首选
最短队列任务耗时差异较大
加权各 Worker 硬件不一致
07 / 09
07 · 故障恢复

进程隔离 · 单点故障不影响整体

Worker 崩溃

进程异常退出 → 调度器 tick 发现 TTL 超期 → 任务自动重新入 Ready 队列

任务执行失败

连续失败 5 次(failure_limit)→ 标记 Blocked → 人工介入或自动重置

结果幂等性

写入前检查文件是否存在 → 已存在则跳过 → 可安全重跑,不影响已成功结果

故障恢复流程

Worker 启动
执行任务
成功 → complete()
Done
执行任务
失败 ×5
Blocked / 重新入队
08 / 09
09 · 总结

完整方案一览

  • 700+ 任务 29 小时 → 30 分钟完成
  • 最多 15 个 Worker 并行执行
  • Skill 更新一次,全量 Worker 生效
  • 进程隔离,单点故障不影响整体
  • 任务失败自动重试或重新入队
  • 结果幂等,可安全重跑
  • 调度器自主运行,无需人工干预
  • 全程可观测,任务状态透明
  • Hermes 多 Agent 协同方案 · 负载均衡批量执行 Skill 架构设计 · Hermes Agent System · 2026
    09 / 09