Inbox、Steering 与 Continuation

结论：Inbox 是可回放的调度协议，不是聊天输入框的临时数组

其关键优点不是支持“运行中再发一句”，而是把待处理输入本身写进 Session Event Log：稳定 MessageId、插入、编辑、取消、认领、恢复和 UI 分类都能围绕同一事实工作。代价也很明确：已接受只表示 Inbox 已接收，不表示已执行、已产生回复，甚至不必然表示已经 fsync；running 表示整个 driver 活动，也不是某一条消息的完成句柄。

1. 先拆开六个容易混名的机制

2. 队列类别不是 Message role：身份、来源和调度位置彼此正交

进入 Inbox 的对象仍是统一的不可变 UserMessage：有稳定 id、role: user、精确 content blocks 和必填 source。MessageSourceMap 可由插件扩展；freezeMessage 会 structured-clone 后深冻结，创建函数则分配新的 UUID。INBOX-MESSAGE-IDENTITY

因此，“steering message”不是第三种消息结构。它是 user-source 消息先从 next-step 被认领这一历史事实；同一个 role 的非用户 source 则会被 UI 解释为 context。

3. 两个列表由同一种 durable splice 重建；提交先于 live mutation

agent/inbox/spliced {
  target: next-turn | next-step,
  start,
  removedCount?,
  inserted: full UserMessage[],
  outcome?: canceled
}

这也是为什么 Web projection 不需要自己维护一套命令队列：它读取 Agent 当前列表，再把正在发布的 splice 应用一次，就得到权威 post-state。

4. Claim 有严格优先级：全部 next-step，然后至多一个 next-turn

每个提议 Step 的 claim(target)
  1. 删除并取得全部 next-step（按 FIFO）
  2. 若 target = next-turn，再删除 next-turn 头部一条
  3. 按上述顺序逐条发 claimed(message, turn)

Turn 第一个 Step：target = next-turn
同 Turn 后续 Step：target = next-step

这给出一个常被忽略的组合：Turn 的第一个请求可以同时包含早已停放的注入上下文、steering，以及该 Turn 自己的普通 prompt；顺序固定为 next-step 批次在前、next-turn 头部在后。

5. Follow-up 保证普通输入的 FIFO Turn 映射，但 status 不会逐 Turn 闪烁

followup(message) 等价于 send(message, next-turn, true)。空闲时 wake 会同步把 phase 预留为 running，再异步启动 driver；运行中只需排队，因为活着的 driver 在当前 Turn 关闭后会检查 hasPending，换新 AbortController 并继续下一 Turn。INBOX-SEND-MAP

6. Steer 是“最近 Step + wake”，不是对正在飞行请求的流内追加

steer(message) 写入 next-step 并请求 wake。若 Agent 正在正常运行，wakeDriver() 不另开 driver：当前 driver 应在下一 Step 边界 claim 它。若 Agent 空闲，steer 自己打开一个 Turn；因此底层 API 并不要求 running，空闲 steer 最终仍会成为该新 Turn 的第一个输入，只是 replay 分类保留为 steering。INBOX-DRIVER-WAKE

Web composer 只在 ordinary session 的 running 状态提供 steer 选择，减少“空闲 steer 其实新开 Turn”的意外；但 Host 的直接 session.prompt(mode: steer) 仍接受该底层语义。

7. Inject 是“最近 Step但不 wake”；是否同 Turn完全由落点决定

8. Pre-step 先消费、后准入：reject 不会自动把原消息退回

turn/start
  → inbox.claim(target)                 // durable pure deletion
  → assemble system prompt
  → agent/pre-step waterfall
       ├─ enter(messages) → step/start → user/message* → model
       └─ reject          → turn/end(blocked)，无 Step

如果 assemble 或 listener 抛错，Turn 以 error 关闭；同一时刻尚未 claim 的 next-turn 与后来到达的 next-step 仍在队列，但 driver 停止。这里选择的是“input claim 是提交点”，而不是“模型调用成功才消费”。

9. Tool continuation 与 turn-stopping 都复用 next-step，却拥有不同生产者

模型给出 tool calls 后，结果按模型顺序写入日志；每个 finalized result 的 additionalContexts 随后依次 splice 到 next-step。工具未声明 concludesTurn 时，loop 在同一 Turn 开下一个 Step；声明 concluded 也不会越过已经存在的 next-step 输入。INBOX-TOOL-CONTEXTINBOX-TOOL-CONTINUATION

10. running 属于 whole driver；maintenance 对外仍显示 idle

11. Cancel 要分“信号”“待处理输入”“已认领输入”三层看

12. Abort-to-idle wake latch 修复了取消收敛窗口，但仍保留一个更窄的退休缺口

活跃 Turn 已 abort，但尚未 idle
  ├─ 此前已排队 + keepInbox → 保留但停放（没有 latch）
  ├─ 此后新的 waking send  → 强制 next-turn + wakeRequested=true
  ├─ 默认 cancel            → 清 Inbox + 清 latch
  └─ disposed               → 永不 latch

旧 driver finally：idle → 若 latch 且仍有 pending → 新 driver

13. Turn 记录本身不足以回答“这份工作去了哪里”

一个无 Step 的 Turn 可能是空 claim、listener 清空、pre-step reject、取消或错误；只看 turn/end 无法区分“什么都没做”和“消费了但没有进入模型”。foldConsumedWork 因而联合读取 step、纯删除 claim 与 canceled splice。INBOX-CONSUMED-WORK

14. “已写日志”“已发 Web 快照”“已落盘”是三个不同提交点

Host prompt accepted
  → Inbox splice 已同步 append 到 live Session
  → API 可返回 accepted
  → JSONL write-behind batch（默认固定窗口）

首个 pre-step checkpoint
  → flush enqueue + turn/start + claim
模型 adapter dispatch 前
  → flush step/start + user/message + request prefix

JSONL backend 把 live events 固定窗口合批，flush/teardown 会立即 drain；每批 append 与 fsync，失败回滚到原字节长度。由此可知 prompt 的同步 accepted 是 Session-level admission，不是独立的 fsync receipt；如果产品需要“回复前必须断电安全”，还需要显式等待 checkpoint。INBOX-JSONL-DURABILITY

15. Resume 会重建 pending，但不会仅因重建而自动开跑；fork seed 也不会复制祖先待办

恢复路径先从 persistence prepare Session，再走与新建相同的 prepare/setup/publish；新的 ReactLoopAgent 构造器从日志恢复最后 Turn 编号和 Inbox。INBOX-AGENT-RESUME

构造与 publish 本身不调用 wake。普通 Host 冷恢复通常紧接着处理一条 waking prompt；continuable child 冷恢复也紧接着调用 followup，所以旧 pending 会按两队列 claim 规则与新 wake 一起继续。单独恢复一个 Agent 并不承诺自动消费停放输入。

16. Ordinary Host API 返回 admission，不返回 Turn 或回复

session.prompt 接受 mode: queue | steer，处理时区、附件耐久化和 message source 后，分别调用 agent.followup 或 agent.steer；同步入队成功即返回 {accepted:true}。它没有等待 pre-step、模型结果或 idle。INBOX-HOST-PROMPT

Host 会为 cold ordinary session 先解析/恢复 Agent；但直接 mode: steer 不额外检查 running，因此它仍服从底层的“空闲时由 steer 打开一个 Turn”。这与 UI 的保守 submission policy 是不同层的约束。

17. Queue edit/remove/strict-steer 以 MessageId 定址；claim 赢掉竞态

18. Web 使用完整快照做 live mirror，再用 durable splice 恢复历史身份

Session splice（observer 看到 pre-state）
  → Host 对当前列表应用本次 splice
  → session/queue { complete items[] }
       next-turn              → queued
       next-step + user       → steering
       next-step + non-user   → context

Queue mirror 以完整 snapshot last-wins；pending steering 一旦出现相同 MessageId 的 durable user/message 就从瞬态镜像退休。历史 replay 则读取 next-step splice 的非 canceled removal，再检查 user source，把同一个 user/message 重建为 steering。INBOX-CLIENT-MIRRORINBOX-HISTORY-CLASSIFICATION

19. UI 把 queued 与 steering 放在两个位置，并把“快捷发送”定义成策略而非真相

QueueDock 只显示 placement=queued，提供编辑、删除和逐条 steer；steer 按钮只在 running 时启用。pending steering 则以用户气泡样式显示在 conversation tail，等 durable message 进入历史后完成 handoff。INBOX-QUEUE-DOCKINBOX-PENDING-STEERING-UI

20. Continuable child 的 Activation 是 residency epoch，不是一次请求或一个结果

startContinuable 建立 durable child；后续 followup 隐藏 resident 与 cold-resume 差异，并把每条输入交给孩子自己的唯一 Inbox。成功边界是孩子接受 message id，不等待 Turn 开始，也不返回孩子回复。INBOX-CONTINUATION-SEAM

一个 Activation 可以执行许多 FIFO Turn，也会因后代仍运行而在自身 idle 后继续驻留；manager 只拥有 residency/ownership，Turn 顺序仍完全由 Agent loop 与 Inbox 所有。INBOX-ACTIVATION-MODELINBOX-ACTIVATION-STATE

21. 父→子 delivery 永远是 follow-up；锁把 delivery 与 disposal 线性化

对 resident child，manager 在 child-id 锁内提交消息；若 disposal 已开始，就等待旧 Activation 释放后 cold-resume。对 absent child，它检查持久化 Session、先按 durable parent lineage 授权、只折叠 seed 之后的 continuable descriptor，再重建 Activation。INBOX-CONTINUATION-DELIVERYINBOX-COLD-RESUME

22. 子→父有两种独立消息：主动 report 与自动 settlement account

23. Child 的 Web 与模型控制面有意比 ordinary Session 更窄

Wire contract 明确把 prompt receipt 定义为 Inbox MessageId，把 interrupt receipt 定义为信号被接受而非目标 quiescent；Host 的 child prompt 要求 live parent，interrupt 则刻意不查询 parent、catalog 或 persistence。INBOX-SUBAGENT-WIREINBOX-SUBAGENT-HOST

客户端把 one-shot 设为只读；continuable child 即使 running 也保留 Send 并单列 Stop，使新消息排为后续 Turn。parent offline 时输入禁用但仍允许停止 live child；模型工具同样说明 send_message 不返回回复、不能 redirect 当前工作。INBOX-CHILD-CLIENTINBOX-CHILD-COMPOSERINBOX-CHILD-OFFLINE-UIINBOX-CONTROL-TOOLS

24. 固定基线存在两处可复现的文档漂移

25. 保证矩阵与设计评价