DeepSeek Harness CJK Heredoc 300 秒挂起：Agent Teams 状态分析

在 DeepSeek Harness Desktop 0.2.1-rc.3 的一次社区复现中，四个子 Agent 已经先后完成任务，父 Agent 随后提交了一条包含 Python Heredoc 与中日韩文字的 Bash 命令。命令没有产生任何输出，等待满 300 秒后才以超时或内存错误结束，并重置了持久 Shell。

界面上看起来像是 Agent Teams 一直没有结束，事件时间线却显示：子 Agent 都已完成，真正阻塞流程的是父级 Bash Tool Call。这个区别直接决定排查方向。

复现时间线

社区记录使用 DSH Desktop 0.2.1-rc.3、内置 DSH 0.1.208 与 macOS arm64。四个委派任务分别运行约 6 分 46 秒到 10 分 02 秒，随后均进入完成状态。

父 Agent 在 17:37:14.997 发起第 121 个步骤：一条约 970 个字符的 Bash 命令，内部通过 Python Heredoc 写入包含 CJK 界面文字的文件。直到 17:42:21.817，工具都没有返回标准输出；300 秒上限到达后，父 Agent 立即恢复并继续执行。稍后使用约 511 个字符的 git apply 加 perl -0pi 完成相近修改，其中同样包含 CJK 文本，却能正常结束。

这组对照把问题缩小到输入送入交互式或持久 PTY 的方式，而不是中文字符本身、文件系统写入或 Agent Teams 调度。

为什么界面会误导判断

Agent Teams 页面同时展示父任务、委派任务和当前工具状态。子任务完成并不等于父任务已经具备结束条件：父 Agent 仍可能等待一个 Shell 调用、文件修改或汇总步骤。

排查时应分别核对三条状态线：

• 每个子 Agent 的结束事件与最终输出；
• 父 Agent 是否已经收到全部委派结果；
• 父 Agent 当前是否存在仍在运行的 Tool Call。

如果子 Agent 均已完成，而父级 Bash 从开始到超时没有任何输出，应把它记录为“父级工具阻塞”，不要继续增加子 Agent 或等待 Team 状态自行刷新。

Heredoc 为什么容易在这里出问题

Heredoc 依赖 Shell 持续读取多行输入，直到精确匹配终止标记。命令经过 Agent、工具协议、PTY、Shell 与子进程多层传递时，换行、输入完成信号或编码边界中的任何偏差，都可能让 Shell 继续等下一行。

DSH 社区还出现过 CJK 输入与 readline、以及多行 PTY 输入相关的问题。三类现象共同提示：长多行内容不应默认通过交互式 Shell 注入，尤其是在内容包含非 ASCII 文本、嵌套引号和第二层解释器时。

更稳妥的执行方式

对于代码和配置修改，优先使用 Patch 或文件写入工具，让正文作为结构化参数传递。必须调用 Shell 时，可以采用以下顺序：

1. 把修改拆成可检查的小 Patch；
2. 使用非交互式命令并明确标准输入边界；
3. 避免在一条命令中嵌套 Bash、Heredoc、Python 与大量转义；
4. 为长命令设置较短的无输出告警，再保留总超时；
5. 在父级事件中显示正在等待的 Tool Call 名称、开始时间和已用时间。

超时处理还应保留诊断信息。重置持久 Shell 可以恢复后续任务，但如果同时丢掉最后一条命令、进程树和输入状态，下一次复现仍只能看到“卡住”。

对 Agent Teams 设计的启示

团队状态需要把“子 Agent 全部完成”和“父 Agent 完成”分开显示。父级等待 Shell 时，界面可以明确标注“4/4 子任务完成，父任务正在执行 Bash”，并提供终止当前工具的入口。这样用户能判断结果是否已经产出，也能避免把工具超时误认为多 Agent 协作故障。

如果你遇到的是每轮稳定等待约 30 秒，而不是单条命令持续 300 秒，可以对照DSH 每轮固定 30 秒延迟分析。两者都表现为任务停顿，但前者发生在 Turn 调度边界，本文案例发生在已经启动的 Shell 工具内部。

参考资料

• CJK Heredoc 超时与 Agent Teams 状态复现
• CJK 输入与 readline 问题
• 多行 PTY 输入问题