Qwen Code Web Shell 监控任务详情面板设计：零额外轮询的 Monitor 右侧面板实现

Qwen Code Web Shell 监控任务详情面板设计零额外轮询的 Monitor 右侧面板实现【免费下载链接】qwen-codeAn open-source AI coding agent that lives in your terminal.项目地址: https://gitcode.com/GitHub_Trending/qw/qwen-code本文基于 Qwen Codeqwen-code仓库中的设计文档 web-shell-monitor-details.md讲解 Web Shell 如何让用户从右侧背景任务列表中直接打开 monitor监控任务详情为什么 monitor 工具调用被视为背景任务活动、session_monitor_tool_correlation能力标签如何门控从转录点击工具跳到面板的行为、以及右侧面板如何完全复用既有的背景任务轮询来保持快照新鲜而不再增加一条独立的轮询链路。读完本文你可以理解该功能的完整设计约定、生命周期规则以及 App.tsx 中对应的关键实现面板 tab 的键控与快照合并、工具调用到 monitor 任务的解析、轮询唤醒与 tab 同步。目标不新增轮询循环也能实时查看 monitor 详情设计文档的 Goal 部分给出了一个很明确的产品诉求Let users open a monitor task from the background-tasks list in the Web Shell right panel and keep its details current without adding another polling loop.即让用户能够从 Web Shell 右侧面板的背景任务列表中打开一个 monitor 任务并让其详情保持最新——同时不引入任何新的轮询循环。Web Shell 中已经存在一套背景任务background tasks状态条与轮询机制状态栏status bar上的任务入口是 monitor 的发现面当会话中出现 monitor 工具调用时既有的任务轮询会被启动。这份设计的核心思路就是寄生在这条已有的轮询链路上右侧面板不自己发请求、不自己定时器而是订阅/复用既有轮询拿到的任务快照来更新已打开的 monitor tab。设计约定逐条解析下面按设计文档 Design 章节的条目展开每一条都尽量对应到仓库中的实际实现。1. 状态栏任务入口是 monitor 的发现面文档约定Keep the status-bar task entry as the monitor discovery surface。也就是说用户看到这里有一个 monitor 在跑的入口依然是状态栏上的任务徽标右侧详情面板是它的延伸视图而不是又一个并列的发现渠道。2. monitor 工具调用被当作背景任务活动文档约定Treat a monitor tool call as background-task activity so the existing task polling starts when a monitor is created。这意味着 monitor 的创建动作会触发既有的任务轮询启动逻辑——一旦 monitor 出现轮询就开始后续 monitor 快照就天然有来源右侧面板才有数据可用。3. 从背景任务列表打开 monitor关对话框、开专属右侧 tab文档约定在嵌入式背景任务列表中打开某个 monitor 时会关闭该对话框并打开一个专属的右侧面板 tab。该行为对应的实现是 openMonitorPanel它构造一个kind: monitor的ArtifactPanelTab把 tab 写入右侧 Artifact Panel 的 tab 列表、设为活动 tab并在面板首次打开时给一个默认宽度。4. 从转录点击 monitor 工具按 tool-call ID 解析任务文档约定在转录transcript中点击一个 monitor 工具时客户端通过发起该 monitor 的 tool-call ID去解析出对应的任务并打开同一个右侧 tab对于较旧的历史快照则回退到工具结果中内嵌的 monitor ID。这一链路的客户端入口是 openMonitorPanelFromTool流程如下可直接从源码读出捕获会话所有权sessionOwnerGuard.capture()防止会话切换导致把结果写错会话调用sessionActions.getTasks()拉取当前任务快照并校验会话未变snapshot.sessionId ! sessionId则放弃用findMonitorTaskForTool(snapshot.tasks, tool)在任务列表中解析出对应的 monitor 任务解析不到就返回false解析成功后递增backgroundTasksRefreshTrigger即唤醒轮询见下文第 7 条再调用openMonitorPanel(task)打开面板。点击入口本身通过 MonitorDetailsContext 注入MonitorDetailsProvider向子树暴露一个onOpen(tool: ACPToolCall) PromisebooleanChatPane.tsx 将其传给 ProviderToolGroup.tsx 中的openMonitorDetailsOnce则负责工具行的点击处理。5. 能力门控session_monitor_tool_correlation文档约定Gate transcript-to-panel navigation on thesession_monitor_tool_correlationcapability. Older daemons retain the original inline tool expansion.即从转录跳到面板这一新行为必须受 daemon 能力标签门控不支持该标签的旧 daemon 保持原来的行内工具展开inline tool expansion行为不变。该标签在两侧都有对应实现daemon 侧capabilities.ts 的SERVE_CAPABILITY_REGISTRY中注册了session_monitor_tool_correlation: { since: v1 }。它是一个基线标签不在CONDITIONAL_SERVE_FEATURES的谓词表中因此一旦 daemon 实现即无条件广告。客户端侧constants/sessions.ts 定义了SESSION_MONITOR_TOOL_CORRELATION_FEATURE session_monitor_tool_correlation供 Web Shell 各表面统一做能力预检避免在旧 daemon 上触发会失败的跳转。测试用例也在能力开关上做了覆盖App.test.tsx 中多处通过mockConnection.capabilities.features [session_monitor_tool_correlation]构造新 daemon场景并验证了MonitorDetailsProvider的onOpen测试中取testState.latestMonitorDetailsOnOpen能正确解析并打开面板。6. 解析失败时回退到行内展开而不是报错文档约定如果一个支持该能力的 daemon 也无法把被点击的工具解析到某个 monitor 快照例如任务已被清理客户端应回退到行内展开行为而不是把错误抛给用户。从 openMonitorPanelFromTool 的实现看这个约定体现得很直接会话校验失败、findMonitorTaskForTool返回undefined、或getTasks()抛错三条路径全部return false——调用方拿到false后就走既有的行内展开逻辑全程无用户可见错误。7. 打开 monitor 时唤醒既有轮询保证恢复会话保持活跃文档约定Wake the existing background-task poller when a monitor opens so resumed sessions stay live even when the originating tool call is outside the loaded transcript window。场景是用户恢复resume一个旧会话发起 monitor 的那次工具调用可能已经不在当前加载的转录窗口内因此工具调用出现时启动轮询这条路径可能没有机会触发此时用户手动打开 monitor 面板就必须主动把既有轮询唤醒一次。实现上openMonitorPanelFromTool在打开面板前执行setBackgroundTasksRefreshTrigger((value) value 1)正是这个轻推动作。8. 右侧面板不独立拉取从既有轮询同步 tab文档约定Store the latest monitor snapshot in the tab. While the existing background-task hook is polling, synchronize matching open tabs from those snapshots. The right panel does not fetch or poll independently.即最新 monitor 快照保存在 tab 自身上当既有背景任务 hook 在轮询时把匹配的已打开 tab 从轮询拿到的快照中同步过去右侧面板自己不发请求、不跑定时器。对应实现在 App.tsx 的同步 effect它监听backgroundTasks由既有轮询产出且只保留 live 状态、不掺入项目保留的历史 workflow把其中kind monitor的任务按task.id建索引然后遍历 Artifact Panel 中kind monitor的 tab并跳过属于其他会话的 tab用mergeMonitorTaskSnapshot(tab.task, task)合并快照。由于openMonitorPanel同样调用这个合并函数更新已有 tabApp.tsx#L5290-L5301整条数据链路收敛为一条既有轮询 → 背景任务列表 → tab 合并更新没有任何第二条轮询源这与 Goal 的不新增轮询循环完全一致。9. tab 按 monitor 任务 ID 键控重复打开即选中并刷新文档约定Key the tab by monitor task ID so reopening the same monitor selects and refreshes the existing tab。实现上 tab id 为monitor:task.id跨会话场景下为monitor:sourceSessionId:task.id见 openMonitorPanel。setArtifactPanelTabs的更新逻辑是id 已存在则就地替换/合并该 tab否则追加新 tab然后setActiveArtifactPanelTabId(tab.id)选中它。因此无论是从背景任务列表还是从转录工具行再次点击同一个 monitor行为都是选中已有 tab 并用新快照刷新而不是堆叠出重复 tab。快照合并规则本身值得单独看mergeMonitorTaskSnapshot 的实现只有一条规则——若当前 tab 中的快照已处于终态非running而新快照又是running则保留当前的终态快照否则采用新快照。这防止了晚到的过期running快照把面板上已经显示的已完成/已停止状态冲回去。测试 App.test.tsx 中expect(mergeMonitorTaskSnapshot(cancelled, running)).toBe(cancelled)与expect(mergeMonitorTaskSnapshot(running, cancelled)).toBe(cancelled)双向验证了这一点终态优先且终态对终态直接引用相等避免无谓的重渲染。10. 详情渲染沿用背景任务对话框的口径文档约定右侧面板渲染既有的任务详情呈现使运行时长、命令、事件计数、丢弃行数、退出码、失败/停止原因与背景任务对话框保持一致remain consistent with the background-tasks dialog并沿用 Subagent 详情的排版层级描述description在最前状态以 Badge 标签形式放在 Stop 操作旁边紧凑指标compact metrics在下命令用等宽monospace代码块展示。同时约定 Stop 操作在右侧面板详情中继续可用且取消后立即刷新其快照refresh its snapshot immediately after cancellation——这对应取消后马上拿到终态快照的需求确保面板不必等到下一轮轮询周期就显示停止结果。而 shell 与 agent 两类任务行保持其原有的行内详情行为Keep shell and agent rows on their existing inline-detail behavior只有 monitor 升级为右侧专属 tab改动范围被刻意收窄。生命周期跟随既有轮询的起止规则设计文档的 Lifecycle 章节对 monitor 的生命周期约定如下运行中active monitor 持续通过既有背景任务轮询更新即上述第 8 条的 tab 同步链路进入终态最终一次快照更新 tab轮询按既有规则停止对话框开关不破坏 tab关闭或重新打开背景任务对话框不会丢弃已经打开的 monitor tab——tab 的生命周期属于右侧 Artifact Panel与发现它的对话框解耦。结合第 6、9 条的回退与合并规则可以推断出完整的状态保障终态不会被旧快照回退、解析失败不会报错、轮询停止后面板上保留的就是最后一次终态快照。小结这份设计的取舍可以用三句话概括发现面留在状态栏数据面寄生在既有背景任务轮询上展示面复用右侧 Artifact Panel 的 tab 机制。它通过session_monitor_tool_correlation能力标签与旧 daemon 干净地划界用findMonitorTaskForTool 工具结果内嵌 monitor ID 的双路解析兼容新旧转录快照并用mergeMonitorTaskSnapshot的终态优先规则保证面板状态的单调性。对于需要理解 Qwen Code Web Shell 如何零额外轮询接入 daemon 快照的场景建议直接对照 设计文档、App.tsx 的 openMonitorPanel / openMonitorPanelFromTool / 同步 effect 与 能力注册表 阅读相关行为在 App.test.tsx 与 ChatPane.test.tsx 中均有能力开关维度的测试覆盖。【免费下载链接】qwen-codeAn open-source AI coding agent that lives in your terminal.项目地址: https://gitcode.com/GitHub_Trending/qw/qwen-code创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考