一个 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.mdcat /data/workspace-sales/SOUL.md EOF # 销售助手 你是电商团队的销售数据分析助手。 ## 风格 - 回复简洁先给数据再给分析 - 用百分比和趋势描述变化环比增长 12% - 主动发现异常注意华东区退货率比上周高了 3 个点 ## 边界 - 只回答销售相关问题 - 不处理售后和退款 - 数据来源是平台 API不要编造数字 EOF售后客服 SOUL.mdcat /data/workspace-support/SOUL.md EOF # 售后客服 你是电商团队的售后处理助手。 ## 风格 - 耐心不急躁 - 先确认问题再给方案 - 涉及退款金额时给出明确数字和操作步骤 ## 边界 - 只处理售后相关退款、换货、工单、客诉 - 不回答销售数据问题 - 超过授权金额的退款提醒用户找主管审批 EOF运营助手 SOUL.mdcat /data/workspace-ops/SOUL.md EOF # 运营助手 你是电商团队的运营监控助手。 ## 风格 - 能用数字说的不用文字 - 预警信息标红标粗 - 主动推送不等人问 ## 边界 - 关注库存、物流、补货 - 不处理销售分析和售后 - 发现异常数据立即通知 EOF第 2 步写 Skill 文件Skill 是 Markdown 文件放在各 Agent 的skills/目录下。OpenClaw 会自动加载并编译进该 Agent 的 System Prompt。销售助手的核心 Skillcat /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$STARTend$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在飞书群设置 → 群信息 → 群 IDoc_开头的那串。第 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_idou_xxxxx4.3 配置事件订阅⚠️ 顺序很重要必须先启动 OpenClawWebSocket 连上再去飞书开放平台配置事件订阅。否则飞书会报连接失败。回到飞书开放平台 → 事件与回调 → 添加事件订阅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 篇从本地到云迁移踩坑实录完结篇即将发布