qwen-code Workflow 級 Trace Span 缺口分析用雙 ALS 父級解析構建 Agent 執行軌跡樹【免費下載鏈接】qwen-codeAn open-source AI coding agent that lives in your terminal.項目地址: https://gitcode.com/GitHub_Trending/qw/qwen-code本文以 qwen-code 的設計文檔《Workflow 級 Span 粒度不足分析》為主線剖析一個 AI coding agent 在 OpenTelemetry 接入中有 tracing 主干、卻沒有 workflow 階段邊界的典型困境審批等待、hook、subagent 等階段如何編碼成 trace 樹中的獨立節點。讀完本文你將掌握基于 AsyncLocalStorageALS的 span 父子掛載模型、五種 workflow span 缺口及其修復方案并能對照當前倉庫源碼驗證這些建議的實際落地方式。1. 背景從有 tracing 主干到編碼 workflow 階段邊界該分析文檔基于 2026-05-13 對 qwen-code origin/main 的復核。當時項目已具備 tracing 基礎設施各組件分布如下組件位置說明Span 類型定義session-tracing.tsinteraction、llm_request、tool、tool.executionTracer 工具tracer.tssession root context、withSpan、startSpanWithContext交互入口client.ts頂層交互顯式啟動interactionspan生命周期管理—AsyncLocalStorage WeakRef TTL cleanup當時的 runtime 中穩定接入的主要是兩類 generic spanapi.generateContent/api.generateContentStreamtool.toolName文檔的核心結論是已進入有 tracing 主干階段但尚未把 agent workflow 的階段邊界完整編碼進 trace 樹。作為對照文檔引用了外部項目 claude-code 在src/utils/telemetry/sessionTracing.ts中已實現的六類 spaninteraction、llm_request、tool、tool.blocked_on_user、tool.execution、hook此引用來自原文檔的外部對比非本倉庫文件。2. 五大缺口workflow 階段在哪里隱形缺失 span / 機制影響permission_wait/blocked_on_userspan無法區分審批等待 vs 工具執行耗時hookspanhook 耗時被折疊進 tool span定位邊界不清subagentroot spansubagent 內部 llm/tool 調用無法形成 trace 子樹tool.execution真實接線helper 已定義但主鏈路未調用穩定的 parent-child wiringspans 多為 session root 下的 sibling 而非層級樹2.1 用戶審批等待不在 trace 中工具調用等待審批時狀態遷移路徑為awaiting_approval→scheduled→ 執行。等待用戶確認只是狀態遷移不是 trace 節點trace 上看不到審批等待耗時工具慢時無法區分是卡在等用戶還是工具本身執行慢。2.2 Hook 有事件記錄但沒有獨立 spanPre/Post hook 執行后產出HookCallEvent走logHookCall()記錄日志但不建立獨立 OTel span。后果是hook 變慢時表現為外層 tool span 變慢hook 失敗時表現為tool 失敗trace 無法回答時間花在 hook 還是 tool.execution 上。2.3 Subagent 是 log/metric 而非 trace subtreesubagent 啟動/完成時記錄SubagentExecutionEvent事件名定義見 constants.ts并進入 log/metric但沒有形成顯式 span 子樹。能統計哪個 subagent 跑過但不能順著 trace 看這個 subagent 觸發了哪些 llm/tool 調用并發 subagent 場景下因果鏈不清。2.4 tool.execution helper 已定義但未接入主鏈路復核時session-tracing.ts中已有startToolExecutionSpan()/endToolExecutionSpan()但非測試代碼中未見調用點。當時的實際 trace 樹與理想 trace 樹對比如下實際session-root interaction api.generateContent tool.Bash subagent_execution (log/metric) hook_call (event/QwenLogger)理想interaction llm_request tool tool.blocked_on_user hook(pre) tool.execution hook(post) subagent interaction llm_request tool2.5 Parent-child wiring 不夠穩定interaction span 已存在但很多運行中的 spans 掛在 session root 下作為 sibling而不是 interaction 的子節點。調用樹偏平、節點間因果關系不直觀從一個用戶輪次追到內部 llm/tool/hook/subagent 的體驗不連續。在 Jaeger / Tempo / ARMS 等后端上這樣的樹比層級清晰的實現更難讀。3. 根因剖析兩套斷裂的 span 創建路徑這是文檔指出的當前最關鍵的架構問題層文件用法parent 解析session-tracing 層session-tracing.tsstartInteractionSpan/startLLMRequestSpan/startToolSpan/startToolExecutionSpan顯式從interactionContextALS 取 parenttracer 層tracer.tswithSpan/startSpanWithContext從context.active()取 parentfallback 到 session rootruntime 實際調用情況復核時點startInteractionSpan→已接入client.ts寫入interactionContextALSstartLLMRequestSpan/endLLMRequestSpan→未接入runtime 用的是withSpan(api.generateContent, ...)在loggingContentGenerator.tsstartToolSpan/endToolSpan→未接入runtime 用的是withSpan(tool.${name}, ...)在coreToolScheduler.tsstartToolExecutionSpan/endToolExecutionSpan→未接入。從源碼看withSpan的父級解析函數getParentContext()只返回context.active()tracer.ts它完全不讀取interactionContextALS找不到活躍 span 時回退到 session root context。因此 interaction span 與 LLM/tool spans 變成了 session root 下的平級 sibling而不是 parent-child 樹session-root ├── interaction (來自 session-tracing, 寫入了 interactionContext ALS) ├── api.generateContent (來自 withSpan, 不讀 interactionContext → 掛到 session root) ├── tool.Bash (來自 withSpan, 同上) └── tool.Read (來自 withSpan, 同上)而參照實現 claude-code 中只有一套 span 創建路徑sessionTracing.ts所有 span 都走同一套 ALS → OTel context 轉換邏輯所以樹是完整的。4. 參照模型claude-code 的雙 ALS span 管理文檔對 claude-code 源碼做了深度對比其 tracing 架構可概括為interactionContext (ALS) toolContext (ALS) │ │ ▼ ▼ ┌─────────────────────┐ ┌─────────────────────┐ │ interaction span │ │ tool span │ │ (session root) │ │ (child of intxn) │ └─────────────────────┘ └─────────────────────┘ ▲ parent of ▲ parent of │ │ ┌───────┴───────┐ ┌──────────┼──────────┐ │ │ │ │ │ llm_request tool blocked execution hook _on_user核心機制機制實現雙 ALSinteractionContext存當前 interaction spantoolContext存當前 tool spanparent 解析每種 span 類型硬編碼從哪個 ALS 取 parentllm_request/tool取interactionContextblocked_on_user/execution/hook取toolContexthook有 fallback 到interactionContext生命周期enterWith 注入 → span 運行 → enterWith(undefined) 清除查找 span非 ALS 存儲的 span如 blocked_on_user通過activeSpansMap 按span.type反查內存管理ALS 持有的 span 用 WeakRef非 ALS 持有的 span 用 strongRef 防 GCTTL 30min 自動清理tool span 完整生命周期toolExecution.tsstartToolSpan(name, attrs) // → toolContext.enterWith(spanCtx) startToolBlockedOnUserSpan() // → parent toolContext.getStore() [permission resolution / user prompt] endToolBlockedOnUserSpan(decision, source) startToolExecutionSpan() // → parent toolContext.getStore() [tool.call()] endToolExecutionSpan({ success }) endToolSpan(result) // → toolContext.enterWith(undefined)hook spanhooks.tsstartHookSpan(event, name, count, defs) // → parent toolContext ?? interactionContext [parallel hook execution] endHookSpan(span, { success, blocking, ... })5. 逐項復用方案5.1 雙 ALS 顯式 parent 解析核心修復維度claude-codeqwen-code復核時ALS 數量2interactionContexttoolContext1interactionContext無toolContextparent 解析每種 span 類型顯式指定從哪個 ALS 取 parentwithSpan統一走context.active()context 注入trace.setSpan(otelContext.active(), parentCtx.span)withSpan內部由startActiveSpan隱式注入qwen-code 的session-tracing.ts當時已經實現了與 claude-code幾乎相同的 parent 解析模式// qwen-code session-tracing.ts (已有但未用) export function startLLMRequestSpan(model, promptId): Span { const parentCtx interactionContext.getStore(); const ctx parentCtx ? trace.setSpan(otelContext.active(), parentCtx.span) : otelContext.active(); // ... }核心修復路徑廢棄 runtime 中的withSpan(api.*)/withSpan(tool.*)調用改為調用 session-tracing 的 typed helpers。不需要重寫 session-tracing 層——它的 API 已經就緒。需要新增的只有增加toolContextALS仿 claude-code增加blocked_on_user和hookspan 類型及 helper 函數。5.2 tool.blocked_on_user適配審批流差異維度claude-codeqwen-code審批位置在toolExecution.ts內tool span 內部在coreToolScheduler._schedule()內tool span 之前審批模式同步等待resolveHookPermissionDecision()狀態機驅動validating→awaiting_approval→scheduled→executingspan 覆蓋范圍tool span 包含 blocked executiontool spanwithSpan只包含 execution從executeSingleToolCall開始關鍵差異qwen-code 的executeSingleToolCall入口檢查toolCall.status ! scheduled才繼續——調用到這里時審批已經完成tool span 的withSpan包不住審批等待。文檔給出兩種適配方案方案 A — 前移 tool span 起點推薦將startToolSpan調用從executeSingleToolCall移到_schedule中審批檢查之前使 tool span 覆蓋完整生命周期。在進入awaiting_approval狀態時startToolBlockedOnUserSpan在審批完成scheduled時endToolBlockedOnUserSpan_schedule(): startToolSpan(name) // ← 新增 startToolBlockedOnUserSpan() // ← 新增進入 awaiting_approval 時 [狀態機等待] endToolBlockedOnUserSpan(decision) // ← 新增進入 scheduled 時 executeSingleToolCall(): startToolExecutionSpan() // ← 接入已有 helper [hook execute] endToolExecutionSpan() endToolSpan() // ← 需要在 finally 中方案 B — 保持 tool span 位置不變單獨追蹤審批在_schedule中獨立創建approval_waitspan不作為 tool 的 child掛到 interaction 下。好處是改動更小壞處是與參照模型不一致、trace 樹可讀性差。建議采用方案 A原因與參照實現的 trace 樹結構一致trace 上一個 tool 節點就能看到等了多久 執行了多久狀態機驅動的特性只影響 span start/end 的觸發時機不影響 parent-child 建模。5.3 hook span可直接復用維度claude-codeqwen-codehook 執行入口executeHooks()inhooks.tsfirePreToolUseHook/firePostToolUseHookviahookEventHandler.ts現有記錄方式OTel span Perfetto spanHookCallEvent→QwenLogger無 OTelparenttoolContext ?? interactionContext—復用方案在session-tracing.ts新增startHookSpan/endHookSpanparent toolContext ?? interactionContext在coreToolScheduler.ts的executeSingleToolCall中 pre/post hook 調用前后分別 start/end hook span保留現有logHookCall事件記錄兩套并行不互斥。改動量低不影響現有 hook 邏輯。5.4 tool.execution已有 helper只需接線startToolExecutionSpan()/endToolExecutionSpan()已經完整實現只需在executeSingleToolCall中調用// coreToolScheduler.ts executeSingleToolCall 內部 const toolSpan startToolSpan(toolName, attrs); // ... hook pre ... const execSpan startToolExecutionSpan(toolSpan); try { // ... invocation.execute() ... endToolExecutionSpan(execSpan, { success: true }); } catch (e) { endToolExecutionSpan(execSpan, { success: false, error: e.message }); } // ... hook post ... endToolSpan(toolSpan);風格差異說明qwen-code 的startToolExecutionSpan原設計接收顯式parentToolSpan參數而參照實現從toolContextALS 隱式獲取。引入toolContextALS 后可統一為隱式獲取。5.5 subagent trace tree不建議直接復用維度claude-codeqwen-codeOTel trace 傳播無— subagent 的 interaction 是新 root無— subagent 無顯式 trace 傳播身份關聯Perfetto metadataagent process/threadteammateContextStorageALSsubagentNameContextALS SubagentExecutionEvent并發隔離OTel ALS 有泄漏風險enterWith是進程級并發 subagent 會互覆蓋同樣的風險claude-code 在 subagent OTel tracing 上自己也沒解決好interactionContext.enterWith()是進程級的并發 subagent 會覆蓋彼此的 ALS 值真正的 agent 層級樹只存在于 Perfetto一個 feature-flagged 的內部系統不在 OTel 中。因此建議短期沿用現有的subagentNameContext 事件日志方案中期在 subagent 啟動時創建一個subagentspanparent 當前 toolContext并用context.with()而非enterWith()來隔離并發 subagent 的 OTel context。這是需要獨立設計的工作項不建議直接照搬。5.6 LLM request span路徑明確復核時點在loggingContentGenerator.ts中用withSpan(api.generateContent, ...)和startSpanWithContext(api.generateContentStream, ...)改為調用startLLMRequestSpan/endLLMRequestSpansession-tracing 層已有實現即可。streaming 場景需注意startLLMRequestSpan返回Span對象需要手動傳入endLLMRequestSpan(span, metadata)終結——這與startSpanWithContext的手動管理模式兼容。5.7 復用總結與實施順序改造項可復用程度改動量優先級統一 span 創建路徑廢棄 runtimewithSpan用 session-tracing helpers核心修復— 解決 parent-child 斷裂中約 5 個調用點P0新增toolContextALS直接照搬參照模式低session-tracing.ts 內部P0tool.blocked_on_user span方案 A 需適配狀態機中_scheduleexecuteSingleToolCall協調P1tool.execution 接線helper 已有只需調用低executeSingleToolCall內 3 行P1hook span新增 helper 調用點低P1LLM request span 切換替換 withSpan 為 typed helper低2 個調用點P1subagent trace tree不建議直接復用— 需獨立設計高P2Phase 1 — 修復 trace 樹結構 (P0) ├── 1a. session-tracing.ts 新增 toolContext ALS blocked_on_user / hook span helpers ├── 1b. loggingContentGenerator.ts: withSpan → startLLMRequestSpan/endLLMRequestSpan └── 1c. coreToolScheduler.ts: withSpan → startToolSpan/endToolSpan Phase 2 — 補齊 workflow span (P1) ├── 2a. coreToolScheduler._schedule: blocked_on_user span 接入 ├── 2b. coreToolScheduler.executeSingleToolCall: tool.execution span 接入 └── 2c. hook pre/post 調用處: hook span 接入 Phase 3 — Subagent trace tree (P2) ├── 3a. 設計 context.with() 隔離方案替代 enterWith ├── 3b. subagent 啟動時創建 subagent root span └── 3c. 并發 subagent 場景驗證6. 當前倉庫源碼驗證缺口如何被逐一修復設計文檔是 2026-05 的快照而當前倉庫源碼顯示上述修復項已基本落地源碼注釋中引用了 issue #3731 的 Phase 2/3 等推進標記。本節以當前源碼為證據說明每項建議的實際實現形態。6.1 Span 詞匯表七類 workflow span 全部成為一等公民constants.ts 定義了完整的 span 名常量常量span 名語義SPAN_INTERACTIONqwen-code.interaction一次用戶輪次trace rootSPAN_LLM_REQUESTqwen-code.llm_request單次 LLM 請求SPAN_TOOLqwen-code.tool工具調用完整生命周期含審批等待SPAN_TOOL_EXECUTIONqwen-code.tool.execution工具實際執行階段SPAN_TOOL_BLOCKED_ON_USERqwen-code.tool.blocked_on_userawaiting_approval等待用戶的時間SPAN_HOOKqwen-code.hook單個 hook 觸發點SPAN_SUBAGENTqwen-code.subagent單次 subagent 調用同時 constants.ts 維護了tool.failure_kind詞匯表cancelled、pre_hook_blocked、invocation_guard_denied、timeout、plan_mode_blocked等注釋明確要求寫入點與文檔不能漂移——即 span 語義在 coreToolScheduler、session-tracing 與文檔三方共享同一常量源。6.2 雙 ALS實為三 ALS與 parent 優先級鏈session-tracing.ts 中現有三個 AsyncLocalStorageconst interactionContext new AsyncLocalStorageSpanContext | undefined(); const toolContext new AsyncLocalStorageSpanContext | undefined(); // 注釋子 span 創建時優先讀取 subagentContext // 否則前臺 subagent 的子 span 會被 re-parent 回外層 interaction const subagentContext new AsyncLocalStorageSpanContext | undefined();startLLMRequestSpanWithContext與startToolSpan的 parent 解析采用統一優先級鏈session-tracing.tsconst parentCtx subagentContext.getStore() ?? toolContext.getStore() ?? interactionParentCtx; const ctx resolveGenAiParentContext(parentCtx);這正是文檔 5.1 節雙 ALS 顯式 parent 解析建議的實現并額外增加了subagentContext一層解決了subagent 內部 LLM span 逃逸回外層 interaction的問題。值得注意的是resolveGenAiParentContext的防御邏輯session-tracing.ts當沒有任何 ALS 屬主時強制返回ROOT_CONTEXT防止錯誤 prompt 的 span 被錯誤地掛到活躍 interaction 之下。6.3 方案 A 落地tool span 前移到 validating 階段文檔推薦的方案 A 在 coreToolScheduler.ts 中按注釋原文實現// Open the tool span as soon as the call is validated. This covers // validating → awaiting_approval → executing in one span (#3731 // Phase 2). Every cancel/error path below — and the existing // success path in executeSingleToolCall — must call // finalizeToolSpan(callId, ...) to avoid leaking spans. const toolSpan startToolSpan(canonicalName, { tool.call_id: reqInfo.callId, ... }, ...);即 tool span 從validating狀態就打開一個 span 覆蓋validating → awaiting_approval → executing完整生命周期span 句柄存入this.toolSpansMap 以便跨狀態機階段終結。審批等待階段則顯式掛 blocked_on_user 子 spancoreToolScheduler.tsthis.setStatusInternal(callId, awaiting_approval, confirmationDetails); // blocked_on_user span as a child of the tool span const blockedSpan startToolBlockedOnUserSpan(toolSpan, { tool_name: canonicalName, call_id: callId, });startToolBlockedOnUserSpan的父級通過顯式toolSpan參數解析session-tracing.ts注釋明確說明原因該 span 啟動于工具主體進入runInToolSpanContext之前此時toolContext.getStore()為空同時顯式傳 span 對象也規避了參照實現中按 type 反查最后一個 span在并發下的競態問題。endToolBlockedOnUserSpan記錄decisionproceed_once/proceed_always/cancel/aborted/auto_approved/error見 session-tracing.ts與sourcecli/ide/hook/auto/system兩個規范屬性且 span 狀態保持 UNSET——等用戶既非 OK 也非 ERROR決策屬性才是規范信號。6.4 tool.execution 與 hook span 接線tool.executioncoreToolScheduler.ts 與 #L5305 兩處startToolExecutionSpan({ toolName, callId })對應文檔 5.4 節只需 3 行接線的預測。helper 內部從toolContext.getStore()取父級session-tracing.ts在runInToolSpanContext外調用時會打 warning 并回退到活躍 OTel span。hook spancoreToolScheduler.ts 中startHookSpan(opts)與endHookSpan(hookSpan, endMeta)成對出現。當前HookEvent類型比文檔復核時更豐富覆蓋PreToolUse/PostToolUse/PostToolUseFailure/PostToolBatchsession-tracing.tsstartHookSpan的 parent 優先級為toolContext → subagentContext → interactionContextsession-tracing.ts在 subagent 內部、tool 之外觸發的 hook 也能正確掛到 subagent 下。并發安全runInToolSpanContextsession-tracing.ts刻意用toolContext.run()otelContext.with()而非enterWith()把上下文作用域限定在單個異步調用樹內——這直接回應了文檔 5.5 節對進程級enterWith在并發下互相覆蓋的擔憂。6.5 LLM request span 切換到 typed helperloggingContentGenerator.ts 與非流式/流式路徑#L563均已改為startLLMRequestSpanWithContext/endLLMRequestSpan測試文件 loggingContentGenerator.test.ts 對 token 計數、緩存命中、重試上下文attempt/requestSetupMs/retryTotalDelayMs、流空閑超時等終結路徑均有斷言。endLLMRequestSpan除寫入gen_ai.usage.*、ttft_ms、finish_reason等屬性外還派生sampling_ms與output_tokens_per_second并按 Phase 4c 記錄分階段直方圖session-tracing.ts。6.6 Subagent trace treePhase 3 的獨立設計文檔 5.5 節建議獨立設計、用context.with()隔離并發當前實現源碼注釋標記#3731 Phase 3給出了具體答案startSubagentSpansession-tracing.ts區分foreground/fork/background三種調用形態foreground作為當前活躍 span通常 AGENT tool span的子節點繼承 traceIdfork/background則創建linked-root span——root: true強制新 traceId同時用 OTelLink指向發起方 span注釋引用了 OTel 規范對長耗時異步操作使用 Link 的建議理由正是 fire-and-forget subagent 運行數分鐘到數小時若掛在父 trace 下會超出多個后端的 trace 容量上限。runInSubagentSpanContextsession-tracing.ts是并發隔離的關鍵它用subagentContext.run()toolContext.run(undefined, ...)otelContext.with()組合包裹 subagent 主體注釋明確說明會主動清空toolContext——否則 subagent 主體內、首個內部 tool 調用之前觸發的 hook如 SubagentStart會錯誤地掛到外層 AGENT tool span 上。全程沒有任何enterWith與文檔用context.with()替代enterWith()的建議一致。記憶管理上fork/background這類可能運行數小時的調用獲得 4 小時長 TTLLONG_TTL_SUBAGENT_KINDSsession-tracing.ts其余 span 默認 30 分鐘為tool.blocked_on_user的用戶思考時間選取。注釋坦陳一個已知限制長 TTL 只作用于 subagent span 本身其內部子 span 仍用 30 分鐘默認值長時間后臺 agent 的 trace 可能出現前段子 span 被清掃的空洞留作后續工作項。6.7 內存與生命周期管理文檔現狀表中提到的 AsyncLocalStorage WeakRef TTL cleanup 在當前源碼中完整可見activeSpansWeakRef 表與strongSpans防 GC 的強引用表雙表管理session-tracing.tssweepStaleSpans每 60 秒巡檢一次對被 TTL 清掃的 span 打上qwen-code.span.ttl_expired哨兵屬性并按類型補規范屬性如 blocked_on_user 補decision: aborted、subagent 補terminate_reason: ttl_swept使后端能把被安全網回收與主動結束但未設狀態區分開session-tracing.ts。所有 span 的文本屬性經truncateSpanError截斷默認 1024 字符、防孤立代理項、剝離 ANSI、脫敏 URL 憑據session-tracing.ts避免超大字段導致后端丟棄整個 span。6.8 修復后的 trace 樹形態從當前源碼結構看文檔理想 trace 樹已達成并略有演化每個 interaction 現在是獨立的 trace rootstartInteractionSpan顯式傳入ROOT_CONTEXTsession-tracing.ts舊的 session root 機制已標記deprecated見 tracer.ts跨輪次關聯改由session.idspan 屬性完成。這樣單條 trace 保持有界、可在 ARMS / Jaeger 中正常渲染qwen-code.interaction (trace root) qwen-code.llm_request qwen-code.tool (Bash) qwen-code.tool.blocked_on_user (decision, source, duration_ms) qwen-code.hook (PreToolUse) qwen-code.tool.execution qwen-code.hook (PostToolUse) qwen-code.tool (AGENT) qwen-code.subagent (foreground: 子節點 / fork|background: linked root) qwen-code.llm_request qwen-code.tool qwen-code.tool.execution與文檔理想的差異在于subagent 下不再嵌套一層新的interaction而是 subagent span 直接承載內部的 llm_request / tool / hook 子樹——這與startSubagentSpan的設計注釋Hosts the LLM/tool/hook subtree emitted by the subagent一致語義上等價且更簡潔。7. 小結這份設計文檔的價值《Workflow 級 Span 粒度不足分析》展示了一種可復用的排障方法論先盤點再補缺口——用組件 × 位置 × 說明表格固化現狀基線再列出缺失項 × 影響對照表讓每個缺口都有可感知的排障代價如無法區分審批等待 vs 工具執行耗時定位到架構級根因——問題不在個別 helper 缺失而在兩套斷裂的 span 創建路徑導致 parent 解析分叉對照外部實現做逐項復用評估——對每項機制標注可復用程度 / 改動量 / 優先級并誠實標注雙方都不完整、不建議照搬的部分subagent tree給出獨立設計路線修復方案可對照源碼驗收——從當前倉庫看typed helper 統一創建路徑、toolContextALS、方案 A 的前移 tool span、hook span 接線、context.with()化的 subagent 隔離均已落地文檔中的 P0/P1/P2 路線與源碼注釋中的 Phase 標記一一對應。對于任何構建 agent 式產品的團隊這套span 詞匯表 顯式 parent 解析 按階段建模的思路都能直接借鑒trace 的價值不在于 span 數量而在于能否回答這輪慢在等用戶、hook還是 tool 真執行這類排障問題。【免費下載鏈接】qwen-codeAn open-source AI coding agent that lives in your terminal.項目地址: https://gitcode.com/GitHub_Trending/qw/qwen-code創作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考 qwen-code Workflow 級 Trace Span 缺口分析：用雙 ALS 父級解析構建 Agent 執行軌跡樹
qwen-code Workflow 級 Trace Span 缺口分析用雙 ALS 父級解析構建 Agent 執行軌跡樹【免費下載鏈接】qwen-codeAn open-source AI coding agent that lives in your terminal.項目地址: https://gitcode.com/GitHub_Trending/qw/qwen-code本文以 qwen-code 的設計文檔《Workflow 級 Span 粒度不足分析》為主線剖析一個 AI coding agent 在 OpenTelemetry 接入中有 tracing 主干、卻沒有 workflow 階段邊界的典型困境審批等待、hook、subagent 等階段如何編碼成 trace 樹中的獨立節點。讀完本文你將掌握基于 AsyncLocalStorageALS的 span 父子掛載模型、五種 workflow span 缺口及其修復方案并能對照當前倉庫源碼驗證這些建議的實際落地方式。1. 背景從有 tracing 主干到編碼 workflow 階段邊界該分析文檔基于 2026-05-13 對 qwen-code origin/main 的復核。當時項目已具備 tracing 基礎設施各組件分布如下組件位置說明Span 類型定義session-tracing.tsinteraction、llm_request、tool、tool.executionTracer 工具tracer.tssession root context、withSpan、startSpanWithContext交互入口client.ts頂層交互顯式啟動interactionspan生命周期管理—AsyncLocalStorage WeakRef TTL cleanup當時的 runtime 中穩定接入的主要是兩類 generic spanapi.generateContent/api.generateContentStreamtool.toolName文檔的核心結論是已進入有 tracing 主干階段但尚未把 agent workflow 的階段邊界完整編碼進 trace 樹。作為對照文檔引用了外部項目 claude-code 在src/utils/telemetry/sessionTracing.ts中已實現的六類 spaninteraction、llm_request、tool、tool.blocked_on_user、tool.execution、hook此引用來自原文檔的外部對比非本倉庫文件。2. 五大缺口workflow 階段在哪里隱形缺失 span / 機制影響permission_wait/blocked_on_userspan無法區分審批等待 vs 工具執行耗時hookspanhook 耗時被折疊進 tool span定位邊界不清subagentroot spansubagent 內部 llm/tool 調用無法形成 trace 子樹tool.execution真實接線helper 已定義但主鏈路未調用穩定的 parent-child wiringspans 多為 session root 下的 sibling 而非層級樹2.1 用戶審批等待不在 trace 中工具調用等待審批時狀態遷移路徑為awaiting_approval→scheduled→ 執行。等待用戶確認只是狀態遷移不是 trace 節點trace 上看不到審批等待耗時工具慢時無法區分是卡在等用戶還是工具本身執行慢。2.2 Hook 有事件記錄但沒有獨立 spanPre/Post hook 執行后產出HookCallEvent走logHookCall()記錄日志但不建立獨立 OTel span。后果是hook 變慢時表現為外層 tool span 變慢hook 失敗時表現為tool 失敗trace 無法回答時間花在 hook 還是 tool.execution 上。2.3 Subagent 是 log/metric 而非 trace subtreesubagent 啟動/完成時記錄SubagentExecutionEvent事件名定義見 constants.ts并進入 log/metric但沒有形成顯式 span 子樹。能統計哪個 subagent 跑過但不能順著 trace 看這個 subagent 觸發了哪些 llm/tool 調用并發 subagent 場景下因果鏈不清。2.4 tool.execution helper 已定義但未接入主鏈路復核時session-tracing.ts中已有startToolExecutionSpan()/endToolExecutionSpan()但非測試代碼中未見調用點。當時的實際 trace 樹與理想 trace 樹對比如下實際session-root interaction api.generateContent tool.Bash subagent_execution (log/metric) hook_call (event/QwenLogger)理想interaction llm_request tool tool.blocked_on_user hook(pre) tool.execution hook(post) subagent interaction llm_request tool2.5 Parent-child wiring 不夠穩定interaction span 已存在但很多運行中的 spans 掛在 session root 下作為 sibling而不是 interaction 的子節點。調用樹偏平、節點間因果關系不直觀從一個用戶輪次追到內部 llm/tool/hook/subagent 的體驗不連續。在 Jaeger / Tempo / ARMS 等后端上這樣的樹比層級清晰的實現更難讀。3. 根因剖析兩套斷裂的 span 創建路徑這是文檔指出的當前最關鍵的架構問題層文件用法parent 解析session-tracing 層session-tracing.tsstartInteractionSpan/startLLMRequestSpan/startToolSpan/startToolExecutionSpan顯式從interactionContextALS 取 parenttracer 層tracer.tswithSpan/startSpanWithContext從context.active()取 parentfallback 到 session rootruntime 實際調用情況復核時點startInteractionSpan→已接入client.ts寫入interactionContextALSstartLLMRequestSpan/endLLMRequestSpan→未接入runtime 用的是withSpan(api.generateContent, ...)在loggingContentGenerator.tsstartToolSpan/endToolSpan→未接入runtime 用的是withSpan(tool.${name}, ...)在coreToolScheduler.tsstartToolExecutionSpan/endToolExecutionSpan→未接入。從源碼看withSpan的父級解析函數getParentContext()只返回context.active()tracer.ts它完全不讀取interactionContextALS找不到活躍 span 時回退到 session root context。因此 interaction span 與 LLM/tool spans 變成了 session root 下的平級 sibling而不是 parent-child 樹session-root ├── interaction (來自 session-tracing, 寫入了 interactionContext ALS) ├── api.generateContent (來自 withSpan, 不讀 interactionContext → 掛到 session root) ├── tool.Bash (來自 withSpan, 同上) └── tool.Read (來自 withSpan, 同上)而參照實現 claude-code 中只有一套 span 創建路徑sessionTracing.ts所有 span 都走同一套 ALS → OTel context 轉換邏輯所以樹是完整的。4. 參照模型claude-code 的雙 ALS span 管理文檔對 claude-code 源碼做了深度對比其 tracing 架構可概括為interactionContext (ALS) toolContext (ALS) │ │ ▼ ▼ ┌─────────────────────┐ ┌─────────────────────┐ │ interaction span │ │ tool span │ │ (session root) │ │ (child of intxn) │ └─────────────────────┘ └─────────────────────┘ ▲ parent of ▲ parent of │ │ ┌───────┴───────┐ ┌──────────┼──────────┐ │ │ │ │ │ llm_request tool blocked execution hook _on_user核心機制機制實現雙 ALSinteractionContext存當前 interaction spantoolContext存當前 tool spanparent 解析每種 span 類型硬編碼從哪個 ALS 取 parentllm_request/tool取interactionContextblocked_on_user/execution/hook取toolContexthook有 fallback 到interactionContext生命周期enterWith 注入 → span 運行 → enterWith(undefined) 清除查找 span非 ALS 存儲的 span如 blocked_on_user通過activeSpansMap 按span.type反查內存管理ALS 持有的 span 用 WeakRef非 ALS 持有的 span 用 strongRef 防 GCTTL 30min 自動清理tool span 完整生命周期toolExecution.tsstartToolSpan(name, attrs) // → toolContext.enterWith(spanCtx) startToolBlockedOnUserSpan() // → parent toolContext.getStore() [permission resolution / user prompt] endToolBlockedOnUserSpan(decision, source) startToolExecutionSpan() // → parent toolContext.getStore() [tool.call()] endToolExecutionSpan({ success }) endToolSpan(result) // → toolContext.enterWith(undefined)hook spanhooks.tsstartHookSpan(event, name, count, defs) // → parent toolContext ?? interactionContext [parallel hook execution] endHookSpan(span, { success, blocking, ... })5. 逐項復用方案5.1 雙 ALS 顯式 parent 解析核心修復維度claude-codeqwen-code復核時ALS 數量2interactionContexttoolContext1interactionContext無toolContextparent 解析每種 span 類型顯式指定從哪個 ALS 取 parentwithSpan統一走context.active()context 注入trace.setSpan(otelContext.active(), parentCtx.span)withSpan內部由startActiveSpan隱式注入qwen-code 的session-tracing.ts當時已經實現了與 claude-code幾乎相同的 parent 解析模式// qwen-code session-tracing.ts (已有但未用) export function startLLMRequestSpan(model, promptId): Span { const parentCtx interactionContext.getStore(); const ctx parentCtx ? trace.setSpan(otelContext.active(), parentCtx.span) : otelContext.active(); // ... }核心修復路徑廢棄 runtime 中的withSpan(api.*)/withSpan(tool.*)調用改為調用 session-tracing 的 typed helpers。不需要重寫 session-tracing 層——它的 API 已經就緒。需要新增的只有增加toolContextALS仿 claude-code增加blocked_on_user和hookspan 類型及 helper 函數。5.2 tool.blocked_on_user適配審批流差異維度claude-codeqwen-code審批位置在toolExecution.ts內tool span 內部在coreToolScheduler._schedule()內tool span 之前審批模式同步等待resolveHookPermissionDecision()狀態機驅動validating→awaiting_approval→scheduled→executingspan 覆蓋范圍tool span 包含 blocked executiontool spanwithSpan只包含 execution從executeSingleToolCall開始關鍵差異qwen-code 的executeSingleToolCall入口檢查toolCall.status ! scheduled才繼續——調用到這里時審批已經完成tool span 的withSpan包不住審批等待。文檔給出兩種適配方案方案 A — 前移 tool span 起點推薦將startToolSpan調用從executeSingleToolCall移到_schedule中審批檢查之前使 tool span 覆蓋完整生命周期。在進入awaiting_approval狀態時startToolBlockedOnUserSpan在審批完成scheduled時endToolBlockedOnUserSpan_schedule(): startToolSpan(name) // ← 新增 startToolBlockedOnUserSpan() // ← 新增進入 awaiting_approval 時 [狀態機等待] endToolBlockedOnUserSpan(decision) // ← 新增進入 scheduled 時 executeSingleToolCall(): startToolExecutionSpan() // ← 接入已有 helper [hook execute] endToolExecutionSpan() endToolSpan() // ← 需要在 finally 中方案 B — 保持 tool span 位置不變單獨追蹤審批在_schedule中獨立創建approval_waitspan不作為 tool 的 child掛到 interaction 下。好處是改動更小壞處是與參照模型不一致、trace 樹可讀性差。建議采用方案 A原因與參照實現的 trace 樹結構一致trace 上一個 tool 節點就能看到等了多久 執行了多久狀態機驅動的特性只影響 span start/end 的觸發時機不影響 parent-child 建模。5.3 hook span可直接復用維度claude-codeqwen-codehook 執行入口executeHooks()inhooks.tsfirePreToolUseHook/firePostToolUseHookviahookEventHandler.ts現有記錄方式OTel span Perfetto spanHookCallEvent→QwenLogger無 OTelparenttoolContext ?? interactionContext—復用方案在session-tracing.ts新增startHookSpan/endHookSpanparent toolContext ?? interactionContext在coreToolScheduler.ts的executeSingleToolCall中 pre/post hook 調用前后分別 start/end hook span保留現有logHookCall事件記錄兩套并行不互斥。改動量低不影響現有 hook 邏輯。5.4 tool.execution已有 helper只需接線startToolExecutionSpan()/endToolExecutionSpan()已經完整實現只需在executeSingleToolCall中調用// coreToolScheduler.ts executeSingleToolCall 內部 const toolSpan startToolSpan(toolName, attrs); // ... hook pre ... const execSpan startToolExecutionSpan(toolSpan); try { // ... invocation.execute() ... endToolExecutionSpan(execSpan, { success: true }); } catch (e) { endToolExecutionSpan(execSpan, { success: false, error: e.message }); } // ... hook post ... endToolSpan(toolSpan);風格差異說明qwen-code 的startToolExecutionSpan原設計接收顯式parentToolSpan參數而參照實現從toolContextALS 隱式獲取。引入toolContextALS 后可統一為隱式獲取。5.5 subagent trace tree不建議直接復用維度claude-codeqwen-codeOTel trace 傳播無— subagent 的 interaction 是新 root無— subagent 無顯式 trace 傳播身份關聯Perfetto metadataagent process/threadteammateContextStorageALSsubagentNameContextALS SubagentExecutionEvent并發隔離OTel ALS 有泄漏風險enterWith是進程級并發 subagent 會互覆蓋同樣的風險claude-code 在 subagent OTel tracing 上自己也沒解決好interactionContext.enterWith()是進程級的并發 subagent 會覆蓋彼此的 ALS 值真正的 agent 層級樹只存在于 Perfetto一個 feature-flagged 的內部系統不在 OTel 中。因此建議短期沿用現有的subagentNameContext 事件日志方案中期在 subagent 啟動時創建一個subagentspanparent 當前 toolContext并用context.with()而非enterWith()來隔離并發 subagent 的 OTel context。這是需要獨立設計的工作項不建議直接照搬。5.6 LLM request span路徑明確復核時點在loggingContentGenerator.ts中用withSpan(api.generateContent, ...)和startSpanWithContext(api.generateContentStream, ...)改為調用startLLMRequestSpan/endLLMRequestSpansession-tracing 層已有實現即可。streaming 場景需注意startLLMRequestSpan返回Span對象需要手動傳入endLLMRequestSpan(span, metadata)終結——這與startSpanWithContext的手動管理模式兼容。5.7 復用總結與實施順序改造項可復用程度改動量優先級統一 span 創建路徑廢棄 runtimewithSpan用 session-tracing helpers核心修復— 解決 parent-child 斷裂中約 5 個調用點P0新增toolContextALS直接照搬參照模式低session-tracing.ts 內部P0tool.blocked_on_user span方案 A 需適配狀態機中_scheduleexecuteSingleToolCall協調P1tool.execution 接線helper 已有只需調用低executeSingleToolCall內 3 行P1hook span新增 helper 調用點低P1LLM request span 切換替換 withSpan 為 typed helper低2 個調用點P1subagent trace tree不建議直接復用— 需獨立設計高P2Phase 1 — 修復 trace 樹結構 (P0) ├── 1a. session-tracing.ts 新增 toolContext ALS blocked_on_user / hook span helpers ├── 1b. loggingContentGenerator.ts: withSpan → startLLMRequestSpan/endLLMRequestSpan └── 1c. coreToolScheduler.ts: withSpan → startToolSpan/endToolSpan Phase 2 — 補齊 workflow span (P1) ├── 2a. coreToolScheduler._schedule: blocked_on_user span 接入 ├── 2b. coreToolScheduler.executeSingleToolCall: tool.execution span 接入 └── 2c. hook pre/post 調用處: hook span 接入 Phase 3 — Subagent trace tree (P2) ├── 3a. 設計 context.with() 隔離方案替代 enterWith ├── 3b. subagent 啟動時創建 subagent root span └── 3c. 并發 subagent 場景驗證6. 當前倉庫源碼驗證缺口如何被逐一修復設計文檔是 2026-05 的快照而當前倉庫源碼顯示上述修復項已基本落地源碼注釋中引用了 issue #3731 的 Phase 2/3 等推進標記。本節以當前源碼為證據說明每項建議的實際實現形態。6.1 Span 詞匯表七類 workflow span 全部成為一等公民constants.ts 定義了完整的 span 名常量常量span 名語義SPAN_INTERACTIONqwen-code.interaction一次用戶輪次trace rootSPAN_LLM_REQUESTqwen-code.llm_request單次 LLM 請求SPAN_TOOLqwen-code.tool工具調用完整生命周期含審批等待SPAN_TOOL_EXECUTIONqwen-code.tool.execution工具實際執行階段SPAN_TOOL_BLOCKED_ON_USERqwen-code.tool.blocked_on_userawaiting_approval等待用戶的時間SPAN_HOOKqwen-code.hook單個 hook 觸發點SPAN_SUBAGENTqwen-code.subagent單次 subagent 調用同時 constants.ts 維護了tool.failure_kind詞匯表cancelled、pre_hook_blocked、invocation_guard_denied、timeout、plan_mode_blocked等注釋明確要求寫入點與文檔不能漂移——即 span 語義在 coreToolScheduler、session-tracing 與文檔三方共享同一常量源。6.2 雙 ALS實為三 ALS與 parent 優先級鏈session-tracing.ts 中現有三個 AsyncLocalStorageconst interactionContext new AsyncLocalStorageSpanContext | undefined(); const toolContext new AsyncLocalStorageSpanContext | undefined(); // 注釋子 span 創建時優先讀取 subagentContext // 否則前臺 subagent 的子 span 會被 re-parent 回外層 interaction const subagentContext new AsyncLocalStorageSpanContext | undefined();startLLMRequestSpanWithContext與startToolSpan的 parent 解析采用統一優先級鏈session-tracing.tsconst parentCtx subagentContext.getStore() ?? toolContext.getStore() ?? interactionParentCtx; const ctx resolveGenAiParentContext(parentCtx);這正是文檔 5.1 節雙 ALS 顯式 parent 解析建議的實現并額外增加了subagentContext一層解決了subagent 內部 LLM span 逃逸回外層 interaction的問題。值得注意的是resolveGenAiParentContext的防御邏輯session-tracing.ts當沒有任何 ALS 屬主時強制返回ROOT_CONTEXT防止錯誤 prompt 的 span 被錯誤地掛到活躍 interaction 之下。6.3 方案 A 落地tool span 前移到 validating 階段文檔推薦的方案 A 在 coreToolScheduler.ts 中按注釋原文實現// Open the tool span as soon as the call is validated. This covers // validating → awaiting_approval → executing in one span (#3731 // Phase 2). Every cancel/error path below — and the existing // success path in executeSingleToolCall — must call // finalizeToolSpan(callId, ...) to avoid leaking spans. const toolSpan startToolSpan(canonicalName, { tool.call_id: reqInfo.callId, ... }, ...);即 tool span 從validating狀態就打開一個 span 覆蓋validating → awaiting_approval → executing完整生命周期span 句柄存入this.toolSpansMap 以便跨狀態機階段終結。審批等待階段則顯式掛 blocked_on_user 子 spancoreToolScheduler.tsthis.setStatusInternal(callId, awaiting_approval, confirmationDetails); // blocked_on_user span as a child of the tool span const blockedSpan startToolBlockedOnUserSpan(toolSpan, { tool_name: canonicalName, call_id: callId, });startToolBlockedOnUserSpan的父級通過顯式toolSpan參數解析session-tracing.ts注釋明確說明原因該 span 啟動于工具主體進入runInToolSpanContext之前此時toolContext.getStore()為空同時顯式傳 span 對象也規避了參照實現中按 type 反查最后一個 span在并發下的競態問題。endToolBlockedOnUserSpan記錄decisionproceed_once/proceed_always/cancel/aborted/auto_approved/error見 session-tracing.ts與sourcecli/ide/hook/auto/system兩個規范屬性且 span 狀態保持 UNSET——等用戶既非 OK 也非 ERROR決策屬性才是規范信號。6.4 tool.execution 與 hook span 接線tool.executioncoreToolScheduler.ts 與 #L5305 兩處startToolExecutionSpan({ toolName, callId })對應文檔 5.4 節只需 3 行接線的預測。helper 內部從toolContext.getStore()取父級session-tracing.ts在runInToolSpanContext外調用時會打 warning 并回退到活躍 OTel span。hook spancoreToolScheduler.ts 中startHookSpan(opts)與endHookSpan(hookSpan, endMeta)成對出現。當前HookEvent類型比文檔復核時更豐富覆蓋PreToolUse/PostToolUse/PostToolUseFailure/PostToolBatchsession-tracing.tsstartHookSpan的 parent 優先級為toolContext → subagentContext → interactionContextsession-tracing.ts在 subagent 內部、tool 之外觸發的 hook 也能正確掛到 subagent 下。并發安全runInToolSpanContextsession-tracing.ts刻意用toolContext.run()otelContext.with()而非enterWith()把上下文作用域限定在單個異步調用樹內——這直接回應了文檔 5.5 節對進程級enterWith在并發下互相覆蓋的擔憂。6.5 LLM request span 切換到 typed helperloggingContentGenerator.ts 與非流式/流式路徑#L563均已改為startLLMRequestSpanWithContext/endLLMRequestSpan測試文件 loggingContentGenerator.test.ts 對 token 計數、緩存命中、重試上下文attempt/requestSetupMs/retryTotalDelayMs、流空閑超時等終結路徑均有斷言。endLLMRequestSpan除寫入gen_ai.usage.*、ttft_ms、finish_reason等屬性外還派生sampling_ms與output_tokens_per_second并按 Phase 4c 記錄分階段直方圖session-tracing.ts。6.6 Subagent trace treePhase 3 的獨立設計文檔 5.5 節建議獨立設計、用context.with()隔離并發當前實現源碼注釋標記#3731 Phase 3給出了具體答案startSubagentSpansession-tracing.ts區分foreground/fork/background三種調用形態foreground作為當前活躍 span通常 AGENT tool span的子節點繼承 traceIdfork/background則創建linked-root span——root: true強制新 traceId同時用 OTelLink指向發起方 span注釋引用了 OTel 規范對長耗時異步操作使用 Link 的建議理由正是 fire-and-forget subagent 運行數分鐘到數小時若掛在父 trace 下會超出多個后端的 trace 容量上限。runInSubagentSpanContextsession-tracing.ts是并發隔離的關鍵它用subagentContext.run()toolContext.run(undefined, ...)otelContext.with()組合包裹 subagent 主體注釋明確說明會主動清空toolContext——否則 subagent 主體內、首個內部 tool 調用之前觸發的 hook如 SubagentStart會錯誤地掛到外層 AGENT tool span 上。全程沒有任何enterWith與文檔用context.with()替代enterWith()的建議一致。記憶管理上fork/background這類可能運行數小時的調用獲得 4 小時長 TTLLONG_TTL_SUBAGENT_KINDSsession-tracing.ts其余 span 默認 30 分鐘為tool.blocked_on_user的用戶思考時間選取。注釋坦陳一個已知限制長 TTL 只作用于 subagent span 本身其內部子 span 仍用 30 分鐘默認值長時間后臺 agent 的 trace 可能出現前段子 span 被清掃的空洞留作后續工作項。6.7 內存與生命周期管理文檔現狀表中提到的 AsyncLocalStorage WeakRef TTL cleanup 在當前源碼中完整可見activeSpansWeakRef 表與strongSpans防 GC 的強引用表雙表管理session-tracing.tssweepStaleSpans每 60 秒巡檢一次對被 TTL 清掃的 span 打上qwen-code.span.ttl_expired哨兵屬性并按類型補規范屬性如 blocked_on_user 補decision: aborted、subagent 補terminate_reason: ttl_swept使后端能把被安全網回收與主動結束但未設狀態區分開session-tracing.ts。所有 span 的文本屬性經truncateSpanError截斷默認 1024 字符、防孤立代理項、剝離 ANSI、脫敏 URL 憑據session-tracing.ts避免超大字段導致后端丟棄整個 span。6.8 修復后的 trace 樹形態從當前源碼結構看文檔理想 trace 樹已達成并略有演化每個 interaction 現在是獨立的 trace rootstartInteractionSpan顯式傳入ROOT_CONTEXTsession-tracing.ts舊的 session root 機制已標記deprecated見 tracer.ts跨輪次關聯改由session.idspan 屬性完成。這樣單條 trace 保持有界、可在 ARMS / Jaeger 中正常渲染qwen-code.interaction (trace root) qwen-code.llm_request qwen-code.tool (Bash) qwen-code.tool.blocked_on_user (decision, source, duration_ms) qwen-code.hook (PreToolUse) qwen-code.tool.execution qwen-code.hook (PostToolUse) qwen-code.tool (AGENT) qwen-code.subagent (foreground: 子節點 / fork|background: linked root) qwen-code.llm_request qwen-code.tool qwen-code.tool.execution與文檔理想的差異在于subagent 下不再嵌套一層新的interaction而是 subagent span 直接承載內部的 llm_request / tool / hook 子樹——這與startSubagentSpan的設計注釋Hosts the LLM/tool/hook subtree emitted by the subagent一致語義上等價且更簡潔。7. 小結這份設計文檔的價值《Workflow 級 Span 粒度不足分析》展示了一種可復用的排障方法論先盤點再補缺口——用組件 × 位置 × 說明表格固化現狀基線再列出缺失項 × 影響對照表讓每個缺口都有可感知的排障代價如無法區分審批等待 vs 工具執行耗時定位到架構級根因——問題不在個別 helper 缺失而在兩套斷裂的 span 創建路徑導致 parent 解析分叉對照外部實現做逐項復用評估——對每項機制標注可復用程度 / 改動量 / 優先級并誠實標注雙方都不完整、不建議照搬的部分subagent tree給出獨立設計路線修復方案可對照源碼驗收——從當前倉庫看typed helper 統一創建路徑、toolContextALS、方案 A 的前移 tool span、hook span 接線、context.with()化的 subagent 隔離均已落地文檔中的 P0/P1/P2 路線與源碼注釋中的 Phase 標記一一對應。對于任何構建 agent 式產品的團隊這套span 詞匯表 顯式 parent 解析 按階段建模的思路都能直接借鑒trace 的價值不在于 span 數量而在于能否回答這輪慢在等用戶、hook還是 tool 真執行這類排障問題。【免費下載鏈接】qwen-codeAn open-source AI coding agent that lives in your terminal.項目地址: https://gitcode.com/GitHub_Trending/qw/qwen-code創作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考