workspace-changes: git snapshot in agent/turn-stopping can block turn/end for a minute on large workspaces

[zhang-guo-wen]

现象

每次模型回复结束后，界面上的「深度求索中」状态行仍会继续转圈、计秒十几秒到几十秒才消失。模型实际生成只用了 1.9 秒，但整轮迟迟不结束。

从 Session 日志看得很清楚（一次「你好」对话）：

0.000s  turn/start
1.939s  assistant/message + step/end   ← 模型早就说完了
30.607s turn/end                        ← 又空等 28.7 秒

根本原因

@deepseek-ai/dsh-workspace-changes 在 agent/turn-stopping 里同步等待一次完整的 git 工作区快照。该钩子是阻塞的，turn/end 必须等它跑完才会写入，所以前端 running 标记在模型已经输出完毕之后仍保持为 true。

相关代码：

• packages/core/agent-loop/src/agent.ts:361-364 — await this.dispatch.serial('agent/turn-stopping', ...)
• packages/deliverables/workspace-changes/src/index.ts:155-157 → recorder.stopping(turn)
• packages/deliverables/workspace-changes/src/recorder.ts:310 → snapshotTree(...)
• packages/deliverables/workspace-changes/src/git.ts:165 — git add --all --ignore-errors 写私有 index

关键点：慢的不是受跟踪文件，而是未跟踪文件

我在 Windows 11 + git 2.52.0.windows.1 上，对 DSH 源码仓库（16,347 个受跟踪文件）做了对照测量：

操作	修复前	修复后	说明
git ls-files	0.065s	0.065s	受跟踪文件本身很快
git status --porcelain	0.11s	0.11s	只做 stat，不动 index
git ls-files --others --exclude-standard	121,182 个文件	67	未跟踪、未被忽略的文件
git add --all	66.03s	0.13s	全量重算 blob 哈希
git write-tree	1.65s	0.04s
单次快照合计	67.7s	0.17s

也就是说：受跟踪文件只有 1.6 万个，但工作区里有 12 万个未被 .gitignore 覆盖的未跟踪文件（本例中 .dsh-build-tmp/ 一个目录就贡献了 115,776 个，4.98 GB）。git add --all 会为它们全部计算 blob 哈希并写入 index，这才是耗时来源。

把相关目录补进 .gitignore 后，未跟踪文件从 121,182 降到 67，单次快照从 67.7s 降到 0.17s，卡顿随之消失。

想请教的问题

1. 这是否是已知问题？ 类似场景下是否有推荐的规避方式？

2. 工作区快照是否必须同步阻塞 turn/end？ 按代码，end() 那条路径（turn/end 之后）本来就是异步的，而 stopping() 是同步等待。能否把记录整体移到 turn/end 之后，让 turn/end 先落、workspace/changes 事件后到？这样至少 UI 不会被拖住。

3. 是否考虑过限制 add --all 的范围？ 例如只快照受跟踪文件，或对未跟踪文件加数量/耗时预算，超过就退化记录（就像现有 maxFiles / maxFileBytes 那样）。现在 --ignore-errors 会让超长路径被静默跳过，快照实际是不完整的，但没有提示。

4. Agent Note 里的性能结论是否是在 macOS/Linux 上测的？ 2026-09-11-turn-changed-files-card 中写「一万个文件约 60ms，stat 缓存在 index 里对耗时没有可测量的影响」。这个结论在 Windows + 大量未跟踪文件时不成立——我在本机测到 66 秒。如果 Windows 是支持目标平台，这条结论可能需要补充平台条件和未跟踪文件数量的前提。

环境

• 平台：Windows 11
• git：2.52.0.windows.1
• 仓库：deepseek-harness 源码仓库，16,347 个受跟踪文件，.git 约 1.1 GB
• DSH 版本：Web bundle 内置 @deepseek-ai/dsh-workspace-changes 0.2.1-rc.2

感谢！

[PerryLink]

确认，而且卡点就是你说的那一处。

agent.ts:361-364：

if (turnEnds && this.inbox.nextStep.length === 0) {
  await this.dispatch.serial('agent/turn-stopping', { turn, signal })
  signal.throwIfAborted()
}
if (turnEnds && this.inbox.nextStep.length === 0) break

serial 且 await，所以 turn/end 一定在这之后才写。钩子那头是 workspace-changes/src/index.ts:155-157，await recorders.get(agent.session)?.stopping(turn)；stopping 落到 recorder.ts:310 的 await snapshotTree(baseline.git, baseline.workspace, signal)。快照一次完整工作树的耗时，就是你日志里那 28.7 秒。

有个可以直接改的点：这个插件在 :152 已经监听了 turn/end（recorders.get(session)?.end(event.data.turn)），也就是说"回合结束后再记"本来就有一条路。agent/turn-stopping 这条阻塞钩子更像是在抢在会话状态变化前拿基线，但它换来的是把整轮的收尾时间绑在 git 上。

两个方向，代价不同：

一是把快照挪出阻塞路径——turn-stopping 里只记下需要的坐标（HEAD、基线 tree），snapshotTree 改成回合结束后异步补，UI 的 running 就能立刻翻。风险是这中间工作树可能又变，快照不再精确对应"回合结束那一刻"。

二是保住精确性、只把等待变成可见——turn-stopping 里先发一个"正在生成变更摘要"的状态，前端据此把转圈换成明确的进度。这不改耗时，只是别再让它看起来像模型还在想。

如果这条要走补丁，建议按一改，因为 28 秒的收尾对长会话是常态；按二改只是把体验问题从"卡住"变成"知道在等"。