遇到问题并提出建议：流式回合完成后最终结论被错误折叠到思考区域

[ljyzww]

问题描述

在 DSH Desktop 的流式对话中，助手已经生成最终结论，但回合完成后默认折叠会把最终结论一起隐藏到“思考/过程”区域。展开折叠区域后才能看到结论，导致用户误以为本轮没有正式回答。

截图中可以看到：回答完成后，最终文本被归入可折叠的过程区域。

环境

• DSH Desktop：2.0.17
• DSH 内核：@deepseek-ai/dsh 0.2.0-rc.2
• 当前模型：deepseek-flash
• 相关前端包：@deepseek-ai/dsh-client-ui-chat

已排除因素

该问题出现在普通文本回答中，并不依赖 dsh-ui 围栏。

已检查 @changfenhuang/dsh-genui：它主要负责围栏校验、渲染反馈，以及 reasoning-only 回合重试；没有参与消息节点的 processMember、processAnswer、processHidden 折叠判定。因此目前判断问题来自 DSH 本体的聊天 UI，而不是 GenUI 插件。

初步定位

在 @deepseek-ai/dsh-client-ui-chat/lib/client.js 中：

• 约 7682 行：流式回答节点使用首个可见片段的 anchorSeq。
• 约 10051 行：最终回答使用最终 assistant 消息的序号计算 answerAnchorSeq。
• 约 1689–1709 行：同一个回答节点可能同时满足 processMember 和 processAnswer，完成后 processHidden 会随过程区域一起隐藏它。
• 约 10807–10818 行：同一 assistant-step 已经被拆分为 reasoning 和 response，因此可以按 response 边界修正分类。

典型时序是：流式首片段序号为 10，最终结算序号为 20。同一回答节点保留 anchorSeq=10，但最终边界使用 20，导致最终 response 同时被认定为过程成员和最终回答。默认折叠完成回合时，最终结论会随过程节点隐藏。

期望行为

完成回合折叠时只折叠 reasoning/过程内容；最终 assistant response 应始终保留在折叠区外并直接显示。

建议让 processMember 与 processAnswer 互斥，并按最终 assistant reply block 或最终 response 节点计算回答边界。需要覆盖以下回归场景：

1. 流式首片段序号小于最终结算序号。
2. 历史无流式路径。
3. 同一个 assistant-step 同时包含 tool-call 和最终 response。

目前这是基于静态代码分析和实际 UI 现象的定位，尚未修改本地安装包。

[PerryLink]

你的定位方向是对的，而且我把它升级一个结论：这不是「期望行为之争」，是明确的 bug —— 因为仓库自己带一条断言「最终回答不得落在折叠区里」的回归测试，现状是违约。

1. ⭐ 决定性证据：仓库自己的反向断言

packages/client/ui-chat/tests/chat-view.client.spec.tsx:3069：

expect(view.getByText('final answer').closest('[hidden]')).toBeNull()

「final answer 的祖先里不能有 [hidden]」是被显式写进测试的契约。 所以你要的行为就是设计意图，问题出在判定式漏了一项。

2. 根因精确到一行

packages/client/ui-chat/src/client/chat/ChatNodeSeat.tsx:109：

const processHidden = controllerInactive || (foldable && processMember && !processOpen)

processAnswer 根本不参与隐藏判定。 而同一文件 :83-88 算出了它：

const processAnswer = routedNode !== undefined
  && processWindowReady
  && !liveProcess
  && groupPart !== 'reasoning'
  && routedNode.kind === 'assistant-step'
  && routedNode.data.step === processSpec.answerStep

⇒ 两个判定不互斥，而 processHidden 只挑了 processMember。这就是你说的"同一节点同时满足两者"的准确形态。

3. 为什么流式下 processMember 必然为真

:77-82 的第三个析取项：

&& (liveProcess || processSpec.answerAnchorSeq === null || routedNode.anchorSeq < processSpec.answerAnchorSeq
  || (groupPart === 'reasoning' && routedNode.kind === 'assistant-step' && routedNode.data.step === processSpec.answerStep))

它恒真，因为两个锚点取自不同来源：

• 节点锚点 = 首个可见 chunk 的 seq（conversation-nodes/assistant.ts:349-352，:349 注释写着 "A successful message retains its live anchor alongside pending Tool calls" —— 刻意保留 live 锚点，目的是和未完成的 tool call 保持文档序）
• answerAnchorSeq = 最终 assistant/message 事件的 seq（assistant.ts:190-200 的 finalNode，turn-process.ts:163 赋给 answerAnchorSeq）

最终事件必然晚于首个可见 chunk ⇒ anchorSeq < answerAnchorSeq 在流式回合里恒成立。你的"首片段 10、结算 20"时序与源码因果链完全吻合。

4. 作者本意其实写在第四个析取项里

同一 assistant-step 会被拆成两次渲染（conversation-nodes/process-groups.ts:172,175）：:172 走 groupPart: 'reasoning'，:175 走 groupPart: 'response'。

而 :82 专门为 reasoning 渲染开了口子（groupPart === 'reasoning' && … === answerStep）—— 说明作者想要的就是"reasoning 进折叠、response 不进"。缺口只是第三个析取项没有把 response 那一半排除掉。

5. 最小改法

先算 processAnswer，再让两者互斥 —— 例如把 processMember 的最后一项改成 (…) && !processAnswer，或把第三个析取项限定为：

|| (groupPart !== 'reasoning' ? false : routedNode.kind === 'assistant-step' && routedNode.data.step === processSpec.answerStep)

⚠️ 注意住手的地方：必须保证 reasoning 渲染仍被折叠（:82 那条口子不能拆），否则 Think 行会跑到折叠外面。

6. 回归必须先补「流式」fixture —— 这条最要紧

现有测试恰好覆盖不到你的场景：chat-view.client.spec.tsx:2363 那条 folds Think and Tool rows before the final answer without unmounting them 的夹具里，节点 anchorSeq 就等于自己的 seq（见 tests/chat-snapshot-fixture.client.ts:431-432 的 processStartSeq: processStart?.anchorSeq），所以 firstVisibleSeq < finalNode.seq 的形状从来没被测过。

建议照你列的 3 条之外再加第 4 条：构造一个首片段 seq 早于最终事件 seq 的快照，断言 data-turn-process-hidden 不出现在 groupPart="response" 那一行上 —— 直接复用 :3069 的 closest('[hidden]') 写法即可。

7. 版本与"不是有意设计"的确认

你写内核 0.2.0-rc.2。我核的是 origin/master = d743267388（= dsh-v0.2.1-alpha.2），上述四个表达式语义与 rc.2 完全一致 ⇒ 最新代码仍未修。

你说"尚未修改本地安装包"——不必改，你给的 4 处行号与 npm 上 @deepseek-ai/dsh-client-ui-chat@0.2.0-rc.2 的 lib/client.js（12513 行）只差 1–2 行（:1688/:7680/:10049/:10805-10818），说明你读的就是那份构建。源码位置以上面给的为准，投稿时替换掉 bundle 行号会更利于维护者定位。

临时规避

点开「已完成，用时 N 秒」那个折叠控件即可（processOpen 变 true ⇒ processHidden 为 false）。另外 transcript 视图与完成折叠策略相关（ui-chat/src/client/apply.ts:173-194 的 presentation-policy 派生 foldCompletedTurns）。