4个 Agent 干 10 个人的活：我用 Kanban 搭了条 AI 流水线

Wed, 17 Jun 2026 08:00:00 +0800

在终端里给 3 个 Agent 派任务，中间等通知、等完一个再派下一个，一篇文章搞了 1.5 小时。后来用任务板把它们串起来，16 分钟搞定。

先说结论

多 Agent 协作的瓶颈从来不是 Agent 本身，而是协调方式。

在聊天窗口里给 Agent 排队派活，等于让一整个团队走单行道——前面的不走完，后面的全堵着。

换成 Kanban 任务板驱动后：依赖自动串联、独立任务并行、崩溃自动重跑，我的内容生产 Pipeline 从 10 步 1.5 小时压缩到 7 步 16 分钟。

这不是理论推演。下面每一组数据、每一个状态流转，都来自我实际跑过的任务。

一、为什么"聊天派活"走不通

先说三个真实场景，你应该很熟悉。

场景 1：串行瓶颈。

Agent A 写完文章，我手动复制结果喂给 Agent B 审核审校，B 跑完我再手动通知 Agent C 发博客。

三个人在群里排队，中间全是我在等。一篇技术文章从选题到发布，10 步操作耗时 90 分钟，其中 Agent 实际干活只有 40 分钟，剩下 50 分钟全是我手动衔接的等待。

场景 2：状态不可见。

派了 4 个 Agent 同时调研，有人跑完了有人卡住了有人崩了我根本不知道。

没有看板，没有进度条，没有审计记录。只能一个一个去翻历史消息问"你好了没"。

最离谱的一次，一个 Agent 崩溃了 20 分钟我才发现，它上游的两个 Agent 产出的数据已经丢了——因为没人存。

场景 3：崩溃恢复。

Agent 跑到一半挂了，上下文全丢。重新启动后它不记得之前做了什么，从头来过。

最痛的一次是文章写到 2500 字，审校 Agent 崩了，写作 Agent 的上下文也被清掉，整篇文章重写。从头到尾又花 40 分钟。

三个场景的共同特征：我在用人力协调本该由系统协调的事情。

二、Kanban 解决了什么

核心思路只有一个：把任务状态变成一等公民。

任务即状态机。 每个任务有明确的生命周期：

stateDiagram-v2
 [*] --> todo
 todo --> ready: 任务创建
 ready --> running: 调度器派发
 running --> done: 正常完成
 running --> blocked: 审核失败/阻塞
 blocked --> running: unblock 修复后继续
 done --> [*]
 blocked --> [*]: 归档

不是"在聊天里说了就算"，而是状态变更被持久化到数据库，任何时候都能查到"这个任务现在在哪一步、谁在做、什么时候开始的"。

依赖图让下游自动等待。

创建任务时指定 parents（上游依赖），子任务在父任务完成前不会 promote 到 ready。

不用我手动通知"B 做完了，你可以开始了 C"，系统自己管。这是效率提升的关键——并行任务同时跑，串行依赖自动接。

质量门禁。

审核任务（reviewer）如果发现问题，调用 block，下游所有任务全部卡住，不会出现"文章没审完就发出去了"的情况。修复后 unblock，流水线自动继续。

故障自动重排。

Agent 崩溃后，调度器检测到心跳超时，自动把任务从 running 回收到 ready，下一个空闲 Agent 接手。上下文不丢——因为任务记录里带着上一次的执行摘要和产出物路径。

这四条加起来，就是从"人盯人"到"系统自运转"的转变。

三、架构拆解：一张 SQLite 表怎么管住一整条流水线

我用的方案是一个 SQLite 驱动的 Agent 任务板。三块核心组件：

组件 1：SQLite 任务库。

所有任务状态、依赖关系、执行记录都存在一个本地 SQLite 文件里。选 SQLite 而不是 Redis/PostgreSQL 的原因很简单：零运维、够快、文件可备份。

两张核心表：tasks 表存所有任务的标题、状态、负责人、时间戳；task_links 表存依赖关系（哪个任务等哪个）。结构清晰到用 sqlite3 手动查询就能排查问题。

组件 2：Dispatcher 调度器。

一个常驻进程，每 60 秒轮询一次任务库。逻辑很直白：

找所有 ready 状态、且 assignee 空闲的任务 → 派给对应的 Agent 进程 → 任务变 running。

同时检查 running 任务的 TTL（默认 4 小时），超时则回收重排到 ready 队列。还处理 heartbeat——Agent 长时间没心跳就视为崩溃。

组件 3：Profile 工作进程。

每个 Agent 是一个独立的 Profile（你可以理解为"角色配置"），有自己的技能集、工作目录、记忆空间。

Profile 之间完全隔离——写手 Agent 看不到部署 Agent 的配置文件，审核 Agent 的记忆不会污染写作 Agent 的输出。这种隔离很重要，避免 Agent 之间的上下文串扰导致输出质量下降。

graph TB
 DB[SQLite 任务库
tasks + task_links + events]
 
 DB -->|轮询 60s| Disp[Dispatcher 调度器
发现ready → 派发
检测heartbeat → 回收
检查parents → promote]
 
 Disp --> Writer[writer
写稿 Profile]
 Disp --> Reviewer[reviewer
审核 Profile]
 Disp --> BlogBuilder[blog-creator
构建 Profile]
 Disp --> MPCreator[mp-creator
公众号 Profile]
 
 Writer -.->|产出| Reviewer
 Reviewer -.->|审核通过| BlogBuilder
 Reviewer -.->|审核通过| MPCreator
 
 style DB fill:#e1f5ff
 style Disp fill:#fff4e1
 style Writer fill:#e8f5e9
 style Reviewer fill:#ffebee
 style BlogBuilder fill:#f3e5f5
 style MPCreator fill:#e8f5e9

几个关键机制值得一提：

Heartbeat 心跳：Agent 跑长任务时每隔几分钟发一次心跳。调度器据此判断"还活着"。超过 1 小时没心跳的任务会被标记为 stale 并回收。
Skill 隔离：每个 Profile 只加载自己需要的技能。写作 Agent 有 blog/写作相关的 skill，部署 Agent 有运维 skill，互不干扰。
Event Log：每个状态变更都记一条 event。出问题时回溯时间线一目了然，不用猜是哪一步挂了。

四、实战场景一：7 步内容生产流水线

这是我最常用的场景——从选题到博客 + 公众号双渠道发布，全自动。

完整流程：

graph TB
 T1[T1: writer
写稿]
 T2[T2: reviewer
审校内容
PII/事实/AI味]
 T3[T3: blog-creator
Markdown + Hugo 构建]
 T4[T4: mp-creator
HTML + 封面 + 上传草稿]
 T5[T5: reviewer
审博客格式/构建]
 T6[T6: reviewer
审公众号格式]
 T7[T7: blog-deployer
部署上线]
 
 T2 -.->|parents: T1| T1
 T3 -.->|parents: T2| T2
 T4 -.->|parents: T2| T2
 T5 -.->|parents: T3| T3
 T6 -.->|parents: T4| T4
 T7 -.->|parents: T5, T6| T5
 T7 -.->|parents: T5, T6| T6
 
 style T1 fill:#e8f5e9
 style T2 fill:#ffebee
 style T3 fill:#e3f2fd
 style T4 fill:#fff3e0
 style T5 fill:#ffebee
 style T6 fill:#ffebee
 style T7 fill:#f3e5f5

每一步做什么：

T1 writer 拿到选题大纲，产出 Markdown 文稿。这一步通常 3-5 分钟。

T2 reviewer 检查内容质量——有没有泄露个人信息、有没有事实错误、有没有"AI 味"。这是第一道质量门禁。

T2 通过后 T3 和 T4 同时启动：T3 把 Markdown 转成 Hugo 格式并本地构建（验证页面数、检查 front matter），T4 生成公众号 HTML 和封面图并上传草稿。两个并行跑，谁先完成都行。

T5 和 T6 分别审博客和公众号的格式质量。T5 检查 Hugo 构建是否正常、页面数是否合理；T6 检查公众号 HTML 排版、封面图是否正确。

两个都通过后，T7 才部署到线上。

关键设计：T7 依赖 T5 和 T6 同时通过。

这意味着博客在终审通过前不会上线。有一次 T5 发现博客的 front matter 日期格式错误——没有时区后缀，导致 Hugo 解析成 0001 年，所有页面 URL 变成 /0001/01/01/...。

T7 自动被阻塞，直到修复日期格式、T5 重新通过后才继续。全程没有人为干预，调度器自己等了 3 分钟。

reviewer 的 block/unblock 实战：

reviewer 不是只说"通过"或"不通过"那么简单。它发现问题后，会在任务评论区写明具体原因和修改建议，然后调用 block。

下游任务全部卡在 blocked 状态。上游的写手 Agent 被 unblock 重跑后，能看到 reviewer 的评论作为上下文，直接针对性修改。

修改完成 → reviewer 重新审 → 通过 → block 解除 → 下游继续。这个循环跑 2-3 轮很正常，但每一轮的修改都有记录可追溯。

效果数据：

指标	优化前	优化后
步骤数	10 步	7 步（合并审核环节）
总耗时	1.5 小时	16 分钟
并行度	串行	2 路并行（T3 T4）
崩溃恢复	手动从头来	自动重排续跑
审计记录	无	全链路 event log

从 90 分钟到 16 分钟，省下的 74 分钟不是 Agent 变快了，是我在中间等待和手动衔接的时间被消除了。

五、实战场景二：多研究者并行调研

内容生产是线性流水线，但有些任务天然适合扇出。

模式：N 个 researcher 并行 → analyst 汇总 → writer 输出

graph TB
 R1[T1: researcher-A
调研竞品定价]
 R2[T2: researcher-B
调研竞品功能]
 R3[T3: researcher-C
调研用户评价]
 T4[T4: analyst
汇总]
 T5[T5: writer
输出报告]
 
 R4[并行] --> R1
 R4[并行] --> R2
 R4[并行] --> R3
 
 T4 -.->|parents: T1, T2, T3| R1
 T4 -.->|parents: T1, T2, T3| R2
 T4 -.->|parents: T1, T2, T3| R3
 
 T5 -.->|parents: T4| T4
 
 style R1 fill:#e3f2fd
 style R2 fill:#e3f2fd
 style R3 fill:#e3f2fd
 style T4 fill:#fff3e0
 style T5 fill:#e8f5e9

T1/T2/T3 同时跑，各自独立工作，互不干扰。它们都完成后 T4 自动 promote 到 ready——不需要我手动检查"三个都好了没"。T4 汇总后，T5 再基于汇总结果写报告。

为什么这比手动协调好？

三个 researcher 的完成时间通常不一致——A 可能 5 分钟跑完，B 要 8 分钟，C 遇到反爬可能 12 分钟。手动协调你得盯着，一个回来记一下，三个都回来再启动 analyst。中间的等待和状态追踪全在你脑子里。

用任务板，T4 的 parents 写着 [T1, T2, T3]，调度器自动检测三个都 done 后才 promote T4。你只需要创建任务，剩下的交给系统。

适合的场景：

技术选型（多个候选方案并行调研 → 横向对比报告）
竞品分析（每个竞品一个 researcher → 汇总对比）
市场调研（多个数据源并行采集 → 综合分析）

实际案例： 上周我做了一次 AI 编码工具调研，5 个 researcher 分别调研 GitHub Copilot、Cursor、Windsurf、Aider 和 Claude Code。串行跑要 50 分钟，5 个并行只要 12 分钟，analyst 汇总再加 5 分钟，总共 17 分钟出了一份完整报告。

六、2026 Agent 编排工具横评

2026 年 6 月，Augment Code 盘点了 9 个开源 Agent Orchestrator。Mistral AI 推出 Workflows 企业级工作流编排平台，Google 开源了 Agent 技能工具箱，Slack 发布长时运行多智能体系统。

Agent 协作已从"单兵作战"进化到"团队协作"阶段。FifthRow 在 2026 年 4 月的报告中指出，企业级 Agentic Orchestration 已从试点进入合规模基础设施建设阶段。

我挑几个有代表性的对比：

维度	SQLite 任务板方案	Vibe Kanban	Multica	OpenClaw A2A	Agent Kanban
定位	本地 SQLite 驱动的全能任务板	专注 coding agent 协调	托管式 Agent 平台	Agent 间通信协议	轻量开源任务板
依赖管理	✅ parents 图 + 自动 promote	✅ planning + review	✅ 托管	✅ A2A 协议	⚠️ 基础
并行执行	✅ fan-out	⚠️ 串行为主	✅ 多 Agent	✅ 独立 Agent	⚠️ 基础
质量门禁	✅ block/unblock	✅ code review 内建	❌	❌	❌
故障恢复	✅ heartbeat + 自动重排	⚠️ 需手动	✅ 托管	❌	❌
隔离性	✅ Profile 级隔离	⚠️	✅	✅ 独立配置	⚠️
部署门槛	低（一个 SQLite 文件）	中	高（SaaS）	高（协议复杂）	低

选型建议：

个人 / 小团队：优先选本地 SQLite 方案或 Vibe Kanban，够用且零运维。做内容生产选 SQLite 方案更通用，做编码选 Vibe Kanban 更垂直。

中等团队：Multica 的托管模式省心，Agent 作为"正式团队成员"被纳入管理。代价是依赖第三方平台，数据不在本地。

企业级：OpenClaw A2A 适合需要跨组织 Agent 协作的场景，但协议复杂度和运维成本都不低。适合技术能力强的团队。

七、落地建议 + 总结

三条实用建议：

第一，先跑通一个场景。

不要一上来就搭复杂的 Pipeline。选一个你最痛的流程——比如内容发布——先串通 writer → reviewer → deployer 三步。跑通后再加并行分支、加审核环节。复杂度是长出来的，不是设计出来的。

第二，reviewer 是质量核心。

没有 reviewer 的流水线等于没有刹车。我的 Pipeline 里 reviewer 出现了两次：内容审核和格式审核。每次审核都是一次 block/unblock 循环，看起来"慢"了，但它拦截了 PII 泄露、事实错误、格式崩溃——这些一旦上线，修复成本是 10 倍。

第三，依赖图是效率关键。

仔细想想哪些步骤可以并行、哪些必须串行。我的 Pipeline 里 blog-creator 和 mp-creator 是并行的（独立产物），但它们都依赖 reviewer 通过（质量门禁）。把并行和串行想清楚，7 步就能做到 10 步的效果。

总结：

多 Agent 协作的本质不是"让更多 Agent 同时干活"，而是"让正确的 Agent 在正确的时机拿到正确的上下文"。

Kanban 任务板做的事情就是管这件事：状态可见、依赖自动、质量可拦截、崩溃可恢复。

我自己跑了几十轮 Pipeline 后最大的感受是：协调方式比 Agent 能力更影响产出效率。同样的 Agent、同样的模型，换一种协调方式，时间砍掉 80%。这不是 Agent 变聪明了，是我不挡路了。

流水线 on Kalend's Blog