给本地 Agent 造一块看板（一）：总览——看板只是壳，调度与验收才是本体

Thu, 08 Oct 2026 21:45:00 +0800

给本地 Agent 造一块看板（一）：总览——看板只是壳，调度与验收才是本体

本系列共八篇，用同一套评价框架横向解剖 20 个开源任务看板 / 编排项目。所有仓库元数据（星数、许可证、最近提交时间、仓库体量、创建时间）均于 2026-10-08 通过 GitHub REST API 一手核验，不采信二手索引站与聚合博客。本系列刻意区分「架构设计」与「工程成熟度」，对明星项目同样保留独立判断。

一、场景：一句话的需求，七层的实现难度

先把需求写清楚：

人在一块看板上发布任务 → 本机的多个 coding agent（CodeBuddy / Codex / Trae / CodeArts 之类）定时扫描看板 → 自动领取并完成 → 持续产出可复用的资料或信息 → 由此把各家的免费额度用满。

这个描述里最容易被抓住的关键词是看板。于是绝大多数调研都会从「找一个开源看板」开始——我第一轮也是这么做的，然后发现结论很别扭：看起来功能最全的几个项目，恰恰都不能自主干活；而真能自主干活的，看板又都很简陋。

问题出在提问方式。看板只是这套系统里最外面的一层壳。 把需求拆开会发现，真正决定"能不能无人值守长跑"的，是底下那几层：

#	能力层	验收口径（做到什么算覆盖）
C1	看板呈现	人可读写任务、状态可视、最好有终端或 Web UI
C2	原子领取与互斥	多方同时取单不丢更新；有 WIP 上限；claim 有租约、超时能回收
C3	定时扫描与心跳	有守护进程或周期扫描；agent 存活可判定；无任务时正确挂起而非空转
C4	异构 agent 驱动	能统一调起多类本地 CLI 的 headless 入口；能探测各自能力差异
C5	执行隔离	每任务独立工作目录（worktree / 沙箱），失败可回滚
C6	产出回收与验收	交付物有约定落点；有质量门；不合格能自动派生补做任务
C7	额度感知调度	「剩余额度 → 派给谁 → 耗尽切换或排队」的闭环

graph TB subgraph SHELL["外面这层：看得见的"] C1["C1 看板呈现<br/>拖拽、列、评论、历史"] end subgraph FRAME["中间这层：决定能不能跑"] C2["C2 原子领取 + 租约"] C3["C3 定时扫描 + 心跳"] C5["C5 执行隔离"] end subgraph CORE["里面这层：决定能不能长期跑出东西"] C4["C4 异构 Agent 驱动"] C6["C6 产出验收 + 质量门"] C7["C7 额度感知调度"] end C1 --> C2 --> C3 --> C4 C4 --> C5 --> C6 --> C7

这张分层图是本系列的评价基准。后面每篇都会用同一把尺子去量不同项目。

Kanban on CAO ZUOHUA

给本地 Agent 造一块看板（一）：总览——看板只是壳，调度与验收才是本体

给本地 Agent 造一块看板（一）：总览——看板只是壳，调度与验收才是本体

一、场景：一句话的需求，七层的实现难度