跳转到主要内容
HermesAgent.Work
消息入口

Hermes Agent 消息入口 Gateway 中文指南

把 Hermes 接到 Telegram、Slack、Discord、飞书或企业微信时,重点是用户范围、频道隔离、权限边界和失败日志。

01 / 平台选择

先选最贴近工作场景的平台

个人先用 Telegram 跑通最小闭环;团队协作优先 Slack、飞书或企业微信;社群场景再考虑 Discord。

Telegram

个人使用、轻量通知

适合一个人先跑通,Bot Token 和 Chat ID 最容易验证。

Slack

团队协作、频道消息

适合研发、运营、客户成功团队,把工作流结果推到指定频道。

Discord

社区、公开讨论

适合社群、研究小组和公开频道,需要控制谁能触发命令。

飞书

国内团队办公

适合审批、项目群和知识库场景,权限边界要提前设计。

企业微信

客户运营、企业通知

适合内部通知和客户服务流程,群发动作必须人工确认。

02 / 接入流程

四步跑通 Gateway

创建 Bot 或应用

只申请当前工作流需要的权限。能读消息和发回复就不要先申请管理权限。

写允许名单

限定用户、群组或频道。测试时只放自己,稳定后再加团队成员。

设计会话隔离

个人私聊、团队频道和客户群要分开,避免上下文和 Memory 串场。

跑通通知闭环

从消息触发、Hermes 执行、返回结果到错误提醒,都要留一条可追踪日志。

常用命令和测试口令

命令行先启动 Gateway,再到聊天窗口里测试 `/status`、`/model`、`/skills`。能稳定返回后,再接入真实工作流。

hermes gateway setup
hermes gateway start
hermes doctor

# 在目标聊天窗口里测试
/status
/model
/skills
03 / 安全边界

Gateway 必须先限权,再自动化

聊天入口会降低触发成本,也会放大误触发风险。把权限边界写清楚,比多接一个平台更重要。

默认只读:摘要、分类、草稿、查询可以先放开。
高风险动作必须确认:发邮件、删文件、改表格、开工单、群发通知都要二次确认。
不要把管理员 Token 放进默认 Gateway 环境。
命令入口要短,但输出要清楚:失败原因、下一步、是否需要人工处理。
长任务先返回“已开始”,完成后再推送结果,避免用户误以为卡死。
每个频道只接入明确场景,不要把所有工作流塞进一个群。
04 / 排错

Gateway 常见问题

收不到消息

检查 Bot 是否在目标群、是否开启事件订阅、Chat ID 是否匹配。

Hermes 执行了但没回复

看 Gateway 日志,确认发送权限、网络出口和平台限流。

回复到错误频道

检查会话映射和环境变量,清掉测试时期留下的 Chat ID。

多人触发串上下文

按用户或频道隔离会话,敏感任务强制新会话。

成本突然升高

限制触发频率,长消息先摘要,再进入模型处理。

05 / 子命令实务

gateway 子命令实务

hermes gateway 下挂着 run、start、stop、restart、status、install、uninstall、list、setup 一整组子命令。其中 setup 负责配置消息平台,前面的接入流程已经讲过;跑通之后,真正每天用到的是下面这几组。

前台 run 还是后台 install

hermes gateway run 在前台运行,日志直接打在当前终端,官方推荐 WSL、Docker、Termux 这三类环境用它,因为它们的服务管理往往不可靠。hermes gateway install 则把 Gateway 注册成 systemd(Linux)或 launchd(macOS)后台服务,开机自启,适合长期挂在 VPS 或常开的 macOS 机器上。拿不准选哪种,就先用 run 跑几天,确认稳定后再 install 转成常驻服务。

状态、重启与多 profile

改完配置用 hermes gateway restart 重启进程;拿不准进程是否活着,先看 hermes gateway status。同一台机器维护多个 profile 时,hermes gateway list 能一次列出每个 profile 的 Gateway 状态。临时停用走 stop,彻底移除后台服务再用 uninstall。

私聊先过 pairing 配对

Gateway 在线不等于谁都能用。hermes pairing 管理私聊配对码,决定哪些人能在私聊里使用这个 Bot。建议平台接通后第一时间设置配对授权,然后再考虑把 Bot 拉进群聊。配对授权和前面讲的允许名单是两道不同的闸:一道管私聊,一道管频道,两道都设好,入口才算收紧。

一个进程,全部平台

官方描述里,单一 Gateway 进程同时承载 Telegram、Discord、Slack、WhatsApp、Signal、Weixin(微信)等全部已接平台,还支持语音转写和跨平台会话连续,不需要为每个平台单独起服务。WhatsApp 的接入走独立的 hermes whatsapp 设置命令,Slack 则用 hermes slack 生成应用 manifest。

hermes send:不经 LLM 的推送通道

通知类场景不需要每次都唤醒模型。hermes send 把任意 shell 文本直接推到已配置的平台:不经过 LLM、不启动 agent 循环;Telegram、Discord、Slack、Signal 这类 Bot Token 平台甚至不要求 Gateway 进程在跑。凭证复用 ~/.hermes/.env 和 ~/.hermes/config.yaml,所以脚本和 crontab 里可以直接调用。目标支持四种写法:platform(主频道)、platform:chat_id、platform:chat_id:thread_id、platform:#channel-name。长内容用 --file 发 Markdown 文件,--subject 加一行标题,记不住目标就先用 --list 查一遍;脚本里要判断发送结果,加 --json 拿 JSON 返回,定时任务不想刷屏再加 --quiet。

hermes gateway run        # 前台运行,WSL / Docker / Termux 推荐
hermes gateway install    # 注册 systemd / launchd 后台服务
hermes gateway list       # 列出所有 profile 的 Gateway 状态

hermes send --to telegram "deploy finished"
hermes send --to discord:#ops --file /tmp/report.md
echo "RAM 92%" | hermes send --to telegram:-1001234567890
hermes send --list telegram
06 / 下一步

接上工作流前,先跑一个低风险任务

建议先用日报、Issue 分类、内容摘要这类只读任务验证 Gateway。稳定后再接入外部系统动作。

查看工作流模板