人工智能大模型LLM 网关AI Agent即时通讯【免费下载链接】openclaw-zero-tokenOpenClaw: Use All Major AI Models NO API Token! Claude/ChatGPT/Gemini/DeepSeek/Doubao/Grok/Qwen/Manus/Kimi项目地址https://gitcode.com/gh_mirrors/op/openclaw-zero-token点击查看免费下载OpenClaw 通过一个进程内in-process的 lane 感知 FIFO 队列将来自 WhatsApp Web、Telegram、Slack、Discord、Signal、iMessage、webchat 等所有渠道的入站自动回复运行auto-reply run串行化避免多个 Agent 运行同时碰撞、争抢会话文件、日志与 CLI stdin 等共享资源。本文以 docs/concepts/queue.md 为核心骨架结合源码实现完整讲解队列的设计动机、双层级会话 lane 全局 lane排队模型、六种队列模式、messages.queue配置、/queue会话级指令与排障方法帮助你按需调优并发与突发消息处理策略。为什么需要命令队列自动回复运行往往代价高昂——一次运行通常要触发大模型 LLM 调用而多个入站消息在短时间内集中到达时彼此之间可能产生冲突共享资源竞争会话文件session file、日志输出、CLI 标准输入等资源同一时刻只能被一个运行安全占用上游限流风险并发突增会提高触发模型服务商 rate limit 的概率体验问题多个运行互相打断导致回复顺序错乱或重复。命令队列的解决方案是串行化入站自动回复运行同时在会话维度保留安全的并行能力。串行化避免了资源竞争与限流而 lane车道机制让不同会话、不同任务的运行仍可并行推进互不阻塞。核心设计lane 感知的双层级 FIFO 队列从源码结构看OpenClaw 的排队体系由两层构成会话 lanesession lanerunEmbeddedPiAgent按session key入队lane 名为session:key保证同一会话同一时刻只有一个运行全局 laneglobal lane每个会话的运行随后进入全局 lane默认main由agents.defaults.maxConcurrent控制整体并行度上限。对应实现分散在两个模块中进程级 lane 执行器src/process/command-queue.ts 维护每个 lane 的QueueEntry[]队列与maxConcurrent并发上限lane 常量定义在 src/process/lanes.ts包括main、cron、subagent、nestedfollowup 队列状态机src/auto-reply/reply/queue/ 目录下的state.ts、drain.ts、enqueue.ts、settings.ts等文件负责 followup 轮次的收集、去重、溢出与排空。lane 名称解析逻辑位于 src/agents/pi-embedded-runner/lanes.tsresolveSessionLane(key)将任意 key 规范化为session:key空 key 回退到mainresolveGlobalLane(lane)在传入cron时返回nested——这是因为 cron 作业已持有 cron lane 的槽位内部操作必须使用嵌套 lane 以避免死锁。并发上限的默认值与配置不同 lane 的并发上限不同定义在 src/config/agent-limits.tsLane / 配置项默认值说明未配置的 lane1command-queue.ts中新建 lane 的默认maxConcurrent为 1agents.defaults.maxConcurrent4全局mainlane 的默认并发DEFAULT_AGENT_MAX_CONCURRENTagents.defaults.subagents.maxConcurrent8subagent lane 的默认并发DEFAULT_SUBAGENT_MAX_CONCURRENTcommand-queue.ts通过setCommandLaneConcurrency(lane, maxConcurrent)设置并发上限enqueueCommandInLane()入队后调用drainLane()泵出任务只要activeTaskIds.size maxConcurrent且队列非空就持续取出任务执行。因此设置agents.defaults.maxConcurrent为 N意味着mainlane 中最多有 N 个会话运行同时执行。排队等待的日志提示队列为每个任务记录enqueuedAt时间戳并在出队时计算waitedMs。enqueueCommandInLane的默认warnAfterMs为2000ms见 src/process/command-queue.ts当任务等待超过约 2 秒才开始时会触发onWait回调并通过诊断日志输出lane wait exceeded: lane... waitedMs... queueAhead...。这就是文档中启用 verbose 日志后排队运行在等待超过约 2s 时输出短提示的实现来源。输入指示Typing不受排队影响消息入队的同时渠道的 typing 指示输入中…立即触发typingSignals.signalRunStart()等用户等待期间仍能看到正在输入的反馈体验与立即回复几乎一致。这个细节在 src/auto-reply/reply/agent-runner.ts 与 src/auto-reply/reply/followup-runner.ts 中均有体现followup 轮次结束后必须同时调用typing.markRunComplete()与typing.markDispatchIdle()否则空 payload 的 followup 会让 typing 指示卡住。队列模式Queue Modes入站消息如何参与当前运行入站消息可以立即介入当前运行、等待下一轮 followup或两者兼顾。六种模式在 src/auto-reply/reply/queue/types.ts 中定义为QueueMode联合类型名称规范化含别名在 src/auto-reply/reply/queue/normalize.ts 中实现模式行为别名steer立即注入当前运行在下一个工具边界取消待执行的工具调用若当前未在流式输出则回退为 followupqueue、queuedlegacy 别名、steeringfollowup入队等待当前运行结束后作为下一轮 Agent 轮次执行followups、follow-upscollect将队列中所有消息合并为单次followup 轮次默认模式若消息来自不同渠道/线程则逐条单独排空以保留路由coalescesteer-backlog先 steer 立即处理同时保留消息用于一次 followup 轮次steerbacklog、steer_backloginterrupt中止该会话的当前运行然后执行最新消息legacyinterrupts、abortqueuelegacy 别名等价于steer—默认值所有渠道surface未配置时均为collect。该默认在 src/auto-reply/reply/queue/settings.ts 的defaultQueueModeForChannel()中硬编码返回collect。模式如何被决策执行resolveActiveRunQueueAction()见 src/auto-reply/reply/queue-policy.ts根据当前是否有活跃运行、是否心跳、是否应 followup、队列模式四要素把本次入站消息归类为三种动作之一run-now当前无活跃运行或模式不要求 followup 且非 steer——直接立即执行enqueue-followup当前运行活跃且模式为followup/collect/steer-backlog或steer需要排队drop当前运行活跃且本条为心跳消息——心跳被直接丢弃避免打断正在进行的回复。steer与steer-backlog的立即注入走另一条路径当shouldSteer isStreaming时调用queueEmbeddedPiMessage(sessionId, prompt)将消息注入正在流式输出的运行注入成功且不要求 followup 时本次入站消息即完成处理见 src/auto-reply/reply/agent-runner.ts。steer-backlog 的重复回复提醒steer-backlog意味着被 steer 的运行结束后还会再产出一轮 followup 回复因此流式渠道上用户可能看到两条看似重复的回复。如果你希望每条入站消息只对应一条回复请优先使用collect或steer。原文中的这条提醒直接来自模式语义本身steer 负责立即响应backlog 又保留消息触发后续轮次。interrupt 模式的底层实现interrupt是唯一会中止正在运行的 Agent的模式。在 src/auto-reply/reply/get-reply-run.ts 中可以看到它的完整链路const sessionLaneKey resolveEmbeddedSessionLane(sessionKey ?? sessionIdFinal); const laneSize getQueueSize(sessionLaneKey); if (resolvedQueue.mode interrupt laneSize 0) { const cleared clearCommandLane(sessionLaneKey); const aborted abortEmbeddedPiRun(sessionIdFinal); logVerbose(Interrupting ${sessionLaneKey} (cleared ${cleared}, aborted${aborted})); }即先调用clearCommandLane()清空该会话 lane 中排队但未执行的任务这些任务会收到CommandLaneClearedError见 src/process/command-queue.ts再调用abortEmbeddedPiRun()中止正在执行的运行最后执行最新消息。该模式语义激进适合以最新消息为准的场景日常建议保持保守模式。collect 模式下的跨渠道路由collect的合并逻辑在 src/auto-reply/reply/queue/drain.ts排空前通过hasCrossChannelItems()src/utils/queue-helpers.ts检查队列中是否存在跨渠道/跨线程消息。判断依据是channel|to|accountId|threadId组合出的路由 key同时兼容 Telegram 的数值 topic id 与 Slack 的字符串thread_ts。一旦检测到跨渠道消息就切换为逐条单独排空forceIndividualCollect保证每条消息都能回复到它原本的渠道而不是被错误地合并或发送到错误目的地。配置messages.queue队列行为可通过messages.queue在全局或按渠道配置。原文给出的完整配置示例JSON5 格式{ messages: { queue: { mode: collect, debounceMs: 1000, cap: 20, drop: summarize, byChannel: { discord: collect }, }, }, }配置项详解配置解析与优先级逻辑集中在 src/auto-reply/reply/queue/settings.ts各字段说明如下mode全局队列模式取值steer、followup、collect、steer-backlog文档中也写作steerbacklog、queue、interrupt。schema 帮助文本见 src/config/schema.help.tsKeep conservative modes unless you intentionally need aggressive interruption/backlog semantics.除非确实需要激进的打断/backlog 语义否则保持保守模式。byChannel按渠道provider id如telegram、discord、slack覆盖模式。当某个渠道的流量特征与全局默认不同时使用。示例byChannel: { discord: collect }表示 Discord 渠道单独使用collect。debounceMs开始 followup 轮次前等待的静默窗口单位为毫秒用于防止连续消息触发continue, continue式的连环回复。全局默认1000msDEFAULT_QUEUE_DEBOUNCE_MS定义于 src/auto-reply/reply/queue/state.ts。debounceMsByChannel按渠道的 debounce 覆盖该键在schema.help.ts中有专门帮助文本说明用于为节奏不同的聊天渠道独立调节突发处理。cap每个会话最大排队消息数。默认20DEFAULT_QUEUE_CAP。设置cap时会经过Math.max(1, Math.floor(cap))规范化保证至少为 1。drop队列达到cap后的溢出策略取值old、new、summarize默认summarizeDEFAULT_QUEUE_DROP。插件channel plugin还可以通过自身清单的defaults.queue.debounceMs提供渠道级 debounce 默认值resolvePluginDebounce()src/auto-reply/reply/queue/settings.ts会在配置未显式给出时读取它。配置解析的优先级链resolveQueueSettings()对每一项都遵循固定的优先级从高到低mode消息内联指令/queue mode 会话条目queueMode 渠道级byChannel 全局mode 默认collectdebounceMs内联选项 会话queueDebounceMsdebounceMsByChannel 插件默认 全局debounceMs 默认1000cap内联选项 会话queueCap 全局cap 默认20drop内联选项 会话queueDrop 全局drop 默认summarize。也就是说任何一层配置了值都会覆盖下一层这一设计让全局默认 → 渠道特化 → 会话覆盖 → 单条消息覆盖的粒度全部可用。队列选项debounce、cap 与 drop 溢出策略debounceMs、cap、drop三个选项作用于followup、collect、steer-backlog三种模式以及steer回退为 followup 时。debounceMs静默等待排空逻辑在真正执行 followup 前调用waitForQueueDebounce()src/utils/queue-helpers.ts不断检查距上次入队的时间差是否达到debounceMs未达到则用setTimeout继续等待直到渠道安静下来再合并执行。这样用户连续发来的多条消息会被合并而不是每条都触发一次独立的 LLM 调用。测试环境下可通过环境变量OPENCLAW_TEST_FAST1跳过等待。cap 与 drop溢出策略入队时调用applyQueueDropPolicy()src/utils/queue-helpers.ts当队列长度达到cap后按策略处理old丢弃最旧的消息从队首splice掉超出的部分new丢弃最新消息返回false直接拒绝入队summarize丢弃最旧消息但保留摘要——每条被丢弃的消息被压缩成一行最多 160 字符空白折叠并累计droppedCount摘要行数量受cap限制超出时从最旧的开始淘汰。summarize 的合成 followup prompt当drop: summarize且确有消息被丢弃时排空阶段会生成一段合成提示注入 followup 轮次buildQueueSummaryPrompt()src/utils/queue-helpers.ts。其格式大致为[Queue overflow] Dropped N messages due to cap. Summary: - 第一条被丢弃消息的摘要 - 第二条被丢弃消息的摘要同时collect模式合并多条消息时使用buildCollectPrompt()生成统一 prompt标题为[Queued messages while agent was busy]每条消息以---\nQueued #N\n原始消息的形式列出见 src/auto-reply/reply/queue/drain.ts。这样 Agent 既能处理排队消息又不会丢失因溢出被丢弃的关键意图。入队去重队列还内置了消息级去重QueueDedupeMode见 src/auto-reply/reply/queue/types.ts。enqueueFollowupRun()src/auto-reply/reply/queue/enqueue.ts按messageId 路由四元组channel/to/accountId/threadId判断是否已在队列中并在进程级缓存RECENT_QUEUE_MESSAGE_IDSTTL 5 分钟、上限 10000 条中记录最近处理过的消息 ID拒绝重复投递。这在消息系统出现重发redelivery时尤为重要保证同一条消息不会被排队两次。会话级覆盖/queue 指令除了全局与按渠道配置还可以直接在会话中发送/queue mode作为独立指令为当前会话临时设置模式。支持的命令形式命令效果/queue collect将会话模式设为collect其余选项保留/queue collect debounce:2s cap:25 drop:summarize模式与选项组合覆盖/queue default清除会话级覆盖回到全局/渠道配置/queue reset或clear同上等价于恢复默认指令解析实现在 src/auto-reply/reply/queue/directive.ts以/queue开头逐 token 识别debounce:/debounce、cap:/cap、drop:/drop形式的选项debounce支持parseDurationMs时长解析默认单位ms所以debounce:2s会被解析为 2000ms遇到default/reset/clear标记清除遇到无法识别的 token 则停止解析并把剩余部分作为正常消息内容处理。持久化到会话条目指令生效后设置被写入会话条目并持久化到 session storequeueMode、queueDebounceMs、queueCap、queueDrop四个字段见 src/auto-reply/reply/directive-handling.impl.ts 第 403-421 行。发送/queue default/reset时这四个字段被删除会话恢复全局默认。设置成功后 Agent 会回复确认消息格式如Queue mode set to collect.。作用域与保证Scope and Guarantees适用渠道所有使用 gateway 回复管线reply pipeline的入站渠道包括 WhatsApp Web、Telegram、Slack、Discord、Signal、iMessage、webchat 等。排队逻辑统一在 src/auto-reply/reply/get-reply-run.ts 中按会话上下文触发渠道无关。全局 lane 与并行度默认mainlane 为进程级process-wide承载入站自动回复与主心跳运行设置agents.defaults.maxConcurrent可让多个会话并行。lane 状态存放于globalThis上的进程级单例COMMAND_QUEUE_STATE_KEY见 src/process/command-queue.ts保证生产构建中所有 bundle chunk 共享同一套队列、计数与 draining 标志。独立 lane还存在其他 lane例如cron与subagent——后台定时任务可以在不阻塞入站回复的前提下并行运行。cron 任务内部操作会被映射到nestedlane避免持有 cron 槽位造成死锁。会话级保证session:key会话 lane 保证同一时刻只有一个 Agent 运行接触给定会话。即使会话在排队期间发生自动压缩auto-compaction导致sessionId变化refreshQueuedFollowupSession()src/auto-reply/reply/queue/state.ts也会把队列中已排队任务的sessionId/sessionFile同步更新到新会话保证 followup 轮次仍指向正确的会话记录。零外部依赖整个队列不依赖任何外部服务或后台工作线程是纯 TypeScript Promise 实现。会话清理当会话被删除或重置时clearSessionQueues()src/auto-reply/reply/queue/cleanup.ts会同时清理三类状态followup 队列条目、drain 回调、以及会话 lane 中排队未执行的任务返回被清理的条目数与涉及的 key避免残留任务继续执行。源码导读queue 模块结构如果你希望深入阅读实现推荐按以下顺序浏览src/auto-reply/reply/queue/types.tsQueueMode、QueueDropPolicy、QueueSettings、FollowupRun含回复路由所需的originatingChannel/originatingTo/originatingThreadId等字段的定义src/auto-reply/reply/queue/normalize.ts模式与溢出策略的别名规范化src/auto-reply/reply/queue/settings.ts配置解析与优先级链src/auto-reply/reply/queue/state.ts进程级队列注册表FOLLOWUP_QUEUES与默认值src/auto-reply/reply/queue/enqueue.ts入队、去重、cap/drop 应用src/auto-reply/reply/queue/drain.ts排空调度、collect 合并、跨渠道逐条排空、溢出摘要注入src/process/command-queue.tslane 执行器并发上限、等待告警、lane 清理、gateway drainingsrc/agents/pi-embedded-runner/lanes.tslane 名称解析与 cron→nested 映射。对应测试可参考 src/auto-reply/reply/queue-policy.test.ts、src/agents/pi-embedded-runner/lanes.test.ts 与 src/config/config.agent-concurrency-defaults.test.ts。排障指南Troubleshooting命令看起来卡住stuck启用 verbose 日志查找queued for …ms或lane wait exceeded: lane… waitedMs…之类的排队计时行确认队列确实在排空而不是死锁。如果drainLane出现drainingtrue active0 queueN的诊断警告说明存在异常状态可关注 lane generation 重置逻辑resetAllLanes()是否因进程内重启被触发。需要查看队列深度启用 verbose 日志并观察队列计时行代码层面getQueueSize(lane)与getTotalQueueSize()src/process/command-queue.ts分别返回单 lane 与全 lane 的排队执行中任务数可配合状态命令src/auto-reply/status.ts确认当前积压情况。回复出现重复确认是否使用了steer-backlog——它本来就会在 steer 后追加一轮 followup 回复若要求每条入站消息一条回复切换为collect或steer。小结OpenClaw 的命令队列以会话 lane 串行化 全局 lane 并发上限的双层模型在避免 Agent 运行互相碰撞的前提下保留了跨会话的并行能力collect默认模式让突发消息合并为单轮回复cap/drop/summarize则保证队列在高压下可控且不丢失意图。无论是通过messages.queue全局调优、byChannel渠道特化还是/queue会话级即时覆盖你都可以在不改动代码的前提下为不同流量特征的渠道定制最合适的入站消息处理策略。赞分享人工智能大模型LLM 网关AI Agent即时通讯【免费下载链接】openclaw-zero-tokenOpenClaw: Use All Major AI Models NO API Token! Claude/ChatGPT/Gemini/DeepSeek/Doubao/Grok/Qwen/Manus/Kimi项目地址https://gitcode.com/gh_mirrors/op/openclaw-zero-token点击查看免费下载相关推荐OpenClaw 命令队列Command Queue深入解析多会话并发、队列模式与消息转向机制OpenClaw 命令队列Command Queue深入解析多会话并发、队列模式与消息转向机制 本文系统讲解 OpenClaw 进程内的命令队列CommAI 应用AI Agent交互助手后端即时通讯网关深入理解 JavaScript 微任务队列Microtask QueuePromise 异步执行与 unhandledrejection 的底层机制深入理解 JavaScript 微任务队列Microtask QueuePromise 异步执行与 unhandledrejection 的底层机制 本篇文档/教程前端OpenClaw 队列引导Queue Steering机制解析运行时边界上的消息注入与工具调度OpenClaw 队列引导Queue Steering机制解析运行时边界上的消息注入与工具调度 当智能体Agent正在流式执行一轮会话sessionAI 应用AI Agent交互助手后端即时通讯网关上一篇mason-nvim-dap.nvim支持的20调试适配器清单Python、C、Go等语言全覆盖下一篇30 seconds of code 实战用 JavaScript 精确获取浏览器垂直滚动条宽度创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考