长任务 Agent 的暂停、恢复与续跑：工程实现全解
核心观点：长任务 Agent 的暂停/恢复/续跑，本质是将不可靠的执行过程变成可检查、可暂停、可重放的确定性链路。可靠性与可追溯性，是实现这一功能的两大支柱。
总览：三大核心机制
| 核心机制 |
解决什么问题 |
关键设计 |
最终目标 |
| 🗺️ 任务状态机 |
“任务现在在哪一步？” |
定义所有可能状态及转移规则 |
让任务状态可追踪 |
| 📌 检查点 |
“断点在哪里？” |
在关键节点保存执行信息 |
让任务可恢复 |
| 📷 上下文快照 |
“恢复时知道之前发生了什么吗？” |
存储完整任务上下文 |
让任务可重放 |
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
| ┌──────────────────────────────────────────────────────────────┐
│ 长任务 Agent 架构全景 │
├──────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────────────┐ │
│ │ 任务状态机 │ → │ 检查点 │ → │ 上下文快照 │ │
│ │ （骨架） │ │ （记忆） │ │ （完整上下文） │ │
│ └────┬─────┘ └────┬─────┘ └────────┬─────────┘ │
│ │ │ │ │
│ └────────────────┼────────────────────┘ │
│ ↓ │
│ ┌────────────────────────────────┐ │
│ │ 暂停 / 恢复 / 续跑 │ │
│ │ （控制层：可靠性保证） │ │
│ └───────────────┬────────────────┘ │
│ ↓ │
│ ┌───────────────────────────────┐ │
│ │ 幂等性 │ 上下文过期 │ 人工接管 │ │
│ └───────────────────────────────┘ │
│ │
└──────────────────────────────────────────────────────────────┘
|
一、任务状态机：定义执行状态
首先需要定义清晰的任务状态机，包括所有可能的状态，每个状态都要有明确的入口条件和出口条件。
状态转移图
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
| ┌──────────────────────────────────────┐
│ │
↓ │
┌──────────┐ 需要用户输入 ┌────────────┐ 超时/取消 ┌──────┐
│ 运行中 │ ─────────────→ │ 等待用户 │ ────────────→ │ 失败 │
│ RUNNING │ │ WAITING │ │FAILED│
└─────┬────┘ └─────┬──────┘ └──────┘
│ │
│ 用户主动暂停 │ 用户提供输入
↓ ↓
┌──────────┐ ┌──────────┐
│ 暂停 │ │ 恢复中 │
│ PAUSED │ ─────────────→ │RESUMING │
└─────┬────┘ 用户恢复 └─────┬────┘
│ │
│ 上下文过期 │ 上下文有效
│ ↓
│ ┌──────────┐
└───────────────────→ │ 运行中 │
重新规划 │ RUNNING │
└─────┬────┘
│ 任务完成
↓
┌──────────┐
│ 完成 │
│COMPLETED │
└──────────┘
|
状态详解表
| 状态 |
入口条件 |
出口条件 |
可转移至 |
🟢 运行中 RUNNING |
任务启动 / 恢复成功 |
需用户输入 / 被暂停 / 出错 / 完成 |
WAITING, PAUSED, FAILED, COMPLETED |
🟡 等待用户 WAITING |
Agent 需要用户输入 |
用户提供输入 / 超时 |
RESUMING, FAILED |
🔵 暂停 PAUSED |
用户主动暂停 / 系统暂停 |
用户恢复 / 上下文过期 |
RESUMING, FAILED |
🟣 恢复中 RESUMING |
从 PAUSED 恢复 |
校验完成 |
RUNNING（继续）/ RUNNING（重规划） |
🔴 失败 FAILED |
不可恢复错误 / 超时 |
用户重试 / 放弃 |
RUNNING（重试）/ 终态 |
✅ 完成 COMPLETED |
所有步骤成功执行 |
— |
终态 |
二、检查点：保存关键执行信息
在任务执行的关键步骤后，需要保存检查点（Checkpoint）。检查点是任务恢复的”存档点”。
检查点数据结构
1
2
3
4
5
6
7
8
9
10
11
12
| ┌──────────────────────────────────────────────────────────────┐
│ 📌 检查点（Checkpoint） │
├──────────────────────────────────────────────────────────────┤
│ │
│ 📋 当前计划（Plan） 当前正在执行的整体计划 │
│ 📥 输入（Input） 本步骤的输入数据 │
│ 📤 输出（Output） 本步骤的执行结果 │
│ 🔧 工具结果（Tool Results） 调用了哪些工具，返回了什么 │
│ 👉 执行指针（Next Step） 下一步应该执行什么 │
│ ⏰ 时间戳（Timestamp） 检查点保存的时间 │
│ │
└──────────────────────────────────────────────────────────────┘
|
检查点示例
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
| {
“checkpoint_id”: “ckpt_20260619_001”,
“task_id”: “task_research_001”,
“status”: “PAUSED”,
“current_plan”: “生成竞品分析报告”,
“completed_steps”: [
{“step”: 1, “name”: “收集竞品数据”, “result”: “saved_to_file://data.json”},
{“step”: 2, “name”: “数据清洗与分类”, “result”: “saved_to_file://clean.json”}
],
“next_step”: {
“step”: 3,
“name”: “生成分析报告”,
“input”: “file://clean.json”
},
“tool_results”: {
“web_search”: [“result_1”, “result_2”],
“file_write”: [“data.json”, “clean.json”]
},
“timestamp”: “2026-06-19T10:30:00Z”
}
|
检查点保存策略对比
| 策略 |
描述 |
优点 |
缺点 |
适用场景 |
| 📸 全量快照 |
每步保存完整状态 |
恢复简单，数据完整 |
存储开销大 |
短任务、状态小 |
| 📝 增量日志 |
只保存变化部分 |
存储高效 |
恢复需重放日志 |
长任务、状态大 |
| 🎯 混合模式 |
定期全量 + 步间增量 |
兼顾效率与恢复速度 |
实现复杂 |
生产级长任务 |
| 🤖 语义检查点 |
Agent 自主判断何时保存 |
灵活，只保存关键节点 |
依赖 Agent 判断力 |
智能体任务 |
三、上下文快照：存储完整上下文
除了聊天记录，还需要存储更广泛的上下文信息，使 Agent 在恢复时能”理解”之前发生了什么。
上下文快照五要素
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
| ┌──────────────────────────────────────────────────────────────┐
│ 📷 上下文快照（Context Snapshot） │
├──────────────────────────────────────────────────────────────┤
│ │
│ 🎯 目标（Goal） 任务要达成什么 │
│ └─ 例：生成一份 2026 年 AI Agent 市场竞品分析报告 │
│ │
│ ⛓️ 约束（Constraints） 有哪些限制条件 │
│ └─ 例：预算 10 万、只关注中国市场、用中文输出 │
│ │
│ 📊 证据（Evidence） 收集到了哪些数据/事实 │
│ └─ 例：10 家竞品数据、3 份行业报告、5 个用户访谈 │
│ │
│ 🧠 决策（Decisions） 做过哪些关键决定及原因 │
│ └─ 例：选择 A 策略而非 B，因为用户更看重成本 │
│ │
│ ⏳ 未完成动作（Pending） 还有哪些动作没做完 │
│ └─ 例：等待用户确认报告大纲、第 4 章未写 │
│ │
└──────────────────────────────────────────────────────────────┘
|
上下文快照示例
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| {
“task_id”: “task_research_001”,
“goal”: “生成 AI Agent 市场竞品分析报告”,
“constraints”: [“预算10万”, “中国市场”, “中文输出”],
“evidence_collected”: [
{“type”: “web_data”, “source”: “竞品A官网”, “saved_at”: “2026-06-18”},
{“type”: “report”, “source”: “艾瑞咨询2026”, “saved_at”: “2026-06-18”}
],
“decisions_made”: [
{“decision”: “使用直接抓取而非API”, “reason”: “数据时效性更好”},
{“decision”: “选择价格优先策略”, “reason”: “用户明确更关注成本”}
],
“pending_actions”: [
{“action”: “用户确认报告大纲”, “status”: “WAITING”},
{“action”: “完成第4章撰写”, “status”: “NOT_STARTED”}
],
“execution_pointer”: “step_3_generate_report”
}
|
四、暂停与恢复：处理任务中断
暂停与恢复是 Agent 系统最关键的两个操作，也是最容易出问题的地方。
暂停流程（4 步）
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
| ┌──────────────────────────────────────────────────────────────┐
│ ⏸️ 暂停流程 │
├──────────────────────────────────────────────────────────────┤
│ │
│ Step 1：停止接受新任务 │
│ └─ 不再接受新的工具调用请求 │
│ │
│ Step 2：处理进行中的动作 │
│ └─ 正在执行的动作 → 标记为”可恢复”或”待确认” │
│ └─ 等待中的动作 → 标记为”未执行” │
│ │
│ Step 3：保存状态 │
│ └─ 写入检查点（Checkpoint） │
│ └─ 写入上下文快照（Context Snapshot） │
│ │
│ Step 4：安全终止 │
│ └─ 释放资源，但不销毁状态 │
│ │
│ ⚠️ 核心原则：暂停 ≠ 杀死进程 │
│ ⚠️ 暂停 = 保存进度 + 安全停止 │
│ │
└──────────────────────────────────────────────────────────────┘
|
恢复流程（5 步）
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
| ┌──────────────────────────────────────────────────────────────┐
│ ▶️ 恢复流程 │
├──────────────────────────────────────────────────────────────┤
│ │
│ Step 1：读取检查点 │
│ └─ 加载最新的 Checkpoint 数据 │
│ │
│ Step 2：恢复上下文 │
│ └─ 加载 Context Snapshot，重建任务认知 │
│ │
│ Step 3：校验外部世界状态 ⚡ 关键步骤 │
│ └─ 文件是否被修改？ │
│ └─ 数据库记录是否变化？ │
│ └─ 相关 API 返回是否不同？ │
│ └─ 用户输入是否已改变？ │
│ │
│ Step 4：决策 │
│ └─ 校验通过 → 继续执行（续跑） │
│ └─ 校验失败 → 进入重规划 │
│ │
│ Step 5：通知用户 │
│ └─ 展示恢复状态 + 差异摘要（如有） │
│ │
└──────────────────────────────────────────────────────────────┘
|
暂停 vs 恢复对比表
| 维度 |
暂停（Pause） |
恢复（Resume） |
| 核心动作 |
保存状态 |
读取状态 + 校验 |
| 关键风险 |
状态丢失 |
上下文过期 |
| 必须做的事 |
写检查点 + 快照 |
校验外部世界状态 |
| 失败后果 |
任务进度丢失 |
执行错误操作 |
| 用户感知 |
“任务已暂停” |
“任务已恢复/需重新规划” |
五、续跑：保证结果一致
续跑（Rerun）是恢复后最关键的一环——如何保证再次执行的结果与第一次一致？
三大核心保障
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
| ┌──────────────────────────────────────────────────────────────┐
│ 🔄 续跑三大保障 │
├──────────────────────────────────────────────────────────────┤
│ │
│ 1️⃣ 幂等性（Idempotency） │
│ ┌────────────────────────────────────────────────────┐ │
│ │ 问题：恢复后重新执行，是否会重复操作？ │ │
│ │ 方案：幂等 Key + 执行记录 │ │
│ │ 适用范围：发邮件、写库、付款等有副作用的动作 │ │
│ │ │ │
│ │ 公式：同一操作 + 同一幂等Key = 相同结果 │ │
│ │ 例：付款操作(idempotency_key: “pay_order_123”) │ │
│ └────────────────────────────────────────────────────┘ │
│ │
│ 2️⃣ 上下文过期检测（Context Expiration） │
│ ┌────────────────────────────────────────────────────┐ │
│ │ 问题：暂停期间，外部数据是否已变？ │ │
│ │ 方案：恢复时对比检查点时的快照与当前状态 │ │
│ │ 处理：过期 → 停止执行 → 重新规划 → 用户确认 │ │
│ └────────────────────────────────────────────────────┘ │
│ │
│ 3️⃣ 人工接管（Human-in-the-loop） │
│ ┌────────────────────────────────────────────────────┐ │
│ │ 问题：任务卡住了，用户能做什么？ │ │
│ │ 方案：暴露进度、证据、下一步建议 │ │
│ │ 原则：任务执行不是黑盒，用户随时可见可干预 │ │
│ └────────────────────────────────────────────────────┘ │
│ │
└──────────────────────────────────────────────────────────────┘
|
幂等性实现方式
| 操作类型 |
幂等策略 |
示例 |
| 数据库写入 |
UPSERT（存在则更新，不存在则插入） |
INSERT ... ON CONFLICT UPDATE |
| 发送邮件 |
幂等 Key 去重 |
邮件头带 X-Idempotency-Key |
| 支付操作 |
唯一交易 ID |
payment_ref: task_001_step_3 |
| 文件写入 |
覆盖写（同内容幂等） |
写入同一文件路径 |
| API 调用 |
重试安全标记 |
请求头 X-Request-Id |
上下文过期处理决策树
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
| 恢复任务
│
↓
┌────────────────┐
│ 外部数据是否变化？│
└───────┬────────┘
│
┌───────┴───────┐
│ │
否 是
│ │
↓ ↓
继续执行 ┌──────────────┐
│ 变化是否影响 │
│ 后续执行？ │
└──────┬───────┘
│
┌───────┴───────┐
│ │
否 是
│ │
↓ ↓
继续执行 ┌────────────┐
│ 重新规划 │
│ 展示差异 │
│ 用户确认？ │
└─────┬──────┘
│
┌───────┴───────┐
│ │
确认 拒绝
│ │
↓ ↓
按新计划执行 终止任务
|
六、现实案例：正在发生的工程实践
案例一：AI 编程助手的长任务续跑（Claude Code / Cursor）
背景：用户使用 Claude Code 执行一个大型代码重构任务，涉及 50+ 文件的修改。任务中途用户关闭终端。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| 📋 任务：将项目中所有 REST API 迁移到 GraphQL
执行进度：
✅ Step 1-3：分析代码结构、生成 GraphQL Schema
✅ Step 4：重构用户模块（15个文件）
⏳ Step 5：重构订单模块（正在执行，修改了 8/20 个文件）
⬜ Step 6-8：支付模块、通知模块、集成测试
⏸️ 用户在 Step 5 中途关闭终端
恢复过程：
1. 读取检查点 → 知道正在修改订单模块的第 8 个文件
2. 校验外部状态 → 检查已修改的 8 个文件是否被其他操作改动
3. 检查 Git 状态 → 确认没有其他人的 push 冲突
4. 使用幂等 Key → 已写入的文件不重复修改
5. 从第 9 个文件继续 → 无缝续跑
|
关键技术点：
- 每个文件修改都有唯一操作 ID，保证幂等性
- Git commit 作为天然检查点
- 文件 hash 校验外部状态是否变化
案例二：LangGraph 中的对话状态持久化
背景：LangGraph 是目前最流行的 Agent 框架之一，原生支持 Checkpoint 机制实现暂停/恢复。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
| ┌──────────────────────────────────────────────────────────────┐
│ LangGraph Checkpoint 机制 │
├──────────────────────────────────────────────────────────────┤
│ │
│ Thread 1: 数据分析任务 │
│ ├── Checkpoint A: 用户输入 “分析销售数据” │
│ ├── Checkpoint B: Agent 调用 read_csv 工具 │
│ ├── Checkpoint C: Agent 生成图表 ← 此处暂停 │
│ ├── Checkpoint D: (等待恢复...) │
│ └── Checkpoint E: Agent 输出分析结论 │
│ │
│ 每个 Checkpoint 包含： │
│ • channel_values: 当前通道状态 │
│ • versions: 各通道版本号 │
│ • metadata: 来源、步骤数、时间戳 │
│ • parent_config: 父检查点配置（形成链表） │
│ │
│ 存储后端支持： │
│ • MemorySaver（内存，用于开发测试） │
│ • SqliteSaver / PostgresSaver（持久化，用于生产） │
│ │
└──────────────────────────────────────────────────────────────┘
|
| 特性 |
LangGraph 实现 |
通用设计 |
| 检查点存储 |
Channel-based 状态快照 |
可插拔存储后端 |
| 恢复策略 |
从最近 Checkpoint 重放 |
校验后继续或重规划 |
| 人工接管 |
interrupt_before / interrupt_after 配置 |
关键步骤前/后自动暂停 |
| 上下文管理 |
State Schema 定义 + 版本控制 |
类型化 + 版本化 |
案例三：AI 数据分析 Agent 的上下文过期处理
背景：某电商平台的数据分析 Agent 正在执行每日竞品监控任务，执行期间竞争对手突然降价。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
| 📋 任务：每日竞品价格监控与分析
⏰ 2026-06-18 22:00 开始执行
✅ 步骤1：抓取竞品A价格 → 均价 ¥299
✅ 步骤2：抓取竞品B价格 → 均价 ¥319
⏸️ 步骤3：暂停（等待人工确认异常数据）
⏰ 2026-06-19 09:00 恢复执行
📷 重新校验 → 发现竞品A凌晨降价至 ¥199！
┌─────────────────────────────────────────────────┐
│ ⚠️ 上下文过期检测 │
│ │
│ 检查点时：竞品A价格 = ¥299 │
│ 恢复时：竞品A价格 = ¥199（降幅 33%） │
│ │
│ → 上下文已过期！ │
│ → 原分析结论（”我方价格有竞争力”）可能失效 │
│ → 自动停止续跑，触发重新规划 │
│ → 通知用户：发现重大价格变化，建议重新分析 │
└─────────────────────────────────────────────────┘
|
案例四：不同框架的暂停/恢复方案对比
| Agent 框架 |
暂停机制 |
恢复机制 |
幂等性保障 |
人工接管 |
| LangGraph |
interrupt_before/after |
Checkpoint 重放 |
State 版本控制 |
内置 human-in-the-loop |
| OpenAI Assistants |
requires_action 状态 |
submit_tool_outputs |
Run ID 去重 |
工具确认机制 |
| AutoGen |
对话历史持久化 |
历史重放 + 继续 |
消息 ID 去重 |
用户代理模式 |
| CrewAI |
任务状态枚举 |
状态恢复 |
回调函数控制 |
流程控制器 |
| 自研 Agent |
自建状态机 |
自建 Checkpoint |
自建幂等层 |
自建 UI |
七、高级思考问答：全文总结
Q1：为什么长任务 Agent 必须设计检查点？没有检查点会怎样？
A：没有检查点，就像写论文不保存——一次意外就回到原点。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
| ┌──────────────────────────────────────────────────────────────┐
│ │
│ 没有检查点： │
│ ┌────────────────────────────────────────┐ │
│ │ 开始 ──────────────────── 中断 ──→ 💥 全部丢失 │
│ │ （2小时的工作白费） 必须从头开始 │
│ └────────────────────────────────────────┘ │
│ │
│ 有检查点： │
│ ┌────────────────────────────────────────┐ │
│ │ 开始 ──📌──📌──📌── 中断 ──→ 📌 从最近检查点恢复 │
│ │ cp1 cp2 cp3 cp3 最多丢失1步进度 │
│ └────────────────────────────────────────┘ │
│ │
│ 更深层的价值： │
│ • 可观测性：用户随时知道任务在哪一步 │
│ • 可追溯性：出问题时可以回溯到任意检查点 │
│ • 可调试性：开发者可以”时光倒流”排查问题 │
│ │
└──────────────────────────────────────────────────────────────┘
|
| 维度 |
没有检查点 |
有检查点 |
| 中断恢复 |
从头开始 |
从最近检查点恢复 |
| 进度可见 |
黑盒 |
白盒 |
| 错误排查 |
无法定位 |
可回溯到问题步骤 |
| 用户体验 |
不可接受的等待 |
可暂停可恢复 |
| 系统可靠性 |
单点故障 |
容错恢复 |
Q2：检查点应该保存多频繁？如何平衡性能与可靠性？
A：这是一个工程权衡问题，没有标准答案——但有最佳策略。
| 策略 |
检查点频率 |
可靠性 |
性能开销 |
适用场景 |
| 每步保存 |
100% |
🟢 最高 |
🔴 高 |
关键任务（金融、医疗） |
| 关键节点保存 |
60-80% |
🟡 中等 |
🟢 低 |
一般分析任务 |
| 语义保存（Agent 自主判断） |
动态 |
🟢 较高 |
🟡 中等 |
智能体任务 |
| 混合策略（定期全量 + 增量） |
灵活 |
🟢 高 |
🟢 较低 |
生产级系统 |
最佳实践：
- 副作用操作前必存——发邮件、写库、付款之前必须保存检查点
- Agent 自主标记——让 LLM 判断”这一步很重要，我应该保存”
- 增量保存——只存变化部分，而非完整状态
- 异步写入——检查点保存不阻塞主任务执行
Q3：如何保证”续跑”的结果与第一次一致？幂等性的终极挑战是什么？
A：幂等性的本质问题是——你无法区分”第一次执行”和”第一次成功恢复后的重试”。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
| ┌──────────────────────────────────────────────────────────────┐
│ 幂等性的三个层次 │
├──────────────────────────────────────────────────────────────┤
│ │
│ Level 1：操作幂等 │
│ └─ 同一操作执行多次，结果相同 │
│ └─ 例：设置温度为 25°C（设置 10 次还是 25°C） │
│ │
│ Level 2：任务幂等 │
│ └─ 同一任务重新跑一遍，最终产出相同 │
│ └─ 例：生成报告（内容基于相同输入数据） │
│ │
│ Level 3：系统幂等 ← 终极挑战 │
│ └─ 即使外部世界变化，任务也能正确完成 │
│ └─ 例：付款任务中途汇率变了，系统能感知并处理 │
│ │
│ 终极挑战： │
│ ┌──────────────────────────────────────────────┐ │
│ │ • 副作用操作的幂等性（付款、发消息） │ │
│ │ • 时序依赖（操作 A 的结果影响操作 B） │ │
│ │ • 外部系统不一致（部分成功、部分失败） │ │
│ │ • 并发问题（两个恢复请求同时到达） │ │
│ └──────────────────────────────────────────────┘ │
│ │
└──────────────────────────────────────────────────────────────┘
|
| 难点 |
问题 |
解决方案 |
| 副作用操作 |
发邮件后恢复，是否重发？ |
幂等 Key + 执行记录 |
| 时序依赖 |
Step B 依赖 Step A 的结果，但 Step A 结果可能变了 |
依赖图 + 级联失效检测 |
| 外部不一致 |
写了数据库但缓存没更新 |
分布式事务 / Saga 模式 |
| 并发恢复 |
两个进程同时恢复同一任务 |
分布式锁 / 单实例保证 |
Q4：什么时候应该让 Agent 自动续跑？什么时候必须等人工确认？
A：这本质上是一个”自主权边界”问题——Agent 的权力应该有多大？
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
| ┌──────────────────────────────────────────────────────────────┐
│ 自主权决策矩阵 │
├──────────────────────────────────────────────────────────────┤
│ │
│ 低风险 高风险 │
│ ┌─────────────────┬─────────────────┐ │
│ 可逆 │ ✅ 自动续跑 │ 🟡 自动+记录 │ │
│ │ （读文件、查询） │ （写文件、更新） │ │
│ ├─────────────────┼─────────────────┤ │
│ 不可逆 │ 🟡 自动+通知 │ 🔴 必须人工确认 │ │
│ │ （内部计算） │ （付款、删除、 │ │
│ │ │ 发送、发布） │ │
│ └─────────────────┴─────────────────┘ │
│ │
│ 额外规则： │
│ • 上下文过期 → 无论如何都必须人工确认 │
│ • 任务已执行超过 N 步 → 阶段性人工确认 │
│ • 成本超过阈值 → 暂停等待预算确认 │
│ │
└──────────────────────────────────────────────────────────────┘
|
| 操作类别 |
示例 |
策略 |
理由 |
| 只读操作 |
读文件、查询数据库 |
自动续跑 |
无副作用，零风险 |
| 可逆写入 |
创建文件、更新记录 |
自动 + 日志 |
可回滚 |
| 不可逆操作 |
发邮件、付款、删除 |
必须人工确认 |
无法撤回 |
| 上下文过期 |
数据已变、需求已变 |
重新规划 + 确认 |
盲目续跑可能产生错误结果 |
Q5：人工接管的”最佳界面”应该长什么样？
A：用户不需要看到 Agent 的每一行日志——他们需要看到”决策点”和”证据”。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
| ┌──────────────────────────────────────────────────────────────┐
│ 🖥️ Agent 任务控制台（理想设计） │
├──────────────────────────────────────────────────────────────┤
│ │
│ 📊 任务健康度：🟢 正常 / 🟡 需关注 / 🔴 需干预 │
│ │
│ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 75% │
│ ✅ Step 1-6 完成 ⏳ Step 7 执行中 ⬜ Step 8-10 待执行 │
│ │
│ ──── 当前步骤 ──── │
│ 📝 “正在生成第 3 章分析报告” │
│ 📊 已完成：数据收集 → 清洗 → 统计 → ⏳ 撰写报告 │
│ │
│ ──── 需要你的决定 ──── ⚠️ │
│ ❓ “竞品A刚降价33%，是否调整分析策略？” │
│ [查看证据] [继续原计划] [重新规划] [暂停任务] │
│ │
│ ──── 已完成决策记录 ──── │
│ ✅ 决策1：选择直接抓取（你确认于 10:15） │
│ ✅ 决策2：纳入竞品C（你确认于 10:20） │
│ │
│ ──── 预计剩余 ──── │
│ ⏰ 约 15 分钟 ｜ 💰 已消耗预算 40% │
│ │
└──────────────────────────────────────────────────────────────┘
|
设计原则：
| 原则 |
描述 |
反模式 |
| 分层展示 |
概要 → 详情 → 原始日志 |
一次性展示所有信息 |
| 决策优先 |
突出需要用户决定的事项 |
淹没在技术细节中 |
| 证据驱动 |
每个建议附带证据和推理 |
只给结论不给理由 |
| 进度可视化 |
完成度 + 里程碑 + 预估 |
只显示”运行中” |
| 可干预性 |
随时暂停/修改/终止 |
启动后无法干预 |
Q6：长任务 Agent 的”终极架构”是什么？
A：将所有机制统一为一个模型——Agent 就是一个”可暂停的计算”，本质上是人类工作流的数字化。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
| ┌──────────────────────────────────────────────────────────────┐
│ 长任务 Agent 终极架构 │
├──────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ Layer 5: 人机交互层（Human-Agent Interface） │ │
│ │ └─ 进度可视化 · 决策请求 · 人工接管 │ │
│ ├──────────────────────────────────────────────────────┤ │
│ │ Layer 4: 安全与治理层（Safety & Governance） │ │
│ │ └─ 幂等性 · 权限控制 · 成本控制 · 审计日志 │ │
│ ├──────────────────────────────────────────────────────┤ │
│ │ Layer 3: 恢复策略层（Recovery Strategy） │ │
│ │ └─ 上下文过期检测 · 重规划引擎 · 级联回滚 │ │
│ ├──────────────────────────────────────────────────────┤ │
│ │ Layer 2: 状态管理层（State Management） │ │
│ │ └─ 检查点 · 上下文快照 · 版本控制 │ │
│ ├──────────────────────────────────────────────────────┤ │
│ │ Layer 1: 执行引擎层（Execution Engine） │ │
│ │ └─ 任务状态机 · 工具调用 · 结果收集 │ │
│ └──────────────────────────────────────────────────────┘ │
│ │
│ 核心洞察： │
│ ┌────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ 状态机 = 骨架（定义可能的状态） │ │
│ │ 检查点 = 记忆（记住执行到哪里） │ │
│ │ 快照 = 理解（记住为什么这么做） │ │
│ │ 恢复 = 智慧（判断能否继续） │ │
│ │ 幂等 = 纪律（防止重复犯错） │ │
│ │ 人工 = 兜底（最后一道防线） │ │
│ │ │ │
│ │ → 六者合一 = 可靠的可恢复 Agent 系统 │ │
│ │ │ │
│ └────────────────────────────────────────────────────┘ │
│ │
└──────────────────────────────────────────────────────────────┘
|
全文逻辑总图
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
| ┌─────────────────────────────────────────────────────────────────────┐
│ 长任务 Agent 暂停/恢复/续跑 全景 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ 问题是什么？ │
│ └─ 长任务中断 → 状态丢失 / 重复执行 / 黑盒等待 │
│ │
│ 如何定义状态？ │
│ └─ 任务状态机 → 6种状态 + 明确转移规则 │
│ │
│ 如何保存进度？ │
│ ├─ 检查点 → 执行指针 + 工具结果 + 计划 │
│ └─ 上下文快照 → 目标 + 约束 + 证据 + 决策 + 未完成动作 │
│ │
│ 如何处理中断？ │
│ ├─ 暂停 → 停止新调用 + 标记进行中 + 保存状态 │
│ └─ 恢复 → 读取检查点 + 校验外部状态 + 决策（继续 or 重规划） │
│ │
│ 如何保证一致？ │
│ ├─ 幂等性 → 幂等 Key + 执行记录（防止重复） │
│ ├─ 上下文过期 → 快照对比（防止过期执行） │
│ └─ 人工接管 → 进度可见 + 决策可干预（防止黑盒） │
│ │
│ 工程启示？ │
│ └─ 可靠性 = 状态机 + 检查点 + 快照 │
│ └─ 安全性 = 幂等 + 过期检测 + 人工兜底 │
│ └─ 可追溯 = 完整执行日志 + 决策记录 │
│ │
└─────────────────────────────────────────────────────────────────────┘
|
| 核心概念 |
一句话总结 |
关键设计 |
失败后果 |
| 任务状态机 |
定义任务”在哪里” |
6 种状态 + 转移规则 |
状态混乱，无法追踪 |
| 检查点 |
保存”做了什么” |
计划 + 输入 + 输出 + 指针 |
中断后无法恢复 |
| 上下文快照 |
保存”为什么这么做” |
目标 + 约束 + 证据 + 决策 |
恢复后不理解上下文 |
| 暂停 |
优雅地”停下来” |
停止调用 + 标记 + 保存 |
状态丢失/不一致 |
| 恢复 |
安全地”继续走” |
读取 + 校验 + 决策 |
基于过期信息执行 |
| 幂等性 |
防止”重复做” |
幂等 Key + 执行记录 |
重复付款/发邮件 |
| 上下文过期 |
发现”世界变了” |
快照对比 + 重新规划 |
错误决策 |
| 人工接管 |
让人”看得见” |
进度 + 证据 + 建议 |
黑盒运行，失去信任 |
