Hermes 集成

Hermes Telegram 接入思路:Messaging Gateway 上线前的权限和触发词设计

把 Hermes 接进 Telegram 前,先设计触发范围、白名单、工具权限、memory 写入和回执策略,避免消息入口放大风险。

生态 预计 13 分钟 核验 2026/6/1
本页目录

完成结果

学完后你会留下什么

一份 Telegram 接入前检查清单:入口范围、触发词、用户白名单、工具权限、memory 写入和回执策略。

适合谁
想把 Hermes 放进 Telegram 私聊或小团队消息入口中的用户
开始前确认
  • Hermes CLI 已经可用
  • 了解 Messaging Gateway 的基本用途
  • 准备一个低风险 Telegram 测试入口

把 Hermes 接进 Telegram 很有吸引力:你不用打开终端,就能在消息入口里唤起 Agent。但消息入口越自然,越容易让风险自然扩散。

Telegram 接入的第一原则不是“让 Agent 能回复”,而是“让 Agent 只在该回复的时候回复,只做被允许的事”。

先选入口范围

推荐顺序:

  1. 个人私聊测试。
  2. 低风险测试群。
  3. 小团队白名单群。
  4. 更公开或高频的入口。

不要一开始就把 Hermes 放进真实工作群。群聊里会出现玩笑、临时讨论、半截上下文和敏感信息,这些都可能误触发 Agent。

Telegram 场景先分成 3 类

不是所有 Telegram 接入都一样。先分清你面对的是哪一种:

场景典型目标第一阶段建议
个人私聊助手随时提问、收提醒、查资料最适合起步
小团队协作群总结讨论、只读检查、回执提醒先白名单,再触发词
自动化投递入口cron 发送日报、告警、状态变更只做单向投递或低风险回执

如果你还没决定是哪一类,就先不要把“消息入口”和“自动化执行入口”混在一个 bot 上。

触发词设计

群聊场景建议使用明确触发词,例如:

  • @hermes
  • /agent
  • /summarize
  • /check

触发词应该和任务类型绑定。比如 /summarize 只做总结,/check 只做只读检查,不要让一个入口默认可以调用所有工具。

一个简单可落地的做法是先只开放两类命令:

  • 总结类:读消息、整理上下文、生成摘要。
  • 检查类:只读查询、状态说明、已知资料检索。

把写文件、执行脚本、发外部通知这类动作留到你已经跑通审批和日志之后。

白名单和身份边界

至少确认:

检查项建议
谁能触发先用白名单
哪些会话有效先限制 chat / group
是否允许多人连续触发测试期限制频率
是否能调用 tools默认只开放低风险工具
是否能写 memory默认人工确认

如果一个消息入口可以触发写文件、调用 API 或发送外部消息,它就不再是普通聊天入口,而是自动化入口。

建议额外写清两件事:

  1. 哪些消息即使带了触发词也应该拒绝,例如涉及部署、删除、批量发送的动作。
  2. 机器人在无法执行时如何回执,例如“已拒绝,因为当前群只开放只读检查”。

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。

继续学习

按当前任务继续推进