长任务 Agent：跑一夜的竞品监控

客服 Agent 一次对话几分钟，错了大不了转人工。但“每天凌晨把 20 个竞品链接的价格、库存、评价全爬一遍”这种活，一跑几小时——没有保命设计，半夜崩了你都不知道。

前面章节的 Agent 都在“短平快”场景里：一轮对话几十秒到几分钟。长任务完全不同——跑的时间越长，出事的概率越接近 100%。API 会超时、网络会抖、平台会限流、模型会抽风。跑 10 分钟不出事是运气，跑 10 小时不出事靠设计。

• 竞品监控：每晚盯 20 个链接的价格/库存/上新，早上给你一份异动报告。
• 评价分析：大促后把 5000 条新评价逐条打标归类，出一份痛点报告。
• 批量上新：把 200 个 SKU 的标题、卖点、详情文案一次性生成并入库。

这三个场景的共同点：任务可以拆成一个个独立小格子。这是长任务能救回来的前提——先记住这句话，下面的设计全靠它。

2-8 节讲过 Agent 死循环。长任务里死循环更阴：它不会原地打转，而是慢慢跑偏——比如竞品页面结构变了，Agent 反复重试同一个失败动作，每轮都在烧 Token，一夜烧掉几百块，早上给你一堆报错。

解法简单粗暴：每个子任务设最大迭代次数。抓一个链接最多试 5 轮，5 轮还不行就记下来跳过，绝不纠缠。就像你给运营定的规矩：一个客人的问题 10 分钟搞不定就升级，别让一个人卡死整条客服线。

长任务最怕的不是失败，是从头再来。5000 条评价分析到 4800 条崩了，如果没有断点，明天重跑又是几小时。断点恢复的核心动作就一个：每完成一格，就把进度写进磁盘（4-1 节的交接卡思想，只不过交接对象是“明天重启的自己”）。

• 单次调用超时：一次 API 请求 30 秒没回就放弃，记为失败格——不让一个卡死的请求拖住整夜。
• 子任务超时：一个链接 5 分钟没搞定就跳过——跟迭代上限双保险。
• 总时长兜底：整个任务超过 4 小时没跑完，强制收工，把已完成的先发你——早上 8 点你收到的是“80% 结果 + 异常清单”，而不是一个还在转的圈。