多 Agent 企微接入管理

要解决什么问题

团队里往往不止一个「企微里的机器人」：财务、运营、客服各有一套话术和权限，却容易共用一个 OpenClaw 实例和同一套全局模型。结果是人设串台、模型无法按角色拆分，多个 Bot 也无法明确对应到固定 Agent。

本技能面向 OpenClaw + 企业微信智能体 Bot 场景：在同一实例里让多个 Agent 各自绑定不同的企微账号，消息从哪个 Bot 进就从哪个 Bot 回，并在 workspace 层面隔离 SOUL、工具说明和模型配置。

核心机制

依赖 WeCom Plugin（@wecom/wecom-openclaw-plugin）提供的多账号与 bindings 路由。典型配置落在 openclaw.json：

• channels.wecom.accounts：登记多个 Bot 的 BotID、Secret 等账号信息
• bindings：把账号 ID 映射到 agents.list 中的具体 Agent
• 每个 Agent：独立 workspace，内含 SOUL.md、USER.md、AGENTS.md、TOOLS.md 等人设与上下文文件

模型可按 Agent 在 agent/models.json 或 agents.list[].model.primary 中指定；未单独配置时会按优先级继承全局 models.providers 与 defaults。文档还提供配置诊断思路：检查未绑定账号、缺 SOUL.md 的 Agent、以及模型是否仅依赖全局兜底。

同一 Agent 也可绑定多个 Bot，此时可通过消息里的 accountId 区分来源并调整回复策略。

适用边界与注意点

• 多账号绑定适合固定角色分工；dynamicAgents 适合按用户/群动态建临时 Agent，两者可并存，但用途不同，不要混为一谈。
• 执行绑定相关 CLI 时可能覆盖现有 bindings，追加前应先读取再合并。
• 改完账号、绑定或模型后需重启 Gateway；Bot 无响应时依次查绑定、人设文件、企微白名单与 Gateway 日志。
• Agent 主动推群消息需走企微 Bot API（文档中的 exec 调用方式），与被动回复的路由规则是两套能力。