OpenClaw 多 Agent AI 团队搭建与项目开发实战

前言

你可能已经习惯了一个人干所有事：写需求、写代码、写文案、管进度。但如果我说，你可以同时拥有一个项目管理专家、一个全栈开发工程师、一个文案高手、一个数据分析师，而且他们 7×24 待命、秒级响应、从不抱怨呢？

这就是 OpenClaw 多 Agent 架构带来的可能性。

本文将完整分享我们如何：

用 OpenClaw 搭建一个 5 人 AI 团队（含一个「人类」和四个专家 Agent）
让他们通过飞书群聊协作完成一个真实项目——从 PRD 到可运行的看板应用
过程中踩过的坑、总结的经验、以及可复用的方法论

读完本文，你也能搭一支属于自己的 AI 团队。

第一部分搭建你的 AI 团队

1. 为什么需要多 Agent？

你可能会问：一个 ChatGPT 不就够了吗？

不够。原因有三：

第一，角色混乱。你让同一个 AI 又当产品经理又当程序员，它的思维会在「这个需求合不合理」和「这个函数怎么写」之间反复横跳，两件事都做不好。
第二，上下文污染。项目管理的上下文（里程碑、风险日志）和代码的上下文（变量名、依赖版本）完全不同。混在一起，谁都记不清。
第三，并行效率低。一个人干五件事是串行的，五个人各干各的是并行的。

💡 核心思路：让每个 Agent 只扮演一个角色，做一件事，做到极致。

2. 团队成员介绍

我们搭建了一支 5 人团队：

每个 Agent 有独立的：

工作空间：自己的 SOUL.md（人格定义）、AGENTS.md（行为规范）、记忆文件
状态目录：认证信息、会话历史、配置文件
飞书机器人：独立的飞书应用，各有自己的头像和名称

3. 架构设计

核心机制：

确定性路由：飞书消息通过 accountId 自动路由到对应 Agent，不需要猜测
独立工作空间：每个 Agent 的 SOUL.md、记忆、工具配置完全隔离
Agent 间通信：开启 agentToAgent 后，PMBot 可以直接通知 DevBot 加速开发
WebSocket 连接：无需公网 IP，飞书通过 WebSocket 推送消息

4. 搭建步骤

第一步： OpenClaw 初始化

openclaw init

第二步：创建 Agent

openclaw agents add dev

openclaw agents add copy

openclaw agents add data

openclaw agents add pm

每个命令会引导你创建工作空间和 SOUL.md。

第三步：创建飞书应用

在飞书开放平台创建 4 个企业自建应用，每个应用需要：

获取凭证：记录 App ID 和 App Secret
添加权限：im:message、im:message.group_at_msg、im:resource、im:chat、contact:user.id:readonly
启用机器人能力：应用能力 → 机器人 → 开启
配置事件订阅：订阅 im.message.receive_v1
发布应用：创建版本 → 申请上线 → 管理员审批

然后绑定到 OpenClaw：

openclaw channels add feishu

# 按提示输入每个应用的 App ID 和 App Secret

第四步：配置 openclaw.json

{

"agents": {

"list": [

{

"id": "main",

"name": "朱大龙",

"default": true,

"workspace": "D:\\myprog"

{

"id": "dev",

"name": "DevBot 开发助手",

"workspace": "C:\\Users\\lgzhu\\.openclaw\\workspace-dev",

"model": { "primary": "zai/glm-5.1" }

{

"id": "copy",

"name": "CopyBot 文案专家",

"workspace": "C:\\Users\\lgzhu\\.openclaw\\workspace-copy",

"model": { "primary": "zai/glm-5-turbo" }

......

"bindings": [

{ "agentId": "main", "match": { "channel": "feishu", "accountId": "main" } },

{ "agentId": "dev", "match": { "channel": "feishu", "accountId": "dev" } },

{ "agentId": "copy", "match": { "channel": "feishu", "accountId": "copy" } },

......

"tools": {

"profile": "coding",

"agentToAgent": {

"enabled": true,

"allow": ["main", "dev", "copy", "data", "pm"]

}

"channels": {

"feishu": {

"enabled": true,

"connectionMode": "websocket",

"domain": "feishu",

"groupPolicy": "open",

"defaultAccount": "main",

"accounts": {

"main": { "appId": "你的AppID", "appSecret": "你的AppSecret" },

"dev": { "appId": "...", "appSecret": "..." },

"copy": { "appId": "...", "appSecret": "..." },

......

}

第五步：给每个 Agent 写 SOUL.md

SOUL.md 是 Agent 的「灵魂」，定义了它的角色、能力、工作方式和记忆重点。以 PMBot 为例：

# PMBot - 项目管理助手

你是 PMBot，一个项目管理专家。

## 角色定位

- 项目进度跟踪和里程碑管理

- 资源协调和任务分配

- 风险预警和问题升级

## 能力

- 擅长拆解任务和制定计划

- 识别项目风险并提前预警

- 跨团队沟通协调

## 工作方式

- 维护项目看板和待办列表

- 定期检查进度，发现延期风险主动提醒

- 用结构化的方式记录决策和变更

## 记忆重点

- 项目时间线和里程碑

- 任务状态和负责人

- 风险日志和应对措施

第六步：启动验证

# 启动网关

openclaw gateway start

# 检查所有 Agent 状态

openclaw agents list --bindings

# 检查飞书连通性

openclaw channels status --probe

# 配对飞书群聊

openclaw pairing list feishu

openclaw pairing approve feishu <CODE>

在飞书里分别给 4 个机器人发消息，如果它们各自回复了——恭喜，你的 AI 团队已经就位了！🎉

第二部分：实战——10 分钟开发一个看板应用

1. 项目背景

我们的 10 人团队需要一个轻量级任务管理工具。需求很明确：看板视图、拖拽操作、截止日期提醒、移动端可用。

分工：

PMBot 负责撰写 PRD（产品需求文档）
人类（朱大龙）审阅 PRD 并下达开发指令
PMBot 作为项目管理协调开发过程
DevBot/DataBot 执行编码和调试任务

2. 第一步：PMBot 输出 PRD

PMBot 在飞书群里输出了完整的 PRD 文档，包含：

功能需求（看板视图、任务 CRUD、拖拽排序、截止日期提醒、成员管理、移动端适配）
数据模型（精确到 SQL 建表语句）
API 设计（8 个端点，方法 + 路径 + 请求格式）
项目结构（目录树）
技术选型（Flask + SQLite + Tailwind CSS + SortableJS）
非功能需求（浏览器兼容、响应时间、数据容量）

💡 关键经验：PRD 越精确，AI 开发的效率越高。写到 SQL 和 API 路径级别的 PRD，让后续编码几乎没有歧义。

3. 第二步：PMBot 调度开发

人类在飞书群发送指令：

请按 PRD 文件完成项目开发，项目目录：D:\myprog\projects。

PMBot 收到指令后：

读取 PRD 文件
理解全部需求
逐个创建项目文件
调用 Claude Code 或直接写入代码

整个过程约 5-10 分钟，产出了完整的项目结构：

task-board/

├── app.py # Flask 主入口（create_app 工厂模式）

├── config.py # 配置文件

├── models.py # SQLAlchemy 数据模型（Task + Member）

├── routes/

│ ├── __init__.py # 蓝图注册

│ ├── tasks.py # 任务 REST API（5 个端点）

│ └── members.py # 成员管理 API（3 个端点）

├── templates/

│ └── index.html # 单页看板（含 3 个弹窗）

├── static/

│ ├── css/

│ │ ├── tailwind.min.css # 预编译 Tailwind CSS

│ │ └── style.css # 自定义样式（卡片、弹窗、拖拽）

│ └── js/

│ └── app.js # 前端逻辑（SortableJS + API 调用）

├── requirements.txt

├── Dockerfile

└── README.md

2.4 第三步：人类验收 + 反馈

人类在浏览器打开应用进行测试，发现问题：

问题一：「添加成员后弹窗直接退出了」

人类反馈：

可以启动项目，但操作-添加成员后直接退出了，检查原因。

PMBot 立即排查：

启动应用，用 PowerShell 的 Invoke-RestMethod 测试 API → 后端正常
检查前端 JS 代码 → 发现 api() 函数没有错误处理
定位根因：fetch() 返回错误时，JS 抛出未捕获异常，整个交互流程中断

DevBot修复BUG。

问题二：「打开页面非常慢」

人类反馈：

可以正常工作，但打开页面时非常慢，检查原因。

排查发现 HTML 中引用了 Tailwind Play CDN：

这个脚本会在浏览器端实时编译 CSS（下载 300KB+ JS → 扫描 HTML → 生成 CSS），在我国网络环境下延迟被放大。

解决方案：下载预编译 Tailwind CSS 到本地，改用 <link> 标签引入。页面加载时间从 3-5 秒降到 <100ms。

5. 第四步：API 自动化测试

PMBot 用 PowerShell 脚本执行了 10 项 API 测试：

# 1. 添加成员 → 201

Invoke-RestMethod -Uri "http://127.0.0.1:5001/api/members" -Method POST -Body '{"name": "张三"}'

# 2. 获取成员列表 → 200

Invoke-RestMethod -Uri "http://127.0.0.1:5001/api/members" -Method GET

# 3. 创建任务（含截止日期 + 负责人）→ 201

Invoke-RestMethod -Uri "http://127.0.0.1:5001/api/tasks" -Method POST -Body '{"title": "测试任务", "assignee_id": 1, "due_date": "2026-04-03"}'

# 4. 拖拽变更状态 → 200

Invoke-RestMethod -Uri "http://127.0.0.1:5001/api/tasks/1/status" -Method PATCH -Body '{"status": "in_progress"}'

# 5. 删除有任务的成员 → 400（保护性拒绝）✅

# 6. 删除无任务的成员 → 200 ✅

# ...全部通过

6. 交付

从 PRD 到可运行的产品，总耗时约 0.5 小时（含两轮迭代和 Bug 修复）。如果纯人工开发，这个项目预计需要 1-2 天。

第三部分：踩过的坑与解决方案

坑 1：前端 JS 缺少错误处理

症状：用户操作后页面「失灵」，弹窗莫名关闭。

原因：fetch() 返回非 200 时没有 try/catch，JS 执行中断。

解决：所有异步操作统一 try/catch，向用户展示友好错误信息。

启示：AI 生成的代码经常「乐观假设一切正常」。人类审核时必须重点检查错误处理。

坑 2：Tailwind CDN 导致页面极慢

症状：首次打开页面白屏 3-5 秒。

原因：cdn.tailwindcss.com 在浏览器端实时编译 CSS，海外 CDN 在国内延迟严重。

解决：预编译 CSS 下载到本地，用 <link> 引入。

启示：AI 生成的模板代码经常默认使用 CDN 引入。在国内环境下，所有前端依赖应尽量本地化。

坑 3：多弹窗层级互相干扰

症状：确认删除弹窗和编辑弹窗同时出现，ESC 键关错了弹窗。

原因：关闭逻辑没有区分弹窗层级。

解决：ESC 只关闭最顶层可见弹窗，点击 overlay 只关闭当前 overlay。

启示：弹窗管理是前端经典问题，不能只考虑单个弹窗的行为，要考虑组合场景。

坑 4：Windows Shell 兼容性

症状：AI 生成的命令在 Windows PowerShell 中报错。

原因：PowerShell 5.1 不支持 && 语法。

解决：改用分号 ; 连接命令，或在 AGENTS.md 中标注运行环境。

启示：在配置 Agent 时就要写清楚运行环境信息，避免反复踩坑。

坑 5：SQLite 文件被进程锁定

症状：想删除数据库重建，但文件被占用。

解决：先终止 Python 进程再操作数据库文件。生产环境使用 WAL 模式。

启示：开发过程中的状态管理（进程、端口、文件锁）需要纳入 Agent 的知识库。

第四部分核心方法论

1. 文档驱动的协作模型

人类写 PRD → PMBot 审阅/优化 → DevBot 按文档编码 → 人类验收

│

发现问题反馈

│

PMBot 排查修复 ──→ 人类再验收

核心原则：

PRD 即契约 — 产品智能体写清楚，开发智能体照着做，不需要口头沟通

文档 > 对话 — Agent 之间通过文件（PRD、SOUL.md、记忆文件）传递上下文，而非即时对话

快速反馈循环 — 发现问题立即修复，不积累技术债

2. 分层测试策略

第一层：启动测试（1 分钟）

python -c "from app import create_app; create_app()" → 无报错

第二层：API 测试（3 分钟）

POST /api/members → 201

GET /api/tasks → 200

PATCH /api/tasks/1/status → 200

DELETE /api/members/1 → 400（保护性拒绝）

第三层：浏览器测试（5 分钟）

打开页面 → 看板渲染 → 新建任务 → 拖拽 → 编辑 → 删除 → 成员管理

第四层：边界测试（3分钟）

空标题提交 → 报错提示

删除有任务的成员 → 保护性拒绝

网络断开 → 友好提示

3. 人类审核清单

AI 生成代码后，人类必须检查：

□ 应用能否正常启动（无 ImportError）

□ 页面能否正常加载（无白屏、无 JS 报错）

□ 核心流程是否跑通（增删改查 + 拖拽）

□ 错误处理是否完善（网络异常、空输入、非法数据）

□ 响应式布局是否生效（手机端 / 桌面端）

□ 中文内容是否正常显示

□ CDN 依赖是否可访问（国内网络环境）

□ 数据库操作是否有保护（删除保护、输入校验）

4. 「推倒重来」是一种策略

第一版开发有 Bug？别犹豫，直接推倒重写。

对 AI Agent 来说：

重写成本极低：几分钟 vs 人类几天

第二次一定更好：已经踩过坑了，不会再犯

不需要在烂代码上缝缝补补：干净的重写比打补丁更可靠

第五部分：进阶技巧

1. Agent 间通信

开启 agentToAgent 后，Agent 之间可以直接对话：

PMBot 发现项目延期 → 通知 DevBot 加速开发

DevBot 写完功能 → 通知 CopyBot 准备发布文案

DataBot 分析完数据 → 结果同步给 PMBot 做决策

2. 记忆管理

每个 Agent 的记忆是独立的，通过文件系统管理：

短期记忆：memory/YYYY-MM-DD.md（每日笔记）

长期记忆：MEMORY.md（精华摘要）

心跳状态：memory/heartbeat-state.json（定时任务追踪）

建议定期让 Agent 整理记忆：回顾日记 → 提炼要点 → 更新 MEMORY.md。

3. 模型选择策略

不同角色用不同模型可以优化成本：

4. 安全注意事项

App Secret 不要提交到公开仓库

用 allowlist 限制 DM 访问

用 tools.allow/deny 限制各 Agent 的工具权限

不信任的 Agent 可通过 sandbox 提供沙箱隔离

第六部分：日常运维速查

# 检查 Agent 和路由状态

openclaw agents list --bindings

# 重启网关

openclaw gateway restart

# 检查飞书连通性

openclaw channels status --probe

# 查看待配对列表

openclaw pairing list feishu

# 审批配对请求

openclaw pairing approve feishu <CODE>

# 查看实时日志

openclaw gateway logs --follow

结语

多 Agent AI 团队不是一个噱头，而是一个已经被验证有效的开发模式。它的核心不是「让 AI 取代人」，而是「让每个人（包括 AI）专注于自己最擅长的事」。

搭建一个 AI 团队只需要半小时，但带来的效率提升是持续的。从 PRD 到可运行的产品，从天级缩短到小时级——这不是未来，这是现在。

如果你也想搭建自己的 AI 团队，建议从两个 Agent 开始：一个管项目（PMBot），一个写代码（DevBot）。跑通流程后，再逐步扩展。