dsh 的 ConversationNodeAssembler 遇到重复 callId 时崩溃, 同一response需要使用不同参数多次调用相同工具，此时会产生相同callid引发界面异常

[lisr]

我的场景 确实 需要 大模型 一次response多次调用同一个工具，但是工具参数是不同的，这应该被当成不同的 工具调用，目前看起来无法被区分开 进而导致界面异常

错误链路：

1. LLM 生成重复的 tool call ID：maas-glm-5.2-aliyun 在同一个 response 中对同名工具返回了相同的 callId（如 call_a947292...|fc_call_a947292...）

2. dsh 记录了重复的 tool/call 事件：tool-calls.ts 的 appendToolCall() 直接用 block.id（来自 LLM）作为 callId 写入 session 事件流

3. ConversationNodeAssembler.replaceWindow() 崩溃：trajectory-tool-definition.ts 的 match() 函数对每个 tool/call 事件返回 { id: callId, role: 'start' }。当第二个相同 callId 的 tool/call 到达时，acceptMatch() 发现 context.start !== undefined，抛出：

   conversation Context ... received more than one start Match

4. 整个对话窗口替换失败：replaceWindow() 抛出后，BoundConversation.replace() → MutableSessionEventSource.publish() 全链路失败，UI 没有任何
   conversation node 可渲染。

经过深入探索 D:\ai\deepseek-harness 代码，确认了完整的因果链：

  LLM (GLM) 在同一 response 中返回多个 tool-call block 使用了相同的 callId
      ↓
  BlockAssembler (llm/src/assembler.ts) 直接使用 chunk.id 作为 ToolCallBlock.id
      ↓
  executeToolCalls (agent-loop/src/tool-calls.ts) 对每个 block 调用 session.append('tool/call', {callId: block.id})
      ↓ 产生两个相同 callId 的 tool/call 事件
  ConversationNodeAssembler.replaceWindow (ui-conversation/src/.../assembler.ts)
      ↓ trajectoryToolDefinition.match() 对每个 tool/call 返回 {id: callId, role: 'start'}
      ↓ 第二个相同 callId 触发 "received more than one start Match" 错误
      ↓ throw 中断整个 replaceWindow
  BoundConversation.replace 失败 → UI 对话区完全空白

[argszero]

Excellent causal-chain analysis — I independently verified every link against alpha.2 (0a53fb55be) and it holds end to end. I'll add the precise choke-point location and flag why this deserves to be treated as its own member of a known family rather than a one-off.

All three source claims confirmed.

1. BlockAssembler.assemble() (packages/llm/llm/src/assembler.ts:115) does:

   id: partial.toolCallId ?? brandString<ToolCallId>(`call-${index}`)
   

   And in the chunk handler (tool-call-delta, :72): partial.toolCallId = chunk.id — the LLM's chunk.id overwrites unconditionally. So when GLM emits the same chunk.id for two different indices, both blocks assemble to the same id. The call-${index} fallback only fires when toolCallId is absent — it never corrects a duplicate that is present.

2. appendToolCall (packages/core/agent-loop/src/tool-calls.ts) writes session.append('tool/call', { ..., callId: block.id, ... }), and the sibling appendToolResult uses the same block.id for the result callId. Two duplicate block ids → two identical tool/call events and two identical tool/result events — the duplication propagates through both sides of the session stream.

3. Client acceptMatch (packages/client/ui-conversation/src/conversation/assembler.ts) throws when context.start !== undefined for a second start match — exactly your received more than one start Match. The throw is deliberate (pinned by the test "rejects a duplicate start before mutating the existing Context"), so it isn't a bug in the reader — it's correctly refusing what the writer produced.

The precise piece worth noting: the writer-side choke point is the shared root.

This is the same identity-loss family as #5247 (duplicate callId → frontend assembler throw, which I analyzed earlier), but the root causes are distinct and worth keeping separate:

• 打开历史会话失败：同一 callId 出现第二次 tool/call 时汇编器抛 "received more than one start Match" #5247 = reader tolerating legacy cross-turn short-id reuse (a valid id reused across turns because old writers used turn-scoped index ids).
• dsh 的 ConversationNodeAssembler 遇到重复 callId 时崩溃, 同一response需要使用不同参数多次调用相同工具，此时会产生相同callid引发界面异常 #5268 = writer accepting an LLM-emitted same-response duplicate id — GLM's fault, but the harness currently forwards it verbatim.

This matters because a single fix should not blur them:

• 打开历史会话失败：同一 callId 出现第二次 tool/call 时汇编器抛 "received more than one start Match" #5247 wants the reader (or a re-key upstream) to tolerate legitimate cross-turn reuse; the current throw is a deliberate guard.
• dsh 的 ConversationNodeAssembler 遇到重复 callId 时崩溃, 同一response需要使用不同参数多次调用相同工具，此时会产生相同callid引发界面异常 #5268 wants the writer/assembler to reject or re-key a duplicate id emitted within the same response. The cleanest point is BlockAssembler.assemble() / the tool-call-delta handler: since index already disambiguates blocks, a duplicate toolCallId could be re-keyed to call-${index} (or call-${index}-${n}) at assembly, which would also fix the related 一条空 id 的 tool call 会让会话永久不可用 #5182 (empty id call-${index} fallback) and BlockAssembler fuses parallel tool calls when provider reuses stream index #4427 (index-reuse fusion) cases from the same choke point.

Suggested small regression test: feed two tool-call-delta chunks with the same id at different indices through the assembler and assert the emitted block ids are distinct. That would pin the fix at the writer boundary rather than relying on the reader throw.

整体判断：你的因果链完全成立，而且这正好暴露了 harness 在"LLM 回传 id 不可信"这一层缺少一个 dedup 卫兵——index 已经天然区分 block，用它兜底是最省事也最不容易误伤的修法。需要的话我可以帮你把 #5268/#5247/#5182/#4427 的差异整理成一张对照表，方便 upstream 收敛。

[goatliamia]

这个分析我基本同意，尤其是 writer-side 是共同 choke point 这一点。

不过我觉得这里可能还能再往下拆一层：问题不只是缺一个 duplicate-id guard，而是现在 callId 同时承担了几种不同的 identity 语义。

现在大致是：

provider-emitted callId
        ↓
ToolCallBlock.id
        ↓
session tool/call + tool/result identity
        ↓
Conversation assembler pairing identity

也就是说，一个来自 provider 的外部 ID，直接变成了 Harness 内部的 canonical invocation identity。

这次 GLM 的 same-response duplicate 把这个假设打破了，但 #5247 的 cross-turn reuse、#5182 的 empty id、#4427 的 stream-index reuse，我感觉其实都在说明同一个更基础的问题：

provider identity 和 Harness invocation identity 可能不应该是同一个东西。

我更倾向于把它拆成至少两层：

providerCallId
→ 保留 provider 原始值
→ 用于 provider protocol / diagnostics

invocationId
→ Harness 自己生成并保证唯一
→ session event pairing / tool result / UI 使用

stream index / ordinal 则只是 assembly-local identity，不一定适合升级成最终 canonical id。

这样即使 provider 返回：

tool X(args=A), callId=foo
tool X(args=B), callId=foo

Harness 仍然可以得到：

invocation-1 → providerCallId=foo
invocation-2 → providerCallId=foo

两次调用在内部从一开始就是不同事件，而不是等 reader 发现冲突以后再容错。

所以我赞成在 writer / assembler boundary 修，但可能会比：

duplicate → call-${index}

再多走一步：把 external provider ID 和 internal invocation ID 正式分离。

index 作为 duplicate fallback 对这个 case 很有效，不过 #4427 已经说明 provider 的 stream index 本身也可能复用；而 call-${index} 如果跨 response / turn 成为长期 identity，也仍然可能重复。

一个 regression test 我会再加一层：

same providerCallId
different calls
→ distinct internal invocationIds
→ providerCallId preserved on both

这样测试锁住的就不只是 GLM 这个具体异常，而是「LLM/provider 回传 identity 不可信，Harness 自己负责内部 identity」这个边界。

当然还有一个 provider-protocol 细节需要单独处理：如果下一次请求必须把 tool result 关联回 provider 的原始 call id，那么 re-key 不能简单覆盖原始值；这也正是把两个 ID 分开的理由。

[argszero]

你这个 layer 站得住，我同意把 providerCallId 和 invocationId 正式分离——这比我提的 call-${index} 兜底更根本，而且确实能覆盖到 index 本身也被复用的 case（#4427 已证明 provider 的 stream index 也可能复用，call-${index} 跨 response/turn 未必长期唯一）。

我这边补充三个实现层面的约束，可能是这个设计真正要预算的成本：

1. 这是 session event schema 的 breaking change，不是纯 writer 内部改动。

当前 packages/core/session/src/types.ts 里 tool/call 事件只带一个字段：

'tool/call': { turn: number; step: number; callId: ToolCallId; name: string; arguments: string }

tool/result 的 ToolResultMessage 也通过同一个 callId 配对。也就是说现在只有一个 id 字段、没有独立的 provider 位。要分离就必须给 tool/call 增加一个字段（比如 providerCallId?），这是一次对磁盘会话格式的改动——按 harness 当前 SESSION_FORMAT_VERSION 的守卫逻辑（refuseForeignFormatVersion 只在格式版本变化时才拦旧读端），任何新增字段 + 可选默认值虽可向后读，但写端版本号必须 bump，否则旧读端会把新字段当未知数据丢弃，或误判损坏。这正好是本仓库 d1a9b6e3/e3b9a5d1 家族那类"格式版本守卫缺口"的高危区。

2. 两条 id 各自的正确性边界要划清楚。

• providerCallId 只用于 protocol round-trip（如"下次请求把 tool result 关联回 provider 原始 call id"）与 diagnostics，永远不该参与内部配对；
• invocationId 是 harness 自生成、保证唯一，负责 session tool/call↔tool/result 配对 + conversation assembler + UI。
  只要内部一切配对走 invocationId，providerCallId 哪怕重复/为空都不再影响 UI 稳定性。

3. 重放一致性 + 迁移是隐藏成本。
旧会话盘上只有一个 id。分离后：重放要能重建 invocationId（不然已落盘会话的 tool/result 无法和 tool/call 对上）；tool/result.message.callId 必须和对应的 tool/call.invocationId 严格一致。对存量数据，最省事的迁移是"旧单 id → 同时填入 invocationId 和 providerCallId（都等于旧值）"，这样老的配对逻辑不变，新的语义也不丢。

回归测试建议（在你那句之上再锁一层）：

same providerCallId, different calls
→ distinct invocationIds
→ providerCallId preserved on both
→ replay of the resulting session still pairs correctly

第 4 条是把"格式改动不破坏重放"也钉住，否则只锁住 writer 生成、没锁住 reader 回放。

整体判断：分离是正确方向，invocationId 作为 canonical identity 是根治；但它是带格式成本的 schema 演进，不是一次 assembler 局部 re-key。要做的话我建议按"先加字段 + 版本 bump + 旧数据双填迁移 + 重放测试"四步走，避免踩 d1a9b6e3 那类格式版本守卫的坑。你那边如果有现成的 schema 演进流程（比如 SESSION_FORMAT_VERSION 的 bump 规范）我可以对齐着看。