一个 OpenClaw 实例跑 3 个 Agent：电商多角色助手配置实战（附飞书接入）
本文是「OpenClaw 云上实战指南」系列第 4 篇。第 1 篇讲了 Bedrock + IAM 零密钥部署，第 2 篇讲了 Mac + iMessage 接入，第 3 篇讲了龙虾自己开服务器。这篇搞一件不一样的事——在同一个 OpenClaw 实例里跑 3 个不同角色的 Agent，分别对接不同的飞书群。
问题：一个龙虾不够用
前几篇都是"一个实例一个 Agent"的模式。但实际业务场景里，团队需要不止一个 AI 助手：
- 销售群想要一个能查销售额、订单趋势的助手
- 售后群想要一个能处理退款、查工单的助手
- 运营群想要一个能监控库存、推日报的助手
你可以开 3 台服务器跑 3 个 OpenClaw 实例。但那是浪费——一个实例完全可以跑多个 Agent，各自有独立的人格、技能和对话历史。
最终效果
配完之后是这样的：
| 飞书群 | 对应 Agent | 人格 | 核心技能 |
|---|---|---|---|
| 销售讨论群 | sales | 热情、数据驱动 | 销售额查询、订单分析、退货率 |
| 售后工单群 | support | 耐心、专业 | 退款处理、工单状态、客诉分类 |
| 运营日报群 | ops | 简洁、效率导向 | 库存预警、补货建议、每日报表 |
三个群 @ 同一个飞书 Bot，但回复风格和能力完全不同。用户感知是三个独立的助手，实际上是一个进程。
第 1 步：创建 Workspace 目录
每个 Agent 需要一个独立的 Workspace。这是 OpenClaw 隔离多 Agent 能力和人格的核心机制——不同 Workspace 下的SOUL.md、skills/、USER.md互相独立。
# 在你的 OpenClaw 项目根目录下 mkdir -p /data/workspace-sales/skills mkdir -p /data/workspace-support/skills mkdir -p /data/workspace-ops/skills写人格文件
销售助手 SOUL.md：
cat > /data/workspace-sales/SOUL.md << 'EOF' # 销售助手 你是电商团队的销售数据分析助手。 ## 风格 - 回复简洁，先给数据再给分析 - 用百分比和趋势描述变化（"环比增长 12%"） - 主动发现异常："注意，华东区退货率比上周高了 3 个点" ## 边界 - 只回答销售相关问题 - 不处理售后和退款 - 数据来源是平台 API，不要编造数字 EOF售后客服 SOUL.md：
cat > /data/workspace-support/SOUL.md << 'EOF' # 售后客服 你是电商团队的售后处理助手。 ## 风格 - 耐心，不急躁 - 先确认问题，再给方案 - 涉及退款金额时给出明确数字和操作步骤 ## 边界 - 只处理售后相关：退款、换货、工单、客诉 - 不回答销售数据问题 - 超过授权金额的退款，提醒用户找主管审批 EOF运营助手 SOUL.md：
cat > /data/workspace-ops/SOUL.md << 'EOF' # 运营助手 你是电商团队的运营监控助手。 ## 风格 - 能用数字说的不用文字 - 预警信息标红标粗 - 主动推送，不等人问 ## 边界 - 关注库存、物流、补货 - 不处理销售分析和售后 - 发现异常数据立即通知 EOF第 2 步：写 Skill 文件
Skill 是 Markdown 文件，放在各 Agent 的skills/目录下。OpenClaw 会自动加载并编译进该 Agent 的 System Prompt。
销售助手的核心 Skill：
cat > /data/workspace-sales/skills/sales-query/SKILL.md << 'EOF' # 销售数据查询 ## 触发条件 用户问销售相关问题：销售额、订单量、退货率、GMV、客单价、转化率 ## 执行方式 通过平台 API 获取数据： ### 查询今日销售概况 ```bash curl -s -H "Authorization: Bearer $SHOP_TOKEN" \ "$SHOP_API/v1/orders/stats?date=$(date +%Y-%m-%d)" | jq '{ total_orders: .data.order_count, total_amount: (.data.total_amount / 100 | tostring + " 元"), avg_price: (.data.avg_amount / 100 | tostring + " 元"), return_rate: (.data.return_rate | tostring + "%") }'查询指定日期范围的趋势
curl -s -H "Authorization: Bearer $SHOP_TOKEN" \ "$SHOP_API/v1/orders/trend?start=$START&end=$END" | jq '.data[] | { date: .date, orders: .order_count, amount: (.total_amount / 100) }'输出格式
- 先报数字，再给同比/环比
- 发现异常（如退货率 > 5%）主动标出 EOF
**运营助手的库存预警 Skill：** ```bash cat > /data/workspace-ops/skills/inventory-alert/SKILL.md << 'EOF' # 库存预警 ## 触发条件 - 用户问库存情况 - 定时任务触发（Cron 调度） ## 执行方式 ```bash # 获取低于安全库存的 SKU curl -s -H "Authorization: Bearer $SHOP_TOKEN" \ "$SHOP_API/v1/inventory/alerts" | jq '.data[] | select(.stock < .safety_stock) | { sku_id: .sku_id, name: .product_name, stock: .stock, safety: .safety_stock, gap: (.safety_stock - .stock) }'输出格式
- 按缺口大小排序
- 缺口超过安全库存 50% 的标为"紧急"
- 给出补货建议数量（= 安全库存 × 2 - 当前库存） EOF
--- ## 第 3 步：配置 openclaw.json 这是核心配置——定义 Agent 列表和路由规则： ```json { "ai": { "provider": "amazon-bedrock", "model": "us.anthropic.claude-sonnet-4-6", "auth": "aws-sdk" }, "agents": { "list": [ { "id": "sales", "name": "销售助手", "workspace": "/data/workspace-sales" }, { "id": "support", "name": "售后客服", "workspace": "/data/workspace-support" }, { "id": "ops", "name": "运营助手", "workspace": "/data/workspace-ops" } ] }, "bindings": [ { "match": { "channel": "feishu", "peer": { "kind": "group", "id": "oc_sales_group_id" } }, "agentId": "sales" }, { "match": { "channel": "feishu", "peer": { "kind": "group", "id": "oc_support_group_id" } }, "agentId": "support" }, { "match": { "channel": "feishu", "peer": { "kind": "group", "id": "oc_ops_group_id" } }, "agentId": "ops" } ], "channels": { "feishu": { "enabled": true, "accounts": [{ "appId": "cli_your_app_id", "appSecret": "your_app_secret" }], "dmPolicy": "open", "groupPolicy": "open", "requireMention": true } }, "session": { "dmScope": "per-peer" } }几个关键点：
bindings是路由核心：飞书群 ID → Agent ID 的映射。不同群的消息自动路由到不同 AgentrequireMention: true：群里必须 @ Bot 才响应，避免刷屏dmScope: per-peer：同一个群里不同人的对话自动隔离，session 互不串扰- 三个 Agent 共享一个 Bedrock 后端，模型调用走 IAM 角色认证，配置里没有任何密钥
怎么拿飞书群 ID？在飞书群设置 → 群信息 → 群 ID（oc_开头的那串）。
第 4 步：接入飞书
OpenClaw 对飞书的接入方式是出站 WebSocket——不需要公网 IP，不需要 Webhook。
4.1 创建飞书应用
- 打开 飞书开放平台 → 创建企业自建应用
- 记下 App ID 和 App Secret
- 添加权限：
im:message— 获取消息内容im:message:send_as_bot— 以 Bot 身份发消息im:chat:readonly— 读取群信息- 开启Bot 能力
4.2 启动 OpenClaw
# 确保 openclaw.json 已配置好飞书凭证 openclaw gateway start # 看日志确认连接成功 tail -f ~/.openclaw/logs/gateway.log | grep feishu # 期望输出： # [feishu] WebSocket connected to wss://open.feishu.cn/... # [feishu] Bot info loaded: open_id=ou_xxxxx4.3 配置事件订阅
⚠️ 顺序很重要：必须先启动 OpenClaw（WebSocket 连上），再去飞书开放平台配置事件订阅。否则飞书会报连接失败。
- 回到飞书开放平台 → 事件与回调 → 添加事件
- 订阅
im.message.receive_v1 - 发布应用版本
4.4 把 Bot 拉进飞书群
把 Bot 分别拉进销售群、售后群、运营群。在群里 @ Bot 说句话测试：
@销售助手 今天卖了多少？如果配置正确，销售群里会收到salesAgent 的回复，售后群里会收到supportAgent 的回复——人格和技能完全不同。
第 5 步：加上定时推送
运营助手光被动回答不够，还要主动推信息。在openclaw.json里加 Cron：
{ "cron": { "jobs": [ { "id": "morning-report", "schedule": "0 9 * * *", "agentId": "ops", "task": "生成昨日运营日报，包含：销售额、订单量、退货率、低库存 SKU 清单，推送到运营群", "channel": "feishu", "target": "group:oc_ops_group_id" }, { "id": "stock-check", "schedule": "every 4h", "agentId": "ops", "task": "检查库存，如有 SKU 低于安全库存线，立即推预警消息", "channel": "feishu", "target": "group:oc_ops_group_id" } ] } }效果：每天早上 9 点运营群自动收到日报，每 4 小时检查一次库存。运营人员不需要主动问，关键信息自动送达。
进阶：多租户 SaaS 化
上面是"一个团队用"的场景。如果你是电商平台方，想给每个卖家都提供 AI 助手呢？
思路是一商户一实例，用容器编排：
# docker-compose.yml — 单个卖家的 Agent 实例 version: '3' services: openclaw: image: openclaw/openclaw:latest environment: - SELLER_ID=${SELLER_ID} volumes: - ./workspace-${SELLER_ID}:/data/workspace restart: always mem_limit: 512m用 Amazon ECS 或 EKS 管理这些容器，CloudFormation 模板化部署，新商户开通分钟级完成。所有实例共享一个 Bedrock 模型后端（按量付费），数据通过独立 Workspace 目录天然隔离。
这种模式的好处是隔离性强——一个商户的 Agent 出问题不影响其他商户。坏处是资源利用率不如共享进程高，但在 Agent 场景下（主要消耗模型调用，不是 CPU/内存），这个代价可以接受。
小结
一个 OpenClaw 实例跑 3 个 Agent 的配置，总共改了这些东西：
新增文件： /data/workspace-sales/SOUL.md /data/workspace-sales/skills/sales-query/SKILL.md /data/workspace-support/SOUL.md /data/workspace-support/skills/ticket-handler/SKILL.md /data/workspace-ops/SOUL.md /data/workspace-ops/skills/inventory-alert/SKILL.md 修改文件： openclaw.json ← 加了 agents.list + bindings + cron不需要写任何后端代码。Skill 是 Markdown，人格是 Markdown，路由是 JSON 配置。整个过程是"配置驱动"的，不是"开发驱动"的。这是 OpenClaw 做多 Agent 场景和传统 Function Calling 方案的本质区别。
完整的架构设计和部署模式分析，参考亚马逊云科技官方博客的深度解析文章。
本系列其他文章：-第 1 篇：Bedrock + IAM 零密钥部署-第 2 篇：Mac + iMessage 接入-第 3 篇：龙虾自己开服务器-第 5 篇：从本地到云：迁移踩坑实录（完结篇，即将发布）
