AI Agent 長任務中斷後怎麼恢復：檢查點、上下文重建與接續流程

AI Agent 跑長任務時，真正麻煩的通常不是中斷本身，而是中斷之後的那一刻：終端沒了、上下文重置了、模型只記得一半計畫，你也不確定哪些檔案已經被改過。

實用的解法不是祈禱 Agent 永遠不要出錯，而是從一開始就把任務設計成可以恢復。

這篇文章只回答一個很具體的問題：AI Agent 長任務中斷後，怎麼接續而不是從頭再來？

Quick Answer

要讓 AI Agent 長任務可恢復，整個過程中至少要保留三樣東西：任務目標、檢查點清單、目前工作區狀態。中斷後先檢查 git status、已修改檔案、日誌與產物，再根據最新檢查點重建上下文，最後只讓 Agent 繼續未完成項。

一句話：不要讓 Agent 只依賴聊天記憶，要讓倉庫和檢查點記錄成為記憶。

為什麼長任務容易斷

長時間執行的 Agent 任務常見中斷原因包括：

模型上下文太長；
命令逾時或終端會話消失；
使用者開了新對話但沒有帶足背景；
Agent 忘了自己已經改過哪些檔案；
生成檔案和原始檔案混在一起；
測試跑到一半失敗，下一步不清楚。

任務越涉及寫內容、改程式、跑測試、生成翻譯或跨多個目錄，這個風險就越高。

例如你用 Codex Skills 自訂工作流之後，可能會讓 Agent 連續處理很多文章。如果中途停止，你需要清楚知道哪些文章完成了，哪些還沒完成。

最小恢復結構

一個可恢復的 Agent 任務，需要一個小而明確的結構。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


Goal:
- 最終要完成什麼？

Scope:
- 哪些目錄或檔案允許修改？

Progress:
- Done
- In progress
- Pending

Verification:
- 用哪些命令或檢查證明任務可用？

Recovery note:
- 如果中斷，下一個 Agent 應該從哪裡繼續？

它不必是一份很長的專案文件。聊天裡的一個簡短清單、臨時 Markdown 檔案，或任務專用的 SKILL.md 都可以。

關鍵是：狀態必須能在模型記憶之外被重建。

第一步：先檢查工作區

中斷後，不要馬上說「繼續」。先檢查倉庫。

常用命令：

1
2
3


git status --short
git diff --stat
git diff -- path/to/file

如果是內容生成任務，也要列出目標目錄：

1

ls content/post/2026/07/38

如果是程式任務，還要查看最近的測試輸出、建置產物，以及中斷前 Agent 提到過的檔案。

這一步的目標很簡單：把已完成工作和半成品分開。

第二步：重建精簡上下文

開新 Agent 會話時，不要把整段舊對話全部貼回去。更好的做法是給一段精簡的恢復提示詞。

範例：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


Continue the interrupted task.

Goal:
- Translate posts 36, 37, and 38 into en, zh-tw, ja, and es.

Already completed:
- 36: all target files created.
- 37: all target files created.

Still pending:
- 38: create index.en.md, index.zh-tw.md, index.ja.md, index.es.md.

Rules:
- Preserve source date and slug.
- Skip existing target files.
- Do not commit.

Verification:
- Check target files exist.
- Check date/slug match source.
- Check front matter and code fences are valid.

這類提示詞能讓 Agent 不必重新理解整個任務，也能接著做正確的部分。

第三步：從下一個小單元繼續

除非必要，不要重跑整個長任務。應該從下一個小單元恢復。

合適的小單元包括：

一篇文章；
一種翻譯語言；
一個測試檔案；
一個模組；
一批生成資產；
一條命令加它的驗證。

對 AI 編程任務尤其如此。如果你也像 Claude Code hooks 自動跑測試那樣配置了自動測試，恢復單元越小，測試失敗時越容易定位到具體檔案或行為。

第四步：先驗證，再擴大範圍

最安全的恢復模式是：

1

Inspect current state, finish only the pending part, then verify before doing anything else.

內容任務的驗證可以包括：

檔案是否存在；
front matter 欄位；
slug/date 是否一致；
站內連結語法；
Markdown 程式碼區塊；
是否有明顯編碼破損。

程式任務的驗證可以包括：

定向單元測試；
型別檢查；
lint；
小範圍建置；
git diff 審查。

Agent 不應把「檔案存在」等同於「任務完成」。

開始長任務前要保存什麼

長任務開始前，最好保存：

精確目標；
允許修改的路徑；
禁止修改的路徑；
批次順序；
驗證命令；
回滾或恢復規則。

例如：

1
2
3
4
5


Process posts 36, 37, 38 in that order.
Only create missing target language files.
Do not edit existing translated files.
After each post, verify date and slug.
If interrupted, continue from the first post with missing targets.

這一小段文字，往往能省下很多後續清理時間。

上下文太長時怎麼辦

長任務常常因為 prompt 變得太大而出問題。解法是主動壓縮上下文。

保留：

當前目標；
已修改檔案清單；
已做決策；
待辦項；
驗證結果。

丟掉：

重複討論；
已知修復後的舊失敗嘗試；
冗長命令輸出；
無關檔案內容；
沒有採用的猜測性計畫。

如果是 token 使用量本身出問題，除錯時也適用同一個原則：只保留下一步必需的事實。相關症狀可以參考 Claude Code token 暴增排查。

什麼時候做成 Skill 或工作流

如果同一套恢復模式反覆出現，就值得把它寫成工作流。

可複用工作流可以定義：

如何發現來源檔案；
如何判斷哪些已完成；
什麼必須跳過；
如何保留 metadata；
如何驗證結果；
最後回報要包含什麼。

這也是本地 skill 有用的地方。與其每次寫一大段提示詞，不如把恢復規則寫好，之後直接重用。

跨工具接力也是同理。如果 Codex 開始任務，Claude Code 接手完成，或反過來，都需要明確檢查點。這個方向可以參考 Codex 和 Claude Code 任務接力教程。

可直接複用的恢復提示詞

可以直接用這個模板：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


This is a resumed AI Agent task.

Objective:
- ...

Source of truth:
- Repository files and git status are more reliable than prior chat memory.

Allowed changes:
- ...

Already done:
- ...

Pending:
- ...

Rules:
- ...

Verification:
- ...

Please inspect the current workspace first, continue only the pending items, and report exactly what changed.

最重要的是 source-of-truth 那一句。它能避免 Agent 在工作區已經改變時，還自信地沿用過期記憶。

常見錯誤

恢復長任務時最常見的錯誤有：

只說「繼續」，沒有提供狀態；
讓 Agent 把所有內容重做一遍；
不看 git status；
把生成檔案和原始碼修改混在一起；
覺得「看起來完成」就跳過驗證；
恢復上下文時讓 Agent 順手改了無關檔案。

恢復不是單純接著做，而是先把任務縮小到可以安全接續的程度。

小結

AI Agent 長任務中斷，不等於任務失敗。只有在沒有外部狀態可以恢復時，它才會真正變成失敗。

做長任務時，保留目標、檢查點清單和驗證規則。中斷後先檢查工作區，再重建精簡上下文，從下一個小單元繼續，完成後立刻驗證。

一旦形成這個習慣，長任務就不再那麼脆弱。Agent 可能會忘，終端可能會關，對話可能會重開，但任務仍然有跡可循。