尧图网站建设 
qwen-code 冷启动优化将 OpenTelemetry SDK 从 ACP 子进程启动路径上延迟加载【免费下载链接】qwen-codeAn open-source AI coding agent that lives in your terminal.项目地址: https://gitcode.com/GitHub_Trending/qw/qwen-code导读本文剖析 qwen-code 为优化 daemon 冷启动首会话延迟而实施的一项关键改造把重达约 2.16 MiB 的 OpenTelemetry SDK 静态依赖簇从 ACPAgent Client Protocol子进程的启动关键路径上彻底移出改为仅在遥测功能真正启用时通过动态import()按需加载。改造的核心是把packages/core/src/telemetry/sdk.ts拆分为轻量状态门面与重型 SDK 组装两个模块并配套引入打包守卫脚本防止回归。读完本文你将掌握这套门面 动态导入 打包黑名单的冷启动优化方法论理解其三个生产调用点的异步化处理与排序风险控制并了解对应的验收测量门槛。一、问题背景ACP 子进程启动路径上的遥测模块税qwen-code 的 daemon 在冷启动首个会话时channel.initialize是最大的耗时项2C4G 环境下 P50 约 1035ms其中约67%来自 ACP 子进程的模块加载。对 #7182 之后的 bundle 进行 esbuild metafile 审计commitde962a5ecfDEVtrue发现ACP 子进程的 eager 静态闭包高达17.24 MiB / 2420 个模块而 OpenTelemetry 相关依赖是其中最大的单一相干块依赖组体积tree-shake 后grpc/grpc-js577 KiBopentelemetry/otlp-transformer479 KiBprotobufjslonggrpc/proto-loader305 KiBopentelemetry/sdk-metrics/sdk-node/sdk-trace-*/sdk-logs~260 KiBopentelemetry/instrumentation-*instrumentation~132 KiB其余opentelemetry/*exporters、propagators、resources 等~250 KiB遥测依赖簇合计2.16 MiB这 2.16 MiB 的代码在每一次 ACP 子进程启动时都会被完整求值但存在两个明显问题遥测默认是关闭的——最常见的场景下用户要为一段initializeTelemetry()根本不会执行的代码支付全额模块加载开销!config.getTelemetryEnabled()早退发生在 sdk.ts 的初始化函数入口。即使开启遥测在首个 span/log/metric 产生之前也不需要 SDK而首个信号必然出现在initialize被 ACK 之后。作为校准参考#7182TUI 模块移除删掉了 1.16 MiB把 ACP 导入耗时从 115ms 砍到 52ms-63ms。本次的遥测簇几乎是其 2 倍大小因此量级相当的效果是合理的——最终是否合入由 issue #4748 的测量门槛决定。二、为什么导入链是 eager 的门面与重型组装必须分离改造前sdk.ts 在顶层静态导入了所有内容六个 OTLP exportergRPC HTTP × traces/logs/metrics、NodeSDK、批处理器、PeriodicExportingMetricReader以及两个 instrumentation。而sdk.ts本身又被 core 的 barreltelemetry/index.ts静态引用无法整体惰性化因为有两个热路径模块静态依赖它的廉价状态读取器loggers.ts 中的每条日志都调用isTelemetrySdkInitialized()做门控session-tracing.ts 中的每个 span 辅助函数同样依赖它。因此拆分必须把廉价状态门面与重型 SDK 组装分开而不仅仅是把六个 exporter 的 import 包进await import()——NodeSDK、instrumentation、sdk-metrics 等约 0.7 MiB 的依赖同样可以移除且它们就在同一个文件里。三、设计方案sdk.ts 门面化 sdk-impl.ts 重装化3.1 文件拆分sdk.ts保留变为门面——不再有重型导入。保持其他模块静态可达的一切内容名称与语义不变模块状态sdk、telemetryInitialized、telemetryShutdownPromise、activeMetricReader用import type标注类型不产生运行时加载isTelemetrySdkInitialized()、refreshSessionContext()、shutdownTelemetry()、forceFlushMetrics()resolveHttpOtlpUrl()导出、纯函数、无重型依赖diag.setLogger(...)副作用只需opentelemetry/api该包已普遍存在且廉价——56 KiBloggers.ts/metrics.ts也在用。门面对opentelemetry/*的唯一运行时导入是opentelemetry/api。从当前源码看门面还额外保留了startSdkWithExplicitExporters()启动前临时清理OTEL_TRACES_EXPORTER/OTEL_LOGS_EXPORTER/OTEL_METRICS_EXPORTER三个环境变量防止 sdk-node 的自动配置构造第二个 exporter以及带 10 秒超时的shutdownTelemetry()、带 2 秒超时的forceFlushMetrics()等基础设施。sdk-impl.ts新增重型半边。原样承接六个 OTLP exporter 导入、NodeSDK、BatchSpanProcessor、BatchLogRecordProcessor、PeriodicExportingMetricReader、两个 instrumentation、CompressionAlgorithm、resourceFromAttributes、SessionIdSpanProcessor、parseOtlpEndpoint、validateUrl、normalizeOtlpPrefix 前缀匹配、propagator 门控以及今日initializeTelemetry()从 resource 构建往后的全部主体。它只导出一个函数export function startTelemetrySdk(config: TelemetryRuntimeConfig): | { sdk: NodeSDK; metricReader: PeriodicExportingMetricReader | undefined; } | undefined;在gRPC 但没有 base endpoint的既有跳过路径上返回undefined。file-exporters.ts 和 log-to-span-processor.ts 也一并移到sdk-impl.ts之后它们目前只被sdk.ts导入且会拉入sdk-logs/sdk-metrics/sdk-trace-base。当前实现还在此基础上叠加了 issue #7264 的协议级拆分sdk-impl.ts内部不再静态导入六个 exporter而是按配置的 OTLP 协议动态加载 sdk-exporters-http.ts拉入 otlp-transformer或 sdk-exporters-grpc.ts拉入 grpc/grpc-js protobufjsoutfile 配置则两条链都不加载——详见 sdk-impl.ts 头部注释。3.2initializeTelemetry变为异步门面中的新实现let telemetryInitPromise: Promisevoid | undefined; export function initializeTelemetry( config: TelemetryRuntimeConfig, ): Promisevoid { if (telemetryInitialized || !config.getTelemetryEnabled()) { return Promise.resolve(); } telemetryInitPromise ?? (async () { const { startTelemetrySdk } await import(./sdk-impl.js); const started startTelemetrySdk(config); if (!started) return; sdk started.sdk; // sdk.start() telemetryInitialized true setSessionContext // setShellTracePropagation initializeMetrics —— 与今日相同的顺序 // 相同的仅记录日志的 try/catch。 })().finally(() { telemetryInitPromise undefined; }); return telemetryInitPromise; }关键性质关闭路径保持同步且零成本——getTelemetryEnabled()检查发生在动态导入之前默认配置的用户根本不会加载那 2.16 MiB。这才是 ACP 子进程真正的收益点单飞守卫telemetryInitPromise保证并发调用下的幂等性等价于今日的telemetryInitialized复查finally中清空 promise使失败的动态导入可被重试而成功初始化则继续通过telemetryInitialized早退shutdownTelemetry()无需改动它操作门面的sdk变量且在!telemetryInitialized时本就 no-op。当前实现还额外处理了初始化仍 in-flight的情况shutdownTelemetry()会先await挂起的初始化 promise 再执行关闭与 flush避免与同步布尔标志竞态导致 SDK 泄漏见 sdk.ts。实际实现中动态导入与startTelemetrySdk调用都被放在 try 内使 chunk 加载失败降级为遥测不可用而非抛错——因为 daemon 运行时对该调用是await且不带 catch 的见下文调用点 3。3.3 三个生产调用点的处理调用点 1packages/core/src/config/config.ts 的 Config 构造函数同步上下文。这是 ACP 子进程走的路径ACP 模式下deferTelemetryInitialization为 false参见 packages/cli/src/config/config.ts。采用 fire-and-forget 记录日志的 catchvoid Promise.resolve(initializeTelemetry(this)).catch((error) { this.debugLogger.error(Failed to initialize telemetry:, error); });风险分析迟启动的唯一后果是间隙期产生的 span/log 被isTelemetrySdkInitialized()门控丢弃——而这本来就是整个构造函数之前窗口期以及交互式 TUI 路径的既有行为TUI 下遥测初始化被推迟到后台任务见 startup-prefetch.ts。因此没有引入新的失败模式。需要注意的行为变化有意为之并有文档记录在非延迟路径上——ACP 子进程与 headless-p运行deferTelemetryInitialization为 false——遥测此前在同步initializeTelemetry调用返回时已完全注册现在改为异步收敛既有丢弃窗口会因动态导入开销约 50–150ms而略微变宽。这里故意不await一旦 await那 2.16 MiB 的导入就会重新回到 ACP 子进程的关键路径上抵消全部收益。需要保证遥测就绪后才能继续的调用方daemon 运行时即调用点 3会显式await。调用点 2packages/cli/src/startup/startup-prefetch.ts 的延迟任务执行器。把任务闭包改为返回 promise() initializeTelemetry(config)让runDeferredTask既有的错误处理能观察到 rejection语义上其余不变。当前代码中对应runDeferredTask(telemetry_init, () initializeTelemetry(config))且仅在options.initializeTelemetry为 true 时注册startup-prefetch.ts。调用点 3packages/cli/src/serve/run-qwen-serve.tsdaemon 运行时。必须await。紧邻的下一行就调用initializeDaemonMetrics()而 OTel 的metrics.getMeter()如果在 SDK 注册全局 MeterProvider 之前被调用会永久缓存一个 noop meter——daemon 指标将静默失效。外层函数已是 async所以await core.initializeTelemetry(...)只是一词之改。当前代码中的注释也明确记录了这一点run-qwen-serve.ts。这会把模块加载成本转移到 daemon 运行时加载延迟执行、不在快速路径上且仅在遥测开启时发生——可接受且严格优于在每个 ACP 子进程里都支付。initializeMetrics()metrics.ts在原理上存在同样的排序风险但它在 init promise 内部、sdk.start()之后被调用因此顺序由构造天然保证。3.4 打包守卫扩展扩展 scripts/check-serve-fast-path-bundle.js 中 ACP 边界检查findAcpImportBoundaryOffenders的遥测黑名单防止拆分静默回退grpc/grpc-js, grpc/proto-loader, protobufjs, opentelemetry/otlp-transformer, opentelemetry/sdk-node, opentelemetry/exporter-trace-otlp-grpc, opentelemetry/exporter-logs-otlp-grpc, opentelemetry/exporter-metrics-otlp-grpc, opentelemetry/instrumentation-http, opentelemetry/instrumentation-undiciopentelemetry/api、semantic-conventions、core、resources、api-logs不在黑名单内——它们从loggers.ts、metrics.ts以及类型级导出被合法可达。当前仓库中该守卫已经落地为两层结构check-serve-fast-path-bundle.jsFORBIDDEN_OTLP_PROTOCOL_PACKAGES额外禁止opentelemetry/otlp-exporter-base与全部六个 HTTP/gRPC exporter 包从sdk-impl静态闭包可达FORBIDDEN_ACP_TELEMETRY_PACKAGES在其上叠加sdk-node与两个 instrumentation共同约束 ACP 边界闭包。四、本改造不改变什么遥测开启时行为不变——同样的 exporters、同样的 processors、同样的 instrumentation 钩子、同样的 shutdown/flush 语义不删除任何公共 API——initializeTelemetry的返回类型从void变为Promisevoid对既有 fire-and-forget 调用方是源码兼容的所有调用点在同一 commit 中更新这是 core 包改动按 AGENTS.md 由维护者编写telemetry/index.ts barrel 导出的名称保持不变。从当前 sdk.test.ts 可以印证测试直接await initializeTelemetry(...)并通过vi.mock屏蔽六个 exporter、sdk-node、两个 instrumentation 等重型依赖断言 exporter 构造的用例面向sdk-impl.ts一侧展开。五、验收issue #4748 的测量门槛字节数不能直接换算成毫秒改动必须通过 issue 既有的纪律才能合入2C4G、30 次串行冷启动遥测关闭默认配置对比channel.initialize的 P50/P95 与 process→first-Session P50 相对de962a5ecf基线的表现。仅当 P50 改善超过运行间噪声时才合入。遥测开启的功能回归OTLP gRPC 与 HTTP 目标在改动后均能收到 traces/logs/metrics既有 sdk.test.ts 矩阵 对本地 collector 的一次手动端到端--telemetry-outfile文件导出器仍正常写入。Daemon 指标遥测开启时daemon Status 指标环与initializeDaemonMetrics()的 gauges 仍正常上报守卫调用点 3 的 await。打包守卫node scripts/check-serve-fast-path-bundle.js在黑名单扩展后保持绿色重跑闭包审计.qwen/scripts/acp-closure-audit.mjs并记录新的 ACP 闭包总量预期 ≈ 17.24 − ~2.0 MiB再减去opentelemetry/api等保留 eager 的部分。单元测试sdk.test.ts 中await initializeTelemetry15 个调用点断言 exporter 构造的测试迁移到sdk-impl.ts或对其 mock。六、备选方案与取舍设计文档记录了三类被否决的备选方案理解它们有助于把握拆分边界的必然性只惰性导入六个 exporter 类、保留同步initializeTelemetry。否决会无谓地留下约 0.7 MiBNodeSDK、instrumentations、sdk-metrics、批处理器处于 eager 状态且开启路径仍要构造 exporter异步边界迟早要引入函数无论如何都会变异步。把整个telemetry/sdk.ts模块动态化。否决loggers.ts与session-tracing.ts对每次遥测调用都用isTelemetrySdkInitialized()门控把该门控变异步会污染数十个热点同步调用点。在 ACP 子进程中完全跳过遥测。在 issue 中已被否决一刀切跳过会改变开启遥测用户的可观测行为。七、总结一条可复用的冷启动优化路径本次改造给出了一个可复用的优化模式识别启动关键路径上的静态依赖簇 → 用廉价门面 重型实现的文件拆分把状态读取与重型组装解耦 → 门面通过单飞动态导入按需加载重型实现 → 用打包守卫把依赖包列入黑名单防止回归 → 用测量门槛量化收益。对于默认关闭的可选能力遥测、诊断、SDK 接入层等这套方法能显著压缩冷启动体积与模块求值时间若要落地到自己的项目中还可以进一步参考 qwen-code 后续的协议级拆分按 gRPC/HTTP/outfile 分链动态加载把按需细化到配置维度。相关文件索引设计文档docs/design/2026-07-19-lazy-telemetry-sdk-loading.md门面模块packages/core/src/telemetry/sdk.ts重型实现packages/core/src/telemetry/sdk-impl.ts协议级导出器sdk-exporters-http.ts / sdk-exporters-grpc.tsbarrel 导出packages/core/src/telemetry/index.ts打包守卫scripts/check-serve-fast-path-bundle.js单元测试packages/core/src/telemetry/sdk.test.ts【免费下载链接】qwen-codeAn open-source AI coding agent that lives in your terminal.项目地址: https://gitcode.com/GitHub_Trending/qw/qwen-code创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 qwen-code 冷启动优化：将 OpenTelemetry SDK 从 ACP 子进程启动路径上延迟加载
qwen-code 冷启动优化将 OpenTelemetry SDK 从 ACP 子进程启动路径上延迟加载【免费下载链接】qwen-codeAn open-source AI coding agent that lives in your terminal.项目地址: https://gitcode.com/GitHub_Trending/qw/qwen-code导读本文剖析 qwen-code 为优化 daemon 冷启动首会话延迟而实施的一项关键改造把重达约 2.16 MiB 的 OpenTelemetry SDK 静态依赖簇从 ACPAgent Client Protocol子进程的启动关键路径上彻底移出改为仅在遥测功能真正启用时通过动态import()按需加载。改造的核心是把packages/core/src/telemetry/sdk.ts拆分为轻量状态门面与重型 SDK 组装两个模块并配套引入打包守卫脚本防止回归。读完本文你将掌握这套门面 动态导入 打包黑名单的冷启动优化方法论理解其三个生产调用点的异步化处理与排序风险控制并了解对应的验收测量门槛。一、问题背景ACP 子进程启动路径上的遥测模块税qwen-code 的 daemon 在冷启动首个会话时channel.initialize是最大的耗时项2C4G 环境下 P50 约 1035ms其中约67%来自 ACP 子进程的模块加载。对 #7182 之后的 bundle 进行 esbuild metafile 审计commitde962a5ecfDEVtrue发现ACP 子进程的 eager 静态闭包高达17.24 MiB / 2420 个模块而 OpenTelemetry 相关依赖是其中最大的单一相干块依赖组体积tree-shake 后grpc/grpc-js577 KiBopentelemetry/otlp-transformer479 KiBprotobufjslonggrpc/proto-loader305 KiBopentelemetry/sdk-metrics/sdk-node/sdk-trace-*/sdk-logs~260 KiBopentelemetry/instrumentation-*instrumentation~132 KiB其余opentelemetry/*exporters、propagators、resources 等~250 KiB遥测依赖簇合计2.16 MiB这 2.16 MiB 的代码在每一次 ACP 子进程启动时都会被完整求值但存在两个明显问题遥测默认是关闭的——最常见的场景下用户要为一段initializeTelemetry()根本不会执行的代码支付全额模块加载开销!config.getTelemetryEnabled()早退发生在 sdk.ts 的初始化函数入口。即使开启遥测在首个 span/log/metric 产生之前也不需要 SDK而首个信号必然出现在initialize被 ACK 之后。作为校准参考#7182TUI 模块移除删掉了 1.16 MiB把 ACP 导入耗时从 115ms 砍到 52ms-63ms。本次的遥测簇几乎是其 2 倍大小因此量级相当的效果是合理的——最终是否合入由 issue #4748 的测量门槛决定。二、为什么导入链是 eager 的门面与重型组装必须分离改造前sdk.ts 在顶层静态导入了所有内容六个 OTLP exportergRPC HTTP × traces/logs/metrics、NodeSDK、批处理器、PeriodicExportingMetricReader以及两个 instrumentation。而sdk.ts本身又被 core 的 barreltelemetry/index.ts静态引用无法整体惰性化因为有两个热路径模块静态依赖它的廉价状态读取器loggers.ts 中的每条日志都调用isTelemetrySdkInitialized()做门控session-tracing.ts 中的每个 span 辅助函数同样依赖它。因此拆分必须把廉价状态门面与重型 SDK 组装分开而不仅仅是把六个 exporter 的 import 包进await import()——NodeSDK、instrumentation、sdk-metrics 等约 0.7 MiB 的依赖同样可以移除且它们就在同一个文件里。三、设计方案sdk.ts 门面化 sdk-impl.ts 重装化3.1 文件拆分sdk.ts保留变为门面——不再有重型导入。保持其他模块静态可达的一切内容名称与语义不变模块状态sdk、telemetryInitialized、telemetryShutdownPromise、activeMetricReader用import type标注类型不产生运行时加载isTelemetrySdkInitialized()、refreshSessionContext()、shutdownTelemetry()、forceFlushMetrics()resolveHttpOtlpUrl()导出、纯函数、无重型依赖diag.setLogger(...)副作用只需opentelemetry/api该包已普遍存在且廉价——56 KiBloggers.ts/metrics.ts也在用。门面对opentelemetry/*的唯一运行时导入是opentelemetry/api。从当前源码看门面还额外保留了startSdkWithExplicitExporters()启动前临时清理OTEL_TRACES_EXPORTER/OTEL_LOGS_EXPORTER/OTEL_METRICS_EXPORTER三个环境变量防止 sdk-node 的自动配置构造第二个 exporter以及带 10 秒超时的shutdownTelemetry()、带 2 秒超时的forceFlushMetrics()等基础设施。sdk-impl.ts新增重型半边。原样承接六个 OTLP exporter 导入、NodeSDK、BatchSpanProcessor、BatchLogRecordProcessor、PeriodicExportingMetricReader、两个 instrumentation、CompressionAlgorithm、resourceFromAttributes、SessionIdSpanProcessor、parseOtlpEndpoint、validateUrl、normalizeOtlpPrefix 前缀匹配、propagator 门控以及今日initializeTelemetry()从 resource 构建往后的全部主体。它只导出一个函数export function startTelemetrySdk(config: TelemetryRuntimeConfig): | { sdk: NodeSDK; metricReader: PeriodicExportingMetricReader | undefined; } | undefined;在gRPC 但没有 base endpoint的既有跳过路径上返回undefined。file-exporters.ts 和 log-to-span-processor.ts 也一并移到sdk-impl.ts之后它们目前只被sdk.ts导入且会拉入sdk-logs/sdk-metrics/sdk-trace-base。当前实现还在此基础上叠加了 issue #7264 的协议级拆分sdk-impl.ts内部不再静态导入六个 exporter而是按配置的 OTLP 协议动态加载 sdk-exporters-http.ts拉入 otlp-transformer或 sdk-exporters-grpc.ts拉入 grpc/grpc-js protobufjsoutfile 配置则两条链都不加载——详见 sdk-impl.ts 头部注释。3.2initializeTelemetry变为异步门面中的新实现let telemetryInitPromise: Promisevoid | undefined; export function initializeTelemetry( config: TelemetryRuntimeConfig, ): Promisevoid { if (telemetryInitialized || !config.getTelemetryEnabled()) { return Promise.resolve(); } telemetryInitPromise ?? (async () { const { startTelemetrySdk } await import(./sdk-impl.js); const started startTelemetrySdk(config); if (!started) return; sdk started.sdk; // sdk.start() telemetryInitialized true setSessionContext // setShellTracePropagation initializeMetrics —— 与今日相同的顺序 // 相同的仅记录日志的 try/catch。 })().finally(() { telemetryInitPromise undefined; }); return telemetryInitPromise; }关键性质关闭路径保持同步且零成本——getTelemetryEnabled()检查发生在动态导入之前默认配置的用户根本不会加载那 2.16 MiB。这才是 ACP 子进程真正的收益点单飞守卫telemetryInitPromise保证并发调用下的幂等性等价于今日的telemetryInitialized复查finally中清空 promise使失败的动态导入可被重试而成功初始化则继续通过telemetryInitialized早退shutdownTelemetry()无需改动它操作门面的sdk变量且在!telemetryInitialized时本就 no-op。当前实现还额外处理了初始化仍 in-flight的情况shutdownTelemetry()会先await挂起的初始化 promise 再执行关闭与 flush避免与同步布尔标志竞态导致 SDK 泄漏见 sdk.ts。实际实现中动态导入与startTelemetrySdk调用都被放在 try 内使 chunk 加载失败降级为遥测不可用而非抛错——因为 daemon 运行时对该调用是await且不带 catch 的见下文调用点 3。3.3 三个生产调用点的处理调用点 1packages/core/src/config/config.ts 的 Config 构造函数同步上下文。这是 ACP 子进程走的路径ACP 模式下deferTelemetryInitialization为 false参见 packages/cli/src/config/config.ts。采用 fire-and-forget 记录日志的 catchvoid Promise.resolve(initializeTelemetry(this)).catch((error) { this.debugLogger.error(Failed to initialize telemetry:, error); });风险分析迟启动的唯一后果是间隙期产生的 span/log 被isTelemetrySdkInitialized()门控丢弃——而这本来就是整个构造函数之前窗口期以及交互式 TUI 路径的既有行为TUI 下遥测初始化被推迟到后台任务见 startup-prefetch.ts。因此没有引入新的失败模式。需要注意的行为变化有意为之并有文档记录在非延迟路径上——ACP 子进程与 headless-p运行deferTelemetryInitialization为 false——遥测此前在同步initializeTelemetry调用返回时已完全注册现在改为异步收敛既有丢弃窗口会因动态导入开销约 50–150ms而略微变宽。这里故意不await一旦 await那 2.16 MiB 的导入就会重新回到 ACP 子进程的关键路径上抵消全部收益。需要保证遥测就绪后才能继续的调用方daemon 运行时即调用点 3会显式await。调用点 2packages/cli/src/startup/startup-prefetch.ts 的延迟任务执行器。把任务闭包改为返回 promise() initializeTelemetry(config)让runDeferredTask既有的错误处理能观察到 rejection语义上其余不变。当前代码中对应runDeferredTask(telemetry_init, () initializeTelemetry(config))且仅在options.initializeTelemetry为 true 时注册startup-prefetch.ts。调用点 3packages/cli/src/serve/run-qwen-serve.tsdaemon 运行时。必须await。紧邻的下一行就调用initializeDaemonMetrics()而 OTel 的metrics.getMeter()如果在 SDK 注册全局 MeterProvider 之前被调用会永久缓存一个 noop meter——daemon 指标将静默失效。外层函数已是 async所以await core.initializeTelemetry(...)只是一词之改。当前代码中的注释也明确记录了这一点run-qwen-serve.ts。这会把模块加载成本转移到 daemon 运行时加载延迟执行、不在快速路径上且仅在遥测开启时发生——可接受且严格优于在每个 ACP 子进程里都支付。initializeMetrics()metrics.ts在原理上存在同样的排序风险但它在 init promise 内部、sdk.start()之后被调用因此顺序由构造天然保证。3.4 打包守卫扩展扩展 scripts/check-serve-fast-path-bundle.js 中 ACP 边界检查findAcpImportBoundaryOffenders的遥测黑名单防止拆分静默回退grpc/grpc-js, grpc/proto-loader, protobufjs, opentelemetry/otlp-transformer, opentelemetry/sdk-node, opentelemetry/exporter-trace-otlp-grpc, opentelemetry/exporter-logs-otlp-grpc, opentelemetry/exporter-metrics-otlp-grpc, opentelemetry/instrumentation-http, opentelemetry/instrumentation-undiciopentelemetry/api、semantic-conventions、core、resources、api-logs不在黑名单内——它们从loggers.ts、metrics.ts以及类型级导出被合法可达。当前仓库中该守卫已经落地为两层结构check-serve-fast-path-bundle.jsFORBIDDEN_OTLP_PROTOCOL_PACKAGES额外禁止opentelemetry/otlp-exporter-base与全部六个 HTTP/gRPC exporter 包从sdk-impl静态闭包可达FORBIDDEN_ACP_TELEMETRY_PACKAGES在其上叠加sdk-node与两个 instrumentation共同约束 ACP 边界闭包。四、本改造不改变什么遥测开启时行为不变——同样的 exporters、同样的 processors、同样的 instrumentation 钩子、同样的 shutdown/flush 语义不删除任何公共 API——initializeTelemetry的返回类型从void变为Promisevoid对既有 fire-and-forget 调用方是源码兼容的所有调用点在同一 commit 中更新这是 core 包改动按 AGENTS.md 由维护者编写telemetry/index.ts barrel 导出的名称保持不变。从当前 sdk.test.ts 可以印证测试直接await initializeTelemetry(...)并通过vi.mock屏蔽六个 exporter、sdk-node、两个 instrumentation 等重型依赖断言 exporter 构造的用例面向sdk-impl.ts一侧展开。五、验收issue #4748 的测量门槛字节数不能直接换算成毫秒改动必须通过 issue 既有的纪律才能合入2C4G、30 次串行冷启动遥测关闭默认配置对比channel.initialize的 P50/P95 与 process→first-Session P50 相对de962a5ecf基线的表现。仅当 P50 改善超过运行间噪声时才合入。遥测开启的功能回归OTLP gRPC 与 HTTP 目标在改动后均能收到 traces/logs/metrics既有 sdk.test.ts 矩阵 对本地 collector 的一次手动端到端--telemetry-outfile文件导出器仍正常写入。Daemon 指标遥测开启时daemon Status 指标环与initializeDaemonMetrics()的 gauges 仍正常上报守卫调用点 3 的 await。打包守卫node scripts/check-serve-fast-path-bundle.js在黑名单扩展后保持绿色重跑闭包审计.qwen/scripts/acp-closure-audit.mjs并记录新的 ACP 闭包总量预期 ≈ 17.24 − ~2.0 MiB再减去opentelemetry/api等保留 eager 的部分。单元测试sdk.test.ts 中await initializeTelemetry15 个调用点断言 exporter 构造的测试迁移到sdk-impl.ts或对其 mock。六、备选方案与取舍设计文档记录了三类被否决的备选方案理解它们有助于把握拆分边界的必然性只惰性导入六个 exporter 类、保留同步initializeTelemetry。否决会无谓地留下约 0.7 MiBNodeSDK、instrumentations、sdk-metrics、批处理器处于 eager 状态且开启路径仍要构造 exporter异步边界迟早要引入函数无论如何都会变异步。把整个telemetry/sdk.ts模块动态化。否决loggers.ts与session-tracing.ts对每次遥测调用都用isTelemetrySdkInitialized()门控把该门控变异步会污染数十个热点同步调用点。在 ACP 子进程中完全跳过遥测。在 issue 中已被否决一刀切跳过会改变开启遥测用户的可观测行为。七、总结一条可复用的冷启动优化路径本次改造给出了一个可复用的优化模式识别启动关键路径上的静态依赖簇 → 用廉价门面 重型实现的文件拆分把状态读取与重型组装解耦 → 门面通过单飞动态导入按需加载重型实现 → 用打包守卫把依赖包列入黑名单防止回归 → 用测量门槛量化收益。对于默认关闭的可选能力遥测、诊断、SDK 接入层等这套方法能显著压缩冷启动体积与模块求值时间若要落地到自己的项目中还可以进一步参考 qwen-code 后续的协议级拆分按 gRPC/HTTP/outfile 分链动态加载把按需细化到配置维度。相关文件索引设计文档docs/design/2026-07-19-lazy-telemetry-sdk-loading.md门面模块packages/core/src/telemetry/sdk.ts重型实现packages/core/src/telemetry/sdk-impl.ts协议级导出器sdk-exporters-http.ts / sdk-exporters-grpc.tsbarrel 导出packages/core/src/telemetry/index.ts打包守卫scripts/check-serve-fast-path-bundle.js单元测试packages/core/src/telemetry/sdk.test.ts【免费下载链接】qwen-codeAn open-source AI coding agent that lives in your terminal.项目地址: https://gitcode.com/GitHub_Trending/qw/qwen-code创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考