轨迹（Trajectory）面板：历史回放时首 token 延迟/生成时间/吞吐量恒显示"首 token 时间不可用"

[xiangsam]

摘要

Trajectory（轨迹）面板的 Assistant timing 面板在**打开已结束的会话（历史回放）**时，
首 token 延迟、生成、吞吐量 三项恒显示 "首 token 时间不可用"。

同一份会话数据，聊天统计条（turn footer）与 sessionStats 投影的 TTFT 均正常。
根因是轨迹面板自有的流折叠只识别裸 delta chunk，而持久化的 assistant/message.stream
一律以**压缩批（packed run）**格式存储，从未包含裸 delta。

影响

• 所有已结束会话的轨迹面板 timing 三项不可用（100% 复现）
• 仅正在流式输出的步正常（此时走另一条合成事件路径）
• 与 provider、模型、部署方式（loopback / 反代）均无关；本机 loopback 访问同样复现

复现

1. 用任意 provider 完成一次至少含一个 assistant 步的对话
2. 刷新页面（或重新打开该会话）——确保该步不再是流式进行中
3. 打开 Trajectory 面板 → 展开任一 assistant 步 → 查看 timing 面板

实际：首 token 延迟 / 生成 / 吞吐量 均显示 首 token 时间不可用

期望：三者显示具体数值（如 5.4s、12.1s、42.3 tok/s）

环境

项	值
dsh CLI	0.1.5-alpha.1
@deepseek-ai/dsh-client-ui-trajectory	0.1.5-alpha.1
@deepseek-ai/dsh-llm	0.1.5-alpha.1
@deepseek-ai/dsh-session-stats	0.1.5-alpha.1
@deepseek-ai/dsh-api-session-controller	0.1.5-alpha.1
provider	任一（见下文"provider 无关性"论证）
部署	dsh --profile web，浏览器访问（loopback 与反代均复现）

根因分析

数据链路

轨迹面板的首 token 时间来自 state.firstTokenTime，其唯一赋值点在
dsh-client-ui-trajectory/lib/client.js：

// 第 722 行 —— 唯一的赋值点
...isTokenDelta(chunk) && state.firstTokenTime === void 0 ? { firstTokenTime: time } : {}

// 第 592 行 —— 判定只看裸 delta
function isTokenDelta(chunk) {
    switch (chunk.type) {
        case "text-delta":
        case "reasoning-delta": return chunk.text !== "";
        case "tool-call-delta": return chunk.argumentsDelta !== "" || chunk.name !== void 0;
        default: return false;
    }
}

updateChunk 的唯一调用来源是客户端合成的 assistant/live-chunk 事件：

// 第 843 行
if (match.event.type === "assistant/live-chunk") return updateChunk(context.state, match.event.data.chunk, match.event.seq, match.event.time);

而该合成事件在 dsh-api-session-controller/lib/client.js 中仅在 baseline.activeAttempt
存在时才由压缩批展开产生：

// dsh-api-session-controller/lib/client.js 第 1368 行起
const opening = baseline?.activeAttempt;
if (opening !== void 0) for (const [index, member] of expandAssistantStream(opening.stream).entries()) {
    // ...合成 assistant/live-chunk
}

服务端只在流式进行中提供 activeAttempt
（dsh-api-session-controller/lib/index.js 第 1253 行，snapshot() 里
...this.activeAttempt === void 0 ? {} : { activeAttempt: {...} }）。

因此历史回放时 state.firstTokenTime 恒为 undefined。

持久化格式：只有压缩批，没有裸 delta

assistant/message 事件的 data.stream 一律为压缩批记录。实测一条真实记录：

record types: ['chunk', 'reasoning-chunks', 'chunk', 'tool-call-chunks', 'chunk', 'tool-call-chunks', 'chunk', 'chunk']
has text-chunks: False
has raw text-delta chunk: False

其中 chunk 记录仅承载 block-start / block-end / usage / finish，
没有任何 text-delta / reasoning-delta。

遍历本机全部历史会话确认：assistant/message.stream 从未包含过裸 delta。
（更早的 v0 格式里出现过 text-delta，但它属于 assistant/chunk 事件，不是 assistant/message.stream，
故不属于"格式回归"，该缺陷在当前架构下一直存在。）

provider 无关性

打包发生在 harness 内部的统一组件 dsh-llm 的 BlockAssembler.push()
（dsh-llm/lib/index.js 第 1119 行起）：

case "text-delta":
case "reasoning-delta": {
    const type = chunk.type === "text-delta" ? "text-chunks" : "reasoning-chunks";
    const gap = previous !== void 0 && previous.type === type ? safeGap(previous.lastTime, time) : void 0;
    if (previous !== void 0 && previous.type === type && previous.index === chunk.index && gap !== void 0) {
        previous.dt.push(gap);
        previous.texts.push(chunk.text);
        ...

即：任何 provider 的裸 delta 经 assembler 后一律成为压缩批。
打包是 harness 的存储层行为，与适配器实现无关，故该缺陷对所有 provider 生效。

（报告者本机有 stream 的会话恰好全部来自自建适配器，
但上述代码路径表明官方 provider 走同一 assembler，结论不依赖观测样本。）

为什么三项一起失效

三个渲染函数共用 firstTokenTime 作为前置门槛
（dsh-client-ui-trajectory/lib/client.js）：

// 第 4035 行 —— ttft()
if (metrics.firstTokenTime === null) return t("timing.firstTokenUnavailable");

// 第 4039 行 —— generationTime()
if (!metrics.timingRecorded || metrics.firstTokenTime === null) return t("timing.firstTokenUnavailable");

// 第 4046 行 —— throughput()
if (!metrics.timingRecorded || metrics.firstTokenTime === null) return t("timing.firstTokenUnavailable");

timing 对象在 settleMessage 中构造（第 776 行起），直接透传该状态：

timing: {
    stepStartTime: state.started ? state.startTime : null,
    firstTokenTime: state.firstTokenTime ?? null,   // ← 恒为 null
    completedTime: event.time
}

对照组：同一数据在别处工作正常

消费者	是否解码压缩批	TTFT 结果
dsh-session-stats	✅ 调用 assistantStreamFirstTokenTime（来自 dsh-llm）	正常
dsh-client-connection（聊天统计条折叠）	✅ 本地 expandAssistantStream	正常
dsh-client-ui-trajectory	❌ 裸 isTokenDelta	不可用

dsh-client-connection/lib/client.js 第 3057/3063 行即为正确范例：

case "assistant/attempt": {
    const first = expandAssistantStream(event.data.stream).find((member) => isFixtureTokenDelta(member.chunk))?.time;
    if (openStep.firstTokenTime === null && first !== void 0) openStep.firstTokenTime = first;
    break;
}

同文件第 1549 行有一份客户端本地的 expandAssistantStream 实现
（含 validateRecord / validateRun，含 time0 + dt 差分时间重建），
证明该解码逻辑在浏览器侧完全可实现，不违反客户端 bundle 的跨插件值导入约束。

实测数据

在真实会话日志（440 条带 stream 的 assistant/message；会话仍在增长，数字随会话内容增加）上对比两种算法：

带 stream 的 assistant/message 总数: 413
轨迹面板算法（当前实现，裸 isTokenDelta）能算出首 token 的: 0
dsh-llm 算法（含压缩批展开）能算出的:              440

按修复算法计算出的实际数值（同一会话前 5 步）：

step (1, 1): 首 token 延迟 = 7391 ms  (轨迹面板当前显示: 不可用)
step (1, 2): 首 token 延迟 = 4050 ms  (轨迹面板当前显示: 不可用)
step (1, 3): 首 token 延迟 = 5516 ms  (轨迹面板当前显示: 不可用)
step (1, 4): 首 token 延迟 = 5219 ms  (轨迹面板当前显示: 不可用)
step (1, 5): 首 token 延迟 = 5409 ms  (轨迹面板当前显示: 不可用)

即：数据完好，仅未被解码。

建议修复

在 dsh-client-ui-trajectory 的 settleMessage 中，为 firstTokenTime 增加
"从 event.data.stream 回退解码"的路径，与 dsh-session-stats / dsh-client-connection 对齐：

timing: {
    stepStartTime: state.started ? state.startTime : null,
    // 实时路径优先；历史回放时从持久化的压缩批回退解码
    firstTokenTime: state.firstTokenTime
        ?? assistantStreamFirstTokenTime(event.data.stream)
        ?? null,
    completedTime: event.time
}

实现要点：

1. 不要直接 import @deepseek-ai/dsh-llm —— 客户端 bundle 有跨插件值导入约束。
   按 dsh-client-connection 的做法在包内本地实现等价解码
   （压缩批 → 成员时间 = time0 逐项累加 dt[i-1]；首个非空 text/reasoning 成员，
   或带 name 的 tool-call 批的 time0）。
2. 保留 state.firstTokenTime 的优先级，使实时路径行为不变。
3. 建议同时覆盖 assistant/attempt 事件（同格式），以防重试步的 timing 缺失。

附：最小验证脚本

# 取任一会话日志，对比两种算法
zstd -dc ~/.dsh/sessions/<workspace>/<session-id>/session.v3.jsonl.zstd | python3 - <<'PY'
import sys, json

def is_token_delta(c):
    t = c.get("type")
    if t in ("text-delta", "reasoning-delta"): return c.get("text", "") != ""
    if t == "tool-call-delta": return c.get("argumentsDelta", "") != "" or c.get("name") is not None
    return False

def run_first_token_time(run):
    if run.get("type") == "tool-call-chunks" and run.get("name") is not None:
        return run.get("time0")
    members = run.get("texts") or run.get("args") or []
    if not members: return None
    dt, t = run.get("dt") or [], run.get("time0")
    for i, frag in enumerate(members):
        if i: t += dt[i - 1] if i - 1 < len(dt) else 0
        if frag != "": return t
    return None

def trajectory_algo(stream):          # 当前实现
    for r in stream:
        if r.get("type") == "chunk" and is_token_delta(r.get("chunk", {})):
            return r.get("time")
    return None

def correct_algo(stream):             # dsh-llm / client-connection 实现
    for r in stream:
        if r.get("type") == "chunk":
            if is_token_delta(r.get("chunk", {})): return r.get("time")
        else:
            t = run_first_token_time(r)
            if t is not None: return t
    return None

traj = correct = total = 0
for line in sys.stdin:
    try: o = json.loads(line)
    except Exception: continue
    if o.get("type") != "assistant/message": continue
    st = o.get("data", {}).get("stream")
    if not st: continue
    total += 1
    traj += trajectory_algo(st) is not None
    correct += correct_algo(st) is not None

print(f"total={total}  trajectory_algo_ok={traj}  correct_algo_ok={correct}")
# 预期输出：trajectory_algo_ok=0  correct_algo_ok=total（total 随会话内容增长）
PY