【独家】6月的更新后,OpenClaw 也有自己的 Kanban 了——而且可视化

小虾也能loop engineering了 ？

先说重点：

– 改 config 后多留意 prompt cache 的变化，有可能造成缓存失效。– Agent 不会纯靠 workboard 里的任务链来实现自动 dispatch 任务，最终搞 loop 还是得用上 claim。

5 月 28 日的更新里，OpenClaw 悄悄上线了一个叫 Workboard 的插件。这个可视化 Kanban 藏在更新日志里，我好奇试了——花 token 踩坑——最终探索出一个可行的自动化流程。

一个真能看到工作状态的看板

之前 Hermes 那种kanban状态管理，只有命令行里一行行文字，得靠脑补。Workboard 直接长在 OpenClaw 的控制面板里——打开就是一个九列看板，卡片能拖，状态能变，agent 能自己领走任务。

九列分别是：

● triage（待分类）：刚扔进来的想法，还没决定做不做

● backlog（堆积）：想做但排不上队，躺着

● todo（待办）：确认要做，等人领

● scheduled（定时）：设了时间，到点自动进入 ready

● ready（就绪）：前置条件满足了，就等有人来领走

● running（执行中）：agent 正在干活

● review（待审核）：干完了，等你检查

● blocked（阻塞）：撞墙了——API 挂了、文件找不到、等别人先完成

● done（完成）：过了，归档

每张卡片有标题、备注、优先级、标签、指派的 agent、链接的 session 和 run。点开已链接 session 的卡片，可以看到对应的执行对话记录。

这个看板也给 agent 自己用。每张卡片背后有一套完整的工具链——workboard_claim、workboard_complete、workboard_heartbeat、workboard_block、workboard_decompose、workboard_link 等等。一个 agent 可以在没人操作的情况下，自己领卡、自己执行、自己交卡。整个流程留在 board 上，每一步都有事件日志。

卡片数据存在本地数据库里，不用怕丢。

指令清单：agent 能怎么用

主 agent 用的

● workboard_create：建一张卡。最基本的操作——填标题、备注、状态、优先级、指派给谁。

● workboard_decompose：把一张大卡拆成子卡。拆完后父卡自动标记完成，子卡自动继承父卡的看板和标签。这是整个流水线的起点——你只要告诉系统”这个任务拆成 A → B → C”，它帮你一次性生成好。

● workboard_link：在两张卡之间建立依赖。比如 B 依赖 A（A 的素材没出来 B 不能开始）。建好依赖后，系统会自动检测——前置任务完成了才把后续任务推到就绪状态。

● workboard_promote：手动把一张卡推到 ready 状态。

● workboard_dispatch（agent 端）：扫一遍看板，把依赖满足的卡推到就绪、把超时的卡标记阻塞、回收没人干的任务。注意——agent 端的 dispatch 能整理板子，但不能启动干活的 worker。启动 worker 需要 user 在控制面板点 Dispatch 按钮。实际启动 worker 仍需用户手动 Dispatch。

干活的 agent 用的

● workboard_claim：领走一张卡。卡片状态变成”执行中”，同时拿到一个领取凭证。别的 agent 没有这个凭证就改不了这张卡——防止抢活。

● workboard_heartbeat：长任务过程中刷新心跳，告诉系统”我还活着，别把我的卡收回去”。

● workboard_complete：干完了，交卡。卡片变成完成状态，系统自动发通知。

● workboard_block：碰到外部问题搞不定了（比如接口报错、超时），主动标记这张卡为阻塞，写清楚原因。不硬撑，不绕路——等人来决定下一步。

● workboard_read / workboard_list：查看一张卡或整个看板的状态。所有 agent 都能用。

跑通的第一种方式：Claim Loop

这是我最早跑通、也是目前最可靠的方式。

流程是这样的：主 agent 建卡 → 拆子卡 → 建依赖链 → 用 sessions_send 通知对应 agent 来领卡 → agent 自己 claim → 执行 → complete → 再把结果 sessions_send 回传给主 agent。

主Agent建卡 → 拆子卡 → 建依赖链          ↓   sessions_send 通知子Agent          ↓    子Agent claim 领走          ↓    执行 → complete 交卡          ↓   sessions_send 回传结果          ↓  主Agent判断是否还有子卡      ↙        ↘   有 → 循环      无 → 完成

全程人不碰（需要详细的prompt设计）——主 agent 在那推着走就行。

优点：agent 以自己的主会话身份执行——它会读自己的性格文件、记忆文件，带着完整的人格干活。如：负责选题的agent 做选题脑暴的时候，是因为它”知道”自己是一个嗅觉敏锐的选题操盘手，带着这个身份在思考。

成本：每次完整的选题流水线（3个agent）不便宜，跑一轮大概6块——主要是因为每通知一次 agent 就要启动一整轮对话。中间有大量的工具调用。最后还有echo要收束。

什么时候用

：高度专注的任务，因为主agent要处理的事情太多了。以及需要 agent 有个性、有判断力的时候。选题、脑暴、写作、任何需要”那个角色”来做的事。

你不在电脑边的时候：完全可以。主 agent 自己就能走完完整的 Claim Loop——建卡、通知 agentb、等它回来、再通知agentc 、等它回来、拿到选题自己写（或者新建一个写作agent）。你只需要说一句”来开个任务板搞一轮写作loop吧。”

跑通之后记得固化成skills。✨

跑通的第二种方式：Dispatch

Dispatch 是 Workboard 自带的自动调度功能。你点一下控制面板的 Dispatch 按钮（或跑 openclaw workboard dispatch），系统自动扫就绪列、挑优先级最高的卡、领走、启动一个轻量级子 agent 去干活。

这个子 agent 跑在一个临时会话下，拿到卡片的上下文和领取凭证，自主执行。一张卡完成之后依赖链自动推进下一张到就绪，你再点一下 Dispatch 就把下一张推走了。

缺点：自动化程度没有claim loop高。人需要在启动当前agent之前点按钮，剩下的系统推，有几个agent干活就要点几次run。

优点：成本低，比 Claim Loop 低3-5倍——子 agent 更轻量，上下文更短，省 token。

踩坑：dispatch 启动的子 agent 目前读不到性格文件（SOUL），只读 agent 的说明文档（AGENTS.md、tools.md）。这意味着”选题军师”人格不会带进去——它只是一个拿着工具干活的执行器，没有那股”嗅觉”。

解法：把性格描述合并到 AGENTS.md 文件里。这个文件子 agent 能读到，格式上也支持放人格描述。没有独立性格文件那么纯粹，但能兜住。效果比完整 SOUL 稍弱，但能大幅改善子 Agent 的一致性。

什么时候用：人在电脑前，有空点”run”。纯数据处理、搬砖型任务、不需要 agent 有个性的场景。或者——在你把性格描述塞进 AGENTS.md 之后——什么任务都行。

就绪卡片 → 人点 Dispatch              ↓    系统挑卡 → 启临时subAgent (不读SOUL)              ↓         执行任务              ↓    依赖链推进，下一张就绪              ↓         还有任务？       ↙          ↘  人再点Dispatch   结束

第三种方式：spawn subagent

这个跟 Workboard 无关，但经常被拿来对比。

sessions_spawn 是让主 agent 直接分出一个临时子 agent 去干活。子 agent 拿到一段指令和工具，跑完把结果交回来。整个过程没有卡片、没有状态流转、没有记录——跑完就消失了。

和 Claim Loop 的区别：Claim Loop 有看板追踪——每张卡的状态、谁领的、什么时候完成的、挂了为什么挂，全部有日志可查。spawn 只有对话记录。

和 Dispatch 的区别：Dispatch 也有卡片追踪，而且依赖链自动推进。spawn 是纯手动——你 fork 一个子 agent 说”干这个”，它干了，你想让它继续往下干？再 fork 一次。

什么时候用：一次性小任务。比如”帮我看一下这个脚本为什么报错”、”读一下这个文件总结给我”。别用它跑流水线——跑完你不知道卡在哪。

主Agent sessions_spawn 分出临时子Agent              ↓      子Agent 执行一次性任务              ↓         结果返回主Agent              ↓            结束     (无卡片，无状态流转，仅对话记录)

相比 Workboard，spawn 模式没有任务板追踪和依赖管理，更适合短平快的一次性任务。

花了多少 token 买到的经验

Claim Loop 跑完一整条”素材→选题→文章”，大量会话互传 + 工具调用 + 3 个 agent，大约 6 块钱。两天的测试花了近百——包括 n 次 dispatch 撞墙、调用太频繁被封接口、两次被 agent 刷屏刷到崩溃😂。

值得吗？搞明白一个能在看板上自己推任务的多 agent 系统——这个价格的学费不算贵。

至少现在我知道什么时候用 Claim Loop、什么时候用 Dispatch、什么时候 spawn 就够了——以及子 agent 没灵魂这件事怎么绕过去。

下一个版本的 Workboard 如果能支持 agent 端 dispatch 自动启动 worker——或者至少让 worker 读到性格文件——这个看板会从”能用”变成”好用”。

在那之前，Claim Loop 是主路，Dispatch 是备胎，spawn 是临时工。

看板已经有了。Loop 已经跑了。路还长，但至少有地图了。

作者lili & Opus地点杭州时间2026 夏