DeepSeek Harness 每轮结束多转 28 秒：turn/end 被 git 快照阻塞的链路

一次「你好」对话，模型 1.9 秒就说完了，界面却继续转圈到 30.6 秒——多出来的 28.7 秒不在模型，也不在网络，而在回合收尾的那条串行钩子里。 钩子做了一次完整的 git 工作区快照，而工作区里有 12 万个未被忽略的未跟踪文件（#10601）。按三段拆开看。

DeepSeek Harness 发生前：模型其实已经说完了

日志里的两个时间点把责任划得很清楚：内容在 1.939 秒就落盘了。

1. 0.000s turn/start。
2. 1.939s assistant/message + step/end——模型输出完成，这一步结束。
3. 30.607s turn/end——回合才正式结束。
4. 中间 28.7 秒没有任何模型输出，纯粹是收尾等待。
5. 这就是「界面还在转、但其实早就答完了」的来源。

DSH插件 发生时：串行钩子把 turn/end 挡在后面

agent/turn-stopping 是 serial 且 await 的分发，所以 turn/end 一定在它之后才写入。

1. agent.ts 里在回合结束时判断没有下一步，然后 await this.dispatch.serial('agent/turn-stopping', ...)。
2. 因为是串行等待，后续的 turn/end 写入被排在这之后。
3. 钩子落点是 workspace-changes/src/index.ts，里面 await recorders.get(...).stopping(turn)。
4. stopping() 再落到 recorder.ts 的 await snapshotTree(...)。
5. 快照最终执行 git add --all --ignore-errors，写一个私有 index。
6. 整条链上没有任何一步是后台异步的，所以耗时直接叠加到用户等待上。

DeepSeek Harness 发生后：慢在未跟踪文件，不在受跟踪文件

git add --all 会为每个未跟踪文件计算 blob 哈希并写进 index，12 万个文件就是 12 万次计算。

1. 社区在 Windows 11 + git 2.52.0.windows.1、1.6 万个受跟踪文件的仓库上做了对照测量。
2. 受跟踪文件本身很快：git ls-files 只要 0.065 秒，git status --porcelain 0.11 秒。
3. 但 git ls-files --others --exclude-standard 列出了 121,182 个未跟踪且未被忽略的文件。
4. 其中一个临时目录贡献了 115,776 个、约 4.98 GB。
5. git add --all 因此要 66.03 秒；git write-tree 还要 1.65 秒。
6. 单次快照合计 67.7 秒——这解释了你看到的几十秒卡顿。

DeepSeek插件 一张表看清慢在哪一步

同一组命令，补 .gitignore 前后对比，差距全在未跟踪文件那一行。

DeepSeek Harness 减负清单：先补 .gitignore

把构建产物、临时目录、缓存目录补进 .gitignore，是成本最低、收益最大的一步。

1. 用 git ls-files --others --exclude-standard | wc -l 数一下当前未跟踪文件。
2. 按目录聚合，找出贡献最多的几个：git ls-files --others --exclude-standard | cut -d/ -f1 | sort | uniq -c | sort -rn | head。
3. 把 .dsh-build-tmp/ 这类构建临时目录、下载缓存、模型权重目录补进 .gitignore。
4. 重新数一遍，确认数量降到几十的量级。
5. 手动跑一次 git add --all 计时，确认从几十秒降到一秒以内。
6. 再回 DSH 发一条消息，观察 turn/end 是否紧跟 step/end。

社区就是靠这一步把单次快照从 67.7 秒降到 0.17 秒的。

DSH插件 为什么「加缓存」「换硬盘」都不解决

成本与文件数量线性相关，不降数量就只能等。

1. 慢的动作是为每个新文件算哈希，不是读磁盘缓存命中率。
2. 换更快的盘能改善一部分，但 4.98 GB 的临时目录照样要遍历。
3. 加大内存不改变 git add --all 的算法复杂度。
4. 结论：先减文件数，再谈硬件。

修复方向：把快照挪出阻塞路径

插件已经在监听 turn/end，说明「回合结束后再记」这条路本来就有。

1. 在 turn-stopping 里只记录需要的坐标（HEAD、基线 tree）。
2. 把 snapshotTree 改成回合结束后的异步补记，让 UI 的 running 立刻翻。
3. 风险要认：这中间工作树可能又变，快照不再精确对应「回合结束那一刻」。
4. 另一条路线是保住精确性、只把等待变可见：先发一个「正在生成变更摘要」的状态。
5. 后者不改耗时，只是别让它看起来像模型还在思考。

注意事项

1. 别只看总耗时。拆成 step/end 与 turn/end 两个时间点，责任立刻清楚。
2. 别先怀疑模型。这段等待里没有任何生成。
3. .gitignore 要覆盖临时目录，不只是源码构建产物。
4. 注意 --ignore-errors 会让超长路径被静默跳过，快照可能不完整。
5. 长会话里这是常态开销，每轮都要付一次，值得一次性治理。

如果你的 turn/end 延迟只有一两秒，那可能只是正常的收尾开销；几十秒才说明工作区里有大量未跟踪文件。相关排查见 dsh 启动很慢、启动卡住怎么办？DeepSeek Harness 启动耗时的原因与加速排查。