打造你的家庭 AI 助手（四）：单 OpenClaw 配置多 Agent、多 QQ、飞书机器人

优质文章学习记录

— 6 min read
打造你的家庭 AI 助手（四）：单 OpenClaw 配置多 Agent、多 QQ、飞书机器人

打造你的家庭 AI 助手（四）：单 OpenClaw 配置多 Agent、多 QQ、飞书机器人

引言

OpenClaw 是一个强大的智能体（Agent）编排框架，它通过统一的架构让开发者可以轻松管理多个聊天机器人，并接入不同的即时通讯平台。在实际应用中，我们往往需要同时运行多个 QQ 机器人（例如个人助手、工作助手），甚至希望同一个智能体既能处理 QQ 消息，也能响应飞书消息。

本文将详细介绍如何在一个 OpenClaw 实例中配置多通道（QQ、飞书）、多 Agent 以及多 QQ 机器人账号，实现资源的高效利用和灵活的消息路由。特别地，我们将阐明飞书通道与 QQ 通道在绑定规则上的差异，避免常见的配置错误。

核心概念回顾

  • Agent（智能体）：拥有独立人格、记忆和技能的对话单元。每个 Agent 有自己的工作区（workspace），存放 SOUL.md（人格设定）和 skills/（技能）。
  • Channel（通道）：连接外部即时通讯平台的模块，如 qqbot（QQ 官方机器人）、feishu（飞书）。
  • Binding（绑定）：定义消息路由的规则，将特定通道的 incoming 消息派发给指定的 Agent 处理。

环境准备

  • 已安装 OpenClaw
  • 拥有至少一个 QQ 机器人（在 QQ 开放平台 创建）和一个飞书应用（在 飞书开放平台 创建），获取各自的 AppID 和 AppSecret

配置多 QQ 机器人账号

OpenClaw 的 qqbot 通道支持同时接入多个 QQ 机器人，只需在 channels.qqbot.accounts 对象中为每个机器人定义一个唯一的 accountId，并填入对应的凭证。

配置文件示例 ~/.openclaw/config.json：

{"channels":{"qqbot":{"enabled":true,"accounts":{"personal-bot":{"appId":"QQ_APPID_1","clientSecret":"QQ_SECRET_1"},"work-bot":{"appId":"QQ_APPID_2","clientSecret":"QQ_SECRET_2"}}}}}

这里 personal-bot 和 work-bot 是我们自定义的账号 ID，后续在绑定规则中会用到。

配置多 Agent

每个 Agent 对应一种人格或功能。例如我们可以创建两个 Agent：

  • shuying-finance：金融助手，负责处理投资咨询
  • shuying-general：通用助手，负责日常闲聊

Agent 配置示例：

{"agents":{"list":[{"id":"shuying-finance","name":"金融助手","workspace":"/data/workspace/finance"},{"id":"shuying-general","name":"通用助手","workspace":"/data/workspace/general"}]}}

每个 Agent 的工作区是独立的，可以放置不同的人格设定文件（SOUL.md）和技能代码。

配置绑定规则：将 QQ 账号路由到不同 Agent

现在我们将两个 QQ 机器人分别绑定到不同的 Agent。注意，在匹配 QQ 通道时，我们使用 accountId 字段来指定具体的机器人账号。

{"bindings":[{"agentId":"shuying-finance","match":{"channel":"qqbot","accountId":"work-bot"}},{"agentId":"shuying-general","match":{"channel":"qqbot","accountId":"personal-bot"}}]}
易错提醒：字段名必须是 accountId，而不是 account。如果写成 "account": "..." 会导致 Invalid input 错误。

配置飞书通道与绑定规则

飞书通道的配置与 QQ 略有不同。首先在 channels.feishu 中配置应用账号：

{"channels":{"feishu":{"enabled":true,"accounts":{"finance-feishu":{"appId":"FEISHU_APPID","appSecret":"FEISHU_SECRET"}}}}}

飞书绑定规则的关键区别在于：飞书的消息来源需要指定具体的 peer（对话对象），可以是用户私聊（user）或群聊（group），并给出对应的 ID。

例如，我们希望将某个飞书群的会话路由给金融助手：

{"bindings":[{"agentId":"shuying-finance","match":{"channel":"feishu","accountId":"finance-feishu","peer":{"kind":"group","id":"oc_582b57e290ba8a4d662eedaa0f446eb7"}}}]}

如果需要匹配某个用户的私聊，则将 kind 改为 user，id 改为用户的 open_id。

为什么飞书不使用 accountId 直接匹配？

因为飞书通道支持在同一应用账号下区分不同的会话来源（群或用户），提供更精细的路由控制。如果你希望某个飞书应用账号的所有消息都交给同一个 Agent，可以省略 peer 字段。

进阶：同一个 Agent 同时处理 QQ 和飞书

如果希望一个 Agent（例如 shuying-finance）既能处理 QQ 消息，也能处理飞书消息，只需添加两条绑定规则，指向同一个 agentId。

完整绑定示例：

{"bindings":[// QQ 绑定{"agentId":"shuying-finance","match":{"channel":"qqbot","accountId":"work-bot"}},{"agentId":"shuying-general","match":{"channel":"qqbot","accountId":"personal-bot"}},// 飞书绑定（同一个金融助手）{"agentId":"shuying-finance","match":{"channel":"feishu","accountId":"finance-feishu","peer":{"kind":"group","id":"oc_582b57e290ba8a4d662eedaa0f446eb7"}}}]}

现在，无论是通过 work-bot QQ 号发来的消息，还是通过指定飞书群发来的消息，都会交给 shuying-finance 这个 Agent 统一处理。Agent 将使用同一套人格和技能进行回复，实现跨平台的一致性体验。

配置文件完整示例

将以上片段整合成一个完整的配置文件（仅展示关键部分）：

{"agents":{"list":[{"id":"shuying-finance","workspace":"/data/workspace/finance"},{"id":"shuying-general","workspace":"/data/workspace/general"}]},"channels":{"qqbot":{"enabled":true,"accounts":{"personal-bot":{"appId":"QQ_APPID_1","clientSecret":"QQ_SECRET_1"},"work-bot":{"appId":"QQ_APPID_2","clientSecret":"QQ_SECRET_2"}}},"feishu":{"enabled":true,"accounts":{"finance-feishu":{"appId":"FEISHU_APPID","appSecret":"FEISHU_SECRET"}}}},"bindings":[{"agentId":"shuying-finance","match":{"channel":"qqbot","accountId":"work-bot"}},{"agentId":"shuying-general","match":{"channel":"qqbot","accountId":"personal-bot"}},{"agentId":"shuying-finance","match":{"channel":"feishu","accountId":"finance-feishu","peer":{"kind":"group","id":"oc_582b57e290ba8a4d662eedaa0f446eb7"}}}]}

验证与重启

修改配置文件后，建议先验证语法：

openclaw config validate

如果没有错误，重启网关服务使配置生效：

openclaw gateway restart

之后可以通过 openclaw status 查看 Agent 和通道的运行状态。分别用 QQ 和飞书向对应的机器人/群发送消息，测试是否被正确路由到预期的 Agent。

常见问题

  1. 绑定规则不生效（QQ）：检查 accountId 是否与 accounts 中的键名完全一致（区分大小写），且字段名为 accountId 而非 account。
  2. 绑定规则不生效（飞书）：确认 peer 中的 kind 和 id 正确无误，且该群或用户确实属于配置的飞书应用。
  3. 通道启动失败：确认 appId/appSecret 无误，并且服务器 IP 已在对应平台的白名单中。
  4. Agent 无响应：检查 Agent 的工作区是否存在有效的 SOUL.md 文件，或者是否有技能代码错误。

总结

通过本文的配置，我们实现了在一个 OpenClaw 实例中：

  • 接入多个 QQ 机器人账号
  • 定义多个具有不同人格的 Agent
  • 将不同 QQ 账号的消息精确路由到对应的 Agent
  • 将飞书特定群的消息也路由到其中一个 Agent，实现跨平台统一处理

OpenClaw 的灵活性和扩展性为构建复杂的对话系统提供了坚实的基础。掌握通道、Agent 和绑定规则的关系，你可以轻松扩展更多平台和更多智能体，打造属于自己的机器人矩阵。

相关文章：

Read more

Flutter 组件 google_generative_language_api 适配鸿蒙 HarmonyOS 实战：生成式 AI 集成，构建大语言模型调度与全场景智能推理治理架构

Flutter 组件 google_generative_language_api 适配鸿蒙 HarmonyOS 实战：生成式 AI 集成，构建大语言模型调度与全场景智能推理治理架构

欢迎加入开源鸿蒙跨平台社区：https://openharmonycrossplatform.ZEEKLOG.net Flutter 组件 google_generative_language_api 适配鸿蒙 HarmonyOS 实战：生成式 AI 集成，构建大语言模型调度与全场景智能推理治理架构 前言 在鸿蒙（OpenHarmony）生态迈向全场景 AI 赋能、涉及高效的语义理解、自动化内容生成及严苛的端云协同智能隐私保护背景下，如何实现一套既能深度对接 Google 生成式语言模型（如 Gemini、PaLM）、又能保障异步请求高响应性且具备多模态输入处理能力的“AI 调度中枢”，已成为决定应用智能化水平与用户体验代差的关键。在鸿蒙设备这类强调分布式协同与端侧算力按需分配的环境下，如果应用依然采用低效的 REST 手写拼接，由于由于 payload 结构复杂性，极易由于由于“协议解析异常”导致鸿蒙应用在大模型推理环节发生由于由于由于由于通讯阻塞。 我们需要一种能够统一模型调用语义、支持流式（Streaming）响应且符合鸿蒙异步异步并发范式的
2026技术展望】Python与AI的深度融合：从“能用”到“好用”的质变之年

2026技术展望】Python与AI的深度融合：从“能用”到“好用”的质变之年

🔥个人主页：北极的代码（欢迎来访） 🎬作者简介：java后端学习者 ❄️个人专栏：苍穹外卖日记，SSM框架深入，JavaWeb ✨命运的结局尽可永在，不屈的挑战却不可须臾或缺！ 前言 站在2026年的春天回望，Python与AI的这段“联姻”已经走过了近十年的高光时刻。如果说过去五年我们关注的是“大模型还能多大”、“算力还能多强”，那么2026年，整个技术圈的风向已经发生了根本性的转变。 2026年，是AI Agent（智能体）全面落地的一年，是模型从“重训练”转向“轻推理”的一年，更是Python生态从“胶水语言”蜕变为“AI原生操作系统”的一年。 今天，我们不聊虚的，直接深入2026年Python+AI的技术腹地，看看这一年的热点到底在哪里，以及作为开发者，我们该如何抓住这波红利。 热点一：AI Agent 框架的“百团大战”与 Python

Whisper.Unity终极指南：在Unity中轻松实现本地语音转文字

Whisper.Unity终极指南：在Unity中轻松实现本地语音转文字 【免费下载链接】whisper.unityRunning speech to text model (whisper.cpp) in Unity3d on your local machine. 项目地址: https://gitcode.com/gh_mirrors/wh/whisper.unity 想要在Unity项目中添加语音识别功能，却担心复杂的配置和昂贵的云端服务费用？🤔 Whisper.Unity正是你需要的解决方案！这个强大的开源项目将OpenAI的Whisper语音识别模型完美集成到Unity3D环境中，让你轻松实现完全离线的语音转文字功能。 🎯 为什么选择Whisper.Unity？ 零成本部署 💰 - 完全免费开源，无需支付任何服务费用 隐私安全保障 🔒 - 所有语音处理都在本地完成，保护用户数据安全 多语言支持 🌍 - 支持约60种语言识别和跨语言翻译 跨平台兼容 📱 - 支持Windows、macOS、

AI绘画提示词生成器：从原理到实战的开发者指南

快速体验 在开始今天关于 AI绘画提示词生成器：从原理到实战的开发者指南 的探讨之前，我想先分享一个最近让我觉得很有意思的全栈技术挑战。 我们常说 AI 是未来，但作为开发者，如何将大模型（LLM）真正落地为一个低延迟、可交互的实时系统，而不仅仅是调个 API？ 这里有一个非常硬核的动手实验：基于火山引擎豆包大模型，从零搭建一个实时语音通话应用。它不是简单的问答，而是需要你亲手打通 ASR（语音识别）→ LLM（大脑思考）→ TTS（语音合成）的完整 WebSocket 链路。对于想要掌握 AI 原生应用架构的同学来说，这是个绝佳的练手项目。 从0到1构建生产级别应用，脱离Demo，点击打开 从0打造个人豆包实时通话AI动手实验 AI绘画提示词生成器：从原理到实战的开发者指南 背景与痛点 AI绘画的兴起让提示词（Prompt）成为连接创意与生成结果的关键纽带。然而在实际开发中，构建一个高效的提示词生成器常面临以下挑战： * 质量不稳定：生成的提示词可能过于笼统（如"