Telegram
个人使用、轻量通知
适合一个人先跑通，Bot Token 和 Chat ID 最容易验证。
01 / 平台选择
先选最贴近工作场景的平台
个人先用 Telegram 跑通最小闭环；团队协作优先 Slack、飞书或企业微信；社群场景再考虑 Discord。
Slack
团队协作、频道消息
适合研发、运营、客户成功团队，把工作流结果推到指定频道。
Discord
社区、公开讨论
适合社群、研究小组和公开频道，需要控制谁能触发命令。
飞书
国内团队办公
适合审批、项目群和知识库场景，权限边界要提前设计。
企业微信
客户运营、企业通知
适合内部通知和客户服务流程，群发动作必须人工确认。
四步跑通 Gateway
创建 Bot 或应用
只申请当前工作流需要的权限。能读消息和发回复就不要先申请管理权限。
写允许名单
限定用户、群组或频道。测试时只放自己，稳定后再加团队成员。
设计会话隔离
个人私聊、团队频道和客户群要分开，避免上下文和 Memory 串场。
跑通通知闭环
从消息触发、Hermes 执行、返回结果到错误提醒，都要留一条可追踪日志。
常用命令和测试口令
命令行先启动 Gateway，再到聊天窗口里测试 `/status`、`/model`、`/skills`。能稳定返回后，再接入真实工作流。
hermes gateway setup
hermes gateway start
hermes doctor
# 在目标聊天窗口里测试
/status
/model
/skills03 / 安全边界
Gateway 必须先限权，再自动化
聊天入口会降低触发成本，也会放大误触发风险。把权限边界写清楚，比多接一个平台更重要。
默认只读：摘要、分类、草稿、查询可以先放开。
高风险动作必须确认：发邮件、删文件、改表格、开工单、群发通知都要二次确认。
不要把管理员 Token 放进默认 Gateway 环境。
命令入口要短，但输出要清楚：失败原因、下一步、是否需要人工处理。
长任务先返回“已开始”，完成后再推送结果，避免用户误以为卡死。
每个频道只接入明确场景，不要把所有工作流塞进一个群。
04 / 排错
Gateway 常见问题
收不到消息
检查 Bot 是否在目标群、是否开启事件订阅、Chat ID 是否匹配。
Hermes 执行了但没回复
看 Gateway 日志，确认发送权限、网络出口和平台限流。
回复到错误频道
检查会话映射和环境变量，清掉测试时期留下的 Chat ID。
多人触发串上下文
按用户或频道隔离会话，敏感任务强制新会话。
成本突然升高
限制触发频率，长消息先摘要，再进入模型处理。
05 / 下一步
查看工作流模板接上工作流前，先跑一个低风险任务
建议先用日报、Issue 分类、内容摘要这类只读任务验证 Gateway。稳定后再接入外部系统动作。