深度研究报告：通过 Discord 实现多 Agent 协作

Codex 核验（2026-10-09）：Microsoft AutoGen现为 maintenance mode，新项目官方推荐 Microsoft Agent Framework；AG2 是独立延续的项目，不是当前 Microsoft AutoGen 的别名。OpenAI Swarm已由 Agents SDK 接替。正文框架版本、stars 和项目部署是历史快照。Discord thread 不能无限嵌套；真正的权限应核对稳定 user/bot ID 与角色，不能依赖显示名或 prompt。timeout/retry 需幂等 msg_id、去重与实际取消路径；把任务标 CLOSED 不意味着远端 agent 已停止。自定义桥接协议与“成熟/领先”评价不是 Discord 官方协议或端到端验收。

一、现状格局 — 这不是新问题

多 Agent 通过 消息中间件 通信是成熟模式，Discord 已被多个项目用作 Agent 间的 传输层/消息总线。现有方案分四类：

1.1 原生框架内嵌 Discord 桥接

框架	项目/Stars	Discord 集成程度	核心技术
AutoGen (Microsoft)	58.8k★	社区有 `discord-bridge`、`autogen-discord` 等桥接层，官方无原生支持	Agent 间用 `ConversableAgent` 的 `generate_reply` 循环，Discord 作为 UserProxy 输入
CrewAI	26k+★	官方示例有 Discord bot 集成，用 `@agent` event handler 转发任务	基于流程编排，Agent 通过 `Task` + `Process` 定义协作
OpenAI Swarm	21.6k★	无原生集成（教育框架），但模式是 `handoff` 函数可对接任意传输层	`function_call` → agent handoff
Semantic Kernel	24k+★	有 Discord Connector（官方 Python SK 包）	`IChatCompletion` 接口抽象，Connector 模式
LangGraph	12k+★	社区实现将 LangGraph 节点挂到 Discord event loop	有向图状态机 + persistence

1.2 纯 Discord 原生 Agent 协作项目

discord-multi-agent (R2D2 类项目)：多个 bot token 各自独立运行，通过 channel 消息用结构化协议通信（JSON payload, regex 匹配 action）
AgentConnect：用 Discord 的 threads + embeds 实现 Agent 会话隔离
Cog-based 框架（discord.py）：用 Cog 架构实现 Agent 模块化，每个 Cog 就是一个 Agent，共享 Gateway 连接

1.3 非 Discord 但可借鉴的模式

项目	通信模式	可迁移到 Discord 的部分
CAMEL	角色扮演 + 任务指定	`role` header + `task` payload 可在 Discord embed 中实现
MetaGPT	SOP 驱动的角色流水线	用 Discord channel 模拟会议室（如 product-manager, architect）
ChatDev	结构化对话链	用 message chain + parent_id 追踪

二、核心设计模式（综合所有已知实现在总结）

Pattern A：单 Bot + 多 Profile 路由（Hermes 当前模式）

一个 Discord Bot Token → 一个 Hermes Gateway
                                    ├── → Manas (WSL, 决策层)
                                    ├── → Mano (Windows, 用户侧)
                                    └── → Keeper (Windows, 运维层)

优点：简单，一个连接，token 管理少
挑战：消息路由歧义（谁该回复？），需要严格的 @mention 协议
谁在用：Hermes 生态（本项目）；部分 AutoGen 自定义实现

Pattern B：多 Bot Token + 独立 Gateway

Bot A (Token A) → Agent A → Channel α
Bot B (Token B) → Agent B → Channel α (共享频道)

优点：Agent 完全独立，各自鉴权，failover 相互隔离
挑战：需要管理 N 个 bot 权限，消息排序问题，容易被 Discord rate limit 同时打
谁在用：大型 multi-agent 游戏服务器（如 AI Town 变体）

Pattern C：共享 Bot + Thread 隔离

一个 Bot → Gateway → 为每个会话/任务创建 Discord Thread
                      Agent A → Thread T1
                      Agent B → Thread T1
                      Agent C → Thread T1 (子线程)

优点：利用 Discord 原生 thread 机制做会话隔离，天然上下文分离
挑战：Thread 有生命周期管理问题
谁在用：AgentConnect 类项目

Pattern D：Event Bus 模式（最可扩展）

[Discord Gateway]
     ↓ (raw events)
[Event Bus / PubSub] ←→ Agent A (subscribed to "cmd.*")
                       ←→ Agent B (subscribed to "monitor.*")
                       ←→ Agent C (subscribed to "gateway.*")

优点：松耦合，Agent 只需要订阅关心的频道/前缀
挑战：需要自己实现 Event Bus 组件
谁在用：Cog 架构本质是退化版 event bus；Hermes plugins 也接近

三、Agent 间通信协议设计（从已有项目中提取）

经过对 AutoGen 的 agent message protocol、AgentScript、CrewAI 的 Task/Output 接口、以及多个 Discord bot 互操作项目的分析，提取出的最实践中性协议：

3.1 消息格式（结构化 JSON over Discord message）

{
  "protocol": "hermes-inter-agent/1.0",
  "msg_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "timestamp": "2026-06-10T12:00:00Z",
  "from": "agent:manas",
  "to": "agent:keeper",
  "priority": "normal",
  "type": "action_request",
  "thread_id": "task-xyz-123",
  "parent_msg_id": "prev-msg-id",
  
  "payload": {
    "action": "restart_gateway",
    "params": { "profile": "default", "force": true },
    "deadline": "2026-06-10T12:05:00Z"
  },
  
  "signature": null
}

3.2 协议约束（从多项目失败经验中总结）

每个消息必须有一个 to → 否则所有 agent 竞争回复
回复链必须用 parent_msg_id → 否则多轮对话串不起来
状态前缀机制 → [ACTION] [QUESTION] [BLOCKED] 等标签做快速过滤
[CLOSED] 终止协议 → 防止回声循环
不要求 Ack → 只要求对带 @mention 的消息回复一次，然后静默
超时重试 → 无回复 30s 后重试，最多 3 次

3.3 discord.py / discord.js 的技术选型

方面	discord.py (Python)	discord.js (JS/TS)
Agent 消息协议	容易实现，Hermes 已用 Python	适合 WebSocket 密集型
Gateway 管理	`asyncio` + `discord.Client`	`Client#ws` 更多控制
Embed 构建	`discord.Embed`	更丰富的组件支持
建议	Manas/Keeper 已在 Python 栈，保持统一	新 Agent 可考虑

四、现有 GitHub 项目的关键教训

从可访问到的项目和文档中提取出 7 个常见陷阱：

4.1 回声循环（Echo Loop）

问题：Agent A 发消息 → Agent B 回复 → Agent A 看到回复又回复 → 无限循环
社区解法：
- AutoGen: max_consecutive_auto_reply 参数
- Hermes: [CLOSED] 终止标记（已在用 ✓）
- 推荐：自发送消息不触发回复 + parent_msg_id 唯一性校验

4.2 角色边界模糊

问题：运维 Agent 做了决策，决策 Agent 去执行操作
社区解法：领域分离 + 权限矩阵
Hermes 状态：已有 Manas/Keeper/Mano 角色划分（已在用 ✓）

4.3 Rate Limit 冲突

问题：多个 Agent 同时发送消息触发 Discord 429
社区解法：共享 discord.py 的 HTTPClient（同 bot 实例自然共享）
Hermes 状态：单 Bot 模式天然规避 ✓

4.4 状态同步失败

问题：Agent A 关机后重新上线，Agent B 已经发了 5 条消息
社区解法：Discord channel history 做状态重建
Hermes 状态：session_search 做 cross-session 上下文（已在用 ✓）

4.5 消息顺序混乱

社区解法：带 sequence_num 序列号，或使用 thread 做线性会话

4.6 安全与认证

推荐：from 字段 + #bot 专用频道（Hermes 已有 ✓）

4.7 dead Agent 检测

社区解法：Heartbeat 机制
Hermes：Keeper 的 gateway health cron（5 分钟 ✓）

五、针对 Hermes 现状的改进建议

✅ 已实践的最佳模式（不应动）

模式	Hermes 实现	判断
单 Bot + 多 Profile 路由	✓ Keeper/Manas/Mano 共享一个 bot	保持
@mention 路由	✓ `<@BOT_ID> [tag]` 协议	保持
`[CLOSED]` 终止协议	✓ 防止回声	保持
`[ACTION]` `[QUESTION]` `[BLOCKED]` 前缀	✓ 结构化标签	保持
角色分工 Manas/Keeper/Mano	✓ 三层分离	保持
频道纪律 bot	✓ 安静待命	保持
session_search 跨会话恢复	✓ memory 系统	保持

🔧 可增强的部分

建议	参考来源	说明
UUID-based msg_id	AutoGen/CAMEL 标准做法	当前缺 message dedup 能力
thread_id 支持多轮任务追踪	AutoGen “group chat”模式	复杂 task 需要有绑定上下文的机制
parent_msg_id 追踪对话链	ChatDev 消息链	多轮交互时知道回复哪条
超时重试协议	AutoGen max_turns	当前缺超时重试，Agent 不回复就静默丢失
structured JSON payload 替代纯文本	AgentScript/CrewAI Task	当前有前缀但 payload 是自由文本，解析成本高
Discord Embed 做状态可视化	AgentConnect	运维状态用 embed 比纯文本更可读
死 Agent 心跳通告	通用 heartbeat	Keeper 可定期向 bot 发 heartbeat JSON
跨 Agent 消息签名	HMAC 可选	防止频道被注入假 Agent 消息

六、总结

Hermes 当前的 Agent-Over-Discord 协作模式已经相当成熟。与 AutoGen/CrewAI/CAMEL 等主流框架比较后，Hermes 在以下方面领先：

✅ 单 Bot 多 Profile 模式避免了很多多 Bot 架构的 rate limit / 鉴权 / 消息竞争问题
✅ [CLOSED] 协议解决了回声循环——这是很多社区项目反复头疼的问题
✅ 角色分工比 AutoGen 的 RolePlaying 更干净
✅ session_search 提供了可用的跨会话记忆

主要差距（值得优先补齐）：

消息 ID + 线程 ID 的显式结构化——当前纯依赖 Discord 消息 ID，缺少 parent_msg_id 和 thread_id
JSON payload 替代自由文本——减少 Agent 解析开销
Heartbeat / 健康通告——给 bot 频道定期发 Agent 存活信号

知识库

探索

discordagent