Hermes Kanban 是一块持久化任务板，多个命名 Agent 从上面认领工作、并行执行、结构化交接——跨进程、跨重启、可追溯。

如果你已经在用 Hermes 做单 Agent 任务，但发现一个 Agent 做所有事效率太低、上下文太长、任务之间互相干扰——Kanban 就是你需要的下一步。

这篇文章适合谁：已上手 Hermes 单 Agent 的用户，准备升级到多个专精 Agent 并行协作。

为什么需要多 Agent 编排

单 Agent 的瓶颈很明显。

翔宇在实际使用中反复遇到三个问题：一个 Agent 同时处理研究、编码、审查三类任务时，上下文窗口被占满，前面讨论的细节被压缩丢失；长任务执行到一半进程崩溃，所有中间状态全部丢失，从头再来；需要人工确认的决策点无法优雅地暂停和恢复。

多 Agent 协作不是让一个 Agent 更聪明，而是让多个专精 Agent 各做各的事。

Hermes 提供了两种互补的多 Agent 机制：Kanban 持久化任务板用于跨进程、跨重启的长期协作，delegate_task 子代理委派用于进程内的短期并行推理。

Kanban 的六列看板机制

Kanban 的核心是一个 SQLite 数据库（~/.hermes/kanban.db），在所有 Hermes Profile 之间共享。每个任务是数据库中的一行，每次交接是一条任何人都能读写的记录，每个 Worker 是一个拥有自身身份的完整操作系统进程。

💡 通俗讲：把 Kanban 想象成一块共享白板。你在白板上贴任务卡片，不同的人（Agent）走到白板前认领自己的卡片，做完后把结果写在卡片背面。白板不会因为某个人下班（进程退出）而消失。

六列定义

任务在六列之间流转的逻辑是自动的：调度器每 60 秒执行一次 dispatch tick，检查 Ready 列中有任务的 Profile，为匹配的 Profile 派生 Worker 进程，Worker 通过工具集与看板交互，完成或阻塞后调度器处理状态转换。

依赖引擎

任务之间可以建立父子依赖关系。子任务在父任务完成前停留在 Todo 列，不会被提升到 Ready。这意味着你可以创建依赖链：设计 Schema → 实现 API → 编写测试——只有 Schema 任务完成后，API 任务才会变为 Ready。

工具集划分

Kanban 的工具严格分为两组：

Worker 工具（任务范围内操作）：

• kanban_show — 获取当前任务信息
• kanban_complete — 标记任务完成，写入 summary 和 metadata
• kanban_block — 阻塞任务，等待人工或审查
• kanban_heartbeat — 报告进度
• kanban_comment — 添加评论

Orchestrator 工具（跨任务路由）：

• kanban_list — 列出所有任务
• kanban_create — 创建新任务
• kanban_link — 建立任务依赖
• kanban_unblock — 解除阻塞
• kanban_comment — 对外部任务评论

这个分割不是建议，而是由 kanban-orchestrator Skill 强制执行的约束。Worker 不做分发或路由，Orchestrator 不做实现工作。

九种协作模式

Kanban 支持九种协作模式，覆盖了从简单并行到复杂流水线的各种场景：

翔宇在实际使用中最常用的是 P1（并行研究）、P2（流水线）和 P5（人工闸门）。P8 在运营多个品牌频道时非常有用——每个品牌频道是同一个 content-creator Profile 的不同任务，自然并行。

编排模式：自动 vs 手动

Kanban 的任务分解有两种模式：

• Auto 模式：Triage 列的任务自动被分解器处理——读取 Profile 名单和描述，生成子任务图，路由到最合适的专家
• Manual 模式：点击卡片上的「Decompose」或运行 hermes kanban decompose <id>

分解器使用的模型可以在 auxiliary 配置段中单独指定：

提示词：生成看板分解器辅助配置

请帮我生成 Hermes config.yaml 的 auxiliary 配置段。要求：

• 包含 kanban_decomposer 和 triage_specifier 两个子项
• 每个子项包含 provider（默认 "auto"）和 model（默认空字符串）字段
• 格式为 YAML

将生成的配置段添加到 ~/.hermes/config.yaml 的顶层即可。

delegate_task：进程内子代理委派

Kanban 是跨进程的持久化协作，而 delegate_task 是同一个进程内的轻量级委派。两者互补，不是替代关系。

核心机制

delegate_task 派生 AIAgent 子实例，每个子代理有三个关键特性：

完全隔离的对话 — 子代理从零开始，不知道父代理的对话历史、工具调用记录或讨论过的任何内容。唯一上下文来自 goal 和 context 字段。

受限工具集 — 通过 toolsets 参数控制子代理可访问的工具。叶子子代理被永久阻止访问 delegate_task、clarify、memory、send_message、execute_code 五个工具。

独立终端会话 — 每个子代理有自己的终端、工作目录和状态。中间工具调用不进入父上下文，只返回摘要。

并行批次

默认最多 3 个并发子代理（通过 delegation.max_concurrent_children 配置，无硬上限）：

提示词：并行批次委派任务

请帮我写一个 delegate_task 调用，同时启动三个子代理。要求：

• 两个子代理分别研究 topic A 和 topic B，工具集只开放 web
• 一个子代理修复构建问题，工具集开放 terminal 和 file
• 使用 tasks 列表批量传入

三个子代理同时启动，各自独立工作，结果按任务索引排序返回。如果批次超过 max_concurrent_children 限制，会返回工具错误而不是静默截断。

上下文传递的铁律

这是翔宇在实际使用中反复踩的坑：子代理完全不知道你的对话。必须在 goal 和 context 中传递所有需要的信息。

提示词：正确传递上下文给子代理

请帮我写一个 delegate_task 调用，修复 api/handlers.py 第 47 行的 TypeError。要求：

• goal 要具体到文件名和错误类型，不能写模糊的 "Fix the error"
• context 要包含完整的错误信息（'NoneType' object has no attribute 'get'）
• context 要说明函数名（process_request）、数据来源（webhook 的 dict）和根因（'metadata' 键有时缺失）
• 子代理完全看不到父代理的对话历史，所有背景必须写在 goal 和 context 中

关键原则：写得越模糊，子代理越容易跑偏。把 delegate_task 想象成给一个全新同事发邮件——对方完全不知道你之前做了什么。

💡 通俗讲：把 delegate_task 想象成给一个全新的同事发邮件。这个同事完全不知道你之前做了什么，你得在邮件里把所有背景信息写清楚。写得越具体，他干得越好。

模型覆盖

子代理可以配置更便宜的模型——这是成本优化的关键杠杆：

提示词：配置子代理使用便宜模型

请帮我在 Hermes config.yaml 中添加 delegation 配置段。要求：

• model 设为 "google/gemini-flash-2.0"（或其他便宜快速模型）
• provider 设为 "openrouter"
• 格式为 YAML，放在 config.yaml 顶层

翔宇的做法是主 Agent 用贵模型做规划和综合，子代理用便宜模型做具体的研究或实现工作。一次三路并行研究，主 Agent 用 Claude Sonnet，子代理用 Gemini Flash，成本降低 80% 以上。

关于 Hermes 的完整成本控制策略，见 Hermes 成本控制指南。

五种委派模式（Delegation Patterns）

官方文档定义了五种委派模式，每种解决一类特定问题：

Pattern 1：Parallel Research（并行研究）

三个话题同时研究，每个子代理独立搜索网页，返回摘要。父代理综合为连贯简报。

提示词：三路并行研究认证方案

请帮我写一个 delegate_task 调用，同时启动三个研究子代理。要求：

• 项目背景：~/code/auth-service（Python, FastAPI）
• 子代理 1：研究 OAuth 2.0 PKCE 流程，聚焦移动客户端，输出写入 /tmp/research-oauth.md
• 子代理 2：研究 JWT 轮换和刷新令牌策略，聚焦令牌轮换与重放检测，输出写入 /tmp/research-jwt.md
• 子代理 3：研究基于 Redis 的会话认证，聚焦 Redis 会话存储和 Cookie 安全，输出写入 /tmp/research-session.md
• 每个子代理的 toolsets 开放 web 和 file
• 每个子代理的 context 要包含项目路径、技术栈、聚焦点和输出文件路径

三个子代理完全隔离运行，互相不知道对方的存在，研究结论不会交叉污染。

Pattern 2：Code Review（代码审查）

委派安全审查到一个全新上下文的子代理。因为子代理不知道你写代码时的任何假设，它能用新鲜的视角审视代码。context 必须包含项目路径、文件列表、测试命令。

Pattern 3：Compare Alternatives（方案对比）

并行评估同一问题的多种方案。因为子代理之间完全隔离，每个评估独立进行，不会交叉污染——评估方案 A 的子代理不知道方案 B 的存在。

Pattern 4：Multi-File Refactoring（多文件重构）

把大重构任务分配到并行子代理，每个处理不同的代码区域。关键约束：如果两个子代理可能改同一个文件，留给父代理在并行工作完成后处理冲突。

Pattern 5：Gather Then Analyze（采集后分析）

先用 execute_code 做机械化数据收集（10+ 顺序工具调用，成本低），再用 delegate_task 做推理密集的分析（单次昂贵推理，干净上下文）。这是成本优化的经典模式。

并发和深度调优

🔥 翔宇判断：max_spawn_depth: 3 加上 max_concurrent_children: 3，理论上能产生 27 个并发叶子代理。每多一层乘以开销。翔宇建议 depth 保持默认的 1，需要嵌套时用 Kanban 代替——Kanban 的嵌套有依赖引擎保护，不会失控。

并行批次 vs Kanban 的对比

两种机制的并行方式完全不同：

Kanban 的并行性

Kanban 的并行天然来自调度器。每个 Profile 是一个独立的 Worker 池。调度器在每个 tick 为每个有 Ready 任务的 Profile 派生 Worker：

• Translator Profile → 一个翻译任务在跑
• Transcriber Profile → 一个转录任务在跑
• Copywriter Profile → 一个文案任务在跑

三个 Profile 自然并行。同一 Profile 内的任务按优先级串行——这是有意设计，避免同一角色的两个 Worker 争抢资源。

delegate_task 的并行性

delegate_task 的并行通过 ThreadPoolExecutor 实现。默认 3 个并发子代理，结果按任务索引排序返回。

全维度对比

💡 通俗讲：delegate_task 像你在会议中分配即时任务——"你去查 A，你去查 B，五分钟后回来汇报"。Kanban 像公司的项目管理看板——任务贴在板上，不同部门的人各自认领，做完交接，项目经理随时能看到全局进度。

Orchestrator 铁律

一个行为端正的 Orchestrator 绝不亲自做工作。

它分解用户的目标为任务，链接依赖，把每个任务分配给你设置的 Profile 之一，然后退场。kanban-orchestrator Skill 编码了三条约束：

1. 反诱惑规则 — Orchestrator 不能写代码、不能运行测试、不能编辑文件
2. Step-0 Profile 发现 — Orchestrator 必须先运行 hermes profiles list 发现机器上实际存在的 Profile，不能分配给不存在的 Profile（调度器对未知 assignee 静默失败）
3. 分解手册 — 基于 kanban_create、kanban_link、kanban_comment 的标准化分解流程

翔宇的 Orchestrator SOUL.md 模板长这样：

提示词：生成 Orchestrator SOUL.md

请帮我生成一个 Hermes Orchestrator Profile 的 SOUL.md 文件。要求：

• 身份定义为任务分解和路由专家
• 铁律部分包含五条：禁止自己做实现工作、禁止写代码/跑测试/编辑文件、分配必须基于机器上实际存在的 Profile、顺序任务必须创建依赖链、任务正文必须包含完整上下文
• 分解流程分六步：读取用户目标 → 运行 hermes profiles list 发现可用 Profile → 拆分为 3-7 个离散任务 → 用 kanban_create 创建并用 kanban_link 建立依赖 → 分配到最合适的 Profile → 退场
• 格式为 Markdown，包含标题、铁律列表和编号步骤

这份 SOUL.md 放在 Orchestrator Profile 的目录下，Hermes 启动时自动加载为系统提示词。

Kanban Tutorial：四个用户故事

官方教程用四个递进的用户故事展示 Kanban 的完整能力。翔宇把每个故事的关键操作提炼出来。

初始化

hermes kanban init           # 可选，首次使用自动初始化
hermes dashboard             # 打开 http://127.0.0.1:9119

Dashboard、CLI、Worker 工具三个入口共享同一个 SQLite 数据库，数据始终一致。

Story 1：Solo Dev 发布功能

三任务依赖链——设计 Schema → 实现 API → 编写测试：

提示词：创建三任务依赖链

请帮我用 hermes kanban create 创建三个有依赖关系的任务。要求：

• 任务 1："Design auth schema"，分配给 backend-dev，tenant 为 auth-project，优先级 2，body 描述设计 user/session/token 的 schema
• 任务 2："Implement auth API endpoints"，分配给 backend-dev，用 --parent 依赖任务 1，body 描述实现 POST /register、POST /login 等端点
• 任务 3："Write auth integration tests"，分配给 qa-dev，用 --parent 依赖任务 2，body 描述覆盖正常路径和错误密码等场景
• 每个任务创建后用 --json | jq -r .id 捕获 ID，作为下一个任务的 --parent 参数

依赖引擎自动管理提升：只有任务 1 在 Ready，任务 2 和 3 在 Todo 等待父任务完成。

Worker 完成任务时调用 kanban_complete，把结构化交接信息写入 task_runs 表：

提示词：结构化交接完成任务

请帮我写一个 kanban_complete 调用，完成 Schema 设计任务。要求：

• summary 写一句话结论，包含设计出的表结构（如 users 表含 id/email/pw_hash，sessions 表含 id/user_id/jti/expires_at）
• metadata 传入结构化数据，包含 changed_files 列表和 decisions 列表
• summary 给下游 Worker 看，metadata 给下游 Worker 用

下游 Worker 调用 kanban_show() 时，会在 worker_context 中看到父任务的 summary 和 metadata——这就是结构化交接的威力。

Story 2：Fleet Farming（批量任务并行）

提示词：批量创建翻译和转录任务

请帮我用 shell 循环批量创建 Kanban 任务。要求：

• 第一组：分别为 Spanish、French、German 三种语言各创建一个翻译任务，标题格式 "Translate homepage to {语言}"，分配给 translator Profile，tenant 为 content-ops
• 第二组：为 5 个客户电话录音各创建一个转录任务，标题格式 "Transcribe Q3 customer call #{编号}"，分配给 transcriber Profile，tenant 为 content-ops
• 使用 for 循环批量创建

三个专业 Profile 的任务在同一个 kanban.db 上并行推进。In Progress 列按 Profile 分组，每个 Worker 的活跃任务一目了然。

Story 3：角色流水线 + 重试

PM 写规格 → 工程师实现 → 审查员拒绝 → 工程师带改动重试 → 审查员通过。

重试是一等公民。每次尝试是 task_runs 表中的独立行，有自己的 outcome、summary、error、metadata。重试的 Worker 看到前次尝试的阻塞原因，针对性修复而非从头开始：

# 审查员发现问题，阻塞任务
kanban_block(
    reason="Review: password strength check missing, reset link isn't single-use"
)
# → 任务转到 blocked，run 1 以 outcome='blocked' 关闭

解除阻塞后，调度器把任务推回 Ready，下一 tick 派生新 Worker。新 Worker 调用 kanban_show() 时看到 run 1 的阻塞原因，针对性修复：

kanban_complete(
    summary="added zxcvbn strength check, reset tokens are now single-use",
    metadata={"changed_files": [...], "review_iteration": 2},
)

Story 4：断路器和崩溃恢复

断路器：连续 N 次失败后自动阻塞，防止看板无限抖动。

hermes kanban create "Deploy to staging (missing creds)" \
    --assignee deploy-bot --tenant ops \
    --max-retries 3

三次 spawn_failed 后任务变 blocked，outcome 为 gave_up。如果接入了 Telegram 或 Discord 或 Slack，网关在 gave_up 事件时自动发通知。

崩溃恢复：Worker 进程死掉（内存溢出、段错误），调度器通过 kill(pid, 0) 检测到死 PID，释放认领，任务回到 Ready，下一 tick 派发新 Worker。重试 Worker 看到崩溃历史，可以选择更安全的策略。

Kanban 的结构化交接是它与普通任务管理工具的核心差异。

Worker 调用 kanban_show() 时获得的 worker_context 包含两部分信息：

1. 当前任务的前次尝试 — outcome、summary、error、metadata
2. 父任务结果 — 每个父任务最近完成 run 的 summary 和 metadata

这取代了平面看板系统中"翻评论和产出"的低效模式。PM 在 spec 的 metadata 写验收标准，工程师的 Worker 在父交接中结构化地看到这些标准——不是去评论区搜索，而是数据直接传递。

🔥 翔宇判断：结构化交接是 Kanban 最被低估的特性。大部分教程只讲任务创建和看板流转，但真正让多 Agent 协作高效的是交接质量。翔宇建议每个 kanban_complete 调用都认真写 summary（给下游看的一句话结论）和 metadata（给下游用的结构化数据），不要只写一个"done"。

Kanban Codex Lane：让 Codex 参与协作

Hermes 设计了一个名为 Kanban Codex Lane 的 Skill，让 Codex CLI 作为隔离实现车道参与 Kanban 协作。

设计原则

核心理念是"Hermes 是壳层，Codex 是引擎"：

• Hermes 始终是任务所有者 — 它调用 kanban_show，决定是否适合 Codex，创建隔离工作空间，启动和监控 Codex，协调差异，运行验证，写最终的 kanban_complete 或 kanban_block
• Codex 仅是输入车道 — Codex 的输出不是任务完成信号，不是受信审查者，不允许直接写持久 Kanban 状态
• Codex 成功退出时故意阻塞等待审查 — 依赖任务不会自动提升

Codex 被明确禁止调用 kanban_complete、kanban_block、kanban_create、网关消息或任何 Hermes 看板 CLI。

Worker Lane 架构

Kanban Worker Lane 是调度器可以路由任务的进程类别。当前有三种 Lane 类型：

Non-Hermes CLI Lane 的 spawn_fn 是可插拔的，但包装 CLI 退出码到 kanban_complete/kanban_block、映射 CLI 工作空间惯例到 HERMES_KANBAN_WORKSPACE 环境变量等集成工作仍需逐案设计。Codex Lane 的 PR 因范围过大被关闭，等待从最新 main 重建的窄范围后续 PR。

关于 Hermes 的完整功能体系，见 Hermes Agent 完全指南。

完整的三 Profile Kanban 实操

翔宇把从创建 Profile 到启动 Dashboard 的完整步骤整理出来：

提示词：搭建三 Profile 流水线并创建依赖链任务

请帮我完成以下五步 Hermes Kanban 搭建。要求：

第一步：创建三个专精 Profile

• researcher：描述 "Deep web research and source gathering"
• implementer：描述 "Code implementation with TDD"
• reviewer：描述 "Code review and quality gates"

第二步：为每个 Profile 安装 Skill

• researcher 安装 llm-wiki
• implementer 安装 test-driven-development 和 subagent-driven-development
• reviewer 安装 requesting-code-review

第三步：创建 Orchestrator Profile

• 描述 "Task decomposition and routing only"

第四步：创建三任务依赖链（tenant 为 auth-project，优先级 2）

• 任务 1：Research authentication best practices → 分配给 researcher，body 为调研 OAuth2/JWT/session-based auth
• 任务 2：Implement auth module → 分配给 implementer，--parent 依赖任务 1，body 为按调研结论用 TDD 实现
• 任务 3：Review auth implementation → 分配给 reviewer，--parent 依赖任务 2，body 为安全审查加代码质量检查
• 每个任务用 --json | jq -r .id 捕获 ID 传给下游

第五步：启动 Dashboard

• 运行 hermes dashboard 打开 http://127.0.0.1:9119 观察

这个配置创建了一个 P2 Pipeline 模式的三阶段流水线：researcher 调研最佳实践 → implementer 按调研结论实现 → reviewer 做安全审查。每个阶段完成后，结构化交接数据自动传递到下游。

每个 Worker 是完整的 Hermes 实例

一个容易忽视的细节：每个 Kanban Worker 是一个完整的 Hermes 实例，拥有自己的 Agent 循环（Agent Loop）。这意味着每个 Worker 可以在执行任务过程中独立学习和创建 Skill——第一次做代码审查时创建的 Skill，后续任务自动可用。Orchestrator 不需要知道 Worker 的 Skill 细节，Worker 自适应。

关于 Hermes 的 Skill 进化系统如何工作，见 Hermes Skill 自我进化系统。

config.yaml 完整 delegation 配置段

提示词：生成完整的 delegation 配置段

请帮我生成 Hermes config.yaml 的 delegation 配置段。要求包含以下五个字段：

• max_concurrent_children：每次 delegate_task 的并行批次大小，设为 3
• max_spawn_depth：子代理嵌套深度，设为 1（扁平，不嵌套）
• model：子代理默认模型，设为 "google/gemini-flash-2.0"（可选）
• provider：子代理默认提供商，设为 "openrouter"（可选）
• orchestrator_enabled：是否允许 orchestrator 角色的子代理，设为 true
• 格式为 YAML，每个字段加注释说明用途

嵌套编排：Kanban vs delegate_task

当任务需要嵌套时，两种机制的行为差异很大：

delegate_task 的嵌套

通过 role="orchestrator" 允许子代理再委派：

提示词：嵌套委派——子代理再派生子代理

请帮我写一个 delegate_task 调用，委派一个 Orchestrator 子代理。要求：

• goal 为 "Survey three code review approaches and recommend one"
• role 设为 "orchestrator"（允许该子代理再派生叶子子代理）
• context 包含项目背景和评估维度

这个 Orchestrator 子代理可以再派生三个叶子子代理分别研究三种方案，然后综合结论。但嵌套深度受 max_spawn_depth 限制。

Kanban 的嵌套

通过 --parent 参数建立任务依赖：

提示词：创建扇入依赖——多个研究汇聚到一个综合任务

请帮我用 hermes kanban create 创建四个任务的扇入结构。要求：

• 三个并行研究任务：分别研究 approach A/B/C，全部分配给 researcher Profile
• 一个综合任务："Synthesize findings"，分配给 analyst Profile
• 综合任务用 --parent 同时依赖三个研究任务（传入三个 --parent $ID）
• 每个研究任务用 --json | jq -r .id 捕获 ID

SYNTHESIS 任务在三个 RESEARCH 任务全部完成前停留在 Todo。Kanban 的嵌套没有深度限制，依赖引擎自动管理提升。

两者的本质差异

多看板支持

当项目多了之后，一个全局看板会变得拥挤。Hermes 支持创建独立的 Board：

hermes kanban board create my-project
hermes kanban --board my-project create "任务标题" --assignee backend

每个 Board 有独立的 kanban.db，Worker 物理上无法看到其他 Board 的任务。这在多项目并行时非常有用——auth-project 的任务和 payment-project 的任务完全隔离。

Kanban 相关 Skill 推荐

Hermes 生态中有几个 Skill 与 Kanban 多 Agent 协作直接相关：

一个典型的配置：研究员 Profile 装 llm-wiki，实现者 Profile 装 test-driven-development 和 subagent-driven-development，审查者 Profile 装 requesting-code-review。每个 Profile 的 Skill 组合决定了它的专业能力。

行业对比：Hermes Kanban 的定位

Hermes Kanban 不是唯一的多 Agent 编排方案，但它的定位非常独特。

同类工具

Microsoft 的三种编排模式

微软 Azure 的 AI Agent 编排文档定义了三种模式：

Hermes 的独特之处在于它同时覆盖了三种模式：Orchestrator 做 Supervisor，每个 Worker 通过自我改进循环做 Adaptive，Worker Lane 的可插拔架构支持 Custom。

社区反响

Kanban 多 Agent 功能在社区引发了强烈反响。Nous Research 官方 User Stories 页面收录了一篇标题为 "WHAT IS THE NEW KANBAN FEATURE BUILT INTO HERMES? (IT'S GAME CHANGING)" 的 Reddit 帖子。

社区反复提到的三个赞点：

1. 持久性 — 不像 delegate_task 在父轮次中断时全部丢失，Kanban 任务跨重启存活
2. 可见性 — Dashboard 让你随时看到所有 Agent 在做什么，不用翻日志
3. 结构化交接 — 不是"去评论区找信息"，而是 summary 加 metadata 在父子任务间结构化传递

YouTube 上也有多个深度教程，其中 "I Built the Ultimate Multi-Agent Workflow w/ Hermes Agent Kanban Board" 获得了超过 24000 次观看。

关于 Hermes 的定时任务自动化能力，见 Hermes Cron 自动化。如果你还没开始用 Hermes，建议先从 Hermes Agent 完全指南 入手。更多关于多 Agent 协作的通用方法论，见翔宇之前写的 多 Agent 协作指南。

常见问题

Hermes Kanban 和 delegate_task 有什么区别？

delegate_task 是同步的进程内委派，子代理在父轮次内完成后返回结果。Kanban 是持久化的跨进程任务板，任务跨重启存活，支持人工介入和多 Agent 认领。前者适合短期推理任务，后者适合跨边界、需持久化、需人工参与的工作。两者互补——Kanban Worker 内部可以使用 delegate_task 进一步并行。

Kanban 最多能跑多少个 Agent 并行？

并行数等于 Profile 数量——三个 Profile 就是三路并行，十个就是十路。同一 Profile 内的任务按优先级串行，跨 Profile 天然并行。

delegate_task 的子代理能看到父代理的对话历史吗？

不能。子代理完全隔离，唯一上下文来自 goal 和 context 字段显式传入的内容。这是有意设计——隔离防止父代理偏见传递。

Kanban 任务失败了怎么办？会无限重试吗？

不会。内置断路器在连续 N 次失败（默认 2 次，--max-retries 可调）后自动阻塞任务为 gave_up 状态，接入消息网关时自动发通知。

Orchestrator 可以自己做实现工作吗？

绝对不可以。Orchestrator 只负责分解目标、链接依赖、分配 Profile 后退场，kanban-orchestrator Skill 通过反诱惑规则强制执行这一约束。

可以给 Kanban Worker 和 delegate_task 子代理配置不同的模型吗？

可以。delegate_task 通过 delegation.model 配置子代理模型，Kanban 每个 Profile 独立配置。典型做法是 Orchestrator 用贵模型做规划，Worker 用便宜模型做执行。

Kanban 能让 Codex 参与协作吗？

设计了 Kanban Codex Lane，Codex 作为隔离实现车道参与协作，Hermes 保留任务所有权，成功退出时故意阻塞等待审查。该 PR 因范围过大被关闭，等待窄范围后续 PR。

Kanban 和工作流是什么关系？

工作流是单 Agent 内的多步指令执行，Kanban 是多 Agent 间的任务分发和交接。Kanban 不替代工作流，而是在更高层级编排——一个 Kanban 任务的 Worker 内部可以执行一个完整工作流。两者是互补的层级关系。

下一步

• AI 编程实操课：Claude Code + Codex + Agent 工作流，覆盖一人公司、自媒体自动化、AI 副业全场景。237 篇实战教程 + 最佳实践 + 源码包，跟着做就出成果。国内版-FlowUS | 国际版-BMC
• YouTube 频道：翔宇工作流
• 微信公众号：搜索「翔宇工作流」