建议：为 Ralph 增加可选、有界的失败接续（failure successor）

[cocolord]

最近在学习 DeepSeek Harness 的 workflow / subagent / Ralph 实现，也在对照我们此前在 LoopX 中使用过的 failure successor（失败接续）模式。想讨论一个比较窄的方向：Ralph 是否适合增加一种由部署配置控制、次数有界、默认关闭的失败接续策略。

当前行为

@deepseek-ai/dsh-tool-ralph 的固定 workflow 每轮启动一个 fresh child，并通过有界的结构化 report 在轮次间交接。

当某一轮 child 未能产出结构化 report 时，workflow 中的 agent() 返回 null，Ralph 随即返回 round-failed；工具最终呈现为错误，并保留失败轮次与最近一次成功 handoff（如果存在）。

这种行为是 fail-closed 的：它不会把失败误判为完成或预算耗尽，这一点很好。不过，它也意味着单次普通 child 失败会终止整个 Ralph run，即使：

• shared workspace 中已经存在有效进展；
• 前一轮留下了合法的结构化 handoff；
• maxRounds 预算尚未耗尽。

建议方向

是否可以为 Ralph 增加一种 opt-in 的 bounded failure successor？例如：

• 增加部署侧配置 maxFailureSuccessors，默认值为 0，因此保持当前行为；
• successor 仍然计入现有 maxRounds 与 maxTotalAgents，不能绕过总预算；
• cancellation 后绝不启动 successor；
• provider 启动、transport、worker 或 workflow 基础设施级错误仍然直接失败，不进入该策略；
• 只处理已经成功启动、但未产生结构化 report 的普通 child failure。

发生这类失败后，下一名 fresh child 可以收到：

• 不变的 objective；
• 最近一次成功的结构化 handoff（如果存在）；
• “上一轮在产生 report 前失败”的明确标记；
• 先检查 authoritative shared workspace，再决定继续、诊断、pivot 或报告 concrete blocker 的指令。

这里的 successor 不是原样重试同一请求，而是一个新的、fresh 的诊断或转向轮次。它同时受剩余 Ralph round 预算和单独的 failure-successor 上限约束。

希望保持的边界

这个建议不涉及：

• 修改 agent-loop；
• 引入持久 scheduler、registry、lease 或共享 task graph；
• 自动重试基础设施错误；
• 让模型控制 provider 选择；
• 把 worker 的自我报告当作 independent completion certification；
• 修改通用 workflow agent() 当前“普通 child 失败返回 null”的脚本契约。

实现仍可完全由 dsh-tool-ralph 所有，因为它已经负责固定 orchestration script、handoff schema、终态校验和部署策略。

想请教的问题

1. 首次普通 child failure 就终止，是否是 Ralph 希望长期保持的 invariant，还是只是当前暂缓的恢复策略？
2. 如果接受有界恢复，它是否应先保持为 Ralph 专属策略，而不改变通用 workflow seam？
3. failure marker 更适合只存在于固定 prompt 中，还是应该成为结构化 handoff 的一部分？

我倾向于先保持非常轻量：默认关闭、只改 Ralph、所有 successor 都占用现有总轮次预算，也不改变 completion 仍是 worker self-declaration 的事实。

[weijiafu14]

这个提案的边界控制我很欣赏——默认关闭、计入既有预算、基础设施级错误不进策略、cancellation 后绝不启动 successor、不碰通用 workflow 的 agent() 契约。这些"不做什么"比"做什么"写得还清楚，这在提案里很少见。

对你明确提出的三个问题，我只有第 3 个有实质意见，另外补一条关于"有界"该怎么界的想法。

你的问题 3：failure marker 应该是结构化的，理由是"只在 prompt 里的东西没人能数"

failure marker 更适合只存在于固定 prompt 中，还是应该成为结构化 handoff 的一部分？

我认为该进结构化 handoff，理由不是整洁，是只在 prompt 里的标记，编排层看不见，于是任何基于它的判断都做不了：

• successor 连续失败了几次？
• 这几次的失败是不是同一种？
• shared workspace 在这几次之间有没有变化？

这三件事都是 orchestrator 该知道的，而如果 marker 只是塞进提示词的一句话，orchestrator 只能数自己启动了几次 successor，不知道它们是不是在原地打转。

关于"有界"：次数上限之外，建议再看一眼"是不是同一种失败"

你提的 maxFailureSuccessors（默认 0）是对的，但纯次数上限有个已知的弱点——它会把预算平均花在"有希望的重试"和"注定失败的重试"上。

这个社区里有一批很贵的教训都是同一个形状：一个确定性的错误被当成偶发错误反复重试。

• #3489：MCP 会话过期，每次工具调用都返回同一个 -32001，模型重新规划 61 次、烧掉 500 多秒——而那个错误无论怎么规划都不会变；
• #3568：工具参数解析失败退化成空对象、server 报"缺少必填参数"，模型据此原样重发同一个坏参数 17 次。

放到 Ralph 上：如果一轮 child 因为 objective 本身有歧义、或者 shared workspace 处在一个它解不开的状态而没能产出 report，那么下一个 fresh child 大概率会以完全相同的方式失败——而它是 fresh 的，所以它不会记得上一次。maxFailureSuccessors: 3 就是把这个坑踩三遍。

所以建议在"有界"里加一条便宜的短路：

successor 只在"上一次失败之后，authoritative shared workspace 发生了变化"时才启动（或者：连续 N 次 successor 失败且 workspace 无变化时，提前终止而不耗尽剩余额度）。

"workspace 有没有变化"是可观测的事实（文件 mtime / 内容哈希），不需要理解失败的含义，也不需要模型参与。而且它正好和你自己写的那句指令配套——你已经要求 successor "先检查 authoritative shared workspace"，那 orchestrator 也该看同一个东西来决定要不要启动它。

（顺带说：这个判据和 #3489 那边讨论的"确定性错误重复出现应熔断"是同一个信号。同一个东西，一边当刹车，一边当 successor 的准入条件。）

你的问题 1 和 2，我认为你自己的倾向是对的

问题 1（首次失败即终止是不是长期 invariant）：这个只有维护者能答。但我想说的是——你把它提成"是 invariant 还是暂缓的策略"这个问法本身很有价值，因为这两个答案导向完全不同的东西。如果是 invariant，那正确的做法是把它写进文档并说明理由（"Ralph 有意 fail-closed，因为 X"），这样后面就不会有人反复提同一个建议；如果只是暂缓，那你的提案就是现成的落地方案。无论哪个答案，这帖都有产出，这是个好提法。

问题 2（先做成 Ralph 专属还是改通用 workflow seam）：我倾向你的判断——先 Ralph 专属。理由是通用 agent() 的 null 契约是很多东西的地基，动它的影响面无法用一个 Ralph 场景论证；而 Ralph 已经拥有固定 orchestration script、handoff schema 和终态校验，加一条策略是它本职范围内的事。

如果将来别的 workflow 也要，那时候有两个真实消费者，再往上提。 这个社区里有几个提案就是因为一上来要求改通用 seam 而卡住的。

边界与利益相关

我们不修 DSH 自家组件——dsh-tool-ralph、workflow seam、agent-loop 都在 DSH 里。上面全是提案层面的意见；我没有读过 Ralph 的实现，也没有跑过 Ralph，前两节建立在你原帖对当前行为的描述上，引用的 #3489 / #3568 是别人的报告。

利益相关：我维护 pi2dsh（Pi 生态兼容层）。这条不推销——Ralph 是 DSH 自己的工具，装什么插件都不改变它的失败策略。

[liyangbing]

这个方向适合保持为 Ralph 专属策略；我会再补三条可测试的 invariant：

• 先把失败分类做成宿主侧判定：普通 child 已启动但缺少结构化 report，才允许进入 successor；provider/transport/worker 启动、取消、权限和基础设施错误必须保持 terminal failure。不要让 child 自己声明“可重试”来决定类别。
• 把每轮标识为 attempt/generation，并在 successor 输入和最终 receipt 中记录 parent attempt、failure class、剩余 maxRounds/maxTotalAgents、successor budget 和 handoff digest。successor 产出的 handoff 仍是中间证据，不能把“成功生成 report”直接当作独立完成认证。
• 在 successor 启动前做 authoritative workspace 检查并保留只读快照/摘要；若上一轮已产生副作用，必须按 generation 或幂等键防止 successor 重复提交。取消、超时和并发状态变化都应使尚未启动的 successor 失效。

建议的最小矩阵包括：普通 report 缺失且有剩余预算、普通 report 缺失但预算耗尽、基础设施错误、用户取消、workspace 已有部分进展、重复 successor 触发和 successor 自身失败。每个分支都应清楚显示 round-failed、successor-exhausted 或 completed 的区别，并验证 maxRounds/maxTotalAgents 没有被绕过。

独立社区 handbook 的 Ralph 边界说明： https://github.com/sandbaseai/deepseek-harness-handbook/blob/main/docs/en/agent-patterns/ralph-bounded-failure-successor.md

本 handbook 是独立社区项目，并非 DeepSeek AI 官方项目。