Posts
read more
给本地 Agent 造一块看板（一）：总览——看板只是壳，调度与验收才是本体
给本地 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
这张分层图是本系列的评价基准。后面每篇都会用同一把尺子去量不同项目。