perf(startup): lazy-load Google GenAI SDK on first use

[doudouOUC]

What this PR does

This PR removes @google/genai from the ACP bootstrap static closure. Core orchestration now uses a package-local, SDK-parity implementation for the small synchronous surface it needs while retaining the official SDK types and provider response classes.

Provider construction and the logging decorator are loaded through a single-flight lazy content generator on the first asynchronous model operation. Configuration validation, runtime fetch preparation, and Qwen OAuth credential acquisition keep their existing eager timing. MCP tool adaptation loads the official SDK on discovery, and the bundle boundary guard now rejects any future static SDK path from the ACP entry.

Why it's needed

Candidate 3 in #7264 identified the Google GenAI SDK as a remaining ACP cold-start cost after the telemetry and undici lazy-loading work had landed. A dynamic import alone was insufficient because ACP session creation eagerly constructed the selected provider, so the SDK would merely have moved from initialize into POST /session.

The bundled ACP static closure decreased from 14,279,497 bytes to 13,280,177 bytes, a 999,320-byte reduction. The 755,788 bytes attributed directly to @google/genai dropped to zero in the static closure while remaining available in dynamic provider and MCP chunks.

On the 2-vCPU reference host, 30 alternating paired cold starts with telemetry enabled to an outfile improved channel.initialize P50/P95 from 984.9/1010.6 ms to 954.8/972.5 ms, process-to-first-session from 1924.6/1951.1 ms to 1858.7/1901.0 ms, and peak RSS from 414.6/427.1 MiB to 406.5/420.5 MiB. A separate 30-pair telemetry-off run with an immediate real prompt improved process-to-first-token P50 from 2900.7 ms to 2843.1 ms; first-token P95 was dominated by unrelated multi-second model-network outliers, so this PR does not claim a first-token tail improvement.

Reviewer Test Plan

How to verify

• Build the release bundle and run the serve fast-path boundary check. The ACP static closure should contain no @google/genai input, while dynamic provider and MCP chunks should still contain the SDK.
• Start the bundled daemon without MCP servers and create an ACP session. Initialization and session creation should succeed without evaluating the SDK; the first content-generator operation should load the selected provider once, including when two first operations race.
• With Qwen OAuth selected, valid cached credentials should still be acquired before session registration, and missing or expired cached credentials should reject initial authentication with the existing /auth guidance rather than starting device flow after the session has been accepted.
• Exercise OpenAI-compatible, Qwen OAuth, Anthropic, Gemini, and Vertex configurations. Provider behavior, summarized-thinking selection, auth refresh, per-model routing, subagent overrides, and logging should remain unchanged after first use.
• Configure an MCP server and confirm discovery, schemas, annotations, duplicate-name handling, pagination, and direct tool invocation still use the SDK adapter successfully.

Evidence (Before & After)

N/A (no user-visible or TUI change). The cold-start and memory measurements are reported above and in the committed design document.

Tested on

OS	Status
🍏 macOS	✅
🪟 Windows	⚠️
🐧 Linux	✅

Environment (optional)

macOS 26.4.1 with Node.js 22.22.3: build, full workspace typecheck, affected-file ESLint, 805 targeted core tests, 299 ACP integration tests, 27 bundle-guard tests, release bundle, and startup boundary check. Alibaba Cloud Linux with 2 vCPUs, approximately 3.5 GiB RAM, no swap, and Node.js 22.23.1: 30-pair cold and preheated benchmarks, concurrent-session/telemetry-disabled/legacy functional checks, and a 30-pair immediate live OpenAI-compatible prompt run.

Risk & Scope

• Main risk or tradeoff: Provider module or constructor failures now surface on the first asynchronous model operation rather than during content-generator creation. Configuration errors and initial Qwen OAuth credential failures remain eager. An MCP configuration may load the SDK during background discovery before the first model prompt.
• Not validated / out of scope: Live Gemini, Vertex, and Anthropic calls were not available on the benchmark host; their construction and compatibility paths are covered by unit tests. First-token P95 is not claimed as an improvement because live model-network variance dominated the tail. Other lazy-loading candidates in Cold-start follow-ups: remaining lazy-loading candidates from the ACP eager-closure audit #7264 remain out of scope.
• Breaking changes / migration notes: None. The public content-generator interface and documented provider configuration remain unchanged.

Linked Issues

Part of #7264. Implements candidate 3 without closing the tracking issue.

中文说明

本 PR 做了什么

本 PR 将 @google/genai 从 ACP 启动静态闭包中移除。Core 编排层现在通过包内、与 SDK 行为一致的实现提供所需的少量同步能力，同时继续使用官方 SDK 类型和 provider 响应类。

Provider 构造和 logging 装饰器通过单飞懒加载 content generator，在首次异步模型操作时加载。配置校验、运行时 fetch 准备和 Qwen OAuth 凭证获取仍保持原有的急切执行时机。MCP 工具适配在 discovery 时加载官方 SDK，bundle 边界守卫也会阻止未来从 ACP 入口重新静态引入 SDK。

为什么需要

#7264 的 candidate 3 指出，在 telemetry 和 undici 懒加载工作合入后，Google GenAI SDK 仍是 ACP 冷启动成本之一。仅改成动态 import 并不足够，因为 ACP session 创建仍会急切构造选定 provider，SDK 只会从 initialize 阶段移动到 POST /session 阶段。

打包后的 ACP 静态闭包从 14,279,497 bytes 降至 13,280,177 bytes，减少 999,320 bytes。静态闭包中直接归属于 @google/genai 的 755,788 bytes 降为零，同时 SDK 仍保留在动态 provider 和 MCP chunks 中。

在 2 vCPU 参考机器上，开启 telemetry outfile 的 30 对交替冷启动中，channel.initialize P50/P95 从 984.9/1010.6 ms 改善至 954.8/972.5 ms，进程到首 session 从 1924.6/1951.1 ms 改善至 1858.7/1901.0 ms，峰值 RSS 从 414.6/427.1 MiB 降至 406.5/420.5 MiB。另一次关闭 telemetry、启动后立即发送真实 prompt 的 30 对测试中，进程到首 token P50 从 2900.7 ms 改善至 2843.1 ms；首 token P95 受到互不相关的多秒模型网络离群点主导，因此本 PR 不宣称首 token 长尾改善。

Reviewer 测试计划

如何验证

• 构建 release bundle 并运行 serve fast-path 边界检查。ACP 静态闭包不应包含任何 @google/genai input，而动态 provider 和 MCP chunks 仍应包含 SDK。
• 在不配置 MCP server 的情况下启动打包 daemon 并创建 ACP session。初始化和 session 创建应在未执行 SDK 的情况下成功；首次 content-generator 操作应只加载一次选定 provider，包括两个首次操作并发竞争时。
• 选择 Qwen OAuth 时，有效缓存凭证仍应在 session 注册前获取；缺失或过期的缓存凭证应通过现有 /auth 提示拒绝初始认证，而不是在 session 已接受后才启动 device flow。
• 验证 OpenAI-compatible、Qwen OAuth、Anthropic、Gemini 和 Vertex 配置。首次使用后的 provider 行为、summarized-thinking 选择、auth refresh、按模型路由、subagent override 和 logging 应保持不变。
• 配置 MCP server，确认 discovery、schema、annotation、重名处理、分页和直接工具调用仍能正确使用 SDK adapter。

证据（修改前后）

N/A（无用户可见或 TUI 变更）。冷启动与内存测量已在上文及提交的设计文档中报告。

测试平台

OS	Status
🍏 macOS	✅
🪟 Windows	⚠️
🐧 Linux	✅

环境（可选）

macOS 26.4.1、Node.js 22.22.3：build、完整 workspace typecheck、受影响文件 ESLint、805 项目标 core 测试、299 项 ACP 集成测试、27 项 bundle guard 测试、release bundle 和启动边界检查。Alibaba Cloud Linux、2 vCPU、约 3.5 GiB RAM、无 swap、Node.js 22.23.1：30 对冷启动与预热基准、并发 session/telemetry-disabled/legacy 功能检查，以及 30 对启动后立即发送真实 OpenAI-compatible prompt 的测试。

风险与范围

• 主要风险或权衡：Provider 模块或构造器错误现在会在首次异步模型操作时暴露，而不是在 content-generator 创建时暴露。配置错误和初始 Qwen OAuth 凭证失败仍保持急切执行。配置 MCP 时，SDK 可能在首次模型 prompt 前由后台 discovery 加载。
• 未验证 / 超出范围：Benchmark 主机上没有可用的 Gemini、Vertex 和 Anthropic 真实调用凭证；其构造和兼容路径由单元测试覆盖。由于真实模型网络波动主导长尾，本 PR 不宣称首 token P95 改善。Cold-start follow-ups: remaining lazy-loading candidates from the ACP eager-closure audit #7264 中其他懒加载候选不在本 PR 范围内。
• 破坏性变更 / 迁移说明：无。公共 content-generator 接口和文档化 provider 配置保持不变。

关联 Issue

属于 #7264 的一部分。实现 candidate 3，但不关闭该跟踪 issue。

[qwen-code-ci-bot]

Thanks for the PR!

Template looks good ✓

Problem: clearly observed and well-measured. The ACP static closure carries ~756 KB of @google/genai that is parsed on every cold start despite not being needed until the first model operation. The 30-pair benchmark data (P50 -30ms on channel.initialize, -66ms process-to-first-session, -8 MiB RSS) demonstrates a real, reproducible cold-start cost. This is candidate 3 from the #7264 tracking issue, so the problem is already triaged and prioritised.

Direction: aligned. Startup latency is a core product concern, and the #7264 tracking issue explicitly scopes this work. CHANGELOG has no direct reference to lazy-loading the GenAI SDK, but startup performance is a recurring theme in the ecosystem.

Size: 264 production logic lines (additions + deletions), 313 test lines, 96 docs lines. Core paths are touched (packages/core/src/**), but production lines are well under the 500-line advisory threshold.

Approach: the scope feels right. The design doc considers and rejects five alternatives, and the implementation follows through on the chosen path cleanly — a small genai-compat.ts for the synchronous surface, a single-flight LazyContentGenerator for deferred provider construction, eager Qwen OAuth credential checks preserved, and a bundle guard to prevent regression. Every file in the diff serves the stated goal; no drive-by changes. The two follow-up commits address the earlier review feedback (bundle-guard wording narrowed to @google/genai, a real ERR_MODULE_NOT_FOUND test via a fresh module graph, and the Google/Apache-2.0 attribution added beside the adapted conversion helpers). Moving on to code review. 🔍

中文说明

感谢贡献！

模板完整 ✓

问题：已观测且有充分测量。ACP 静态闭包中携带约 756 KB 的 @google/genai，每次冷启动都会解析，但直到首次模型操作才需要。30 对基准数据（channel.initialize P50 -30ms、进程到首 session -66ms、RSS -8 MiB）证明了真实的冷启动成本。这是 #7264 跟踪 issue 的 candidate 3，问题已经过分类和优先级排序。

方向：对齐。启动延迟是核心产品关注点，#7264 跟踪 issue 明确将此工作纳入范围。

规模：264 行生产逻辑（增+删），313 行测试，96 行文档。触及核心路径（packages/core/src/**），但生产行数远低于 500 行建议阈值。

方案：范围合理。设计文档考虑并否决了五种替代方案，实现干净地遵循了选定路径——小型 genai-compat.ts 提供同步表面、单飞 LazyContentGenerator 延迟 provider 构造、保持 Qwen OAuth 凭证急切检查、bundle 守卫防止回归。diff 中每个文件都服务于既定目标，无夹带改动。两个后续提交已处理早先的审查意见（bundle 守卫措辞收窄到 @google/genai、通过全新模块图实现真实的 ERR_MODULE_NOT_FOUND 测试、在改编的转换 helper 旁补充 Google/Apache-2.0 署名）。进入代码审查 🔍

— Qwen Code · qwen3.8-max-preview

_{Reviewed at b67c64770589a2439fcf07e9b1c3eca4bb105eba · re-run with @qwen-code /triage}

[wenshao]

Code Review — perf(startup): lazy-load Google GenAI SDK on first use

Reviewed the full diff (16 files, +546/-88) plus the referenced SDK source and every downstream consumer of the rerouted imports. This is a well-scoped, well-documented change and I verified the risky parts against @google/genai directly. No blocking issues found; notes below are mostly maintainability/edge-case.

What it does

Removes @google/genai from the ACP bootstrap static closure (≈999 KB / 755 KB attributable to the SDK). It does this three ways: (1) a package-local genai-compat.ts supplies the tiny synchronous surface core orchestration needs (FinishReason, FunctionCallingConfigMode, createUserContent, createModelContent); (2) createContentGenerator now returns a single-flight LazyContentGenerator that defers provider construction + LoggingContentGenerator wrapping to the first async op; (3) mcpToTool moves to a dynamic import in discoverTools. A bundle guard entry makes any future static re-import fail CI.

Correctness — verified ✅

• genai-compat content conversion is a faithful copy. isPart uses the exact key set as the SDK's _isPart (fileData/text/functionCall/functionResponse/inlineData/videoMetadata/codeExecutionResult/executableCode); string→{text} matches createPartFromText; the three error messages and the branch ordering match _toParts. genai-compat.test.ts cross-checks output and validation against the real SDK, which is the right way to lock this.
• The compat approach is sound because these are string enums. FinishReason.STOP === 'STOP', FunctionCallingConfigMode.ANY === 'ANY', etc. Provider converters still import the real SDK enums, and cross-boundary comparisons (e.g. baseLlmClient.ts:281 sets mode: FunctionCallingConfigMode.ANY, consumed downstream) stay equal by string value. Confirmed each rerouted file only uses members present in the compat (STOP/MAX_TOKENS/ANY).
• useSummarizedThinking() hardcoding is faithful. The lazy value authType === USE_GEMINI || USE_VERTEX_AI matches every provider: Gemini true, Vertex→Gemini true, OpenAI/Qwen(extends OpenAI)/Anthropic false.
• No caller unwraps the concrete generator. Repo-wide, getWrapped()/instanceof LoggingContentGenerator have no production callers, so returning LazyContentGenerator (which wraps LoggingContentGenerator internally, preserving logging/telemetry) is safe. The removed instanceof assertions in the test are appropriate.
• Single-flight is correct. this.generatorPromise ??= this.loader() is atomic w.r.t. the event loop (no await between read and assign); the concurrent-calls test proves createCount === 1.
• Eager Qwen credential check preserved. OAuth acquisition stays before session registration; the captured qwenClient is closed over and only the QwenContentGenerator construction defers. Tested for both success and cached-credential-failure-rejects paths.
• ACP closure stays clean. acpAgent.ts, session/Session.ts, history-replayer.ts all import @google/genai type-only (erased); the new guard + boundary tests backstop regressions.

Notes / suggestions (non-blocking)

1. Partial-enum compat is TS-guarded but under-commented (low). FinishReason/FunctionCallingConfigMode in genai-compat.ts intentionally expose only the members core code uses. Accessing an absent member (e.g. FinishReason.SAFETY) is a compile error thanks to as const, so this is safe — but a one-line comment ("only the subset used by non-provider core code; provider converters still use the SDK enum") would prevent a future contributor from assuming it's the full enum, and the genai-compat.test.ts parity list must be extended in lockstep whenever a member is added.

2. Failed loader promise is sticky (low, partly documented). A first-use load failure caches the rejected promise, so every subsequent call on that generator fails identically until refreshAuth() rebuilds it. Correct for the ERR_MODULE_NOT_FOUND "needs restart" case; for other provider-construction errors it means a session that looked healthy at creation now fails on first prompt and stays failed. Provider constructors are effectively deterministic so this is acceptable, and it's covered by the Risk & Scope "failure surfaces on first async op" note — just calling it out explicitly.

3. Config captured by reference (low, documented). The loader closes over generatorConfig/config, so a same-provider model change between createContentGenerator and first use is observed by the deferred constructor (vs. the old snapshot-at-construction). Documented in the design doc; edge case, fine.

4. await import('@google/genai') runs per discoverTools() call. Module cache makes repeats ~free, so no real cost — noting only that MCP-configured setups still evaluate the full SDK during background discovery (as the PR states).

Test coverage

Strong: deferred construction, concurrent single-flight, Qwen eager-check + failure, module-not-found→restart wrapping, non-module re-throw, and SDK-parity for the compat helpers. Minor gaps worth a follow-up: no assertion that useSummarizedThinking() is true for USE_VERTEX_AI specifically, and no direct test for the sticky-rejection recovery or the generateContentStream/embedContent passthroughs.

Verdict

Correct, faithful to the SDK where it matters, and the perf/closure win is backed by a bundle guard so it won't silently regress. Approve with the minor notes above (a comment on the partial-enum module being the only one I'd actually action before merge).

[yiliang114]

The lazy-loading design is solid — single-flight loader, eager Qwen OAuth credential check preserved, bundle guard prevents future regression. Design doc is thorough and the benchmark methodology is honest about what it does and doesn't claim.

One blocking item and a few non-blocking observations.

Blocking: copyright headers on new files

genai-compat.ts and genai-compat.test.ts both say Copyright 2025 Google LLC. These are new Qwen-authored files — the repo convention for those is Copyright 2026 Qwen Team (see session-start-profiler.ts, grepReadTracking.ts, notebook-edit.test.ts, etc.).

Non-blocking:

1. Error message text in toParts doesn't exactly match the SDK. The compat module throws 'partOrString must be a Part object, string, or array' where the SDK throws 'partOrString must be a Part object'; same pattern for the array-element message (or string suffix). Tests pass because toThrow does substring matching, but the test name says "matches SDK validation" — the messages aren't identical. No behavioral impact.

2. LazyContentGenerator caches a rejected loader promise permanently (this.generatorPromise ??= this.loader()). A transient dynamic-import failure sticks until refreshAuth() rebuilds the generator. The design doc documents this as the intended retry boundary — just noting that clearing the promise on rejection would allow next-call retry if that ever becomes desirable.

3. isPart checks 8 properties matching the current SDK Part type. If the SDK adds a new part field later, this won't recognize it. Low risk since the parity test compares against the actual SDK at test time.

[qwen-code-ci-bot]

Code Review

Independent proposal: given the goal "remove @google/genai from the ACP static closure", I would (1) convert value imports of the small synchronous surface (FinishReason, FunctionCallingConfigMode, createUserContent, createModelContent) to a local compat module, (2) convert remaining SDK imports to import type where only types are used, (3) wrap provider construction in a lazy single-flight loader so the SDK loads on first async operation, (4) keep Qwen OAuth credential acquisition eager, (5) make MCP's mcpToTool a dynamic import inside discoverTools(), and (6) add a bundle guard.

Comparison with the diff: the PR's approach matches this proposal almost exactly, and the implementation is clean:

• genai-compat.ts is minimal — only the four synchronous values core orchestration needs, with type-only SDK imports. The parity test verifies values and validation messages match the real SDK. The follow-up commit added the Google/Apache-2.0 attribution beside the adapted _isPart/_toParts helpers, which was the right call.
• LazyContentGenerator is a textbook single-flight wrapper. generatorPromise ??= this.loader() guarantees one load across concurrent first calls. I verified the hardcoded useSummarizedThinking() mapping against every provider: geminiContentGenerator returns true, openaiContentGenerator/anthropicContentGenerator return false, and QwenContentGenerator extends OpenAIContentGenerator (so false) — the authType-based boolean (true for Gemini/Vertex, false otherwise) matches all five providers exactly, so deferring it ahead of provider load is not a behavior change.
• The LoggingContentGenerator import is parallelised with the provider load via Promise.all — avoids serialising two dynamic imports.
• Qwen OAuth credential acquisition stays eager in createContentGenerator(); only the QwenContentGenerator construction is deferred, preserving the existing auth-failure UX (missing/expired cached creds still reject session creation).
• The mcpToTool dynamic import inside discoverTools() is the right call — replacing it locally would duplicate experimental SDK behavior.
• The sticky-rejection behavior of the cached loader promise is intentional and documented: a failed first load stays failed until refreshAuth() rebuilds the generator, which is the correct retry boundary for immutable chunk/config failures.
• I confirmed the design doc's downstream-consumer audit: getWrapped() is defined but never called in production, and no code does instanceof LoggingContentGenerator, so nothing unwraps the lazy wrapper.

No critical blockers or AGENTS.md violations found.

sequenceDiagram
    participant P1 as createContentGenerator
    participant P2 as LazyContentGenerator
    participant P3 as Provider Loader
    participant P4 as LoggingContentGenerator
    P1->>P1: validate config, preload fetch, Qwen OAuth (eager)
    P1->>P2: return lazy wrapper
    Note over P2: first async call (generateContent, countTokens, etc.)
    P2->>P3: single-flight loader (once)
    P3->>P3: dynamic import provider module
    P3->>P4: wrap in LoggingContentGenerator
    P4-->>P2: resolved ContentGenerator
    P2-->>P2: delegate all subsequent calls

Loading

Files changed (16 total)

File	What changed
docs/design/2026-07-22-lazy-google-genai-loading.md	Design doc covering problem, design, alternatives, and benchmark results
packages/core/src/core/genai-compat.ts	New module providing FinishReason, FunctionCallingConfigMode, createUserContent, createModelContent without SDK runtime
packages/core/src/core/genai-compat.test.ts	Parity tests verifying compat values and validation match the real SDK
packages/core/src/core/contentGenerator.ts	Core change: LazyContentGenerator class, deferred provider construction, parallel LoggingContentGenerator import
packages/core/src/core/contentGenerator.test.ts	Updated tests for deferred construction, single-flight, Qwen credential timing, real ERR_MODULE_NOT_FOUND via fresh module graph
packages/core/src/core/turn.ts	Import FinishReason from genai-compat instead of SDK
packages/core/src/core/client.ts	Import createUserContent from genai-compat instead of SDK
packages/core/src/core/geminiChat.ts	Import createUserContent and FinishReason from genai-compat
packages/core/src/core/baseLlmClient.ts	Import FunctionCallingConfigMode from genai-compat
packages/core/src/agents/runtime/agent-core.ts	Import FinishReason from genai-compat
packages/core/src/services/chatRecordingService.ts	Import createModelContent and createUserContent from genai-compat
packages/core/src/confirmation-bus/types.ts	Convert to import type for full erasure
packages/core/src/core/geminiRequest.ts	Convert to import type for full erasure
packages/core/src/tools/mcp-client.ts	Dynamic import of mcpToTool inside discoverTools
scripts/check-serve-fast-path-bundle.js	Add google/genai to ACP forbidden packages
scripts/tests/serve-fast-path-bundle-check.test.js	Tests for static detection and dynamic allowance

Real-Scenario Testing

No user-visible TUI change — verified build, bundle boundary, and a live headless prompt on the bundled PR build (current head b67c64770).

Unit tests (worktree, PR head):

 ✓ src/core/genai-compat.test.ts (7 tests) 4ms
 ✓ src/core/contentGenerator.test.ts (12 tests) 555ms
 Test Files  2 passed (2)
      Tests  19 passed (19)

 ✓ scripts/tests/serve-fast-path-bundle-check.test.js (27 tests) 95ms
 Test Files  1 passed (1)
      Tests  27 passed (27)

Build + bundle + boundary check + live prompt (tmux capture-pane):

$ npm run build && DEV=true npm run bundle
BUILD_BUNDLE_EXIT=0
✅ All bundle assets copied to dist/

$ node scripts/check-serve-fast-path-bundle.js
Startup bundle closure checks passed.
BOUNDARY_EXIT=0

$ node dist/cli.js --version
0.20.1
VERSION_EXIT=0

$ timeout 120 node dist/cli.js -p 'reply with the single word: hello' --output-format text
hello
PROMPT_EXIT=0

The boundary guard passing on the freshly built bundle confirms @google/genai is absent from the ACP static closure (and the 27 guard tests confirm it still detects a static re-import while allowing the SDK behind dynamic imports). The live headless prompt shows the lazy-loaded provider constructs correctly on first use and the model responds. TypeScript compilation passed as part of npm run build.

中文说明

代码审查

独立方案： 给定目标"从 ACP 静态闭包中移除 @google/genai"，我会 (1) 将小型同步表面（FinishReason、FunctionCallingConfigMode、createUserContent、createModelContent）的值导入转换为本地兼容模块，(2) 将仅使用类型的 SDK 导入转换为 import type，(3) 将 provider 构造包装在懒加载单飞加载器中，使 SDK 在首次异步操作时加载，(4) 保持 Qwen OAuth 凭证获取为急切执行，(5) 将 MCP 的 mcpToTool 改为 discoverTools() 内的动态导入，(6) 添加 bundle 守卫。

与 diff 的比较： PR 方案与此提案几乎完全一致，实现干净。已逐一核对 useSummarizedThinking() 的硬编码映射与全部五个 provider 一致（Gemini/Vertex 为 true，OpenAI/Anthropic/Qwen 为 false，其中 Qwen 继承自 OpenAI），因此提前返回该布尔值不构成行为变化。同时确认 getWrapped() 仅有定义、生产代码无任何调用，也没有 instanceof LoggingContentGenerator，因此没有消费者会解开懒包装。未发现关键阻塞问题或 AGENTS.md 违规。

实际场景测试

无用户可见 TUI 变更——在当前 head b67c64770 的打包 PR 构建上验证了构建、bundle 边界与真实无头 prompt。

• 单元测试：46 项全部通过（genai-compat 7 项、contentGenerator 12 项、bundle guard 27 项）
• 构建 + bundle + 边界检查（tmux capture-pane）：BUILD_BUNDLE_EXIT=0、Startup bundle closure checks passed.、BOUNDARY_EXIT=0
• 真实无头 prompt：hello、PROMPT_EXIT=0——懒加载 provider 在首次使用时正确构造，模型正常响应
• TypeScript 编译随 npm run build 通过

— Qwen Code · qwen3.8-max-preview

_{Reviewed at b67c64770589a2439fcf07e9b1c3eca4bb105eba · re-run with @qwen-code /triage}

[qwen-code-ci-bot]

Confidence: 5/5 — clean across every stage on re-review; the design is well-reasoned, the implementation is minimal, and the results are verified on a real build.

This is what a good performance PR looks like. The problem is real and measured (756 KB of SDK parsed on every cold start), the design doc considers five alternatives and explains why each was rejected, and the implementation follows through with the minimum code needed — an 83-line compat module, a single-flight lazy wrapper, and import rewiring. No scope creep, no drive-by refactors, no unnecessary abstractions.

On this re-run I re-verified against the current head (b67c64770), including the two follow-up commits that addressed the earlier review feedback (bundle-guard wording narrowed to @google/genai, a real ERR_MODULE_NOT_FOUND test via a fresh module graph, and the Google/Apache-2.0 attribution). The things I checked most carefully:

• useSummarizedThinking mapping: now returned ahead of provider load, so I confirmed it against every provider implementation — Gemini/Vertex return true, OpenAI/Anthropic return false, and Qwen extends OpenAI (false). The authType-based boolean matches all five exactly; not a behavior change.
• Qwen OAuth timing: credential acquisition stays eager, only provider construction is deferred. An expired credential still rejects session creation with the existing /auth guidance. Verified in the test suite.
• Single-flight correctness: concurrent first calls share one loader promise; the test fires two countTokens in parallel and asserts the provider is constructed exactly once.
• No unwrapping: getWrapped() is defined but never called in production and nothing does instanceof LoggingContentGenerator, so the lazy wrapper is opaque to all consumers.
• Bundle guard + live build: 46 targeted tests pass, the freshly built bundle passes the closure check (@google/genai out of the ACP static closure, still shipped in dynamic chunks), and a live headless prompt responds — the lazy provider constructs on first use.

This also aligns with the maintainer's independent A/B verification on the same head, which reproduced the −999,320-byte closure reduction byte-for-byte and confirmed SDK parity (61/61 checks) and runtime deferral.

If I had to maintain this in six months, I'd thank the author — the bundle guard prevents regression, the design doc explains the why, and the code is straightforward.

中文说明

置信度：5/5 —— 复审后每个阶段都很干净；设计合理，实现最小化，结果已在真实构建上验证。

这是一个优秀的性能 PR 的典范。问题真实且有测量（每次冷启动解析 756 KB SDK），设计文档考虑了五种替代方案并解释了否决原因，实现以最少代码完成——83 行兼容模块、单飞懒加载包装器和导入重连。无范围蔓延、无顺手重构、无不必要的抽象。

本次复审针对当前 head（b67c64770），包含处理早先审查意见的两个后续提交。重点核对：useSummarizedThinking 映射已与全部五个 provider 逐一对照，完全一致，不构成行为变化；Qwen OAuth 凭证获取保持急切执行；并发首次调用共享一个 loader promise；getWrapped() 仅有定义、生产代码无调用，懒包装对所有消费者透明；46 项目标测试通过，新构建 bundle 通过闭包检查，真实无头 prompt 正常响应。

这也与维护者在同一 head 上的独立 A/B 验证一致——其逐字节复现了 −999,320 字节的闭包缩减，并确认 SDK 等价性（61/61）与运行时延迟加载。

— Qwen Code · qwen3.8-max-preview

_{Reviewed at b67c64770589a2439fcf07e9b1c3eca4bb105eba · re-run with @qwen-code /triage}

[qwen-code-ci-bot]

LGTM, looks ready to ship. ✅

[doudouOUC]

Addressed the first review round in 8ca1571f63.

Feedback	Decision	Action
New-file copyright headers	Fixed	Updated both new files to Copyright 2026 Qwen Team.
Partial runtime enum surface is under-commented	Fixed	Added a concise comment stating that the runtime values are intentionally limited to the subset used outside provider adapters.
Compat validation messages differ from the SDK	Not changed	Verified against the locked @google/genai Node source: it emits the same full partOrString must be a Part object, string, or array and element in PartUnion must be a Part object or string messages.
Sticky rejected loader promise	Not changed	Intentional for deterministic provider construction/import failures; refreshAuth() remains the documented retry boundary.
Additional Vertex/passthrough/recovery tests	Deferred	Existing provider parity, single-flight, failure-timing, and broad downstream tests cover the changed behavior; the suggested additions are non-blocking follow-up coverage.

Verification on the pushed commit: genai-compat.test.ts 7/7, affected ESLint, Prettier, and a clean worktree.

[doudouOUC]

Code Review — perf(startup): lazy-load Google GenAI SDK on first use

Reviewed the full diff against 2f725c863, cross-checked genai-compat.ts against the actual @google/genai@2.6.0 source pulled from npm, and traced every downstream consumer of the rerouted imports. Two thorough reviews are already on this PR, so the notes below are limited to what they did not cover, plus one correction.

Verdict: no blocking correctness defect. The content-conversion parity is exact, the single-flight ??= is atomic w.r.t. the event loop, the eager Qwen OAuth check is preserved, and the guard's inputMatchesPackage prefix match won't false-positive on google-auth-library. Only item 5 below is something I'd action before merge; item 1 is a two-line change I'd fold in while here.

1. BaseLlmClient's per-model fallback path is silently bypassed (Suggestion, worth fixing)

packages/core/src/core/baseLlmClient.ts:741-748 depends on createContentGenerator() throwing:

} catch (err: unknown) {
  this.perModelGeneratorCache.delete(cacheKey);   // evict on construction failure
  throw normalizeGeneratorError(err);
}
...
return generatorPromise.catch(fallbackAfterGeneratorError);  // non-failClosed → fall back to main generator

After this change it no longer throws for two error classes: dynamic-import failure (ERR_MODULE_NOT_FOUND, i.e. a background update swapped the chunks) and provider-constructor failure (e.g. GoogleGenAI throwing Project/location and API key are mutually exclusive when GOOGLE_CLOUD_PROJECT is set alongside a Vertex API key).

Two consequences: (a) fallbackAfterGeneratorError becomes dead code for those errors — a routed side request (summarize, memory, title generation) that used to degrade to the main generator with a warning now hard-fails; (b) the failed lazy generator stays in perModelGeneratorCache, because the eviction only wraps createContentGenerator, and LazyContentGenerator.generatorPromise ??= never clears on rejection — so every subsequent routed call for that model rethrows the same stale rejection until refreshAuth().

validateModelConfig still runs eagerly and catches the common "env var not set" case, so severity is moderate rather than high. But clearing generatorPromise on rejection inside getGenerator() is a two-line fix that removes both the sticky failure and the cache poisoning at once. Both prior reviews flagged the sticky rejection as optional; combined with perModelGeneratorCache I think it's worth doing now.

2. The bundle-guard comment overclaims — the Google auth graph is still in the static closure (Suggestion)

scripts/check-serve-fast-path-bundle.js:216-218 says "Keep its SDK and Google auth graph out of the ACP bootstrap closure". At this same commit:

packages/core/src/tools/mcp-client.ts:31  import { GoogleCredentialProvider } from '../mcp/google-auth-provider.js';
packages/core/src/tools/mcp-client.ts:32  import { ServiceAccountImpersonationProvider } from '../mcp/sa-impersonation-provider.js';

Both modules statically import google-auth-library (packages/core/src/mcp/google-auth-provider.ts:14, sa-impersonation-provider.ts:13), and mcp-client.ts is itself inside the ACP static closure — otherwise this PR wouldn't have needed to make mcpToTool dynamic. So google-auth-library and its dependency graph remain in the bootstrap closure, and the guard won't catch it since only @google/genai is listed.

Suggest narrowing the comment to what the guard actually enforces. Separately, this looks like a cheap follow-up: ServiceAccountImpersonationProvider and GoogleCredentialProvider are only instantiated inside function bodies (mcp-client.ts:1994 and :2023) — exactly the mcpToTool shape — so an await import() plus a new FORBIDDEN_ACP_PACKAGES entry would trim the closure further. Not for this PR, but worth recording on #7264.

3. The ERR_MODULE_NOT_FOUND path lost its real coverage (Suggestion)

The mock semantics changed in packages/core/src/core/contentGenerator.test.ts: the module factory used to throw (simulating a genuine dynamic-import failure), and now the throw happens inside createOpenAIContentGenerator, i.e. a constructor failure. The import itself now always succeeds, so should handle ERR_MODULE_NOT_FOUND exercises "a constructor threw an error carrying an ERR_MODULE_NOT_FOUND code" — something that doesn't occur in production. The assertions still pass only because wrapProviderLoadError treats both identically.

That matters here because the "background update removed the chunk" case is the sole reason the restart message exists, and it's precisely the path this PR moves from session creation to first prompt — so the most-changed behavior is now the least-covered one. A vi.doMock + vi.resetModules() case that makes the module factory itself throw would restore it (that describe block already calls vi.resetModules()).

4. Correction to an earlier note — please don't act on it

An earlier review reports that the compat error messages diverge from the SDK ("the SDK throws partOrString must be a Part object"). I checked the pinned @google/genai@2.6.0 (packages/core/package.json:40) source directly:

throw new Error('partOrString must be a Part object, string, or array');
throw new Error('element in PartUnion must be a Part object or string');

These are byte-identical to genai-compat.ts. Changing them would introduce the divergence the note is trying to prevent.

5. License header — attribution rather than a straight swap (the one item I'd action before merge)

The content-conversion logic in genai-compat.ts is adapted from the Apache-2.0 @google/genai, not original code, so replacing the header with Copyright 2026 Qwen Team isn't obviously more correct. Keeping the Google copyright and adding an upstream-attribution comment reads better and also answers the "partial enum is under-commented" note from the other review:

// Adapted from @google/genai 2.6.0 (`_isPart` / `_toParts`, Apache-2.0) so core
// orchestration can use these helpers without evaluating the SDK. `FinishReason` and
// `FunctionCallingConfigMode` expose only the members non-provider core code uses;
// provider converters still import the real SDK enums. Parity is locked by
// genai-compat.test.ts — re-check on every SDK upgrade.

6. Minor observations

• FinishReason members lose their literal types — FinishReason.STOP is now typed as the whole enum rather than the STOP literal, so a switch (reason) { case FinishReason.STOP: } would no longer narrow. All rerouted sites do plain === comparisons (turn.ts:560, geminiChat.ts:2760/2823/3953, agent-core.ts:908), so there's no impact today.
• refreshAuth() now reports success — and fires the auth_success notification hook (config.ts:3354-3368) — for configurations whose provider construction is guaranteed to fail (the Vertex project + API key conflict above). The Risk section covers deferred failures generically but not this effect on the auth-success signal.
• The import { type X } → import type { X } changes in confirmation-bus/types.ts and geminiRequest.ts are pure style: esbuild elides both forms in TS, so they don't contribute to the closure reduction. Zero risk, just not load-bearing.
• docs/design/2026-07-22-lazy-google-genai-loading.md:104 cites absolute paths on the benchmark host (/root/qwen-7264-c3-20260722/results/...) that no reviewer can reach and that will rot. Either inline the summary numbers or drop the reference.

Also worth waiting on CI: Test (ubuntu-latest, Node 22.x) is still pending and the macOS/Windows jobs are showing as skipping.

中文说明

在提交 2f725c863 上完整审阅了 diff，并把 genai-compat.ts 与从 npm 下载的 @google/genai@2.6.0 实际源码逐条比对，同时追踪了所有改道导入的下游消费点。本 PR 已有两份详细 review，下面只写它们未覆盖的内容，外加一处更正。

结论：无阻塞性正确性缺陷。 内容转换与 SDK 完全等价，单飞 ??= 在事件循环内是原子的，Qwen OAuth 急切校验得以保留，guard 的 inputMatchesPackage 前缀匹配不会误伤 google-auth-library。下面只有第 5 条是我认为合并前需要处理的；第 1 条是两行改动，建议顺手做掉。

1. BaseLlmClient 的 per-model 降级路径被静默绕过（建议处理）：baseLlmClient.ts:741-748 依赖 createContentGenerator() 抛错。改动后它对两类错误不再抛出——动态 import 失败（ERR_MODULE_NOT_FOUND，即后台升级替换了 chunk）和 provider 构造器抛错（例如同时设置 GOOGLE_CLOUD_PROJECT 与 Vertex apiKey 时 GoogleGenAI 抛 mutually exclusive）。后果有两层：fallbackAfterGeneratorError 对这两类错误成为死代码，原本会带 warning 回落主 generator 的 side request 现在直接硬失败；失败的 lazy generator 还会留在 perModelGeneratorCache 里（驱逐逻辑只包住 createContentGenerator），叠加 generatorPromise ??= 从不在 rejection 后复位，该 model 的每次后续路由请求都会重抛同一个陈旧 rejection，直到 refreshAuth()。validateModelConfig 仍急切校验，最常见的"环境变量没配"仍被拦住，所以严重度中等。但在 getGenerator() 中 rejection 时清掉 generatorPromise 是两行修复，能同时消除 sticky 失败和缓存污染。

2. bundle guard 注释过度宣称，Google auth graph 仍在静态闭包内（建议）：check-serve-fast-path-bundle.js:216-218 的注释写着要把 SDK "and Google auth graph" 挡在 ACP bootstrap 闭包外，但同一提交上 mcp-client.ts:31-32 静态导入了 GoogleCredentialProvider / ServiceAccountImpersonationProvider，二者又静态导入 google-auth-library，而 mcp-client.ts 本身就在 ACP 静态闭包内（否则本 PR 无需把 mcpToTool 改成动态）。建议把注释收敛到 guard 实际保证的范围。另外这是个顺手的后续优化：那两个 provider 只在 mcp-client.ts:1994 与 :2023 的函数体内实例化，与 mcpToTool 形态完全一致，改成 await import() 后把 google-auth-library 加进 FORBIDDEN_ACP_PACKAGES 即可继续瘦身。不必在本 PR 做，建议记进 #7264。

3. ERR_MODULE_NOT_FOUND 的真实路径失去覆盖（建议）：contentGenerator.test.ts 的 mock 语义变了——原先是 module factory 抛错（模拟真正的动态 import 失败），现在改成在 createOpenAIContentGenerator 内抛错，即构造器失败。import 本身永远成功，因此该用例实际测的是"构造器抛出一个带 ERR_MODULE_NOT_FOUND code 的错误"，现实中不会发生；断言仍通过只是因为 wrapProviderLoadError 对两条路径处理相同。而"后台升级导致 chunk 消失"正是这个 restart 提示存在的唯一理由，也恰恰是本 PR 从 session 创建推迟到首次 prompt 的那条路径——改动最大的路径反而覆盖最弱。用 vi.doMock + vi.resetModules() 让模块工厂真正抛错即可恢复（该 describe 已有 vi.resetModules()）。

4. 对既有 review 的一处更正——请勿据此修改：有 review 指出 compat 的错误消息与 SDK 不一致。核对仓库锁定的 @google/genai@2.6.0（packages/core/package.json:40）实际源码，其抛出的正是 partOrString must be a Part object, string, or array 与 element in PartUnion must be a Part object or string，与 genai-compat.ts 逐字相同。按该意见修改反而会引入它想避免的不一致。

5. License header——补归属而非直接替换（合并前唯一需处理项）：genai-compat.ts 的内容转换逻辑改写自 Apache-2.0 的 @google/genai，并非原创，因此直接换成 Copyright 2026 Qwen Team 未必更正确。保留 Google 版权声明并加一段上游归属注释更合适，同时也回应了另一份 review 提到的"partial enum 缺注释"。

6. 其他小点：FinishReason 成员丢失了字面量类型（switch 不再收窄，当前所有改道点都是 === 比较，无影响）；refreshAuth() 现在对必然构造失败的配置也报告成功并触发 auth_success hook（config.ts:3354-3368）；confirmation-bus/types.ts 与 geminiRequest.ts 的 import { type X } → import type { X } 是纯风格改动，esbuild 对两种写法都会消除，不构成闭包缩减的一部分；设计文档 :104 引用的基准机绝对路径（/root/qwen-7264-c3-20260722/...）reviewer 无法访问且会失效，建议内联数据或删除。

另外 Test (ubuntu-latest, Node 22.x) 仍在 pending，macOS/Windows 显示为 skipping，建议等 CI 出结果。

[qwen-code-ci-bot]

Reviewed. Suggestions are inline.

— qwen3.7-max via Qwen Code /review

[doudouOUC]

Review follow-up for b67c647705:

Review item	Decision	Action
Lazy loader rejection caching / per-model fallback	Not taking	The sticky rejection is the intentional retry boundary for immutable chunk/config failures. Clearing only the lazy promise would not restore BaseLlmClient fallback semantics and would repeatedly rerun non-recoverable construction; auth refresh or restart rebuilds the generator.
Bundle guard wording	Fixed	Narrowed the comment to the boundary the guard actually enforces: @google/genai, not the separate Google auth graph.
Real ERR_MODULE_NOT_FOUND coverage	Fixed	The test now uses a fresh module graph plus vi.doMock() whose module factory throws, so it exercises an actual dynamic-import failure.
Upstream attribution	Fixed	Kept the maintainer-requested Qwen file header and added the Google/Apache-2.0 attribution beside the adapted conversion helpers.
Google auth lazy loading	Deferred	Useful follow-up for #7264, but separate from candidate 3 and not needed for this PR boundary.
Inaccessible benchmark-host paths	Fixed	Removed the private absolute paths; the full benchmark results remain inline in the design document.
Enum literal typing and auth-success timing observations	Deferred	No current downstream narrowing defect; deferred provider construction is the documented behavior and changing auth signaling would widen scope.

Validation: 19 targeted core tests passed, 27 bundle-boundary tests passed, and affected ESLint/Prettier checks passed. The bundle test had one local 5-second subprocess timeout while run concurrently, then passed 27/27 when rerun sequentially.

[wenshao]

Local build & real-test verification — perf(startup): lazy-load Google GenAI SDK on first use

Verified as a maintainer against the current head b67c64770. The load-bearing claims — @google/genai leaves the ACP cold-start static closure, the ~999 KB reduction, deferred provider construction, and unchanged behavior — all reproduce exactly on a real build.

Setup (clean A/B, no shortcuts). Two isolated worktrees, each with a full npm ci (no node_modules symlink — mandatory here since the change lives in packages/core, which the bundle resolves through the workspace link):

• HEAD = PR head b67c64770
• BASE = merge-base 271497417 (HEAD is exactly BASE + the PR's 3 commits, so this isolates the PR)

Both bundled with the exact reviewer command (clean-package-build-artifacts && build --cli-only && DEV=true bundle). Anti-false-bundle check confirmed each metafile contains its own code: HEAD carries genai-compat.ts / LazyContentGenerator, BASE carries neither.

---

1. @google/genai removed from the ACP static closure — matches the claim to the byte

Running the PR's own findAcpImportBoundaryOffenders as the oracle against both metafiles:

metric (bytes)	BASE	HEAD	Δ
ACP static closure total	14,289,021	13,289,701	−999,320
@google/genai in closure	755,788	0	−755,788

• Guard fails-closed on BASE (ok=false, offender Google GenAI SDK, static path acpAgent-2WDIV2Z3.js → chunk-TYQMGACW.js (1,196,331 bytes)) and passes on HEAD (Startup bundle closure checks passed., exit 0).
• The SDK is still shipped in HEAD — now in a dynamic chunk (chunk-22C7BQ6D.js, inStaticClosure=false), so provider/MCP first-use still works.
• My −999,320 and 755,788 → 0 are identical to the PR's stated deltas. Absolute totals sit ~9.5 KB above the PR's figures only because my BASE is the merge-base (4 commits behind the PR's stated control) — the delta is identical.

---

2. Behavior unchanged & loading genuinely deferred — on real built code

• genai-compat ≡ @google/genai 2.6.0 — 61/61 equivalence checks. A side-by-side harness against the real installed SDK: enum values (FinishReason, FunctionCallingConfigMode), 19 inputs × createUserContent/createModelContent deep-equal, role correctness, and 9 error inputs where both throw with byte-identical messages. (Broader than the 3-case shipped test.)
• 844 unit/regression tests pass across every touched module — geminiChat (239), client (281), mcp-client (103), chatRecordingService (48), baseLlmClient (54), turn (35), agent-core (26), geminiRequest (12), plus genai-compat (7), contentGenerator (12) and the bundle guard (27). The contentGenerator suite pins the deferral: Gemini generator not built until first op, single-flight across concurrent first calls, Qwen OAuth creds checked before deferral, missing creds reject at session-create, and module-not-found → restart message + cause.
• Runtime deferral, proven on the shipped dist via an ESM load hook: importing each of the 6 changed core modules evaluates @google/genai 0× on HEAD vs 1× on BASE; genai-compat.js itself pulls the SDK 0×. This is the exact mechanism behind the closure reduction, observed at runtime.

---

Scope / not covered (honesty)

• I did not reproduce the cold-start latency / peak-RSS numbers — those need the 2-vCPU reference host and are hardware-sensitive. My verification targets the structural + behavioral claims, which are the load-bearing ones for correctness and for the stated bundle win.
• Live Gemini / Vertex / Anthropic network calls weren't exercised (no creds) — same limitation the PR states; those paths are covered by unit tests. The documented first-use trade-offs (aborted-first-request module eval, MCP background discovery loading the SDK) are intentional and called out in the design doc.
• Environment: macOS (Darwin 24.6), Node 22.23.1.

Verdict

From a correctness and bundle-boundary standpoint this is solid and merge-ready: the @google/genai removal, the guard's fail-closed behavior, SDK-parity of the compat shim, deferral, and no-regression across the touched surface all check out on a real build. 👍

中文说明

本地构建 + 真实测试验证 — perf(startup): lazy-load Google GenAI SDK on first use

作为维护者针对当前 head b67c64770 进行了验证。核心（load-bearing）结论 —— @google/genai 移出 ACP 冷启动静态闭包、约 999 KB 的减少、provider 延迟构造、行为不变 —— 在真实构建中全部精确复现。

环境搭建（干净 A/B，无捷径）。 两个隔离 worktree，各自完整 npm ci（不 symlink node_modules —— 因为改动位于 packages/core，bundle 通过 workspace 链接解析它，symlink 会让 esbuild 误取主仓的 core，导致假 A/B）：

• HEAD = PR head b67c64770
• BASE = merge-base 271497417（HEAD 恰好 = BASE + PR 的 3 个提交，因此精确隔离本 PR）

两者均用 reviewer 原始命令构建（clean-package-build-artifacts && build --cli-only && DEV=true bundle）。防「假 bundle」检查确认各 metafile 含自身代码：HEAD 含 genai-compat.ts / LazyContentGenerator，BASE 都没有。

1. @google/genai 移出 ACP 静态闭包 —— 与声明逐字节吻合

以 PR 自带的 findAcpImportBoundaryOffenders 作为 oracle，对两个 metafile 运行：

指标（bytes）	BASE	HEAD	Δ
ACP 静态闭包总量	14,289,021	13,289,701	−999,320
闭包中的 @google/genai	755,788	0	−755,788

• 守卫在 BASE 上失败（fail-closed）（ok=false，offender Google GenAI SDK，静态路径 acpAgent-2WDIV2Z3.js → chunk-TYQMGACW.js (1,196,331 bytes)），在 HEAD 上通过（Startup bundle closure checks passed.，exit 0）。
• SDK 在 HEAD 中仍然打包，只是进入了动态 chunk（chunk-22C7BQ6D.js，inStaticClosure=false），provider/MCP 首次使用仍可用。
• 我测得的 −999,320 与 755,788 → 0 与 PR 声明的 delta 完全一致。绝对总量比 PR 高约 9.5 KB，仅因我的 BASE 是 merge-base（比 PR 声明的 control 落后 4 个提交）—— delta 相同。

2. 行为不变 & 加载确实延迟 —— 基于真实构建产物

• genai-compat ≡ @google/genai 2.6.0 —— 61/61 等价性检查。 与真实安装的 SDK 逐一对照：枚举值（FinishReason、FunctionCallingConfigMode）、19 组输入 × createUserContent/createModelContent 深度相等、role 正确性、以及 9 组错误输入两者均抛出且报错信息逐字节一致（比 PR 自带的 3 组用例更广）。
• 844 项单测/回归测试全部通过，覆盖全部被改模块 —— geminiChat(239)、client(281)、mcp-client(103)、chatRecordingService(48)、baseLlmClient(54)、turn(35)、agent-core(26)、geminiRequest(12)，外加 genai-compat(7)、contentGenerator(12) 与 bundle 守卫(27)。contentGenerator 用例锁定延迟语义：首次操作前不构造 Gemini generator、并发首调用单飞、Qwen OAuth 凭证在延迟之前校验、缺失凭证在 session 创建时拒绝、module-not-found → 重启提示 + cause。
• 运行时延迟在打包 dist 上验证（ESM load hook）： 导入 6 个被改 core 模块，各自对 @google/genai 的求值次数 HEAD 为 0，BASE 为 1；genai-compat.js 自身求值 SDK 0 次。这正是闭包缩减的机制，运行时可观测。

范围 / 未覆盖（如实说明）

• 未复现冷启动延迟 / 峰值 RSS 数字 —— 需 2-vCPU 参考机且对硬件敏感；本次验证聚焦结构性 + 行为性结论，这些才是正确性与 bundle 收益的关键。
• 未做真实 Gemini / Vertex / Anthropic 网络调用（无凭证）—— 与 PR 声明一致，相关路径由单测覆盖。设计文档中列出的首次使用权衡（已中止的首请求仍会完成模块求值、MCP 后台 discovery 会加载 SDK）为有意为之。
• 环境：macOS（Darwin 24.6），Node 22.23.1。

结论

从正确性与 bundle 边界角度看，本 PR 扎实、可合并：@google/genai 移除、守卫 fail-closed 行为、compat shim 的 SDK 等价性、延迟加载、以及被改面无回归，均在真实构建中验证通过。👍

[wenshao]

@qwen-code /triage

[qwen-code-ci-bot]

LGTM, looks ready to ship. ✅