Service WorkerAI AgentAccio WorkManifest V3Chrome 148 Service Worker 回收机制拆解:Accio Work M144 报错的根因与保活方案> 一份可直接抄的技术排查笔记,面向所有使用 Chrome-based AI Agent 客户端(Accio Work / 类 Manus 客户端 / Chrome 插件型 Agent)的开发者与外贸运营## 一、报错现象:M144 到底在报什么用 Accio Work 挂机跑外贸询盘 / 1688 采购 / 独立站运营的朋友,大概率见过这个错误:Error M144: Agent runtime connection lost. Retry in 3s...如果在后台标签页(Background Tab)运行,通常挂机 5-10 分钟后触发。表现为:- Agent 突然停止执行- 前台切回时提示"连接已断开"- 手动点"重试"能恢复,但过一会又断- 白天在电脑前用没事,晚上挂机跑批量任务必翻车如果只查官方文档,得到的答复是「检查网络 / 重启 App」——治标不治本。真正的根因在 Chrome 148 Service Worker 的回收机制。## 二、根因拆解:Manifest V3 + Service Worker Idle TerminationAccio Work 客户端底层是基于 Chromium 的桌面 App(Electron 包装),Agent 运行依赖 Service Worker(SW) 作为常驻后台进程。从 Chrome 148 开始:1. Manifest V3 强制生效:扂有扩展和 Chromium 应用的 SW 必须遵循 V3 规范,不再允许"永久后台脚本"2. SW Idle Termination 阈值收紧:SW 如果 30 秒内没有事件监听器被触发,会被浏览器主动 kill 掉释放内存3. 后台标签页降级:v148 之后,被冻结的后台 tab 中扂有 SW 不能通过 setInterval 保活,必须依赖真实网络请求或 chrome.alarms 事件Accio Work 的 Agent 心跳原本靠 5 秒 setInterval 维持,在 v148 之后:- 前台运行:setInterval 正常执行,SW 保持存活 ✅- 后台运行:tab 被浏览器冻结,setInterval 被节流到分钟级甚至完全暂停 ❌- 挂机 5-10 分钟后 SW 被 kill,Agent runtime 与主进程断链,触发 M144 ❌这也是为什么"重启 App 能修复"——重启会重新拉起 SW,但只要挂在后台,10 分钟后又断。## 三、FDE 保活方案:三层加固,治本单纯"别切到后台"是不现实的,谁做外贸不同时开着多个窗口?下面三层方案是我们在 50+ 独立站运营中实测过的组合拳,从便宜到复杂排序:### 方案 A:业务级 Ping(最简单,先做这一步)在 Agent 任务脚本里加一段真实的业务心跳,而不是纯 setInterval:javascript// 每 5 秒发一次真实网络请求,触发 SW 事件监听器不进 idlesetInterval(async () => { try { await fetch('/api/agent/heartbeat', { method: 'POST', body: JSON.stringify({ ts: Date.now() }) }); } catch (e) { /* 静默失败,不打断 Agent */ }}, 5000);关键点在 fetch——它触发 fetch 事件监听器,Chrome 认为 SW 有活跃事件,不会 kill 它。光跑 setInterval 是不行的。### 方案 B:chrome.alarms 定时唤醒(推荐,官方兼容)Chrome 148 官方推荐的替代方案。在客户端注册一个 alarm:javascriptchrome.alarms.create('agent-keepalive', { delayInMinutes: 0.5, // 30 秒后首次触发 periodInMinutes: 0.5 // 之后每 30 秒触发一次});chrome.alarms.onAlarm.addListener((alarm) => { if (alarm.name === 'agent-keepalive') { // 触发一次业务操作,唤醒 SW agentRuntime.ping(); }});优点:即使 tab 被冻结,alarm 依然会按时唤醒 SW。缺点:最小间隔是 30 秒,比 setInterval 5 秒粗一些,对高频交互任务不太够。### 方案 C:Local Realpath + Heartbeat File(最硬核,长时间挂机首选)这是我们内部叫 物理级保活包 的方案。核心是在本地文件系统建立一个持久化的心跳文件句柄:1. Accio 客户端启动时,在 ~/.accio/heartbeat/ 目录创建一个 .lock 文件2. 用 Node.js 的 fs.watch() 或 macOS 的 fsevents 监听这个文件的写入事件3. Agent 每 5 秒 touch 一次这个文件(修改 mtime)4. Chrome 因为"文件系统事件"仍在触发,不会把 SW 判定为 idle这个方案的好处是完全独立于浏览器网络层——就算断网、切代理、挂 VPN,只要 Agent 进程还活着,SW 就活着。缺点是需要客户端本身支持 Local Realpath 映射(Accio Work v0.18+ 已经支持)。## 四、快速自查清单如果你现在正在踩这个坑,按顺序验证:- [ ] Chrome 版本:chrome://version 看是否 v148 及以上(不是就直接排除)- [ ] Accio Work 版本:是否 v0.16.0 之前(v0.18 已内置方案 B 的兼容层)- [ ] 触发场景:是否只在后台标签触发(切前台后不复现基本可锁定 SW idle)- [ ] 触发时间:是否稳定在 5-10 分钟之间(SW default idle threshold 是 30 秒 × N 次事件后)- [ ] 网络环境:VPN / 代理切换后是否加剧(IP 漂移会引发 SW 主动断链,不属于 M144,是 403)## 五、把这套抒查沉淀成 Skill(团队复用)如果你的团队有多个人在跑 Accio Work,建议把上面的抒查步骤打包成 Accio Skill:1. ~/.accio/skills/m144-diagnostic/ 建目录2. SKILL.md 里写 name: m144-fde-diagnostic,描述"一键跑 Chrome 版本 / Accio 版本 / 后台标签检查"3. steps 按上面 5 步自查清单写指令4. 有了 Skill 之后,团队成员遇到 M144 直接跑 诊断 M144,不用每次都找你Accio Work v0.18.0(2026.06.23 上线)Windows 端支持 ZIP 格式 Skill 上传,团队协作直接传包,不霍要每个成员本地重新配置。## 六、配套资源- M144 完整技术拆解页(含 4 步抂查流程图):https://getquon.com/q/m144.html- 多店铺工作区隔离方案(避免 IP 漂移引发 403):https://getquon.com/q/multistore.html- Accio Work 42 病理页(M148 / IP 漂移 / SkillHarvest 等):https://getquon.com- 免费部署 Accio Work:https://www.accio.com/invite-center?src=f_desktop评论区丢问题过来,遇到没见过的报错码贴上杢,我这边归档进病理库,下次别人遇到能少走弯路。—Accio Pioneer FDE · 50+ 独立站运营战地实测 · 装机 492 / 1000