SuperAI Agent v0.2.27

SuperAI Agent v0.2.27

代理返回 407 时会说明原因并自动重试；同时纠正 v0.2.26 中我判断错误的一处设计。

问题修复

• 407 现在会说明发生了什么：此前用户只会看到 API Error: 407 status code (no body)。这句话字面上没错——407 响应确实没有正文——但它既没说是哪个代理，也没说该怎么办。

  407 的含义是代理要求身份验证。现在的提示会写明是哪个代理（自动去除其中的账号密码）、代理要求哪种验证方式，以及可以怎么处理。若代理要求的是 NTLM / Negotiate（Windows 登录态验证），提示会直接说明本应用无法完成该验证，而不是让用户反复填写一个根本不可能生效的密码。

  这套判断逻辑本来就存在——设置页「测试代理」按钮早已能解析 Proxy-Authenticate 并识别 NTLM/Negotiate——只是从未出现在用户真正会遇到的路径上。本次把同一个答案接到了聊天的报错里。

• 407 现在会自动重试（有次数上限）：此前 shouldRetry 对 407 直接返回 false，于是代理下一次本会放行，这一轮对话却已经结束。企业代理通常按来源 IP 缓存授权状态若干分钟，因此请求成败取决于这台机器最近是否有其他程序完成过验证。上限是刻意保留的：要求 NTLM 的代理会一直拒绝，把整整十次退避耗尽之后才告知原因，比报错本身更糟。

• 纠正 v0.2.26 的一处误判：拦截页现在也会重试：v0.2.26 中我认为「拦截页是策略性拒绝，每次结果都一样，重试只会让用户白等」，据此没有给拦截页任何重试机会。用户的截图推翻了这一判断——同一个地址、同一个代理，前一秒被拦截，后一秒正常返回。也就是说，那恰恰是最需要重试的情形，而我把它排除掉了。现在拦截页同样会重试，但次数上限低于普通连接失败，确保真正被封禁的地址仍然会快速报错，而不是在十次退避之后。

  这两件事很可能是同一个原因：当代理无法确认连接对应哪个已验证用户时，它要么回 407，要么直接套用默认拒绝策略返回过滤页。

需要说明的（不含糊其辞）

尚未证实代理验证就是根本原因。 它能同时解释 407、时好时坏的现象，以及那个默认拒绝页面，吻合度很高，但目前仍是推断——调试日志尚未查看。

若代理接受 Basic（用户名/密码）验证，那么在「设置 → 代理」中填入账号密码可能就足以解决问题；而 407 响应中的 Proxy-Authenticate 头会直接告诉我们它到底接受哪一种。新版的报错信息里就写着这个信息。

调试日志默认开启，位于：

%USERPROFILE%\.claude\debug\

验证情况

新增 8 项测试，共 30 项通过。三处新增防护全部经过「故意改坏使其失败」的验证：删掉 407 重试、删掉 407 分支、把拦截页上限调到与完整预算相同，各自恰好让一项测试失败。

其中包含一项「接线测试」：构造真实的 APIError(407) 走完整的错误展示路径——「函数写对了但根本没被调用到」这个疏漏我此前连续两个版本都留了下来，这次一并补上。另有一项对照：与之无关的 400 错误仍然不重试，以确认本次改动没有把重试范围扩大到别处。

src/services/api 与服务端测试套件在改动前后按测试名逐一比对，失败集合完全一致，既有的 27 项失败没有任何变动。