CSDN 原文镜像

本文为作者 CSDN 博客的全文镜像，原文发布于 2026-08-12。为适配本站结构，仅补充了站内元数据与来源说明，正文主体保持原文内容。

• 原文链接：https://blog.csdn.net/m0_63309778/article/details/163697628
• 站内分区：Agent / Agent LongTask

前言

在设计 Agent 系统时，一个非常容易产生疑问的问题是：

普通 Agent Run 本身也可以后台运行，也可以增加 Checkpoint、重试和状态恢复，为什么还需要专门提出 LongTask 这个概念？

这个疑问本身是成立的。

LongTask 并不是一种全新的 Agent，也不是某种普通 Agent 无法实现的特殊算法。一个普通 Agent Run 如果不断加入 Persistence、Checkpoint、暂停恢复、Step、SubTask、Scheduler、Human-in-the-loop 等能力，它最终确实可以演化成长时任务系统。

所以真正的区别并不在于：

普通 Run 没有 Checkpoint
LongTask 有 Checkpoint

而在于系统的核心执行抽象发生了变化。

普通 Agent Run 关注的是：

如何把一次 Agent 执行跑完。

而 LongTask 关注的是：

如何把一个由多个 Agent Run、确定性任务、等待节点、人工审批和外部系统共同组成的复杂目标可靠地做完。

因此更准确的关系应该是：

LongTask
↓
Stage / Step / Dependency
↓
Agent Run / Worker Task / Approval / Waiting

而不是：

Agent Run VS LongTask Run

也就是说：

LongTask 编排 Run，而不是替代 Run。

这也是本文理解 Agent LongTask 的核心。

---

一、先从最普通的 Coding Agent Run 说起

假设用户给 Coding Agent 一个任务：

修复登录接口偶发出现的 NullPointerException。

Agent 接到任务后，通常会经历一个连续的执行过程：

理解问题
↓
搜索相关代码
↓
阅读 Controller / Service
↓
分析异常原因
↓
修改代码
↓
执行测试
↓
修复完成

Agent Runtime 内部实际上一直在执行一个循环：

构建 Context
↓
调用 LLM
↓
LLM 决定下一步动作
↓
调用 Tool
↓
观察 Tool Result
↓
重新构建 Context
↓
继续调用 LLM

OpenAI Agents SDK 对 Runner 的描述也是类似的 Agent Loop：Runner 调用模型，处理工具调用或 handoff，再继续下一轮，直到产生最终输出或满足停止条件。

对于“修复一个 Bug”这样的任务，这种 Run 模型非常自然。

即使它执行两三分钟，甚至更久，也没有必要因为时间长就把它定义成 LongTask。

此时用户交给系统的业务目标和 Agent Run 基本是一一对应的：

用户目标
“修复登录 Bug”

↓

Agent Run
run_10001

Run 完成，用户目标也完成。

---

二、给普通 Run 加上 Persistence，它仍然可以只是 Run

现在假设 Coding Agent 已经完成：

✓ 找到异常位置
✓ 确定问题原因
✓ 修改代码
● 正在运行测试

这时 Worker 突然崩溃。

如果所有状态只保存在当前 Python 进程内存中，那么新的 Worker 很难知道：

Agent 之前已经做了什么？

于是我们开始引入 Persistence。

Persistence 的意思并不复杂：

将 Agent 当前执行状态保存到进程之外，使状态可以跨请求、跨 Worker、跨进程继续存在。

LangGraph 官方把 Persistence 明确拆成两类：Checkpointer 保存 thread 范围内的 Graph State Snapshot，而 Store 用于保存跨 thread 的长期应用数据。Checkpointer 可以支撑 conversation continuity、fault tolerance、human-in-the-loop 和 time travel 等能力。

于是 Agent 可以在执行过程中保存：

Checkpoint #1
完成代码搜索

Checkpoint #2
完成问题分析

Checkpoint #3
完成代码修改

当前：
准备执行测试

Worker 崩溃以后：

Worker A Crash
↓
读取 Checkpoint
↓
Worker B
↓
继续执行测试

LangGraph 的 Checkpointer 会在 Graph 执行过程中保存状态快照，这也是 fault-tolerant execution 和恢复能力的重要基础。

但请注意：

拥有 Checkpoint 并不意味着它一定应该变成 LongTask。

这个 Run 依然可能只是：

修复一个 Bug

只不过它现在变成了一个更加可靠的、可以恢复的 Agent Run。

这也是理解 Run 和 LongTask 最容易被忽略的一点。

---

三、Persistence、Checkpoint 和 Durable Execution 到底是什么关系

这几个概念非常容易被混在一起。

可以把它们理解成三个层次。

Persistence：状态能不能保存下来

Persistence 解决：

Agent 当前状态
不要只存在内存

例如保存：

Messages
Tool Results
Plan
当前 Node
Run Status
Artifact Reference

Checkpoint：具体保存到哪个恢复点

Checkpoint 是 Persistence 的一种具体表现。

例如：

Checkpoint 1
仓库分析完成

Checkpoint 2
方案设计完成

Checkpoint 3
后端修改完成

Checkpoint 表示：

如果执行中断，系统可以从哪个已经确认的状态继续。

Durable Execution：整个任务能不能跨故障继续

Durable Execution 是最终获得的运行能力。

Temporal 对 Durable Execution 的定义非常直接：Workflow Execution 的状态和进度能够在 failure、crash 或 server outage 等情况下继续保持，并恢复执行。Temporal 的 Workflow 本身可以运行数秒，也可以持续多年，而不要求原来的 Worker 进程一直存在。

因此关系可以理解为：

Persistence
↓
保存状态

Checkpoint
↓
建立恢复边界

Replay / Resume
↓
重建执行

Durable Execution
↓
任务获得长期可靠运行能力

所以：

Persistence 是机制，Checkpoint 是恢复点，而 Durable Execution 是最终获得的能力。

---

四、LongTask 的真正分界出现在“一个 Run 已经表达不了整个任务”时

继续把 Coding Agent 的任务放大。

现在用户要求：

把系统认证体系从 Session 改造成 JWT，同时增加 Refresh Token、权限校验、自动化测试、前端适配、数据库 Migration 和迁移文档。

这已经不再像一个简单 Bug Fix。

它可能需要：

仓库分析
↓
架构设计
↓
后端认证改造
↓
Refresh Token
↓
权限体系调整
↓
前端认证改造
↓
数据库 Migration
↓
单元测试
↓
集成测试
↓
修复失败测试
↓
等待 CI
↓
人工确认
↓
生成迁移文档

其中甚至可能同时存在：

Backend Agent

Frontend Agent

Test Agent

Documentation Agent

这时候如果整个任务仍然只使用：

run_10001

去表达，就会越来越别扭。

因为可能出现：

Backend Agent Run      completed
Frontend Agent Run     completed
Test Agent Run         failed
Migration Task         completed
CI                     waiting
Documentation Agent    pending

那么问题来了：

“JWT 认证体系改造”这个整体任务现在到底是什么状态？

显然不能通过某一个 Run 的状态回答。

于是系统需要一个更高层的业务执行对象：

LongTask

JWT 认证体系改造
status = running
progress = 68%
current_stage = testing

这就是 LongTask 真正出现的地方。

---

五、LongTask 的核心不是“执行更久”，而是“推进一个持久化任务状态机”

普通 Agent Run 的执行思维通常是：

启动 run_agent()
↓
一直执行
↓
直到返回

而 LongTask 的运行思想发生了变化：

读取 LongTask 当前状态
↓
判断哪些 Step 可以执行
↓
调度对应执行单元
↓
保存结果
↓
更新任务状态
↓
决定下一步

当前 Worker 并不需要把整个任务执行到底。

它甚至可能只负责：

执行一个 Step

执行完成以后释放。

下一步可能由另一台机器上的 Worker 继续。

所以：

Agent Run

更接近：

执行一次 Agent Loop。

而：

LongTask

更接近：

推进一个 Persistent Task State Machine。

这就是二者在代码和架构层面真正重要的分界。

---

六、为什么 Durable Execution 对 Coding Agent 特别重要

大型 Coding Agent 的执行天然具有很多长时任务特征。

例如一次大型仓库升级：

Java 17 升级 Java 21，同时升级 Spring Boot，修复 Breaking Changes，修改 Docker、CI 和测试，并提交 PR。

任务可能持续几十分钟。

但这里“长”的并不只是计算时间。

更重要的是，它中间会不断发生：

执行代码修改
↓
等待测试
↓
修复失败
↓
等待 CI
↓
等待人工确认
↓
继续执行

这意味着任务生命周期可能持续数小时，但是实际占用 Agent Worker 的时间只有其中一部分。

一个 Durable LongTask 应该允许：

10:00
Agent 完成代码修改

10:10
进入 waiting_ci

此时没有 Worker 持续执行

10:30
CI Callback

10:31
新的 Worker 恢复任务

10:40
进入 waiting_user

14:00
用户批准

14:01
再次恢复任务

整个任务存在四个小时。

但没有任何线程需要连续运行四个小时。

这就是：

Long-running 不等于 Continuous Running。

真正需要的是：

Durable Execution。

---

七、Human-in-the-loop：LongTask 为什么能够“睡着以后再醒来”

LangGraph 当前将 Human-in-the-loop 与 Durable Execution、Persistence、Streaming 一起视为 Agent orchestration runtime 的核心能力。

Human-in-the-loop 在 Coding Agent 中非常典型。

假设 Agent 分析以后发现：

必须修改 users 表结构。

这种操作风险较高，于是 LongTask 进入：

waiting_user

前端展示：

Agent 准备执行数据库 Migration。

影响：
users
sessions

[查看 Migration]
[批准]
[拒绝]

这时系统不应该让一个 Worker：

await approval...

等几个小时。

而应该：

保存状态
↓
创建 Checkpoint
↓
LongTask = waiting_user
↓
释放 Worker

LangGraph 的 interrupt() 就是类似机制：执行到 interrupt 时，当前 Graph State 会通过 persistence layer 保存，随后执行可以无限期暂停，直到外部再次传入 Command 恢复。

甚至用户第二天才点击批准，也没有问题。

OpenAI Agents SDK 的 RunState 同样支持将待审批 Run 序列化到数据库或 Queue，之后再恢复，这正是长时间 Human-in-the-loop 场景需要的能力。

所以 Human-in-the-loop 真正难的并不是 UI 上的两个按钮。

而是：

任务能不能暂停几个小时甚至几天以后，从正确的位置继续。

---

八、Replay / Resume：系统是怎么“恢复”的

Durable Execution 还有一个非常重要的概念：

Replay

或者：

Resume

不同系统的实现方式不同。

LangGraph 更强调：

Checkpoint
+
Graph State
+
Resume

而 Temporal 更强调：

Event History
+
Replay

Temporal 会持久化 Workflow Event History。当 Worker 重新获得 Workflow Task 时，可以根据历史事件重新执行 Workflow Definition，并检查新的 Commands 是否与历史一致，从而重建 Workflow 当前状态。

可以简单理解为：

过去发生过：

仓库分析完成
后端修改完成
前端修改完成
CI Started

这些事实已经持久化。

Worker 崩溃以后：

新的 Worker
↓
Replay Event History
↓
恢复任务状态
↓
继续等待 CI

而不是：

重新分析仓库
重新修改后端
重新修改前端

因此一个真正 Durable 的 LongTask，真正保存的不是：

“一个 Python 函数现在运行到了第几行。”

而是：

“这个业务执行过程中，哪些事实已经发生并被确认。”

---

九、Streaming：长任务为什么必须让用户看到“现在做到哪里了”

LongTask 还有一个经常被忽略的能力：

Streaming

它和 Durable Execution 解决的是完全不同的问题。

Durable Execution 解决：

后台任务怎么可靠运行？

Streaming 解决：

用户怎么知道后台正在发生什么？

大型 Coding Agent 如果只显示：

Agent 正在工作……

然后持续 30 分钟，用户体验会非常差。

更合理的是：

JWT 认证体系改造                        Running

✓ 仓库分析
✓ 方案设计

代码改造
✓ Backend Agent
✓ Frontend Agent
✓ Database Migration

测试验证
● Integration Test
已执行 128 / 183

○ CI
○ 人工确认
○ 生成迁移文档

LangGraph 官方将 Streaming 和 Durable Execution、Human-in-the-loop、Persistence 一同列为 orchestration runtime 的核心能力。

所以 LongTask 通常会持续产生事件：

longtask.started

stage.started

step.started
step.progress
step.completed

agent.run.started
agent.run.completed

ci.waiting
ci.completed

approval.required
approval.resolved

artifact.created

longtask.completed

这些事件可以写入 Event Log，然后通过：

SSE / streamUrl

推给 Agent UI。

---

十、Persistence + Durable Execution + HITL + Streaming 是如何串起来的

现在可以把这些概念全部连起来。

假设 Coding Agent 正在执行一次框架升级：

LongTask
Spring Boot 升级

Runtime 执行：

Step 1
仓库分析

完成后：

Persistence
保存 Task State

Checkpoint
记录 Step 1 completed

然后：

Step 2
修改后端

执行过程中：

Streaming
实时把修改进度推给 UI

修改完成：

Checkpoint
Step 2 completed

随后进入：

Human-in-the-loop

等待用户确认 Migration

系统暂停。

几个小时以后用户批准：

Resume

如果中间 Worker 重启：

Replay / State Recovery

恢复执行。

最终：

LongTask completed

所以它们之间并不是互相独立的功能。

而是一条完整的可靠执行链：

Persistence
↓
Checkpoint

↓

Durable Execution

↓

Interrupt / Human-in-the-loop

↓

Resume / Replay

↓

Streaming

↓

用户持续观察整个任务

---

十一、为什么大型 Coding Agent 最终会变成 Agent + Workflow

普通 Coding Agent 最自然的结构是：

LLM
↓
Tool
↓
LLM
↓
Tool

但一个大型仓库迁移中，有很多工作实际上并不需要 LLM 决策。

例如：

npm install
mvn test
pytest
docker build
git diff
运行 lint
等待 CI

这些都是确定性任务。

因此成熟 LongTask 往往不会让 LLM 控制所有流程。

更好的结构是：

Workflow
负责整体执行骨架

Agent
负责需要智能判断的 Step

例如：

分析 Repository
↓
Agent Run

修改 Backend
↓
Agent Run

修改 Frontend
↓
Agent Run

执行 Unit Test
↓
Worker Task

测试失败？
├── 否 → 下一步
└── 是
↓
Coding Agent Run
↓
再运行测试

等待 CI
↓
Waiting

人工批准
↓
Interrupt / Resume

创建 PR
↓
Artifact

这就是为什么现代 Agent orchestration framework 会特别强调：

deterministic workflow steps 和 agentic steps 可以组合。

LangGraph 官方也明确把“deterministic steps 与 LLM-driven agentic steps 混合在同一 Graph”作为其核心 orchestration 能力之一。

---

十二、LongTask 为什么需要 Step 级恢复

假设 Spring Boot 升级任务执行到了：

✓ Repository Analysis

✓ Dependency Upgrade

✓ Backend Migration

✓ Frontend Migration

✗ Integration Test

○ Documentation

○ PR

如果整个 LongTask 重新执行：

重新分析 Repository

重新升级依赖

重新修改 Backend

重新修改 Frontend

既浪费资源，也可能引入新的代码变化。

正确做法应该是：

Integration Test failed
↓
创建 Fix Test Step
↓
Coding Agent Run
↓
再次 Integration Test

已经完成的 Step 不重新执行。

这就是：

Step-level Recovery

而不是：

Run-level Retry Only

LangGraph 的 checkpoint 机制本身就围绕状态恢复和 fault tolerance 构建；其生产文档也指出，在 failure、timeout 或 human-in-the-loop pause 后，可以从最近记录的状态恢复，而无需重新执行此前已经完成的工作。

---

十三、LongTask 里为什么还需要普通 Agent Run

讲到这里，很容易又产生一个误解：

那是不是有 LongTask 以后就不需要 Run 了？

恰恰相反。

LongTask 中大量智能 Step 本身就是普通 Run。

例如：

LongTask
“升级认证体系”

├── Step
│   Repository Analysis
│      ↓
│   Agent Run
│
├── Step
│   Backend Migration
│      ↓
│   Coding Agent Run
│
├── Step
│   Frontend Migration
│      ↓
│   Coding Agent Run
│
├── Step
│   Unit Test
│      ↓
│   Worker Task
│
├── Step
│   Fix Test
│      ↓
│   Agent Run
│
├── Waiting
│   CI
│
├── Approval
│
└── Artifact
Pull Request

因此更准确的技术关系是：

LongTask Runtime
↓
Step / Stage / Dependency / Scheduler
↓
Agent Run / Worker Task / Approval / Waiting
↓
Agent Runtime
↓
LLM / Tool / RAG / Memory / Skill

这里各层职责非常清晰。

Agent Runtime 解决：

这一次 Agent 应该怎么思考和执行？

LongTask Runtime 解决：

这么多执行单元应该怎么编排、暂停、恢复、重试和最终完成？

---

十四、什么时候其实不需要 LongTask

LongTask 不是越多越好。

如果你的 Coding Agent 大部分需求都是：

修一个 Bug
解释一段代码
增加一个接口
修改一个函数
补几个测试

那么：

Agent Run
+
Checkpoint
+
Event Log
+
SSE

已经完全足够。

即使 Run 偶尔执行五分钟，也没有必要额外建立复杂的 LongTask Domain Model。

真正判断是否需要 LongTask 的标准不是：

任务运行超过多少分钟？

而是：

一次 Agent Run 还能不能完整表达这个用户目标？

如果一个目标已经开始包含：

多个 Agent Run
多个 Worker Task
并行 SubTask
等待外部事件
Human Approval
Step Dependency
部分失败恢复

那么这个目标已经明显高于 Run 层级。

此时 LongTask 才成为一个非常有价值的业务抽象。

---

十五、最终推荐的 Coding Agent 架构

对于复杂 Coding Agent，可以采用这样的层次：

Repository / Workspace
↓
Conversation
↓
User Request
↓
LongTask
↓
Stage
↓
Step
↓
┌─────────────────────────────┐
│ Agent Run                   │
│ Worker Task                 │
│ Subagent Run                │
│ Approval                    │
│ Waiting                     │
└─────────────────────────────┘
↓
Agent Runtime
↓
LLM / Tool / RAG / Memory / Skill

LongTask 周围再建立：

Persistence
Checkpoint Store
Event Log
Scheduler
Recovery Engine
Artifact Store
Trace / Metrics
SSE Gateway

最终形成：

             LongTask State
│
┌──────────┼──────────┐
↓          ↓          ↓
Persistence   Scheduler   Event Log
│          │          │
Checkpoint       Step       SSE
│          │          │
└──── Recovery ───────┘
│
Durable Execution

---

结语

普通 Agent Run 和 Agent LongTask 之间，并不存在一道绝对的技术分界线。

普通 Run 完全可以增加：

Persistence
Checkpoint
后台执行
Retry
SSE

而且对于大量 Agent 场景，这已经足够。

但随着任务复杂度不断提高，系统会逐渐出现：

多个 Run
多个 Step
并行 SubTask
外部 Waiting
Human-in-the-loop
复杂 Dependency
Step 级恢复

这时候真正需要升级的就不再是 Agent Loop，而是任务编排层。

于是：

Agent Run

从“整个任务”，变成：

LongTask 中的一个执行单元

而 LongTask 成为：

代表用户完整工程目标，并管理它从创建、执行、暂停、失败、恢复到最终完成的持久化业务执行对象。

如果用 Coding Agent 来概括：

“修一个 Bug”通常是一次 Agent Run。

而：

“完成一次大型代码库迁移”通常是一个 LongTask。

大型迁移任务里面可以包含很多普通 Run。

这也是理解两者最重要的一句话：

LongTask 不是更长的 Run，而是 Run 上层的 Durable Task Orchestration。

其中 Persistence 让状态能够保存，Checkpoint 建立恢复边界，Durable Execution 让任务能够跨故障继续，Human-in-the-loop 让任务能够安全暂停，Replay / Resume 让执行重新恢复，而 Streaming 则让用户持续看到整个长任务正在发生什么。

这些能力组合起来以后，Coding Agent 才真正从：

“会修改代码的 Agent”

逐渐走向：

“能够可靠完成完整软件工程任务的智能执行系统”

参考资料

LangGraph 官方将自身定位为 Agent orchestration runtime，并把 Durable Execution、Streaming、Human-in-the-loop 和 Persistence 作为核心能力。

LangGraph Persistence 文档详细说明了 Checkpointer、Checkpoint、Thread State，以及它们如何支持 fault tolerance、conversation continuity、human-in-the-loop 和 time travel。

LangGraph Interrupts 文档说明了 Agent 如何保存状态、无限期暂停，并在外部输入到达后 Resume，非常适合人工审批等长时等待场景。

OpenAI Agents SDK 的 Human-in-the-loop 文档说明 RunState 可以序列化保存到数据库或 Queue，并在之后重新恢复；SDK 也提供 Temporal、Dapr、Restate、DBOS 等 durable orchestration 集成，用于 long-running agents、process restart 和长时间等待场景。

Temporal 官方将 Workflow Execution 定义为 durable、reliable、scalable 的函数执行，并通过持久化 Event History 与 Replay 在 Worker 或基础设施故障后恢复工作流。