批量生成题解时要给重试留出边界批量生成题解常见的失败不是一次请求报错而是格式错误、限流或沙盒失败被重复提交。若每一轮重试都带上完整上下文成本会很快失控也会挤占其他任务的配额。处理方式不是简单把重试次数调大而是为每个任务设定可解释的停止条件最大尝试次数、截止时间、token 预算和可重试错误集合。编译错误、Schema 错误与 429 的处理不能相同。前两类通常要改变输入或人工介入429 才适合在服务端指引允许时做带抖动的退避。type Budget struct { MaxAttempts int MaxTokens int } func allowRetry(attempt, used int, b Budget, retryable bool) bool { return retryable attempt b.MaxAttempts used b.MaxTokens }输出摘要可以帮助发现完全相同的结果反复出现但哈希相同不等于模型一定陷入死循环确定性的题目也可能正常返回相同答案。因此应把它作为停止或人工复核信号并与错误类型、尝试次数一起判断。任务结束时要留下什么每个终止任务至少保存任务 ID、模型与提示词版本、累计 token、尝试次数、最后一个失败阶段和脱敏后的错误摘要。这样才能区分是输入问题、服务限流还是验证器规则过严。Worker 的退出也必须响应context.Done()。清理超时任务时先取消上下文、关闭子进程并等待回收只有在确认进程不响应时才采用强制终止。上线前用可控的格式错误、429 和长时间运行的沙盒任务分别验证这些路径。
