10061 拒连真因已定位——native host 动态端口 + MV3 Service Work

技术组好，接昨天关于“浏览器插件通道不稳定（BrowserConnectionError 10061）”的主帖，今天我们通过另一套独立环境（另一台 AI Agent 运行器）做了对照实测，把 10061 的真因基本锁定了，反馈给技术组参考。

一、结论先行

10061 拒连不是随机的环境故障，而是两个确定性因素叠加：

native host 监听端口已改为动态分配：旧版本固定监听 127.0.0.1:38127，现在每次启动端口都会变。任何仍按固定端口连接的调用方，表现就是 10061 拒连。

native host 进程随扩展的 MV3 Service Worker 存活，空闲几十秒会被回收：进程被回收后监听自然消失，同样表现为 10061。这就是我们观察到“同一脚本 9:39 连续 20 次全失败、9:50 未做任何改动一次成功”的随机窗口期真因。

二、定位方法（可复现）

tasklist /FI "IMAGENAME eq lingxi-native-host.exe" 观察：Edge 空闲几十秒后进程消失；操作一下扩展页面（如打开扩展的 popup/刷新页面）进程即被重新拉起。

进程存在时用 netstat -ano 反查其监听端口：每次启动端口均不同（动态分配），不再是 38127。

对该端口发起 GET http://127.0.0.1:{port}/status，返回体含 pluginConnected 字段——以此作为“通道真可用”的判活标准；仅 TCP 端口开放但 /status 不通时，实际仍不可用。

三、确认是新架构还是回归（请技术组确认）

我们无法区分这是有意的设计变更还是本轮迭代引入的回归，请技术组确认：

native host 端口动态化是否为官方设计？如果是，是否有约定的端口发现机制（如写注册表/固定文件/本地发现接口），供第三方调用方遵循，而不是靠 netstat 反查？

MV3 Service Worker 空闲回收导致 native host 被带走，对长时间运行的自动化任务（如批量表单录入）影响很大——是否考虑 native host 与 Service Worker 生命周期解耦，或提供 keepalive 机制？

/status 接口目前未在文档中出现，建议官方将其作为健康检查标准接口文档化（包括 pluginConnected 等字段含义）。

四、我们侧的临时规避方案（供其他用户参考）

连接前先探测：进程存在 → netstat 反查端口 → /status 探活通过，再建立连接；

探测失败时先区分状态：进程不在（Service Worker 休眠）→ 唤醒或重拉 Edge 即可；端口在但 /status 不通 → 扩展未连接，需重新加载扩展；

长任务期间保持页面活跃，避免 Service Worker 休眠。

按上述方案改造后，今天已完成全流程验证：自动启动浏览器 → 自动登录 OA → 批量信息录入，全部成功，未再出现 10061。

五、环境信息

WPS 灵犀客户端 1.3.27（app_server 5.9.0 → 5.14.0）；浏览器助手插件 1.0.4

Microsoft Edge（Windows 11，MV3 扩展）

另一套独立 Agent 环境（非灵犀运行时）对照实测，结论一致，可排除运行时自身问题