多 Agent 系统通信架构选型：Discord vs 飞书 vs Telegram

上周在服务器上部署了 3 个 AI Agent：一个写文章，一个搞技术，一个管运维。最开始用飞书，建了 3 个群，每个群配一个 Agent。能跑，但每次加新 Agent 就要建新群，群列表越来越长，权限管理也麻烦。

后来试了 Telegram，发现更糟：Bot 私聊只有一个对话上下文，所有话题混在一起。想问写作 Agent 改文章，结果它把上午讨论的服务器配置也带进来了。

最后换到 Discord，问题全解决了。一个服务器，5 个频道，4 个 Agent，管理成本直接降到零。

这篇文章聊聊多 Agent 系统的通信架构怎么选，以及为什么 Discord 在这个场景下是最优解。

多 Agent 系统的核心需求

在讨论平台选型之前，先明确多 Agent 系统到底需要什么。

会话隔离：上下文不能串

假设你有两个 Agent：Agent A 负责写技术文档，Agent B 负责客服问答。用户在跟 A 讨论 API 设计时，B 不应该看到这些消息；反过来，B 处理的用户投诉也不该影响 A 的输出。

这不是功能需求，是架构必须保证的隔离性。如果两个 Agent 共享上下文，会出现：

  • 回复内容错乱（A 的技术术语跑到 B 的客服回复里）
  • token 浪费（B 的每次调用都要带上 A 的历史消息）
  • 调试困难（出问题时无法定位是哪个 Agent 的上下文污染）

技术上，这要求平台能提供独立的 session 管理机制。

路由机制：请求要找对 Agent

用户发一条消息，系统怎么知道该交给哪个 Agent 处理？

最简单的方案是"一个 Bot 一个 Agent"，但这会导致：

  • 用户要记住每个 Bot 的名字
  • 切换 Agent 要切换对话窗口
  • 管理多个 Bot Token 和 Webhook

更好的方案是"一个 Bot，多个路由规则"。用户在不同的"空间"里说话，系统根据空间 ID 路由到对应 Agent。这个"空间"可以是群组、频道、或者带标签的对话。

配置灵活性：行为要能快速调整

Agent 的行为不是一成不变的。今天你可能希望写作 Agent 的风格是"专业严谨"，明天可能要改成"轻松幽默"。

如果每次调整都要：

  1. 修改配置文件
  2. 重启服务
  3. 等待重新加载

那开发效率会很低。理想情况是，改个描述或发个命令，Agent 立刻切换行为。

三大平台的架构对比

现在看看飞书、Telegram、Discord 在这三个需求上的表现。

飞书：群组模型的管理成本

飞书的多 Agent 方案是"一个应用，多个群组"。每个群绑定一个 Agent，通过群 ID 做路由。

会话隔离：✅ 每个群是独立的，上下文不会串。

路由机制：⚠️ 需要手动建群、拉人、配置。3 个 Agent 就要建 3 个群，10 个 Agent 就要建 10 个群。群列表会越来越长。

配置灵活性：❌ 群公告可以写提示词，但 Agent 读不到。要改行为只能改代码或配置文件，然后重启。

适用场景：企业内部已经在用飞书，且 Agent 数量不多（3 个以内）。飞书的优势是权限管理和审批流集成，但多 Agent 场景下管理成本高。

Telegram：单一上下文的困境

Telegram Bot 的私聊是一个长对话，所有消息按时间顺序排列。

会话隔离：❌ 私聊只有一个上下文。要隔离只能建多个 Bot（每个 Bot 一个 Token）或建群。但 Telegram 群没有子频道概念，隔离能力弱。

路由机制：⚠️ 可以用命令（如 /writer、/coder）切换 Agent，但用户体验差。或者建多个 Bot，但管理成本高。

配置灵活性：⚠️ 可以用 Bot Commands 做简单配置，但不如频道描述直观。

适用场景：移动端为主的个人使用，且只有 1-2 个 Agent。Telegram 的移动端体验很好，但多 Agent 场景下架构不够优雅。

Discord：频道架构的天然优势

Discord 的核心是"服务器 + 频道"结构。一个服务器可以有无数个频道，每个频道是独立的消息流。

会话隔离：✅ 每个频道自动生成独立 session。写作频道的消息不会跑到编程频道。

路由机制：✅ 通过频道 ID 做路由，配置一次就行。用户切换频道就是切换 Agent，不需要记命令或切窗口。

配置灵活性：✅ 频道 topic（频道名下面的描述）可以被 Agent 读取，当作行为提示。改描述就能切换 Agent 行为，不用重启。

适用场景：个人或小团队的多 Agent 系统，特别是需要频繁调整 Agent 行为的场景。

对比总结：

维度飞书TelegramDiscord
会话隔离✅ 群级隔离❌ 需建多 Bot✅ 频道级隔离
路由机制⚠️ 手动建群⚠️ 命令切换✅ 频道自动路由
配置灵活性❌ 需重启⚠️ 命令配置✅ topic 动态配置
管理成本高（多群）中（多 Bot）低（多频道）
适用场景企业内部移动优先个人/小团队

Discord 的技术优势解析

Discord 为什么这么适合多 Agent？核心是三层隔离机制。

频道级 session 隔离

Discord 的每个频道有独立的 channel ID。当 Agent 框架（如 OpenClaw）接入 Discord 时，会为每个频道创建独立的 session。

技术实现上，session key 通常是 discord:{guild_id}:{channel_id}。这意味着：

  • 频道 A 的消息历史只会传给处理 A 的 Agent
  • 频道 B 的上下文完全独立
  • 两个频道可以同时跑不同的任务，互不干扰

这是架构层面的隔离，不需要开发者手动管理。

topic 作为动态配置

频道 topic 是频道名下面那行小字，用户可以随时修改。OpenClaw 这类框架会把 topic 读进来，拼到 system prompt 里。

举个例子，我的减肥频道 topic 写的是：

你是一个严格的健身教练，回复风格直接、不废话、数据驱动。
用户说吃了什么就帮他算热量，不要安慰，不要鼓励，直接说超没超。

效果：我说"今天吃了一碗螺蛳粉"，Agent 直接回"450 大卡，你今天的配额还剩 800，晚饭少吃点"。

换到个人频道，同一个 Bot，语气完全不一样。

这个能力飞书和 Telegram 都没有。飞书的群公告 Agent 读不到，Telegram 没有频道 topic 的概念。

线程实现任务级隔离

频道解决了"谁干什么"，但同一个频道里，任务还是会打架。

比如写作频道，我让 Agent 写 A 文章，写到一半又开了 B 文章的选题讨论。两个任务的消息混在一起，Agent 回复 B 的时候把 A 的素材也带进来了。

Discord 线程就是干这个的。每个线程是频道里的子房间，有独立消息流。OpenClaw 把每个线程当成独立 session 处理——A 文章一个线程，B 文章一个线程，上下文完全隔离。

配置只需一行：

"channels": {
  "频道ID": {
    "allow": true,
    "requireMention": false,
    "autoThread": true
  }
}

开了 autoThread，每次在主频道发消息，Bot 自动创建线程来回复。主频道只剩一排线程标题，像目录。

所以完整的隔离架构是：

  • 服务器：整个 Agent 系统的容器
  • 频道：职能分层（写作、编程、运维）
  • 线程：任务分层（每篇文章、每个项目）

OpenClaw + Discord 实战配置

理论讲完，看看怎么配。整个过程就三步：创建 Bot、拿 ID、改配置。

Bot 创建与权限配置

去 Discord Developer Portal 创建 Application，进 Bot 页面拿 Token。Token 只显示一次，复制好存起来。

然后打开两个开关（Privileged Gateway Intents）：

  • Server Members Intent
  • Message Content Intent

这两个 Intent 必须开，否则 Bot 收不到消息内容。症状是：Bot 在线，日志没报错，但就是不回复。这个坑很隐蔽，因为不会报错，只是静悄悄地丢消息。

邀请链接用 OAuth2 → URL Generator，Scopes 勾 bot + applications.commands。

权限方面，自用服务器直接勾 Administrator 省事。如果服务器有其他人，最小权限是：

  • View Channels
  • Send Messages
  • Read Message History
  • Embed Links
  • Attach Files
  • Add Reactions

binding 路由规则设计

OpenClaw 的配置分三块：定义 Agent、开启 Discord、写 bindings。

定义 Agent：

{
  "agents": {
    "list": [
      { "id": "main" },
      {
        "id": "writer",
        "workspace": "/root/.openclaw/workspace-writer",
        "identity": { "name": "写作助手", "emoji": "✍️" }
      },
      {
        "id": "coder",
        "workspace": "/root/.openclaw/workspace-coder",
        "identity": { "name": "代码助手", "emoji": "🛠️" }
      }
    ]
  }
}

每个 Agent 有自己的 workspace，里面放 SOUL.md（人设）、MEMORY.md（记忆）。workspace 不同，人格就不同。

开启 Discord：

{
  "channels": {
    "discord": {
      "enabled": true,
      "token": "你的BOT_TOKEN",
      "guilds": {
        "你的服务器ID": {
          "channels": {
            "写作频道ID": { "allow": true, "requireMention": false, "autoThread": true },
            "编程频道ID": { "allow": true, "requireMention": false, "autoThread": true }
          }
        }
      }
    }
  }
}

requireMention: false 是关键。不加这个，每次说话都要 @Bot。自用服务器直接关掉。

写 bindings（频道 → Agent 的路由规则）：

{
  "bindings": [
    {
      "agentId": "writer",
      "match": {
        "channel": "discord",
        "peer": { "kind": "channel", "id": "写作频道ID" },
        "guildId": "你的服务器ID"
      }
    },
    {
      "agentId": "coder",
      "match": {
        "channel": "discord",
        "peer": { "kind": "channel", "id": "编程频道ID" },
        "guildId": "你的服务器ID"
      }
    }
  ]
}

没匹配到 binding 的频道自动走 default agent（main）。

改完配置，重启 gateway：

openclaw gateway restart

去每个频道发句话验证。写作助手回复带 ✍️，代码助手带 🛠️，emoji 对了就说明路由没问题。

autoThread 的最佳实践

即使服务器就你一个人，也建议开 autoThread。原因：

  1. 回溯方便：按线程找每篇文章的完整过程，不用在主频道翻几百条消息
  2. 并行不冲突：三个任务同时跑也不乱
  3. 手机端友好：主频道只显示线程标题，点进去才看详情

唯一的缺点是，Bot 的回复不会出现在主频道，而是在线程里。如果你希望主频道也能看到回复，可以关掉 autoThread，但要接受上下文混乱的代价。

社区里用 OpenClaw 的人，绝大多数都开了线程。一旦习惯了，回不去主频道直聊。

生产环境的注意事项

配置跑通只是第一步，生产环境还有几个坑要注意。

常见配置错误与排查

Bot 在线但不回复：

  • 检查 Message Content Intent 是否开启
  • 检查 requireMention 是否为 false（或者你确实 @了 Bot）
  • 看日志有没有 no-mention 或权限错误

回复的 Agent 不对：

  • 检查 binding 配置，确认频道 ID 没写错
  • 频道 ID 是一串数字，复制时容易多一位少一位
  • 用 openclaw doctor 检查配置

升级后消息全混了：

  • 配置格式可能变了，session key 生成规则也可能变了
  • 跑 openclaw doctor --fix 修复
  • 如果还不行，清空 session 数据库重新开始（会丢历史记忆）

多人协作的权限设计

如果服务器不止你一个人，需要考虑权限：

  1. 频道权限：哪些人能看到哪些频道
  2. 执行权限：哪些人能让 Agent 执行 shell 命令
  3. 配置权限：哪些人能修改频道 topic

OpenClaw 的 execApprovals 可以限制命令执行：

{
  "execApprovals": {
    "enabled": true,
    "approvers": ["你的Discord用户ID"]
  }
}

开启后，Agent 执行 shell 命令前会弹按钮让你确认。

监控与成本控制

多 Agent 系统的 token 消耗很快，特别是用 Claude Opus 这种大模型。建议：

  1. 按场景分配模型：写作用 Opus（深度思考强），日常问答用 Sonnet（省 token）
  2. 定期检查用量：Anthropic Console 可以看每个 API Key 的消耗
  3. 设置预算告警：超过阈值就发通知

另外，Discord Bot 的 API 调用也有速率限制。如果频道很多、消息量大，可能会触发 rate limit。OpenClaw 内置了重试机制，但最好还是控制并发。

选型建议

回到最开始的问题：多 Agent 系统的通信平台怎么选？

个人或小团队（5 人以内）：

  • 首选 Discord。配置简单，管理成本低，频道架构天然适合多 Agent。
  • 如果已经在用 Telegram 且只有 1-2 个 Agent，可以继续用，但扩展性差。

企业内部（已有飞书）：

  • 如果 Agent 数量不多（3 个以内），飞书的集成优势更大（审批流、日历、文档）。
  • 如果 Agent 数量多（5 个以上），建议单独搭 Discord 服务器，或者用企业微信（架构类似飞书）。

移动端为主：

  • Telegram 的移动端体验最好，但多 Agent 场景下架构不够优雅。
  • Discord 移动端也不错，且支持线程，长期使用更舒服。

技术栈考虑：

  • 如果用 OpenClaw、Dify、Coze 这类框架，Discord 的集成最成熟。
  • 如果自己写 Agent 框架，Discord 的 API 文档完善，社区活跃。

下一步行动：

  1. 去 Discord Developer Portal 创建一个测试 Bot
  2. 建一个私人服务器，创建 2-3 个频道试试
  3. 参考本文的配置示例，跑通第一个 Agent
  4. 开启 autoThread，体验任务级隔离

Discord 的频道架构天生适合多 Agent 系统。一个频道一个 Agent，频道 topic 切换行为，线程隔离任务上下文。配置就三件事：创建 Bot、列频道、写 bindings。再加一行 autoThread，任务级隔离也有了。

如果你也在搭多 Agent 系统，试试 Discord。比飞书省心，比 Telegram 灵活。