一个 Agent 如何同时出现在多个聊天软件里？拆解消息网关机制
摘要
一个 Agent 能同时出现在多个聊天软件里，是因为聊天软件只是入口，Agent 才是持续工作的主体。消息网关负责三件事：把微信、飞书、QQ 等平台格式各异的消息标准化成统一请求；根据已连接配置把请求路由到同一个 Agent，而不是为每个平台复制一份人格和记忆；执行完成后把结果投递回原来那个平台的那一条会话。因为身份（SOUL.md）、记忆（USER.md、MEMORY.md）、技能（skills/）和自动任务都存放在通道之外，所以你在微信说过的事，在飞书继续问时它依然知道。但统一不等于没有边界：每个通道有各自的授权方式、消息格式与投递限制，新接一个通道后必须先发测试消息确认回复落到了预期会话。
引子：同一个助理，为什么能在不同 App 里接着聊
设想这样一段使用过程：你在微信上让 Agent 帮你梳理一个项目的进展，中午出门时在飞书上追问"刚才那个方案里第二条的风险是什么"，晚上又在 QQ 群里让它把结论发出来。
如果这三次交互像三个互不相识的机器人，那多平台接入就没有价值——你得在每个平台重新交代一遍背景。真正有用的形态是：三个入口，同一个助理。
这件事的难点常被误解为"多对接几个 API"。对接 API 只是最表层的工作量。真正的难点是：让所有入口指向同一份身份与上下文，同时不破坏各平台自己的规则。 消息网关就是解决这个矛盾的那一层。
一、先纠正一个概念：通道不是 Agent
这是理解整套机制的前提。
| 概念 | 它是什么 | 数量关系 |
|---|---|---|
| 通道（Channel） | 消息进出的入口，例如微信、飞书、QQ | 一个 Agent 可连接多个 |
| Agent | 持续存在的工作主体，持有身份、记忆、技能、任务 | 多个通道共享同一个 |
很多人下意识把"我在微信上的机器人"当作一个独立实体，于是自然产生"那我在飞书上是不是另一个机器人"的疑问。把通道理解为入口而非主体，这个疑问就消失了。
整条链路可以这样表示：
聊天软件（多个入口）
↓ 平台原生消息
消息网关（标准化 / 路由 / 投递）
↓ 统一请求
同一个 Hermes Agent
↓
模型推理 + 工具执行 + 记忆召回 + Skills 装载
↓ 执行结果
消息网关
↓ 按平台格式投递
原通道的原会话注意最后一步"原通道的原会话"。这不是细节，而是网关必须精确处理的核心问题之一——下面会具体讲。
二、网关做的第一件事：接收并标准化
不同平台在几乎每个维度上都不一样：
- 用户标识不同：有的用数字 ID，有的用手机号，有的用平台内部的用户名。
- 会话标识不同：单聊、群聊、频道、话题（thread）的表示方式各不相同。
- 消息结构不同：文本、图片、语音、文件、引用回复、表情反应的字段设计各有一套。
- 事件模型不同：有的通过 Webhook 推送，有的需要长连接或轮询。
如果让 Agent 直接面对这些差异，Agent 内部就会长出大量平台分支逻辑，每接一个新平台都要改核心代码。标准化这一步的作用，就是把这些差异收敛在网关层：把平台原生消息转换成统一的处理请求，让 Agent 只需要理解一种输入格式。
这带来一个直接好处：新增一个通道，理论上不需要改动 Agent 的身份、记忆与技能逻辑。 Agent 关心的是"有人问了什么"，而不是"这句话来自哪个 App 的哪种字段结构"。
三、网关做的第二件事：路由到同一个 Agent
这是"多平台同一人格"能够成立的关键环节。
网关收到标准化请求后，依据已连接配置判断这条消息属于哪个 Agent，然后把请求交给那个 Agent 处理。它不会因为消息来自新平台就临时创建一个新的人格或新的记忆库。
这一步之所以重要，是因为它决定了长期资产是共享还是分裂：
| 资产 | 存放位置 | 多通道下的行为 |
|---|---|---|
| 身份与行为准则 | SOUL.md | 所有通道共享同一份 |
| 用户画像 | USER.md | 所有通道共享同一份 |
| 跨会话事实 | MEMORY.md / memories/ | 所有通道共享同一份 |
| 方法沉淀 | skills/ | 所有通道共享同一份 |
| 自动任务 | Agent 层配置 | 与通道解耦，可指定投递通道 |
因为这些资产都在通道之外，所以"你在微信说过的项目名，在飞书继续问时它依然知道"不是额外做的同步功能，而是架构的自然结果——它们本来就只有一份。
这与"换模型不丢记忆"是同一种解耦思路：把易变的接入层与稳定的资产层分开。 关于模型层与 Agent 层的解耦，可参考《Hermes Agent 的"大脑"可以替换吗？模型层与 Agent 层如何分工》。
四、网关做的第三件事：把结果投递回正确的位置
Agent 执行完毕后，网关要把结果送回去。"送回去"比听起来复杂，因为它必须同时答对三个问题：
- 回哪个平台：这条消息从微信来，就要回微信，不能回到飞书。
- 回哪个会话：同一平台上你可能有单聊、多个群、多个频道。回错会话不只是体验问题，在群聊场景下可能造成信息泄露。
- 用什么格式：各平台对消息长度、Markdown 支持程度、图片与文件发送方式、是否支持引用回复的规定都不同。同一段内容在不同平台需要不同的呈现方式。
第二点值得特别强调。投递目标错误是多通道场景下后果最严重的一类问题：把本该私聊回复的内容发到了群里，或者把 A 群的讨论结论发到了 B 群。这也是为什么每接入一个新通道，都应该先在一个安全的会话里发测试消息验证。
五、统一不等于没有边界
"一个 Agent 多个入口"容易被理解成"所有平台完全一致"。实际上每个通道仍保有自己的约束，这些约束不会因为共享 Agent 而消失。
5.1 授权方式不同
每个平台的连接方式与凭据形态都不一样：有的需要在平台开发者后台创建机器人并获取 Token，有的需要扫码授权，有的需要 AppID 与 AppSecret。这意味着连接每个通道都是一次独立的授权动作，不能一次配置全部生效。
5.2 支持的通道范围是有限的
LightVela 当前支持的通道是微信、飞书、QQ，都是国内常用的消息平台。这个范围不是"任意 IM 都能接"，因此规划使用方式前应先确认目标平台在支持范围内。
看到某些文档或社区内容里提到其他消息平台时，要以「配置通道」文档实际列出的通道为准，不要按未支持的平台来设计流程。
5.3 群聊语境与单聊语境不同
单聊里 Agent 面对一个人，群聊里它面对一群人。群聊需要额外考虑：什么时候该应答、什么时候该沉默、哪些内容不适合在群里展开、谁有权限触发敏感操作。这些属于行为准则与权限设计的范畴，不是网关能自动决定的。
5.4 投递能力不同
消息长度上限、是否支持富文本、能否发送文件、能否引用特定消息——这些差异会直接影响输出形态。一段在飞书里能正常展示的长回复，在另一个平台可能需要拆分或简化。
六、接入新通道的实操顺序
把上面的原理落到操作上，建议按这个顺序做，能避免大部分问题。
- 先确认区域支持：确认目标通道在你所在的区域可用，避免照着另一区域的文档操作。
- 完成平台侧授权：按对应通道文档在平台侧创建机器人或完成授权，取得所需凭据。凭据属于敏感信息，不要写进长期上下文文件，也不要粘贴到聊天里。
- 在产品侧完成连接：填入凭据并保存，确认连接状态显示为已连接。
- 发一条测试消息：在一个安全的会话（建议先用单聊或测试群）发消息，确认 Agent 能回复。
- 确认投递位置：重点检查回复是否落在你发消息的那一条会话里，而不是别的会话。
- 验证记忆是否共享：问一件你在其他通道说过的事。如果它答得出来，说明这个新通道确实路由到了同一个 Agent。
- 再考虑群聊接入：单聊验证通过后，再考虑加入群聊，并同步确认群内的应答边界是否符合预期。
第 6 步是很多人会跳过、但价值很高的一步——它是"通道共享同一个 Agent"这件事最直接的验证方法。
七、常见问题与判断方法
| 现象 | 更可能的原因 | 建议动作 |
|---|---|---|
| 新通道没有任何回复 | 授权未完成或凭据填写有误 | 检查连接状态与凭据，重新走授权流程 |
| 回复出现在别的会话 | 投递目标解析或配置有误 | 停止在群聊使用，先回到单聊定位问题 |
| 新通道回复了但"不认识我" | 可能连接到了另一个 Agent | 用一条已知事实验证，并核对连接配置指向的 Agent |
| 只有群聊不回、单聊正常 | 群内触发条件或权限设置 | 检查群聊应答规则与所需权限 |
| 长回复被截断或格式错乱 | 平台投递能力限制 | 调整输出长度与格式，适配该平台 |
其中第三行值得注意："不认识我"在多通道场景下的含义与换模型场景不同。 换模型时它通常是风格差异；而在新接通道时，它更可能意味着这个通道并没有指向你以为的那个 Agent。判断方法同样是拿一条确定的已知事实去问。
八、LightVela 的做法：把通道当作可插拔入口
Hermes 在机制上实现了通道与 Agent 的分离，但连接每个平台仍需要使用者自己处理凭据、回调与运行环境。LightVela 的方向是把这一层做成产品化的可插拔入口：
- 通道是配置项：在同一个 Agent 下按需连接或断开通道，不需要为每个平台各建一个 Agent。
- 资产天然共享：人格、记忆、技能、自动任务只有一份，新增通道即刻复用，不需要迁移或同步。
- 接入状态可见：管理台可确认通道是否显示为已接入，便于快速区分"没接入成功"与"接入了但没回复"。
- 支持范围明确：「配置通道」文档列出当前支持的通道（微信、飞书、QQ），避免按未支持的平台设计流程。
- 问题可追溯：出现异常时可查看诊断中心的近期日志，判断问题出在通道授权、投递还是任务本身。
小结
- 通道是入口，Agent 是主体。多个通道共享同一个 Agent，而不是每个平台一个机器人。
- 网关做三件事：标准化（收敛平台差异）、路由（交给同一个 Agent）、投递（回到原平台原会话）。
- 人格、记忆、技能、自动任务都在通道之外，所以跨通道的连续性是架构的自然结果，不是额外的同步功能。
- 统一不等于没有边界：授权方式、区域支持范围、群聊语境、投递能力，每个通道都不同。
- 接入新通道后必须验证两件事：回复是否落在预期会话，以及它是否确实共享同一份记忆。