title: Background completion backlogs sidebar_label: Completion backlogs

后台任务完成队列

交互式界面会将同一对话中已准备就绪的连续后台进程完成结果合并为单个通知轮次。这一机制不会造成延迟，也无法强制将不同时间完成的任务合并在一起。无论任务是失败还是成功，其输出都会保留在批次中，且每个完成结果都会保留其原始文本。

进程标识在任务被调度之前始终有效。因此，通过显式调用 process_manage 来控制等待、记录日志或终止进程，即便相关CLI完成结果已从进程注册表移出并进入输入队列，仍可阻止其被处理。一旦某个批次的所有任务都被完全处理完毕，就不会再产生新的轮次。而输出监控结果与异步委托处理结果仍将作为独立的通知按原有顺序呈现，不会被合并到任务完成批次中。

消费者与所有权归属

• 经典 CLI： hermes_cli/cli_process_notifications.py 负责处理空闲状态/轮次结束后的数据清理、基于压缩效率的所有权判定以及最终输入数据的解析。
• TUI 及桌面端： tui_gateway/session_notifications.py 会在检查完所有权后，汇总轮询机制获取的会话就绪状态信息。各进程仍会独立显示自身的 UI 状态。处于忙碌状态的会话会重新发送结构化事件，而非已格式化的批量字符串。
• 轮次结束后的 TUI 安全机制： tui_gateway/prompt_turn.py 采用相同的路由与渲染流程。桌面端和仪表板聊天客户端均共享这一后端服务。
• 消息网关： gateway/run_notifications.py 已经实现了基于路由键的短时间窗口批量处理机制。此次针对交互式队列的改进并不会取代该机制，也不会改变适配器的发送方式。
• 非交互式/无界面客户端： 此次改动不会为 API 请求、ACP 客户端或一次性 CLI 命令创建新的独立通知循环。

通用的渲染模块为 tools/process_registry_notifications.py::ProcessNotificationBatch。无论是批量数据还是其交付状态，都不会被保存到系统提示中。已处理的事件仍需具备可验证的所有权，其他正在运行的会话无法接管这些事件。任务委派后的数据传递仍通过现有的持久化记录/完成日志机制进行，且每次委派仅处理一次，而非每个进程批次处理一次。

本地验证及其局限性

evals/completion_backlog_probe.py REPO OUTPUT.json 会在临时目录中启动真实的本地子进程 shell，读取这些进程产生的实际补全事件，并驱动生产环境中的 CLI、TUI 轮询机制以及对话结束后的通知流程。一个回环 HTTP 接收端用于替代原有的 chat / _run_prompt_submit 功能；它仅负责记录实际的请求分发情况，而不会执行模型推理、与原生渲染器的交互，也不会调用任何托管平台。那些用于模拟监控和任务委派的测试数据会被标记为固定值；而真正的任务委派操作则会使用真实的临时 SQLite 数据库进行记录。该探测程序在处理补全任务时，还会同时检查待处理的任务队列、特定的有效负载内容、已被明确处理的结果、外部资源的所有权关系，以及与补全任务交织在一起的监控和委派操作。它的评估标准是通知环节处的任务接收情况，而非模型推理所节省的token数量。