hermes教程-网关内部机制

关键文件

架构概览

┌─────────────────────────────────────────────────┐
│                  GatewayRunner                  │
│                                                 │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐       │
│  │ Telegram │  │ Discord  │  │  Slack   │       │
│  │ Adapter  │  │ Adapter  │  │ Adapter  │       │
│  └────┬─────┘  └────┬─────┘  └────┬─────┘       │
│       │             │             │             │
│       └─────────────┼─────────────┘             │
│                     ▼                           │
│              _handle_message()                  │
│                     │                           │
│         ┌───────────┼───────────┐               │
│         ▼           ▼           ▼               │
│  Slash command   AIAgent    Queue/BG            │
│    dispatch      creation   sessions            │
│                     │                           │
│                     ▼                           │
│                 SessionStore                    │
│              (SQLite persistence)               │
└───────┴─────────────┴─────────────┴─────────────┘

消息流程

当消息从任何平台到达时：

1. 平台适配器 接收原始事件，将其标准化为 MessageEvent
2. 基础适配器 检查活跃会话守卫：
   • 如果该会话的代理正在运行 → 将消息加入队列，设置中断事件
   • 如果是 /approve、/deny、/stop → 绕过守卫（内联分发）
3. GatewayRunner._handle_message() 接收事件：
   • 通过 _session_key_for_source() 解析会话键（格式：agent:main:{platform}:{chat_type}:{chat_id}）
   • 检查授权（见下文授权部分）
   • 检查是否为斜杠命令 → 分发给命令处理器
   • 检查代理是否已在运行 → 拦截 /stop、/status 等命令
   • 否则 → 创建 AIAgent 实例并运行对话
4. 响应 通过平台适配器发送回去

会话键格式

会话键编码了完整的路由上下文：

例如：agent:main:telegram:private:123456789

支持线程的平台（Telegram 论坛主题、Discord 线程、Slack 线程）可能会在 chat_id 部分包含线程 ID。切勿手动构造会话键 — 始终使用 gateway/session.py 中的 build_session_key()。

两级消息守卫

当代理正在运行时，传入的消息会经过两个顺序守卫：

1. 第一级 — 基础适配器（gateway/platforms/base.py）：检查 _active_sessions。如果会话处于活动状态，则将消息加入 _pending_messages 队列并设置中断事件。这会在消息到达网关运行器之前捕获它们。

2. 第二级 — 网关运行器（gateway/run.py）：检查 _running_agents。拦截特定命令（/stop、/new、/queue、/status、/approve、/deny）并适当路由。其他所有命令都会触发 running_agent.interrupt()。

在代理被阻塞时必须到达运行器的命令（如 /approve）通过 await self._message_handler(event) 内联分发 — 它们绕过后台任务系统以避免竞态条件。

授权

网关使用多层授权检查，按顺序评估：

1. 按平台允许所有标志（例如 TELEGRAM_ALLOW_ALL_USERS）— 如果设置，该平台上的所有用户均被授权
2. 平台允许列表（例如 TELEGRAM_ALLOWED_USERS）— 逗号分隔的用户 ID
3. DM 配对 — 已认证用户可以通过配对码配对新用户
4. 全局允许所有（GATEWAY_ALLOW_ALL_USERS）— 如果设置，所有平台上的所有用户均被授权
5. 默认：拒绝 — 未授权用户被拒绝

DM 配对流程

管理员：/pair
网关："配对码：ABC123。分享给用户。"
新用户：ABC123
网关："已配对！您现在已获得授权。"

配对状态持久化在 gateway/pairing.py 中，重启后仍然保留。

斜杠命令分发

网关中的所有斜杠命令都通过相同的解析管道：

1. hermes_cli/commands.py 中的 resolve_command() 将输入映射到规范名称（处理别名、前缀匹配）
2. 规范名称与 GATEWAY_KNOWN_COMMANDS 进行比对
3. _handle_message() 中的处理器根据规范名称进行分发
4. 某些命令受配置门控（CommandDef 上的 gateway_config_gate）

运行中代理守卫

在代理处理期间不得执行的命令会被提前拒绝：

if _quick_key in self._running_agents:
    if canonical == "model":
        return "⏳ 代理正在运行 — 请等待其完成或使用 /stop 停止。"

绕过命令（/stop、/new、/approve、/deny、/queue、/status）有特殊处理。

配置来源

网关从多个来源读取配置：

与 CLI（使用带有硬编码默认值的 load_cli_config()）不同，网关通过 YAML 加载器直接读取 config.yaml。这意味着 CLI 默认字典中存在但用户配置文件中不存在的配置键在 CLI 和网关之间可能表现不同。

平台适配器

每个消息平台在 gateway/platforms/ 中都有一个适配器：

gateway/platforms/
├── base.py              # BaseAdapter — 所有平台的共享逻辑
├── telegram.py          # Telegram Bot API（长轮询或 webhook）
├── discord.py           # 通过 discord.py 的 Discord 机器人
├── slack.py             # Slack Socket 模式
├── whatsapp.py          # WhatsApp Business Cloud API
├── signal.py            # 通过 signal-cli REST API 的 Signal
├── matrix.py            # 通过 mautrix 的 Matrix（可选 E2EE）
├── mattermost.py        # Mattermost WebSocket API
├── email.py             # 通过 IMAP/SMTP 的电子邮件
├── sms.py               # 通过 Twilio 的短信
├── dingtalk.py          # 钉钉 WebSocket
├── feishu.py            # 飞书/ Lark WebSocket 或 webhook
├── wecom.py             # 企业微信回调
├── weixin.py            # 通过 iLink Bot API 的个人微信
├── bluebubbles.py       # 通过 BlueBubbles macOS 服务器的 Apple iMessage
├── qqbot/               # QQ 机器人（腾讯 QQ）通过官方 API v2（子包：adapter.py、crypto.py、keyboards.py 等）
├── yuanbao.py           # 元宝（腾讯）私聊/群聊适配器
├── feishu_comment.py    # 飞书文档/云盘评论回复处理器
├── msgraph_webhook.py   # Microsoft Graph 变更通知 webhook（Teams、Outlook 等）
├── webhook.py           # 入站/出站 webhook 适配器
├── api_server.py        # REST API 服务器适配器
└── homeassistant.py     # Home Assistant 对话集成

适配器实现通用接口：

• connect() / disconnect() — 生命周期管理
• send_message() — 出站消息投递
• on_message() — 入站消息标准化 → MessageEvent

令牌锁

使用唯一凭据连接的适配器在 connect() 中调用 acquire_scoped_lock()，在 disconnect() 中调用 release_scoped_lock()。这防止两个配置文件同时使用同一个机器人令牌。

投递路径

出站投递（gateway/delivery.py）处理：

• 直接回复 — 将响应发送回原始聊天
• 主频道投递 — 将定时任务输出和后台结果路由到配置的主频道
• 显式目标投递 — send_message 工具指定 telegram:-1001234567890，或 hermes send CLI 包装同一工具用于 shell 脚本
• 跨平台投递 — 投递到与原始消息不同的平台

定时任务投递不会镜像到网关会话历史中 — 它们仅存在于自己的定时任务会话中。这是有意为之的设计选择，以避免消息交替违规。

钩子

网关钩子是响应生命周期事件的 Python 模块：

网关钩子事件

钩子从 gateway/builtin_hooks/（一个扩展点 — 当前在发布版本中为空；_register_builtin_hooks() 是一个无操作存根）和 ~/.hermes/hooks/（用户安装）中发现。每个钩子是一个包含 HOOK.yaml 清单和 handler.py 的目录。

记忆提供者集成

当启用记忆提供者插件（例如 Honcho）时：

1. 网关为每条消息创建一个带有会话 ID 的 AIAgent
2. MemoryManager 使用会话上下文初始化提供者
3. 提供者工具（例如 honcho_profile、viking_search）通过以下方式路由：

AIAgent._invoke_tool()
  → self._memory_manager.handle_tool_call(name, args)
    → provider.handle_tool_call(name, args)

4. 在会话结束/重置时，触发 on_session_end() 进行清理和最终数据刷新

记忆刷新生命周期

当会话被重置、恢复或过期时：

1. 内置记忆被刷新到磁盘
2. 记忆提供者的 on_session_end() 钩子触发
3. 一个临时的 AIAgent 运行一个仅记忆的对话轮次
4. 然后上下文被丢弃或归档

后台维护

网关在消息处理的同时运行定期维护：

• 定时任务触发 — 检查作业计划并触发到期的作业
• 会话过期 — 超时后清理废弃的会话
• 记忆刷新 — 在会话过期前主动刷新记忆
• 缓存刷新 — 刷新模型列表和提供者状态

进程管理

网关作为长期运行的进程运行，通过以下方式管理：

• hermes gateway start / hermes gateway stop — 手动控制
• systemctl（Linux）或 launchctl（macOS）— 服务管理
• PID 文件位于 ~/.hermes/gateway.pid — 配置文件作用域的进程跟踪

配置文件作用域 vs 全局：start_gateway() 使用配置文件作用域的 PID 文件。hermes gateway stop 仅停止当前配置文件的网关。hermes gateway stop --all 使用全局 ps aux 扫描来杀死所有网关进程（用于更新时）。

相关文档

• 会话存储
• 定时任务内部机制
• ACP 内部机制
• 代理循环内部机制
• 消息网关（用户指南）