DSH plugin 怎么加 subagent 提供方？DeepSeek Harness 的 ctx.subagents

DSH plugin 新增 subagent 提供方，是往 ctx.subagents 这个按名注册表里注册一个传输层实现；它与其他能力 seam 的区别在于「同一上下文中可共存多个提供方」，而不是只允许一个执行器（来源）。 本文面向 DSH插件 / DeepSeek插件 作者，讲清注册表与两类能力、SubagentProvider 要实现的接口与如何向模型暴露，以及六种官方后端的差异与选型；用户侧怎么用与选后端见 subagent 委派配置，这里只讲开发者要实现的规范。

DSH plugin 的 ctx.subagents 提供方注册表与两类能力

subagent seam 让一个 agent 将工作委派给子 agent；它是可选能力、不属于 agent loop，并且因为「同一上下文中可共存多个提供方实现」而与 bash 之类的单一执行器不同——它遵循 LLM 适配器注册表模式（来源）。 官方把角色分成三层：

1. Service Definition — dsh-subagent 提供 ctx.subagents 及其词汇。
2. Service Provider — 六个兄弟包：dsh-subagent-spawn-in-process、dsh-subagent-fork-in-process、dsh-subagent-acp、dsh-subagent-codex、dsh-subagent-claude-code、dsh-subagent-dsh-sdk。
3. Consumer — 面向模型的有 dsh-tool-subagent（按提供方委派）与可选的 dsh-tool-subagent-control（全局 send_message、interrupt_agent、list_agents）。

能力分两类，发现方式也不同：

• 启动时能力用静态描述符 SubagentCapabilities（agentOptions、outputSchema、depthLimit、toolFilter、persona）公布，服务会在单次 run 存在之前即行检查；请求依赖提供方不具备的能力会被明确拒绝（SubagentError('UNSUPPORTED_CAPABILITY')），绝不会被接受后静默忽略（fail loud、不静默降级）。这些 flag 只描述单次 start() 路径。
• 可继续能力由唯一一个可选方法把关：SubagentProvider.prepareContinuable。方法存在即为能力，并以 TypeScript 的类型收窄作为发现机制；没有它的提供方会被拒绝发起可继续 start。

DSH plugin 的 SubagentProvider 接口与向模型暴露

每个提供方都是一个具名的子 agent 传输层，多个提供方可以共存；服务可以在不同 child 上并发调用同一提供方，提供方须隔离 operation-local 可变状态（来源）。 要实现的接口如下：

• name — 唯一注册名（如 spawn、fork、acp）。
• capabilities — 上述启动时能力描述符。
• inheritsParentContext — 仅描述对话种子注入（fork: true；spawn 与 acp: false），使消费方能生成准确的面向模型措辞，不暗示继承了工具、服务或权限。
• agentRouteDefaults? — 可选、不可变的提供方自有 provider/model 路由，供消费方在预检前合并模型与工具覆盖。
• start(request) — 建立一次性 child 并在发布后返回句柄；服务已校验所有请求的能力并解析 request.descriptor。
• prepareContinuable?(request) — 可继续能力关卡，只返回分离的创建输入（是否用父级历史种子），不携带 Agent、handle、提示词投递、结果、dispose 或恢复操作。

注册与暴露：实现后用 ctx.subagents.registerProvider(provider) 注册，返回精确的 Cordis effect disposer；注册是 effect 作用域且 HMR 安全。移除提供方会阻止新的 start，但不会撤销已经返回给持有者的 run。提供方本身只管传输，面向模型的是消费方——dsh-tool-subagent 按提供方委派，暴露一个已配置的提供方。

服务方 start() 会以已发布的 run fulfill：服务铸造唯一 runId、快照 local、观察结果、emit subagent/start，并返回同一个 run。start() rejection 意味着未发布资源已清理，且不会 emit 生命周期事件对；而发布后的结果 rejection 会结束已经 emit 的事件对。subagent/start 与 subagent/end 仅用于观察，且各自隔离监听器异常。

DSH plugin subagent 提供方的差异与选型

同一个 SubagentProvider 接口之后，从「新建一个子 agent」到「把一个轮次委派给另一个产品」都有实现（来源）。 差异集中在种入与能力匹配：

1. 进程内 spawn / fork — 通过 parent.ctx 创建普通单次 agent，把取消信号传入核心创建流程，并用 AgentHandle 进行 dispose。fork 会传入父级日志的一段平衡的已完成轮次前缀（直到并包括其最后一个 turn/end，因此种子从 seq 0 连续、可被回放接受）；spawn 不种入。
2. 外部产品后端（acp / codex / claude-code） — 会在启动传输前拒绝 agentOptions，因为它们无法把父级 Agent 选项合并进外部产品。
3. DSH SDK 后端 — 把四个 Agent 路由字段合并到实例默认值之上，并在子运行时初始化期间校验。
4. 一次性 vs 可继续 — 单次走 start() 返回 SubagentRun（一个只有一个结果、可 dispose 的前台委派，result 在子级失败时以非 completed 的 stop reason resolve，只有无法表示的基础设施故障才 reject）；可继续对话根本没有 run——继续执行管理器直接持有它们的 AgentHandle，提供方只通过 prepareContinuable 参与初始创建 spec。

选型判据：只需要一次性委派（一个结果、随后 dispose）就用 start()；需要多轮继续对话就让提供方实现 prepareContinuable，把后续生命周期交给继续执行管理器。

写完自检三项：name 是否唯一、capabilities 是否如实描述了 start() 路径支持的选项；需要继续对话时是否实现了 prepareContinuable 而不在 start() 里假装；inheritsParentContext 是否只声明了对话种子注入、没有暗示继承权限。想找已有哪些 subagent 插件可对照，你可以在 DSH Plugin Hub 检索；扩展点归属判据见 功能→机制映射。