看板编排器

编排器配置文件通过看板分配工作的分解手册与防诱惑规则。"不要自己动手做"的规则和基本生命周期会自动注入到每个看板工作者的系统提示词中；当你专门扮演编排器角色时，这份技能是更深入的工作手册。

技能元数据

来源	内置（默认安装）
路径	skills/devops/kanban-orchestrator
版本	3.0.0
平台	linux, macos, windows
标签	看板, 多智能体, 编排, 路由
相关技能	看板工作者

信息

以下是 Hermes 在触发此技能时加载的完整技能定义。这是智能体在技能激活时看到的指令。

看板编排器 — 分解手册

核心工作生命周期（包括 kanban_create 扇出模式和"分解，而非执行"规则）通过 KANBAN_GUIDANCE 系统提示块自动注入到每个看板流程中。当你的角色是编排器配置文件，其全部职责是路由时，此技能是更深层的手册。

配置文件由用户配置 — 不是固定的名单

Hermes 的设置差异很大。有些用户运行单个配置文件来完成所有工作；有些运行一个小型舰队（docker-worker、cron-worker）；有些运行他们自己命名的精选专家团队。没有默认的专家名单 — 编排器技能不知道此机器上存在哪些配置文件。

在扇出之前，你必须基于实际存在的配置文件来制定分解计划。调度器在生成未知的受派者名称时会静默失败 — 它不会自动纠正、不会建议、不会回退。因此，在只有 docker-worker 的设置中分配给 researcher 的卡片将永远停留在 ready 状态。

步骤 0：在规划之前发现可用的配置文件。

使用以下方法之一：

• hermes profile list — 打印此机器上配置的配置文件表格。如果有终端工具，通过终端工具运行；否则询问用户。
• kanban_list(assignee="<某个名称>") — 对单个名称进行健全性检查。对未知的受派者返回空列表（而非错误），因此这只用于确认你已经在考虑的名称。
• 直接询问用户。 "你设置了哪些配置文件？" 是一个很好的第一个回合，当目标需要不止一个专家时。

将结果缓存在你的工作记忆中，用于剩余的对话。每个回合都重复询问会浪费一次工具调用。

何时使用看板（vs. 直接执行工作）

当以下任一条件为真时创建看板任务：

1. 需要多个专家。 研究 + 分析 + 写作涉及三个配置文件。
2. 工作应在崩溃或重启后保留。 长期运行、重复性或重要任务。
3. 用户可能想要介入。 在任何步骤中实现人在回路。
4. 多个子任务可以并行运行。 扇出以提升速度。
5. 预计需要审查/迭代。 审查者配置文件对起草者输出进行循环审查。
6. 审计跟踪很重要。 看板行永久保存在 SQLite 中。

如果以上条件均不适用 — 这是一个小型一次性推理任务 — 请改用 delegate_task 或直接回答用户。

反诱惑规则

你的工作描述是"路由，而非执行"。强制执行这些规则：

• 不要自己执行工作。 你的受限工具集通常甚至不包括用于实现的终端/文件/代码/网络。如果你发现自己在"只是快速修复一下" — 停下来，为合适的专家创建一个任务。
• 对于任何具体任务，创建看板任务并分配。 每次都是如此。
• 在创建卡片之前拆分多通道请求。 一个用户提示可能包含多个独立的工作流。首先提取这些通道，然后为每个通道创建一张卡片，而不是将不相关的工作捆绑到单个执行者卡片中。
• 并行运行独立通道。 如果两张卡片不需要彼此的输出，则保持它们无链接，以便调度器可以将它们扇出。仅链接真正的数据依赖关系。
• 永远不要将有依赖关系的工作创建为独立的就绪卡片。 如果一张卡片必须等待另一张卡片，请在原始 kanban_create 调用中传递 parents=[...]。不要先创建再链接，也不要依赖正文中像"等待 T1"这样的描述。
• 如果没有专家适合可用的配置文件，请询问用户要创建哪个配置文件或使用哪个现有配置文件。 不要编造配置文件名称；调度器会静默丢弃未知的受派者。
• 分解、路由和总结 — 这就是全部工作。

分解手册

步骤 1 — 理解目标

如果目标含糊不清，请提出澄清性问题。提问的成本低；生成错误舰队的成本高。

步骤 2 — 绘制任务图

在创建任何内容之前，先在你的回复中向用户大声地绘制任务图。将每个具体的工作流视为一个候选卡片：

1. 从请求中提取通道。
2. 将每个通道映射到你在步骤 0 中发现的配置文件之一。如果某个通道不适合任何现有配置文件，请询问用户使用或创建哪个。
3. 决定每个通道是独立的还是受另一个通道限制的。
4. 将独立通道创建为没有父链接的并行卡片。
5. 创建综合/审查/集成卡片，并链接到它们所依赖的通道的父链接。在父级未完成时创建的子卡片处于 todo 状态；调度器只有在每个父级都完成后才将其提升为 ready。

应该扇出的提示示例（使用占位配置文件名称 — 替换为用户设置中存在的实际名称）：

• "构建一个应用程序" → 一张卡片给面向设计的配置文件用于产品/UI 方向，一张或两张卡片给工程配置文件用于实现，如果用户有审查配置文件则加上后期的集成/审查卡片。
• "修复阻碍并检查模型变体" → 一张实现卡片用于阻碍修复，加上一张发现/研究卡片用于配置/源代码验证。最终的审查卡片可以依赖两者。
• "研究文档并实现" → 文档研究卡片可以与代码库发现卡片并行运行；实现仅在真正需要这些发现时才等待。
• "分析此截图并找到相关代码" → 一张卡片给具有视觉能力的配置文件用于视觉分析，同时另一张卡片搜索代码库。

像"还有"、"最后"或"并且"这样的词并不自动意味着依赖关系。它们通常意味着"在报告之前确保这一点已涵盖"。仅当一张卡片无法在另一张卡片的输出存在之前开始时才链接任务。

在创建卡片之前向用户展示任务图。让他们纠正它 — 包括每个通道应由哪个实际的配置文件名称负责。

步骤 3 — 创建任务并链接

使用步骤 0 中的配置文件名称。下面的示例使用占位符 <profile-A>、<profile-B>、<profile-C> — 替换为用户实际拥有的。

t1 = kanban_create(
    title="research: Postgres cost vs current",
    assignee="<profile-A>",  # whichever profile handles research on this setup
    body="Compare estimated infrastructure costs, migration costs, and ongoing ops costs over a 3-year window. Sources: AWS/GCP pricing, team time estimates, current Postgres bills from peers.",
    tenant=os.environ.get("HERMES_TENANT"),
)["task_id"]

t2 = kanban_create(
    title="research: Postgres performance vs current",
    assignee="<profile-A>",  # same profile, run in parallel
    body="Compare query latency, throughput, and scaling characteristics at our expected data volume (~500GB, 10k QPS peak). Sources: benchmark papers, public case studies, pgbench results if easy.",
)["task_id"]

t3 = kanban_create(
    title="synthesize migration recommendation",
    assignee="<profile-B>",  # whichever profile does synthesis/analysis
    body="Read the findings from T1 (cost) and T2 (performance). Produce a 1-page recommendation with explicit trade-offs and a go/no-go call.",
    parents=[t1, t2],
)["task_id"]

t4 = kanban_create(
    title="draft decision memo",
    assignee="<profile-C>",  # whichever profile drafts user-facing prose
    body="Turn the analyst's recommendation into a 2-page memo for the CTO. Match the tone of previous decision memos in the team's knowledge base.",
    parents=[t3],
)["task_id"]

parents=[...] 限制提升 — 子任务保持在 todo 状态，直到每个父任务达到 done 状态，然后自动提升为 ready。无需手动协调；调度器和依赖引擎会处理。

如果任务图存在依赖关系，请先创建父卡片，捕获返回的 ID，并在子卡片的 kanban_create 调用期间将这些 ID 包含在子卡片的 parents 列表中。避免并行创建所有卡片然后在事后链接它们；这会创建一个窗口，在此期间调度器可以在子卡片的输入存在之前认领它。

步骤 4 — 完成你自己的任务

如果你是作为任务生成的（例如，规划配置文件被分配了 T0: "调查 Postgres 迁移"），使用你创建的内容的摘要将其标记为完成：

kanban_complete(
    summary="decomposed into T1-T4: 2 research lanes in parallel, 1 synthesis on their outputs, 1 prose draft on the recommendation",
    metadata={
        "task_graph": {
            "T1": {"assignee": "<profile-A>", "parents": []},
            "T2": {"assignee": "<profile-A>", "parents": []},
            "T3": {"assignee": "<profile-B>", "parents": ["T1", "T2"]},
            "T4": {"assignee": "<profile-C>", "parents": ["T3"]},
        },
    },
)

步骤 5 — 向用户报告

用简单的文字告诉他们你创建了什么，指明你使用的实际配置文件名称：

我已排队 4 个任务：

• T1（<profile-A>）：成本比较
• T2（<profile-A>）：性能比较，与 T1 并行
• T3（<profile-B>）：将 T1 + T2 综合为建议
• T4（<profile-C>）：将 T3 转化为 CTO 备忘录

调度器现在将处理 T1 和 T2。T3 在两者都完成后开始。T4 完成时你会收到网关通知。使用仪表板或 hermes kanban tail <id> 来跟踪进度。

常见模式

扇出 + 扇入（研究 → 综合）： N 个无父级的研究型卡片，一张综合卡片以所有研究卡片为父级。

并行实现 + 验证： 一张实施者卡片负责进行变更，同时一张探索者/研究者卡片负责验证配置、文档或源码映射。审阅者卡片可以依赖两者。不要因为用户在一句话中同时提到了两者，就让实施者负责无关的验证任务。

带门控的流水线： 规划者 → 实施者 → 审阅者。每个阶段的 parents=[前一个任务]。审阅者阻断或完成；如果审阅者阻断，操作员通过反馈解除阻断并重新生成任务。

同配置文件队列： N 个任务，全部分配给同一个配置文件，任务之间无依赖关系。调度器会串行处理——该配置文件按优先级顺序处理这些任务，并在其自身的记忆中积累经验。

人在回路： 任何任务都可以使用 kanban_block() 来等待输入。调度器在 /unblock 后重新生成。评论线程承载完整的上下文。

陷阱

编造不存在的配置文件名称。 调度器在生成未知的受派者时会静默失败——该卡片将永远停留在 ready 状态。请始终使用您在步骤 0 发现中找到的配置文件进行分配；如果不确定，请询问用户。

将独立的通道捆绑到一张卡片中。 如果用户要求两个独立的结果，请创建两张卡片。例如：“修复阻碍因素并检查模型变体”不是一个修复任务；应为修复创建一张修复者/工程师卡片，为变体检查创建一张探索者/研究者卡片，然后可以选择将审阅者依赖于两者。

因措辞而过度关联。 “最后检查 X” 如果 X 是静态配置、文档或源码发现，仍然可能与实现并行。仅当检查依赖于实现结果时，才将其链接在实现之后。

忘记依赖链接。 如果任务图是 研究 → 实现 → 审阅，不要将所有任务创建为独立的就绪卡片。使用父链接，以便实现/审阅任务在它们的输入存在之前无法运行。

重新分配 vs. 新任务。 如果审阅者以“需要更改”阻断，请创建一个从审阅者任务链接出来的新任务——不要用严厉的表情重新运行同一个任务。新任务应分配给原始的实施者配置文件。

链接的参数顺序。 kanban_link(parent_id=..., child_id=...) ——父级在前。搞混它们会将错误的任务降级为 todo。

不要在形状取决于中间发现时预先创建整个图。 如果 T3 的结构取决于 T1 和 T2 的发现，让 T3 作为“综合发现”任务存在，其自身的第一步是读取父级交接物并规划其余部分。协调器可以生成协调器。

租户继承。 如果在您的环境中设置了 HERMES_TENANT，请在每次 kanban_create 调用时传递 tenant=os.environ.get("HERMES_TENANT")，以便子任务保持在同一命名空间中。

恢复卡住的工作器

当一个工作器配置文件持续崩溃、产生幻觉或因其自身的错误而被阻断时（通常是：错误的模型、缺失的技能、损坏的凭证），看板仪表板会用一个 ⚠ 徽章标记该任务，并在抽屉中打开一个 恢复 部分。主要操作有三种：

1. 回收（或 hermes kanban reclaim <task_id>）—— 立即中止正在运行的工作器，并将任务重置为 ready。现有的认领 TTL 约为 15 分钟；这是快速脱离的途径。
2. 重新分配（或 hermes kanban reassign <task_id> <new-profile> --reclaim）—— 将任务切换到不同的配置文件（一个在此设置中存在的配置文件），并让调度器用一个新的工作器拾取它。
3. 更改配置文件模型 —— 仪表板会打印一个 hermes -p <profile> model 的复制提示，因为配置文件配置存在于磁盘上；在终端中编辑它，然后回收以使用新模型重试。

幻觉警告出现在以下情况：工作器的 kanban_complete(created_cards=[...]) 声明包含了不存在或不是由该工作器配置文件创建的卡片 ID（门控会阻止完成），或者自由格式的摘要引用了无法解析的 t_<hex> ID（建议性文本扫描，非阻断）。两者都会生成审计事件，即使在恢复操作之后也会持续存在——线索会保留以供调试。