Hermes Telegram 接入思路:Messaging Gateway 上线前的权限和触发词设计
适合谁
想把 Hermes 放进 Telegram 私聊或小团队消息入口中的用户
帮助用户在接入 Telegram 前先设计触发词、白名单、权限和长期记忆边界,而不是一开始开放所有消息。
交付物
学完后你会留下什么
一份 Telegram 接入前检查清单:入口范围、触发词、用户白名单、工具权限、memory 写入和回执策略。
开始前确认
前置条件
- Hermes CLI 已经可用
- 了解 Messaging Gateway 的基本用途
- 准备一个低风险 Telegram 测试入口
你会学到
Hermes Telegram
帮助用户在接入 Telegram 前先设计触发词、白名单、权限和长期记忆边界,而不是一开始开放所有消息。
教程内搜索
支持桌面与移动端。回车可直接搜索。
把 Hermes 接进 Telegram 很有吸引力:你不用打开终端,就能在消息入口里唤起 Agent。但消息入口越自然,越容易让风险自然扩散。
Telegram 接入的第一原则不是“让 Agent 能回复”,而是“让 Agent 只在该回复的时候回复,只做被允许的事”。
先选入口范围
推荐顺序:
- 个人私聊测试。
- 低风险测试群。
- 小团队白名单群。
- 更公开或高频的入口。
不要一开始就把 Hermes 放进真实工作群。群聊里会出现玩笑、临时讨论、半截上下文和敏感信息,这些都可能误触发 Agent。
Telegram 场景先分成 3 类
不是所有 Telegram 接入都一样。先分清你面对的是哪一种:
| 场景 | 典型目标 | 第一阶段建议 |
|---|---|---|
| 个人私聊助手 | 随时提问、收提醒、查资料 | 最适合起步 |
| 小团队协作群 | 总结讨论、只读检查、回执提醒 | 先白名单,再触发词 |
| 自动化投递入口 | cron 发送日报、告警、状态变更 | 只做单向投递或低风险回执 |
如果你还没决定是哪一类,就先不要把“消息入口”和“自动化执行入口”混在一个 bot 上。
触发词设计
群聊场景建议使用明确触发词,例如:
@hermes/agent/summarize/check
触发词应该和任务类型绑定。比如 /summarize 只做总结,/check 只做只读检查,不要让一个入口默认可以调用所有工具。
一个简单可落地的做法是先只开放两类命令:
- 总结类:读消息、整理上下文、生成摘要。
- 检查类:只读查询、状态说明、已知资料检索。
把写文件、执行脚本、发外部通知这类动作留到你已经跑通审批和日志之后。
白名单和身份边界
至少确认:
| 检查项 | 建议 |
|---|---|
| 谁能触发 | 先用白名单 |
| 哪些会话有效 | 先限制 chat / group |
| 是否允许多人连续触发 | 测试期限制频率 |
| 是否能调用 tools | 默认只开放低风险工具 |
| 是否能写 memory | 默认人工确认 |
如果一个消息入口可以触发写文件、调用 API 或发送外部消息,它就不再是普通聊天入口,而是自动化入口。
建议额外写清两件事:
- 哪些消息即使带了触发词也应该拒绝,例如涉及部署、删除、批量发送的动作。
- 机器人在无法执行时如何回执,例如“已拒绝,因为当前群只开放只读检查”。
memory 写入策略
Telegram 里的内容不等于长期事实。推荐规则:
只有明确表达长期偏好、项目约定、安全限制或稳定流程的信息,才允许写入 memory。
群聊里的临时讨论、情绪表达、未确认决定和敏感信息不写入 memory。
这条规则越早写清,后面越少清理负担。
一个实用的补充是,把 memory 写入改成显式动作,例如只有 /remember 或人工确认后才写入。这样你会少掉很多“为什么 bot 记住了不该记的东西”的排障成本。
和 cron 的关系
Telegram 也常被用作 cron delivery 目标。这里要分清:
- 用户在 Telegram 里主动触发 Hermes,是 gateway。
- Hermes 定时把结果发到 Telegram,是 cron delivery。
两者都需要消息范围和通知策略。不要让 cron 在深夜频繁刷屏,也不要让群聊临时消息触发长期任务。
如果同一个 Telegram 入口同时承担人工触发和 cron 投递,建议至少拆开:
- 不同 chat 或不同 topic。
- 不同命令前缀。
- 不同 profile 或不同 delivery 说明。
否则群里的人很容易分不清一条消息到底是手动触发结果,还是后台任务回执。
上线前的故障和风控设计
Telegram 接入真正麻烦的地方,不是“bot 能不能回消息”,而是回错消息、在错误的会话里回消息,或者持续刷屏。上线前先确认:
- bot 断线或重启后,是否会重复消费旧消息。
- 失败回执是否会暴露内部路径、密钥或敏感输出。
- 群聊里是否有人能一键暂停或移除 bot。
- 高频触发时是否有限流、冷却或最小间隔。
- 敏感操作是否明确回复“需要改走人工审批”。
上线前检查
- 第一个入口是低风险私聊或测试群。
- 群聊触发词明确。
- 触发用户有白名单。
- 高风险工具默认不可用。
- memory 写入需要确认。
- 失败时有可读回执。
- 可以快速暂停 gateway 或移除 bot。
可执行清单
- 先选一个个人私聊或测试群,不直接进真实业务群。
- 只开放总结类和只读检查类触发词。
- 白名单、限频和拒绝回执已经配置。
- memory 写入改为显式动作或人工确认。
- cron 投递和人工触发已经分开设计。
- 已准备暂停 bot、移除权限和清理错误消息的办法。
完成检查
- 你已经选定第一个 Telegram 测试入口。
- 你写清了触发词和白名单。
- 你没有开放全部工具权限。
- 你知道哪些消息不应该进入 memory。
- 你区分了 gateway 触发和 cron 投递。
下一步建议继续看 Hermes Messaging Gateway 教程、Hermes Cron 示例 和 Hermes Memory 指南,把消息入口、定时投递和长期记忆串成一套可控流程。
官方资料
继续深挖时,先看这些官方页面
本页内容已按官方文档和产品能力重写,下面这些链接适合你做版本核对和参数确认。
常见问题
你大概率还会继续搜这几个问题
把高频疑问写在教程页内,既减少跳出,也让这篇内容更适合收藏回看。
Hermes Telegram 接入应该先接群还是私聊?
建议先用个人私聊或低风险测试会话验证,再考虑小群。群聊中应设置触发词、白名单和高风险动作人工确认。
Telegram 消息都应该写入 memory 吗?
不应该。消息入口里的临时讨论很多,只有长期有效的项目约定、用户偏好和安全边界才适合写入 memory。
继续学习
下一步推荐
优先继续当前主题,再给一篇桥接内容,避免学习链路被打断。
Hermes Messaging Gateway:把 Agent 接进消息入口
理解 Hermes messaging gateway 的应用边界:先用低风险入口测试,再把 Telegram、Discord、Slack、WhatsApp 等入口放进长期工作流。
Hermes 应用Hermes Memory 实战:长期记忆适合存什么,不适合存什么
理解 Hermes persistent memory、USER.md、MEMORY.md、session search 和容量边界,避免把记忆用成垃圾桶。
Hermes 应用Hermes Cron 自动化:定时任务、后台检查与周期性提醒
Hermes cron 不只是定时提醒,它可以把 skills、profiles、workdir、消息投递和 no-agent watchdog 串成长期运行任务。
关联路径
同 Agent 与同意图内容
多 Agent 站点里,相关内容不只看分类,也要看 Agent 归属和搜索意图。
Hermes Agent 是什么:和 OpenClaw、普通聊天机器人的区别
用应用层视角理解 Hermes Agent:memory、skills、messaging gateway、cron、profiles 和从 OpenClaw 迁移到底意味着什么。
Hermes 安装Hermes Agent 安装与 Quickstart:第一次跑通完整清单
从安装命令、首次启动、模型配置到 gateway 前置检查,整理 Hermes Agent 第一次跑通时最该确认的顺序。
Hermes 迁移从 OpenClaw 迁移到 Hermes:能力映射、风险和回滚
把 OpenClaw 用户最关心的迁移问题拆成预览、配置映射、密钥策略、迁移后验收和回滚清单。
OpenClaw 集成OpenClaw Gateway 架构:channels、pairing、worker 是怎么协同的
理解 Gateway 在 OpenClaw 体系中的角色,才能知道为什么 channels、pairing 和审批都围着它转。
OpenClaw 集成OpenClaw Browser 工具:如何复用 Chrome 登录态做真正可用的网页任务
OpenClaw 的 Browser 工具不是“能开网页”就够了,关键在于会不会安全地复用你的登录状态。
OpenClaw 集成OpenClaw WhatsApp 接入教程:pairing、session 持久化与群聊策略
把 OpenClaw 接到 WhatsApp,不只要能登录,还要能理解 session、群聊和 selfChatMode 的边界。