长任务不是长连接

很多人谈长程 Agent，会自然想到「让模型连续工作更久」。这个说法能解释演示，却解释不了生产。

生产里的长任务不是一条不断延长的聊天连接。它更像一个后台 job：有发起人，有任务参数，有队列，有 worker，有步骤状态，有等待，有重试，有审批，有超时，有恢复，也有最终产物。模型只是其中一个执行组件。

如果把长程 Agent 当成长连接，系统会遇到很现实的问题：进程重启怎么办，工具调用失败怎么办，人半小时后才审批怎么办，外部 API 限流怎么办，某一步已经成功是否要重跑，worker 被抢占后从哪里恢复，用户刷新页面后任务状态在哪里。

这些问题都不是「更久思考」能解决的。它们需要生产任务队列。

队列决定任务能不能被接住

Temporal 的 Task Queue 文档给了一个很稳的参照。Task Queue 是 worker 轮询的轻量队列，worker 有可用容量时才拉取任务；Workflow Task 和 Activity Task 会保留在队列中，worker 挂掉后也不会因为某个进程消失就丢掉。

这类机制对 Agent 很关键。一个长程 Agent 任务不应该绑死在某个进程、某台机器、某个浏览器 tab 或某次 HTTP 请求上。它应该先进入 job 系统，再由 worker 领取执行。worker 挂了，任务还在；worker 恢复，任务继续；需要扩容，就增加 worker；需要限流，就控制队列和并发。

这听起来像老派后台系统，但 Agent 更需要它。因为 Agent 的工作天然不稳定：模型调用会失败，工具会超时，外部服务会限流，人会迟迟不批，任务会被拆成很多步。没有队列，长程只是一次高风险长跑。

step 比 run 更重要

Inngest 的 durable execution 文档把长函数拆成 steps，每个 step 可以独立执行、重试和持久化结果。成功过的 step 不会因为后续失败而重复执行。这一点很适合 Agent。

很多 Agent 系统现在只记录 run：一次任务开始了、结束了、失败了。但生产排障时，有用的是 step。

一个代码修复 Agent 的 run 里，可能包含：

  • 读取 issue。
  • 检出仓库。
  • 安装依赖。
  • 搜索相关文件。
  • 生成补丁。
  • 运行测试。
  • 修复失败。
  • 提交 PR。
  • 等待 review。

如果第七步失败，系统不应该从第一步重来。安装依赖不应该重跑，已经生成的中间产物不应该丢，已经通过的测试结果也不应该忘。把 run 拆成 step，才能让 Agent 的失败成本可控。

这也是为什么「把所有历史塞回模型」不是状态管理。状态管理是：每一步是否完成，输出是什么，能不能重试，能不能跳过，谁批准，是否可回放。

失败要局部重试，而不是整条任务重跑

Temporal 的 Retry Policies 文档提醒了一个常被忽略的工程原则：默认自动重试的是 Activity，而不是整个 Workflow。文档也建议把 API 调用、LLM 调用这类易失败或非确定性操作放进 Activity。

放到 Agent 上，这个原则很实用。

模型调用失败，重试模型调用。邮件发送失败，重试发送动作。数据库查询超时，重试查询。不要因为某个外部工具临时失败，就让整个 Agent 从头重新规划、重新读取、重新生成所有中间结果。

整条任务重跑会带来三类问题。

第一是成本。长任务前半段可能已经消耗了大量 token、CI、网络和人工审批。重跑会把成本翻倍。

第二是一致性。外部世界已经改变过一次，再重跑可能产生不同结果。比如已经创建了分支、发过消息、写过记录。

第三是行为漂移。模型第二次规划未必和第一次一样。你以为是在恢复，实际是在启动一个新任务。

所以长程 Agent 的稳定性，核心是「失败时尽量只重做最小一步」。

等待状态不该占着 worker

长程 Agent 大量时间都在等。等工具返回，等 CI，等人工审批，等定时任务，等外部系统解锁。

Inngest 的 concurrency 文档区分了正在执行的 step 和 sleeping、waiting、paused 的 function run。并发限制约束活跃执行，不把等待状态当成一直占用 worker。这对 Agent 很重要。

如果一个 Agent 等人审批时还占着 worker，系统并发很快会被耗尽。十个等待审批的任务，看起来都「在运行」，实际没有任何计算发生。生产系统应该把等待变成状态，而不是把等待变成占用。

OpenAI Agents SDK 的 human-in-the-loop 文档也指向同一件事。工具调用可以暂停，等人批准或拒绝后再通过 RunState 恢复；文档还建议把 pending work 存到数据库或队列中。人工接管重点是任务状态。

这会改变产品设计。审批按钮不是 UI 小功能，它是 durable execution 的一部分。系统必须记住：谁需要审批，审批什么参数，审批前状态是什么，审批后从哪一步恢复。

云厂商也在把长任务显式化

Amazon Bedrock AgentCore Runtime 的 long-running agents 文档，已经把这件事写成云产品能力。它支持异步长任务：Agent 可以先回复「已开始处理」，然后后台继续执行，用户稍后查询结果。SDK 里也有 add_async_task 和 complete_async_task 这样的任务追踪机制。

长程 Agent 的产品形态正在从「等它说完」变成「提交任务、后台执行、查询状态、返回结果」。这正是传统任务系统的形状。

Microsoft Agent Framework 的 workflow checkpoint 文档也类似。checkpoint 会在 superstep 结束后保存 workflow 状态、executor 状态、pending messages、pending requests/responses 和 shared states，并支持从指定 checkpoint 恢复。

这里最重要的是，checkpoint 保存的重点是执行现场。哪些 executor 处于什么状态，哪些消息待处理，哪些 request/response 还没完成，shared state 里有什么。这才是长任务能恢复的基础。

长程 Agent 的最小生产模型

把这些文档放在一起，可以得到一个很朴素的最小模型。

第一，任务要先进入 job 表或队列。用户发起的一个可追踪 job。

第二，job 要拆成 step。每个 step 有输入、输出、状态、重试策略、超时、依赖和副作用标记。

第三，worker 只处理活跃 step。等待人、等定时器、等外部事件时，释放 worker。

第四，失败要局部重试。能重试工具调用，就不要重跑整个任务；能从 checkpoint 恢复，就不要重新规划。

第五，高风险动作要进入 pending state。人类审批、预算确认、权限提升都应该成为任务状态的一部分。

第六，最终产物和中间证据都要落盘。结果、日志、trace、审批记录、工具输出和错误路径都要能复盘。

这套东西听起来不像 AI，但它决定 AI 能不能生产化。

为什么这不是旧系统换个名字

有人会说，队列、worker、checkpoint、retry 都是老东西。没错。也正因为它们是老东西，Agent 才应该尽快回到这些工程常识里。

Agent 的新问题在于：每个 step 里可能包含非确定性模型调用，任务路径可能动态变化，工具结果可能改变下一步计划，人类审批可能穿插其中，输出还会影响后续记忆和评估。

所以我们不能把 Agent 退化成普通工作流引擎。但也不能把它神化成一条会自己坚持到底的长对话。更稳的理解是：Agent 是动态决策组件，任务队列和 durable execution 是它进入生产的骨架。

没有骨架，模型再强也只能跑演示。有了骨架，模型失败、工具失败、人类迟到、worker 重启，都不会直接把整个任务摔碎。

分水岭是可恢复

长程 Agent 真正缺的不是「想得更久」。它缺的是中断后能恢复，失败后能局部重试，等待时不占资源，审批后能接着跑，重启后不丢现场。

这就是生产任务队列的价值。

未来的 Agent 平台如果要承接真实工作流，核心卖点不会只是「能连续运行几小时」。更重要的是，它能不能把这几小时拆成可管理的任务状态。谁在跑，跑到哪一步，卡在哪里，能不能暂停，能不能恢复，能不能只重试失败那一步。

长程重点是任务可靠性。