Hermes Agent 在 Telegram 上没响应：快速排查指南
Hermes Agent 的 Telegram 机器人突然不出声。按顺序走查 allowed-users、令牌被吊销、409 冲突、隐私模式、网关掉线等最常见的原因。
机器人刚才还好，现在却没反应
你发了一条消息，什么都没回。机器人还在聊天里，头像也在，就是不回复。这是 Hermes Agent 在 Telegram 上最常见的故障，而人们在它上面花掉一小时的原因几乎总是相同的：还没搞清哪一层坏了，就急着乱试修复。
Hermes 在 Telegram 上其实是三层叠起来的。Hermes 智能体进程（负责推理和工具调用）。Hermes 网关（对 Telegram 做 long-polling）。以及 Telegram 本身（BotFather 配置、allowed users、隐私模式）。当机器人沉默时，故障刚好落在其中一层，最快的返回路径是先隔离出是哪一层，再动手改。
本文按能最快命中常见原因的顺序，逐一走查。如果你已经读过更全面的 Telegram 故障排查指南，这一篇是"完全没回复"这种具体症状下更短、以症状为线索的版本。
检查 1：你的用户 ID 是否真的在允许列表里
十次里有九次就是这个原因。只要你的 Telegram 数字 ID 不在 telegram_allowed_users 中，Hermes 就不会回复。机器人收到了消息，网关也做了路由，但 Hermes 会静默地丢弃它。从你的视角看，和机器人死掉毫无区别。
这里通常会出两种问题：
- 你填了
@用户名而不是数字 ID。@用户名不是 Hermes 想要的。在 Telegram 里给@userinfobot发送/start，复制它回复的那串数字，用那个。 - 你在上次重启之后新加了用户，但一直没重新加载配置。Hermes 在启动时读取
telegram_allowed_users。改好后请重启网关。
配置文件位于 config.yaml：
telegram_allowed_users: "123456789,987654321"
如果你在用 Hermify，对应字段在控制台的凭据表单里。
检查 2：先确认网关真的在跑
在把锅甩给 Telegram 之前，先确认网关是活着的。
hermes gateway status
如果没有在跑，问题就是它。启动它：
hermes gateway start
如果在跑但机器人还是不出声，在发测试消息的同时跟着看日志：
tail -f ~/.hermes/logs/agent.log
你要在里面找三种线索之一。出现 "message received" 说明网关工作正常，是 Hermes 在静默丢弃消息（回到检查 1）。出现 "409 Conflict" 说明有两个进程在用同一个令牌做轮询（见检查 4）。什么都没有则说明网关没能连到 Telegram（见检查 5）。
检查 3：机器人令牌是否仍然有效
BotFather 允许吊销令牌，很容易发生这样的事：吊销了旧测试机器人的令牌，然后忘了这回事，接着奇怪为什么一切都不管用。
打开 Telegram，给 @BotFather 发消息，发送 /mybots，选中你的机器人，点 API Token，把显示出来的字符串一个字符一个字符地和 Hermes 配置里的做比对。两者必须一致。如果不一致，要么把当前令牌粘回 Hermes 并重启，要么在 BotFather 里点 Revoke current token 生成新令牌，再粘进去。
无效令牌会在启动时在 Hermes 日志里以 "Unauthorized" 错误的形式暴露出来。看到这个错误，一定是令牌的问题。
检查 4：是不是两个进程在对同一个机器人做轮询
Telegram 的 Bot API 对每个 bot 令牌只允许一个 long-poll 消费者。如果两个进程同时调用 getUpdates，Telegram 会返回 "409 Conflict: terminated by other getUpdates request"，之后每一轮的更新只会去到胜出的那个进程，或者哪个都不去。在你看来，机器人像是一条消息一条不回。
出现这种情况的常见方式并不奇怪：
- 一个 systemd unit 在跑 Hermes，你又在 tmux 里手动开了一个 Hermes 会话。
- 你在笔记本上测试开发用的机器人，但生产实例用的是同一个令牌。
- 你临时起了个后台 worker，忘了旧容器还在跑。
找出重复的进程：
ps aux | grep -E 'telegram|hermes' | grep -v grep
杀掉不想保留的那个，然后重启剩下的那个。几秒钟内 409 就会停下，因为一旦"输"的那一方断开，Telegram 就会释放过期的 long-poll 会话。
检查 5：群里的沉默通常是隐私模式
如果机器人在私聊里能回，但在群里不回，元凶几乎一定是 Telegram 的机器人隐私模式，而不是 Hermes。
所有新建的机器人默认都开启隐私模式。这意味着机器人只能看到直接 @ 它、回复它某条消息，或作为命令发送的消息。群里的普通聊天永远到不了你的 Hermes 网关。
两种解决方式：
- 把机器人设为群管理员。 管理员机器人能看到全部消息，是最不容易踩坑的选项。
- 关闭隐私模式。 在 BotFather 发送
/setprivacy，选中机器人，选择 Disable。之后把机器人从群里移出，再重新加回来。隐私模式的调整只有在下次加入群时才会生效。
如果你的机器人跑在论坛话题或线程里，还要确认 Hermes 配置的 allowed_chats 和 topic ID 覆盖了那个具体线程。一个有权限在"通用"频道说话的机器人，如果那个"运维"话题的 topic ID 不在名单上，仍然会保持沉默。
检查 6：你的网络在杀 long-poll
如果机器人开始时能回一次，然后每次都在几乎相同的时间段里沉默、之后又活过来，说明你的网络在 Telegram 有机会推送更新之前，就把空闲的 long-poll 关掉了。家用路由器、便宜的 VPS、公司网络经常因为 NAT 空闲超时而这样做。
打开 debug 日志观察一下：
export HERMES_LOG_LEVEL=debug
hermes gateway restart
以固定间隔反复出现的 "connection reset" 就能确认这个诊断。缩短 Hermes 的 poll timeout，让它比你网络的空闲超时更早地重新连接：
hermes config set messaging.telegram.poll_timeout 30
默认是 60。改成 30 或更小，重置问题就会消失，因为你能在网络"不耐烦"之前就完成并重新打开 long-poll。这和很多"本地能跑，部署后就坏"的故事在廉价基础设施上有着同样的根因。
检查 7：智能体循环因供应商错误静默崩溃
网关活着，令牌没问题，允许列表也对，可是回复就是不来。检查日志中最后一次成功回复附近是否有模型供应商的错误。速率限制、配额耗尽和 LLM 供应商的 5xx 响应在某些 Hermes 版本里会让智能体循环崩溃，且不会自动重启。网关继续轮询，收到你新发的消息，把它交出去，但对面已经没人接了。
修复方法是重启，加上去供应商的控制台确认底层问题。如果你在某家供应商的免费档，聊天进行到一半用完当日配额，机器人在配额窗口翻页之前都会显得"不响应"。升级到付费计划，或在 Hermes 配置里切到另一家供应商，然后重启网关。
一个两分钟就能定位的诊断顺序
赶时间的时候按这个顺序走，我们见到的所有真实案例都能在两分钟内锁定原因：
hermes gateway status：网关起了吗？tail -f ~/.hermes/logs/agent.log：一条新消息真的传到 Hermes 了吗？- 传到了：检查
telegram_allowed_users。 - 没传到：在日志里找 "409 Conflict"（重复轮询）或 "Unauthorized"（令牌被吊销）。
- 以上都不是，且机器人只在群里沉默：隐私模式。
- 以上都不是，且它按固定节奏沉默：网络的空闲超时。
- 以上都不是，且它是从可用状态突然沉默：上游供应商崩溃。
干脆跳过整个排查循环
上面每一条检查都存在，是因为 Telegram、网关、Hermes 和你的供应商是四个可以彼此独立故障的活动部件。当它们都在你的基础设施里时，每次有一个掉链子，被叫起来的人都是你。
Hermify 是一个托管的 Hermes Agent，运行在 Telegram 上。你只需要在控制台里录入一次 bot 令牌、allowed users 列表和供应商密钥。网关、重启、日志采集和重连逻辑由我们负责。当上游出问题时，控制台里的状态卡片会告诉你是哪一层，一键即可重启。你不用再打开 ~/.hermes/logs/agent.log，除非你真的想看。
开始使用 Hermify，大约一分钟就能把机器人重新拉回线上，记忆始终归你所有。