Hermes 第三方插件稳定性核查

生成时间：2026-05-19 21:56:10 CST

总体稳定性为“可用但需治理”：核心 Master、Web UI、Report Center、CLIProxyAPI、Worker/Stock/Health 运行正常；主要风险是 Network/News/Sub 的 systemd 状态与 Web UI 子进程运行状态不一致，以及外置记忆 sidecar 带来的资源与端口管理复杂度。

0failed systemd units

50%根分区使用率

18GiB可用内存

3/4已配置外置记忆 profile 在线

结论

核心入口稳定：Master gateway、Web UI、公网 Web UI、Report Center、CLIProxyAPI 均可访问或 active。
新接入的 Worker/Stock/Health 外置记忆均已健康运行，端口分别为 8421/8422/8423。
Network 外置记忆端口 8420 当前不可达；但 Web UI 服务下另有 network 子进程运行，说明该 profile 的运行管理方式发生分叉。
资源层面尚未紧张：磁盘 50%、inode 9%、可用内存 18GiB；但 Master 峰值 3.0G，需持续观察。

服务状态

服务	状态	角色	证据/备注
`cliproxyapi.service`	active	核心模型代理	运行 2+ 天；本地 /v1/models 无 key 返回 401，说明鉴权入口正常
`hermes-gateway.service`	active	Master/默认网关	运行 1天4小时；内存 1.5G，峰值 3.0G，需关注但未崩溃
`hermes-web-ui.service`	active	Web UI	本地与公网均 200；内存 431M，峰值 784M
`report-center.service`	active	报告中心	服务 active，公网 /reports/ 200；本地 /health 404 属无该路由，不代表故障
`hermes-gateway-worker.service`	active	Worker	刚接入外置记忆后 active；8421 health ok
`hermes-gateway-stock.service`	active	Stock	刚接入外置记忆后 active；8422 health ok
`hermes-gateway-health.service`	active	Health	刚接入外置记忆后 active；8423 health ok
`hermes-gateway-network.service`	inactive(systemd)	Network	systemd 单元 dead，但 Web UI 子进程中 network gateway 正在运行；运行路径不统一
`hermes-gateway-news.service`	inactive(systemd)	News	systemd 单元 dead，但 Web UI 子进程中 news gateway 正在运行；运行路径不统一
`hermes-gateway-sub.service`	inactive(systemd)	Sub	systemd 单元 dead，但 Web UI 子进程中 sub gateway 正在运行；运行路径不统一

外置记忆状态

Agent	端口	状态	证据/备注
Network	`8420`	down	systemd Network dead；Web UI 子进程在跑，但未看到 8420 sidecar health
Worker	`8421`	ok	{"status":"ok","vectorStore":true,"embeddingService":false}
Stock	`8422`	ok	{"status":"ok","vectorStore":true,"embeddingService":false}
Health	`8423`	ok	{"status":"ok","vectorStore":true,"embeddingService":false}
News	`8424`	not configured/down	profile memory.provider 为空
Master	`8425`	not configured/down	default profile memory.provider 为空

HTTP / 控制面探测

目标	URL	HTTP	耗时/备注
Web UI local	`http://127.0.0.1:16060/`	200	0.0017s
Web UI public	`https://hermes.loveason.com/`	200	0.788s
Report Center public	`https://www.loveason.com/reports/`	200	0.611s
CLIProxyAPI models no-key	`http://127.0.0.1:8317/v1/models`	401	预期鉴权失败

主要风险清单

级别	问题	影响
高	网关管理路径不统一	Network/News/Sub 的 systemd 单元 inactive，但 Web UI 下存在对应子进程。后续排障时容易误判“已停止/已运行”，也可能产生重复 gateway 或抢 bot lock。
中	Master 内存占用偏高	default gateway 当前 1.5G RSS、峰值 3.0G；第三方插件和外置记忆 sidecar 增多后，需监控内存趋势。
中	TencentDB sidecar 端口冲突噪音	Worker/Stock/Health 烟测出现 EADDRINUSE，但 health 正常；属于多进程尝试启动同一 profile sidecar 的已知噪音。
中	cron/x_search import 错误历史	News 日志中出现 AmbiguousJobReference 与 x_search import 错误，可能影响定时任务/工具加载；24h 内未在当前 active 服务重复出现。
低	API Server 无 key 警告	Worker/Stock/Health gateway 日志提示 API_SERVER_KEY 未配置；若 API server 未公网暴露则风险较低，但应确认 Web UI/本地控制面边界。
低	FTS5 不可用	TencentDB memory SQLite FTS5 不可用时降级到内存评分，影响召回质量但不是可用性故障。

建议处置顺序

统一 Network/News/Sub 的运行归属：确认这些 profile 是否应由 Web UI 托管，还是恢复 systemd 单元；避免双启动、假离线、bot lock 冲突。
为外置记忆加监控：定时检查 8421/8422/8423 health、数据文件增长、stderr 中持续 EADDRINUSE/ERROR；Network 8420 单独决定是否恢复。
观察 Master 内存：设置每日 RSS/峰值趋势检查，若持续增长再定位插件、LSP、sidecar 或会话压缩。
修复历史 import 错误：重点检查 cron.jobs 的 AmbiguousJobReference 与 x_search_tool 的导入错误是否仍影响 News/cron。
确认 API Server 暴露边界：若 API server 只在本机/Web UI 内部使用可暂缓；若有公网路径，必须补 API key 或访问控制。

本次未执行的动作

未重启服务。
未修改配置。
未清理进程或日志。
未对外置记忆做破坏性写入。