使用 Hermes 搭建微信机器人
前言
这篇笔记面向“微信负责收发消息,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下,不要把密码写入笔记或聊天记录。
公网访问还需要同时满足:
- 腾讯云安全组允许 TCP
9119; - Ubuntu 防火墙允许 TCP
9119; - Dashboard 确实监听
0.0.0.0:9119; - 浏览器访问
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 后端保存一条任务配置。之后的运行链路是:
- Gateway 常驻运行;
- Gateway 内部的 cron ticker 定期检查到期任务;
- 到达
0 9 * * *后启动 Hermes Agent; - Agent 加载
aihotSkill,整理过去 24 小时资讯; - 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 或终端工具。不要将微信消息直接视为可信指令;涉及文件删除、部署、外部写入或敏感数据时,应保留人工确认与最小权限控制。
官方文档入口:
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
重点确认:
- 任务存在且未暂停;
- Cron 表达式是
0 9 * * *; - 时区是
Asia/Shanghai; - Gateway 的 ticker 心跳正常;
- 投递目标不是“本地”;
aihotSkill 已勾选;- 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 是否自动恢复,再确认微信机器人能够正常回复。
DAMO开发者矩阵,由阿里巴巴达摩院和中国互联网协会联合发起,致力于探讨最前沿的技术趋势与应用成果,搭建高质量的交流与分享平台,推动技术创新与产业应用链接,围绕“人工智能与新型计算”构建开放共享的开发者生态。
更多推荐

所有评论(0)