通过 Profile 运行多个独立的 Hermes Agent每个 Agent 有独立的配置、会话、技能和记忆。2.1 什么是 ProfileProfile 是一个独立的 Hermes home 目录。其中包含各自的 config.yaml、.env、SOUL.md、记忆、会话、技能、cron 任务、状态数据库和 Gateway 状态。通过 Profile 可以运行用于不同用途的 Agent 而不会混淆 Hermes 状态。创建 Profile 后Hermes 会自动生成同名命令别名。例如创建 coder 后可以直接使用 coder chat、coder setup、coder gateway start本质上等价于 hermes -p coder …。2.2 创建 Profile【重要操作实用】hermes profile create coder # 创建空白 Profile内置技能会初始化hermes profile create coder --description “负责阅读源码、实现已明确的代码修改、修复测试或构建问题、运行必要验证并在完成后汇报改动、测试结果和剩余风险”hermes profile create coder --clone # 克隆当前 Profile 的 config.yaml、.env、SOUL.mdhermes profile create backup --clone-all # 克隆完整状态hermes profile create coder --clone --clone-from backup # 从指定 Profile 克隆hermes profile describe coder --text “…” # 为 Profile 添加描述hermes profile describe coder --auto # 用辅助模型自动生成描述hermes profile delete coder # 删除 Profile2.3 使用 Profilecoder chat # 启动 coder profile 的交互式对话coder setup # 运行 coder profile 的配置向导coder gateway start # 启动 coder profile 的 Gateway 服务coder doctor # 检查 coder profile 的健康状态coder skills list # 查看已安装的 skillscoder config set model.default anthropic/claude-sonnet-4 # 修改默认模型别名本质上等价于 hermes -p 。也可以显式指定hermes -p coder chat。设置默认 Profilehermes profile use coder # 默认使用 coder Profilehermes profile use default # 恢复为 default2.4 工作原理Profile 使用 HERMES_HOME 环境变量。运行 coder chat 时包装脚本会在启动 Hermes 前设置 HERMES_HOME~/.hermes/profiles/coder。每个 Profile 都可以作为独立进程运行自己的 Gateway拥有自己的 bot token。Delegation 任务委派【重要原理须知】官方文档https://hermes-agent.nousresearch.com/docs/user-guide/features/delegationHermes 可以创建子 Agent 来处理独立的任务。子 Agent 有自己的对话和终端环境互不干扰。3.1 单任务与并行批量单任务delegate_task(goal“Debug why tests fail”,context“Error: assertion in test_foo.py line 42”,toolsets[“terminal”, “file”],)并行批量默认最多 3 并发可通过 max_concurrent_children 调高delegate_task(tasks[{“goal”: “Research topic A”, “toolsets”: [“web”]},{“goal”: “Research topic B”, “toolsets”: [“web”]},{“goal”: “Fix the build”, “toolsets”: [“terminal”, “file”]},])超过 max_concurrent_children 的批量请求会直接返回工具错误。结果按输入顺序排列。父 Agent 中断会传播到所有活跃子 Agent。3.2 子 Agent 上下文子 Agent 启动时拥有全新对话不知道父会话之前的任何内容。唯一上下文来自接收的 goal 和 context 两个字段goal任务目标必填context完成目标所需的全部背景信息子 Agent 完成后只有结构化摘要回传到父会话详细对话过程不保留以此控制 token 开销。3.3 工具集限制toolsets 适用场景[“terminal”, “file”] 编码、调试、文件编辑[“web”] 调研、查文档[“terminal”, “file”, “web”] 全栈任务默认某些工具限制为子 Agent 无法使用工具 原因delegation 叶子节点禁止再次委派orchestrator 保留clarify 子 Agent 不能与用户交互memory 不写入共享持久记忆code_execution 子 Agent 应逐步推理send_message 无跨平台副作用3.4 嵌套委派与配置【推荐操作实用】默认委派是扁平的父 Agent深度 0→ 子 Agent深度 1不可再委派。如需多阶段工作流需要如下配置配置项 作用role leaf 是叶子节点orchestrator 申请保留委派能力max_spawn_depth 全局最大委派深度1 表示只允许一层叶子 Agentorchestrator_enabled 嵌套委派总开关~/.hermes/config.yamldelegation:max_concurrent_children: 3 # 全局并发任务上限max_async children: 3 # 异步IO型任务单独上限max_spawn_depth: 1orchestrator_enabled: true配置交互关系配置组合 结果role“leaf”任意 max_spawn_depth 子 Agent 是叶子节点不能继续委派role“orchestrator”max_spawn_depth: 1 仍不能继续委派role“orchestrator”max_spawn_depth: 2 可以再委派一层叶子 Agentorchestrator_enabled: false 全局禁用嵌套委派4. Kanban 多 Agent 协作官方文档https://hermes-agent.nousresearch.com/docs/user-guide/features/kanban架构 PDFhttps://github.com/NousResearch/hermes-agent/blob/main/docs/hermes-kanban-v1-spec.pdfHermes Kanban 是一个多 Agent 协作层一个可恢复、可审计、可中途介入的工作队列。它把任务、依赖、评论、运行记录和工作目录放进一个持久任务板里让多个具名 profile 以异步方式协作。4.1 从 delegate_task 到 Kanbandelegate_task 适合短的、自包含的推理子任务但无法覆盖研究分流与综合多个专家型 Agent 并行产出候选发现一个或多个审查者选择、合并定时循环工作流日报、周报、小时级收件箱分流等会跨运行积累知识数字分身 / 持久助手具名、长期存在的 Agent 身份在数周或数月里积累记忆端到端工程流水线拆解、并行实现、审查、迭代、提交Kanban 的目标就是补上这些能力提供跨运行持久状态、工作可见性、不同技能 Agent 之间的交接、人类或对等 Agent 随时介入。4.2 架构【重要原理须知】三层架构hermes_kanban_architectureControl Plane控制层CLI、Gateway、Dashboard — 用户交互入口State Plane状态层SQLite board dispatcher — 唯一事实来源决定哪些任务可运行Execution Plane执行层独立 profile worker 进程每个都有隔离状态所有协调都通过任务板流转profile 之间没有直接的进程间通信。4.3 核心概念Board任务板Board 是一个独立的任务队列拥有自己的 SQLite 数据库、workspaces 目录和调度循环。默认 board 数据库位于 ~/.hermes/kanban.db。非默认 board 位于 ~/.hermes/kanban/boards//。Task任务Task 是 Kanban 的基本工作单元。一个 task 只有一个 assignee通常是 Hermes profile 名称。Task 状态状态 说明triage 待分流 / 待明确todo 已创建但尚未满足运行条件scheduled 已暂缓调度等待恢复ready 可以被 dispatcher 认领running worker 正在执行blocked 需要人工输入或等待外部条件review 等待审查done 已完成archived 已归档Task 生命周期状态流转┌──────────────┐ │ triage │ ← 粗略想法 / 高层目标 └──────┬───────┘ │ specify / decompose自动或手动 ▼ ┌──────────────┐ ┌────│ todo │ ← 已创建等待依赖满足 │ └──────┬───────┘ │ │ 所有父任务 done/archived │ ▼ │ ┌──────────────┐ │ │ ready │ ← 可以被 dispatcher 认领 │ └──────┬───────┘ │ │ dispatcher atomic claim │ ▼ │ ┌──────────────┐ │ │ running │ ← worker 进程中执行 │ └──┬───┬───┬───┘ │ │ │ │ │ │ │ └──────────┐ │ │ │ │ │ ▼ ▼ ▼ │ ┌────────┐ ┌────────┐ ┌──────────┐ │ │ done │ │blocked │ │ crashed/ │ ← 自动恢复或超过重试上限 │ └────────┘ └───┬────┘ │ timed_out│ 进入 blocked │ ▲ │ └─────┬─────┘ │ │ unblock人工/自动化 │ │ │ │ ┌────────┘ │ │ ▼ ▼ │ │ ┌──────────────┐ │ └───│ ready │ ← 重新进入调度队列 │ └──────────────┘ │ ▼ ┌──────────────┐ │ archived │ ← 归档不再参与调度 └──────────────┘关键点triage 是入口态经过 decompose 拆解后变成 todo 子任务原始 triage 变成 root tasktodo → ready 由 dispatcher 在每次 tick 中自动推进检查依赖是否满足ready → running 通过 SQLite 原子 CAS 更新完成保证并发安全running 结束后进入 done正常完成或 blocked需要人工介入blocked 经 unblock 后回到 ready重新进入调度队列崩溃/超时任务由 dispatcher 的 stale recovery 自动回收关键字段包括 title、body、assignee、priority、workspace_kind、workspace_path、claim_lock、consecutive_failures、max_retries 等。Link任务依赖Link 是 task 之间的父子依赖parent_id - child_id。父任务完成之前子任务保持在 todo所有父任务完成done/archived后dispatcher 推进子任务到 ready。支持 fan-out 和 fan-in。Comment评论 / 交接记录Comment 是人类和 Agent 在 task 上追加的持久消息也是 Kanban 的跨 Agent 交接协议。Worker 启动时会读取完整评论串。人类可通过评论补充要求Agent 可留下中间发现或交接说明。Event任务事件Event 是 Kanban 的审计日志记录 task 生命周期里的状态变化、人工编辑和 worker 执行遥测。常见事件生命周期created、promoted、claimed、completed、blocked、unblocked、archived人工编辑assigned、edited、reprioritized、status遥测spawned、heartbeat、reclaimed、crashed、timed_out、stale、gave_upWorkspace工作目录Task 绑定的工作目录worker 执行时所在位置。scratch默认模式为 task 创建新的临时工作目录dir:使用已有绝对路径worktree为代码任务创建 git worktree4.4 协作模式Kanban 可衍生出 6 种可重用协作模式模式 说明 典型场景Fan-out扇出 一个目标拆成多个同级 task并行执行 多角度研究、并行实现Pipeline流水线 上游完成 → 下游启动阶段式传递 researcher → analyst → writer → reviewerFan-in扇入 多个 task 汇总到一个聚合 task 研究综合、方案评审Long-running journal 同一 profile 通过定时任务在共享 workspace 反复处理 日报、周报、监控巡检Human-in-the-loop worker 阻塞 → 人工评论 → unblock → 重新启动 不确定决策、需要审批Fleet farming 一个 profile 管理 N 个对象每个对象独立 workspace 多账号管理、多服务器巡检4.5 Dispatcher 调度器Dispatcher 是一个长期循环默认运行在 Gateway 内部。每 N 秒默认 60 秒扫描 board执行四类动作stale recovery处理异常的 running 任务认领过期、进程退出、超时recompute ready推进依赖满足的任务到 readyatomic claim通过比较并交换式 SQL 更新认领任务启动 worker认领成功后启动 assignee 对应的 profile worker核心并发语义UPDATE tasksSET status ‘running’,claim_lock ?,claim_expires ?WHERE id ?AND status ‘ready’AND claim_lock IS NULL;更新命中 1 行 认领成功命中 0 行 已被其他调度器认领。失败与恢复连续失败超过重试上限后任务自动进入 blocked等待人类介入。4.6 案例展示安装目录中config.yaml修改kanban的配置delegation: