《DeepSeek Harness 架构解读：三层组合与「一切皆插件」》 把 dsh 读成三层：Profile 叠 Bundle 拼插件树，Turn 的数据流过 Session 日志，扩展默认旁挂 Service、订事件，而不是改 agent loop。那篇「二次开发」对照表里出现过 subagent、dsh-agent-teams、dsh_workflow------表上能看出 Harness 能装这些能力，但没有展开委派在运行时怎么走。
《DeepSeek Harness 背后的 Cordis：插件卸载与 Agent 自我进化，为什么都要「时空可组合」？》 从 agent harness 层看这个问题：论文 §1.2.2 写现代 harness 要在运行时组合工具、Session、多 Agent 编排；若 Agent 高频改自己的组件，装卸插件与依赖响应就不只是体验问题，而是服务能否连续跑、失败能否收回。Cordis 用 ctx.effect() 与 inject 回应时间维与空间维。两篇读下来，Turn/Session 主干有了，论文也把多 Agent 编排列进了 harness 该做的事------但 dsh 里对应哪些 API，还没对上号。
官方说明里 ctx.subagents、workflow tool、ctx.jobs 和社区里的 AgentTeams、Workflow 插件会一起出现；名字都沾 Agent 或流程，读 README 时很容易以为自带编排工作台。Harness 写得很直白：subagent 和 bash 一样，是 loop 旁挂的可选 capability。父 agent 通过 tool 派出去的是 Session 树上的 child，不是 UI 里多开一个聊天 Tab。官方一次性 workflow tool 和社区 @dsh-external/workflow 也不是同一层。
本文想要分享的是，把这些入口拆开对照：one-shot 和 continuable 子 agent 生命周期差在哪，各 Provider 把 child 派到哪里，官方 workflow 与 jobs 各覆盖哪段流程，社区 bundle 是在 subagent 上补团队协议，还是在 workflow 上补可保存流程。下文按 Harness 仓库当前实现来写；社区插件只作举例，不是默认自带。项目还在 developer preview，细节随时可能跟 changelog 走。
Harness 没有内置编排器
Harness 把「委派给另一个 agent」做成可选 capability 接口（文档里叫 seam，即一条可替换的能力边界），挂在 loop 旁边。模型通过 tool 触发委派；child 在 Session 树里挂在父 Session 下面，各自有 transcript，不是跟父 agent 共用一段对话上下文。
你在评估 dsh 能不能做 OpenClaw 式「父 bot 派子 bot」时，能委派------走 tool、独立 Session、可按需持久化这条链。团队面板、流程落盘、暂停恢复如果也要，官方 subagent、workflow、jobs 往往覆盖不到，得再装社区 bundle。
subagent 和 workflow 不是一回事
ctx.subagents、官方 workflow tool、ctx.jobs，再加上社区里叫 Workflow 的插件，名字相近，很容易当成同一套「编排系统」。其实各干各的：
subagent 解决委派：父 agent 通过 tool 把活交给 child，child 自带独立 Session。官方 workflow 解决编排：同一轮里跑一段脚本，脚本里可以并行调多个 subagent，跑完把 JSON 结果交回父 tool------它自己不保存流程，也不能 pause 后接着跑。jobs 解决后台：bash 或 subagent 之类长任务先注册成 JobId，父 turn 可以先返回，稍后再 read / wait / kill。
社区插件又是另一套。dsh-agent-teams 在 subagent 之上加队长、任务依赖和成员私信；dsh_workflow 在官方一次性 workflow 之上加命名流程、run 落盘和 resume。它们可以同 Profile 一起装，但不替换 ctx.subagents，也不替换官方 workflow tool。
对照如下：
| 层次 | 官方入口 | 典型用途 | 生命周期特点 |
|---|---|---|---|
| Subagent 委派 | ctx.subagents + dsh-tool-subagent |
父 agent 把一段工作交给 child agent | child 是独立 Session；分 one-shot 与 continuable 两种 |
| 动态 workflow | ctx.workflowEngine + workflow tool |
模型写一段编排脚本，引擎 fan-out 多个 child | 单次 run、caller 持有 WorkflowRun；官方明确无 checkpoint/resume |
| 后台 jobs | ctx.jobs + job_* 工具 |
bash、subagent 等长任务后台跑，父 turn 可先返回 | 按 JobId 读输出、kill、wait；owner 绑定 Session 授权 |
| 社区：团队协议 | 如 dsh-agent-teams bundle |
Captain、成员、任务依赖、邮箱式 DM | 文件状态 + continuable subagent；非官方 |
| 社区：流程资产 | 如 @dsh-external/workflow（dsh_workflow） |
命名 capsule、run graph 落盘、pause/resume | 不替换官方 workflow tool；非官方 |
官方功能→机制对照里，subagent、workflow、jobs 各占一行，且都不改 agent loop------靠挂 tool 和 capability 做编排，不去改 Turn 状态机。
Subagent：多 Agent 从哪开始
为什么是 seam，而不是 loop 内置
subagent 与 bash 一样，是一项可选能力，类型定义不在 core/agent loop 里。它与 bash 的不同在于：ctx.subagents 允许多个 Provider 实现按名称共存（类似 LLM 适配器注册表），而 bash 在同一 context 里通常只有一个执行器。
Service Definition 在 dsh-subagent 包（ctx.subagents + 一套词汇表）。Service Provider 是多个兄弟包；面向模型的 Consumer 主要是 dsh-tool-subagent（按配置暴露某一个 Provider 给模型），以及可选的 control/report 工具包。扩展 subagent 不需要 fork agent-loop，只需在 bundle 里加载对应 Provider 和 tool 插件。
One-shot：派活、干完、交差
One-shot（单次）子 agent 走 SubagentProvider.start()：父 agent 在 tool 调用里给出描述和 prompt，Provider 在 child Session 里跑完，把结果返回给父 turn。适合「帮我把这段代码审查完，给我一个结构化结论」这类有明确结束点的委派。
启动请求里可以带若干可选约束，但 Provider 不支持就直接报错（SubagentError('UNSUPPORTED_CAPABILITY')），不会静默忽略：
outputSchema：要求 child 返回符合 JSON Schema 的结构化结果（object-rooted schema 子集）；toolFilter：child 只能看到、只能执行父 agent 允许的工具子集（进程内后端在创建窗口里做 scopedtools.restrict()）；persona：给 child 单独的系统 persona 片段，覆盖 deployment 级 persona，仅对该 child 生效；maxDepth：委派深度上限，防止无限 spawn。
父 agent 传入的 signal（AbortSignal）是贯穿启动前与启动后的唯一取消通道：启动前触发则清理部分资源并拒绝；启动后触发则取消 child 剩余 turn 工作。
Continuable：持久 Session + 可反复发消息
Continuable（可继续）子 agent 是另一条路径：child 先对应一份持久化的 Session，进程内至多有一个 Activation（激活）时段------此时重建出的 child Agent 驻留在内存里，可以执行多个 FIFO turn。Activation 不是「一次请求」：child 活着、且其 spawn 的后代还没 dispose 完时，Activation 可以一直占着。
continuation manager（继续执行管理器）负责 Activation 准入、父级鉴权、冷恢复（cold resume）、interrupt 等；agent loop 仍负责 turn 排序与执行。可继续路径不会再进入 SubagentProvider.start()；Provider 只在第一次创建 Activation 时通过可选的 prepareContinuable 贡献 detached 的创建 spec（例如是否 seed 父 Session 日志前缀）。
开发侧常用三个入口：startContinuable() 建立 child id，初始 prompt 进入 child inbox，返回 { childId, messageId }，不等待 child turn 跑完；followup() 给已有 continuable child 再发一条消息，Activation 在跑则入队，在等待则唤醒，没有 Activation 则冷恢复后再入队；interrupt() 对 live child 发 cancel，保留 inbox 里尚未 claim 的消息，已在进行中的 turn 不会把已 claim 的工作塞回队列。
child 还可以通过 report 通道把内容送回 direct parent：delivery 分 quiet（注入 parent，不唤醒新 turn）与 wakeup（走 followup，parent 会多一个 turn）。权限看 direct parent 的 Session 关系与 live 祖先链，不是「任意 agent 都能给任意 child 发消息」。
Provider 选型：进程内还是外部产品
默认 bundle 里常见的是进程内 Provider；Harness 列出的 Provider 类型包括：
| Provider 方向 | 含义 | 典型场景 |
|---|---|---|
| spawn-in-process | 同一 dsh 进程里新建 child Agent | 与父 agent 共享 harness 工具链、沙箱策略 |
| fork | 进程内新建，可 seed 父 Session 日志前缀 | 需要 child 带上父会话部分上下文的委派 |
| acp / codex / claude-code / dsh-sdk | 委派到外部 Agent 运行时或产品 | 把活交给 Claude Code、Codex 等，而不是在 dsh 里再跑一轮 loop |
选 Provider 时要想清：你要的是同一套 tools/approval/Session 语义，还是把 turn 交给别的栈。后者能复用 dsh 的会话管理与审计边界，但 child 侧行为由外部产品决定，不能假设与 web UI 里看到的完全一致。
控制面工具：send_message、list_agents
除「委派干活」的 subagent tool 外，可选插件还提供全局控制 tool：send_message、interrupt_agent、list_agents。它们面向 continuable child 的协调，与 UI 枚举 Session 树的语义不完全相同------例如 list_agents 适配器只保留 continuable 条目，one-shot child 不会出现在这个列表里；状态词也会细化为 running / idle / ready（ready 表示只在存储里、可冷恢复）。
列表里的「运行中」只表示 Session 记录是否仍在内存 store 里存活，不保证 followup 一定成功：所有权冲突、parent 已 dispose 等仍可能在发送时被拒绝。能不能发出去，以 send_message 为准。
Session 树：审计与 fork 仍然适用
每个 subagent child 在持久 header 里带有 origin: 'subagent' 与 parentSession。listChildren(parentSessionId) / listDescendants(rootSessionId) 从 Session store（及可选持久化后端）枚举树，不加载 Agent 就能列出 direct child 与整棵后代树。
Subagent 身份还会写入 Session 日志里的 subagent/descriptor 事件。该事件只进日志、不进 model history（不含 surfaceOp），用于跨 compaction 保留身份投影；fork 时 seed 边界与 descriptor 的 last-wins 折叠规则另有专门约定。child 是谁、用的哪个 Provider、one-shot 还是 continuable，可以审计、可以投影到 UI，但不会悄悄混进模型读到的 transcript。
这与第 1 篇强调的不变量一致：要做 transcript、replay、fork，仍订 Session 事件；agent/* 只适合当轮拦截和 UI 状态。多 Agent 没有另起一套日志当事实源。
官方 workflow：一次性脚本编排
Harness 里的「工作流」，先要分清官方动态 workflow------它不是 DAG 平台，也不是社区 capsule。
机制入口是 ctx.workflowEngine + worker-thread 引擎 + workflow tool。模型（或上层 tool）提交一段编排脚本；引擎在隔离环境（当前实现是 worker thread）里执行脚本，脚本可以 fan-out 调 subagent。WorkflowStartRequest 里带 parent，所以每个 child 仍归因到 invoking agent；可选 subagentProvider 为整次 run 固定 Provider，脚本本身不能换 Provider。
一次 run 返回 WorkflowRun：caller 持有它，必须 dispose()；result 不会 reject，失败以 stopReason: 'error' 落在结果里。workflow 事件（workflow/start、workflow/phase、workflow/agent-start 等）是只读观察，监听器拿不到 cancel/dispose 权限。
与 subagent 直接委派相比，workflow 适合单次、结构化、脚本化的并行或 pipeline：例如同一 turn 里让模型写一段 parallel() / pipeline() 逻辑，强制 child 输出 schema，再由脚本汇总 JSON 结果返回给父 tool。官方 workflow 目前还有这些硬限制：
- 仅 foreground collection：caller await 一个 live run；后台 start/poll、detach 收集 deferred；
- 无 journaling/resume：进程重启不能接着跑 half-done 的 workflow run；
- 无 saved/nested workflow：seam 只启动 caller 当场 supplied 的 script，脚本里不能再调
workflow()嵌套； - 无跨 child 的 token 预算词汇：有并发、child 数量等硬 cap，但不统计全 run 的模型 token。
ctx.jobs：长任务与 subagent 的另一条出口
ctx.jobs 是后台任务运行时：Producer 注册 kind（内置 map 含 bash、subagent 等），start 后返回 JobId；父 agent 可通过 job_* 工具读增量输出、wait 或 kill。Job 与 owner Session 绑定授权：agent dispose 会 cancel 其拥有的 job。
jobs 与 continuable subagent 的 Activation 不是同一层：jobs 负责注册表、生命周期和输出 cursor；continuable 负责持久 Session、inbox FIFO，以及父子 report/followup。Harness 里 bash 后台跑、subagent 后台跑，都走 jobs；社区 workflow 插件在长跑时也会尽量把 run 挂到 ctx.jobs，但 durable run id 仍由插件自己的 store 维护。
同一 turn 里要等结果，用 subagent tool 或 workflow run；要先拿 handle、稍后再读输出，用 jobs（或 continuable + followup，看你要 Job 语义还是对话语义）。
社区两层：团队协议 vs 流程资产
GitHub 上已有两类常见的第三方 bundle（需 pin DSH 快照，见各仓库 compatibility.json）。第 1 篇提过名字；这里只讲它们和官方原语差在哪。
dsh-agent-teams：Captain + 任务图 + 邮箱
dsh-agent-teams 在 continuable subagent 之上加团队协议：当前 Session 当 Captain，创建带角色的 continuable 成员，把目标拆成带依赖的任务，通过 mailbox 消息唤醒成员；Web 活动面板读 .agent-teams/ 目录下的文件状态并订 live 事件。README 里写明的边界包括：同一 Captain 同时只能有一个活跃队；状态文件在单 dsh 进程内串行化，不协调多进程同时写；成员只有被 wake 后才动，模型偶发忘记更新 task 状态是已知限制。
它不需要单独 workflow 引擎：协调靠任务状态机 + DM，执行靠 ctx.subagents。
dsh_workflow：可命名、可落盘、可 pause/resume
dsh_workflow（安装名 @dsh-external/workflow）README 开头就说：不替换 DSH 已有的一次性 workflow tool，而是在上面加流程产品层------版本化 capsule、.dsh/workflow-runs/ 下 run graph 与 events.jsonl、rerun/resume-run、审批与 QuickJS 沙箱执行生成脚本等。子任务仍通过 ctx.subagents spawn；斜杠命令走 ctx.commands，与 tool 入口共用同一引擎。
如果你烦的是「每轮对话都要重新教模型怎么并行审查」，workflow 插件适合把策略存成 capsule；如果你要的是「几个角色协作、互相发消息、看清谁卡在哪个 task」，agent-teams 更合适。两者可以同 Profile 共存，但解决的不是同一层问题。
怎么选
| 你的需求 | 更合适的官方机制 | 什么时候要社区插件 |
|---|---|---|
| 单次委派，要结构化 JSON 结果 | one-shot subagent + outputSchema | 一般不必 |
| 后台研究员，多轮来回补材料 | continuable subagent + followup/report | agent-teams 若要任务板 + DM |
| 同一 turn 内脚本化并行多个 child | 官方 workflow tool |
若要保存脚本、pause、成本账本 → dsh_workflow |
| 长跑 bash / 子 agent，父 turn 先结束 | ctx.jobs |
workflow 插件也会挂 job，但 run 证据在插件 store |
| Lead/Sub 固定编排、内置评测叙事 | Harness 无官方等价物 | 自建或参考其他产品 |
还有成本：每个 child 都是独立 Turn/Session，token 与审批次数随委派深度往上乘；continuable child 占内存与 store；workflow 插件 governance 再强，也不能让官方 workflow run 在进程重启后自动续跑------那是官方 seam 目前明确不做的。
与 Cordis「时空可组合」的衔接
Cordis 论文导读 讲动态装卸组件时，环境修改要能撤销、依赖要能响应。多 Agent 会把 spawn/dispose 频率拉高：每挂一个 subagent Provider、每 dispose 一个 child Activation，都在考验 ctx.effect() 与 Session 边界。Harness 用 Session 树和 descriptor 日志记录身份与 lineage，不在 loop 里藏全局单例------这和「模型可见 ⟺ 已记录」是一回事。
这不等于多 Agent 没有代价：child 写外部文件、调外部 API，仍在 Cordis system boundary 之外；parent 卸载插件也撤不回 child 已发出的 HTTP 请求。编排越频繁，越要在产品层设计 approval 与 Provider 隔离，别指望 seam 会自动帮你收拾干净。
动手前先查两件事
先看本机加载了哪些 subagent 相关插件：
css
dsh --profile web --dump-config在输出里搜 subagent、workflow、jobs 相关 id，确认 Provider 与 tool 是否如预期（不同 Profile/home patch 组合结果可能不同）。
读 child Session 时订 Session 事件，别只盯 parent 的 agent/*。fork、replay、compaction 都认日志；parent UI 上「子 agent 在跑」的 live 状态，不能替代 transcript 里的 tool/result 与 subagent descriptor。
收尾
DeepSeek Harness 对多 Agent 的回答，核心就两点：委派走 ctx.subagents，审计靠 Session 树；工作流分官方一次性 script 和社区可持久 capsule 两层。它不是开箱的多 Agent 工作台，但讲清楚了一点------child 也是完整 Agent。团队 UI、流程库、复杂编排，通常是在这些官方接口上装社区插件，而不是去改 agent-loop 源码。
参考
1 DeepSeek Harness（developer preview）。
2 NanmiCoder/dsh-agent-teams。
3 icetomoyo/dsh_workflow（npm：@dsh-external/workflow）。