Hermes Agent 的性能与监控

长期在线的 agent 如果不被观察，就像一个持续运转但不报状态的机器——你不知道它是在工作还是在空转。

系统健康度、任务执行效率、记忆与技能状态、安全与边界状况——四个维度缺一不可。

调试是在问题发生后打开盖子看，监控是在运行时持续观察仪表盘。长期运行的系统两者都需要。

不要等到出问题了才想怎么监控。在配置 Hermes 的阶段就应该把日志、指标和告警设计进去。

不是一开始就需要完整的监控体系。从任务成功/失败计数和日志开始，随着运行时间增长逐步增加指标和告警。

第一周只需要确认 Hermes 在运行。第一个月关注任务完成率和错误类型。三个月后开始优化性能和资源使用。

单位时间内完成任务的数量。持续下降可能意味着 Hermes 卡在某个任务上，或者模型响应变慢。

成功完成的任务占总任务的比例。长期低于 80% 说明需要检查技能配置、模型选择或任务复杂度。

从任务提交到首次响应的时间。突然升高可能预示模型 API 延迟或系统资源瓶颈。

每个技能被调用的次数和成功率。低频使用的技能可以考虑关闭，高频低成功率的技能需要优化。

记忆系统中被后续任务引用的比例。利用率持续走低说明记忆筛选策略可能需要调整。

子 Agent 从创建到返回结果的平均耗时。执行时间过长的子任务可能需要重新拆分。

按任务类型统计输入和输出 Token 数。异常增长可能说明提示词需要优化或陷入了无效循环。

CPU、内存和磁盘的长期趋势。持续增长可能暗示内存泄漏，突发飙升可能说明任务负载超过预期。

ERROR 记录导致任务失败的问题，WARN 记录异常但未失败的情况，INFO 记录任务生命周期事件，DEBUG 记录详细执行链路。

每行日志包含时间戳、任务 ID、事件类型、关键字段和消息体。结构化日志比纯文本日志更适合后续检索和分析。

长期运行会产生大量日志。建议按天轮转，保留最近 30 天的日志，超过 30 天的归档到低成本存储。

任务连续失败 N 次、响应时间超过阈值、内存使用率过高——为关键指标设置告警，通过消息渠道推送给运维人员。

日志的价值在于能被检索和分析。建议接入日志中心或使用结构化日志工具，支持按任务 ID、时间范围和日志级别快速过滤。

日志中可能包含用户消息、API Key、文件路径等敏感信息。在日志输出前应自动脱敏，避免日志存储成为新的安全风险。

检查模型 API 是否可用、网络连接是否正常、进程是否在运行。逐层排查从基础设施到应用层的链路。

检查存储后端连接状态、磁盘空间是否充足、记忆配置中的持久化开关是否启用。

检查技能代码是否有语法错误、依赖是否安装、声明的权限是否已被授权。在沙箱中单独运行技能确认。

子任务可能过于复杂或依赖的外部资源响应慢。考虑增大超时阈值或进一步拆分子任务。

检查 Bot Token 是否过期、Webhook URL 是否正确、消息平台的 API 是否有访问频率限制。

检查记忆库是否已增长到影响检索效率、是否注册了过多技能、长期运行是否有内存泄漏。

回复包含重复内容、格式错乱或明显错误。检查模型 API 状态、temperature 参数是否过高、提示词是否需要更新。

Hermes 在自动推进过程中停止了下一步动作。检查是否卡在某个技能调用上、是否需要人工确认、任务超时设置是否合理。

最被动的监控模式。等到问题发生了才去看日志，往往已经造成了影响。监控应该从 Hermes 运行的第一天就开始。

堆砌指标仪表盘不等于可观测。每个指标都应该能回答一个问题、触发一个动作。如果不知道某个指标的阈值和应对方案，那它就是在增加噪声。

频繁收到不重要的告警会让人忽略所有告警。设计告警规则时问自己：这个告警需要人做什么？如果不需要，就不要发告警。

只需要确认两件事：任务有没有在正常执行、有没有无法自动恢复的错误。用一行命令就能看到：openclaw status。

开始追踪任务成功率、平均响应时间和常见错误类型。这个阶段你应该能回答"Hermes 这周比上周表现如何"。

当天出现的问题应该当天发现。配置结构化日志、设置关键指标的告警阈值、建立排查手册。

基于累积的数据回顾：哪些指标在改善、哪些技能最有用、哪些任务值得优化。把监控数据变成改进决策的依据。

短期你可以靠感觉判断 Hermes 在不在工作。一个月以上，没有监控你根本不知道它在空转还是真的在处理任务。

趋势告警比阈值告警更有价值。"连续 3 天响应时间在缓慢上升"比"响应时间超过 30 秒"能更早触发行动。

好的监控体系给你的不是更多信息，而是安全感——你知道即使不盯着看，出问题时也会有人通知你。