运行中输入的排队与取消顺序
编写于 2026-08-13
Peri 正在运行测试时，用户又输入一条补充要求，希望顺便检查 Windows。几秒后用户发现当前方向不对，于是按下 Ctrl+C。此时有两个独立问题需要判断，当前轮是否停止，以及刚提交的补充要求是否还会执行。
生成期间提交的普通文本会进入 下一轮输入队列，不会插进正在运行的推理。Ctrl+C 请求取消当前轮，队列默认保留，并在当前轮完成或中断事件到达后按顺序继续提交。
运行中输入停在输入框上方
当 TUI 处于 loading 状态时，普通文本提交后会显示在输入框上方的 queued 区域。它暂时不会成为消息时间线里的用户气泡，也不会改变当前已经发出的模型请求。
界面最多展示 5 条 queued 内容，空间不足时还会优先缩减这块区域。可见数量不是队列总量，隐藏的项目仍可能等待发送，因此不能用屏幕上只剩几行判断其余内容已经消失。
有界队列保留最近输入
当前队列最多保留 32 条普通文本。第 33 条进入时，最旧的一条会被移除，后续内容继续保留，这个上限用于避免运行中的输入无限占用内存。
这意味着队列适合少量补充，不适合在长任务中连续堆积指令。若目标已经明显变化，取消后重新提交一条完整的新要求，比依赖很多零散补充更容易核对范围。下面的输入输出是演示示例，不是真实会话。
当前轮运行 Linux 目标测试
queued 1下一轮再检查 Windows 条件编译
queued 2汇总两个平台未运行的检查这两条补充不会加入当前测试轮。当前轮完成后，它们会按先进先出的顺序各自进入后续处理，第一条先发送，第二条后发送。
Ctrl+C 只请求中断当前轮
loading 状态下按 Ctrl+C，TUI 会向 Agent 发送取消请求，并在请求完成、失败或超时后复位本地 loading 状态。取消发生前已经启动的文件写入、Shell 子进程或外部请求可能已经产生结果，取消本身不会撤销这些副作用。
当前轮没有产生输出时，TUI 会尽量移除刚提交的用户气泡，并把原始文本放回输入框。已经产生部分回复或工具结果时，可见内容会保留在时间线中，用户需要据此检查任务停在什么位置。
取消后队列继续进入下一轮
当前轮收到中断事件后，TUI 会清理本轮状态，再排空 queued 内容。普通文本按原顺序成为新的用户消息并继续提交，所以 Ctrl+C 不能用来同时清除所有后续要求。若取消请求失败或超时且终态事件没有到达，TUI 只会复位本地 loading，队列仍可能等待后续终态事件。
若用户的意图是停止当前工作并放弃排队内容，当前界面没有把两者合并为一个动作。应等待状态复位，检查输入框上方和消息时间线，再明确提交新的完整目标，必要时关闭会话前先核对工作区。
三种输入意图对应不同动作
补充下一阶段要求时，可以在运行中提交一两条普通文本，让它们进入队列。修正当前方向时，应先按 Ctrl+C，再检查已发生的工具结果，最后用一条完整输入重述目标。
只想提供当前任务的背景信息时，也要记住 queued 内容不会改写正在运行的模型请求。需要立即影响当前操作的关键信息不会进入已经发出的请求，此时应及时取消并核对已发生的副作用。
完成状态由工作区重新确认
回到运行测试的场景，Ctrl+C 只处理当前轮，Windows 补充要求仍可能随后执行。取消后先看时间线和 queued 区，再检查 diff、进程和测试输出，才能知道当前工作真正停在哪里。