https://caozuohua.github.io/tags/acp/Recent content in ACP on CAO ZUOHUAHugozh-cnThu, 08 Oct 2026 20:55:00 +0800https://caozuohua.github.io/posts/2026-10-08-agent-kanban-05-agent-workbench/Thu, 08 Oct 2026 20:55:00 +0800https://caozuohua.github.io/posts/2026-10-08-agent-kanban-05-agent-workbench/<h1 id="给本地-agent-造一块看板六多-agent-工作台派派单模型与认领模型的分野">给本地 Agent 造一块看板（六）：多 Agent 工作台派——派单模型与认领模型的分野</h1> <blockquote> <p>本系列共八篇，用同一套七层能力框架（C1–C7）横向解剖开源任务看板。 本篇覆盖 <code>iOfficeAI/AionUi</code>、<code>DanWahlin/ai-agent-board</code>、<code>smtg-ai/claude-squad</code>、<code>Nimbalyst/nimbalyst</code>、<code>langwatch/kanban-code</code>。 元数据于 2026-10-08 经 GitHub API 一手核验。</p> </blockquote> <hr> <h2 id="一这一派是最像产品的一批">一、这一派是最&quot;像产品&quot;的一批</h2> <p>如果说前面几派是&quot;给工程师用的工具&quot;，这一派就是&quot;给人用的产品&quot;：有像样的界面、有自动探测、有向导、有通知、有移动端。</p> <p>它们的共同强项高度一致：</p> <ul> <li><strong>C1 看板呈现</strong>：拖拽、实时流式输出、diff 查看器、行内评论，体验是全系列最好的；</li> <li><strong>C4 异构 agent 驱动</strong>：<strong>启动时自动探测本机已装了哪些 CLI</strong>，这是本派最实用的一项能力；</li> <li><strong>C5 执行隔离</strong>：worktree 隔离几乎是标配，且往往配了自动清理。</li> </ul> <p>它们的共同软肋也高度一致：<strong>C2/C3（自主领取与扫描）与 C6/C7（验收与额度）基本不在射程内。</strong></p> <p>而这一切背后有一个更本质的差别，本篇的主要论点就围绕它展开。</p> <hr> <h2 id="二核心分野派单模型-vs-认领模型">二、核心分野：派单模型 vs 认领模型</h2> <p>先把这个区别讲清楚，因为它解释了本派为什么&quot;功能很多，却依然不能无人值守&quot;。</p> <div class="mermaid"> graph TB subgraph DISPATCH[&#34;派单模型（Leader 分配）&#34;] L[&#34;Leader Agent&#34;] --&gt;|&#34;拆解&#34;| T1[&#34;子任务 A&#34;] L --&gt;|&#34;拆解&#34;| T2[&#34;子任务 B&#34;] T1 --&gt; W1[&#34;Teammate 1&#34;] T2 --&gt; W2[&#34;Teammate 2&#34;] end subgraph CLAIM[&#34;认领模型（任务池）&#34;] P[&#34;共享任务池&lt;br/&gt;（一张张待领的卡）&#34;] --&gt;|&#34;空闲 agent 自行 claim&#34;| A1[&#34;Agent A&#34;] P --&gt;|&#34;空闲 agent 自行 claim&#34;| A2[&#34;Agent B&#34;] P --&gt;|&#34;空闲 agent 自行 claim&#34;| A3[&#34;Agent C&#34;] end </div> <script type="module"> import mermaid from 'https://cdn.jsdelivr.net/npm/mermaid@11/dist/mermaid.esm.min.mjs'; mermaid.initialize({ startOnLoad: true, theme: 'neutral', securityLevel: 'strict', flowchart: { curve: 'basis' } }); </script> <table> <thead> <tr> <th></th> <th>派单模型</th> <th>认领模型</th> </tr> </thead> <tbody> <tr> <td>谁决定任务归属</td> <td>一个中心 Agent（Leader）</td> <td>空闲的 agent 自己</td> </tr> <tr> <td>任务有没有&quot;在列上等人来抢&quot;的状态</td> <td><strong>没有</strong></td> <td>有</td> </tr> <tr> <td>agent 是长期存活还是被唤起</td> <td>被 Leader 唤起</td> <td>常驻，自行轮询</td> </tr> <tr> <td>新增一个 agent 的成本</td> <td>要改 Leader 的分配逻辑</td> <td>几乎是零</td> </tr> <tr> <td>与&quot;吃满免费额度&quot;的契合度</td> <td>低（Leader 决定谁干活）</td> <td><strong>高（谁有额度谁来接）</strong></td> </tr> </tbody> </table> <p><strong>这个区别对本场景是决定性的。</strong> 因为本场景的动机是&quot;让多个 agent 长时间持续运行、吃满各家免费额度&quot;——这要求系统能<strong>根据 agent 的可用性动态分配任务</strong>，而不是由一个 Leader 预先分好。<strong>认领模型天然适合这件事；派单模型天然不适合。</strong></p>