创建成功，落在哪个时间点？
六步比较正常创建与监听器失败。切换场景保留当前步骤，重播从头观察；图中的间距不表示耗时。
01 / 公告结果
两个对象已可查，还要等公告完成
setup 与 commit 在未发布阶段完成。两个 Registry 插入后，创建监听器按序执行，最后才把 handle 交回调用方。
已经送达的 created，需要配对 disposal
示例在第一个 agent/created 监听器抛错。后续监听器跳过，工厂完成清理并撤回登记，原创建 Promise 拒绝。
setup、Registry 插入、公告与 handle 交付是不同时间点。无 JavaScript 与静态模式保留全部连线。
工厂准备 Session、驱动器和预先登记的清理入口。
新 Session 和驱动器先处于未发布状态。
回调完成时，两份 Registry 仍查不到新实例。
这一步成功，不代表后面的公告也会成功。
Session 和 Agent 都入库，随后发出 session/created。
两个对象都已入库，Session 公告已经开始。
agent/created 监听器开始执行；外层 create 仍未完成。
第一个 created 监听器抛错；后续监听器不再执行。
串行派发结束，初始化维护任务可以收尾。
已经观察到创建的消费者仍需要看到配对 disposal。
调用方拿到 agent 与 dispose，之后再驱动普通工作。
停止活动、释放 Scope 与写 handle、解除登记，再拒绝调用方。
- 01请求创建与准备调用方 → AgentLoop
工厂准备 Session、驱动器和预先登记的清理入口。
请求创建与准备调用方 → AgentLoop新 Session 和驱动器先处于未发布状态。
- 02setup / commitAgentLoop → 组合回调
回调完成时，两份 Registry 仍查不到新实例。
setup / commitAgentLoop → 组合回调这一步成功，不代表后面的公告也会成功。
- 03插入并公告 SessionAgentLoop → 活 Registry
Session 和 Agent 都入库，随后发出 session/created。
插入并公告 SessionAgentLoop → 活 Registry两个对象都已入库，Session 公告已经开始。
- 04串行 Agent 公告活 Registry → 组合回调
agent/created 监听器开始执行；外层 create 仍未完成。
Agent 监听器失败活 Registry → 组合回调第一个 created 监听器抛错；后续监听器不再执行。
- 05全部监听器完成组合回调 → AgentLoop
串行派发结束，初始化维护任务可以收尾。
传播创建错误组合回调 → AgentLoop已经观察到创建的消费者仍需要看到配对 disposal。
- 06交回 AgentHandleAgentLoop → 调用方
调用方拿到 agent 与 dispose，之后再驱动普通工作。
清理后拒绝创建AgentLoop → 调用方停止活动、释放 Scope 与写 handle、解除登记，再拒绝调用方。
02 / 完成后检查
固定实验轨迹，不是实时运行的 dsh。
准备 → setup → commit → Session / Agent 入库 → session/created → agent/created 全部完成 → create 返回
准备 → setup → commit → Session / Agent 入库 → session/created → agent/created:first 抛错 → agent/disposed → session/disposed → create 拒绝
AgentRegistry：可查 SessionStore：可查 调用方：持有 AgentHandle 还没有自动发出模型请求。
AgentRegistry：已撤回 SessionStore：已撤回 调用方：没有拿到成功 handle 外部消费者已收到的通知无法倒带。
查看来源与省略的路径
真实实验 03、08 的正常 / 监听器失败轨迹。图中合并了持久化获取、取消检查和清理内部步骤；setup 失败、Session 公告失败及 owner 卸载见正文实验。
agent-loop/src/index.ts:650–666, 789–834 · agent/src/index.ts:537–559