✅ QwenPaw Desktop 启动从 80 秒优化到 10 秒：一次 Playwright 预装的排障复盘

[lcq225]

✅ QwenPaw Desktop 启动从 80 秒优化到 10 秒：一次 Playwright 预装的排障复盘

关键词：启动慢 · Playwright 强制预装 · Embedding 配置失联 · MCP 残留 · 日志定位
相关 Issue：#7023 — Desktop startup: Playwright pre-install slows background startup

---

一、现象

QwenPaw Desktop 每次启动，界面停留在「正在连接后端」约 1~2 分钟才可用。

关键矛盾：日志显示 Server ready 仅需 ~1 秒（API 层早就绪了），但真正可用的 Background startup completed 却在 41~82 秒 之间波动。「服务已就绪」和「真正可用」之间，藏着一大段没人注意的启动成本。

二、如何定位：把日志当成长跑分段计时

Server ready 只是第一步。真正的瓶颈在 background 阶段。逐字节拆日志，锁定三个并行抢背锅的任务：

15:52:43  Server ready in 0.995s (agents loading in background)
15:52:43  Installing managed Playwright Chromium into .../browser/playwright
15:52:45  [EMBEDDING HEALTH CHECK] -> FAIL BadRequestError: 400
15:53:23  Background startup completed in 41.607 seconds

三大根因，全部浮出水面。

三、三大根因

🥇 头号元凶：Playwright Chromium 强制预装（平台层）

每次 Server ready 后，managed_playwright.py 无条件启动 Chromium 下载安装。

最关键、最反直觉的发现 ——「禁用」不等于「跳过」：

即使把浏览器工具在配置里设为 "enabled": false，后端仍会强制走一遍 Playwright 预装，两者是完全独立的逻辑。这是个不小的坑，很多人会（和我一样）误以为关闭工具就能跳过安装。

在企业/受限网络下，后果放大：

• 下载成功：白等 ~25 秒
• 下载失败：重试挂起最长 8 分钟才放弃

🥈 次因：Embedding 配置失联（配置层）

Embedding 健康检查指向了一个免费额度已耗尽的远端 API，每次启动带 5 秒超时 × 多批重试，凭空拖出一个 ~40 秒的启动「地板」。

踩坑点：配置在「远端免费额度 → Ollama SDK → 本地端口」之间反复切换，每次启动行为都不一样，极大干扰排障。配置改后必须重启验证，且保持单一事实来源。

🥉 次因：废弃 MCP 服务残留（配置层）

遗留的 MCP 服务（仍 enabled: true）启动时尝试连接各自端点，在网络受限环境下持续超时，贡献约 28~36 秒。

四、修复方案

#	动作	效果
1	停用不再使用的 MCP 服务（enabled: false）	消除 ~28-36s 超时等待
2	Embedding 切换本地 Ollama + bge-m3，并设开机自启	消除 ~40s 超时地板
3	停用浏览器工具 + 让 Playwright 成功下载一次并缓存	后续启动不再重复下载

关键的 Embedding 配置（注意 backend 类型）：

{
  "backend": "openai",        // 用 OpenAI 兼容协议连 Ollama，而非 "ollama"
  "base_url": "http://127.0.0.1:11434/v1",
  "model_name": "bge-m3",
  "dimensions": 1024
}

两个易错点：

• 必须 backend: "openai"（OpenAI 兼容协议）。选 "ollama" 会因桌面端解释器不含 ollama 库而失败。
• 本地模型需开机自启，否则重启后连不上，问题复现。

五、结果

指标	修复前	修复后
Server ready	~1s	~1s
Background startup	41~82s	~10s
用户体感	等 1~2 分钟	几乎无感

总降幅 85%+（68-82s → 约 10s）。

六、经验教训（送给踩坑的人）

1. 「禁用」不等于「跳过」：enabled: false 只影响工具是否出现在 agent 工具列表，不影响后端独立的初始化逻辑。排查时必须读 backend 源码，不能只看配置项名。

2. Server ready 不代表启动完成：真正的启动标尺是 Background startup completed in X seconds。只看 ready 会漏掉整段后台成本。

3. 配置跳变是隐形杀手：改配置务必「改一处 → 重启 → 验证一处」，保持单一事实来源，否则每次启动行为都不同，无法定位。

4. 不要过度设计：优化到 10s 已是正常范围，剩下的「可优化项」收益低、风险高，保持不动即可。

---

如果你也遇到「服务已就绪却迟迟不能用的启动慢」，先别急着怀疑网络或模型——先看把 Server ready 到 Background startup completed 那段日志，Playwright 预装往往是隐形元凶。

[rayrayraykk]

Thanks for your report! We will look into this issue!

---

Thanks for the detailed write-up! We checked the latest upstream main, and several points have already been addressed:

• Playwright: fix(browser): move managed Chromium install off startup critical path #7539 removed Chromium installation from the startup path. Installation now happens on demand when opening a browser session, or after an explicit browser-settings save.
• Ollama: fix(deps): enable Ollama embedding backend #7131 added the Ollama SDK dependency, so using the native ollama embedding backend should no longer require the OpenAI-compatible workaround in builds containing this fix.
• Embedding: The currently pinned ReMe version runs startup embedding backfill and its health check in the background, so the original ~40-second startup delay should no longer apply in the same way. An unavailable provider can still affect embedding functionality.

One gap remains: enabled but unreachable MCP servers can still delay agent readiness. #7174 made their initialization concurrent, but startup still waits for those connection attempts, with a default connection timeout of 30 seconds. Disabling unused servers therefore remains useful.

Also, core readiness is now signaled before Background startup completed, so that final log line no longer directly represents when the app becomes usable.

These findings are based on the latest source and pinned dependency code; we haven’t yet verified the timing in a Windows Desktop build. Thanks again for highlighting the distinction between HTTP server readiness and actual agent readiness—it helped identify the remaining MCP startup gap.