Hermes Agent Kanban系统新增kanban-orchestrator和kanban-worker组件解析

在开始之前，我先介绍一下Hermes Agent的双版本体系设计。为什么要介绍它呢？你如果是像我这样，基本上每天都要执行一次hermes update，你就会对Hermes的版本感到奇怪。比如Hermes v0.13.0版为啥连续多天升级后，还是v0.13.0版？

1 Hermes Agent双版本体系

Hermes Agent采用了双版本体系设计，结合 语义化版本（SemVer）和日期标签版本（CalVer） 两种策略，以实现版本管理的规范性与可追溯性。

# 查看Hermes Agent的版本

$ hermes --version

Hermes Agent v0.13.0 (2026.5.7)

Project: /home/tenbox/.hermes/hermes-agent

Python: 3.11.15

OpenAI SDK: 2.24.0

Up to date

1.1 双版本体系的主要构成

SemVer（语义化版本）：

示例：

0.13.0

含义：

正式发布的里程碑版本，遵循主版本号.次版本号.修订号规则。

更新方式：

仅在执行正式发布流程时通过release.py --publish命令手动更新。

作用：

标识重大功能变更、兼容性变化或缺陷修复，符合开源社区标准。

CalVer（日期标签版本）：

示例：

v2026.5.7

含义：

基于发布日期的标签版本，格式为vYYYY.MM.DD。

更新方式：

每次正式发布时由发布脚本自动创建Git标签。

作用：

精确记录发布时间点，便于快速关联代码提交与发布日期。

1.2 版本号的组合与显示

完整的版本号格式：SemVer (CalVer)，例如v0.13.0 (2026.5.7)。可以与前面执行hermes --version命令的输出印证。

该组合同时体现：

功能迭代阶段（SemVer）

发布时间戳（CalVer）

1.3 版本不变性原因解析

日常开发与版本关联：

hermes_cli/__init__.py

中的__version__硬编码为上一次正式发布的SemVer（如0.13.0）。

从最近标签（如v2026.5.7）到当前可能有大量提交（如646次），但这些属于开发中的中间状态，未触发正式发布。

结论：

仅执行git pull会同步最新开发代码，但不会自动更新版本号，需通过发布流程才更新__version__。

Hermes Agent的双版本体系通过SemVer与CalVer的互补，实现了 功能迭代（SemVer）与发布时间（CalVer）的解耦管理。开发阶段版本号保持不变，仅通过正式发布流程同步更新，既保证了版本控制的严谨性，又提供了清晰的时间维度追溯能力。该设计结合了规范性、灵活性与可审计性，为开源项目的版本管理提供了高效实践方案。

2 kanban-orchestrator（编排者）和kanban-worker（执行者）

我今天升级Hermes Agent，虽然版本仍然是0.13.0版，但是新增了kanban-orchestrator（编排者）和kanban-worker（执行者）两个组件。

Hermes Agent新发布的Kanban系统通过引入 kanban-orchestrator（编排者）和kanban-worker（执行者）两大核心组件，构建了一套高效的多智能体协作任务管理引擎。该系统通过任务分解、路由调度、并行执行和人机协作机制，实现了复杂目标的高效拆解与专业化分工执行。

3 Kanban Orchestrator（编排者）

角色定位：任务分解与路由调度中心。

核心职责：

任务分解：

将用户的复杂需求拆解为多个独立的工作流（如成本分析、性能对比、综合推荐等），并定义子任务间的依赖关系。

创建看板卡片：

为每个子任务生成标准化kanban_create任务卡，记录任务详情（如目标、依赖项、执行者profile）。

建立依赖关系：

通过parents=[...]参数明确任务的前置条件（如任务T3需等待T1和T2完成后才能启动），确保数据流正确传递。

智能体分配：

动态发现系统中可用的专业智能体（如researcher、implementer、reviewer等profile），并将任务卡路由至对应执行者。

规则约束（反诱惑法则）：

专注调度，不自行执行任务。

所有具体任务必须创建卡片并分配出去。

独立任务并行执行，依赖任务通过parents链接串联。

3.1 工作流程示例：

用户："研究 Postgres 迁移方案并写决策备忘录"

编排者分解为：

T1 researcher: 成本对比分析（并行）

T2 researcher: 性能对比分析（并行）

T3 analyst:   综合 T1+T2 输出推荐方案（依赖 T1,T2）

T4 writer:    编写 CTO 决策备忘录（依赖 T3）

4 Kanban Worker（执行者）

角色定位：专业任务的执行单元。

核心职责：

任务认领：

从看板中领取分配给自己的任务卡，按优先级执行。

执行工作：

在指定类型的workspace中完成实际任务（如编码、研究、审查等）：

scratch

临时目录（任务完成后清理）。

dir:<path>

共享持久化目录，支持后续任务读取。

worktree

Git工作树，支持版本控制提交。

进度汇报：

通过周期性心跳上报执行状态（如训练进度、测试结果等）。

任务完成/阻塞：

完成：

调用kanban_complete提交结果，包含结构化summary和metadata（如修改的文件列表、测试结果、审查问题等）。

阻塞：

通过kanban_block暂停任务并说明原因（如等待人工决策），触发人机协作干预。

结果交付标准化：

通过元数据记录关键执行信息，支持后续任务或审计追踪。

4.1 完成时的元数据格式示例

# 编码任务

kanban_complete(

  summary="实现了速率限制器 — token bucket 算法，14 个测试通过",

  metadata={

      "changed_files":   ["rate_limiter.py", "tests/test_rate_limiter.py"],

      "tests_run": 14,

      "tests_passed": 14,

  },

)

# 审查任务

kanban_complete(

  summary="审查 PR#123；发现 2 个阻塞问题",

  metadata={

      "pr_number": 123,

      "findings": [...],

      "approved": False,

  },

)

5 Kanban系统协作流程与关键机制

任务生命周期管理：

用户请求 Orchestrator分解 创建看板卡片（待办） 依赖引擎解析 调度器按拓扑顺序派发（就绪/进行中） Worker执行 完成/阻塞 结果汇总。

并行化与依赖管理：

独立任务自动并行执行，提升吞吐量。

依赖任务通过parents链接按顺序执行，确保数据就绪。

人机协作（Block机制）：

Worker可主动暂停任务并请求人工介入（如代码审查、决策点）。

人工通过unblock注入反馈后，调度器恢复任务执行，实现灵活协作。

持久化与审计追踪：

所有任务状态持久化至SQLite数据库，系统崩溃后不丢失进度。

完整任务历史可追溯，支持问题排查与流程优化。

专业化分工：

不同profile智能体专注特定领域（研究、编码、审查等），最大化资源利用率。

6 系统优势

高效拆解复杂任务：

通过Orchestrator实现目标分解与智能路由。

弹性并行执行：

独立任务并行处理，依赖任务按序执行。

人机协同：

Worker可灵活触发人工干预，平衡自动化与专家决策。

可靠性保障：

持久化存储与审计追踪提升系统鲁棒性。

专业化协作：

多profile智能体各司其职，适配多样化任务需求。

7 小结

Hermes Agent的Kanban组件通过Orchestrator与Worker的协同，构建了一套自动化与人性化结合的任务管理引擎。其核心在于“分解-路由-执行-反馈”的闭环流程，结合依赖管理、持久化存储和专业化分工，使多智能体系统能够像人类团队一样高效协作，适用于复杂项目的自动化执行与敏捷管理。

不过要说清楚一点，Hermes Agent的Kanban组件太新了，还不够成熟，要用于生产环境，至少还要等待一段时间。