AI agent 原型阶段通常一次只跑一个任务。上线后情况会复杂得多：有人问简单问题，有人提交长流程，有些任务等待人工确认，有些工具调用失败需要重试。如果都进同一个队列，短任务会被长任务拖慢，重试可能挤占正常请求。
任务优先级队列的目标，是让不同类型任务各得其所。它不是“把任务放到后台”这么简单，而是要控制等待时间、重试风暴、人工确认卡点和不同用户之间的公平性。
先给结论：队列要按任务类型分层
| 队列 | 适合任务 |
|---|---|
| realtime | 短问答、快速分类 |
| workflow | 多步工具流程 |
| review_waiting | 等待人工确认 |
| retry | 工具超时后的限次重试 |
| batch | 离线生成、批量整理 |
一个队列承载所有任务，迟早会互相影响。
最小任务模型
队列设计先从任务数据结构开始：
{
"taskId": "run_123",
"queue": "workflow",
"priority": 72,
"status": "queued",
"taskType": "content_generation",
"userTier": "team",
"createdAt": "2026-05-06T10:00:00Z",
"deadlineAt": "2026-05-06T10:05:00Z",
"attempt": 0,
"maxAttempts": 2,
"requiresHumanReview": false,
"costBudget": 1200
}
至少要有 queue、priority、status、attempt、deadlineAt。没有这些字段，队列就只能先进先出，无法表达业务优先级。
一、短任务要保护响应时间
用户等待中的短任务应该优先处理。比如意图分类、简单问答、格式转换。如果被长任务堵住，用户会觉得系统卡死。
可以为 realtime 队列设置独立并发和更短超时。
常见配置：
| 队列 | 并发 | 超时 | 说明 |
|---|---|---|---|
| realtime | 高 | 5-10s | 面向用户等待 |
| workflow | 中 | 1-5min | 多步工具任务 |
| retry | 低 | 按错误类型 | 防止重试挤占资源 |
| batch | 低 | 长 | 离线任务 |
短任务不是永远最高优先级，但它们应该有独立资源，避免被批处理拖垮。
二、长流程要有状态，而不是占住请求
多步 agent 任务应该创建 taskId 后进入后台队列。前端显示进度，而不是一直等待 HTTP 请求。
状态至少包括：queued、running、waiting_review、retrying、completed、failed、cancelled。
更细的状态能帮助前端和运营判断卡在哪里：
queued -> running -> waiting_tool -> waiting_review -> running -> completed
| | |
-> retrying -> cancelled -> failed
等待人工确认时，worker 应该释放任务；确认后重新入队。不要让一个 pending review 的任务占住执行线程。
三、重试队列要限流
工具失败后的重试不能和正常任务抢资源。重试队列要限制并发，并采用退避策略。失败次数超过上限后，任务应转入人工或失败状态。
不要让失败请求越重试越多。
重试任务的优先级通常要低于新任务，除非它影响用户正在等待的流程。可以用退避时间控制：
nextRetryAt = now + baseDelay * 2 ^ attempt
同时要记录 lastErrorType。如果连续两次都是 permission_denied，说明分类错了，不应该继续重试。
四、人工确认会改变队列流向
等待人工确认的任务不应该继续占用执行资源。它应该进入 review_waiting 状态，确认后再回到 workflow 队列。
这样可以避免一堆等待确认的任务占住 worker。
确认结果也要结构化：
{
"taskId": "run_123",
"reviewDecision": "approved | rejected | needs_change",
"reviewerId": "user_456",
"comment": "可以发送，但标题需要改短。",
"resumeQueue": "workflow"
}
不要让 agent 从自然语言评论里猜是否可以继续。
五、优先级公式要透明
可以先用简单公式：
priority = urgency + userTierWeight + taskTypeWeight - retryPenalty - costPenalty
| 因子 | 作用 |
|---|---|
| urgency | 越接近 deadline 越高 |
| userTierWeight | 团队或付费用户权重 |
| taskTypeWeight | 交互任务高于批任务 |
| retryPenalty | 防止失败任务抢占资源 |
| costPenalty | 控制高成本任务排队 |
公式不必复杂，但要可解释。否则用户会觉得任务随机排队。
六、失败案例：批量任务堵住实时问答
一个团队晚上跑批量内容生成，和白天用户问答共用同一队列。批量任务没有完成时，用户简单问题也要等很久。
修复后，批量任务进入 batch 队列，实时问答有独立并发。团队还设置了 retry 队列限流，避免外部工具抖动时重试任务把 worker 占满。批量任务可以慢，交互任务必须快。
七、队列 Checklist
- 是否按任务类型拆队列
- 短任务是否有独立并发
- 长任务是否异步并可查询状态
- 重试是否进入独立队列并限流
- 人工确认是否释放执行资源
- 每类任务是否有超时和取消机制
- 是否监控排队时间和完成时间
- 等待人工确认时是否释放 worker
- 重试任务是否有退避和最大次数
- 优先级公式是否可解释
- 是否监控每个队列的积压和超时
结语
AI agent 的队列设计决定它在真实并发下是否稳定。短任务、长流程、重试、人工确认和批量任务分层处理，再配合状态机、优先级公式和监控指标，才能让系统既快又不乱。
延伸阅读：
