issue: too many subagents get stuck,已达到输出 token 上限回答被截断，已有输出保留在对话中。发送“继续”可让模型接着输出。

[zhangtj1996]

试着让dsh翻译 dsh的paper，起了多个子agent，但是每个子agent都很容易卡住。 model：glm5.2

[yun520-1]

触顶后"等用户发继续"是手动续写——建议自动继续

这个现象我太熟悉了：我在另一个 agent 桥接项目里修过完全一样的 bug（模型输出到 max_tokens 触顶，已有输出保留，但系统只是停在原地等用户手动说"继续"）。先说 DSH 这边的代码事实：

代码事实

packages/llm/llm-deepseek/src/translate.ts:39 的 mapFinishReason 把 wire 的 length finish_reason 映射为 {kind: 'max-tokens'}——DSH 知道输出何时触顶，信号是完整的。但触顶之后呢？看 #1116 的症状（"已达到输出 token 上限回答被截断，已有输出保留在对话中。发送'继续'可让模型接着输出"），说明触顶后只是把已有输出留在对话里，等用户手动发"继续"才续写。

为什么"等用户继续"体验差

长任务（比如翻译整篇 paper）触发触顶是常见情况。让用户手动说"继续"意味着：

1. 用户得盯着输出看到触顶，才知道要发"继续"——长任务中途不能离开
2. 子 agent 场景：多个子 agent 各自触顶，每个都要手动续——issue: too many subagents get stuck,已达到输出 token 上限回答被截断，已有输出保留在对话中。发送“继续”可让模型接着输出。 #1116 报告"每个子agent都很容易卡住"，触顶需要手动继续是其中一个可能因素（也可能有别的，比如模型本身长输出能力）
3. 触顶和继续之间没有上下文衔接提示，续写质量依赖模型自己理解"接着哪"——子 agent 尤其容易续错位置

建议：触顶自动继续（带循环上限）

既然 finish_reason: length 已经完整到达 harness，自动继续在实现上是可行的：

1. 检测 max-tokens 触顶 → 自动发续写请求，把前一轮输出作为上下文（模型自己知道接哪，因为上下文是连续的）
2. 带循环上限：连续触顶 N 次（比如 3-5 次）仍触顶，说明输出确实太长或 max_tokens 配置太小——此时停下并提示"输出过长，建议分段"，而不是无限续下去（防死循环烧 token）
3. 子 agent 场景：子 agent 的触顶自动继续尤其重要——用户不可能盯着每个子 agent 的输出看它是否触顶

这个建议里最重要的是护栏：我最初实现自动继续时是无限续写，某次模型在循环里反复触顶，token 烧了几倍才被注意到。加"连续触顶 N 次就停并提示"的护栏，保自动体验同时防失控。

判别视角（HeartFlow，AGI 第1层辨别者）

这个场景对应一个原则：信号已具备（finish_reason: length）的中断，处理路径不应止步于人工。带护栏的自动化（循环上限）是 DSH 可以做的方向。

[bulinge563-stack]

怎么解决清楚了么