OpenClaw搭建AI特工团队:从单兵作战到协同作战
一个人就是一支队伍?不,你需要的是一个真正的AI特工团队。本文记录我从零搭建多Agent系统的完整过程,包括飞书机器人配置、Agent身份设计、团队协作模式。
为什么需要Agent团队?
单Agent的局限
一开始,我只用了一个AI助手(小柒),问题很明显:
1 2 3 4 5 6 7 8 9
| 用户:帮我开发一个用户登录功能 小柒:好的,我来帮你... [20分钟后] 小柒:这是代码... 用户:等等,你没有先写产品需求文档吗? 小柒:哦对,我应该先写PRD... [又过了10分钟] 用户:代码质量如何?有性能问题吗? 小柒:让我重新审查...
|
问题:
- 😵 身份混乱:一个Agent既要当产品经理,又要当开发,还要当测试
- 🐌 效率低下:上下文频繁切换,每次都要重新理解角色
- 📉 质量不稳定:缺乏专业深度,代码质量、需求质量参差不齐
- 🔀 协作困难:无法像真实团队一样各司其职
多Agent团队的优势
搭建团队后的效果:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
| 用户:帮我开发一个用户登录功能
📋 产品经理Agent: - 需求分析:用户登录、密码加密、Session管理 - 输出PRD文档、流程图、技术选型建议
💻 开发小子Agent: - 技术方案设计:BCrypt加密、Redis Session、JWT Token - 代码实现:Controller + Service + Repository三层架构 - 单元测试:覆盖正常流程、异常场景
🌟 小柒(主Agent): - 统筹协调:分配任务、跟踪进度 - 质量把控:Code Review、测试验收 - 文档输出:技术文档、API文档
|
价值:
- ✅ 专业分工:每个Agent专注自己的领域,深度专业
- 🚀 效率提升:并行工作,整体耗时减少50%
- 📈 质量稳定:专业Agent做专业事,质量更可控
- 🤝 自然协作:像真实团队一样沟通、配合、review
搭建步骤
第一步:飞书机器人配置
OpenClaw通过飞书机器人接收和发送消息,每个Agent对应一个独立的飞书应用。
1. 创建飞书应用
进入飞书开放平台:
-
创建自建应用
- 进入"开放平台" → “创建自建应用”
- 应用名称:如"小柒"、“产品经理”、“开发小子”
- 选择"企业自建应用"
-
配置应用权限
每个应用需要的权限:
- 接收消息:
im:message、im:message:group_at_msg
- 发送消息:
im:message、im:chat
- 获取用户信息:
contact:user.base:readonly
- 文档操作:
docx:document、drive:drive(可选)
-
获取凭证
App ID:如 cli_a93e6a4312b9dbd4
App Secret:在"凭证与基础信息"页面获取
2. 配置事件订阅
在飞书开放平台:
-
启用事件订阅
- 进入"事件订阅" → “配置请求URL”
- 填写OpenClaw的回调地址(如:
https://your-domain.com/feishu/events)
- 订阅事件:
im.message.receive_v1(接收消息)
-
配置机器人入口
- 进入"功能管理" → “机器人”
- 启用"聊天"功能
- 设置描述、头像
3. 测试连接
在飞书中搜索你的机器人,发送测试消息:
如果机器人回复,说明配置成功!
第二步:Agent配置
1. 创建Agent目录结构
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
| ~/.openclaw/agents/ ├── main/ │ ├── agent/ │ │ ├── models.json │ │ └── auth-profiles.json │ └── sessions/ ├── development/ │ ├── agent/ │ │ ├── models.json │ │ └── auth-profiles.json │ └── sessions/ └── product/ ├── agent/ │ ├── models.json │ └── auth-profiles.json └── sessions/
|
2. 创建独立的Workspace
每个Agent有独立的工作空间:
1 2 3 4 5 6 7 8 9
| ~/.openclaw/ ├── workspace/ │ ├── IDENTITY.md │ ├── SOUL.md │ └── MEMORY.md ├── workspace-development/ │ └── IDENTITY.md └── workspace-product/ └── IDENTITY.md
|
3. 定义Agent身份
以开发小子为例:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
| # IDENTITY.md - 开发小子
- **Name:** 开发小子 - **Creature:** 开发工程师 AI - **Vibe:** 专注、高效、技术控 - **Emoji:** 💻
## 我的职责
我是**开发工程师 agent**,专注于技术实现:
- 💻 **代码开发** - 前端、后端、全栈开发 - 🔧 **技术方案** - 架构设计、技术选型 - 🐛 **问题排查** - Bug 修复、性能优化 - 📝 **代码审查** - 代码质量把控
## 我的特长
- 精通多种编程语言和框架 - 熟悉各种开发工具和流程 - 快速理解需求并给出技术方案 - 注重代码质量和最佳实践
## 协作模式
- 接收产品经理的 PRD - 与主 agent 协作完成任务 - 专注技术实现,不涉及需求分析
|
关键设计:
- ✅ 清晰的职责边界:开发只管开发,产品只管需求
- 🎯 明确的协作模式:谁发起、谁接收、谁输出
- 💡 独特的性格设定:Vibe让每个Agent有自己的"个性"
第三步:OpenClaw配置
在~/.openclaw/openclaw.json中配置Agent列表:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69
| { "agents": { "list": [ { "id": "main", "workspace": "/Users/youqi/.openclaw/workspace", "identity": { "name": "小柒", "theme": "AI助手", "emoji": "🌟" }, "tools": { "profile": "full" } }, { "id": "product", "workspace": "/Users/youqi/.openclaw/workspace-product", "identity": { "name": "产品经理", "theme": "产品经理Agent", "emoji": "📋" }, "tools": { "profile": "full" } }, { "id": "development", "workspace": "/Users/youqi/.openclaw/workspace-development", "identity": { "name": "开发小子", "theme": "开发Agent", "emoji": "💻" }, "tools": { "profile": "full" } } ] }, "channels": { "feishu": { "enabled": true, "appId": "cli_a93e6a4312b9dbd4", "appSecret": "xxx", "accounts": { "default": { "dmPolicy": "allowlist", "allowFrom": ["ou_xxx"] }, "product": { "enabled": true, "appId": "cli_a93c7a6cdcf89bcb", "appSecret": "xxx", "dmPolicy": "allowlist", "allowFrom": ["ou_xxx"] }, "development": { "enabled": true, "appId": "cli_a93c7b5ae2385bde", "appSecret": "xxx", "dmPolicy": "allowlist", "allowFrom": ["ou_xxx"] } } } } }
|
关键配置:
- 🔑 每个Agent独立的飞书账号:
appId、appSecret
- 📂 独立的工作空间:避免上下文污染
- 🛡️ 权限控制:
allowFrom控制谁能访问
团队协作模式
模式一:主从协作
适用场景:用户找到主Agent,主Agent协调其他Agent
1
| 用户 → 小柒 → 产品经理 → 小柒 → 开发小子 → 小柒 → 用户
|
流程:
- 用户告诉小柒需求:“我要开发用户登录功能”
- 小柒判断需要需求分析,转给产品经理
- 产品经理输出PRD,给回小柒
- 小柒判断需要开发,转给开发小子
- 开发小子输出代码和测试,给回小柒
- 小柒汇总结果,回复用户
优点:
- ✅ 用户体验好:只需要找一个人
- 🤝 协调有序:主Agent统筹全局
- 📊 进度可控:主Agent跟踪每个环节
模式二:专业对接
适用场景:用户直接找专业Agent
1 2 3 4 5
| 用户 → 产品经理(需求阶段) ↓ 开发小子(开发阶段) ↓ 小柒(验收阶段)
|
流程:
- 用户直接找产品经理聊需求
- 需求明确后,产品经理推荐找开发小子
- 开发完成后,开发小子推荐找小柒验收
- 小柒做最终检查和文档输出
优点:
- 🎯 专业深度:用户直接和专家对话
- 📈 效率高:减少中间环节
- 🧠 知识沉淀:专业Agent积累领域知识
模式三:并联协作
适用场景:复杂任务需要多个Agent并行工作
1 2 3 4 5 6
| → 产品经理(需求分析) 用户 → 小柒 → 开发小子(技术调研) → 测试Agent(测试策略) ↓ 小柒(汇总决策)
|
流程:
- 小柒收到复杂任务
- 小柒同时派任务给产品经理、开发小子、测试Agent
- 三个Agent并行工作
- 小柒汇总三方意见,做最终决策
优点:
- ⚡ 速度快:并行工作,耗时大幅减少
- 🧠 角度全面:产品、技术、测试多维度思考
- 📊 决策质量高:综合多个专业意见
实际效果
案例一:JIRA故障排查
单Agent模式:
1 2
| 用户:线上打印服务故障,帮我排查 小柒:好的...[15分钟后]...这是问题原因
|
多Agent团队:
1 2 3 4 5 6 7 8 9 10 11
| 用户:线上打印服务故障,帮我排查
小柒:收到!我立即组织团队排查 ↓ 产品经理:分析业务影响、用户场景、优先级 ↓ 开发小子:排查日志、定位代码、生成修复方案 ↓ 小柒:汇总报告,给出修复建议
⏱️ 总耗时:3分钟(vs 单Agent 15分钟)
|
案例二:功能开发
单Agent模式:
1 2
| 用户:开发用户登录功能 小柒:好的...[2小时]...这是代码
|
多Agent团队:
1 2 3 4 5 6 7 8 9 10
| 用户:开发用户登录功能
产品经理:输出PRD(需求、流程、技术选型) ↓ 开发小子:技术方案 + 代码实现 + 单元测试 ↓ 小柒:Code Review + 集成测试 + 文档输出
⏱️ 总耗时:1小时(vs 单Agent 2小时) ✅ 质量更高:PRD、CR、文档齐全
|
避坑指南
1. 身份混乱问题
问题:所有Agent都说自己是"小柒"
原因:所有Agent共享workspace/IDENTITY.md
解决:每个Agent创建独立的IDENTITY.md
1 2 3 4
| ~/.openclaw/workspace/IDENTITY.md ~/.openclaw/workspace-product/IDENTITY.md ~/.openclaw/workspace-development/IDENTITY.md
|
2. 消息路由问题
问题:发给产品经理的消息,开发小子收到了
原因:飞书应用的appId配置错误
解决:确保每个Agent的飞书配置独立
1 2 3 4 5 6 7 8 9 10 11 12
| { "accounts": { "product": { "appId": "cli_a93c7a6cdcf89bcb", "appSecret": "xxx" }, "development": { "appId": "cli_a93c7b5ae2385bde", "appSecret": "xxx" } } }
|
3. 权限控制问题
问题:所有人都能直接找产品经理
原因:allowFrom配置过于宽泛
解决:精细控制每个Agent的访问权限
1 2 3 4 5 6 7 8 9
| { "product": { "dmPolicy": "allowlist", "allowFrom": [ "ou_主用户的ID", "ou_核心成员的ID" ] } }
|
总结
搭建AI Agent团队的核心价值:
- 专业分工:每个Agent专注自己的领域
- 高效协作:像真实团队一样沟通、配合
- 质量稳定:专业Agent做专业事
- 扩展性强:随时可以添加新的专业Agent
下一步:
- 📊 监控Agent团队的工作效率
- 🧠 优化协作流程,减少沟通成本
- 🤖 添加更多专业Agent(测试、运维、数据分析)
相关阅读:
项目地址:
OpenClaw搭建AI特工团队:从单兵作战到协同作战