mirror of
https://gitcode.com/JianFeeeee/HomeAgent.git
synced 2026-10-15 12:15:16 +00:00
ee2d43dcbc
## 现象 旁观 agent 响应其它渠道（memo / QQ / email）时，聊天页每秒全量重渲多次， 消息越多越卡。 ## 根因 流式分支判据写的是 `state.chatLoading && ...`，而 chatLoading 只在 「用户从 GUI 自己发消息」（sendChat）时置 true。旁观路径（agent 响应 memo/QQ/email，GUI 仅通过 SSE 收流式帧）下它恒为 false ⇒ 判据恒假 ⇒ 每个 content_delta / reasoning_delta / tool_call 帧都掉进「非流式」分支， 走**全量** innerHTML 重建。 而且它出现**三处**，只改一处无效： · rerenderChatIfActive（决定走 renderChatStreamChunk 还是 renderChat） · renderChat 内部的 streamingLast（决定单条消息的渲染分支） · 工具 pill 的「进行中」收集（旁观时列表恒空，看不到 agent 在做什么） ## 实测（本机 Electron + 192.168.2.60，真实凭据，同一条消息） 修复前：1.7~2 秒内 13~26 次全量重渲，间隔 10~30ms 修复后：同一场景降到 5 次（含轮询触发的） 200 条消息时单次全量重建实测 235ms —— 这是「聊天卡得没有用的欲望」的直接来源。 ## 改法 所有 SSE 流式帧创建的 assistant 消息都带 _streaming:true （content_delta / reasoning_delta / tool_call / agent_output 五个 push 点）， 收尾时才置 _final。所以正确判据是「最后一条是尚未收尾的流式 assistant」， 即用 last._streaming 取代 state.chatLoading。 保留 chatLoading 的两处语义不同，未动： · 「思考中」占位气泡：只在用户自己发消息后等待时显示，旁观不需要 · sendChat / interruptChat 自身的并发保护 判据：cmd/gui npm test 全绿。
