Anthropic 在 2026 年 Google Cloud Next 官方事件页上写了一句直白的话：Most AI agents degrade when task complexity increases or execution runs long。多数智能体在任务变复杂或执行拉长时会退化——这正是 Web 端企业 AI 应用开发从秒级 Demo 走向小时级任务时，被卡住最久的那个缺口。
本文不谈 Demo，只讲生产化。以下 4 个改造点均来自我们过去一年的工程复盘，配合 CTO 可直接照抄的通过标准。关于 Web 端 Agent 工程的量化基线，可参考我们整理的 5 组真实数据。
为什么长时任务在 Web 端会崩：三类根因
秒级任务和小时级任务不是"量"的差别，是"系统"的差别。一个能稳定跑 3 秒的智能体，直接拿去跑 3 小时，大概率在三类根因上依次崩掉。
根因一：连接中断
Web 端基于 HTTP/SSE/WebSocket，浏览器标签页关闭、移动网络切换、网关空闲超时都会掐断会话。SSE 连接 60-90 秒无心跳就会被网关回收，而任务执行到一半，状态全在内存里——一切归零。
根因二：上下文衰减
长任务里工具返回、中间结果、用户补充指令不断累积。超出上下文窗口后，早期关键信息被截断，模型开始"忘记"任务目标，输出逐步漂移。这是最隐蔽的失败：不报错，但结果错。
根因三：任务幂等缺失
Demo 里一次调用完成；生产里同一个任务可能被触发两次——重试、双端并发、webhook 重复回调。没有幂等键，写入、通知、扣款就会重复。审计时只能看到"任务成功"，却不知道执行了两遍。
4 个工程改造点：从秒级 Demo 到小时级任务
改造顺序建议按下面的编号走，每一点都有明确的通过标准，可搬进评审会逐条打勾。
改造点 1：checkpoint 持久化（先做这个）
把智能体每一步的完整状态（对话历史、工具调用结果、已完成的子任务、目标清单）落盘到数据库或对象存储，而不是留在内存。
- 实现要点：按"任务 ID + 步骤序号"存储快照；每步工具调用完成后写一次；恢复时从最近 checkpoint 续跑，而不是从头重放。
- 通过标准：杀掉进程 / 关闭浏览器后重启，任务能从最近 checkpoint 恢复，恢复时间 ≤ 5 秒，且不丢已完成的副作用。
改造点 2：任务队列与重试
把长任务交给队列（如 Redis Stream、Kafka、云上 MQ），由 worker 消费。任务定义与执行进程解耦，进程死了任务不丢。
- 实现要点：任务入队即生成全局唯一任务 ID；消费者处理时携带重试次数与退避策略；对"可重试"与"不可重试"错误分类——网络超时可重试，业务校验失败直接进死信队列。
- 通过标准：单点 worker 崩溃后任务自动重新调度；重试间隔指数退避（1s / 4s / 16s），单任务最多 3 次；死信队列可人工干预，周积压为 0。
改造点 3：超时与熔断
长任务也要有"最长执行时间"的上限，并对模型调用做熔断保护。模型接口抖动或降级时，不能让所有任务一起卡死。
- 实现要点：任务级 TTL（如 2 小时）与单步调用超时（如 60 秒）分开设；模型错误率连续 N 次超过阈值时熔断，切到降级模型或排队，不直接失败。
- 通过标准：超时任务有明确的终态（成功 / 失败 / 超时），且超时后触发补偿逻辑；模型熔断 30 秒内生效，恢复后自动放量。
改造点 4：可观测性与审计链
小时级任务无法靠人盯，必须能回答"现在跑到哪一步、为什么停、每一步调用了什么、花了多少钱"。
- 实现要点：埋点覆盖任务生命周期（入队 / 开始 / 每步 / 完成 / 失败）；记录每步的模型调用 token 与成本；审计日志不可篡改，至少保留 90 天。
- 通过标准：任意时刻可查询任务当前进度与所在步骤；任务失败可回溯到具体一步与具体原因；单任务成本可对账到分。
秒级 vs 小时级任务：五维对比表
| 维度 | 秒级任务（Demo） | 小时级任务（生产） |
|---|---|---|
| 会话保持 | 单次请求，不依赖会话 | 跨请求持久会话，断连可恢复 |
| 状态恢复 | 无状态，失败重跑 | checkpoint 快照，从断点续跑 |
| 成本模型 | 按调用计费，可预估 | 含重试、恢复、审计开销，需预算上限 |
| 故障域 | 单次调用失败，影响小 | 进程 / 队列 / 模型多故障域，需熔断兜底 |
| 验收方式 | 单次输出正确即可 | 成功率 + 恢复时间 + 成本 + 审计链四指标 |
判断你的场景是否属于"小时级"：任务里是否有多个工具调用、是否需要等待外部系统返回、是否会跨越用户多次会话。命中任意一条，就按生产级设计。
反面教训：长任务中断 6 小时，200+ 工单积压
某零售行业客户把客服工单自动处理 Agent 从 30 秒 Demo 直接推上线，第一周就出了事故。任务要在多个系统间流转（CRM 查单、库存确认、退款发起），单笔任务耗时 5-40 分钟不等。
事故现场：夜间一次数据库升级触发 worker 批量重启，所有内存态任务全部丢失。用户侧表现为工单"卡住不动"，服务台第二天上班发现 200+ 工单积压，其中 47 笔已经完成退款、却因状态未落库而重复发起。
修复方案就是我们上面 4 个改造点的组合：checkpoint 落库、任务队列 + 死信、幂等键（用退款单号做唯一约束）、审计日志补全。修复后任务成功率从 41% 回升至 89%，且不再出现重复退款。这个案例的结论很朴素——长时运行 Agent 的生产化，本质上是在给"状态"找可靠的存放位置。
CTO 五步落地清单
- 盘点任务清单：列出所有计划由 Agent 承接的任务，标注单笔耗时与是否跨系统。通过标准：识别出 ≥3 个"小时级"任务，作为首批改造对象。
- 先上 checkpoint：为首批任务设计状态模型与存储。通过标准：进程 kill -9 后恢复时间 ≤5 秒，不丢已完成的副作用。
- 接队列与重试：任务入队 + 消费者 + 死信。通过标准：worker 单点崩溃自动重调度，死信周积压为 0。
- 配超时熔断与预算上限：任务 TTL、单步超时、模型熔断、成本上限。通过标准：超时任务终态明确；模型故障 30 秒内熔断；单任务成本可对账。
- 补审计与复盘机制：全链路日志 + 每周成功率 / 恢复时间 / 成本三指标复盘。通过标准：任意失败可回溯到具体一步；连续两周成功率 ≥ 90%。
这五步不必一次做完，但顺序不建议换。checkpoint 是地基，队列是骨架，熔断是护栏，审计是眼睛。若你的团队还在 PoC 阶段，可先对照 5 个工程化门禁 自查是否具备进入生产化的条件。
常见问题
小团队没有专职平台工程师，能做长时任务生产化吗？
能做，但起点要低。先用托管队列（云上 MQ / Redis）而非自建 Kafka，checkpoint 用一张带 JSON 字段的数据表即可起步。团队 3 人以上、任务量稳定后，再评估是否需要 多智能体编排平台。
长任务的成本模型怎么定？会不会失控？
核心是设预算上限：单任务 token 上限、月总成本上限、熔断阈值三件套。长任务的重试和恢复会放大成本，把 token 与成本按任务 ID 记账，每周对账一次。量级估算可参考 企业 AI 应用成本测算。
自建任务编排 vs 直接用平台，怎么选？
看两个变量：任务形态是否稳定、团队是否有运维余量。任务形态变化快、需要深度定制，自建；想 2-4 周上线且任务标准化程度高，用平台。无论哪种，checkpoint 和审计链都是必需品，平台只是帮你省掉一部分。
长任务里用户数据跨系统流转，安全怎么保证？
三个动作：任务级别的数据隔离（每任务独立凭证）、敏感字段脱敏后入日志、审计链保留访问记录。Web 端场景还要额外处理会话过期与用户离线的数据权限回收。
ROI 怎么量化？向董事会汇报用什么口径？
用"任务成功率 × 单任务人工成本"算替代收益，再减掉 infra 与开发成本。以文中零售客户为例：89% 成功率对应每月减少约 400 人时的重复人工，一个季度即可覆盖改造投入。别用"提效 N%"这种模糊口径，董事会只认账本。
如果你的场景已经出现"Demo 能跑、上线就断"，欢迎带着任务清单来聊——优码云（umayun） 的工程师可以帮你做一次长时运行 Agent 的架构体检。