用 OpenClaw 搭建多 Agent 协作开发系统

本文摘要

分享如何用 OpenClaw 搭建一个主调度+多子 Agent 的协作开发系统，实现 QT C++ 桌面项目的需求分析、架构设计、任务分配和代码审查全流程自动化。

背景

在开发 QT C++ 桌面应用时，一个常见痛点是：一个人要同时扮演产品经理、架构师、后端开发、UI 开发、测试工程师等多个角色。虽然作为全栈开发者可以胜任，但效率并不高。

OpenClaw 的多 Agent 架构为这个问题提供了一个优雅的解决方案——让不同的 AI Agent 各司其职，由一个主调度 Agent 协调全局。

系统架构

角色分工

Agent	角色	职责	模型偏好
M4-mini (主调度)	架构/产品经理	需求分析、架构设计、任务分配、代码审查	GLM
agent2	后端/业务逻辑	models、services、repositories、db	Codex
agent3	UI 开发	ui、views、dialogs、widgets、QML	Gemini
agent4	测试/集成	tests、CMakeLists、bugfix	Claude

协作方式

主调度通过飞书群协调子 Agent，使用 sessions_send 精准派发指令到各 Agent 的会话，避免了群内 Bot 消息互相不可见的问题。

关键设计原则

1. 串行为主，必要时并行

需求分析 → 架构设计 → 接口定义 → [并行] 后端开发 + UI 开发 → 集成测试

只有完全不相关的任务才并行执行，避免合并冲突。

2. ACP 优先的代码修改

修改代码文件时，优先使用 ACP（Agent Communication Protocol）通过 sessions_spawn + runtime="acp" 派发给编码 Agent，而非直接 edit 工具。这样：

代码修改有完整的上下文
可以利用 Codex/Claude Code 的专业编码能力
主调度保持轻量，只做协调

3. 精准派发，避免重复催促

飞书默认屏蔽 Bot 间消息，所以必须通过 sessions_send 在后台精准派发指令。一个重要的经验是：一轮话题只发一次，等回复后再跟进。连续催促会导致模型倾向沉默。

4. 明确的文件边界

每个 Agent 有自己的文件操作范围，跨边界操作必须由主调度协调：

docs/, design/, README    → M4-mini
models/, services/, db/    → agent2
ui/, views/, widgets/      → agent3
tests/, CMakeLists         → agent4

任务分配模板

派发任务时包含以下要素：

项目背景 — 为什么做这个
任务描述 — 具体做什么
自律要求 — 不要越界操作其他 Agent 的文件
交付要求 — 产出物和标准
容错规则 — 遇到问题怎么处理

示例

## 任务：实现用户登录模块

### 背景
项目需要用户认证功能，支持本地数据库存储凭据。

### 任务描述
1. 创建 LoginService 类，处理认证逻辑
2. 创建 UserRepository，操作用户数据表
3. 编写对应的单元测试

### 自律要求
- 仅操作 models/ 和 services/ 目录
- 不要修改 UI 相关文件
- 遵循项目现有的代码风格

### 交付要求
- 代码通过编译
- 单元测试覆盖核心逻辑
- 完成后回复实现方案

### 容错规则
- 如果遇到架构问题，先回复讨论再动手
- 不要自行决定接口变更

消息过滤规则

主调度需要智能判断哪些消息需要回复：

消息类型	处理方式
用户的指示或问题	✅ 回复
子 Agent 的进度汇报	按需回复（需要协调时）
子 Agent 求助或阻塞	✅ 回复并协调
纯汇报性消息	NO_REPLY
心跳/系统消息	NO_REPLY