前幾天開始把不同種類的 Context 拆開。

AGENTS.md
→ 怎麼工作

PROJECT_STATE.md
→ 現在在哪

DECISIONS.md
→ 為什麼走到這

做到這裡，看起來已經很完整了。

但 Codex 開始跑大型任務之後，還是一直出現一個很實際的問題：

這一輪 Session 結束了，下一輪到底要從哪裡接？

這個問題看起來跟 PROJECT_STATE.md 很像。

兩者其實不太一樣。

PROJECT_STATE.md 保存的是專案目前仍然有效的狀態。

Handoff 處理的則是另一件事：

把這一輪尚未結束的工作，安全地交給下一輪。

最早的 Handoff，只是「幫我整理一下剛才做了什麼」

最早的 Handoff 很直覺。

Session 快結束時，通常會請 Agent：

幫我整理目前進度，讓下一個 Session 可以接著做。

然後得到一份很完整的摘要。

可能包含：

• 討論過哪些方案
• 看過哪些檔案
• 嘗試過什麼
• 中間遇到哪些錯誤
• 修改過哪些地方
• 最後做到哪
• 後面還可以做什麼

看起來資訊很多。

但後來遇過幾次很典型的情況：上一輪已經把修改範圍收斂，也跑過部分驗證，但換 Session 之後，新的 Agent 還是得重新確認「哪些 scope 已經核准、哪些測試真的跑過、哪些事情刻意沒做」。

有時候它甚至不是不知道整體目標，而是不知道自己現在應該接著實作、補 verification，還是先停在 deploy 前。

這些摩擦逐漸暴露出：單純把上一輪聊天整理成摘要，還不等於真的完成交接。

問題是下一個 Agent 開始工作時，還是得重新問：

Code 到底是什麼狀態？

哪個方案已經定案？

哪些測試真的跑過？

什麼東西還不能碰？

我第一步到底該做什麼？

問題也逐漸變得清楚：

聊天摘要和工作交接，不是同一件事。

摘要是在回答：

上一輪發生了什麼？

Handoff 應該回答：

下一輪現在可以怎麼繼續？

兩者的資訊選擇標準完全不同。

這裡也可以更明確地區分兩件事：

Session Context
≠
Durable Project State

Context 是這一輪 Agent 當下看得到、拿來推理的材料；Durable State 則是即使換 Session、發生 compaction，甚至換一個 Agent，仍然可以從 Repository、Git、Tests 或其他可查證來源重新取得的狀態。

Handoff 的角色不是把所有 Context 永久保存，而是把「還沒來得及升級成 Durable State、但下一輪又不能一起忘掉」的最小工作狀態送過 Session 邊界。

一份兩千字的摘要，也可能是一份很差的 Handoff

這是最容易誤判的地方之一。

我們很自然會認為：

Context 越完整
↓
交接越完整

但實際做 Agent Workflow，常常剛好相反。

假設上一個 Session 做了很多探索：

查 A
↓
懷疑 B
↓
測 C
↓
發現不是 C
↓
回頭查 A
↓
找到原因
↓
採用方案 D

如果 Handoff 完整記錄整段探索歷史，下一個 Agent 會同時看到：

A 很可疑
B 可能有問題
C 也檢查過
D 最後採用

資訊都是真的。

但它不一定知道：

哪些只是探索過程，哪些才是目前仍然有效的事實。

Handoff 反而應該主動丟掉很多東西。

不是保存完整歷史。

而是把交棒時仍有用的資訊壓到最小。

Handoff 至少留下五個區塊

如果大型任務確定要跨 Session，最值得保留的是這五件事：

CURRENT STATE

DECISIONS

EVIDENCE

OPEN QUESTIONS

NEXT ACTION

它們各自回答一個不同問題。

1. CURRENT STATE：現在到底在哪

第一個問題最簡單：

目前已經完成到哪裡？

例如：

## CURRENT STATE

- root cause 已定位
- 採用方案 B
- backend 修改已完成
- frontend 尚未開始
- 尚未 deploy

重點不是把所有修改列一次。

而是讓下一個 Agent 能快速建立一張：

現在這個任務停在哪個位置。

如果它必須重新讀十個檔案，才能知道上一輪只剩前端沒做，那這個 Handoff 就沒有完成它的工作。

2. DECISIONS：哪些事情已經不要重新設計

這一欄很容易和 DECISIONS.md 搞混。

可以這樣區分：

DECISIONS.md 保存的是值得長期留在 Repository 的決策。

Handoff 裡的 DECISIONS 則是：

這一個任務在這一輪已經確認、下一輪不應該無理由重新打開的選擇。

例如：

DECISIONS

- 本輪只修改 frontend state mapping
- backend contract 不變
- 不修改 production data

它不一定值得永遠留在專案裡。

但如果下一個 Agent 不知道，就可能重新擴大 scope。

它值得跨過這一次 Session 邊界。

3. EVIDENCE：不要只告訴下一輪「已經完成」

這一欄很重要。

最危險的 Handoff 之一是：

backend 已完成。

下一個 Agent 怎麼知道「完成」代表什麼？

可能只是：

Code 寫完了

也可能代表：

Code 寫完
+
targeted test 已跑
+
regression 已跑
+
實際環境已 smoke

這幾個「完成」差非常多。

Handoff 應該留下的是：

EVIDENCE

- 哪些測試已執行
- 結果是什麼
- 哪些環境尚未驗證
- 哪些結論只是推論

甚至如果根本還沒驗證，也應該明講：

EVIDENCE

- implementation completed
- tests not run yet

這比寫：

Done

有價值得多。

因為下一個 Agent 不必猜：

上一輪說的完成，到底完成到哪一層。

4. OPEN QUESTIONS：不知道的事情也要交出去

Agent 很容易在交接時只留下「知道的事」。

但有時更危險的是那些：

上一輪已經知道自己還不知道的事。

例如：

OPEN QUESTIONS

- frontend 是否還有第二份 cache 尚未確認
- production 環境尚未驗證
- 某 edge case 是否需要納入 regression 尚未決定

如果不留下這些問題，下一輪看到一份乾乾淨淨的 Handoff，很容易誤以為：

前面的分析已經全部完成。

於是「未知」會被誤讀成「不存在」。

因此：

已知未知

也視為需要交棒的資訊。

5. NEXT ACTION：下一輪第一步到底做什麼

最後一欄反而最重要。

理想上，不應讓下一個 Agent 讀完 Handoff 後還要問：

好，那接下來你希望我做什麼？

好的 Handoff 應該已經回答這個問題。

例如：

NEXT ACTION

先確認 working tree，
再完成 frontend integration，
完成後跑 targeted tests。

注意它不是：

TODO:
- frontend
- tests
- deploy
- review
- cleanup
- docs

那只是一張工作清單。

NEXT ACTION 的作用是：

告訴下一輪第一個安全動作是什麼。

因為 Session 交接最大的摩擦，很多時候不是 Agent 不知道整個專案要做什麼。

而是：

它不知道現在應該從哪一步重新進入。

合起來，最小 Handoff 可以長這樣

# HANDOFF

## CURRENT STATE
- 已完成什麼
- 尚未完成什麼
- 目前 branch / task 狀態

## DECISIONS
- 本輪已確認的方案
- 明確不處理的範圍
- 不應無理由重新打開的選擇

## EVIDENCE
- 已完成哪些驗證
- 哪些結果為 PASS / FAIL
- 哪些尚未驗證

## OPEN QUESTIONS
- 尚未釐清的問題
- 已知風險
- 仍需確認的假設

## NEXT ACTION
- 下一個 Session 第一個安全動作

這份格式刻意保持很短。

因為如果每次 Handoff 都長成五千字，新的 Session 還是得重新從大量 Context 裡找出現在最重要的是什麼。

那只是把問題從聊天紀錄搬到另一份文件。

Handoff 不是 Knowledge Base，也不應該取代 PROJECT_STATE

做到這裡，也很容易開始文件爆炸。

AGENTS.md
PROJECT_STATE.md
DECISIONS.md
HANDOFF.md
README.md
CHANGELOG.md
...

看起來好像 Agent Governance 的答案就是一直加 Markdown。

但更該問的是：

這份資訊的壽命有多長？

例如：

AGENTS.md
長期有效的工作規則

PROJECT_STATE.md
目前一段時間內有效的專案狀態

DECISIONS.md
值得長期保留的決策理由

HANDOFF
只負責跨過這一次 Session 邊界

Handoff 裡有些資訊下一輪做完後就應該消失。

有些資訊則可能升級成：

新的 PROJECT_STATE
新的 DECISION
新的 Test
新的 AGENTS rule

Handoff 比較像：

Context 的暫存轉運站。

不是永久資料庫，也不是另一套 Knowledge Base。

如果某個資訊跨過幾次 Session 仍然重要，它就不該永遠躺在 Handoff 裡；應該升級到適合它壽命與權威性的 Repository artifact，讓下一個 Agent 能重新查證，而不是只能相信上一輪留下的文字。

甚至可以用一個問題檢查 Handoff 是否合格

可以直接想像：

如果下一個 Agent 完全看不到上一輪聊天，只拿到 Repository 和這份 Handoff，它能不能安全開始工作？

它至少應該回答得出：

1. 現在做到哪？
2. 哪些事情已經決定？
3. 哪些東西真的驗證過？
4. 還有哪些未知？
5. 第一個動作是什麼？

如果這五個問題還要重新翻聊天才能回答，

那份文件可能是一份很好的摘要，

但還不是一份好的 Handoff。

Handoff 也可能害人

這套方法也不是沒有風險。

最明顯的就是：

Handoff 會過期。

例如上一輪寫：

backend 尚未 deploy

但中間有人已經 deploy。

下一個 Agent 如果把 Handoff 當絕對真相，就會拿著舊 Context 工作。

Handoff 不應被當成 Evidence 本身。

它比較像：

告訴下一輪應該從哪裡開始查證。

Code 狀態仍然要看 Git。

Test 狀態仍然要看測試結果。

Production 狀態仍然要從對應環境確認。

也就是：

Handoff
→ 提供方向

Repository / Tests / Environment
→ 提供事實

不然我們只是從「過度相信聊天」變成「過度相信 Markdown」。

到 Day 6，Context 開始呈現不同時間尺度

回頭看前幾天的東西，可以這樣理解：

AGENTS.md
↓
長期工作規則

PROJECT_STATE.md
↓
目前有效狀態

DECISIONS.md
↓
值得保留的決策理由

HANDOFF
↓
跨過下一個 Session 所需的最小工作狀態

它們不是在競爭誰要保存最多資訊。

反而是在決定：

什麼東西應該被保存多久。

這也是 Durable Context 很重要的一部分。

因為可持續的 Agent Workflow，不應該建立在：

Agent 永遠記得全部東西。

而是建立在：

即使它會忘，我們仍然知道哪些東西不能一起被忘掉。

下一篇

Handoff 解決的是：

Session A 結束後，Session B 怎麼接手。

但還有一個更麻煩的情況。

有時候 Session 根本還沒有結束。

只是 Context 已經太長、開始被壓縮，前面的資訊逐漸離開當下工作區。

這時候問題就會從：

怎麼交給下一個 Session？

變成：

當 Conversation 本身開始遺失細節時，哪些狀態不能再只存在對話裡？

這也把後續注意力從 Conversation Memory，進一步移向 Durable State。

Day 6 解的是「怎麼交棒」；下一步要解的是「什麼資訊不該只靠交棒活著」。