AI 消息状态 UI

• JSON Schema 校验（zod/ajv）与流式部分校验
• 类型守卫（type guard）与运行时校验的分工
• 校验失败的降级与重试策略

模型输出是"非结构化"的，结构化输出（Structured Output）通过 schema 约束生成格式，但运行时仍需二次校验。工程链路：定义 schema（zod 或 JSON Schema），服务端用结构化输出 API（如 OpenAI response_format、Vercel AI SDK 的 experimentalObject 或 streamObject），客户端对最终结果用 zod.parse 或 ajv 校验；校验前先用类型守卫（如 isArticle(obj)）做快速结构判断，再细校验字段。流式场景可用 partial-json 或 zod 的流式解析器在增量阶段就校验部分结构，尽早发现偏离。错误回退策略：校验失败视为生成失败，可设置最大重试次数（带修正提示重试）或降级为自由文本展示并提示；结构化失败不能静默进入业务逻辑，防止下游崩溃。工程上把 schema 作为前后端共享的单一事实来源（单一 spec），保证类型定义与校验规则一致。

核心是"schema 约束生成 + 运行时二次校验 + 失败回退"闭环，答出类型守卫与运行时校验的分工、流式部分校验与共享 schema，体现工程严谨性。

• 工具参数的 schema 化表单渲染
• 高风险工具的审批流程（用户确认）
• 执行中进度、结果展示与失败重试的状态机

工具调用 UI 是一条完整的状态流。参数阶段：根据工具参数 schema 动态渲染表单（字段、类型、必填校验），让用户可预览与修改模型生成的参数——这既是防误操作也是防注入；审批阶段：对高风险工具（删除、转账、发消息、写库）强制用户确认，展示参数摘要与影响说明，未审批不执行；执行中：显示进度（步骤、耗时、可取消），长任务用进度条或步骤化指示；结果阶段：展示结构化结果摘要，可折叠详情、支持"使用此结果"的后续操作；失败阶段：区分参数校验失败、执行失败与超时，给出错误信息与重试/修改参数再试的入口。整体用统一状态机（pending/approved/executing/success/error）驱动渲染，并记录完整审计日志。

按"参数 → 审批 → 执行 → 结果 → 失败"五阶段作答，突出高风险必须人工审批与状态机驱动，体现工具调用产品化的完整设计。

• 逐 token 增量渲染与 React 渲染模型的冲突
• useDeferredValue 延迟低优先级更新的机制
• Suspense 在流式数据场景的边界

逐 token 渲染意味着高频状态更新，直接 setState 会让 React 每帧重渲染整棵消息树，交互卡顿。useDeferredValue 把"最新增量文本"标记为低优先级值，React 在空闲时重渲染，保证输入框、按钮等紧急更新优先，可配合节流实现"渲染跟随但不抢主线程"。Suspense 用于声明式等待流式数据（如 await 的流式结果或 React 19 的 use() 读取 promise），在数据未就绪时显示 fallback；但其粒度是"整块等待"，不适合逐 token 的细粒度，实践中常把 Suspense 用于消息级加载、把增量渲染留给 deferred value/批处理。工程价值：把"紧急交互"与"非紧急渲染"分层调度，让流式输出流畅、不阻塞用户操作，是 React 并发特性在 AI UI 的核心应用。

答出 useDeferredValue 的优先级调度价值、Suspense 的粒度边界，以及"紧急交互优先、流式渲染让路"的分层思想，体现对 React 并发模型的理解。

• Markdown 与 MDX 的差异（组件化 vs 纯文档）
• 代码高亮方案（shiki、highlight.js、prism）与流式性能
• 渲染安全（不执行 MDX 中的任意代码）

Markdown 渲染用 react-markdown + remark/rehype 插件链，覆盖标题、表格、列表、代码块等；MDX 允许在文档中嵌入 React 组件（如交互式图表、可运行代码演示），适合文档站与组件示例，但 AI 生成内容不可信，不能直接执行 MDX 中 import/JSX 逻辑，需白名单组件映射（components 属性只渲染允许的组件）并禁用执行。代码高亮选型：shiki 基于 TextMate 语法质量最高（支持 VS Code 主题）、可流式缓存但体积大；highlight.js/prism 轻量但语法覆盖弱；流式场景用"节流 + 完成的代码块再高亮 + Worker 异步"避免阻塞。工程上：消息默认 Markdown 安全渲染，需要交互组件时用受控 MDX（组件白名单），高亮按内容量分档（短代码内联、长代码 Worker），并统一处理复制、行号与语言标签。

分"Markdown 基础渲染、MDX 组件化能力与安全边界、高亮方案与流式性能"三面作答，突出 AI 内容不可信背景下 MDX 的白名单约束。

• 分支对话的数据模型（消息树、fork 点）
• 编辑重试的 UI 状态与消息版本管理
• 重试幂等（requestId）与一致性（引用、用量）保证

分支对话把消息历史建模为树而非线性列表：每条消息可 fork 出多个回复，UI 上展示分支切换器（版本列表、差异对比），切换分支时保存各分支的上下文状态。编辑重试允许用户修改自己的消息或对 AI 回复"重新生成"：数据模型上给消息加 version/requestId，重试产生新版本并标记当前激活版本，其余版本折叠保留可回看。幂等保证：每次生成分配唯一 requestId，重试用新 requestId 但覆盖同一消息槽位（而非追加），服务端按 requestId 去重，防止重复计费与重复渲染；一致性：重试后该分支后续消息全部失效（级联失效标记），引用来源、token 用量、成本统计都绑定到具体版本，切换版本时一并切换。UI 上重试按钮在流式结束时可用，失败时显示"重试/编辑/放弃"三态。

从"树形数据模型、版本管理、幂等与级联失效"三个层面作答，突出 requestId 幂等与分支版本绑定状态的一致性问题。

• 引用锚点与来源块的渲染（citation 标识）
• 来源元数据（标题、链接、片段）与跳转
• 多轮对话中引用与上下文的关联

引用来源 UI 的核心是"可追溯"：模型输出中的引用用锚点标注（[1]、[2]），点击弹出或展开来源卡片，展示标题、URL、来源类型（网页/文档/图片）、相关原文片段，点击跳转到原文并高亮对应段落；来源列表常置于消息末尾或侧边栏，支持 hover 预览与键盘操作。工程要点：来源数据与文本增量同步返回（每个 citation 携带唯一 id），渲染时把 id 与锚点绑定；跳转前校验链接协议（只放行 http/https）并可能经中间页去重统计；多轮对话中，引用可能来自历史轮次，来源卡片要标明所属轮次与上下文，避免"引用歧义"；引用无法验证（无来源）时标注"无来源/低置信度"，配合 grounding/citation 元数据实现负责任的 AI 交互。

答出"锚点 + 来源卡片 + 原文跳转"的交互闭环，并延伸到来源类型、安全校验与多轮归属，体现溯源设计的完整性。

• use() 在 React 19 中读取 Promise/Context 的语义
• useChat 与 use() 协作的流式数据流
• Suspense 边界与流式更新的关系

React 19 的 use() 可以在组件中读取 Promise 或 Context，与 Suspense 配合实现声明式数据等待。工程协作模式：把 useChat 的消息状态或服务端流式数据暴露为 Promise 化的资源，通过 use() 读取并用 Suspense 包裹消息列表，消息未就绪时显示 fallback，就绪后渲染；同时 useChat 本身的增量更新是响应式的（useSyncExternalStore 风格），流式增量到达时重新渲染最新消息，use() 只负责"首次数据准备"的声明式等待，二者分工：use() 管"有无数据"，useChat 管"数据如何增长"。工程价值：减少手写 loading/error 分支（Suspense 边界统一处理）、提升代码可读性、与并发渲染（流式增量不阻塞交互）结合，构建声明式的 AI 消息渲染层。注意 use() 不能在循环/条件中调用，消息列表仍用常规组件接收流式更新。

讲清 use() 的"声明式等待"语义与 useChat 的"响应式增量"分工，以及 Suspense 边界与并发渲染的价值，避免把两者混为一谈。

• tiktoken 客户端（WASM）按模型计数的用法
• 发送前预检与到达阈值的处理
• 截断策略：裁剪最旧、摘要、保留系统提示

客户端用 tiktoken（WASM 版）按目标模型编码器（如 cl100k_base）对消息数组计数，考虑系统提示、历史消息与当前输入的总和。发送前预检：若总和超过窗口（如 128k），按策略截断再发送，避免服务端报错。截断策略按"保留优先级"排序：系统提示与最近 N 轮原始消息最高优先，中间轮次先裁剪工具调用细节、再对更旧轮次做摘要压缩，最后裁剪最旧消息；摘要可以用本地规则（要点提取）或调用模型压缩，且压缩版与本地全文并存（用户可展开回看）。注意：同一文本在不同模型编码器下 token 数不同，计数要用实际使用的模型；流式期间输入框也应实时显示"当前用量/上限"，到阈值时提示清理或自动降级为摘要模式。

答出"按模型编码器计数 → 发送前预检 → 分级截断（保系统提示与最近轮次、中间摘要）"的完整策略，并强调编码器随模型变化。

• 发送后立即上屏的占位消息与"生成中"指示
• 增量替换占位内容的衔接
• 中止、失败的中间态处理

乐观更新指用户发送后不等网络返回，立即把用户消息上屏并创建一条空的 assistant 占位消息，显示"生成中"状态（光标闪烁、骨架屏、转圈）。流式增量到达后，增量文本填充占位消息，占位期间 UI 标记 streaming 状态（可禁用重试、显示停止按钮）。细节处理：占位消息在流结束时转为 completed，若有中途取消则标记为 stopped 并保留已生成的部分文本加"继续生成"按钮；请求失败转为 error 态并显示重试；防止重复渲染需保证占位消息 id 稳定，重试时复用同一 id 覆盖内容。进度表达上，可以用"正在思考/正在生成/正在调用工具"等阶段文案让用户感知进度。整体由消息级状态机（pending/streaming/completed/stopped/error）统一驱动。

答出"即时占位、增量填充、状态机收尾"的乐观更新链路，并覆盖取消与失败中间态，体现对消息状态细节的把控。

• react-markdown 的静态解析能力与定制
• stream-markdown 对增量块的流式语义
• 流式解析的容错与增量合并

react-markdown 负责把完整的 Markdown 字符串解析为 AST 并渲染为 React 组件，适合最终渲染与静态内容；stream-markdown 专门处理流式场景：它跟踪 Markdown 的解析状态，把"增量 token 块"合并到当前文档结构中，判断当前处于什么块（段落、列表、代码块、表格），渲染器据此只更新受影响的节点，而不是整篇重新解析。流式要点：未闭合块（代码块、表格、强调）的容错——stream-markdown 标记"进行中"块，闭合后完整渲染；增量合并时保持行级边界（不要在块中间随意截断）；与 react-markdown 组合时，把流式累积的文本按批次交给解析器，配合节流控制重渲染频率。工程上"stream-markdown 做增量解析、react-markdown 做最终渲染"是常见组合。

答出两者的分工（增量语义 vs 最终渲染）与未闭合块容错、行级边界、节流合并三个流式要点。

• CoT 内容的流式展示与可折叠交互
• 思考过程与最终答案的隔离（不混入上下文）
• 隐私与安全（思考内容不直接作为输入回传）

现代 AI 界面把思考过程与最终答案分离展示：思考内容用折叠面板（默认收起或展开一角）承载，流式生成时实时展开更新，完成后可收起；面板内展示推理步骤、中间结论、使用的工具与来源。交互要点：思考过程标记为"内部推理"，用户可展开查看但不应直接编辑或作为提示词回传；生成中显示"正在思考"动画，完成态收起为摘要行。工程上：消息协议用独立字段/块区分 reasoning 与 content，持久化时分开存储，发送下一轮时默认只携带最终答案，避免思考内容污染上下文；安全上，思考内容可能含敏感中间信息（如内部检索结果），展开显示需注意脱敏，模型侧可配置是否输出 reasoning（如 Anthropic extended thinking）。

答出"分离展示、折叠交互、不回传"三个要点，并延伸到协议字段分离与安全脱敏，体现对 CoT 工程化边界的理解。

• 中间状态的阶段划分（思考/搜索/调用/生成）
• 状态指示器与流式内容的配合
• 多工具并发与状态聚合

工具调用会话的中间状态通常划分为：思考（模型规划）、搜索中（RAG/联网检索）、调工具中（执行具体函数）、生成中（基于结果写答案）。UI 呈现：消息头部或侧栏显示当前阶段徽标与动画（如"正在搜索…"），工具执行时展示工具名、参数摘要与进度；流式文本继续滚动时阶段指示同步切换。多工具并发时，用任务列表聚合各工具的状态（队列/执行/完成/失败），完成一个收起一个，失败的高亮并提供重试。工程要点：状态由协议事件驱动（tool_call 发起、tool_result 返回），前端按事件更新状态机；阶段切换要平滑过渡避免闪烁；超时工具单独标记并继续其他路径；最后把"所用工具与结果摘要"保留在消息元数据中供溯源。

答出阶段划分、指示器与流式配合、多工具状态聚合三点，并落到协议事件驱动与超时处理，体现工具调用中间态的完整设计。

• Prompt Trimming 的目标与触发时机
• 分级截断（系统提示、工具定义、历史消息）
• 截断与质量的权衡及用户告知

Prompt Trimming 指在请求发出前，依据 token 预算主动裁剪提示内容，避免超限报错并控制成本。触发时机：客户端计数达到阈值（如窗口的 85%）时执行，或请求被拒后回退重试。分级策略：按内容重要性分层——系统提示与安全指令最高优先不可裁剪；工具定义（function schemas）可裁剪不常用工具的详细描述；历史消息按"最近优先"裁剪最旧轮次，中间轮次摘要化；长文档/检索内容截断到关键片段或引用片段。工程要点：裁剪规则可配置并记录"裁剪了什么"（metadata），供审计与调试；裁剪可能影响回答质量（丢失细节），UI 上提示用户"部分历史已压缩"，并可一键展开本地保存的完整历史；对关键任务（如代码上下文）保留最近的代码块而压缩闲聊轮次，是质量/长度权衡的常见做法。

答出"触发时机、分级裁剪（系统提示>工具定义>历史）、质量权衡与用户告知"的完整流程，体现提示工程的实操细节。

• 虚拟滚动的渲染模型（只渲染可视区）
• 无限历史的分页/增量加载
• 流式消息与虚拟滚动的兼容（自动滚动、动态高度）

长对话历史可能上万条消息，全量渲染会卡顿，虚拟滚动（如 @tanstack/virtual）只渲染视口附近的条目，配合 overscan 预渲染少量缓冲行，内存与 DOM 数量恒定。无限历史：向上滚动加载更早的消息（分页或游标），加载时保持滚动位置（锚定首条已加载消息的 offset）；向下滚动回最新。流式消息的兼容是难点：消息高度不确定（Markdown/代码块），需动态测量高度（virtual 的 measureElement）并在内容变化时重测；自动滚动与虚拟化冲突——最新消息可能在视口外，策略是"接近底部才滚动、否则显示'回到底部'浮动按钮"；流式期间新消息插入列表头/尾要处理好 index 映射。工程价值：无论历史多长，渲染性能恒定，让无限对话成为可行产品形态。

答出"虚拟化渲染模型、无限历史加载与位置保持、流式消息的动态高度与自动滚动策略"三点，体现长对话列表的工程全貌。

• AbortController 取消 fetch 流的机制
• React 19 Action（useActionState/useTransition）的取消时机
• 卸载、重试与取消的状态清理

AbortController 通过 signal 传递给 fetch，abort() 会中断读取并触发 AbortError，客户端需捕获并区分"主动取消"与"网络错误"。React 19 Action（useTransition 的 async action、useActionState、form action）让异步流程进入组件声明式状态，协作模式：把 abort 函数保存在 action 上下文（ref/闭包），用户点"停止"或组件卸载时调用 abort，同时用 action 的 isPending 驱动 UI；React 19 中 action 重入（pending 时再触发）默认忽略或排队，取消场景下应先 abort 旧请求再触发新 action，保证只存在一个活跃流。要点：卸载时取消（useEffect cleanup 中 abort）防泄漏与 setState on unmounted；AbortError 不按错误上报（避免错误提示）；取消后可提供"从断点继续"的恢复入口。工程价值：把取消纳入声明式 action 状态，UI 与请求生命周期一致。

答出 abort 机制、与 action/isPending 的状态同步、卸载清理与 AbortError 区分三个要点，展示 React 19 时代取消的现代写法。

• Suspense 的"等待数据就绪"语义与流式数据的冲突
• useChat 的缓存/响应式更新 vs Suspense 的挂起
• 合理划分 Suspense 边界

Suspense for Data Fetching 让组件在数据未就绪时挂起并显示 fallback，但 SSE 流式响应是"持续到达"的数据，天然与"一次性就绪"的 Suspense 语义冲突：若把整条消息包进 Suspense，流式增量会反复触发重挂起。正确协作：Suspense 边界放在"消息列表首次加载"或"历史恢复"处（等待初始数据/持久化恢复就绪），而流式增量交给 useChat 的响应式状态（内部 useSyncExternalStore）在 Suspense 边界内部持续渲染；即"Suspense 管第一帧、useChat 管后续帧"。若服务端 API 暴露 promise 化资源（如 React 19 use() 读取历史列表），Suspense 等待该 promise；流式连接建立后不再依赖 Suspense。要点：不要把流式 fetch 本身包进 Suspense 边界，避免"边流边挂起"闪烁；fallback 仅用于首屏骨架。

核心是"边界划分"：Suspense 管首屏与历史恢复，useChat 管流式增量，避免流式数据与挂起语义冲突，体现对 React 数据模式的准确理解。

• 建议内容的生成来源（模板/模型/上下文）
• 展示时机与交互（点击即发送、可编辑）
• 建议的质量控制与防滥用

输入建议（suggestion chips）是消息下方的一组可点击提示词，降低用户输入成本、引导对话方向。来源分三类：静态模板（新手引导）、基于上下文生成（根据上一轮回答动态提炼后续问题，可调用模型或规则提取）、组合式（预设 + 模型补充）。交互：点击直接发送（作为用户消息）或填入输入框供编辑，发送后隐藏当前建议组并可按需生成下一组；展示时机在回复完成且无进行中任务时，避免打断流式渲染。质量控制：建议数量 2-4 个、短句表达、避免重复与空洞；基于模型的建议要做去重与相关性过滤；防滥用：建议不承载敏感引导，内容同样视为"模型输出"管理。工程价值：提升首轮转化、减少空白输入、引导用户探索功能边界。

答出建议来源、展示交互与质量控制的完整设计，突出"时机正确、内容相关、点击即用"三个体验要点。

• 扩展语法的插件链（remark-math、rehype-katex、gfm 表格）
• 代码高亮与复制、行号
• 长内容性能与安全（数学公式的 XSS 面）

ChatGPT 风格渲染 = 完整 Markdown 语法集 + 定制组件。表格用 GFM 扩展（remark-gfm 支持表格、任务列表、删除线）；LaTeX 用 remark-math 解析行内/块级公式、rehype-katex 渲染为 HTML（KaTeX 轻量），也可用 MathJax 保真更高；代码块用自定义渲染组件接入 shiki/highlight.js 高亮，附语言标签、行号与复制按钮。工程要点：公式渲染要配置 KaTeX 的安全选项（trust: false，禁止攻击性宏，如 \href、\url 与自定义 \html），防止公式注入 XSS；表格超宽用容器内滚动；流式场景公式未闭合时延迟渲染；代码高亮按"完成的块才高亮"分批；整体仍走 Markdown 默认转义，链接协议白名单。性能上长文档分片渲染与虚拟化，数学公式较多时考虑缓存渲染结果。

答出 GFM 表格、KaTeX 公式、代码高亮三条插件链，并突出 KaTeX 的安全配置与流式延迟渲染，覆盖"功能+安全+性能"。

• 自动滚动的触发条件（接近底部阈值）
• 用户滚动意图的检测与暂停
• "回到底部"浮动按钮与恢复策略

自动滚动的工程实践：监听 scroll 事件，当 scrollTop + clientHeight 距 scrollHeight 小于阈值（如 80px）判定"用户处于底部"，此时新增量到达才自动滚动跟随；一旦用户向上滚动超过阈值，标记"已偏离底部"，暂停自动滚动，避免强制拉回打断阅读。工程价值：尊重用户阅读上下文（可能在回看引用、对比内容），避免"我滚上去它又拉下来"的糟糕体验。配套：偏离时显示"回到底部"浮动按钮（带新消息计数），点击恢复跟随；流式结束或用户再次滚到底部时自动恢复自动滚动。实现细节：滚动监听用 rAF 节流、被动模式（passive: true）；内容高度变化（Markdown 渲染后）后重新判定位置，用 scrollTo 平滑滚动避免抖动；虚拟列表场景需在数据插入后于下一帧执行滚动，确保布局已更新。

答出"阈值判定、意图暂停、恢复策略"的完整逻辑及其用户体验价值，并覆盖节流与虚拟列表时序细节。

• 多模态输入的价值（信息密度、意图明确）
• 上传前校验（类型、大小、配额）与压缩
• 语音输入的转写链路与边界（噪声、方言、隐私）

多模态输入的工程价值：图片能传递文字难以描述的视觉信息（截图报错、图表数据），文件让模型基于真实文档回答，语音降低移动端输入成本。边界与实现：图片需校验 MIME 与尺寸、EXIF 方向修正、过大图先压缩再上传，避免解码内存峰值；文件要限制类型与大小，敏感文件提示脱敏或不上传；语音输入走"录音 → 转写（本地 Whisper 或云端 STT）→ 文本入 chat"，转写结果可编辑再发送，边界包括噪声环境识别率、方言支持与录音权限、时长限制；多模态内容同样要过 PII 检测（截图可能含敏感信息），遵循"最小化"原则只上传任务所需部分。价值落点：多模态提升任务成功率，但每一项都带来校验、隐私与成本边界，需按场景开关能力。

分图片/文件/语音三类讲价值与边界，突出"校验、压缩、转写可编辑、隐私最小化"四个工程点，体现对多模态完整链路的管理。

• availability 三态（available/available-after-download/unavailable）的分流
• 下载流程与状态管理（下载中、进度、失败）
• 竞态处理（结果变化后的重新探测与优雅降级）

LanguageModel.availability() 返回三态：unavailable（设备/权限不支持）、available-after-download（需先下载模型）、available（可直接使用）。分流：unavailable 时隐藏/禁用 AI 功能并说明原因；available-after-download 时展示下载入口（进度、体积、配额检查），下载完成后再探测；available 时直接启用。竞态处理是关键：探测结果是"快照"，权限变更、磁盘空间变化、浏览器/模型更新都可能使结果失效，因此：进入 AI 会话前与关键操作前重新探测；下载过程中监听进度事件并处理失败（重试、空间不足提示）；运行中若模型版本更新（后台完成升级），旧会话需失效并重新初始化；用"能力状态机"（unknown/downloading/ready/updating/unavailable）统一驱动 UI，任何状态迁移都触发重新探测与对应降级，避免"以为可用实际不可用"的崩溃路径。

答出三态分流与下载状态管理，重点落在"结果会变化"的竞态上：重新探测、状态机驱动与优雅降级，体现端侧 AI 的工程严谨性。

• 应用缓存（CacheStorage）与模型缓存（浏览器托管）的职责区分
• 下载进度展示与持久化（IDB 记录状态）
• 离线/配额不足/存储回收的恢复策略

关键认知：Gemini Nano 的模型由浏览器（Chromium 内置下载与存储管理）托管，不在页面 CacheStorage 中，因此 PWA 要区分两层缓存：应用资源（JS/CSS/图片，CacheStorage，可预缓存离线壳）与模型（浏览器模型缓存，通过 availability/下载事件管理）。工程实践：下载进度通过模型 API 的事件（downloadprogress 等）获取并展示，进度状态（未下载/下载中/百分比/已就绪）持久化到 IndexedDB，刷新后恢复 UI；容量规划上，应用缓存控制在较小体积（如 < 5MB 预算），把 1.5GB 级空间留给模型缓存，使用 navigator.storage.estimate() 监控配额并提示。恢复策略：离线时若模型已就绪仍可用（推理本地执行），应用壳由 Service Worker 缓存兜底；配额不足（navigator.storage.persist() 请求持久化存储）时提示用户清理或降级云端；存储被回收（模型被清）后重新探测 availability 并触发重新下载，UI 状态机回到 downloading，保证流程可恢复。

答出"两层缓存职责分离、进度持久化、配额与回收的恢复链路"三点，核心是理解模型缓存归浏览器管理、PWA 只做编排。

• 跨标签页协调（BroadcastChannel/SharedWorker/IDB 锁）
• 下载状态去重（单一事实源）与取消/重试仲裁
• 模型版本切换后的会话失效与迁移

多标签页协调的核心是"单一事实源 + 广播通知"：用 BroadcastChannel（或 SharedWorker）广播下载/升级事件，状态持久化到 IndexedDB（含当前下载任务 id、进度、模型版本），任意标签页发现"已有下载任务"（IDB 锁或任务记录）时只订阅不重复发起，统一展示同一进度 UI；并发初始化避免——通过"初始化互斥"（如 IDB 中的 lock 记录 + 过期时间）保证只有一个标签页执行 create 会话初始化，其他标签等待或复用会话句柄。取消与重试：取消操作广播到所有标签页，各自清理 UI；失败重试由持有任务的所有者决定，避免多标签同时重试。版本切换：模型升级完成后广播新版本号，各标签页对旧版本会话做失效处理（保存对话到本地、提示"模型已更新，请继续"），用版本号校验会话合法性，防止旧会话以不兼容上下文继续推理；必要时重新初始化新会话并迁移关键上下文。

答出"广播 + IDB 单一事实源去重、初始化互斥、取消重试仲裁、版本号驱动会话失效"的完整协调机制，体现多标签页端侧 AI 的系统工程。