BullMQ
基于Redis的Node.js消息队列与任务调度库，支持延迟任务、重试、去重（jobId）等特性，常用于后台任务与工作流编排
时间轴 (近 90 天)
队列工具选型标准是团队在凌晨 2 点故障时仍能正确运维：BullMQ 适合 Node.js worker，Temporal 适合多步骤长时间等待与审批编排，AWS SQS 适合 AWS 原生托管队列，Cloudflare Queues 适合边缘友好批量处理架构。
让 cron 直接执行完整 Agent 逻辑（如 */15 * * * * node run-agent.js）是坏模式；标准模式是 cron 只负责入队（如 node enqueue-agent-job.js，写入 BullMQ、SQS 或 Cloudflare Queues），由独立 worker 执行 Agent 步骤。
BullMQ 的指数退避公式为 2 ^ (attempts - 1) * delay；基础延迟 3000ms 时第 7 次尝试需等待约 192 秒（约 3.2 分钟）。
BullMQ 的 jobId 去重仅在旧任务仍存在时有效；如果激进清理已完成或失败的任务，去重窗口会随之消失。
这些长驻进程方案（如 Celery、BullMQ、Kafka 消费者、Temporal worker）此前很难直接部署在纯 Serverless 平台上，往往需要单独的容器托管服务。
与 Celery 同类的方案还包括 Node.js 生态的 BullMQ（基于 Redis）、Python 的 RQ、跨语言的 Kafka 消费者组和 Temporal 工作流 worker。
并行处理在工程实现上通常依赖云函数或任务队列架构，常见实现包括AWS Lambda、Azure Functions、Celery、BullMQ
由于LLM推理延迟通常在数秒量级，同步HTTP请求容易触发网关超时，生产部署往往需要引入任务队列（如Celery、BullMQ）或WebSocket/SSE来维持长连接
应对智能体高并发通常需引入异步任务队列（如 Celery、BullMQ）、对长任务进行流式拆分、对工具调用设置超时与熔断机制，以及区分快速响应通道与后台执行通道
绝大多数队列库（如Celery、Sidekiq、BullMQ）的默认实现只序列化业务参数，不会自动携带触发者元信息，也不区分当前用户与真实操作者
全部知识事实 (10)
队列工具选型标准是团队在凌晨 2 点故障时仍能正确运维：BullMQ 适合 Node.js worker，Temporal 适合多步骤长时间等待与审批编排，AWS SQS 适合 AWS 原生托管队列，Cloudflare Queues 适合边缘友好批量处理架构。
50%待验证让 cron 直接执行完整 Agent 逻辑（如 */15 * * * * node run-agent.js）是坏模式；标准模式是 cron 只负责入队（如 node enqueue-agent-job.js，写入 BullMQ、SQS 或 Cloudflare Queues），由独立 worker 执行 Agent 步骤。
50%待验证BullMQ 的指数退避公式为 2 ^ (attempts - 1) * delay；基础延迟 3000ms 时第 7 次尝试需等待约 192 秒（约 3.2 分钟）。
50%待验证BullMQ 的 jobId 去重仅在旧任务仍存在时有效；如果激进清理已完成或失败的任务，去重窗口会随之消失。
50%待验证这些长驻进程方案（如 Celery、BullMQ、Kafka 消费者、Temporal worker）此前很难直接部署在纯 Serverless 平台上，往往需要单独的容器托管服务。
50%待验证与 Celery 同类的方案还包括 Node.js 生态的 BullMQ（基于 Redis）、Python 的 RQ、跨语言的 Kafka 消费者组和 Temporal 工作流 worker。
50%待验证并行处理在工程实现上通常依赖云函数或任务队列架构，常见实现包括AWS Lambda、Azure Functions、Celery、BullMQ
50%待验证由于LLM推理延迟通常在数秒量级，同步HTTP请求容易触发网关超时，生产部署往往需要引入任务队列（如Celery、BullMQ）或WebSocket/SSE来维持长连接
50%待验证应对智能体高并发通常需引入异步任务队列（如 Celery、BullMQ）、对长任务进行流式拆分、对工具调用设置超时与熔断机制，以及区分快速响应通道与后台执行通道
50%待验证绝大多数队列库（如Celery、Sidekiq、BullMQ）的默认实现只序列化业务参数，不会自动携带触发者元信息，也不区分当前用户与真实操作者
50%