SuperAI Agent v0.2.25

SuperAI Agent v0.2.25

PAC 支持已在真实的企业网络上跑通；本次改进的是失败时的报错措辞——让一条报错足以定位问题，而不是把人指向一个本来就正确的设置。

PAC 支持已在真实企业机器上验证

v0.2.24 的说明里写明了一个尚未闭合的缺口：测试用的 PAC 是自建脚本，没有针对真实的企业 PAC 验证过。现在验证完成了。

在此前一直无法完成任何对话的 Win11 机器上：

• 诊断信息显示 proxy_source=pac——PAC 脚本被抓取、执行、并按结果设置了代理；
• 脚本选出的代理与之前手动填写的并不是同一台，说明 PAC 确实在按自己的规则做判断；
• 该机器返回了第一条真实的模型回复。

同时得到一个明确结论：设置页里手动填写的代理会覆盖 PAC。v0.2.23 曾建议用户手动填写代理地址作为临时办法，而这个办法在 v0.2.24 之后反而会盖掉自动判断的结果。如果你曾按 v0.2.23 的提示手动填过代理，升级后请清空该字段，让本应用使用机器自己的 PAC 规则。

报错措辞修正

• 代理放行连接、随后拒绝该地址时，不再说「有东西在拦截你」：请求确实经由配置的代理发出（route=proxy ...），代理接受连接后返回了自己的 URL 过滤页。此时旧措辞仍然说「代理、防火墙或强制门户正在拦截请求……这是网络配置问题」，会把用户推去修一个本来就正确的设置。现在这种情况下会明确说明：代理已接受连接但拒绝了该地址，这是代理上的过滤策略，既不是服务商故障，也不是代理没配好；能改变结果的只有两件事——请代理管理员放行该服务商域名，或改用网络已允许的服务商。直连情况下的措辞保持不变，因为那时「有东西在拦截你」恰恰是准确的。

• 报错中会写明被拒绝的具体地址：部分流式错误自带地址（InvalidHTTPResponse fetching <url>），另一些则完全没有（Stream ended without receiving any events）。后者出现时，报错会写出代理、代理来源和拦截页，却唯独不说是哪个地址被拒——而这正是区分「服务商流量被拦」与「本应用访问的其他站点被拦」所需的唯一信息。现在两处调用都会带上当前服务商的地址。

已知限制（明确取舍，而非默默出错）

• PAC 目前只对服务商地址求值一次，结果全局生效：启动时用服务商的 base URL 执行一次 FindProxyForURL，得到的代理会应用到本进程之后的所有出站请求。而「按 URL 分别判断」正是 PAC 存在的意义，因此访问其他主机（例如联网检索）时用的仍是服务商那条规则算出来的代理，而非脚本为该主机准备的答案。若你的 PAC 对不同站点给出不同代理，这一点可能导致部分非服务商请求被拒。上面新增的地址信息正是为定位此类情况准备的；确认后会改为按主机分别求值。
• v0.2.24 中列出的其余限制（同步的 dnsResolve、跳过 SOCKS、8 秒/1MB 抓取上限、显式代理优先、失败绝不致命）均保持不变。

验证情况

新增 3 项测试，共 46 项通过。其中包含一组对照：同一张拦截页，在有代理与无代理两种情况下必须给出相反的判断——以此确认分支依据的是路由，而非页面内容里的任何字样。新断言均经过「故意改坏使其失败」的验证，避免出现恒真的测试。

需要说明其边界：新增的地址测试证明的是「传入地址时报错会带上它」，而非「调用处确实传了」——该路径在此没有可用的测试脚手架，只能通过阅读两处调用点确认。