# 系列三：一个Bug的修复全程
web_search 从"不存在"到20条结果

📅 2026-06-26🏷️ 运维 · 工程排错⏱ 5分钟
🔧 真实案例

## 一、问题：Agent反复调用不存在的工具

梦境第一份报告揭示了一个优先级最高的错误模式：Agent 在几乎所有 Session 开头都会调用 `web_search` 和 `web_extract`，然后收到"Tool does not exist"错误，再切换到浏览器方案。每次浪费2轮交互。

检查配置发现根因：

# ~/.hermes/config.yaml
web:
search_backend: '' # ← 空的！
extract_backend: '' # ← 空的！
⚠️ 经验： 工具"不存在"不等于工具"不可用"。空的配置字段意味着"没配置"，不是"不支持"。这是梦境报告推动的第一个认知修正。

## 二、修复链：整整7步

本以为填个配置就行，结果挖出了一整条修复链：

# | 步骤 | 发现的问题
--- | --- | ---
1 | 确认 SearXNG 已运行 | Docker 实例在，但 JSON API 被禁用
2 | 启用 JSON 输出 | settings.yml 默认只有 html 格式
3 | 重启容器 | iptables 规则损坏，端口映射丢失
4 | 换用 host 网络模式 | 绕过 Docker 网络问题，直接暴露端口
5 | 修 DNS | 容器内 127.0.0.53 无法解析外部域名
6 | 换搜索引擎 | Google/DuckDuckGo 被墙，启用百度/搜狗
7 | 调大超时 | 3秒对中国网络太短，改成10秒

## 三、验证结果

✅ 搜索"Hermes Agent 梦境模式" → 返回20条结果（百度+搜狗）
✅ 搜索"AI 自进化 Agent" → 相关中文博客和教程
✅ 跨 Profile 继承 — 改一次配置，8个Profile全部生效

## 四、这条修复链揭示了什么？

一个看似简单的"填个配置"动作，实际上踩了5个坑：

- 假设偏差 — "容器在运行就能用"是错的，它可能没有启用你需要的能力
- 网络复杂 — Docker 的 iptables、DNS、端口映射三个独立问题同时出现
- 环境特殊性 — 国际搜索引擎在国外好用，在国内需要替换源
- 超时敏感 — 默认3秒超时对中国网络环境不够，改到10秒才稳定
- 配置层级 — 改全局配置不够，Profile 层可能有自己的覆盖

## 五、梦境闭环

最有意思的是：明天的梦境报告会自动检查 `web_search` 问题是否真的被修复了。如果报告显示"不再出现"，它会标记为 fixed。整个从"发现问题→诊断→修复→验证→确认"的闭环就完整了。

这就是梦境模式的意义——不是取代人去修 Bug，而是让每个 Bug 的修复过程都有据可查、可追踪、可验证。