夜雨聆风前言
最近在研究 OpenClaw 的多 Agent 能力，尝试用多个 AI Agent 模拟真实公司的协作架构：CEO 负责接收需求、拆解任务，各部门 Agent 负责专业执行。
效果出乎意料地好，忍不住写篇文章分享出来。
一、为什么需要多 Agent 协作？
单一 Agent 的问题：
什么都得会，但什么都做不到极致 产品经理的思维和技术方案混在一起 角色模糊，输出不够专业
多 Agent 的优势：
每个 Agent 有明确角色和专业边界 可以用不同的模型处理不同任务 真实模拟公司协作流程
二、整体架构设计
用户（飞书群聊）
│
├── @CEO 机器人 → CEO Agent（任务中枢）
│ ├── 分析需求
│ ├── 拆解任务
│ └── 汇总结果
│
├── @产品部 机器人 → 产品部 Agent
│ ├── 撰写 PRD
│ └── 设计原型
│
└── @开发部 机器人 → 开发部 Agent
├── 技术方案
└── 代码实现
核心思路
一个飞书 App 对应一个 Agent，通过 OpenClaw 的多账号 + 路由机制实现精准分发。
三、技术实现
1. 核心配置结构
{
// 飞书多账号配置
"channels":{
"feishu":{
"accounts":{
"ceo":{
"appId":"飞书应用1的AppID",
"appSecret":"飞书应用1的Secret"
},
"development":{
"appId":"飞书应用2的AppID",
"appSecret":"飞书应用2的Secret"
},
"product":{
"appId":"飞书应用3的AppID",
"appSecret":"飞书应用3的Secret"
}
}
}
},
// Agent 路由绑定
"bindings":[
{"agentId":"ceo","match":{"channel":"feishu","accountId":"ceo"}},
{"agentId":"development","match":{"channel":"feishu","accountId":"development"}},
{"agentId":"product","match":{"channel":"feishu","accountId":"product"}}
],
// 启用 Agent 间通信
"tools":{
"agentToAgent":{
"enabled":true,
"allow":["ceo","product","development"]
}
}
}
2. Agent 角色配置
每个 Agent 有独立的工作区和角色定义：
~/.openclaw/agents/
├── ceo/
│ └── workspace/
│ ├── SOUL.md # 核心原则
│ ├── IDENTITY.md # 身份设定
│ └── USER.md # 协作对象
├── development/
│ └── workspace/
│ ├── SOUL.md
│ ├── IDENTITY.md
│ └── USER.md
└── product/
└── workspace/
├── SOUL.md
├── IDENTITY.md
└── USER.md
3. CEO 的 SOUL.md 示例
# CEO 核心原则
## 职责定位
- 接收并分析用户需求
- 判断任务类型，拆解子任务
- 分派给对应部门 Agent
- 汇总各部门结果，形成完整方案
## 部门职责
- 产品部 (product): PRD、原型、需求分析
- 开发部 (development): 技术方案、代码实现
- 设计部 (design): UI/UX 设计
- 市场部 (marketing): 推广策略、内容运营
## 工作流程
1. 接收需求 → 分析本质
2. 拆解任务 → 确定部门
3. 委派执行 → sessions_send
4. 汇总结果 → 反馈用户
## 沟通风格
- 专业但不冷漠
- 决策清晰有依据
- 适时汇报进度
四、Agent 间如何通信？
核心工具是 sessions_send，让 Agent 可以互相发送消息：
# CEO 向产品部发送任务
sessions_send(
sessionKey="agent:product:main",
message="""
@产品部 [设计新功能流程]
需求：用户反馈收集系统
目标：
1. 创建用户友好的反馈入口
2. 支持截图和文字描述
3. 反馈自动分类
交付物：PRD 文档 + 流程图
截止时间：24小时
"""
)
# CEO 向开发部发送任务
sessions_send(
sessionKey="agent:development:main",
message="""
@开发部 [技术方案设计]
需求：用户反馈收集系统
请评估：
1. 技术可行性和实现复杂度
2. 建议的技术栈
3. 接口设计思路
4. 预估工期
截止时间：12小时
"""
)
五、飞书机器人创建步骤
步骤 1：创建多个飞书应用
在飞书开放平台创建多个企业自建应用：
CEO 机器人 产品部机器人 开发部机器人
步骤 2：配置应用权限
每个应用需要开通：
机器人能力 接收消息权限 发送消息权限
步骤 3：获取凭证
在应用详情页获取：
App ID App Secret
步骤 4：添加到配置
将上述凭证填入 OpenClaw 配置的 channels.feishu.accounts中。
六、使用效果
实测案例
用户需求：「我们需要一个用户反馈收集系统」
CEO 处理流程：
[用户] @CEO 我们需要一个用户反馈收集系统
[CEO] 收到需求，正在分析...
[CEO] @产品部 请设计反馈收集流程和界面原型
[CEO] @开发部 请评估技术方案和工期
[产品部] 任务已接收，预计24小时交付 PRD
[开发部] 技术方案已完成，详见附件
最终输出：CEO 汇总产品部和开发部的方案，形成完整的产品+技术方案。
优势体验
七、常见问题
Q1：需要几个飞书应用？
至少需要 1 个，最多可以每个 Agent 独立一个。建议：
简单场景：1 个应用 + 路由规则 复杂场景：每个 Agent 独立应用
Q2：Agent 之间会冲突吗？
不会。通过 bindings精确路由，每个消息只会被一个 Agent 处理。
Q3：如何避免重复响应？
按群聊绑定：一个群只放对应机器人 按账号绑定：每个机器人对应独立飞书账号 配置 groupPolicy: "allowlist"限制群聊范围
Q4：支持多少个 Agent？
OpenClaw 支持无限个 Agent，建议：
核心流程：3-5 个（效率最高） 完整公司：7-10 个（覆盖主要部门）
八、下一步
目前完成了基础框架，还有一些可以探索的方向：
[ ] 完善 Agent 的人设和知识库 [ ] 添加设计部、市场部等其他部门 [ ] 实现更复杂的任务依赖和审批流程 [ ] 接入更多渠道（Telegram、Discord 等）
结语
多 Agent 协作让 AI 不再是单打独斗的工具人，而是可以像真实团队一样协作的智能体。
如果你也对这个方向感兴趣，欢迎交流探讨。
相关工具：
OpenClaw: https://github.com/... 飞书开放平台: https://open.feishu.cn/app
