建议优化会话流式渲染：批量/节流更新 token，避免每 token 全量重建当前消息

[nickkkkkk123123]

When streaming a long text response, DSH re-renders the current assistant message on every token: assistant.ts updateChunk copies the whole blocks array and rebuilds the entire message per assistant/chunk. This causes noticeable main-thread jank — any UI/widget sharing the page freezes between tokens (virtualized list already handles long conversations, but per-token full rebuild of the current message is the remaining bottleneck).

Suggestions:

1. Batch/coalesce streaming token updates (e.g. 50–100ms, or once per animation frame) — reduce re-renders.
2. Or incrementally update the streaming message (append-only), instead of rebuilding the whole message each time.

Note: I couldn't compile-test a useDeferredValue/throttle patch locally (harness deps couldn't install), so this is a suggestion, not a verified patch. Thanks!

[liyangbing]

这个问题需要区分“服务端事件传输”和“浏览器 UI 重渲染”：SandBase Harness 当前服务端不会把每个 transient token 当成持久化事件，也不会让它推进 replay cursor；SSE 会透传 delta/message_id，而带 seq 的持久事件才参与回放和去重。连接回放期间还会先订阅并缓冲 live events，避免 backfill 与实时事件之间丢失/重复。

参考：

• https://github.com/sandbaseai/sandbase-harness/blob/main/src/api/routes/stream.ts
• https://github.com/sandbaseai/sandbase-harness/blob/main/src/api/routes/session-stream.ts
• https://github.com/sandbaseai/sandbase-harness/blob/main/docs/api.md#event-streaming

这并不能直接解决你指出的 DSH React 组件每 token 重建消息的问题；UI 层仍应按 animation frame 或 50–100ms 合并渲染，服务端则继续保持 transient delta 与 durable event 的边界。两层分开后，降低主线程压力不会牺牲 session replay 的一致性。