3.8 KiB
RFC: 让每次普通 send 独占一个轮次
Status: implemented
English | 中文
问题
每个普通 Agent.send() payload 都是一条完整的调用方消息。如果机会式地把所有等待 payload 放入同一个轮次，相邻调用是否共享边界就会取决于 driver 时机：即使调用方使用相同 API，来自同一个同步调用栈、相邻微任务、事件 listener 和模型 callback 的调用也可能产生不同分组。
轮次拥有提示词准入、turn/start、turn/end 和持久性检查点。合并消息会让后一条消息加入前一条消息的模型请求，而不能观察前一轮次已经提交的结果；获准与被阻止提示词的混合还会引入调用方从未显式请求的生命周期状态。
steer() 已经用于表达加入当前轮次，inject() 则记录面向模型的上下文而不充当普通消息。隐式批处理会让 send() 与这两种显式操作产生语义重叠，无法保持单一含义。
决策
每次成功的 send() 都会同步校验 agent（智能体）状态、创建并冻结内容快照、追加一个独立 FIFO item，然后发布 agent/queued。agent loop 在每次轮次开始时最多取出一个普通 item。如果两个 item 都被认领，第二个轮次只能在第一个轮次结束且其持久性检查点完成后开始；广义取消、dispose（资源释放）或启动前失败可以丢弃尚未启动的 item，而不创建空轮次。
提示词准入只处理一条消息。获准提示词成为该轮次的 user/message；被阻止提示词追加一条持久的 prompt/blocked，并让这个单消息轮次以 rejected 结束。实现中没有 mixed-batch 或 all-blocked-batch 分支。
运行中的 steer() 会追加到当前轮次的 steering FIFO。空闲时的 steer() 委托给 send()，因此创建一个独立的普通轮次。inject() 保持现有的轮次封闭与 flush 行为。cancel()、status 和 whenIdle() 仍是面向整个 agent 的操作，不变成逐消息控制。
曾考虑的替代方案
为吞吐量保留机会式批处理。 当 producer 速度快于 driver 时，合并排队的提示词可以减少模型调用，但会让轮次边界取决于调度，并使后一条消息无法可靠观察前一轮次的持久化结果。额外模型调用的代价低于显式生命周期语义的价值；未来的任何批处理功能都必须提供调用方可见的显式契约，并由测量结果证明其必要性。
验证
- 单元与性质覆盖固定了同一调用栈、相邻微任务、不同来源和重入 send 的行为：每个轮次只有一条消息，并按 FIFO 排序。
- 延迟第一个轮次的 flush 可以证明下一个排队轮次不能在检查点完成前开始，且其请求能看到前一个 assistant result；被拒绝的 flush 也会在下一个轮次开始前完成。
- 提示词否决与 listener failure、广义取消、dispose 和提交前
turn/startfailure 都会保持已记录轮次边界平衡，不会合并消息或让仍应处理的排队工作滞留。 - 运行中与空闲时的
steer()、inject()、面向整个 agent 的 status 和whenIdle()保持原有覆盖。
后果
普通轮次边界是确定的，被认领的 FIFO 后继项可以观察前一轮次已经提交的会话结果。多个排队 item 仍可在同一个全局 running 区间内执行，广义取消也可以丢弃整个未启动队尾，因此 status 和静止状态仍是面向整个 agent 的观察，而不是逐消息结果。
依赖偶然批处理的工作负载会产生更多模型请求和检查点，队列清空时间也可能延长；持续 producer 还可能让 FIFO 队列增长。只有建立显式且经过测量的契约后，才能重新引入吞吐量优化。