[RFC] Re-resolve continuable child policy on each new activation

[Bruce-anle]

DSH Continuable Activation Policy Re-resolution RFC

状态：已发布上游讨论 #2639
日期：2026-08-17
目标版本：DeepSeek Harness 0.1.0-rc.6

摘要

DSH 当前的可续聊子代理会把创建时的模型路由写入父子代理选项和持久描述记录。父会话后来切换模型时，新建子代理可能仍使用创建时的旧路由；如果旧端点或模型已经失效，冷恢复还会再次使用旧配置，导致恢复持续失败。

本提案请求增加一个官方的“执行实例创建前策略解析”入口。它不改变正在运行的执行实例，只在创建、重试、后续追问或冷恢复时重新解析当前有效策略。

现有证据

• 讨论 #117：第三方接口下子代理调用失败 收到多个用户复现：主会话已经切换模型，子代理仍走创建时默认路由。
• 讨论 #1472：旧模型导致意外计费 报告 23 个子代理继续使用创建时的高价模型。
• 讨论 #1581：创建时模型快照问题 给出双向复现和测试补丁。
• 社区补丁 f302da9 修复了“创建新子代理时读取父会话当前路由”的问题，但其设计明确保留已经建立子代理的路由用于冷恢复，因此没有解决本文提出的恢复故障切换问题。

状态模型

需要区分三个对象：

1. 子代理会话：持久身份、历史和上下文。
2. 逻辑工作：子代理负责的任务和所有权。
3. 执行实例：一次实际运行、后续追问、重试或恢复。

策略绑定到执行实例，而不是永久绑定到子代理会话。

期望行为

• 正在运行的执行实例保持创建时的完整策略，不在执行中途改变模型、角色、工具或技能。
• 新建执行实例时，解析最新有效策略。
• 上一执行实例已经结束、需要创建新 Activation 时，同一子代理会话的后续追问解析最新策略。驻留中的执行实例收到的 FIFO 追问继续使用原策略。
• 上一执行实例失败并需要创建新 Activation 时，重试解析最新策略。
• 冷恢复同一个尚未完成的逻辑工作时，保留会话、上下文、所有权和证据，但解析最新策略。
• 同一次 Workflow 中，后续启动的子代理按其启动时的最新策略运行。
• 每个执行实例记录实际使用的策略版本和内容哈希。
• 配置更新与执行实例启动的线性化点，是策略解析和发布之间的原子边界。

这样可以处理模型或端点失效：修改配置后，恢复尝试不会再次使用已经失效的路由。

删除和失败

• 已经运行的执行实例可以完成当前工作。
• 删除角色不会删除已有会话和历史。
• 删除或配置无效后，任何新的执行实例，包括追问、重试和冷恢复，都必须在启动前明确失败。
• 不得静默回退到旧策略或默认模型。
• 需要继续时，调用方必须恢复有效角色，或显式把逻辑工作转交给另一个有效角色。

建议的公开入口

建议在可续聊子代理管理器中增加一个执行实例策略解析器。它应在创建或冷恢复调用 agents.create/resume 之前运行，并返回：

• provider/model；
• persona；
• tool policy；
• Skill catalog/loader policy；
• depth policy；
• output policy；
• profile id、revision 和 content hash。

建议的抽象形式类似：

registerContinuableActivationResolver((input) => {
  return resolveLatestPolicy({
    childSession: input.session,
    descriptor: input.descriptor,
    parent: input.parent,
    reason: input.reason, // create | followup | retry | cold-resume
  })
})

关键要求：

• 解析器必须在旧 descriptor 的 provider/model/tool composition 应用之前运行。
• descriptor 可以持久化稳定的 profile reference，不应只持久化某次执行的具体模型路由。
• 旧版本没有 profile reference 时，继续使用现有 descriptor 快照，保持兼容。
• 解析失败必须阻止新执行实例发布。
• 正在运行的实例不重新解析。
• 生命周期、所有权、settlement 和 session persistence 仍由 DSH 原生管理。

为什么现有 setup 入口不够

当前 setup 入口可以在创建或冷恢复时追加部分子代理环境，但旧的 provider/model 和工具组合已经在 setup 前从 descriptor 解析。它不能可靠替换完整的模型路由、旧工具限制和旧角色策略，因此不能单独实现本文语义。

不应采用的实现

• 不要在插件中复制一套子代理生命周期管理器。
• 不要绕过原生所有权和 settlement。
• 不要用隐藏 prompt 代替工具和技能隔离。
• 不要把旧模型作为恢复失败时的隐式回退。
• 不要把一个失败的执行实例伪装成仍在运行。

可接受的临时方案

如果上游暂时不增加该入口，可以使用“接替子代理”：保留逻辑工作、任务事实、所有权和证据，创建新的子代理执行恢复。该方案能解决端点失效，但不会保留原子代理会话编号和全部上下文，因此应明确标记为降级路径。

希望上游确认的问题

1. 是否接受“策略绑定到执行实例、而不是永久绑定到可续聊会话”的语义？
2. 是否可以在 cold resume 的 descriptor composition 之前提供策略解析 hook？
3. descriptor 是否可以保存插件拥有的稳定 profile reference，并在每次新执行时重新解析？
4. 哪个原生 session/evidence 载体适合记录每次执行的有效策略，而不引入第二状态源？
5. 配置删除或无效时，是否应在新的 follow-up/recovery activation 发布前 fail loud？

参考

• 上游 RFC 讨论 #2639
• DeepSeek Harness
• @deepseek-ai/dsh-subagent
• 讨论 #117
• 讨论 #1472
• 讨论 #1581
• 失败接替讨论 #109

[weijiafu14]

"策略绑定到执行实例、不是永久绑定到会话"这个语义我认为是对的，而且你把 create / followup / retry / cold-resume 四种 reason 分开，是这份 RFC 里最有价值的设计。我想提一个可能让它更容易被接受的建议——先把"已经有权威晚期入口"的那部分从诉求里拆出去。

一、你要重新解析的东西，有一部分今天已经有官方的权威 seam 了

你在"为什么现有 setup 入口不够"里写：

旧的 provider/model 和工具组合已经在 setup 前从 descriptor 解析。它不能可靠替换完整的模型路由、旧工具限制和旧角色策略

这三样的处境不一样，值得分开：

要重新解析的	今天有没有权威的晚期入口
工具组合 / 工具限制	有——tools/pre-execute 是 awaited 的；更关键的是 system-prompt/assemble 这个 async waterfall 的返回值是权威的，assembly.tools 可以在里面被改写（不只是追加：改 description、从 parameters.properties 删字段都能落地）
角色策略 / persona（系统提示）	有——同一个 system-prompt/assemble waterfall，装配时跑、返回值权威，当轮就能改
provider/model 路由	这条我没有对应证据，它在 llm 分发链上，不经过上面那个 waterfall

上面两行不是读类型推的，是在真 DSH 组合上跑探针跑出来的（assembly.tools 那条我改了一个已注册工具的 description、又从它的 parameters.properties 里删掉一个字段，assemble 返回的结果里两处改动都在）。

这意味着你的 RFC 可能只有第三行是真缺口。 如果是这样，提案会强很多：

请求一个在 activation 发布前重新解析 provider/model 路由的入口。工具组合与 persona 已可通过 system-prompt/assemble 在每轮重新决定，本提案不重复它们。

一个只要求"补上确实没有的那一块"的提案，比一个要求"给我一个能替换全套策略的新 hook"的提案容易通过得多——后者会引出"这和现有 waterfall 是什么关系""会不会有两套权威"这类很难三言两语答清的问题。

二、方法上的一条建议：先倒推，再提新 seam

这条是经验之谈，我们吃过三次亏才立成规矩：判"平台做不到"之前必须倒推，不能正推就收工。

• 正推 = 从我手上这个 API 出发，撞到第一个死胡同就宣布不可能；
• 倒推 = 从用户可见的结果出发，问"这个结果的数据是从哪来的"，一路查到源头——数据总得从某处来，所以倒推挡不住。

三次实证，都发生在"我以为结构上不可能"之后：

1. 要在本轮改系统提示，正推看我们在用的那个逐步事件 → "结构性不可能"；倒推问"提示词是谁装配的" → system-prompt/assemble 是 async waterfall、装配时跑、返回值权威，当轮就能改。
2. 要关掉某个工具，正推看名字最像的 tools.restrict() → "scope 模型不给"；倒推问"模型看到的工具列表从哪来" → assembly.tools，同一个 waterfall 里直接改。
3. 一个"没有探针"的能力，倒推发现某个重复注册错误码是文档化行为，探一次就拿到真值。

对你这份 RFC，倒推的问题是："这次 activation 实际发出去的请求，它的 provider/model 是从哪个变量读出来的？从 descriptor 到那个变量之间，有没有任何一个 awaited 的官方 seam？"

如果有——那你可能不需要新入口，只需要在那里改写。如果确实没有——那你就能把诉求写成"数据流我追到了第 N 步，断在这个具体符号上"，这比"setup 太早了"有说服力得多，也让维护者一眼看到该在哪开口子。

（判据我们内部写成一句话：说"不能"之前，必须能说出"这个结果的数据流我追到了哪一步、断在哪个具体符号上"；说不出来就是没查完。而且结论只认实跑——上面三条都是在真 DSH 服务上跑出来才敢写的。）

三、"不应采用的实现"那节，第一条尤其对

不要在插件中复制一套子代理生命周期管理器。

这条值得加粗。我维护 pi2dsh（Pi 生态兼容层），它能跑一套 Pi 生态的子代理——而我们恰恰是靠不复制生命周期才活下来的：子代理是真实的 DSH 会话，创建/恢复/settlement 全部走官方面，我们只做 ABI 翻译。复制一套的代价是你会得到第二份权威状态，然后花全部时间让两份对齐。

利益相关先说清楚：我们那套子代理按会话当前的实时路由解析模型，不吃创建期快照（有端到端 example，断言是"父会话 /model 切换后，未固定模型的子代理跟着换到新路由"）。所以它天然不会踩你引的 #117 / #1472 / #1581 那一族。

但我不建议你为此换掉 DSH 原生子代理，理由有三条：① 我们验过的是创建时按实时路由解析，你 RFC 的重点——followup / retry / cold-resume 三种 reason 下的重新解析——我没有对应的实测断言，不能宣称我们做到了；② 你要的是这个语义进上游，换运行时不会让 #117/#1472/#1581 那几帖消失；③ 你这份 RFC 的价值恰恰在于把"执行实例 vs 会话"这个区分提出来——那是个应该由平台拥有的语义，不该由某个插件私有实现。

边界

我们不修 DSH 自家组件——continuable manager、descriptor、agents.create/resume 都在 DSH 里。第一节那张表里"有"的两行是我们实跑核证过的；"provider/model 那一行我没有证据"这句话就是字面意思——我没查过，不是我查过说没有。 倒推那一步值得你自己做一遍。

[Bruce-anle]

感谢你花时间把这份 RFC 拆开分析，也分享了 pi2dsh 中实际验证过的经验。尤其感谢你明确区分了“已经实跑确认”和“还没有调查”的部分：这帮助我看清了原提案里哪些是目标行为，哪些只是尚未充分验证的实现判断。

你提出从最终请求倒推数据流，再判断是否缺少入口，这个建议我接受。原文仅凭 descriptor 和 setup 的位置，就推到“无法可靠替换完整策略”，证据确实不够。provider/model 到最终请求的路径，我目前还没有完成对应的实跑验证，因此不能据此断言必须新增一个 resolver。

我也想把我们具体希望实现的目标说明白。我们已有一套工程工作方法：主代理负责组织、派发和验收，子代理持续承担具体工作。一个子代理可能经过多次执行、审查反馈和返工才完成任务。因此，我们希望它能保留自己的会话历史和工作上下文，同时在后续执行时，按明确规则使用当前适用的执行策略。

一个具体场景是：

1. 子代理使用路由 A 开始工作，已经积累了上下文，但任务尚未完成。
2. A 随后不可用，用户或配置管理方将适用于该子代理的路由调整为 B。
3. 当同一个子代理需要新建 Activation 来继续工作或恢复失败执行时，能够保留原会话历史，按更新后的策略使用 B，避免再次因为创建时保存的 A 而失败。

这里并不意味着父会话切换模型后，所有子代理都必须跟着切换。子代理可以有自己的显式配置；关键是明确它应当采用哪份策略、何时重新解析，以及最终实际使用了什么。仍在运行的 Activation 收到后续消息，与需要新建 Activation 的追问、重试或冷恢复，也应分别判断。

你对 system-prompt/assemble 的探针，已经为提示词和模型可见工具声明的修改提供了具体证据。我认同应当据此拆分原提案，避免把路由、提示词、工具声明和实际执行权限统称为一个缺口。至于实际权限是否同步生效、现有入口能否满足所需的生效时点，还需要分别验证；不能仅凭声明修改成功就认为整套策略切换已经成立。

如果这些行为可以通过现有官方入口可靠实现，那就应复用现有机制，并删减 RFC 中重复的部分；如果需要调整底层的解析时机或职责划分，我也支持围绕具体缺口讨论。原文中的全套 resolver 是一个实现设想，不应先把它当成结论。

你提到 pi2dsh 保留 DSH 原生生命周期、只做必要适配的实践，也很有参考价值，这与我们的方向一致。如果方便，能否贴一下实时路由的端到端 example？我理解它目前验证的是创建路径，但它仍然是追踪实际路由来源的有用起点；followup、retry 和 cold-resume 则需要各自的证据。