Posts
read more
给本地 Agent 造一块看板（六）：多 Agent 工作台派——派单模型与认领模型的分野
给本地 Agent 造一块看板（六）：多 Agent 工作台派——派单模型与认领模型的分野
本系列共八篇，用同一套七层能力框架（C1–C7）横向解剖开源任务看板。 本篇覆盖
iOfficeAI/AionUi、DanWahlin/ai-agent-board、smtg-ai/claude-squad、Nimbalyst/nimbalyst、langwatch/kanban-code。 元数据于 2026-10-08 经 GitHub API 一手核验。
一、这一派是最"像产品"的一批
如果说前面几派是"给工程师用的工具"，这一派就是"给人用的产品"：有像样的界面、有自动探测、有向导、有通知、有移动端。
它们的共同强项高度一致：
- C1 看板呈现：拖拽、实时流式输出、diff 查看器、行内评论，体验是全系列最好的；
- C4 异构 agent 驱动：启动时自动探测本机已装了哪些 CLI，这是本派最实用的一项能力；
- C5 执行隔离：worktree 隔离几乎是标配，且往往配了自动清理。
它们的共同软肋也高度一致：C2/C3（自主领取与扫描）与 C6/C7（验收与额度）基本不在射程内。
而这一切背后有一个更本质的差别，本篇的主要论点就围绕它展开。
二、核心分野：派单模型 vs 认领模型
先把这个区别讲清楚，因为它解释了本派为什么"功能很多，却依然不能无人值守"。
graph TB
subgraph DISPATCH["派单模型（Leader 分配）"]
L["Leader Agent"] -->|"拆解"| T1["子任务 A"]
L -->|"拆解"| T2["子任务 B"]
T1 --> W1["Teammate 1"]
T2 --> W2["Teammate 2"]
end
subgraph CLAIM["认领模型（任务池）"]
P["共享任务池<br/>（一张张待领的卡）"] -->|"空闲 agent 自行 claim"| A1["Agent A"]
P -->|"空闲 agent 自行 claim"| A2["Agent B"]
P -->|"空闲 agent 自行 claim"| A3["Agent C"]
end
| 派单模型 | 认领模型 | |
|---|---|---|
| 谁决定任务归属 | 一个中心 Agent（Leader） | 空闲的 agent 自己 |
| 任务有没有"在列上等人来抢"的状态 | 没有 | 有 |
| agent 是长期存活还是被唤起 | 被 Leader 唤起 | 常驻，自行轮询 |
| 新增一个 agent 的成本 | 要改 Leader 的分配逻辑 | 几乎是零 |
| 与"吃满免费额度"的契合度 | 低（Leader 决定谁干活） | 高（谁有额度谁来接） |
这个区别对本场景是决定性的。 因为本场景的动机是"让多个 agent 长时间持续运行、吃满各家免费额度"——这要求系统能根据 agent 的可用性动态分配任务，而不是由一个 Leader 预先分好。认领模型天然适合这件事；派单模型天然不适合。