企业官网建设流程全解析

• AI Agent
• 多智能体
• 人工智能
• AI 应用
• 任务调度
• 前端
• 后端

Clawe 是一个多智能体（Multi-agent）任务协调系统，常被形容为"面向 OpenClaw AI 智能体的 Trello"。它让多个拥有独立身份、工作区与心跳调度的 AI Agent 协作完成任务，而整套协作流程的核心，就是任务的完整生命周期：从inbox → assigned → in_progress → review → done五个阶段。本文面向新手，用一张看板图讲清楚每个阶段怎么流转、谁负责、以及背后几个巧妙的设计细节。

Clawe 是什么：给 AI 团队装一块 Trello 看板

在 Clawe 中，一支默认的"小队"由 4 个智能体组成：

它们通过 Web 看板（Kanban 风格）分配任务、共享上下文、提交交付物，并由人类在 review 环节做最终审批。首次进入系统的引导页面如下：

整块看板由 board 页面/board/page.tsx) 渲染，任务按状态分列展示，数据结构定义在 kanban/types.ts 中。

任务生命周期五阶段速览

任务状态在后端 schema 中被严格定义为 5 个取值，定义见 schema.ts：

阶段一：inbox —— 任务的出生

任务有两条出生路径：

1. 人工创建：在看板点击新建，调用 tasks.ts 中的 create 函数。创建时若未指定负责人，状态落在inbox；若同时指定了负责人，则直接进入assigned并触发一条task_assigned通知。
2. 定时 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_progress（blocked除外），就拒绝进入 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 能画下句号。这既防止了智能体"自我验收"，也让人类始终掌握最终决策权。

关键设计总结：为什么这套流程值得借鉴

1. 权限分离：执行者管in_progress，reviewer 管done，AI 自主性与人类控制权各归其位；
2. 状态即界面：5 个状态同时是看板列名、CLI 参数、通知类型和审计日志的字段，一套语义贯穿 CLI、Web 与后端；
3. 可靠投递：通知先落库再投递、成功才标记，Agent"睡觉"期间也不会丢消息；
4. 防漏单的定时任务：Routine 的 1 小时窗口 + 去重，让周期任务在系统重启后依然可靠。

延伸阅读：源码与模板入口

• 数据模型（tasks / notifications / activities / documents 表）：schema.ts
• 任务状态流转的全部 mutation：tasks.ts
• Routine 定时任务触发与去重：routines.ts
• 智能体标准作业流程：WORKFLOW.md
• 团队共享状态模板：WORKING.md
• 负责人心跳工作清单：HEARTBEAT.md
• 通知轮询与投递服务：watcher/index.ts

掌握 inbox → review 这条主链路后，你就能理解 Clawe 看板上的每一张卡片、每一条 Live Feed 和每一句通知消息的来龙去脉——这正是多智能体协作"设计详解"的核心所在 🦞

• AI Agent
• 多智能体
• 人工智能
• AI 应用
• 任务调度
• 前端
• 后端