qwen-code daemon 首次输出延迟基准从进程启动到首个模型输出的可观测测量与发布门禁设计【免费下载链接】qwen-codeAn open-source AI coding agent that lives in your terminal.项目地址: https://gitcode.com/GitHub_Trending/qw/qwen-code导读本文解读 qwen-code 仓库中 docs/design/daemon-first-output-latency.md 所定义的「daemon 首次输出延迟first-output latency」测量与决策体系。这套体系回答一个具体问题当用户向 daemon 发起一条 prompt 时从进程 spawn 到模型产生首个可见输出延迟花在了哪里它通过一个可选启用的基准测试框架把进程启动、会话就绪、SSE 就绪、Provider 请求到达、首个模型输出、首个答案文本、终态等 11 个边界逐一打点并配套纯函数分类器、paired bootstrap 置信区间与严格的发布门禁用于评估「Provider 预加载Provider preparation」这类优化是否值得落地。读完本文你将掌握该基准的完整时间戳契约、运行方式、统计口径与逐级决策流程并能直接在仓库中复现这些测量。背景为什么需要单独测量「daemon 首次输出」qwen-code 的 daemon 是常驻进程对外提供会话与流式事件接口SSE用户提交 prompt 后daemon 需要经过本地提示词准备、ACP 子进程通信、Provider loader 加载、请求构造等一系列本地环节最终才把请求送达模型服务商。现有的生产指标ttft_ms首 Token 时间只覆盖「Provider 分发到首个可见内容」这一段——从 loggingContentGenerator.ts 的源码可以看到它是在流式响应中遇到第一个含用户可见内容的分块时才计算Date.now() - startTime刻意跳过 role-only / usage-only 分块。这意味着懒加载lazy loading、本地提示词准备等发生在 Provider 之前的成本完全不在ttft_ms的视野内。本文档所定义的基准追踪编号 #7757后续 immediate-prompt 归因 #7982背景 #7264正是为补齐这段盲区而设计目标范围明确为daemon / ACP 客户端可观测的延迟并且明确将以下内容排除在测量之外TUI / Web Shell / 编辑器渲染prompt 缓存与压缩模型思考thought与工具行为网络预连接真实模型延迟优化生产遥测改动、公开生命周期 API、协议字段、配置与特性开关。第一阶段的 PR仅做测量一个可选启用的基准、纯分类/统计辅助函数、测试与版本化产物不改变生产启动行为。只有单 bundle 基线通过门禁后才允许另行开发 Provider 预加载原型prototype。仓库与运行器契约文件职责划分路径职责integration-tests/cli/qwen-daemon-first-output-benchmark.test.ts可选运行器fake Provider、隔离的进程生命周期、基线/对比协议、产物写入integration-tests/cli/_first-output-benchmark.ts纯事件跟踪、分类、百分位、paired bootstrap 与决策输入integration-tests/cli/_first-output-benchmark.test.ts纯契约的确定性测试integration-tests/fake-openai-server.ts已有 fake Provider支持按响应关闭连接保证冷/热测量无偏两种输入模式互斥运行器默认禁用必须显式设置QWEN_FIRST_OUTPUT_BENCHMARK1才会生效同时该测试在 Windows 平台会被跳过属 POSIX-only。两种输入模式互斥基线模式single仅设置BENCHMARK_CLI_PATH。对比模式compare同时设置BENCHMARK_CONTROL_CLI_PATH与BENCHMARK_CANDIDATE_CLI_PATH。运行器在校验阶段就会拒绝非法组合单模式混入控制/候选路径、对比模式缺少任一 bundle、控制与候选解析到同一路径、SHA-256 哈希相同、路径不可读、dwell 或样本数不受支持、dwell 与样本计划不匹配等都会以invalid_configuration在采样前失败详见 qwen-daemon-first-output-benchmark.test.ts 中的readBenchmarkConfig与resolveBundlebundle 会做realpathSync解析并计算 SHA-256。对比模式的参数约束BENCHMARK_POST_SESSION_DWELL_MS仅对比模式可用只接受0、100、500三值默认0BENCHMARK_MEASURED_PAIRS同样仅对比模式可用只接受10或30默认规则为500 ms 场景取100/100 ms 场景取30。这种「500 ms 必须 10 对、0/100 ms 必须 30 对」的硬绑定从 measuredPairCountForDwell 的实现可见一斑它直接拒绝与 dwell 不匹配的样本数从而保证诊断场景永远不会被误标为决策场景。三个 dwell 场景在正式 Phase 2 运行中由运行器分别独立执行不同 dwell 的样本从不混合。dwell 锚点为什么锚定 SSE 就绪而不是会话就绪dwell会话后空闲窗口锚定在SSE 就绪sseReadyAt首个 SSE epoch 回调而非会话就绪sessionReadyAt。SSE 连接位于两者之间若锚定sessionReady一个慢速的 SSE 连接会把整个窗口吞掉100 ms 场景会被静默降级为「立即 prompt」运行却仍然报告配置的 dwell。因此运行器额外记录sseReadyToPromptMs表示每个样本实际获得的空闲窗口qwen-daemon-first-output-benchmark.test.ts 的注释与promptNotBefore逻辑直接体现了这一设计。串行执行配置毫秒级数字只有在宿主机无竞争时才有意义因此该运行器被排除在共享集成配置之外使用独立的串行配置 integration-tests/vitest.firstoutput.config.tsfileParallelism: false、串行执行、retry: 0、include只匹配该基准文件并将qwen-code/sdk解析到本地构建产物。纯辅助函数的测试则继续运行在共享套件中。运行命令QWEN_FIRST_OUTPUT_BENCHMARK1 QWEN_SANDBOXfalse BENCHMARK_CLI_PATH... \ npx vitest run --config integration-tests/vitest.firstoutput.config.ts产物落盘位置产物写入.qwen/investigations/daemon-first-output-benchmark/目录带时间戳子目录位于集成 harness 的一次性运行目录之外。这样即使全局 teardown 之后成功、失败与负结果negative result运行都会保留无需依赖KEEP_OUTPUT。测量契约单一时钟与精确时间戳同一把时钟所有延迟时间戳都由父 harness 使用performance.now()产生。没有任何一个时长会混用 daemon、ACP 子进程、Provider 或墙钟wall clock。daemon 的 FIFO 队列等待值是一个已有的独立时长在隔离 prompt 完成后读取从不参与父时间戳的相减。时间戳定义时间戳客户端可观测定义processSpawnAtdaemonspawn前一刻sessionReadyAt会话响应完整读取并校验通过sseReadyAt观察到首个 SSE epoch 回调dwell 锚点promptStartedAt发起非阻塞 prompt 请求前一刻promptAcceptedAtHTTP202响应体校验通过含顶层promptId与 replay cursoruserEchoAt从 SSE 解析到匹配的user_message_chunk回显providerRequestArrivalAtfake Provider 接受被测请求、进入固定延迟之前providerReadyAt固定 50 ms 延迟耗尽、响应流可用前一刻firstModelOutputAt解析到首个合格的顶层promptId匹配 SSE 事件firstAnswerTextAt解析到首个合格的答案文本事件可空terminalAt解析到匹配的turn_complete或turn_error精确派生指标原始时间戳组合出以下精确指标计算均可在 computeFirstOutputSessionTimings 中找到对应实现指标计算processToSessionReadyMssessionReadyAt - processSpawnAtsseReadyToPromptMspromptStartedAt - sseReadyAt诊断用promptToAcceptanceMspromptAcceptedAt - promptStartedAtacceptanceToProviderRequestArrivalMsproviderRequestArrivalAt - promptAcceptedAt有符号promptToUserEchoMsuserEchoAt - promptStartedAtuserEchoToProviderRequestArrivalMsproviderRequestArrivalAt - userEchoAt有符号daemonPromptQueueWaitMs已有的 daemon FIFO 队列等待时长promptToProviderRequestArrivalMsproviderRequestArrivalAt - promptStartedAtpromptToFirstModelOutputMsfirstModelOutputAt - promptStartedAtpromptToFirstAnswerTextMsfirstAnswerTextAt - promptStartedAt可空providerReadyToFirstModelOutputMsfirstModelOutputAt - providerReadyAtpromptToTerminalMsterminalAt - promptStartedAtprocessToFirstModelOutputMsfirstModelOutputAt - processSpawnAt有效性规则promptAcceptedAt只是诊断参考点不是延迟原点Provider 请求或事件可能早于客户端读到 HTTP202。daemon 会在转发 ACP prompt 之前发布匹配的用户回显但 SSE 投递可能在与 Provider 请求到达的竞速中落败。因此acceptanceToProviderRequestArrivalMs与userEchoToProviderRequestArrivalMs是有符号偏移负值合法其余所有时长必须非负findInvalidTimings 在聚合前会将其它指标中的负值或非有限值判为 harness 失败并归一为null。队列等待计数器必须在每次隔离 prompt 中恰好前进一次且保留有限的非负lastMs否则样本无效无法安全关联。缺失必需时间戳或出现非有限值样本无效。harness 拥有 30 秒 SSE 就绪截止期限SDK 连接超时被设置为 35 秒TURN_TIMEOUT_MS 5_000比 harness 晚 5 秒从而保证定时器排序不会把sse_connect_timeout变成其它失败码。immediate-prompt 归因的边界归因指标刻意停在既有边界上共同区分客户端/路由接受、转发前的中继用户回显、daemon FIFO 排队、以及剩余的 ACP 子进程/本地准备区间。这不需要跨进程时间戳、协议字段或生产遥测。回显边界包含 SSE 中继时间是近似值而非 daemon 内部时间戳。这些指标不再细分ACP 传输、提示词准备、Provider loader 结算与请求构造之间的剩余区间——更深的插桩需要另行设计与证据。prompt 与事件关联收集器行为SSE 收集器在 prompt 之前就已激活或从之前的 cursor 续读并缓冲固定数量的事件直到202交出被接受的顶层promptId。接受信封必须包含非空promptId与非负整数lastEventId只有通过stopReason识别的遗留同步响应会被标记为legacy_prompt_response其它畸形响应一律拒绝见 validatePromptAcceptance。prompt 接受超时会先中止底层请求再进入样本 teardown。收集器随后按原始到达顺序评估缓冲与实时事件只接受顶层 ID 精确匹配的事件更早的、无 ID 的、无关 prompt 的事件全部忽略。缓冲溢出时 tracker 锁死失败状态并停止缓冲样本作废多余事件丢弃对应失败码event_buffer_overflow默认缓冲上限 256见 DEFAULT_FIRST_OUTPUT_EVENT_BUFFER_LIMIT。Provider 请求不携带 daemon promptIdProvider 请求不携带 daemon 的promptId。因此每个隔离的 fake Provider 同时只允许一个被测请求并通过唯一固定长度的 prompt 哨兵匹配。其时间戳可能先于202被缓冲出现额外、缺失、过早或并发请求都会使样本失败provider_request_count_mismatch。测试代码中每个 prompt 都是固定 128 字符、带零填充递增 marker 的哨兵makePrompt。首个合格事件判定firstOutputAt由首个合格事件决定事件类别非空agent_message_chunk文本answer_text且为首次答案边界非空agent_thought_chunk文本thought_text格式良好的初始tool_calltool_call「非空」指解码后文本长度大于零文本不做 trim 或改写。以下事件不计入replay/状态帧、本地离散消息含 slash-command 与后台通知输出、用户回显、role-only 或 usage-only 分块、压缩诊断、畸形更新、tool_call_update。turn_error永远判失败qualifying output 之前的turn_complete也判失败terminal_before_first_output。纯 tracker 允许「先 thought 或先 tool、answer 指标为空」的回合而真实运行的 fake Provider 必须产出已知答案哨兵EXPECTED_ANSWER benchmark response complete。上述分类逻辑集中在 classifyFirstOutputEvent 与FirstOutputTracker类中并有完整配套纯测试覆盖。Fake Provider 与隔离策略fake Provider 行为仅回环的 OpenAI 兼容 fake Providerintegration-tests/fake-openai-server.ts记录请求到达、校验请求/model要求streamtrue与modelfake-model、等待配置的 50 ms 定时器、记录实际经过的延迟与providerReadyAt、发出一个流式答案哨兵并正常结束。基准响应显式使用Connection: closekeepAlive: false这样热回合无法从冷回合打开的 TCP 连接中获益网络预连接保持在被测优化之外。50 ms 延迟只用于把「本地请求前工作」与「响应/事件传播」分离并不模拟真实延迟分布。进程级隔离每个基线进程、每个对比分支都获得全新的 daemon/ACP 进程树、workspace、home 与QWEN_HOME、临时 daemon/Provider 端口、事件收集器与请求台账样本串行执行。子进程从最小环境白名单启动固定 locale/时区C.UTF-8/UTC、隔离可写路径、禁用遥测与更新检查、dummy Provider 配置OPENAI_API_KEYfake-key、OPENAI_BASE_URL指向 fake server、清除真实凭据与代理变量NO_PROXY/no_proxy指向回环。产物只记录刻意提供的非机密值。Node 编译缓存策略Node 编译缓存在正式运行开始时为空按 bundle 与模式隔离只由排除在外的 warmup 填充随后仅由同一 bundle 复用。产物记录每个缓存目录用于溯源但干净运行会在 teardown 时删除该目录所以记录的路径事后不一定存在。控制与候选永不共享编译缓存。warmup 观测保留在产物中并标记measured: false。正式对比的宿主要求正式对比使用同一 lockfile 构建的 release bundle在同一空闲的 2-vCPU Linux 宿主机上运行。产物记录解析路径、SHA-256 哈希、可用源码修订、Node/OS/CPU/内存与负载元数据。由于文件系统 page cache 与调度器噪声无法可靠冲刷AB/BA 顺序与顺序敏感性门禁是强制的。Phase 1单 bundle 冷/热基线先运行 2 个排除在外的 warmup 进程再运行 50 个被测进程。每个被测进程创建全新的sessionScope: thread会话并发送一条立即执行的固定长度 promptcold等待其校验通过的终态保持第一个会话打开在同一 ACP 子进程上创建另一个不同的sessionScope: thread会话发送一条等长但哨兵不同的 promptwarm。运行器在两轮结束后记录 ACP 子进程 PID除非同一个且未变化的子进程服务了两轮否则样本作废。直到第二轮结束才关闭两个会话。因此第二个会话拥有全新的按会话懒加载 Provider wrapper但 ACP 进程级 ESM/运行时缓存是热的。这一对样本界定了「进程首次走完整 prompt 路径的一次性本地成本」上界且不引入会话历史干扰。Provider 构造只是该成本的一个分量首个 prompt 还支付了首次 daemon 路由命中、首次 ACP IPC 往返、JIT 预热与任何无关的懒加载 import。因此该差值只是「预加载 Provider 可能挽回成本」的上界不是 Provider 加载量的估计门禁通过也不能证明 Provider 占了其中多少份额——归因由 Phase 2 的配对对比来检验。两个会话都会在 prompt 时各自构造 Provider原型可能移入 dwell 的工作不被计功所以门禁是保守的。第二会话的 process-to 指标仅作诊断。基线期望每进程恰好 2 个 Provider 请求50 对冷/热全部有效。冷与热共享同一进程其差值天然配对而非独立样本门禁基于配对中位数及其带种子 bootstrap 95% 区间providerDelta[i] cold promptToProviderRequestArrivalMs[i] - warm promptToProviderRequestArrivalMs[i] providerDeltaCiLow lower bound of the 95% CI of median(providerDelta)Phase 1 通过条件二选一providerDeltaCiLow 25 ms或providerDeltaCiLow 10% * P50(cold promptToFirstModelOutputMs)必须用区间下界而非点估计去越过阈值只勉强超出的差值无法与噪声区分不能据此授权原型。两个 P50 的差仍会被记录用于连续性但不再参与决策。冷总是第一个会话配对无法像 Phase 2 对比那样做顺序平衡这是构造的已知局限而非遗漏。门禁判定逻辑实现在 evaluateSingleBundlePrototypeGate默认绝对阈值 25 ms、相对比例 0.1、10000 次 bootstrap。否则产物保留、生产工作停止。对比与统计口径样本计划与 AB/BA 平衡每个对比 dwell 先跑 2 对排除在外的 warmup 对再跑 30 对被测对显式诊断的 500 ms 场景用 10 对且顶层结论永远是不确定inconclusive。奇数对先 control 后 candidateAB偶数对先 candidate 后 controlBA。每个分支都是全新状态所有记录的 delta 均为candidate - control负值代表更快。失败处理失败分支保留在原始输出中并使所在对失效不替换、不删除离群值、不 winsorize、不做子集选择、不重试。首个无效进程或完成的对之后采样立即停止。外层 Vitest 截止时间从最大合法样本计划与每个固定生命周期超时保守推导并加上调度余量因此即使接近截止时间的合法样本也无法抢占产物写入紧急 teardown 有自己的固定 hook 截止时间。任何无效主对都会使正式运行整体作废。报告指标每个指标分别报告两分支的 nearest-rank P50/P90/P99 与均值、配对中位数 delta、胜/平次数、AB/BA 子组中位数。P90/P99 在 30 对时仅作描述少于 100 对不下任何 P95 或尾延迟结论。两种中位数的刻意共存每分支p50是 nearest-rank永远是观测到的真实值配对的median delta以及 bootstrap 重采样内的中位数在偶数样本时取两个中间值的平均。因此 Markdown 行里可能出现p50与median delta算术上对不上的情况两者都没有错。相关实现见 percentiles 与median。Bootstrap 与顺序敏感性配对中位数 95% 置信区间使用10,000 次带种子有放回 bootstrap 重采样种子与迭代数一并存储区间端点为 nearest-rank 2.5th 与 97.5th 百分位bootstrapMedianCi95。每个指标的种子按其在指标列表中的位置偏移测试代码中index * 10因此插入或重排指标会改变其后所有指标的 bootstrap 边界——即使原始样本完全相同改动前后的产物也不可比每个指标存储的seed保证可审计。orderSensitive为真当且仅当 AB 与 BA 的中位数 delta 符号相反、且任一绝对值中位数 ≥ 10 ms。顺序敏感性使运行结论为不确定而不是被平均掉。配对产物的顶层结论只描述该场景下唯一主指标processToFirstModelOutputMs的表现它不评估跨场景、资源、功能或发布门禁本身不能授权 Phase 2 PR。失败分类、产物与清理失败码全表每个已分类的生命周期或样本失败都被保留并有一个主代码代码触发条件invalid_configuration模式、路径、dwell、环境或 bundle 身份非法daemon_boot_timeout截止前未出现监听端点daemon_exited_before_listendaemon 在就绪前退出session_create_failed会话响应出错或畸形sse_connect_timeout截止前 SSE 未建立sse_stream_ended匹配终态前 SSE 流结束prompt_accept_timeoutprompt 请求在截止前未完成prompt_rejected202响应出错或畸形legacy_prompt_response端点同步完成而非返回promptIdevent_buffer_overflow接受前固定缓冲溢出provider_request_count_mismatchfake 请求多余、缺失、过早或并发unexpected_output_kindanswer-only 实测首输出为其它类别first_output_timeout截止前无合格输出terminal_before_first_output无合格输出即干净终态turn_error匹配的错误终态terminal_timeout输出后截止前无终态wrong_final_text答案与哨兵不符cleanup_timeout自有资源未在截止前停止residual_process跟踪的 daemon/ACP 后代在清理后仍存活harness_error未分类的 harness 不变量或 I/O 失败首个因果生命周期失败保持为主SSE/会话与进程清理失败单独记录但仍使对失效。固定超时、请求限制与缓冲容量都会序列化进产物诊断消息与有界的 stdout/stderr 尾部不影响决策。产物内容每次调用写出 schema-version-2 的daemon-first-outputJSON 以及仅由该 JSON 派生的 Markdown渲染逻辑见 renderFirstOutputBenchmarkMarkdown。产物包含运行/平台/bundle 身份、清洗后的配置、warmup、每个原始相对时间戳与指标、锁定的首输出/答案/终态事件类型与关联计数、Provider 请求计数、无效样本与对、失败、清理结果、统计/bootstrap/顺序摘要、带明确决策理由的门禁输入。Phase 2 资源运行会额外以 RSS 测量扩充校验证据。产物排除凭据、token 与超出非机密基准哨兵的 prompt 内容。清理协议清理总是中止并等待 SSE、关闭活动会话、采集 ACP/MCP 后代 PID、向所属进程组发送SIGTERM组 leader 仍存活时仅当同一 leader 在固定宽限期后仍存活才升级信号。捕获的后代与「枚举完整性闩锁」通过紧急清理始终附着在活动资源上。leader 退出后清理不再探测或发信号给其数字进程组 IDPOSIX 可能复用该 ID只校验保留的后代集合若有后代存活或枚举不完整则安全失败。Provider socket 只在进程 teardown 之后关闭临时状态在两者都验证后才移除。清理从不做进程名级别的批量杀进程。任何无效进程或已完成的对会立即停止采样但保留失败。若某个自有进程或监听器无法验证已停止运行器会把临时根目录记为延后到紧急清理、必要时标记一个未启动的对位样本以保留无效对、并让紧急 teardown 失败可见而非静默丢弃其跟踪资源。紧急 teardown 在删除延后临时根目录或编译缓存之前会先重试跟踪进程与 Provider。Phase 2尽力而为的 Provider 预加载行为与边界当前的懒加载生成器会在 generation、streaming、token 计数与 embedding 之间记忆化同一个 loader promise。预加载preparation可以提前启动这个同一个 promise但必须满足约束不得新增另一个 loader/Provider不得发起任何 model/token/embed 请求不得刷新凭据不得改变 eager 校验与 Qwen OAuth 凭据时序立即执行的 prompt 必须加入同一个 promisesingle-flight。被拒绝的预加载 promise 保持记忆化让首个 prompt 观察到同样的失败脱离的调用方只能附加 rejection observer 防止 unhandled rejection不得清除或替换已存的 promise。该能力保持在 Core 内部不扩展公开的ContentGenerator契约。最早允许的触发点是 ACP 子进程成功写出session/new结果之后观察收到的请求 ID观察到同 ID 且带result的已发送响应依赖既有观测只在writer.write(frame)resolve 后发生调度一个 unrefed 的setImmediate来启动但不 await 预加载。失败响应、鉴权、session/load、session/resume及其它 RPC 不触发预加载。不使用 sleep 猜测响应投递。ESM import 不可取消因此已关闭的会话可能允许已开始的 import 完成但它仍不得发出请求、不保留外部资源、不产生 unhandled rejection。该边界只是尽力而为daemon 仍执行会话归属/配置/来源持久化工作并在子进程写出后序列化外层 HTTP 响应Provider import 可能竞争 2-vCPU 宿主机并使processToSessionReadyMs回退setImmediate不建立跨进程 happens-before 关系。因此会话非劣性session non-inferiority是阻塞性门禁——如果失败就停止而不是去调定时器。一个精确的「外层响应完成」信号会横跨 HTTP 传输、daemon bridge 与 ACP 子进程只有当测量值证明值得时才需要单独设计。发布门禁在参考宿主机上使用两个不同的 release bundle场景必需结果Fake0 ms dwell30 对processToSessionReadyMs与promptToFirstModelOutputMs两者的 95% 配对中位数 CI 上界均 10 msFake100 ms dwell30 对processToFirstModelOutputMs配对中位数 -10 ms且其 95% CI 上界 0Fake500 ms dwell10 对仅诊断上界不能补偿其它失败门禁也不能单独证明合并在 0 与 100 ms 的 fake 运行中所有 60/60 对必须有效零个预加载窗口内的 Provider 请求、零残留进程、无顺序敏感性。资源门禁测量 Provider 预加载稳定后、任何 prompt 之前的 1、4、16 个空闲会话的整棵进程树 RSS两个门禁都必须通过单会话 candidate-minus-control P50 RSS 10 MiBcandidate-minus-control 从 1 到 16 个活动会话的增量增长 0.5 MiB每额外会话((candidateRss16 - candidateRss1) - (controlRss16 - controlRss1)) / 15每个空闲会话探针串行创建会话、等待预加载稳定、RSS 测量前不发 prompt任何 Provider 请求都会使其失败。对数与顺序在正式测量前固定进 Phase 2 验证产物。只有所有 fake/资源门禁通过后才在同一宿主机上运行真实 Provider 的外部有效性验证100 ms 的 30 对 AB/BA 加上 10 对的立即 smoke。功能/鉴权/流式/答案失败阻塞发布。网络不确定性会被报告但不能双向覆盖 fake 本地结论。验证与决策流程Phase 1 纯测试覆盖answer/thought/tool 分类本地/replay/诊断排除202前与精确关联缓冲溢出终态/错误路径可空 answer 指标nearest-rank 百分位确定性 bootstrapdelta 符号无效对保留顺序敏感性代表性致命产物JSON-to-Markdown 渲染全部见 integration-tests/cli/_first-output-benchmark.test.ts含 dwell/样本数约束测试。一个可选的 release-bundle smoke 验证 Provider 接线、生命周期、产物 schema 与清理。正式基准不属于默认 CI。Phase 2 候选还需测试触发时序与 RPC 过滤与立即 prompt 的 single-flight零 Provider 请求/凭据刷新记忆化拒绝非阻塞响应写出安全关闭。它必须通过构建、类型检查、受影响的单元/集成测试与全部产物门禁。整体决策树与文档一致50-process cold/warm baseline valid and threshold met? ├─ no → retain artifact; stop └─ yes → prototype separately └─ fake 0 ms non-inferior? ├─ no → retain artifact; stop └─ yes └─ fake 100 ms materially faster with CI 0? ├─ no → retain artifact; stop └─ yes └─ 60/60 valid request/cleanup/order/RSS gates pass? ├─ no → retain artifact; stop └─ yes └─ real-Provider runs functionally pass? ├─ no → retain artifact; stop └─ yes → optimization PR may be published关键文件速查设计文档docs/design/daemon-first-output-latency.md基准运行器约 2340 行含配置解析、进程隔离、时间戳采集、产物构建与紧急清理integration-tests/cli/qwen-daemon-first-output-benchmark.test.ts纯分类与统计契约tracker、分类器、百分位、paired bootstrap、门禁、schema-v2 产物类型与 Markdown 渲染integration-tests/cli/_first-output-benchmark.ts纯契约确定性测试integration-tests/cli/_first-output-benchmark.test.ts串行运行配置integration-tests/vitest.firstoutput.config.tsfake ProviderConnection: close开关integration-tests/fake-openai-server.ts生产ttft_ms语义Provider 分发到首个可见内容loggingContentGenerator.ts这套设计将「优化是否值得做」从主观判断转化为带置信区间与失败分类的可证伪测量任何一步门禁不通过都保留产物并停止推进任何诊断结论都不能冒充决策结论从而保证对 daemon 启动路径的每一次改动都有据可依、可复现、可审计。【免费下载链接】qwen-codeAn open-source AI coding agent that lives in your terminal.项目地址: https://gitcode.com/GitHub_Trending/qw/qwen-code创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考