DeepSeek Harness 工具输出按字节截断出现 U+FFFD？中文首词乱码与修复路径

DeepSeek Harness 的截断只应该删内容，不应该改写留下来的内容；这里的实现改写了。 子进程输出超过收集器的保留上限时，缓冲区头部被按字节丢掉，切点没有考虑字符边界，于是模型拿到的文本开头出现命令从未打印过的 U+FFFD。据讨论，报告者在已发布包上实测，社区成员随后核对了 subprocess-local 的 output.ts（讨论原文）。

DeepSeek Harness 子进程输出截断的现象：一个小上限就能稳定切出两个替换字符

只要切点落在多字节序列内部，文本就会多出字符，而且后面的内容完全正确，看起来特别可信。 用讨论里的脚本复现：

import { OutputCollector } from '@deepseek-ai/dsh-subprocess-local/lib/output.js'

const c = new OutputCollector(23, 'stdout', undefined)
c.push(Buffer.from('编译完成：3 个文件 ✅ done\n', 'utf8'))

console.log(JSON.stringify(c.finalize().text))
// "��3 个文件 ✅ done\n"   两个输入里没有的字符

console.log(JSON.stringify(c.readFrom(0).text))
// "��3 个文件 ✅ done\n"   前台读取，同样如此

复现时按下面顺序核对，避免把别的问题混进来：

1. 把上限设为明显小于输出的值，预期 truncated 为 true。
2. 打印 finalize().text，预期开头出现一个或两个 U+FFFD。
3. 再打印 readFrom(0).text，预期同样损坏——说明不是某一条读取路径特有的。
4. 找到同一次运行的 spill 文件，预期内容字节精确，没有替换字符。

损坏发生在 DeepSeek Harness 的缓冲区，不在解码器

真正的动作是 this.chunks[0] = head.subarray(excess)：一次裸字节切片，文件里没有任何 UTF-8 边界处理。 之后的 finalize()、snapshot()、readFrom(0) 解码的都是这段已经被切坏的字节。社区核对的位置是 output.ts:167-181：

while (this.bytes > this.maxBytes) {
  const head = this.chunks[0] as Buffer
  const excess = this.bytes - this.maxBytes
  if (head.length <= excess) {
    this.bytes -= head.length
    // 整块丢弃
  } else {
    this.chunks[0] = head.subarray(excess)
    this.bytes -= excess
  }
}

由此可以推出三件事：

1. 损坏发生在缓冲阶段，所有下游读者都会继承，包括主路径上的前台读取。
2. 只修解码器不够，因为交到解码器手里的字节已经缺了前导字节。
3. truncated: true 无法区分「在字符边界上干净地丢头」和「从字符中间丢头」，两种情况共用一个值。

改法一：把 DeepSeek Harness 的切点推进到下一个 UTF-8 首字节

这是改动最小、语义最稳的修法：保留字节预算，只把切点往后挪到字符起点，最多多丢 3 个字节。 步骤：

1. 把裸切片换成一个裁剪函数，入参是原始缓冲区和要丢掉的字节数。
2. 从 excess 开始向后走，只要当前字节满足 (byte & 0xC0) === 0x80 就继续前进。
3. 用新的偏移量做 subarray，并把实际丢掉的字节数写回 this.bytes。
4. 边界保护：如果一直走到缓冲区末尾，说明整块都不可解码，按整块丢弃处理。
5. 用第 1 节的脚本重跑，预期开头是完整中文，truncated 仍为 true。

示意实现（不是仓库原代码）：

let cut = excess
while (cut < head.length && (head[cut] & 0xc0) === 0x80) cut++
this.chunks[0] = head.subarray(cut)
this.bytes -= cut

改法二：保留 DeepSeek Harness 的字节精确窗口，读取端流式解码

如果下游必须拿到「正好 maxBytes 个字节」，那就别在缓冲区里修，改成每个读者用流式解码器自己处理残缺序列。 步骤：

1. 保持 subarray(excess) 不变，明确记录这块缓冲区可能以连续字节开头。
2. 把 finalize()、snapshot()、readFrom() 里的 toString('utf8') 换成共享的 TextDecoder，开启流式模式。
3. 对窗口开头单独做一次「跳到首字节」的预处理，或在解码前标记跳过不完整序列。
4. 回归三条读取路径，预期三者输出一致，且都没有 U+FFFD。
5. 检查 spill 路径没有跟着改——它写的是原始块，不需要解码。换 DSH插件 或换终端都改不了这段裁剪逻辑，修在收集器本身。

两种改法的取舍要写清楚：改法一保证「存下来的缓冲是合法文本」，改法二保证「上限恰好是 maxBytes」，在不知道编码的前提下无法同时满足。另一条相邻缺陷是 spill 短写，见 DeepSeek Harness spill 短写丢字节排查。

改法三：调高 DeepSeek Harness 的输出上限，让截断不发生

提高上限只是把概率降下来，不是修复；它适合作为止血，不能当作结案。 步骤：

1. 找到当前输出收集器的上限配置，确认它是按字节计的硬上限。
2. 按实际命令的输出分布把上限调到能覆盖绝大多数场景，预期常规构建日志不再触发 truncated。
3. 用一个明显超限的输出再测一次，预期仍会出现替换字符——证明这只是缓解。
4. 同时在结果里补上「省略量按实际返回字节计算」的口径，避免上限与返回值对不上。

DeepSeek Harness 修复后的验证：三类文本加两个对照

验收不能只看一段中文，必须覆盖 2、3、4 字节码点，并带上必定失败与必定成功的对照。 步骤：

1. 准备混合中文、拉丁字母与 emoji 的样本，循环取不同上限，统计开头出现 U+FFFD 的比例，修复后预期为 0。
2. 保留一份纯 ASCII 样本，预期任何时候都不出现替换字符。
3. 保留一份已知必然切在字符中间的样本，修复前预期 100% 命中，修复后预期 0 命中——这证明检测器本身有效。
4. 对比 spill 文件与内存文本，预期修复后两者开头一致；truncated 的语义仍只表示「内容被省略」。