2026/9/17 22:51:28
FEATURED · 精选文章 
Yuxi 前端体验优化实践对话导航、调试面板与流式正文的统一改造【免费下载链接】Yuxi可私有部署的多租户知识智能体平台统一 RAG、知识图谱、多智能体、MCP/Skills、沙盒与权限管理。Self-hosted knowledge agent platform for RAG, knowledge graphs and multi-agent workflows.项目地址: https://gitcode.com/GitHub_Trending/yu/Yuxi导读本篇文章围绕 Yuxi 项目中一份已落地的前端优化决策文档docs/develop-guides/decisions/implemented/2026-09-05-frontend-optimization.md展开完整讲解该次 simplification 型重构的设计思路、实现方案与验证方式。该重构聚焦三类问题对话侧栏与项目分组状态缺乏一致性、调试信息重复且耗时口径不一、流式正文在突发数据下出现跳跃。读完本文你将掌握 Yuxi 对话页在对话导航状态派生、Run 时间语义与调试面板、流式平滑播放三个维度上的具体实现以及这些实现对应的源码位置与测试覆盖可用于二次开发或同类前端体验优化时直接参考。一、背景对话页体验问题与本次决策范围决策文档首先指出了对话页面在样式、组件和状态反馈三方面的不一致调试信息重复且难以对照时间同一 Run 的耗时在不同位置展示且消息与过程摘要的耗时口径不同请求派发前后的调试选择不连续发送消息前与 Run 建立后的调试面板选中状态发生断裂侧栏状态遮挡长标题项目折叠状态、运行状态与长标题在视觉上互相干扰成批到达的正文出现跳跃SSE 流在突发数据下渲染抖动。本次决策采用 simplification简化类型Owner 为 web/src/components/AgentChatComponent.vue即所有相关调整围绕同一个前端体验主题维护局部样式与组件修正随主题持续更新。整份文档的决策内容可拆分为四个相互独立又互相衔接的子系统对话导航与项目分组、调试面板与时间语义、History 数据投影、流式正文平滑播放。二、对话导航状态从已加载线程派生运行优先于未读2.1 决策要点项目状态从已加载线程派生运行running优先于未读unread折叠项目显示聚合运行状态展开后由线程展示各自的未读/运行细节快捷新建只预选项目首次发送消息时才真正创建线程长标题、状态遮罩、hover/focus 操作及触屏入口保持可用分组逻辑由 web/src/utils/projectConversationGroups.js 拥有路由交接由 web/src/layouts/AppLayout.vue 与 web/src/views/AgentView.vue 拥有。2.2 源码实现项目分组的推导逻辑projectConversationGroups.js是整个导航分组的唯一事实来源核心函数为buildProjectConversationGroups(projects, conversations)侧栏会话按is_pinned置顶优先与created_at时间倒序排序sortSidebarConversations仅保留status ! deleted且selection_status selectable的项目作为分组会话依据project_id归入对应项目无法归类的会话进入otherConversations每个项目分组聚合出threadStatus三态。聚合状态由deriveProjectThreadStatus定义只要分组内存在loading线程即为loading否则只要有ready线程即为ready全部终态才为done。这正是运行优先于未读的落地运行中状态优先级最高其次才是有新 Run 但未查看的 ready 态。对应的前端单测见 web/test/unit/projectConversationsGroup.test.js用于覆盖导航状态优先级等行为。2.3 后端支撑线程状态三态的服务端定义前端消费的thread_status由后端派生见 backend/package/yuxi/services/conversation_service.py 的_thread_statusloading顶层 Run 进行中readyRun 已终态但用户尚未查看last_viewed_run_id与最新 Run id 不一致done无 Run 或已查看。服务端从agent_runs表取每个线程的最新顶层 Runget_latest_top_level_runs_for_threads并结合会话的last_viewed_run_id计算状态。因此前端从已加载线程派生并非凭空猜测而是建立在后端持久化的 Run 终态与已读标记之上前端聚合只是在已加载范围内做二次归并避免了为每个项目持久化一份聚合状态的同步成本。三、调试面板统一记录列表、可调尺寸检查器与累计执行时间轴3.1 决策要点统一记录列表 可调整尺寸的详情检查器宽屏左右分栏、窄屏上下分栏Run、User、Model、Tool 共享选择交互原始数据与 Run 时延明细按需查看列表删除重复 ID、角色文字、状态徽标和行内 JSON时间概览按 Run 顺序累计执行窗口压缩提问间空闲选中记录与时间条联动隐藏概览时重置筛选时间位置只使用持久绝对时间缺失记录保留未知时间上下文展示层由 web/src/components/MessageDebugPanel.vue 与 web/src/utils/messageDebug.js 拥有Run 状态始终来自 AgentRun。3.2 源码实现记录构建与分组messageDebug.js是调试数据的纯函数库包含多条关键链路buildMessageDebugEntries(messages)将历史消息与审计记录转换为统一的调试列表条目为 User/System/Tool/AI 各类角色生成roleLabel与单行摘要并规范后端无时区 PostgreSQL 时间为显式 UTCnormalizePersistedUtcTimestampgroupMessageDebugEntries(entries)按连续 Run 或待运行请求分组以requestId保持接入前后的选择——这正是请求派发前后的调试选择连续的实现Run 尚未创建时以request:${requestId}:${occurrence}为组键Run 建立后同一请求仍归属同一组mergeMessageDebugRunGroups(entries, runTraces)以 AgentRun 投影补齐没有普通消息或审计记录的 Run 分组零消息 Run保证无消息 Run 也能在调试面板中完整表达。3.3 时间语义只使用持久绝对时间时间概览是本次重构的重点其实现分布在messageDebug.js与 web/src/utils/runTiming.js 两个文件Run 时间窗口由getRunTimingWindow(timing)构建以created_at为起点优先采用后端total_latency_ms作为时长仅在缺失时才用finished_at / first_output_at / prepared_at / started_at中第一个已知时间点推算绝不使用浏览器当前时间补造。若 Run 尚未开工无任何时间点直接返回null不污染时间轴。顺序累计时间轴由buildSequentialRunTiming(timings)实现按原顺序将各 Run 的时间窗口首尾拼接Run 之间的提问空闲期不计入时间轴——这是对绝对会话时间轴会被用户空闲挤压这一替代方案的否决。阶段映射由buildRunTimingPhases(timing)实现将单个 Run 映射为四段阶段 key展示名起点终点dispatch调度等待created_atstarted_atpreparation运行准备started_atprepared_atfirst-output模型首响prepared_atfirst_output_atcompletion输出到终态first_output_atfinished_at每个阶段只连接真实存在的相邻时间点缺失的阶段不补齐。时间轴点击与选区拖动由buildTimelineRangeAtPoint/constrainTimelineRange实现点击以落点为中心生成选区选区最小宽度为 2 秒TIMELINE_MIN_SELECTION_MS 2000拖动端点时保持顺序与最小宽度并在边缘贴边getTimelineMinimumRangeUnits负责把两秒换算为 0~1000 的整数范围单位。选中联动与筛选由isMessageDebugEntryInTimeRange/isMessageDebugTimelineMarkSelected完成记录按自身持久化时间映射到拼接后的时间轴buildMessageDebugTraceSpans缺少自身时间的记录保留完整 Run 窗口timingFallback标记并判断记录是否与当前选择范围相交。3.4 五段时延指标与后端统一 serializer调试 Run 详情中展示的五段时延METRICS与前端runTiming.js一一对应dispatch_latency_ms调度等待Run 创建到 Worker 取得执行权preparation_latency_ms运行准备Worker 取得执行权到模型流准备完成model_first_output_latency_ms模型首响准备完成到首个非空模型文本/推理/工具调用数据first_output_latency_ms首次输出Run 创建到首个非空模型语义输出total_latency_ms总耗时Run 创建到 PostgreSQL 终态这些指标的权威来源是后端统一 serializerbuild_agent_run_timingbackend/package/yuxi/storage/postgres/models_business.py它从AgentRun表的created_at / started_at / prepared_at / first_output_at / finished_at / first_model_request_at六个持久时间点一次性派生出全部时延并在AgentRun.to_dict()中随每次序列化输出。前端getRunTotalLatencyMs只接受timing.total_latency_ms这一非负有限数字不从时间戳反推从根上保证了消息与过程摘要耗时口径一致。3.5 消息底部与折叠过程的统一耗时消息底部与折叠过程的耗时展示统一由runTiming.js的formatRunTimingSummary/formatRunTimingDuration完成优先展示总耗时 N缺失时回退到首输出 N两者都缺失时保持未知返回空串格式化规则小于 1 秒显示ms小于 60 秒显示秒10 秒以下保留 1 位小数否则显示m s组合。前端单测见 web/test/unit/runTiming.test.js覆盖总耗时只接受后端 timing 投影中的非负有限数字尚未开工的 Run 不生成未知耗时会话时间概览首尾拼接 Run 并移除中间空档时间轴点击始终选择附近两秒等场景。AgentRun模型与运行状态定义见 backend/package/yuxi/storage/postgres/models_business.py其中status字段取值包括pending/running/completed/failed/cancel_requested/cancelled/interrupted。3.6 详情检查器的分栏约束详情检查器尺寸由constrainMessageDebugInspectorSize及其包装函数控制宽屏左右分栏constrainMessageDebugInspectorWidth记录区最小 300px、详情区最小 260px窄屏上下分栏constrainMessageDebugInspectorHeight记录区最小 120px、详情区最小 180px分隔条宽度固定为 4pxINSPECTOR_SEPARATOR_SIZE请求尺寸非法时回退到容器 42% 的默认值并始终夹在记录区与详情区的可用范围内。四、History 数据投影thread 轻量 runs history 的独立返回4.1 决策要点History 独立返回thread、全部轻量runs与history且包含无消息 Run消息通过run_id关联删除消息上的 Run 时间副本run_timing、run_started_at、run_finished_atRepository 拥有查询conversation_service拥有鉴权后的装配读取与显式已读写操作分开审计接口仍独立按需读取审计与 Run 窗口分别限制为最新 500 条并报告截断完整接口与隔离规则由 docs/mechanisms/agent-runtime.md 的线程阅读数据章节维护。4.2 源码实现服务端装配核心实现为conversation_service.py的get_thread_history_viewbackend/package/yuxi/services/conversation_service.py按thread_id读取会话并校验归属与删除状态404 隔离过滤掉queued / cancelled / rejected状态的用户消息读取该会话全部轻量runslist_agent_runs_for_history据此构建run_created_at映射用于消息排序消息排序键为(run 创建时间, 同 Run 内 user 优先, 消息创建时间, 消息 id)保证同一 Run 的用户消息先于 AI 输出消息序列化只保留run_id、request_id、delivery_status等字段与extra_metadata不再携带 Run 时间副本返回结构为{ thread: ..., runs: [...], history: [...] }。runs数组每项由_serialize_run_trace(run)投影补充request_id、run_type、created_by_run_id字段。thread_status由_thread_status基于最新顶层 chat/resume Run 与last_viewed_run_id派生。HTTP 路由见 backend/server/routers/chat_router.pyGET /thread/{thread_id}/history。读取与显式已读写操作分开的落地读取 History 不改变已读标记显式已读由独立的POST /thread/{thread_id}/viewed完成chat_router.py 第 372 行附近。后端 unit 与真实 HTTP integration 测试覆盖了 History 的完整 Run 投影、权限隔离与读取不改变已读标记。4.3 前端消费请求身份与 Run 关联前端在messageDebug.js中处理请求与 Run 的关联getMessageRequestId优先读取extra_metadata.request_id其次message.request_id仅对人类消息可回退到消息 idgetMessageRunId优先读取extra_metadata.run_id其次message.run_idbindMessageRequestRun(messages, requestId, runId)只用接入响应或派发事件中的明确关联补齐用户消息的 run_id不猜测mergeMessageDebugMessages合并普通历史与实时投影只按已有稳定 ID 去重mergeMessageDebugAudits按消息 id 或(run_id, role, operation_id)键合并 PostgreSQL 审计与实时投影并在 Run 内按sequence保持顺序。这一链路保证了Run 创建前以request_id区分请求明确关联到达后原地补齐保持消息、选择与发送时间连续。五、流式正文useStreamSmoother 的缓冲、调速与字素切片5.1 决策要点流式正文由 web/src/composables/useStreamSmoother.js统一缓冲和播放起始缓冲 180 ms按经过时间、到达速率与积压量渐进调速以 600 ms 为追赶目标按完整字素边界切片每条消息只有一个帧任务按线程与消息隔离工具参数先交付对应文本再即时透传减少动态效果模式下直接显示终态、错误和审批 flush 及时交付尾部reset 清除对应待播内容。5.2 源码实现播放引擎核心常量web/src/composables/useStreamSmoother.js常量值含义START_BUFFER_MS180首个 chunk 到达后的起始缓冲RATE_SAMPLE_MS200到达速率采样窗口RATE_ADJUST_MS300速率平滑的时间常数CATCH_UP_MS600追赶目标积压量按 600ms 消化MIN_CHARS_PER_SECOND32播放速度下限渐进调速tick中目标速率取三者最大值——MIN_CHARS_PER_SECOND、观察到的到达速率arrivalRate、积压量折算的追赶速率(buffered * 1000) / CATCH_UP_MS实际速率按指数平滑逼近目标1 - exp(-elapsed / RATE_ADJUST_MS)权重。每个requestAnimationFrame帧按预算切出正文页面恢复或长任务之后单帧计入时间不超过 64ms避免把累计帧时间一次性兑换为大量正文。测试验证了120 Hz 不会比 60 Hz 倍速播放进度按经过时间计算。字素边界切片takeFromBuffer使用Intl.Segmenter(granularity: grapheme)遍历预算以 UTF-16 长度计量但实际切片停在完整字素边界确保表情符号等多字节字素不被拆开对应测试已知完整字素不会在逐帧切片时被拆开。线程与消息隔离控制器按controllersByThread - messageId两级 Map 组织每条消息只有一个帧任务frameId非空即不复用。resetThread可清除指定线程或全部线程的待播内容并取消帧任务重复消息 ID 不会串流测试覆盖。即时透传分支pushChunk中若 chunk 携带tool_call_chunks或用户启用prefers-reduced-motion则立即flushMessage并直接写入——工具参数先交付对应文本再即时透传动态效果模式直接显示测试用户启用减少动态效果后及时交付已有缓冲与新内容。flush 与 resetflushMessage同步交付该消息全部缓冲并取消其帧任务flushThread在线程结束、取消和审批前同步交付全部缓冲reset清除延迟任务。测试覆盖flush 完整交付正文、推理和工具参数并取消全部残留帧一秒断流时显示完已有文字恢复后继续且最终内容准确。5.3 已知权衡决策文档明确列出了代价与边界这些属于设计事实而非缺陷正文首段增加少量显示延迟起始 180ms 缓冲600ms 是追赶目标不能保证任意输入的最大延迟也无法掩盖长时间上游断流同步 flush 可以一次显示尾部本次优化阅读节奏不保证消除长 Markdown 重绘成本——Markdown 分块与滚动架构仅在实际性能证据需要时调整见文档替代方案。六、替代方案评估与后果6.1 被否决的替代方案方案否决原因保留原有分散入口和消息内 Run 时间诊断重复、耗时不一致无消息 Run 无法完整表达故采用独立 Run 投影和统一检查器使用绝对会话时间轴或逐 Run 切换绝对时间轴被用户空闲挤压逐 Run 切换增加选择状态故采用累计执行时间轴不根据序号或浏览器时间补造时间提前创建 Run 或空线程、持久化项目聚合状态扩大生命周期与同步成本故复用现有 Request 身份、首次发送流程和已加载线程状态全量即时显示或固定逐字速度分别导致突发跳跃或长期积压故采用适度缓冲与渐进调速6.2 后果与兼容性约束前后端需同步发布仓库外 History 消费者需改为按run_id查找runsHistory 仍无分页未来分页必须一起定义消息与 Run 范围多个 SQL 读取不承诺原子快照运行中事实通过 SSE 与持久化重读收敛项目聚合仅覆盖已加载线程不持久化全局聚合状态。七、验证旧能力移除、重新引入条件与测试矩阵7.1 旧能力不存在以下旧实现被移除且不允许回归消息中的run_timing、run_started_at、run_finished_at副本与消费路径第二个时延入口逐 Run 时间栏切换行内 JSON 展开。7.2 重新引入条件只有出现独立的消息级时间语义或必须并列诊断的新实体时才扩展对应 Owner同主题的局部样式和组件调整继续更新本决策记录。7.3 测试覆盖矩阵前端 unit耗时缺失、跨 Run 分组、零消息 Run、请求派发前后稳定身份、导航状态优先级以及流式播放的字素、刷新率、flush/reset 和线程隔离对应测试文件见 web/test/unit/runTiming.test.js、web/test/unit/messageDebug.test.js、web/test/unit/projectConversationsGroup.test.js、web/test/unit/stream_smoother.test.js后端 unit / 真实 HTTP integration / Agent 异步 E2E验证 History 的完整 Run 投影、权限隔离、读取不改变已读标记以及 API、worker、SSE、结果与 History 的关联可参考 backend/test/unit/services/test_conversation_queue_history.py提交时检查Web lint、unit、build、后端 unit、相关 HTTP integration/E2E、工程契约检查及其单测、文档构建和差异检查实际命令、结果与未覆盖范围记录在提交说明中浏览器手工检查调试选择、时间筛选、分栏、项目预选和流式正文覆盖浅深色与窄屏合成回放只证明前端展示不替代真实 worker 链路。八、参考路径速查关注点文件决策记录本文主题docs/develop-guides/decisions/implemented/2026-09-05-frontend-optimization.md对话页组件Ownerweb/src/components/AgentChatComponent.vue项目会话分组web/src/utils/projectConversationGroups.js调试面板展示web/src/components/MessageDebugPanel.vue调试数据纯函数web/src/utils/messageDebug.jsRun 时延与时间轴工具web/src/utils/runTiming.js流式平滑播放web/src/composables/useStreamSmoother.js后端 Run 模型与统一 serializerbackend/package/yuxi/storage/postgres/models_business.pyHistory 装配backend/package/yuxi/services/conversation_service.pyHistory 路由backend/server/routers/chat_router.py线程阅读数据机制docs/mechanisms/agent-runtime.md【免费下载链接】Yuxi可私有部署的多租户知识智能体平台统一 RAG、知识图谱、多智能体、MCP/Skills、沙盒与权限管理。Self-hosted knowledge agent platform for RAG, knowledge graphs and multi-agent workflows.项目地址: https://gitcode.com/GitHub_Trending/yu/Yuxi创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Yuxi 前端体验优化实践：对话导航、调试面板与流式正文的统一改造
Yuxi 前端体验优化实践对话导航、调试面板与流式正文的统一改造【免费下载链接】Yuxi可私有部署的多租户知识智能体平台统一 RAG、知识图谱、多智能体、MCP/Skills、沙盒与权限管理。Self-hosted knowledge agent platform for RAG, knowledge graphs and multi-agent workflows.项目地址: https://gitcode.com/GitHub_Trending/yu/Yuxi导读本篇文章围绕 Yuxi 项目中一份已落地的前端优化决策文档docs/develop-guides/decisions/implemented/2026-09-05-frontend-optimization.md展开完整讲解该次 simplification 型重构的设计思路、实现方案与验证方式。该重构聚焦三类问题对话侧栏与项目分组状态缺乏一致性、调试信息重复且耗时口径不一、流式正文在突发数据下出现跳跃。读完本文你将掌握 Yuxi 对话页在对话导航状态派生、Run 时间语义与调试面板、流式平滑播放三个维度上的具体实现以及这些实现对应的源码位置与测试覆盖可用于二次开发或同类前端体验优化时直接参考。一、背景对话页体验问题与本次决策范围决策文档首先指出了对话页面在样式、组件和状态反馈三方面的不一致调试信息重复且难以对照时间同一 Run 的耗时在不同位置展示且消息与过程摘要的耗时口径不同请求派发前后的调试选择不连续发送消息前与 Run 建立后的调试面板选中状态发生断裂侧栏状态遮挡长标题项目折叠状态、运行状态与长标题在视觉上互相干扰成批到达的正文出现跳跃SSE 流在突发数据下渲染抖动。本次决策采用 simplification简化类型Owner 为 web/src/components/AgentChatComponent.vue即所有相关调整围绕同一个前端体验主题维护局部样式与组件修正随主题持续更新。整份文档的决策内容可拆分为四个相互独立又互相衔接的子系统对话导航与项目分组、调试面板与时间语义、History 数据投影、流式正文平滑播放。二、对话导航状态从已加载线程派生运行优先于未读2.1 决策要点项目状态从已加载线程派生运行running优先于未读unread折叠项目显示聚合运行状态展开后由线程展示各自的未读/运行细节快捷新建只预选项目首次发送消息时才真正创建线程长标题、状态遮罩、hover/focus 操作及触屏入口保持可用分组逻辑由 web/src/utils/projectConversationGroups.js 拥有路由交接由 web/src/layouts/AppLayout.vue 与 web/src/views/AgentView.vue 拥有。2.2 源码实现项目分组的推导逻辑projectConversationGroups.js是整个导航分组的唯一事实来源核心函数为buildProjectConversationGroups(projects, conversations)侧栏会话按is_pinned置顶优先与created_at时间倒序排序sortSidebarConversations仅保留status ! deleted且selection_status selectable的项目作为分组会话依据project_id归入对应项目无法归类的会话进入otherConversations每个项目分组聚合出threadStatus三态。聚合状态由deriveProjectThreadStatus定义只要分组内存在loading线程即为loading否则只要有ready线程即为ready全部终态才为done。这正是运行优先于未读的落地运行中状态优先级最高其次才是有新 Run 但未查看的 ready 态。对应的前端单测见 web/test/unit/projectConversationsGroup.test.js用于覆盖导航状态优先级等行为。2.3 后端支撑线程状态三态的服务端定义前端消费的thread_status由后端派生见 backend/package/yuxi/services/conversation_service.py 的_thread_statusloading顶层 Run 进行中readyRun 已终态但用户尚未查看last_viewed_run_id与最新 Run id 不一致done无 Run 或已查看。服务端从agent_runs表取每个线程的最新顶层 Runget_latest_top_level_runs_for_threads并结合会话的last_viewed_run_id计算状态。因此前端从已加载线程派生并非凭空猜测而是建立在后端持久化的 Run 终态与已读标记之上前端聚合只是在已加载范围内做二次归并避免了为每个项目持久化一份聚合状态的同步成本。三、调试面板统一记录列表、可调尺寸检查器与累计执行时间轴3.1 决策要点统一记录列表 可调整尺寸的详情检查器宽屏左右分栏、窄屏上下分栏Run、User、Model、Tool 共享选择交互原始数据与 Run 时延明细按需查看列表删除重复 ID、角色文字、状态徽标和行内 JSON时间概览按 Run 顺序累计执行窗口压缩提问间空闲选中记录与时间条联动隐藏概览时重置筛选时间位置只使用持久绝对时间缺失记录保留未知时间上下文展示层由 web/src/components/MessageDebugPanel.vue 与 web/src/utils/messageDebug.js 拥有Run 状态始终来自 AgentRun。3.2 源码实现记录构建与分组messageDebug.js是调试数据的纯函数库包含多条关键链路buildMessageDebugEntries(messages)将历史消息与审计记录转换为统一的调试列表条目为 User/System/Tool/AI 各类角色生成roleLabel与单行摘要并规范后端无时区 PostgreSQL 时间为显式 UTCnormalizePersistedUtcTimestampgroupMessageDebugEntries(entries)按连续 Run 或待运行请求分组以requestId保持接入前后的选择——这正是请求派发前后的调试选择连续的实现Run 尚未创建时以request:${requestId}:${occurrence}为组键Run 建立后同一请求仍归属同一组mergeMessageDebugRunGroups(entries, runTraces)以 AgentRun 投影补齐没有普通消息或审计记录的 Run 分组零消息 Run保证无消息 Run 也能在调试面板中完整表达。3.3 时间语义只使用持久绝对时间时间概览是本次重构的重点其实现分布在messageDebug.js与 web/src/utils/runTiming.js 两个文件Run 时间窗口由getRunTimingWindow(timing)构建以created_at为起点优先采用后端total_latency_ms作为时长仅在缺失时才用finished_at / first_output_at / prepared_at / started_at中第一个已知时间点推算绝不使用浏览器当前时间补造。若 Run 尚未开工无任何时间点直接返回null不污染时间轴。顺序累计时间轴由buildSequentialRunTiming(timings)实现按原顺序将各 Run 的时间窗口首尾拼接Run 之间的提问空闲期不计入时间轴——这是对绝对会话时间轴会被用户空闲挤压这一替代方案的否决。阶段映射由buildRunTimingPhases(timing)实现将单个 Run 映射为四段阶段 key展示名起点终点dispatch调度等待created_atstarted_atpreparation运行准备started_atprepared_atfirst-output模型首响prepared_atfirst_output_atcompletion输出到终态first_output_atfinished_at每个阶段只连接真实存在的相邻时间点缺失的阶段不补齐。时间轴点击与选区拖动由buildTimelineRangeAtPoint/constrainTimelineRange实现点击以落点为中心生成选区选区最小宽度为 2 秒TIMELINE_MIN_SELECTION_MS 2000拖动端点时保持顺序与最小宽度并在边缘贴边getTimelineMinimumRangeUnits负责把两秒换算为 0~1000 的整数范围单位。选中联动与筛选由isMessageDebugEntryInTimeRange/isMessageDebugTimelineMarkSelected完成记录按自身持久化时间映射到拼接后的时间轴buildMessageDebugTraceSpans缺少自身时间的记录保留完整 Run 窗口timingFallback标记并判断记录是否与当前选择范围相交。3.4 五段时延指标与后端统一 serializer调试 Run 详情中展示的五段时延METRICS与前端runTiming.js一一对应dispatch_latency_ms调度等待Run 创建到 Worker 取得执行权preparation_latency_ms运行准备Worker 取得执行权到模型流准备完成model_first_output_latency_ms模型首响准备完成到首个非空模型文本/推理/工具调用数据first_output_latency_ms首次输出Run 创建到首个非空模型语义输出total_latency_ms总耗时Run 创建到 PostgreSQL 终态这些指标的权威来源是后端统一 serializerbuild_agent_run_timingbackend/package/yuxi/storage/postgres/models_business.py它从AgentRun表的created_at / started_at / prepared_at / first_output_at / finished_at / first_model_request_at六个持久时间点一次性派生出全部时延并在AgentRun.to_dict()中随每次序列化输出。前端getRunTotalLatencyMs只接受timing.total_latency_ms这一非负有限数字不从时间戳反推从根上保证了消息与过程摘要耗时口径一致。3.5 消息底部与折叠过程的统一耗时消息底部与折叠过程的耗时展示统一由runTiming.js的formatRunTimingSummary/formatRunTimingDuration完成优先展示总耗时 N缺失时回退到首输出 N两者都缺失时保持未知返回空串格式化规则小于 1 秒显示ms小于 60 秒显示秒10 秒以下保留 1 位小数否则显示m s组合。前端单测见 web/test/unit/runTiming.test.js覆盖总耗时只接受后端 timing 投影中的非负有限数字尚未开工的 Run 不生成未知耗时会话时间概览首尾拼接 Run 并移除中间空档时间轴点击始终选择附近两秒等场景。AgentRun模型与运行状态定义见 backend/package/yuxi/storage/postgres/models_business.py其中status字段取值包括pending/running/completed/failed/cancel_requested/cancelled/interrupted。3.6 详情检查器的分栏约束详情检查器尺寸由constrainMessageDebugInspectorSize及其包装函数控制宽屏左右分栏constrainMessageDebugInspectorWidth记录区最小 300px、详情区最小 260px窄屏上下分栏constrainMessageDebugInspectorHeight记录区最小 120px、详情区最小 180px分隔条宽度固定为 4pxINSPECTOR_SEPARATOR_SIZE请求尺寸非法时回退到容器 42% 的默认值并始终夹在记录区与详情区的可用范围内。四、History 数据投影thread 轻量 runs history 的独立返回4.1 决策要点History 独立返回thread、全部轻量runs与history且包含无消息 Run消息通过run_id关联删除消息上的 Run 时间副本run_timing、run_started_at、run_finished_atRepository 拥有查询conversation_service拥有鉴权后的装配读取与显式已读写操作分开审计接口仍独立按需读取审计与 Run 窗口分别限制为最新 500 条并报告截断完整接口与隔离规则由 docs/mechanisms/agent-runtime.md 的线程阅读数据章节维护。4.2 源码实现服务端装配核心实现为conversation_service.py的get_thread_history_viewbackend/package/yuxi/services/conversation_service.py按thread_id读取会话并校验归属与删除状态404 隔离过滤掉queued / cancelled / rejected状态的用户消息读取该会话全部轻量runslist_agent_runs_for_history据此构建run_created_at映射用于消息排序消息排序键为(run 创建时间, 同 Run 内 user 优先, 消息创建时间, 消息 id)保证同一 Run 的用户消息先于 AI 输出消息序列化只保留run_id、request_id、delivery_status等字段与extra_metadata不再携带 Run 时间副本返回结构为{ thread: ..., runs: [...], history: [...] }。runs数组每项由_serialize_run_trace(run)投影补充request_id、run_type、created_by_run_id字段。thread_status由_thread_status基于最新顶层 chat/resume Run 与last_viewed_run_id派生。HTTP 路由见 backend/server/routers/chat_router.pyGET /thread/{thread_id}/history。读取与显式已读写操作分开的落地读取 History 不改变已读标记显式已读由独立的POST /thread/{thread_id}/viewed完成chat_router.py 第 372 行附近。后端 unit 与真实 HTTP integration 测试覆盖了 History 的完整 Run 投影、权限隔离与读取不改变已读标记。4.3 前端消费请求身份与 Run 关联前端在messageDebug.js中处理请求与 Run 的关联getMessageRequestId优先读取extra_metadata.request_id其次message.request_id仅对人类消息可回退到消息 idgetMessageRunId优先读取extra_metadata.run_id其次message.run_idbindMessageRequestRun(messages, requestId, runId)只用接入响应或派发事件中的明确关联补齐用户消息的 run_id不猜测mergeMessageDebugMessages合并普通历史与实时投影只按已有稳定 ID 去重mergeMessageDebugAudits按消息 id 或(run_id, role, operation_id)键合并 PostgreSQL 审计与实时投影并在 Run 内按sequence保持顺序。这一链路保证了Run 创建前以request_id区分请求明确关联到达后原地补齐保持消息、选择与发送时间连续。五、流式正文useStreamSmoother 的缓冲、调速与字素切片5.1 决策要点流式正文由 web/src/composables/useStreamSmoother.js统一缓冲和播放起始缓冲 180 ms按经过时间、到达速率与积压量渐进调速以 600 ms 为追赶目标按完整字素边界切片每条消息只有一个帧任务按线程与消息隔离工具参数先交付对应文本再即时透传减少动态效果模式下直接显示终态、错误和审批 flush 及时交付尾部reset 清除对应待播内容。5.2 源码实现播放引擎核心常量web/src/composables/useStreamSmoother.js常量值含义START_BUFFER_MS180首个 chunk 到达后的起始缓冲RATE_SAMPLE_MS200到达速率采样窗口RATE_ADJUST_MS300速率平滑的时间常数CATCH_UP_MS600追赶目标积压量按 600ms 消化MIN_CHARS_PER_SECOND32播放速度下限渐进调速tick中目标速率取三者最大值——MIN_CHARS_PER_SECOND、观察到的到达速率arrivalRate、积压量折算的追赶速率(buffered * 1000) / CATCH_UP_MS实际速率按指数平滑逼近目标1 - exp(-elapsed / RATE_ADJUST_MS)权重。每个requestAnimationFrame帧按预算切出正文页面恢复或长任务之后单帧计入时间不超过 64ms避免把累计帧时间一次性兑换为大量正文。测试验证了120 Hz 不会比 60 Hz 倍速播放进度按经过时间计算。字素边界切片takeFromBuffer使用Intl.Segmenter(granularity: grapheme)遍历预算以 UTF-16 长度计量但实际切片停在完整字素边界确保表情符号等多字节字素不被拆开对应测试已知完整字素不会在逐帧切片时被拆开。线程与消息隔离控制器按controllersByThread - messageId两级 Map 组织每条消息只有一个帧任务frameId非空即不复用。resetThread可清除指定线程或全部线程的待播内容并取消帧任务重复消息 ID 不会串流测试覆盖。即时透传分支pushChunk中若 chunk 携带tool_call_chunks或用户启用prefers-reduced-motion则立即flushMessage并直接写入——工具参数先交付对应文本再即时透传动态效果模式直接显示测试用户启用减少动态效果后及时交付已有缓冲与新内容。flush 与 resetflushMessage同步交付该消息全部缓冲并取消其帧任务flushThread在线程结束、取消和审批前同步交付全部缓冲reset清除延迟任务。测试覆盖flush 完整交付正文、推理和工具参数并取消全部残留帧一秒断流时显示完已有文字恢复后继续且最终内容准确。5.3 已知权衡决策文档明确列出了代价与边界这些属于设计事实而非缺陷正文首段增加少量显示延迟起始 180ms 缓冲600ms 是追赶目标不能保证任意输入的最大延迟也无法掩盖长时间上游断流同步 flush 可以一次显示尾部本次优化阅读节奏不保证消除长 Markdown 重绘成本——Markdown 分块与滚动架构仅在实际性能证据需要时调整见文档替代方案。六、替代方案评估与后果6.1 被否决的替代方案方案否决原因保留原有分散入口和消息内 Run 时间诊断重复、耗时不一致无消息 Run 无法完整表达故采用独立 Run 投影和统一检查器使用绝对会话时间轴或逐 Run 切换绝对时间轴被用户空闲挤压逐 Run 切换增加选择状态故采用累计执行时间轴不根据序号或浏览器时间补造时间提前创建 Run 或空线程、持久化项目聚合状态扩大生命周期与同步成本故复用现有 Request 身份、首次发送流程和已加载线程状态全量即时显示或固定逐字速度分别导致突发跳跃或长期积压故采用适度缓冲与渐进调速6.2 后果与兼容性约束前后端需同步发布仓库外 History 消费者需改为按run_id查找runsHistory 仍无分页未来分页必须一起定义消息与 Run 范围多个 SQL 读取不承诺原子快照运行中事实通过 SSE 与持久化重读收敛项目聚合仅覆盖已加载线程不持久化全局聚合状态。七、验证旧能力移除、重新引入条件与测试矩阵7.1 旧能力不存在以下旧实现被移除且不允许回归消息中的run_timing、run_started_at、run_finished_at副本与消费路径第二个时延入口逐 Run 时间栏切换行内 JSON 展开。7.2 重新引入条件只有出现独立的消息级时间语义或必须并列诊断的新实体时才扩展对应 Owner同主题的局部样式和组件调整继续更新本决策记录。7.3 测试覆盖矩阵前端 unit耗时缺失、跨 Run 分组、零消息 Run、请求派发前后稳定身份、导航状态优先级以及流式播放的字素、刷新率、flush/reset 和线程隔离对应测试文件见 web/test/unit/runTiming.test.js、web/test/unit/messageDebug.test.js、web/test/unit/projectConversationsGroup.test.js、web/test/unit/stream_smoother.test.js后端 unit / 真实 HTTP integration / Agent 异步 E2E验证 History 的完整 Run 投影、权限隔离、读取不改变已读标记以及 API、worker、SSE、结果与 History 的关联可参考 backend/test/unit/services/test_conversation_queue_history.py提交时检查Web lint、unit、build、后端 unit、相关 HTTP integration/E2E、工程契约检查及其单测、文档构建和差异检查实际命令、结果与未覆盖范围记录在提交说明中浏览器手工检查调试选择、时间筛选、分栏、项目预选和流式正文覆盖浅深色与窄屏合成回放只证明前端展示不替代真实 worker 链路。八、参考路径速查关注点文件决策记录本文主题docs/develop-guides/decisions/implemented/2026-09-05-frontend-optimization.md对话页组件Ownerweb/src/components/AgentChatComponent.vue项目会话分组web/src/utils/projectConversationGroups.js调试面板展示web/src/components/MessageDebugPanel.vue调试数据纯函数web/src/utils/messageDebug.jsRun 时延与时间轴工具web/src/utils/runTiming.js流式平滑播放web/src/composables/useStreamSmoother.js后端 Run 模型与统一 serializerbackend/package/yuxi/storage/postgres/models_business.pyHistory 装配backend/package/yuxi/services/conversation_service.pyHistory 路由backend/server/routers/chat_router.py线程阅读数据机制docs/mechanisms/agent-runtime.md【免费下载链接】Yuxi可私有部署的多租户知识智能体平台统一 RAG、知识图谱、多智能体、MCP/Skills、沙盒与权限管理。Self-hosted knowledge agent platform for RAG, knowledge graphs and multi-agent workflows.项目地址: https://gitcode.com/GitHub_Trending/yu/Yuxi创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
