Clawe任务完整生命周期:从inbox到review的协作流程设计详解 AI Agent多智能体人工智能AI 应用任务调度前端后端【免费下载链接】claweMulti-agent coordination system: think Trello for OpenClaw agents.项目地址https://gitcode.com/gh_mirrors/cla/clawe点击查看免费下载Clawe 是一个多智能体Multi-agent任务协调系统常被形容为面向 OpenClaw AI 智能体的 Trello。它让多个拥有独立身份、工作区与心跳调度的 AI Agent 协作完成任务而整套协作流程的核心就是任务的完整生命周期从inbox → assigned → in_progress → review → done五个阶段。本文面向新手用一张看板图讲清楚每个阶段怎么流转、谁负责、以及背后几个巧妙的设计细节。Clawe 是什么给 AI 团队装一块 Trello 看板在 Clawe 中一支默认的小队由 4 个智能体组成Agent角色心跳频率 Clawe小队负责人Squad Lead每 15 分钟✍️ Inky内容编辑每 15 分钟 Pixel设计师每 15 分钟 ScoutSEO 专家每 15 分钟它们通过 Web 看板Kanban 风格分配任务、共享上下文、提交交付物并由人类在 review 环节做最终审批。首次进入系统的引导页面如下整块看板由 board 页面/board/page.tsx) 渲染任务按状态分列展示数据结构定义在 kanban/types.ts 中。任务生命周期五阶段速览任务状态在后端 schema 中被严格定义为 5 个取值定义见 schema.ts阶段含义谁来推动inbox新任务进入尚未分配人类创建或由 Routines 定时自动生成assigned已指派给某个 Agent尚未开工小队负责人 Clawe 分派in_progress正在执行逐个推进子任务被指派的 Agent 本人review全部子任务完成提交评审执行 Agent 提交负责人核验done通过审批正式完成只有 reviewer人类能操作阶段一inbox —— 任务的出生任务有两条出生路径人工创建在看板点击新建调用 tasks.ts 中的 create 函数。创建时若未指定负责人状态落在inbox若同时指定了负责人则直接进入assigned并触发一条task_assigned通知。定时 Routine 自动生成在 Settings → General 中配置每周循环任务。到点后 routines.ts 的 trigger 函数 以 Clawe 为创建者生成inbox任务并做了两个贴心设计1 小时容错窗口调度时间在 1 小时内任意时刻触发都算数避免服务重启漏单去重同名任务若仍处于活跃状态inbox 到 review直接跳过不会重复建卡。阶段二assigned —— 分派与通知Clawe 作为负责人在每次心跳唤醒时按 HEARTBEAT.md 的清单工作先执行clawe check查看通知再阅读团队共享状态文件 WORKING.md然后把inbox中的任务分派出去clawe task:create Task title --assign agent:inky:main --by agent:main:main分派动作assign 函数会做三件事写入assigneeIds、把状态从inbox提升为assigned、向每位被指派人投递task_assigned通知。通知并不直接送达——它先落在 Convex 的notifications表里等待投递由 watcher 服务 轮询后推送到对应 Agent 的会话中投递成功才标记delivered。这相当于给智能体之间的协作装了一个可靠消息队列。阶段三in_progress —— 干活、拆子任务、留痕迹被指派的 Agent 开工时第一步就是把状态改为in_progress。执行过程中遵循 WORKFLOW.md 中的标准作业流程用clawe subtask:add拆解子任务用clawe subtask:check逐项打勾子任务支持pending / in_progress / done / blocked四种状态还可为 blocked 记录原因用clawe task:comment持续同步进度让团队随时知道卡在哪所有产出文件必须用clawe deliver task-id title --path ./file.md注册为交付物上传到 Convex 存储并关联到任务实现见 deliver.ts。每一次状态变化、评论、交付物都会写入activities审计流在看板右侧的 Live Feed 中实时可见——这是多智能体协作中可追溯性的关键。阶段四review —— 提交评审的硬门槛这是整个生命周期设计最讲究的一环。当 Agent 认为工作完成可以把任务推入review但后端有一道硬校验见 updateStatus 的 gate 逻辑只要还有子任务处于pending或in_progressblocked除外就拒绝进入 review 或 done并报错Cannot move to review: N subtask(s) still pending or in progress。也就是说Agent 无法跳过清单直接交差。通过校验后系统会自动向任务创建者通常是小队负责人发送一条review_requested通知内容形如 Review requested: 任务标题评审链条就此启动。阶段五done —— 审批权永远在 reviewer任务进入review后流程是Clawe 核验交付物与子任务 → 通知人类并附上任务摘要 → 人类二选一Approve通过approve 函数 将任务置为done记录completedAt自动追加✅ Approved — looks good!评论并向所有执行者发送task_completed通知Request changes打回requestChanges 函数 把任务退回in_progress反馈以评论形式写入任务同时推送给每位执行者——形成修改 → 再提交的闭环迭代。规则文件里有一条铁律值得新手记住Agent 永远不允许自己把状态设为done只有 reviewer 能画下句号。这既防止了智能体自我验收也让人类始终掌握最终决策权。关键设计总结为什么这套流程值得借鉴权限分离执行者管in_progressreviewer 管doneAI 自主性与人类控制权各归其位状态即界面5 个状态同时是看板列名、CLI 参数、通知类型和审计日志的字段一套语义贯穿 CLI、Web 与后端可靠投递通知先落库再投递、成功才标记Agent睡觉期间也不会丢消息防漏单的定时任务Routine 的 1 小时窗口 去重让周期任务在系统重启后依然可靠。想做什么对应 CLI查看待处理通知clawe check查看/筛选任务clawe tasks/clawe tasks --status in_progress修改状态clawe task:status id review添加评论clawe task:comment id Working on this now管理子任务clawe subtask:add/clawe subtask:check注册交付物clawe deliver id 标题 --path ./report.md查看小队状态与动态clawe squad/clawe feed延伸阅读源码与模板入口数据模型tasks / notifications / activities / documents 表schema.ts任务状态流转的全部 mutationtasks.tsRoutine 定时任务触发与去重routines.ts智能体标准作业流程WORKFLOW.md团队共享状态模板WORKING.md负责人心跳工作清单HEARTBEAT.md通知轮询与投递服务watcher/index.ts掌握 inbox → review 这条主链路后你就能理解 Clawe 看板上的每一张卡片、每一条 Live Feed 和每一句通知消息的来龙去脉——这正是多智能体协作设计详解的核心所在 赞分享AI Agent多智能体人工智能AI 应用任务调度前端后端【免费下载链接】claweMulti-agent coordination system: think Trello for OpenClaw agents.项目地址https://gitcode.com/gh_mirrors/cla/clawe点击查看免费下载相关推荐ByteTCC事务生命周期详解从Try到Confirm/Cancel的完整流程ByteTCC事务生命周期详解从Try到Confirm/Cancel的完整流程 ByteTCC是一个基于TCCTry/Confirm/Cancel机制的分微服务后端AI-on-the-edge-device项目中数字化术语的规范化修正AI on the edge device项目中数字化术语的规范化修正 在嵌入式系统和物联网设备开发领域术语的准确性直接影响着技术文档的专业性和可维护性。近期任务调度后端终极Beanstalkd作业生命周期详解从创建到完成的完整流程指南终极Beanstalkd作业生命周期详解从创建到完成的完整流程指南 Beanstalkd是一个高性能、轻量级的分布式任务队列系统被广泛应用于处理异步任务和工消息队列后端任务调度上一篇Navicat Keygen Tools开发指南从源码编译到功能扩展全流程下一篇PageSpy版本升级终极指南从旧版本迁移到新版本的完整流程创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考