AI Agent 自动化工具最怕的不是报错，而是那种欺骗你的“健康状态”
我写了一个叫 HELM 的小工具，核心目的很简单：在运行长任务时，自动帮我点击 Claude Desktop 弹出的权限允许按钮，避免程序在半夜两点因为等待确认而卡死，把我给吵醒。简单来说，这就是一个盯着 AI 的“监护人”。
结果我发现，这个工具在 7 月 3 日到 23 日之间，整整 20 天时间一个按钮都没点成，但它的自检报告却一直给我发送 Self-check OK (8/9)。日志里看着全是成功批准的记录，实际上全是假象。
这次经历让我意识到，在处理基于 Electron 的桌面应用时，有三个极其隐蔽的陷阱。
首先是 Electron 的“懒加载”机制。Claude Desktop 是基于 Electron 构建的，而 Chromium 的辅助功能树（Accessibility Tree）非常“鸡贼”：如果它检测到当前没有辅助工具在活跃调用，它可能根本不会构建完整的内容树。这意味着 HELM 在运行自检时，能看到窗口的外壳和侧边栏，看起来一切正常，但中间那个真正包含“Allow”按钮的对话区域在树里直接消失了。由于我的自检逻辑只检查了窗口是否存在，导致工具在“失明”状态下依然报告健康。
其次是自检逻辑的分类误区。我之前的健康检查将核心功能链路分在了“non-critical（非关键）”类目里。这其实是一种典型的自欺欺人——如果你的健康检查逻辑中存在“非关键”项，那么请务必检查里面是否潜伏着你的核心业务链路。因为一旦核心功能被标记为非关键，即便它失效了，整体状态依然会显示为 OK，从而掩盖了真实的故障。
最离谱的坑出现在我尝试修复可见性问题之后。我在发布 v1.0.24 版本后，自检终于显示 Self-check OK (9/9)，我以为问题解决了，结果发现它依然点不动按钮。
深挖之后才发现，Claude 的按钮标签是动态的，实际显示为 'Allow once 2 Ctrl +Enter'。我的匹配代码在寻找 "Allow once"，虽然没直接匹配上，但由于触发了一个正则 ^allow，结果它精准地匹配到了对话框的标题问题（那个问题也被标记成了按钮元素）。
于是出现了一个极其诡异的现象：HELM 在那里疯狂点击那个问题标题，点击标题当然没有任何反应，但因为在代码层面上 GetInvokePattern().Invoke() 执行并没有报错，程序就认为点击成功了。我在日志里看到了触目惊心的数字：20 天时间，它对着空气进行了 855 次对话框重复点击，产生了 1,194 条 'Allow once' 和 1,155 条 'Allow' 的成功记录。
这次实操给我最大的教训是：永远不要信任任何不带“结果验证”的成功回调。在 UI 自动化中，Invoke() 成功并不代表业务逻辑成功。现在我把自检逻辑全部重构了，只要结果验证不通过，直接报 Self-check DEGRADED，不再给任何模糊的中间状态。
