前言

这篇笔记面向“微信负责收发消息，Hermes 负责对话、工具调用与定时任务”的部署方式。本文实际使用 DeepSeek 作为模型 Provider，由 Hermes Gateway 将回复投递到微信私聊。

为何不选 OpenClaw

OpenClaw 与 Hermes 都可以承担 Agent/Gateway 相关工作，但本次微信机器人并不需要把两者串联。Hermes 已经提供原生 Weixin 渠道，能够直接通过 iLink Bot 完成扫码登录、消息收发、会话处理和 Cron 投递，链路可以保持为：微信 -> Hermes Gateway -> 模型/Skills -> 微信。

若再加入 OpenClaw，就会多出一层 Gateway、微信登录态和模型配置；排障时也需要判断消息究竟卡在哪一层。更重要的是，同一个 Weixin token 不能被两个本地 Hermes Gateway 同时占用，实际部署中也应避免让多个网关争用同一微信登录态。因此，本方案保留 OpenClaw 的安装文件即可，但不启动、不配置微信桥接；微信机器人统一由 Hermes 原生渠道负责。

官方微信接入说明见：Hermes Weixin / iLink Bot 文档。

本文对应的服务器环境如下：

项目	当前值
系统	Ubuntu 22.04 LTS
服务器时区	Asia/Shanghai
Dashboard 默认端口	9119
Hermes 安装目录	/home/ubuntu/.hermes/hermes-agent/
当前消息渠道	微信私聊

1、先理解 Hermes 的核心运行组件

Hermes 不是一个只会聊天的单体程序，而是一组可以组合的组件。若目标是先把微信机器人跑起来，第一优先级应放在 Agent、Gateway、Dashboard、消息渠道、Skills 与 Cron 这些核心运行组件上；Memory、SOUL、MCP、Tirith 等能力可以在主链路稳定后再逐步接入。

组件	主要职责	本文中的实际角色
Hermes Agent	理解用户消息或任务提示词，选择模型与工具，生成最终回复	处理微信对话，调用 aihot Skill 并整理资讯
模型提供商（Model Provider）	为 Agent 提供推理与生成能力	DeepSeek / deepseek-v4-pro
Gateway	常驻的消息、会话、工具和 Cron 执行入口	接收微信、调用 Agent，并把结果回发微信
Dashboard	查看状态、配置和管理任务的 WebUI	按需开启，不承担消息收发
Skills（技能）	可被 Agent 按需读取的专业操作说明或工具能力	AI HOT 资讯查询、后续可安装的其他 Skill
Cron	按设定时间触发任务调度	每天 09:00 触发 AI HOT 简报任务
消息渠道适配层（Messaging Adapter）	将 Gateway 接到具体平台的渠道适配层	Hermes 原生 Weixin/iLink Bot
Tirith	Agent 调用 terminal 前的安全检查层	检查 AI HOT 等 Skill 发起的 Shell 命令

可先做一个简单区分：Gateway、Dashboard、微信渠道、Skills、Cron 属于这篇文章的主链路；MCP、Memory、SOUL 更偏向扩展能力；Tirith 则属于当 Agent 会调用 terminal 时才需要重点理解的安全执行层，相关内容在“安全与运维”中展开。

2、Hermes 安装、启动与运行方式

2.1 安装前的准备

请以 ubuntu 用户安装和运行 Hermes，不使用 sudo 把用户配置写到系统目录。当前官方安装文档提供一键安装脚本；执行前先阅读脚本来源，并确认服务器具备网络访问和可用磁盘空间。

curl -fsSL https://res1.hermesagent.org.cn/install.sh -o /tmp/hermes-install.sh
less /tmp/hermes-install.sh
bash /tmp/hermes-install.sh
source ~/.bashrc
hermes --version

需要从源码安装、指定 Python 版本或选择依赖组时，应以 Hermes 安装文档 为准。完成安装后，先执行初始化配置：选择模型 Provider 与模型、按需开启工具，再进入消息渠道设置。

hermes model
hermes tools
hermes gateway setup

本文服务器中的 Hermes 工作目录为 /home/ubuntu/.hermes/hermes-agent/。不要将 ~/.hermes/ 整个复制到另一个用户：其中可能包含账号登录态、密钥、会话和机器相关配置。迁移时只选择工作区、Skills、人格或记忆等明确需要的内容，微信登录态应在新用户下重新扫码配置。

2.2 让 Gateway 常驻运行

完成模型和微信配置后，需要先区分两个完全不同的运行对象。Gateway 是机器人的后台服务，应以用户级 systemd 服务常驻运行，持续接收微信消息、调用 Agent、维持会话并触发 Cron，即使没有浏览器连接也必须保持运行。Dashboard 是管理用的 Web 服务，监听服务器端口 9119，只在需要配置模型、查看状态或编辑定时任务时启动并访问；关闭浏览器、断开 SSH 隧道或停止 Dashboard，都不会停止 Gateway。

对比项	Gateway	Dashboard / WebUI
是否需要后台常驻	是；微信机器人与 Cron 依赖它	否；按需启动即可
主要职责	消息收发、Agent 调用、Skills、会话和定时任务	配置与管理 Hermes
访问方式	通过微信消息，不需要打开端口给浏览器	浏览器经 SSH 隧道或受认证保护的公网端口访问
停止后的影响	机器人不回复，Cron 不会触发	无法使用 WebUI；已保存的任务和 Gateway 不受影响

因此，服务器运维的优先级是“保证 Gateway 常驻”，而不是“保证 Dashboard 一直打开”。常用检查命令如下：

hermes status
hermes doctor
hermes gateway status

首次部署可按 Hermes 当前版本提供的服务管理命令将 Gateway 安装为当前用户的 systemd 服务，再启动并检查状态。本文环境已经采用用户级 systemd 常驻运行；日常只需确认服务状态和日志，不应为了关闭 WebUI 而停止 Gateway。

hermes gateway install
hermes gateway start
hermes gateway status
hermes logs --since 20m

[!warning] 版本差异
Hermes 的 CLI 会持续演进。若本机 hermes gateway install 或 start 的帮助信息与本文不同，优先执行 hermes gateway --help 并遵循当前版本的官方文档，不要猜测服务名或手动复制旧版 systemd 配置。

2.3 访问 Dashboard 的两种方式

无论采用哪种方式，都可以看到如下结果：

2.3.1 SSH 隧道：优先推荐

让 Dashboard 继续只监听服务器本机：

hermes dashboard --skip-build --host 127.0.0.1 --port 9119 --no-open

127.0.0.1 是服务器自己的回环地址，只接受服务器内部连接。此时：

• curl http://127.0.0.1:9119 在服务器上可以成功；
• http://1.12.51.69:9119 从公网无法连接；
• 即使腾讯云安全组开放 9119，也不能改变应用只监听本机的事实。

然后在本地 Windows PowerShell 建立隧道：

ssh -N -L 9119:127.0.0.1:9119 `
  -i "$HOME\.ssh\openclaw_gateway_ed25519" `
  ubuntu@1.12.51.69

示例中的 ubuntu 是本服务器可登录的 SSH 用户。迁移到自己的服务器时，请将 ubuntu@1.12.51.69 替换为实际的 用户名@服务器地址，并将 -i 后的私钥路径替换为自己的私钥文件。

保持 SSH 进程运行，浏览器打开：

http://127.0.0.1:9119

该方案不需要在腾讯云安全组开放 9119，Dashboard 也不会直接暴露到公网。

若本地 9119 已被占用，可以改用本地 9120：

ssh -N -L 9120:127.0.0.1:9119 `
  -i "$HOME\.ssh\openclaw_gateway_ed25519" `
  ubuntu@1.12.51.69

此时访问 http://127.0.0.1:9120。

2.3.2 公网访问：方便但需要额外防护

让 Dashboard 监听所有 IPv4 网卡：

hermes dashboard --host 0.0.0.0 --port 9119 --no-open

首次执行可能先构建 WebUI。构建完成且已有前端产物后，可使用：

hermes dashboard --skip-build --host 0.0.0.0 --port 9119 --no-open

示例如下：（默认是 9119 端口）

当前 Hermes 版本对非回环地址强制要求身份认证：

• 可以使用用户名和密码；
• 也可以通过 Nous Portal 配置 OAuth；
• --insecure 已弃用，不能绕过公网绑定的认证要求；
• 认证配置保存在 config.yaml 的 dashboard.basic_auth 下，不要把密码写入笔记或聊天记录。

公网访问还需要同时满足：

1. 腾讯云安全组允许 TCP 9119；
2. Ubuntu 防火墙允许 TCP 9119；
3. Dashboard 确实监听 0.0.0.0:9119；
4. 浏览器访问 http://1.12.51.69:9119。

检查监听地址：

sudo ss -ltnp | grep ':9119'

若启用了 UFW，可查看规则：

sudo ufw status

[!warning] 公网安全
用户名和密码只能解决基础身份认证，裸 HTTP 仍不会加密传输内容。长期公网使用时，建议在 Dashboard 前配置 Nginx/Caddy、HTTPS 和来源 IP 限制；仅个人使用时，SSH 隧道更省事也更安全。

2.4 Dashboard 的状态查看与停止

查看 Dashboard 状态：

hermes dashboard --status

停止所有 Dashboard 进程：

hermes dashboard --stop

如果当前是在前台运行 Dashboard，也可以在对应终端按 Ctrl+C。只有官方停止命令无效时，才按进程匹配发送普通终止信号：

pkill -TERM -f '/home/ubuntu/.hermes/hermes-agent/venv/bin/hermes dashboard'

停止后确认端口已经释放：

sudo ss -ltnp | grep ':9119'

没有输出表示 9119 已不再监听。停止 Dashboard 不会自动停止下面这个 Gateway 进程：

pgrep -af 'gateway run'

3、配置微信 ClawBot

本节的 ClawBot 指通过 Hermes 原生 Weixin/iLink Bot 渠道运行的微信机器人，而不是额外部署一个 OpenClaw 桥接服务。它的常驻链路是：微信消息到达 Hermes Gateway，Gateway 交给 Agent；Agent 使用 DeepSeek 和已启用的 Skills 生成回复，Gateway 再将结果回发微信。

3.1 配置微信渠道并扫码

在 ubuntu 用户下执行设置向导，选择 Weixin/微信渠道并按终端提示完成扫码。扫码生成的 iLink token 与账号信息属于登录态，应由 Hermes 保存到当前用户的 ~/.hermes/ 目录，不要复制到笔记、聊天记录或另一个用户的配置目录。

hermes gateway setup

配置完成后检查 Gateway 正在运行，并从微信向机器人发送一条普通私聊消息。若使用的是新的私信配对策略，终端或聊天中会显示配对码；在服务器上确认该请求：

hermes pairing approve weixin <code>

具体的二维码、环境变量和访问策略说明以 官方 Weixin 文档 为准。对于个人机器人，建议使用 pairing 或 allowlist 限制谁可以私聊；不要长期设为对所有人开放。

3.2 会话与投递目标

在机器人私聊中使用 /sethome 将当前聊天设为 Home Channel。这样 Cron 或通知类任务有明确的默认投递目的地。/clear 只清除当前聊天的对话上下文，用于重新开始一次会话；它不会删除 Gateway 配置、Skills、Cron 任务或微信登录态。

微信机器人正常回复的最小验证是：发送“请用一段完整的话介绍你能做什么”，确认能收到连贯的段落回复；再发送一个包含英文专有名词的问题，确认模型会保留必要的技术术语，而非强制翻译所有内容。

3.3 避免 token 冲突，并在一台服务器运行多个微信机器人

一个 Weixin token 同一时间只能由一个本地 Hermes Gateway 使用。若看到 Another local Hermes gateway is already using this Weixin token，先检查是否有重复启动的 Gateway，再停止旧进程或旧服务；不要反复扫码，也不要让 OpenClaw 与 Hermes 同时持有同一登录态。

hermes gateway status
pgrep -af 'gateway run'

如需在同一台服务器上运行第二个微信机器人，不需要新增服务器。可以使用 Hermes Profile 为每个机器人建立独立配置目录：default 保留原来的机器人，wx2 管理第二个机器人。它们拥有不同的微信登录态、会话、Skills、Cron 与配置，但仍共享同一台服务器的 CPU、内存、磁盘、网络，以及可能共用的模型 API Key 与额度。

同一台 Ubuntu 服务器
├─ default Profile -> Gateway -> 微信机器人 A
└─ wx2 Profile     -> Gateway -> 微信机器人 B

以下示例在当前的 ubuntu 用户下操作，因此 ~/.hermes/ 实际指向 /home/ubuntu/.hermes/；不要把路径写死为 /root/.hermes/。先创建第二个 Profile：

hermes profile create wx2 --clone

--clone 用于基于 default 创建 wx2。不同版本的实际复制范围可能不同，创建后应检查 ~/.hermes/profiles/wx2/，尤其关注模型凭据、SOUL、Skills、Cron、sessions 与微信账号缓存；不要假设第二个机器人会继承第一个机器人的任务、记忆或人格。

接着移除复制来的微信环境变量，避免两个 Profile 争用同一个 token：

sed -i '/^WEIXIN_/d' ~/.hermes/profiles/wx2/.env
ls -la ~/.hermes/profiles/wx2/weixin/accounts/ 2>/dev/null

若第二条命令显示了从 default 克隆来的旧微信账号缓存，在确认路径确实是 wx2 后，再清理该 Profile 自己的微信目录并重新扫码。下面的删除命令只应作用于 wx2，绝不能省略或写错 Profile 名：

rm -rf ~/.hermes/profiles/wx2/weixin

然后为第二个机器人设置新的 Weixin/iLink Bot 身份。私信选择 Use DM pairing approval，群聊选择 Disable group chats：

hermes -p wx2 gateway setup
hermes -p wx2 gateway start
hermes gateway list

[!warning] CLI 版本差异
Profile 与多 Gateway 相关命令会随 Hermes 版本演进。执行前先查看 hermes profile --help、hermes gateway --help；若 create、start 或 list 的参数与本文不同，以当前 CLI 帮助和官方文档为准。

预期可以看到 default 与 wx2 两个 Gateway。新用户先向第二个微信机器人发一条私信，再只在 wx2 Profile 中查看并批准配对请求：

hermes -p wx2 pairing list
hermes -p wx2 pairing approve weixin <配对码>

不带 -p 的 hermes gateway setup 或 hermes pairing approve 操作默认 Profile；带 -p wx2 的命令只操作第二个机器人，不会覆盖原 ClawBot。多 Profile 部署后，应分别检查每个 Profile 的 Gateway 状态、Cron、日志和开机恢复情况；并在克隆后暂停或删除不应由 wx2 重复执行的定时任务。

4、用 ClawBot 做什么：AI HOT 与定时简报

4.1 AI HOT Skill：让机器人查询近期 AI 资讯

AI HOT Skill 用于查询公开 AI 资讯。本节安装在 ubuntu 用户的 ~/.hermes/skills/aihot/SKILL.md，其请求范围为 AI HOT 的匿名公开只读 API。Skill 本身不是一个常驻服务：只有 Agent 收到“最近有哪些重要 AI 新闻”等问题，或 Cron 任务到点时，才会加载 Skill 并执行查询。

安装 Skill 前应先阅读其 SKILL.md 和 README.md，确认访问范围与写入目录；安装时只新增该 Skill 目录，不覆盖 ~/.hermes/skills/ 下其他 Skill。安装完成后可开启新会话，或用 /clear 清理当前聊天上下文，再向机器人验证：

请根据 AI HOT 整理过去 24 小时最值得关注的 AI 资讯，按重要性分组，并保留原文链接。

若需要让 Agent 发起查询，Tirith 会在 terminal 命令实际执行前检查请求方式。AI HOT 的公开只读接口适合资讯查询，但不要把任何私密 token、服务器凭据或写操作混入该 Skill 的调用上下文。

结果如下：

4.2 在 WebUI 创建定时任务

4.2.1 为什么使用“过去 24 小时”而不是“今日日报”

AI HOT 的“日报”和“过去 24 小时资讯”不是同一个时间口径：

• 过去 24 小时是以任务实际执行时刻向前滚动 24 小时；
• 日报按固定自然日窗口生成，北京时间约 08:00 才会出现新一期；
• 任务在北京时间 09:00 执行时，应明确要求“滚动过去 24 小时”，避免误取尚未生成的当日日报。

4.2.2 填充字段

在 Dashboard 的“新建定时任务”界面填写：

字段	建议值
Profile	default
名称	每日 AI HOT 24h 简报
调度类型	Cron 表达式
Cron 表达式	0 9 * * *
投递至	已配置的微信/Weixin 私聊，不要选“本地”
Skills	勾选 aihot
Provider	Default
Model	Default
no_agent	不勾选
Script	留空
Workdir	留空
Context from job IDs	留空

服务器时区已经是 Asia/Shanghai，所以 0 9 * * * 对应北京时间每天 09:00。

“投递至：本地”只保留本地执行结果，不代表会主动发送到微信。需要主动推送时，必须选择已经配置好的微信私聊目标。

推荐提示词 如下：

使用 aihot skill 获取截至执行时刻向前 24 小时内的 AI HOT 精选资讯。注意这是滚动的过去 24 小时，不是按自然日切分的 AI 日报。

用中文整理成简报，按“模型发布/更新、产品发布/更新、行业动态、论文研究、技巧与观点”分类。每条包含标题、简短摘要、来源、北京时间和原文链接；优先保留重要资讯，控制在 20 条以内。将完整简报直接发送到本任务配置的投递目标。

不应勾选 no_agent，因为该任务需要 Hermes Agent 加载 aihot Skill、理解返回内容并生成中文简报。

4.2.3 验证

[!tip] 关闭前端后，定时任务为什么仍会运行
Dashboard 只负责创建和管理任务；任务配置由 Hermes 后端持久化，真正的调度和投递由常驻 Gateway 完成。

WebUI 创建任务时，只是在 Hermes 后端保存一条任务配置。之后的运行链路是：

1. Gateway 常驻运行；
2. Gateway 内部的 cron ticker 定期检查到期任务；
3. 到达 0 9 * * * 后启动 Hermes Agent；
4. Agent 加载 aihot Skill，整理过去 24 小时资讯；
5. Gateway 将结果投递到配置好的微信目标。

因此，以下操作不会影响任务：

• 关闭浏览器标签页；
• 断开本地 SSH 隧道；
• 执行 hermes dashboard --stop。

查看任务列表：

ubuntu@VM-8-10-ubuntu:~$ hermes cron list

┌─────────────────────────────────────────────────────────────────────────┐
│                         Scheduled Jobs                                  │
└─────────────────────────────────────────────────────────────────────────┘

  047504d099a9 [active]    # 补充: 旁边这一串就是定时任务 ID (job_id)
    Name:      每日 AI HOT 24h 简报
    Schedule:  0 9 * * *
    Repeat:    ∞
    Next run:  2026-07-19T09:00:00+08:00
    Deliver:   weixin
    Skills:    aihot

检查调度器：

ubuntu@VM-8-10-ubuntu:~$ hermes cron status

✓ Gateway is running — cron jobs will fire automatically
  PID: 3342702
  Ticker heartbeat: 5s ago

  1 active job(s)
  Next run: 2026-07-19T09:00:00+08:00

创建后无需直接等待第二天，可先手动触发一次：

hermes cron run <job_id>

示例：

该处失败时，Tirith 尚未安装。

其他管理命令：

hermes cron pause <job_id>
hermes cron resume <job_id>
hermes cron remove <job_id>

4.3 微信机器人还能做什么

AI HOT 定时简报只是一个“Skill + Cron + 微信投递”的组合示例。Hermes 微信机器人本质上是把 Agent 放进微信消息渠道，因此能够做什么，取决于已配置的模型、Skills、MCP 服务和工具权限，而不是微信渠道本身。以下是适合作为个人或小团队机器人的常见用法：

场景	机器人可以做什么	需要的前置条件
日常问答与内容整理	回答问题、总结长文本、将零散想法整理为提纲、邮件或待办草稿	可用的模型 Provider
资讯与研究助理	查询 AI HOT、按主题汇总公开资讯、比较资料并保留来源链接	对应 Skill 或可审查的数据源
定时简报与提醒	每日资讯、周报草稿、项目提醒、固定时间的状态汇总	Cron、明确的投递目标与可验证的提示词
个人知识与表达偏好	基于 SOUL、记忆或上下文文件保持相对稳定的表达风格与偏好	谨慎配置人格、Memory 与隐私边界
外部系统协作	通过 MCP 读取或操作经授权的文档、项目、数据库或业务系统	对应 MCP Server、最小权限凭据与审计策略
服务器与开发辅助	在明确授权下检查日志、生成诊断建议或执行受限运维操作	terminal 工具、Tirith 与最小化系统权限
语音交互	将语音输入或输出接入对话流程	已启用语音相关能力和所需 Provider

实际使用时，建议先从“只读、可验证、低权限”的任务开始，例如资讯查询、文本总结和定时推送，再逐步接入 MCP 或终端工具。不要将微信消息直接视为可信指令；涉及文件删除、部署、外部写入或敏感数据时，应保留人工确认与最小权限控制。

官方文档入口：

• 功能总览
• Skills
• Tools
• MCP
• Memory
• 语音模式
• 安全说明

5、常见故障排查

5.1 浏览器提示连接被拒绝

先检查监听：

sudo ss -ltnp | grep ':9119'

再从服务器本机检查 HTTP：

curl -I http://127.0.0.1:9119

判断方法：

• 本机返回成功，但公网失败：重点检查监听地址、安全组和防火墙；
• 本机也失败：Dashboard 没有启动、启动失败或端口已改变；
• 监听为 127.0.0.1:9119：只能通过服务器本机或 SSH 隧道访问；
• 监听为 0.0.0.0:9119：应用已接受外部连接，继续检查网络放行。

不要优先按旧 PID 搜索：

sudo ss -tulnp | grep <旧PID>

PID 可能变化，而且并非每个相关进程都直接持有监听 socket。排查 WebUI 时按端口搜索更可靠：

sudo ss -ltnp | grep ':9119'

5.2 定时任务没有执行

依次检查：

hermes cron list
hermes cron status
pgrep -af 'gateway run'
timedatectl

重点确认：

1. 任务存在且未暂停；
2. Cron 表达式是 0 9 * * *；
3. 时区是 Asia/Shanghai；
4. Gateway 的 ticker 心跳正常；
5. 投递目标不是“本地”；
6. aihot Skill 已勾选；
7. Provider、模型和微信渠道可以正常使用。

5.3 磁盘空间不足

服务器根分区曾达到约 84% 使用率。构建 WebUI、日志和会话数据都会继续占用空间，应定期检查：

df -h
du -sh ~/.hermes/* 2>/dev/null | sort -h

先识别占用来源，再决定清理内容；不要直接删除 Hermes 的配置、会话、凭据或状态文件。

5.4 微信能收消息但没有回复

先确认 Gateway 是否仍在运行，并查看近期日志；然后区分是微信渠道、模型 Provider、Skill/工具还是投递目标的问题。普通问候也没有回复时，优先检查微信登录态、私信访问策略和模型配置；只有使用 AI HOT 或其他工具时失败，则进一步查看 Tirith 的扫描结果、Skill 目录和对应任务输出。

hermes gateway status
hermes logs --since 20m
hermes cron status

不要把“机器人已扫码”当作所有链路均正常的证据。扫码只证明微信渠道已取得登录态，模型不可用、Gateway 停止、用户未通过配对或 Skill 执行失败都可能导致没有最终回复。

6、安全与运维清单

6.1 当 Skill 会调用 terminal 时：Tirith 是什么

Tirith 是 Hermes 在执行终端命令前调用的安全扫描器。它不是 Dashboard、Gateway、Cron、模型 Provider 或消息渠道，而是位于 Agent 与操作系统 Shell 之间的一层防护：Agent 生成命令后，Tirith 先检查命令内容，再给出允许、警告或阻止的判断。

是否会用到 Tirith，取决于 Agent 有没有调用 terminal，而不是取决于消息来自聊天还是定时任务。普通聊天、模型推理、Dashboard 访问、Gateway 向微信投递消息，这些都不依赖 Tirith；只有进入 terminal 链路时，它才会参与执行前检查。像本文里的 aihot Skill，如果是通过 curl 请求公开只读接口，就会自然经过这一层。

AI HOT 定时任务的实际链路可以理解为：

Cron 到点触发
→ Hermes Agent 加载 aihot Skill
→ Agent 准备通过 terminal 执行 curl
→ Tirith 扫描 curl 命令
→ Shell 请求 AI HOT
→ Agent 整理中文简报
→ Gateway 投递到微信

因此，AI HOT 和 Cron 本身并不等于 Tirith，但只要 Skill 会发起终端命令，请求链路就可能触发它。若后续接入更多只读查询型 Skill，保留这一层通常更稳妥；若它因网络原因下载失败或超时，则优先按后面的排障思路检查，不要误判为微信渠道或模型本身故障。

6.2 Tirith 的安装、启停与排障

Linux 或 macOS 上第一次需要终端扫描时，如果系统找不到 Tirith，Hermes 会尝试从官方 GitHub Releases 自动下载对应平台的二进制文件，校验 SHA-256 后安装到：

~/.hermes/bin/tirith

Ubuntu 用户对应的实际路径是：

/home/ubuntu/.hermes/bin/tirith

检查安装状态：

~/.hermes/bin/tirith --version
test -x ~/.hermes/bin/tirith && echo "Tirith executable"

本机在实际安装并验证的版本为：

tirith 0.3.3

如果 GitHub 网络问题导致自动下载阻塞，可以临时关闭扫描以验证任务链路：

hermes config set security.tirith_enabled false
hermes gateway restart

关闭后 terminal 仍能运行，但失去 Tirith 的内容级命令检查。Gateway 可以接收外部消息且 Agent 拥有终端能力时，不应长期关闭。安装完成后重新启用：

hermes config set security.tirith_enabled true
hermes gateway restart

以下日志表示 Hermes 正在尝试自动安装：

tirith not found — downloading latest release...

以下日志通常表示 GitHub 下载失败，系统暂时找不到可执行文件：

tirith download failed: The read operation timed out
tirith spawn failed: No such file or directory: 'tirith'

自动安装失败后，Hermes 可能创建下面的标记，在一段时间内避免重复下载：

~/.hermes/.tirith-install-failed

只有在 Tirith 已成功手动安装后，才删除该失败标记。排查时可以查看：

hermes logs --since 20m
ls -l ~/.hermes/bin/tirith
~/.hermes/bin/tirith --version

如果这台服务器后续仍遇到 GitHub 访问超时，而你又需要继续使用会触发 terminal 的 Skill，可以再补充手动下载方案。当前文章里不把那一长段安装脚本放在前面，是为了避免它抢走微信机器人主线；更合理的阅读顺序是先完成 Gateway、微信与 Cron，再在确实用到 terminal 工具时处理 Tirith。

• 优先选择 127.0.0.1 + SSH 隧道。
• 公网绑定必须启用密码或 OAuth，不依赖已失效的 --insecure。
• 公网长期使用应增加 HTTPS 反向代理。
• 腾讯云安全组尽量只允许自己的固定来源 IP 访问 9119。
• 不把 Dashboard 密码、模型密钥和微信凭据写入笔记或聊天。
• Dashboard 可以按需启停，但 Gateway 必须保持运行，cron 才会自动触发。
• 创建任务后先手动运行一次，确认内容、长度和微信投递都符合预期。
• 定期使用 hermes cron status 检查 ticker 心跳。
• 定期检查磁盘空间、Gateway 状态和 Hermes 日志。
• 服务器重启后，检查 Gateway 与 Cron 是否自动恢复，再确认微信机器人能够正常回复。