生产级 Agent 为什么不能一直挂在 HTTP 请求上

Render 在生产 Agent 基础设施指南中指出，传统“收到 HTTP 请求、完成全部处理、返回响应”的模式不适合长时间、状态依赖且结果不确定的 Agent。更可靠的架构是快速确认请求，再把工作交给队列、后台 Worker 或持久工作流。

一句话结论：Agent 可以思考几分钟甚至几小时，但 HTTP 连接、进程和部署不会耐心等它；生产系统必须把任务生命周期从一次网络请求中拆出来。

普通 API 通常在秒级完成，超时后客户端可以安全重试。Agent 可能调用多个模型和工具、等待人工批准，还可能因为外部服务限流停顿。如果运行绑定在 Web 进程上，一次部署、扩容或连接断开就会丢失状态。

队列解决接收与执行解耦：API 返回任务 ID，Worker 有资源时再处理。工作流引擎进一步记录每一步状态、重试和超时，让任务在进程重启后继续。长任务还可以并行拆分，再聚合结果。

最危险的是盲目重试。模型读取失败可以重跑，发送付款、删除资源或给客户发邮件却可能执行两次。每个有副作用的步骤都需要幂等键、执行记录或补偿操作。人工审批也要放在动作之前，而不是任务完成后发一封通知。

Render 的文章同时推广自家 Workflows 产品，因此性能和便利性属于供应商主张。不过队列、持久状态和幂等性并非某家平台专属，Temporal、Celery、BullMQ 及云厂商工作流都在解决类似问题。

关键事实

• 来源：Render 工程博客与 Workflows 文档
• 涉及技术：任务队列、Worker、工作流引擎、状态持久化、补偿操作
• 关键边界：模型推理重试与有副作用的工具重试必须分开
• 典型场景：长时间研究、批量处理、多工具 Agent、人工审批

OC 判断

Agent 生产化首先是分布式系统问题，然后才是提示词问题。团队需要定义任务接受、运行、暂停、取消、失败和恢复语义，并让每个外部动作可追踪。只把请求超时从 30 秒改成 30 分钟，问题不会消失。

为什么重要

• 对开发者：任务 ID、幂等键和状态机应在原型阶段就设计。
• 对运维：部署和扩容不能让正在运行的 Agent 静默消失。
• 对用户：长任务需要可查询进度、取消入口和明确失败状态。

参考来源

• Infrastructure patterns for agentic applications
• Intro to Render Workflows
• Durability as code: introducing Render Workflows