第 4 卷

发布后失败：通过返回的 run 结算，reject 会被 settleRun 兜住转成 failed。

所以父 agent 拿到的是一个失败结果，不是悬空的 promise。

记录都在：子 agent 会话是 append-only，且部分输出在取消/截断之后依然保留（driver 里明确注释了 partial answer survives cancel and truncation）。

一点边界：这里的"不傻等"指失败路径都有回收。反过来如果子 agent 卡住不返回，等待边界由 req uest 里带的 signal 决定——调用者不取消，就会一直等。

疑惑二：一次性 vs 可继续

你的理解基本对，只有一处要修正：settled 不是子 agent 自己给的。

它是 ctx.subagents 派生判定的，依据是两条客观事实：一是子 agent 已静默（没有活跃 turn、没有待办 inbox），二是它拥有的子都 dispose 干净了。两条都满足 → settled → 由 ctx.subagents

执行释放（dispose 实例 + 移除 Activation）。子 agent 的角色只是"自己停下来"，并不主动声明 s

ettled。

另外"一次性在消息回传后直接结束会话"要精确一点：不是自动结束，是父 agent 必须手动调 run.di spose()（这是兜底，无论成败都要调）。dispose 会先取消剩余工作、等它彻底停下，再连临时会

话一起释放。

两者的区别可以这么记：

会话性质：一次性的是临时的，用完即弃；可继续的是持久的，进程重启不丢。

谁来释放：一次性的靠父 agent 手动 dispose()；可继续的由 ctx.subagents 判到 settled 后自动释放。

释放什么：一次性的释放实例 + 会话；可继续的只释放进程内那个实例（Activation），会话一直保留。

结果怎么回传：一次性的父 agent 直接 await run.result；可继续的是 ctx.subagents 往父 agent 的消息队列投一条结果通知，而且必须在释放之前投——父 agent 名下没子了就会被判定"可以结束"、

接着被回收，回收之后通知就无处可投了。

最后，"只增不删"和"删会话"不矛盾。append-only 说的是会话里的事件不会被删；"删会话"删的是整个临时容器。而且删它不丢信息——结果已经作为工具结果回传、写进父 agent 的会话了。