Hermes Agent 框架层优化建议

以下建议来自实际使用 Hermes Agent 四天的体验反馈。用户为 CLI 模式 + OpenCode Go provider + DeepSeek V4 Flash 配置。

1. image_input_mode: auto 与 vision_analyze 存在重复调用

问题描述： 当 image_input_mode: auto 启用时，系统会自动调用 vision 模型（Gemini）描述用户上传的图片，并将结果以 [The user attached an image. Here's what it contains: ...] 格式挂载到消息中。但主模型（如 DeepSeek V4 Flash）无法感知"该图片已被描述过"，因此可能再次调用 vision_analyze 工具，导致同一张图片产生两次视觉 API 调用和费用。

建议方案：

• 在消息结构中为已描述的图片添加标记（如 _vision_processed: true）
• 或者在系统提示词中加入"图片已被系统自动描述，请勿重复调用 vision_analyze"的指导
• 最简单的方案：在图片描述文本的末尾追加一行 [Image already analyzed by vision system. No need to call vision_analyze again.]

2. Fallback 链触发时没有告警信号

问题描述： 当主服务（如 Gemini API）连续返回 401/403/503 错误时，fallback 链自动切换到备用服务（如本地 qwen3-vl:8b）。但框架没有在主通道失败时产生任何信号或日志警告，导致主通道损坏（如 API key 过期、被覆盖为模板）多日不被发现，用户通过细枝末节才察觉异常。

建议方案：

• 在 fallback 激活时写入一条警告级别的日志
• 可选：在 assistant 消息中追加 [Note: Primary vision service unavailable, using fallback. Check configuration if this persists.]
• 或者提供一个配置项 fallback_warn_after: N，连续 N 次 fallback 后产生告警

3. .env 文件在更新/配置操作中被覆盖为模板

问题描述： 某次 hermes setup 或版本更新后，~/.hermes/.env 文件的内容被替换为初始模板，所有已配置的 API key（GOOGLE_API_KEY, OPENCODE_GO_API_KEY, DEEPSEEK_API_KEY 等）丢失。配置文件没有自动备份机制，用户需要手动发现并恢复。

建议方案：

• 在覆盖 .env 文件前，自动创建备份 ~/.hermes/.env.bak
• 或检查现有 .env 是否已有非注释内容，询问后再覆盖
• 或在更新脚本中添加 .env 变更检测

4. 安全弹窗缺乏"记住选择"功能

问题描述： CLI 模式下，特定管道操作（如 curl | python3）每次都会触发安全审批弹窗，用户需要手动确认。没有类似"记住本次选择"或"添加此命令到白名单"的功能，导致高频操作反复弹窗。

建议方案：

• 添加 trust_command 或 allow_once / allow_always 选项
• 或提供可配置的命令/模式白名单

5. _describe_image_for_anthropic_fallback 函数命名误导

问题描述： run_agent.py 中函数 _describe_image_for_anthropic_fallback 的名称暗示它仅在 Anthropic 模型 fallback 时使用。但实际上它作为 image_input_mode: auto 的核心处理方法，对所有非视觉模型（包括 DeepSeek、OpenAI 等）的图片处理都是默认路径。函数名称与行为不符，会增加后续开发者的理解成本和维护风险。

建议方案：

• 重命名为 _describe_image_for_non_vision_model 或 _auto_describe_image
• 或在函数文档字符串中明确说明其适用范围