【AI Agent通识九课】05 · AI 的红绿灯 — 长任务怎么管

AI Agent 通识课 · 第 5 篇 / 共 9 篇

一句话记住：长任务要能暂停、让控、恢复。

---

上周我让 Claude Code 跑一个任务：

"把整个项目的依赖升级到最新版本，跑通所有测试"

它开始动手------查 package.json、解析依赖、更新版本、装包、跑测试。

20 分钟过去了，还在跑。

我中途想看看日志、插一句"先别升级 React"，却发现我根本插不进去。

界面卡死在"AI 执行中..."。

---

这就是今天要聊的------AI 干长任务时，谁来掌方向盘？

短任务不是问题（30 秒搞定，等就等了）。

长任务（半小时起步）就需要精密设计了。

这是区分"玩具 Agent"和"生产级 Agent"的分水岭。

---

01 · 为什么长任务这么难？

短任务和长任务的区别，不只是时长。

短任务（秒级）：

• 用户等得起
• 状态简单（要么成要么败）
• 中途没必要打断
• 出错重来就行

长任务（分钟到小时级）：

• 用户不会全程盯着
• 状态复杂（已做什么、还剩什么、中间结果是啥）
• 中途一定会想打断（看日志、改方向、加指令）
• 出错不能从头来（损失惨重）

核心矛盾：

AI 在"认真干活"，用户想"瞄一眼 / 插一句"，怎么优雅地共驾方向盘？

---

02 · 生活中的参照：代驾开到一半

你叫了代驾，上高速了。

开了 20 分钟，你突然想：

• "停一下，我要上厕所" → 暂停
• "往这个出口下吧" → 改方向
• "算了你先开，我眯一会儿" → 继续让他开

一个合格的代驾怎么处理？

✅ 你一喊停，立刻靠边

✅ 你给新指令，平滑调整

✅ 你想继续让他开，无缝接管

一个糟糕的代驾呢？

❌ 锁了方向盘不让你干预

❌ 你喊了他也不听

❌ 硬改方向直接出车祸

---

AI 做长任务，就是代驾在开车。

方向盘的交接机制，决定了 Agent 能不能做真事。

---

03 · 如果让你来做，你会怎么设计？

场景：AI 在帮你"升级全项目依赖"。

半小时的任务。

你想在任何时刻：

1. 看它现在干到哪了
2. 让它先停一下
3. 插一句新指令
4. 让它继续

你会怎么设计？

朴素方案 A：同步阻塞

用户：升级依赖
AI：  [执行中，界面锁死 20 分钟]
AI：  [完成]

问题：用户完全失控。

像坐在锁车门的代驾车上。

---

朴素方案 B：纯异步 + 轮询

用户：升级依赖 → 返回 task_id
用户：(不时)查进度(task_id) → 返回 "跑到第 5 步"

问题 ：能看进度但没法插话。

你只能"看它跑"，不能"干预它跑"。

---

正确方向：状态机 + 双向通信

任务有明确状态：
  Running → Paused → Resumed → Success
                 ↘ Cancelled

用户随时可以：
  - 读取当前状态（看日志、看中间结果）
  - 发指令改变状态（暂停、继续、取消、追加指令）

这就是AI 长任务的"红绿灯"模型。

---

04 · 四种主流长任务模式

模式 A：同步等待（ChatGPT 路线）

做法：用户发指令，等到 AI 完成再返回。

谁在用：ChatGPT 基础对话、多数简单 ChatBot

优点：

• ✅ 实现简单
• ✅ 结果明确

缺点：

• ❌ 任务长了就卡死
• ❌ 用户完全失控
• ❌ 不适合 Agent 场景

适合 ：秒级任务（问答、翻译、生成短文）

---

模式 B：回调流（LangChain 路线）

做法：用户提供一个回调函数，AI 每走一步调一次回调，用户在回调里决定做什么。

def on_step(step, state):
    print(f"当前步骤：{step}")
    if user_wants_to_stop():
        return "STOP"
    return "CONTINUE"

agent.run(task, callback=on_step)

谁在用：LangChain Agent Executor、多数开发框架

优点：

• ✅ 能干预
• ✅ 灵活

缺点：

• ❌ 开发者要自己实现所有细节
• ❌ 回调地狱
• ❌ 用户看不到中间状态的 UI

适合 ：开发框架、自定义 Agent

---

模式 C：Hook 插桩（Claude Code 路线）

做法：在 AI 执行流程的关键节点（执行前、执行后、错误时）插 Hook，用户可以在 Hook 里加逻辑。

hooks:
  pre_tool_use:
    - script: "check_safety.sh"
  post_tool_use:
    - script: "log_action.sh"
  on_error:
    - script: "notify_slack.sh"

谁在用：Claude Code（最典型）、部分企业级 Agent

优点：

• ✅ 灵活拦截
• ✅ 不改 AI 本身逻辑
• ✅ 适合企业定制

缺点：

• ❌ 能拦但不能"接管方向盘"（只能被动拦截）
• ❌ 用户无法真正和 AI 共驾

适合 ：需要定制化的企业场景

---

模式 D：状态机 + 快照（Warp 路线）

做法：任务是一个状态机，每一步都保存快照（snapshot）。用户可随时暂停、恢复、分叉、回滚。

// Warp 的状态机（简化）
enum ConversationStatus {
    InProgress,   // 跑着呢
    Success,      // 跑完了
    Error,        // 出错了
    Cancelled,    // 被取消
    Blocked,      // 等用户响应
}

// 每步都有快照
struct Snapshot {
    step_id: u32,
    state: State,
    tool_calls: Vec<ToolCall>,
    results: Vec<Result>,
    timestamp: DateTime,
}

谁在用：Warp、部分新生代 Agent 产品

优点：

• ✅ 真·双向通信：用户和 AI 共驾
• ✅ 可暂停、可恢复、可分叉
• ✅ 出错不用从头来（回滚到快照）
• ✅ 用户体验最好

缺点：

• ❌ 实现复杂
• ❌ 存储成本高（要存快照）

适合 ：严肃使用的生产级 Agent

---

速查表

模式	生活类比	代表产品	用户能干预	实现难度
同步等待	锁车门的代驾	ChatGPT	🔴 不能	🟢 简单
回调流	每 5 分钟跟司机喊一嗓子	LangChain	🟡 能但被动	🟡 中
Hook 插桩	在关键路口设检查站	Claude Code	🟡 能拦不能抢	🟡 中
状态机+快照	和司机轮流开	Warp	🟢 完全可以	🔴 高

---

05 · 状态机的精妙之处

为什么状态机是长任务的最优解？

因为它把一个模糊的"AI 在执行"变成了明确的状态。

5 个核心状态

      ┌───────────────┐
      │   InProgress  │ ← AI 跑着呢
      └───┬───────┬───┘
          │       │
   完成   │       │  出错
          ▼       ▼
    ┌─────────┐  ┌──────────┐
    │ Success │  │  Error   │
    └─────────┘  └──────────┘
          ▲
          │
      ┌───┴───────────┐
      │   Cancelled   │ ← 用户取消
      │    Blocked    │ ← 等用户响应
      └───────────────┘

每个状态都有明确含义：

• InProgress：AI 在干，用户可以看、可以打断
• Success：完美收工
• Error：出错，状态明确可回溯
• Cancelled：用户主动取消
• Blocked：AI 停下来等用户（如"要不要删这个文件？"）

状态转换是受控的------不是 AI 想跳就跳，必须走预定路径。

配合快照的威力

每个状态下都有快照：

Snapshot 1: [Round 1] 查了 package.json
Snapshot 2: [Round 2] 解析出 47 个依赖
Snapshot 3: [Round 3] 升级了 12 个
Snapshot 4: [Round 4] 跑测试，3 个失败  ← 卡在这

用户可以说：

• "回到 Snapshot 2 重新升级，排除 React" → 从快照恢复
• "分叉一个新线程试试别的方案" → 基于快照开新分支
• "看看 Snapshot 3 当时的状态" → 时光倒流

这是"真·双向通信"------用户成为 AI 的共驾。

---

06 · 手把手：一次长任务的完整流程

场景：你对 AI 说"帮我整个项目升级依赖并跑测试"。

预计 20 分钟。

┌─────────────────────────────────────────────────────────┐
│ 用户：升级所有依赖并跑测试                              │
└────────────────┬────────────────────────────────────────┘
                 │
                 ▼  [InProgress 开始]
         ╔═══════════════════╗
         ║   Snapshot 1       ║
         ║ 读 package.json    ║  ← 2 分钟
         ╚═════════╦═════════╝
                   │
                   ▼
         ╔═══════════════════╗
         ║   Snapshot 2       ║
         ║ 升级到最新版       ║  ← 5 分钟
         ╚═════════╦═════════╝
                   │
                   ▼
         ╔═══════════════════╗
         ║   Snapshot 3       ║
         ║ npm install        ║  ← 3 分钟
         ╚═════════╦═════════╝
                   │
                   ▼
  ┌────────────────────────────────────────┐
  │ 用户插话："先别升级 React，有兼容问题" │
  │ [状态：InProgress → Blocked]           │
  └────────────────┬───────────────────────┘
                   │
                   ▼
         ╔═══════════════════╗
         ║ AI 响应：          ║
         ║ 回到 Snapshot 2    ║  ← 回滚到升级前
         ║ 分叉新分支         ║  ← 基于快照开新线
         ║ 排除 React 重新升级║
         ╚═════════╦═════════╝
                   │
                   ▼
  [状态：Blocked → InProgress]
                   │
                   ▼
         ╔═══════════════════╗
         ║   Snapshot 2.1     ║
         ║ 排除 React 后的升级║
         ╚═════════╦═════════╝
                   │
                   ▼
         ╔═══════════════════╗
         ║   Snapshot 4       ║
         ║ 跑测试：全通过     ║
         ╚═════════╦═════════╝
                   │
                   ▼  [状态：InProgress → Success]
       ┌──────────────────────────┐
       │ AI：完成。已排除 React， │
       │    其他 46 个依赖升级，  │
       │    测试全过。            │
       └──────────────────────────┘

关键观察：

1. 每步都有快照：卡住了可以回到任意一步
2. 用户能随时插话：状态切到 Blocked，AI 停下来响应
3. 分叉机制：不破坏原流程，开新分支试新方案
4. 恢复机制：用户处理完，继续跑

这就是"共驾"------不是 AI 说了算，也不是用户事事过问，而是两者流畅交接。

---

07 · 我踩过的坑

做过两个长任务 Agent 项目，总结几条书上不讲的：

坑 1：不存快照 = 重来的痛

第一版我没做快照系统，觉得"反正 AI 能自己恢复"。

结果 AI 在第 18 步挂了，它完全不记得前面干了啥。

20 分钟的工作全废。

用户看完直接卸载。

教训 ：快照不是 feature，是 Must-Have。

哪怕只存每 N 步一个，也比什么都没有强。

---

坑 2：Blocked 状态必须超时

早期我做的 Blocked 状态没超时机制。

用户打开 Agent 让它跑个任务，然后去开会。

3 小时后回来------AI 在一个小弹窗上等了 3 小时没动。

现在的设计：Blocked 超过 5 分钟自动保存快照 + 切到 Paused，用户回来点一下"继续"就恢复。

---

坑 3：日志要用户能看懂

技术上存了全部状态，但界面上只给用户看"Running... 12%"。

用户看不到 AI 到底在干啥，心里没底。

改进 ：状态页要有人话级的日志：

❌ 差的日志：
  Running... 12%

✅ 好的日志：
  ✓ 读取 package.json（47 个依赖）
  ✓ 升级 lodash 4.17.20 → 4.17.21
  ✓ 升级 axios 0.27.0 → 1.5.0
  ⟳ 正在升级 react 18.2.0 → 18.3.0

用户看到就知道现在安全、能不能干预、要不要等。

---

08 · 你的场景该怎么选？

场景 1：聊天机器人（秒级任务）

推荐 ：同步等待

理由：问答、翻译都是秒级，没必要上复杂机制。

---

场景 2：编程助手（分钟级任务）

推荐 ：Hook 插桩 + 部分状态机

理由：Claude Code 这种场景，主要是拦截危险操作 + 可中断。

---

场景 3：自动化运维（小时级任务）

推荐 ：完整状态机 + 快照

理由：任务长、不能从头来、必须支持共驾。

---

场景 4：企业流程自动化

推荐 ：状态机 + 审计日志 + Hook

理由：合规第一，每步都要可审计、可回溯。

---

09 · 你能带走什么

读完这篇，你应该能回答的 3 个问题

✅ 长任务的核心是"共驾"：AI 和用户流畅交接方向盘

✅ 四种主流模式：

• 同步等待 → 秒级任务
• 回调流 → 开发框架
• Hook 插桩 → 企业定制
• 状态机+快照 → 生产级 Agent

✅ 状态机 5 态：InProgress / Success / Error / Cancelled / Blocked

下次评估 Agent 产品时，问 5 个问题

1. 它最长能跑多久的任务？
2. 中途能暂停吗？能看进度吗？
3. 出错能回滚吗？还是要从头来？
4. 用户能不能插话改变方向？
5. 任务状态有没有明确的展示？

产品经理设计长任务 AI 功能时

• 先画状态机：列清楚所有状态和转换
• 每步存快照：不管多轻量
• Blocked 要超时：不要让 AI 傻等
• 日志给人话：不只是百分比
• 允许分叉：用户可能想试几种方案

开发者自己搭 Agent 时

• 起步用 LangChain 回调流 够用
• 进阶加快照存储（Redis / SQLite 都行）
• 生产级做完整状态机
• 长任务都要支持中断（Ctrl+C 或界面按钮）

---

10 · 下一篇预告

06 · AI 的省电模式 --- 怎么懂你的代码库

项目 1 万个文件，AI 每次都重扫吗？

Word 改一个字不会重载全文------AI 也该这样。

对比 ChatGPT 不懂 / Cursor 向量索引 / Claude Code 按需读 / Warp Merkle Tree，

告诉你"改动在哪，重算到哪"怎么做。

---

一句话记忆锚点

🎯 长任务要能暂停、让控、恢复。像代驾开高速------你喊停就停、你改路线就改、你想睡一会儿他继续开。

---

路易乔布斯 © 2026 | AI Agent 通识课 · 第 5 篇 / 共 9 篇