前言

最近在研究 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