第 2 卷

run.result 才拿到。

这么分是刻意的：发布这一刻，所有权（ownership）从提供方转给父 agent：发布前由提供方负责组合（compose），发布后由父 agent 持有句柄、负责 dispose。这是“谁拥有”，不

是“谁在跑”；子 agent 的轮次一直是它自己在跑。同时“建没建成”也就定了：成了句柄到手，败了 start() 直接拒绝，没有中间态。

取消也分两段：request 里带的 signal（取消信号）在发布前中止会让 start() 回滚后拒绝，发布后中止只取消剩余轮次，已返回的句柄仍能 dispose。

start(name, request) 有两个参数：name 选提供方，request 是请求对象，字段如下：

表格里 outputSchema、maxDepth、toolFilter、persona 这四个字段，对应四种能力，不是想要就有，还得提供方支持；不支持的，start() 会在创建前就拒绝，而不是等跑

定。

而工具、人设的继承则是 start() 内部自动做的：进程内提供方创建子 agent 时，会执行组合自父级（composeFrom() 方法），让它默认继承父级已挂载的 preset（dsh 里预设好

的工具 + 人设）；表格里的 persona、toolFilter 就是在这个默认基础上做覆盖：

persona 顶掉人设、toolFilter 裁掉部分工具。

上面这些是给父 agent 代码用的；面向模型，dsh-tool-subagent 把 start() 包成 subagent 工具，底下还是同一个 seam。

第三个关键点：会不会无限往下委派。委派会成树：父 agent 能同时委派多个子 agent，子 agent 还能再委派孙子。不封顶的话，一个子 agent 能无限往下委派，整棵委派树会失控地

疯长。所以委派有深度上限：dsh-tool-subagent 的 maxDepth（默认 3，父 agent 下面最多再有子、孙、曾孙三层），到顶后工具仍可见，但每次启动都会被拒、返回出错结果。

这个深度记在会话头（SessionHeader，会话的元数据）里、重启不丢；否则子 agent 重启后会忘了自己第几层、把自己当顶层，maxDepth 封顶就失效了。进程外提供方例外：它

们在自己的进程里管递归预算（配 maxDepth: 'provider-managed'），不在这里卡。

把这三个关键点合起来看，委派是异步、有界的：父 agent 发出去的是活，结果异步回传；

跑在哪由 seam 换、跑多深由 maxDepth 锁定。

怎么协作：单向等待与双向互动

活交出去之后，父 agent 和子 agent 怎么协作，两种子 agent 不一样。

一次性（one-shot）子 agent 就是前面说的：父 agent 只等结果，中间不掺和。

可继续子 agent（continuable，它的创建本讲不展开）则不然，父 agent 和子 agent 是双向

interrupt() 中断当前这一轮，只停这一轮，排队里的活还在，之后还能接着跑。

reportFrom() 主动报告，子 agent 有事自己上报给父 agent。

这种协作一直持续到它结束。

怎么回收：结果回传与资源释放

委派不是终点，还得回收。回收有两件事：结果回传、资源释放。

回传的结果是一个对象（run.result），三个字段：

字段含义

output子 agent 最终说的话

structured可选的机器可读结果（指定了 outputSchema 才有）

stopReason它为什么停：completed / aborted / error / max-tokens / refusal

stopReason 这五个值里，只有 completed 是干成了，其余四个都是没干成，output 可能不完整。所以父 agent 判成败得看 stopReason，不能光看 output。

失败本身不会让 run.result reject：它照常完成，只是 stopReason 是非 completed 值。只有一种情况会 reject：基础设施故障，那种故障没法归进 stopReason 的五个值，所

以连结果对象都拿不到。

示例里子 agent 跑完一轮，stopReason 是 completed，output 是它的最终文本：