本地提交回显在持久节点落地前就被退役 —— 任何耗时的 agent/pre-step 监听器都会变成可见的消息延迟

[Xieweikang123]

现象

发送消息后，自己刚发出的那条消息要等 0.5–2 秒才出现在聊天记录里；在这段时间里，聊天区只显示 turn 状态指示器。消息不会丢，只是晚到。

这个窗口的宽度等于 agent/pre-step 瀑布上消耗的总时间。

机制

ISession.beginSubmission() 会同步创建一条本地提交回显，它存在的唯一目的就是：不管下游发生什么，你自己发的消息都应立刻可见。有两处把「prompt 送到了 host inbox」当成「持久节点已经渲染出来了」，从而破坏了这个不变量：

1. @deepseek-ai/dsh-api-session-controller —— observeSubmissionQueue() 一旦在队列镜像里看到该 rpcId 就调用 scheduleObservedRetirement()，这会把回显从 pendingSubmissions 里移除。
2. @deepseek-ai/dsh-client-ui-chat —— observedRpcIds() 里有 for (const item of queue) if (item.rpcId !== void 0) observed.add(item.rpcId)，而 ChatView 会把 requestId 落在该集合里的回显全部过滤掉。

但队列行（inbox.nextTurn）不是聊天记录里的节点。持久化的 user 节点只能在 agent/pre-step 瀑布返回之后才追加 —— pre-step 可能返回 reject 或改写这一批消息，所以宿主无法更早地落盘。结果就是：回显已经消失，持久节点还没到，留下一个宽度恰好等于 pre-step 耗时的空窗。

用户观察到的顺序也由此直接推出：turn/start 把 running 置为真，于是 TurnStatus 先渲染，消息气泡要等持久节点落地才出现。

observedRpcIds 自己的文档注释写着这个交换是 atomic — no duplicate, no gap，这显然就是设计意图。队列来源那两行正是制造 gap 的地方。

最小复现

不需要桌面端，也不需要任何插件。在任意插件里：

ctx.on('agent/pre-step', async (payload, next) => {
  if (payload.step === 1) await new Promise(resolve => setTimeout(resolve, 1000))
  return next()
})

然后发一条消息。它会晚大约一秒出现，而这一秒里聊天记录只显示 turn 状态指示器。

真实案例：dsh-tauri-turnrewind 在 agent/pre-step 的 step 1 上跑一次工作区快照（git add --all → write-tree → ls-tree -r -l）。在一个 1223 个文件的工作区上，我们实测冷启动 2.77 秒、稳态约 1.1 秒，几乎精确复现了报告中的 0.5–2 秒延迟。

建议的修法

只有持久的 user / steering 节点才应算作 observed。队列来源只应退役「提交时这一轮已经在跑」（placement === "queued"）的那些回显 —— 那类回显本来就不在聊天记录里渲染，因为队列条接管了它们，而队列条已经按 rpcId 与宿主队列行做了去重。

具体来说：

• observeSubmissionQueue：把退役条件收紧到回显自身的 placement === "queued"
• observedRpcIds：整个删掉队列来源（ChatView 已经有 placement !== "queued" 这个条件了）

两处都必须改。只改 store 层，回显虽然还在 pendingSubmissions 里，但会被渲染层过滤掉；只改渲染层，store 层早就把它删掉了，渲染层没东西可渲染。

已知代价

如果一条消息在提交的瞬间恰好被排进了队列，它会在很短一段时间内（约等于 pre-step 的耗时）同时出现在聊天记录的回显和队列条的宿主队列行里。这是「让回显活到持久节点落地」无法避免的代价。上游目前是靠隐藏聊天记录那一份来避免重复的，而正是这个隐藏制造了空窗。

背景

我是在 dsh-tauri/deepseek-harness-desktop（一个打包了 dsh 的桌面壳）上遇到这个问题的。我们目前把它作为一个幂等补丁，在启动时打到活动核心上，症状完全消失。如果相比下游补丁你们更希望走 PR，我很乐意直接对 core 提一个。

[Xieweikang123]

补充一点更直接的证据，以及一个端到端的对照实验。

那个函数的注释已经写明了它该干什么

observeSubmissionQueue 的文档注释和实现是不符的：

/** Retire echoes whose prompts landed in the host inbox instead of the log
 *  (running-turn submissions). */
observeSubmissionQueue(items) {
  if (this.submissionSettlements.size === 0) return;
  for (const item of items) if (item.rpcId !== void 0) this.scheduleObservedRetirement(item.rpcId, attachmentRefsIn(item.message.content));
}

注释把范围限定在 running-turn submissions（提交那一刻这一轮已经在跑的那些），实现却没有检查 placement，等于把所有落进队列的回显一律退役。

所以这里不只是「没做到 no gap」，而是实现偏离了它自己声明的适用范围。前面建议的修法，就是把它收敛回注释所述的范围：

const queuedEchoes = new Set(this.pendingSubmissions.filter((echo) => echo.placement === "queued").map((echo) => echo.requestId));
for (const item of items) if (item.rpcId !== void 0 && queuedEchoes.has(item.rpcId)) this.scheduleObservedRetirement(item.rpcId, attachmentRefsIn(item.message.content));

端到端对照实验

为了确认这个洞在真实产品里的量级，我们做了一个单变量对照：同一个桌面壳实例、同一个正式版二进制、未打任何核心补丁，只切换那个在 agent/pre-step 上跑工作区快照的插件。

状态	观察结果
插件开启	发送后自己的消息延迟 0.5–2 秒才进入聊天记录，期间只显示 turn 状态指示器
插件关闭	消息立刻出现

关掉之后 pre-step 上没有耗时监听器，空窗缩到一个网络往返的量级，肉眼不可见。

关于严重程度

这也说明了这个问题的量级：默认情况下这个洞是潜伏的 —— 它的宽度就等于 pre-step 的总耗时，没有慢监听器时小到看不出来。所以这不是「每条消息都必然丢 1 秒」，而是「任何把耗时逻辑放到 pre-step 上的插件，都会把它直接翻译成用户可见的消息延迟」。

我们之所以撞上，是因为那个桌面壳默认就装着一个在 pre-step 上跑 git add --all → write-tree → ls-tree 的插件（1223 个文件的工作区，实测冷启动 2.77 秒、稳态约 1.1 秒）。下游我们两侧都会动：核心侧按上面的方式收回队列来源的退役条件，插件侧把等待点挪到 tools/pre-execute —— 快照仍然早于一切文件改动，但那段等待与模型请求并行。

[PerryLink]

结论：在 HEAD 上成立。但有一处更正：observeSubmissionQueue 已经不在了 —— 它在 2026-09-09（72f2e71070）被重构，早于你发帖，所以你读的是更旧或下游的 core。机制还在，只是换了名字（observeSubmissionEvent / observeSubmissionInbox）。

1. 三处决定可见性，其中两处键在「队列出现」而不是「持久节点」

• packages/api/session-controller/src/client/sessions/session.ts:708-713：agent/inbox/spliced 分支把 splice 进去的消息直接喂给 observeSubmissionEvent（只要求 source.kind === 'user' 且 rpcId 是字符串，见 :715-722），随后 :751 安排一帧后 finishSubmission(requestId, { reason: 'observed' })
• :725-736 的 observeSubmissionInbox：只看 [...inbox['next-turn'], ...inbox['next-step']]
• packages/client/ui-chat/src/client/chat/ChatView.tsx:154-156：observedRpcIds 同时收 inbox 来源，过滤在 :292-298（submission.placement !== 'queued' && !observed.has(...)）

两处都通过 settlement.retiring = true（:750）上闩，所以之后从 inbox 里消失不会撤销退役。

2. 队列出现不是会话节点：agent/inbox/spliced 是持久事件（packages/core/agent-loop/src/inbox.ts:227-235）但不产生对话节点，而 claim()（packages/core/agent-loop/src/inbox.ts:109-114）在 pre-step 之前又把它删掉一次。严格说它不是没有节点，而是没有一个可见节点：ui-chat 为该事件注册了 inbox-next-step（packages/client/ui-chat/src/client/conversation-nodes/inbox.ts:107-126），但 publication: () => 'none'，只用来把领取批次归类为 steering。所以「队列行已经没了」和「持久 user/message 还没落地」同时成立。

3. 持久节点不可能更早落地：它只在首次尝试时、在 step() 里追加（agent-loop/src/agent.ts:374-378），而 step() 在 pre-step 瀑布之后才跑（:250-251 发射 agent/pre-step，:290 → :303）。pre-step 有权拒绝或改写这一批，所以宿主确实无法提前提交。

⇒ 顺序是：inbox splice 插入（持久，上一帧闩死退役）→ turn/start → claim（队列行消失）→ 整个 agent/pre-step 耗时 → step/start → user/message。窗口宽度 == pre-step 时间，与你说的一致。

4. 你可以这样自证（你正文里的复现思路是对的，这里给最小形态）：挂一个插件

ctx.on('agent/pre-step', async (p, next) => {
  if (p.step === 1) await new Promise(r => setTimeout(r, 1000))
  return next()
})

回显会在提交后约一帧消失，而消息气泡约 1 秒后才出现。

5. 修法形状（要两层一起改）：只在带该 rpcId 的持久 user/message 上退役、且限 placement !== 'queued'；也就是把 observeSubmissionInbox 与那个 splice 分支限制在 placement === 'queued'，并把 inbox 来源从 observedRpcIds 里去掉。代价就是你自己写的那条（提交时排队中的消息可能短暂同时出现在回显和队列行里）—— 我认为那个代价是对的。注意 packages/client/ui-chat/src/client/chat/ChatView.tsx:296 现有的 placement !== 'queued' 站错了边：它豁免了排队的回显，却在藏 transcript 的那一类。

6. 今天的用户侧绕过：没有。 别把慢活放在 agent/pre-step 里 —— 挪到 tools/pre-execute，那时带该 rpcId 的持久 user/message 已经追加、气泡已经到位（packages/core/agent-loop/src/agent.ts:376 在 :489 的工具阶段之前）。没有配置项能控制这件事。

诚实边界：没有在浏览器里跑，也没量真实帧时序。另外我没能确认你引的 observeSubmissionQueue 出自 0.1.5-rc.x 还是你自己的下游补丁（HEAD 上 git log -S observeSubmissionQueue 只有 72f2e71070、98da332260 两次重构）。