文章资讯

服务器重启后AI Agent不动了？排查记录

2026-05-10 作者：Covsun & Bob 浏览量：33

服务器重启后AI Agent不动了？排查记录

踩坑实录 运维排查 AI Agent Crontab

事情是这样的：某天运维同事重启了服务器，结果跑得好好的 hermes-agent 再也没有自动启动。明明 crontab 配了 @reboot，systemd 也做了开机自启，为什么重启后 AI Agent 就是不动？本文记录完整的排查过程与根因分析。

现象：服务器活了，Agent 死了

服务器重启后 SSH 能连上，CPU、内存、磁盘都正常，但就是没有 AI Agent 在跑。期待的 hermes-agent 进程并未出现，下游依赖这个 Agent 的定时任务、消息消费全部停摆。

直觉告诉我们：先看 crontab 和 systemd 配置，但事情远没这么简单——crontab -l 显示为空。

第一步：crontab -l 发现 Dream cron 为空

登录服务器后，首选检查定时任务是否还在：

# 查看当前用户的 crontab
$ crontab -l
# (空)

没有输出，说明当前用户的 crontab 完全为空。这很奇怪——之前明明配过一个 @reboot 任务来自动拉起 hermes-agent。难道是重启把 crontab 清掉了？不排除这种可能，某些初始化脚本或镜像重置确实会覆盖 /var/spool/cron/ 下的文件。

但别急，crontab -l 只查当前用户。真正的定时任务可能是 root 或其他用户挂的，也可能是 systemd timer，还可能是项目自带的 cronjob 注入脚本。需要三路并行排查。

? 三路并行查定时任务： 
# 第一路：Hermes 自带的 cronjob 注入脚本
$ ls -la /etc/cron.d/hermes* 2>/dev/null

# 第二路：系统 crontab -l
$ crontab -l

# 第三路：systemd timer
$ systemctl list-timers --all | grep -E "hermes|agent"
这三路覆盖了 Linux 上三种主流的定时任务机制。 
# 实际排查结果
$ ls -la /etc/cron.d/hermes*
ls: cannot access '/etc/cron.d/hermes*': No such file or directory

$ systemctl list-timers --all | grep -E "hermes|agent"
# (无输出)

三路全空。这确认了：没有任何定时任务机制会拉起 hermes-agent。

第二步：ps aux 发现跑的是 openclaw-gateway

虽然 Agent 没跑，但服务器上有其他进程在运行。用 ps 看一眼：

$ ps aux | grep -E "hermes|openclaw|gateway|agent"

root      12345  0.5  2.1 /usr/local/bin/openclaw-gateway --config /etc/openclaw.json
root      12346  0.3  1.8 /usr/local/bin/openclaw-gateway --worker
...

等等，跑的是 openclaw-gateway，不是 hermes-agent？

这下问题更清楚了：这台机器上存在两套系统——一套是 hermes（AI Agent 系统），另一套是 openclaw（某种网关系统）。而服务器上活跃的只有 openclaw，hermes 无人问津。

第三步：两套系统配置独立

检查了两套系统的配置位置：

系统 配置文件 状态
Hermes /opt/hermes/.env 配置存在，但进程未运行
OpenClaw /etc/openclaw.json 配置存在，进程运行中 
# Hermes 配置
$ cat /opt/hermes/.env
HERMES_GATEWAY_URL=http://localhost:8080
HERMES_API_KEY=sk-xxx
HERMES_MODEL=gpt-4o

# OpenClaw 配置
$ cat /etc/openclaw.json
{
  "gateway": "http://localhost:8080",
  "workers": 4,
  "log_level": "info"
}

两套系统各自独立配置，互不干扰。openclaw 有开机启动机制（可能是 systemd service 或 rc.local），所以重启后自动跑起来了。但 hermes 没有对应的自启机制，所以躺平了。

第四步：根本原因——hermes-gateway 配置正确但 active_agents=0

继续深入检查 hermes 系统的状态：

# 手动启动 hermes-gateway 看看
$ cd /opt/hermes && ./start-gateway.sh
[INFO] Starting Hermes Gateway...
[INFO] Gateway config loaded from /opt/hermes/.env
[INFO] Gateway URL: http://localhost:8080
[INFO] Database connected
[INFO] Active agents: 0

active_agents = 0！

这才是问题的真正根因。hermes-gateway 本身的配置（.env 文件）是完全正确的，API Key、模型配置、数据库连接都没问题。但 active_agents = 0 意味着没有 Agent 进程在消费消息队列中的任务。

这个系统的架构是这样的：

  • hermes-gateway：管理 Agent 的生命周期，接收来自客户端的请求，分发给 Agent
  • hermes-agent：实际执行任务的 Worker 进程
  • openclaw-gateway：另一套独立的网关系统，可能是旧架构或并行系统

hermes-gateway 启动后，它会检查注册的 agent 数量。如果 active_agents = 0，意味着虽然有正确配置，但没有 agent 来消费任务——所有请求都会卡住或返回错误。Gateway 本身不是消费方，它只是分发者。

再深挖一步：为什么 active_agents 是 0？因为 hermes-agent 没有启动。为什么没有启动？因为 crontab 为空，没有任何 @reboot 或 systemd timer 去拉起它。

所以整个链条是：

服务器重启 → crontab 为空 → 没有拉起 hermes-agent → active_agents=0 → 任务无人消费 → AI Agent 不可用

解决方案：手动写入 crontab

知道了根因，修复就很简单了。手动添加 @reboot 定时任务：

# 编辑 crontab
$ crontab -e

# 添加以下内容
@reboot sleep 10 && /opt/hermes/start-agent.sh >> /var/log/hermes-agent.log 2>&1

# 保存后验证
$ crontab -l
@reboot sleep 10 && /opt/hermes/start-agent.sh >> /var/log/hermes-agent.log 2>&1

几点细节：

  • sleep 10：等服务器完全启动后再拉起 Agent，避免依赖的服务（数据库、网关等）还没就绪
  • 日志重定向：把输出记到日志文件，下次排查有据可查
  • crontab -l 验证：确保写入成功

同时也建议加上 systemd service，更可靠：

# /etc/systemd/system/hermes-agent.service
[Unit]
Description=Hermes AI Agent
After=network.target

[Service]
Type=simple
User=root
WorkingDirectory=/opt/hermes
ExecStart=/opt/hermes/start-agent.sh
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target

# 启用并启动
$ systemctl daemon-reload
$ systemctl enable hermes-agent
$ systemctl start hermes-agent

设置完毕后，验证 agent 正常运行：

$ ps aux | grep hermes-agent
root      23456  2.1  3.2 /opt/hermes/hermes-agent --config /opt/hermes/.env

$ systemctl status hermes-agent
● hermes-agent.service - Hermes AI Agent
   Loaded: loaded (/etc/systemd/system/hermes-agent.service; enabled; vendor preset: enabled)
   Active: active (running) since ...

总结

这次排查暴露了几个常见但容易被忽视的问题：

  1. 不要假设 crontab 永远存在。服务器重启、镜像重置、镜像构建脚本都可能导致 crontab 被清空。用三路并行法（cron.d + crontab -l + systemd timer）全面检查。
  2. ps aux 是第一手现场证据。不要只看"预期中应该有什么"，要看"实际上有什么"。机器上跑着 openclaw 而不是 hermes，说明自启机制只覆盖了一套系统。
  3. 两套系统共存时易出配置遗漏。hermes 和 openclaw 各自独立，但只有一套有自启配置。部署交付时要统一检查所有服务的自启机制。
  4. active_agents=0 是中间状态指标。Gateway 配置正确不等于系统可用，还要看有没有 agent 在消费。这个指标是重要的健康检查信号。
  5. crontab + systemd 双重保障。crontab 简单直接，systemd 提供更完善的 restart、日志、依赖管理。建议对核心服务两种机制都配置。

最终，问题修复后，所有任务恢复正常消费。这次的教训也催生了一个新的运维规范：所有服务的自启配置必须统一纳入部署脚本，每次服务器重建后自动校验，避免再次出现"机器活着、Agent 死了"的尴尬局面。

—— 写于排查完成后，希望对遇到类似问题的同行有所帮助。

附录：快速排查清单

# 1. 查进程
ps aux | grep -E "hermes|agent|gateway"

# 2. 三路查定时任务
ls -la /etc/cron.d/* 2>/dev/null
crontab -l
systemctl list-timers --all

# 3. 查 systemd 服务
systemctl list-units --type=service | grep -E "hermes|agent"

# 4. 查配置完整性
cat /opt/hermes/.env | grep -v "#" | grep .
cat /etc/openclaw.json

# 5. 手动拉起测试
/opt/hermes/start-agent.sh