SuperAI Agent v0.2.29

日志与报错现在会写明「这台机器到底走的哪条网络路径」。

背景：第一份真实调试日志

v0.2.28 让调试日志真正可以打开之后，收到了企业网络机器上的第一份日志。它立刻回答了两个问题：

API error (attempt 11/11)，从 12:35:51 持续到 12:37:51 —— 自动重试确实在工作，11 次尝试全部执行；用户感受到的「卡住」，其实就是这两分钟的重试过程。
code=ConnectionRefused —— 失败原因是 TCP 连接被直接拒绝（RST），而不是此前的拦截页。清空设置页里的代理之后，本应用完全没有代理可用，于是直连，而该网络会直接拒绝直连出网。

但四个日志文件里，关于「走了哪条路径」的记录一行也没有。本次修的就是这件事。

PAC 未执行时不再悄无声息：applySystemPacProxy 中 if (!pacUrl) return null 是整个函数里唯一不打日志的分支——其余每种结果（选中代理 / 脚本判定直连 / 抓取失败 / 已有显式代理）都会记录。而它恰恰是后果最严重的一个：它意味着「没有应用任何代理」，在一个拒绝直连出网的网络上，这等于彻底不可用。现在它也会记录。
启动时记录一次网络路径：describeNetworkRoute() 早已存在，但此前只在「空回复」那一条报错里被调用过。因此从一台我们无法接触的机器上拿到日志，也依然看不出流量是否经过代理、经过哪个代理、这个选择又是从哪来的——而这恰恰是排查任何网络故障时第一个该问的问题。现在 init() 会记录一行。
连接被拒绝时，报错中带上路径信息：此前只有一句 Unable to connect to API (ConnectionRefused)，无法区分两种情况：直连被防火墙 RST，还是走了一个并未监听的代理。这两者的解决方向完全相反，而用户截图往往是唯一的证据。现在它会带上与「空回复」报错相同的 [diagnostic: route=...; proxy_source=...] 尾注。

共 35 项测试通过。连接错误携带路径信息这一条经过「故意改坏使其失败」的验证；该测试对认证环境变量自带兜底，并会还原 process.env（该对象在测试进程间共享）。按测试名比对失败集合，与基线一致。

明确说明一处测试边界：新增的两条日志语句没有测试——它们是启动过程中的日志输出，此处没有对应的测试脚手架。它们是通过对打包产物开启 DEBUG=1 实跑、断言该行确实出现来验证的，而不是靠单元测试。

SUPERAI_PAC_URL 为何缺失，目前仍不清楚。桌面端只在 Windows 报告存在 AutoConfigURL 时才会传递它，而那台机器确实配置了 PAC（这正是 v0.2.24 的结论）。新增的启动日志会在下一次运行时直接给出答案。

在此之前，请先把代理地址填回设置页：在 sidecar 拿不到 PAC 地址的情况下，那个字段是目前唯一能让流量出网的途径。