企业官网建设流程全解析

如何用 Hermes Agent 的 Kanban 多智能体看板跨 Profile 协作执行任务

【免费下载链接】hermes-agentThe agent that grows with you项目地址: https://gitcode.com/GitHub_Trending/he/hermes-agent

当你希望同机器上的多个 Hermes Agent（不同角色、不同 profile）共同完成一个任务链——例如先由 researcher 做调研、再由 writer 基于调研结果写摘要、最后由 reviewer 审核——Hermes Kanban 提供了这个协作面：一个持久的 SQLite 任务板，所有 profile 共享同一份数据（默认看板位于~/.hermes/kanban.db），每个任务是一行记录，每次交接也是一行记录，每个 worker 都是带独立身份的完整 OS 进程。完成本文后，你会建好角色 profile、创建一条跨 profile 的依赖任务链，并能在 CLI 和 dashboard 上核对每一环的执行与交接结果。

前提：为每个角色建 profile，并启动承载 dispatcher 的 gateway

Kanban 的协作单位是 profile。每个 profile 是独立的 Hermes 家目录（~/.hermes/profiles/<name>/），有各自的config.yaml、.env、记忆、sessions 和 skills；dispatcher 派发任务时会以HERMES_HOME指向对应 profile 启动 worker，因此各 worker 天然读取各自的配置与模型设置。

跨 profile 协作的第一步是把参与角色建出来，并在创建时用--description写明角色定位——后续分解/路由 worker 时会参考这些描述：

hermes profile create researcher --description "Reads source code and external docs, writes findings." hermes profile create writer --description "Drafts summaries and posts from research findings." hermes profile create reviewer --description "Reviews work products against acceptance criteria."

每个 profile 创建后会自动生成同名命令别名（如researcher setup），配置模型与 API 密钥的方式与普通 profile 相同。用下面命令核对参与协作的 profile 是否都在盘上：

hermes kanban assignees

该命令列出磁盘上的 profile 及每个 assignee 的任务数。注意：assignee 名字必须真实存在，dispatcher 对未知 profile 名会直接派发失败。

接下来一次性创建看板数据库并启动 gateway。dispatcher 默认运行在 gateway 进程内（kanban.dispatch_in_gateway: true），默认每 60 秒一个 tick 认领ready任务；gateway 不起，ready任务就会一直留在板上，hermes kanban create时也会给出警告：

hermes kanban init # 创建 kanban.db（首次任意 hermes kanban 子命令也会自动初始化） hermes gateway start # 启动 gateway，内嵌 dispatcher hermes dashboard # 打开 http://127.0.0.1:9119，左侧导航进入 Kanban 页

dashboard 是给你（人）观察和干预用的；被 dispatcher 启动的 worker 不看 dashboard、也不走 CLI，它通过专属的kanban_*工具集（kanban_show、kanban_heartbeat、kanban_complete、kanban_block、kanban_create、kanban_link等）直接操作看板数据库。

创建跨 Profile 的依赖任务链

跨 profile 协作的核心机制是assignee + parent 链接：--assignee决定哪个 profile 来执行，--parent建立依赖——子任务在todo等待，直到所有父任务done，dispatcher 才把它提升为ready。三个 profile 各占一环，调研完成前测试与写作不会被提前认领。

SCHEMA=$(hermes kanban create "Research: token-bucket rate limiter" \ --assignee researcher \ --json | jq -r .id) DRAFT=$(hermes kanban create "Write summary from research" \ --assignee writer \ --parent $SCHEMA \ --body "Base the draft strictly on the research findings; cite sources inline." \ --json | jq -r .id) hermes kanban create "Review the summary draft" \ --assignee reviewer \ --parent $DRAFT \ --body "Acceptance: claims traceable to research sources, no unsupported statements."

命令依赖jq解析--json输出里的任务 id。创建后hermes kanban list应显示：第一张卡在ready（无未完成父任务），后两张卡在todo等待依赖。

worker 侧的执行流程（以 researcher 为例）由注入 worker 系统提示的 kanban guidance 驱动，无需任何额外安装：

# worker 工具调用序列（发生在 agent 内部，不是你要执行的命令） kanban_show() # 读取标题、正文、父任务交接、历史尝试、评论 # （用 terminal/file 工具完成实际工作） kanban_heartbeat(note="halfway through") # 长操作期间保活 kanban_complete( summary="...", metadata={"changed_files": [...], "decisions": [...]}, )

两个协作关键点：

• 依赖提升是自动的：SCHEMA进入done后，DRAFT自动todo → ready，下一个 tick（默认 60 秒，或 dashboard 顶栏的Nudge dispatcher按钮立即触发一个 dispatch tick）由 writer profile 认领。
• 父任务的结构化交接随子任务上下文下发：writer 的 worker 调用kanban_show()时，返回的worker_context里带有## Parent task results小节，逐字包含 researcher 那次完成 run 的summary和metadata。下游 worker 因此不用重读长文档就知道上游做了什么、决策了什么。

最后一环由 reviewer 收尾：审核通过后调用kanban_complete(summary="review passed; acceptance criteria verified")，任务进入done。如果同一张卡要承载“实现 → 评审 → 修改 → 再审”的来回，使用一等评审生命周期：实现方调用kanban_request_review(summary=..., reviewer=...)使同一张卡进入review；评审方调用kanban_request_changes(reason=...)把卡退回实现方（不进入 block 计数）；再审通过后由kanban_complete收尾。文档明确：kanban_block留给真正的外部升级（缺权限、产品决策、基础设施不可用），正常评审意见不要用它。

验证结果与检查命令

以下命令都是你（人类）在终端查看看板的视角，worker 不使用它们：

hermes kanban list # 各任务当前状态 hermes kanban stats # 按状态 + 按 assignee 的计数 hermes kanban show <id> # 单任务详情 hermes kanban runs <id> # 每次尝试一行：outcome、profile、耗时、时间 hermes kanban tail <id> # 跟随单个任务的事件流 hermes kanban watch --kinds completed,gave_up,timed_out # 全板流式输出终态事件

文档中hermes kanban runs的示例输出（文档示例，非固定预期）：

# OUTCOME PROFILE ELAPSED STARTED 1 completed backend-dev 0s 2026-04-27 19:34 → users(id, email, pw_hash), sessions(id, user_id, jti, expires_at); refresh tokens ...

一次成功的跨 profile 链路，在runs/ dashboard 的 Run History 里应能对上：第一环outcome=completed、worker 为对应 profile，父任务的 summary/metadata 出现在子任务的交接上下文里，最后一环进入done。gateway 平台接好（Telegram / Discord / Slack 等）时，gave_up等终态事件还会通过网关通知推给你。

控制成本：Profile 级模型与按任务覆盖

Kanban 的 per-profile 配置让“规划用强模型、执行用便宜模型”成为默认结构：orchestrator/dispatcher profile 放 frontier 级模型，worker profile 指向便宜模型——worker 才是消耗 token 的大头。每个 profile 有自己的config.yaml（~/.hermes/profiles/<name>/），dispatcher 启动 worker 时注入 profile 级HERMES_HOME，各 worker 读各自模型设置。源文档给出的配置形态（其中的模型名是需要你替换的占位值，替换为你已配置的模型名）：

# ~/.hermes/config.yaml（orchestrator / dispatcher profile） model: default: "your-frontier-model" # ~/.hermes/profiles/coder/config.yaml（worker profile） model: default: "your-inexpensive-model"

个别质量敏感的卡单独钉回强模型，用按任务覆盖即可，无需改 profile：

# 创建时 hermes kanban create "hard refactor" --assignee coder \ --model claude-opus-4.6 --provider anthropic # 或之后修改——下一次派发生效 hermes kanban set-model t_abcd claude-opus-4.6 --provider anthropic hermes kanban set-model t_abcd none # 清除覆盖，回到 profile 默认

注意--provider必须与--model同时提供。

失败处理：熔断、崩溃回收与人工介入

spawn 熔断：worker 起不来时（profile 环境缺凭证、PATH 缺失、workspace 无法挂载等），dispatcher 释放 claim、递增失败计数，下个 tick 重试。连续失败达到上限后任务自动blocked（outcome 为gave_up），不再重试直到人工 unblock。上限按此顺序解析：任务的--max-retries→config.yaml的kanban.failure_limit→ 内置默认 2。文档示例（文档示例）：一个缺少AWS_ACCESS_KEY_ID的部署任务：

hermes kanban create "Deploy to staging (missing creds)" \ --assignee deploy-bot --tenant ops \ --max-retries 3 hermes kanban runs t_ef5d # # OUTCOME PROFILE ELAPSED STARTED # 1 spawn_failed deploy-bot 0s 2026-04-27 19:34 # ! AWS_ACCESS_KEY_ID not set in deploy-bot env # 2 spawn_failed deploy-bot 0s 2026-04-27 19:34 # ! AWS_ACCESS_KEY_ID not set in deploy-bot env # 3 gave_up deploy-bot 0s 2026-04-27 19:34 # ! AWS_ACCESS_KEY_ID not set in deploy-bot env

修复 profile 环境后hermes kanban unblock t_ef5d即可重新进入派发。unblock 会把任务恢复到来源阶段：父任务全部完成时为ready（评审来源为review），仍有父任务未结时为todo；unblock不会直接路由到triage。另外注意一个保护机制：同一原因 blocked → unblock → 再 blocked 达到BLOCK_RECURRENCE_LIMIT次（默认 2），任务会被路由到triage交给人决定，而不是继续循环 unblock——出现这种情况时先解决反复 block 的根因（父任务未完成、缺输入、能力不满足）。

崩溃回收：spawn 成功但 worker 进程中途死亡（segfault、OOM、systemctl stop）时，dispatcher 轮询kill(pid, 0)检测到死进程，释放 claim、任务回到ready，下个 tick 交给新 worker。教程中的示例：一个迁移任务在扫到约 230 万行时被 OOM 杀掉（run 1 outcome 为crashed），重试 worker 在自己的上下文中看到了 run 1 的失败原因，改用分块策略成功（run 2 outcome 为completed）。

人工介入：worker 需要人决策时走kanban_block（带needs_input/capability/transient类型），你看板上（或从聊天平台/kanban unblock <id>）处理；给任务补上下文用hermes kanban comment <id> "..."，该任务下一次运行时会在kanban_show()读到这条评论。/kanban斜杠命令显式豁免运行中 agent 的排队守卫——即使有 agent 正在思考，list/show/comment/unblock等读写也立即生效，因为看板状态在 SQLite 里而不是运行中 agent 的状态里。

边界与限制

• 单主机：看板是单主机设计，~/.hermes/kanban.db是本地 SQLite，dispatcher 在同机启动 worker；跨两台主机共享一个看板不受支持。多主机场景按文档建议：每台主机跑独立看板，用delegate_task/消息队列桥接。
• 派发节奏：默认 60 秒一个 tick，任务创建后最长等待一个 tick；用 dashboard 的Nudge dispatcher或hermes kanban dispatch手动触发。
• stale 回收：任务运行超过kanban.dispatch_stale_timeout_seconds（默认 4 小时）且最近一小时无kanban_heartbeat，dispatcher 会 SIGTERM 本地 worker 并把任务重置回ready重新派发（不记失败计数）。长操作 worker 应至少每小时调一次kanban_heartbeat。
• scratch workspace 是临时的：默认 workspace 在任务完成时被删除；只有经kanban_complete(artifacts=[...])声明的产物文件会被拷贝到持久附件存储。需要整个目录保留时用dir:<绝对路径>或worktree:workspace（dir:相对路径会在派发时被拒绝）。
• dashboard 安全：dashboard 默认绑定 localhost，但插件路由不经过认证中间件；若你执行hermes dashboard --host 0.0.0.0，看板包含的任务正文、评论与 workspace 路径将对网络可达——共享主机上不要这样做。
• 后续工作：对已完成卡片，规范做法是创建以该 done 卡为--parent的新子卡（父卡已完成，子卡直接进ready，且上下文自带父卡的交接），而不是重开 done 卡；完成后的卡片是不可变历史，其上下文经由 parent 链接向前流动。

【免费下载链接】hermes-agentThe agent that grows with you项目地址: https://gitcode.com/GitHub_Trending/he/hermes-agent