OpenClaw 多 Agent + 双钉钉机器人 SOP：单网关配置与验证

1. 为什么要在单网关下跑两个钉钉机器人OpenClaw 是一个可以把大模型能力接到聊天工具里的网关型框架它最实用的地方在于你不需要为每个业务场景单独部署一套服务而是用同一个 Gateway 进程挂多个 Agent再通过路由规则把不同来源的消息分发给不同 Agent。钉钉机器人则是国内团队最常用的消息入口之一企业内部应用 Stream 模式不用公网回调地址就能收消息。把这两件事拼在一起就得到一个很典型的运维场景一个 main Agent 负责日常问答和通用任务一个 k8sagent 专门处理 Kubernetes 集群相关的排障、巡检、YAML 生成。两个 Agent 各自绑定一个钉钉机器人分别进不同的群会话隔离、人设隔离但共用同一套 Skill 和同一个模型 Key。这样既省资源又不会让 K8S 群里的对话串到通用群里。这篇 SOP 交付的是可复制的openclaw.json骨架、双机器人路由配置、验证动作以及我在落地过程中真实踩过的坑。适合已经装好 OpenClaw、能跑openclaw gateway status但还没配过多 Agent 路由的人。整套流程围绕单网关展开不涉及多实例部署。需要提前说明的是OpenClaw 的模型调用需要配置 provider 和 apiKey。如果你希望统一管理模型访问凭证、避免在每个 Agent 里重复写 Key可以用 TaoToken 这类兼容 OpenAI 协议的中转服务把 base_url 和 key 配在全局 models 段两个 Agent 继承即可。下面会给出具体配置位置。2. 前置准备OpenClaw、钉钉插件与配置备份在动任何配置之前先把环境确认清楚。这一步看起来啰嗦但后面 80% 的报错都源于前置没对齐。先确认 Gateway 在跑openclaw gateway status如果输出里能看到 running 状态和监听信息说明网关正常。接着确认钉钉连接器插件已安装openclaw plugins install dingtalk-real-ai/dingtalk-connector openclaw plugins listplugins list里应该能看到dingtalk-real-ai/dingtalk-connector记下它的完整 id后面plugins.allow要用。注意连接器 README 里会写明它要求的最低 OpenClaw 版本版本太低会出现 schema 不识别accounts字段的情况装之前对一下。配置文件的默认路径是~/.openclaw/openclaw.json也可以用环境变量OPENCLAW_CONFIG_PATH指定。改之前一定备份cp ~/.openclaw/openclaw.json ~/.openclaw/openclaw.json.bak.$(date %Y%m%d%H%M)路径速查Linux示例用户主目录为~用途路径总配置~/.openclaw/openclaw.jsonmain 工作区~/.openclaw/workspacek8sagent 工作区~/.openclaw/workspace/k8sagent会话落盘~/.openclaw/agents/agentId/sessions/公共 Skill~/.openclaw/skills/注意工作区路径以agents.list里实际写的为准上表只是常见默认值。如果你之前改过 workspace以配置为准。钉钉侧需要准备两个企业内部应用。main 沿用你原来那个应用K8S 用的新建一个两个应用各自开启机器人能力消息接收选 Stream 模式。分别记录 Client IDAppKey和 Client SecretAppSecret完成版本发布和可见范围设置再把对应机器人拉进各自的群。这些凭证只写在本地配置文件里不要贴到任何公开地方。3. 新建 k8sagent 并写好人设Agent 的创建用 CLI 完成不需要手改agents.listopenclaw agents add k8sagent --workspace ~/.openclaw/workspace/k8sagent openclaw agents list openclaw agents set-default mainagents list里应该能看到 main 和 k8sagent 两条且 main 标记为 default。把 k8sagent 的 workspace 路径记下来后面写 SOUL 要用。人设文件放在工作区根目录cd ~/.openclaw/workspace/k8sagent vim SOUL.mdSOUL.md 决定这个 Agent 的语气、职责边界和回答风格。k8sagent 的 SOUL 建议明确写清只处理 Kubernetes / 容器 / 集群相关话题遇到无关问题引导回 main 群输出 YAML 时给完整可 apply 的片段排障时先要kubectl describe和事件输出。这样即使两个 Agent 共用同一套 Skill对话风格也不会混。可选地再写USER.md和AGENTS.md前者描述服务对象后者描述协作约束。不要在这些文件里写真实凭证、内网域名或真实群聊标识。Skill 这块当前策略是公共目录技能继续放在~/.openclaw/skills/不要在agents.list里给 k8sagent 或 main 写skills白名单。两个 Agent 共用同一套可见技能区分靠的是会话 SOUL 路由不是 skill 拆分。如果以后确实要按 name 裁剪再单独加白名单。模型和 Key 也不用给 k8sagent 单独写一套。让它继承agents.defaults或全局models段即可和 main 共用同一个 provider 配置。如果你用 TaoToken 统一管理模型访问把 base_url 指向https://taotoken.net/apikey 配在全局 models 里两个 Agent 都能用省得重复维护。4. 可复制的 openclaw.json 双机器人路由骨架核心改动集中在三处channels.dingtalk-connector.accounts变成多账号、根级新增bindings、plugins.allow显式放行连接器。下面这份骨架可以直接对照改把 clientId / clientSecret 换成你自己的并合并进你现有的 gateway、models 段落。{ agents: { list: [ { id: main, default: true, workspace: ~/.openclaw/workspace }, { id: k8sagent, workspace: ~/.openclaw/workspace/k8sagent } ] }, channels: { dingtalk-connector: { enabled: true, accounts: { main: { enabled: true, clientId: ding_第一个应用_AppKey, clientSecret: 第一个应用_Secret }, k8sagent: { enabled: true, clientId: ding_第二个应用_AppKey, clientSecret: 第二个应用_Secret } } } }, bindings: [ { agentId: main, match: { channel: dingtalk-connector, accountId: main } }, { agentId: k8sagent, match: { channel: dingtalk-connector, accountId: k8sagent } } ], plugins: { allow: [dingtalk-real-ai/dingtalk-connector] } }三处命名必须一致这是最容易出错的地方accounts下的 key、bindings.match.accountId、以及你心里预期的 Agent 归属。agentId则必须和agents.list里的id完全对应。名称本身可以自定义比如把 account key 叫ding-main、ding-k8s只要三处对齐就行。如果你之前是顶层单组clientId/clientSecret的写法必须把它们迁进accounts并删掉顶层重复字段否则会和插件的 schema 冲突。plugins.allow里填的 id 要和openclaw plugins list输出的一致不要凭记忆写。注意gateway.auth.token与连接器要求的认证方式保持和你线上一致。如果当前连接器版本仍要求与网关 token 对齐按插件文档填写不要想当然。5. 校验、重启与双群验证配置写完先做 schema 校验openclaw config validate输出Config valid只代表 JSON 和 schema 通过不代表钉钉已经连通。接着重启网关并查看绑定关系openclaw gateway restart openclaw agents list --bindings openclaw channels status --probeagents list --bindings是判断路由是否生效的关键。跑通后每个 Agent 下面应该出现Routing rules: 1并列出dingtalk-connector accountId与 accounts key 一致同时Providers: DingTalk name: configured。如果显示Routing rules: 0说明 bindings 没被识别钉钉消息会走default: true的 Agent。如果openclaw gateway restart报错systemctl is-enabled unavailable: Failed to connect to bus: No medium found这说明当前环境没有可用的 systemd D-Bus常见于无 systemd 的容器或精简会话。处理方式是找到进程后手动重启pgrep -af openclaw kill PID openclaw gatewayDocker 场景直接重启容器即可。前台跑openclaw gateway时日志会直接打在终端方便观察入站消息。验证动作按下面三步走步骤操作期望结果1在 main 机器人所在群 机器人提问走 main~/.openclaw/agents/main/sessions/有更新2在 K8S 机器人所在群 机器人提问走 k8sagent人设符合 SOUL3openclaw agents list --bindings能看到两条 accountId 路由如果私聊触发的是 pairing 流程用openclaw pairing list dingtalk-connector openclaw pairing approve dingtalk-connector 码6. 本篇常见错排查两个机器人进了同一个 Agent。先查bindings.match.accountId和accounts的 key 是否拼写一致再查agentId是否和agents.list的 id 对应。三处任意一处写错路由就会退化到 default。config validate报错。多半是残留了顶层clientId/clientSecret没删或者 JSON 里有尾逗号。严格对照连接器 README 的字段名删掉废弃字段。一直提示plugins.allow is empty。在openclaw.json里补上plugins.allow内容与本机openclaw plugins list中的扩展 id 一致保存后重启网关。openclaw config file报错。旧版 CLI 可能不支持这个子命令直接编辑~/.openclaw/openclaw.json即可不必纠结 CLI。日志里 grep 不到 conversationId。/tmp/openclaw/openclaw-*.log默认可能只打印plugins.allow的 WARN不打印入站正文或会话 ID。要拿群openConversationId优先用钉钉开放平台的「获取群会话 OpenConversationId」接口或提高日志级别。一套 ClientId/Secret 想给多个网关同时收 Stream。不推荐。Stream 侧通常同一应用同时只宜接一个消费端多实例会抢连或不稳定。要复用旧机器人必须确认原 OpenClaw 已停用该应用后再迁。未配 bindings 却像进了 K8S 人设。多半是当时 default 指向了 k8sagent或者 main 的 SOUL 被改过也可能是钉钉侧固定欢迎语造成的错觉。以agents default和agents list --bindings为准排查。回滚很简单cp ~/.openclaw/openclaw.json.bak.时间戳 ~/.openclaw/openclaw.json openclaw gateway restart无 systemd 时按第 5 节的手动启停方式处理。7. 后续新增 Agent 与接入入口再新增一个 Agent比如 coder、ops时按这个顺序走能少踩很多重复的坑钉钉侧新建企业内部应用 机器人Stream并拉群OpenClaw 侧openclaw agents add 新id然后编辑$WS/SOUL.md配置侧在channels.dingtalk-connector.accounts增加新 key在bindings增加 accountId 到新 agentId 的映射plugins.allow已包含连接器就不用改最后openclaw config validate→ 重启网关 →openclaw agents list --bindings→ 两个机器人各测一轮。如果你在配模型 provider 时想统一管理 Key避免每个 Agent 重复写可以到 TaoToken API Keys 生成一个 key把 base_url 配成https://taotoken.net/api写进全局 models 段两个 Agent 继承即可。接入细节和字段说明看 TaoToken 接入文档。配好之后想先确认模型本身能不能正常回话可以直接在 模型对话 里发一条测试消息确认 provider 和 key 没问题再回到钉钉群里验证路由。如果你打算长期跑编码类 Agent、或者让 Agent 承担更多自动化任务Coding Plan 里有按用量规划的方案可以对照自己的调用量选。整套流程里最值得记住的一点路由由 bindings 和 default 决定不能靠提示词切换 Agent。把三处命名对齐、把plugins.allow补全、把无 systemd 环境的重启方式记牢剩下的就是两个群各测一轮的事。