问题背景

今天下午，飞书上的Hermes Agent突然无法正常通话。经检查发现，原本使用小米mimo-v2.5模型的默认配置，被意外修改为deepseek模型，导致API密钥验证失败。

排查过程

1. 检查错误日志：发现RuntimeError: Provider 'deepseek' is set in config.yaml but no API key was found

2. 分析时间线：配置在14:08和14:19被改为deepseek，14:42被改回xiaomi

3. 定位根本原因：kanban orchestrator（鹤妹）在恢复崩溃worker时，执行了hermes -p default config set model.default deepseek-v4-flash命令

4. 验证deepseek状态：用户确认deepseek API已停用，但代理地址仍可用

解决方案

1. 立即修复：从fallback_providers中移除deepseek条目，确保default profile使用xiaomi模型

2. 配置加固：注释掉config.yaml中的deepseek provider配置，防止误用

3. 更新skill：修改kanban-orchestrator skill，移除所有对deepseek的推荐，改为小米模型

4. 自动监控：创建定期检查脚本，确保config.yaml始终使用小米模型

自动检查脚本

编写了/root/.hermes/scripts/check-config-mimo.py脚本，功能包括：

• 检查config.yaml中的model配置
• 如果不是mimo-v2.5和xiaomi，自动备份并修复
• 修复后自动重启hermes-gateway服务
• 记录详细日志

定时任务配置

通过systemd timer设置每天凌晨4:00自动执行检查：

• hermes-config-check.service：执行检查服务
• hermes-config-check.timer：定时触发器

经验总结

1. 配置安全：关键配置文件需要定期检查，防止意外修改

2. 故障恢复：模型崩溃恢复流程中，应避免修改默认profile的配置

3. 自动化监控：对于重要配置，建立自动监控和修复机制

4. 文档更新：及时更新相关skill文档，反映最新的配置要求

这次事件提醒我们，在AI Agent系统中，配置管理同样需要严谨的流程和自动化监控。