Command Queue (2026-01-16)

文档

适用范围

在以下情况使用此页面：

更改自动回复执行或并发

我们通过一个微小的进程内队列序列化入站自动回复运行（所有通道），以防止多个代理运行冲突，同时仍允许跨会话的安全并行性。

为什么

自动回复运行可能很昂贵（LLM 调用），并且可能在多个入站消息接近时到达时发生冲突。
序列化避免竞争共享资源（会话文件、日志、CLI stdin）并减少上游速率限制的机会。

工作原理

具有可配置并发上限的通道感知 FIFO 队列，每个通道的队列的并发上限默认为 1（未配置的通道），main 默认为 4，subagent 默认为 8。
runEmbeddedPiAgent 按会话键（lane session:<key>）排队，以保证每个会话只有一次活动运行。
每个会话运行然后排队到全局通道（默认为 main），因此总体并行性由 agents.defaults.maxConcurrent 限制。
启用详细日志记录时，如果排队运行在开始前等待超过 ~2s，则会发出简短通知。
打字指示器仍然在排队时立即触发（通道支持时），因此用户体验在我们等待轮次时保持不变。

队列模式（每个通道）

入站消息可以引导当前运行、等待后续轮次或两者都做：

steer：立即注入当前运行（在下一个工具边界后取消挂起的工具调用）。如果不流式传输，则回退到后续。
followup：排队等待当前运行结束后的下一个代理轮次。
collect：将所有排队的消息合并为单个后续轮次（默认）。如果消息针对不同的通道/线程，它们将单独排出以保留路由。
steer-backlog（aka steer+backlog）：现在引导并保留消息以进行后续轮次。
interrupt（传统）：中止该会话的活动运行，然后运行最新消息。
queue（传统别名）：与 steer 相同。

Steer-backlog 意味着您可以在引导运行后获得后续响应，因此流式表面可能看起来像重复。如果您想要每个入站消息一个响应，请优先使用 collect/steer。发送 /queue collect 作为独立命令（每个会话）或设置 messages.queue.byChannel.discord: "collect"。

默认值（配置中未设置时）：

所有表面 → collect

通过 messages.queue 全局或每个通道配置：

{
  messages: {
    queue: {
      mode: "collect",
      debounceMs: 1000,
      cap: 20,
      drop: "summarize",
      byChannel: { discord: "collect" }
    }
  }
}

队列选项

选项适用于 followup、collect 和 steer-backlog（以及当它回退到后续时的 steer）：

debounceMs：在开始后续轮次之前等待安静（防止"继续、继续"）。
cap：每个会话的最大排队消息数。
drop：溢出策略（old、new、summarize）。

Summarize 保留丢弃消息的简短项目符号列表，并将其作为合成后续提示注入。默认值：debounceMs: 1000、cap: 20、drop: summarize。

每会话覆盖

发送 /queue <mode> 作为独立命令以存储当前会话的模式。
选项可以组合：/queue collect debounce:2s cap:25 drop:summarize
/queue default 或 /queue reset 清除会话覆盖。

作用域和保证

适用于使用网关回复管道的所有入站通道的自动回复代理运行（WhatsApp web、Telegram、Slack、Discord、Signal、iMessage、webchat 等）。
默认通道（main）是入站 + 主心跳的进程范围；设置 agents.defaults.maxConcurrent 以允许多个会话并行。
可能存在其他通道（例如 cron、subagent），因此后台作业可以并行运行而不会阻塞入站回复。
每个会话通道保证在给定时间只有一个代理运行接触给定会话。
无外部依赖或后台工作线程；纯 TypeScript + promise。

故障排除

如果命令看起来卡住了，请启用详细日志并查找"排队等待 …ms"行以确认队列正在排出。
如果您需要队列深度，请启用详细日志并观察队列计时行。

Brave Search API Date & Time