什么时候修复输出过长被截断不会自动重试的问题？

[ChangedenCZD]

什么时候修复输出过长被截断不会自动重试的问题？

普通单次任务不主动重试可以理解，但是/goal任务下不自动重试就很糟糕。

[173787247]

这确实是当前 /goal + max-tokens 截断 的已知痛点，不是漏修。

现状（按设计）：

1. 输出碰到 token 上限 → turn 以 max-tokens / length 结束。
2. 若截断发生在 未完成的 tool call 中间，BlockAssembler 会 丢弃 这些 block（不能安全执行），partial 输出不会被执行。
3. dsh-goal-round-driver 在 轮次因 max tokens 结束 时会 停止自动续行（README「何时停止续行」里写死了）。Goal 驱动器也不会对这类异常做隐式重试——README「已知限制」里写了「异常情况不自动重试，需用户授权 resume」。

所以你感受到的：/goal 长跑里一旦截断，goal 就「哑火」，要人工点 continue / resume，和普通单次任务一样——对 goal 场景确实更糟。

已修过的相关部分（但不等于 auto-retry）：

• 截断后 session 出现 INVALID_REPLAY_STATE（replay 与持久化 content 不一致）——上游已有 reconcile 修复（如 discussion #2410、commit caafd2b）。这是「会话别永久坏掉」，不是「goal 自动接着干」。

还在讨论/未落地的方向：

• Discussion #3303 提了四条：预检 context 余量、pi-ai 填 replayState 做真续写、把 max-tokens 走类似 compaction 的 recovery、大插件分块写入等。里面也点名了 goal driver 在 max-tokens 时 disarm 这个问题。

临时 workaround：

• 把模型/route 的 maxTokens 调高（并确认请求里真的带上 max_tokens，本地 provider 常有隐藏默认上限，见 #3685）。
• 让 goal 拆小步：少一次 emit 整文件/整插件，多用分步 write/patch。
• 截断后手动发 continue，或在 goal 栏 resume 续行（会消耗 round 计数）。
• 升到较新版本，至少避免 replay 污染导致后续每轮都挂。

有没有 ETA？ 公开文档里这仍标在 goal-round-driver 的「延期工作 / 异常失败重试策略」一侧，没看到维护者给出时间表。若你有稳定复现（模型、maxTokens、是否在写大 tool call、goal 是否 disarm）， worth 在 #3303 或 Issues 里补一条，比单独问「什么时候修」更容易被排期。

你用的 dsh --version 和是 Web 还是 headless /goal，发一下我可以帮对一下是否还踩 replay 老坑。

[ChangedenCZD]

deepseek-v4系列、384K输出，长任务下都会触发。

[PerryLink]

注：本条评论原文因编码问题曾显示为乱码，已重建为可读版（2026-09-07）。

截断不重试的问题（包括 /goal 之类的长输出，来自 dsh-budget 的实测）可以这样缓解：根因是输出上限后 loop 没有触发重试，先止血；「输出过长被截断」可以从两层兜底：

1. dsh-budget 的 max-tokens 预算提前给单轮输出设上限——/goal 长任务被截断时，至少有明确报错，而不是静默丢尾；
2. 用 composer-history 的压缩能力，把长上下文 /compact 处理，避免「上下文溢出导致的截断」。

如果确认是 goal 系统的问题（比如结束条件缺失），欢迎贴出「报错 + 完整日志」的最小复现，我再帮你看。