跟帖：10-30 灵犀升级 5.15.0 后全流程复测——通道架构未变，脚本侧修复后可跑通

技术组好，接前两条跟帖。今天（10-30）灵犀客户端推送了新版本（app_server 5.14.0 → 5.15.0），我们按约定做了全流程复测（自动启动浏览器 → 自动登录 OA → 录入一条信息 → 提交），并按昨天的三板斧（tasklist → netstat → /status 探活）做了完整取证。结论和证据如下。

一、结论

通道架构未变：native host 依然是动态端口 + 随 MV3 Service Worker 休眠被回收，10061 问题在 5.15.0 中未修复。

今天全流程能跑通，靠的是我们侧的两项改造：①连接前用 /status 探活替代盲目重试；②修正了我们脚本对 5.14.0+ API 的兼容错误。与官方通道质量无关。

今天上午实测中亲眼记录到：native host 进程在 Edge 启动后约 1 分钟内消失（MV3 休眠回收），随后又自动重生并换了一个新端口。

二、取证时间线（10-30 上午）

时间事件

08:43启动 Edge 并打开 OA 页面，native host 进程存在（PID 24352）

08:44探测脚本运行 30 秒：进程消失，未探测到可用端口

08:45–08:47发起连接 40 次，全部 10061 拒连

08:48手动 tasklist + netstat：native host 已重生（PID 11596），监听 127.0.0.1:51868（动态端口），GET /status 返回 {"pluginConnected":true}

08:49连接第 1 次即成功，视口 1920×1080 正常

08:52自动登录 OA 成功 → 录入信息（填写 10 字段 + 日期点选 + 提交确认）→ 提交成功

08:55关闭浏览器，测试闭环

三、供技术组确认的三个问题（延续昨天跟帖）

5.15.0 是否包含针对浏览器插件通道的修复？从我们实测看，动态端口与 Service Worker 休眠行为与 5.9.0/5.14.0 完全一致。

native host 随 Service Worker 休眠约 1 分钟即被回收，对批量自动化任务仍是主要障碍——是否有计划解耦生命周期或提供 keepalive？

端口动态化是否为设计变更？若有官方端口发现机制请告知，我们可以放弃 netstat 反查方案。

四、我们侧修复记录（供其他用户参考）

5.14.0 起 Browser 实例的 get_interactive_elements/fill/click 迁移到模块级；但 CDP 底层（_cdp/_session_id）仍在 core.Browser 实例上——两层对象各管各的，混用会报 module has no attribute '_session_id'。这是我们从昨天到今天踩的最后一个坑。

连接前先 /status 探活，探到 pluginConnected:true 再连接，避免盲目重试 40 次。

按上述改造后，今天全流程一次通过（登录→录入→提交确认→弹窗关闭校验）。

五、环境

WPS 灵犀 1.3.27（app_server 5.15.0）；浏览器助手插件 1.0.4；Edge / Windows 11