Session Handoff 看 Long-running Agent — Scaffold 出自己的 AI 開發流程

讓 AI Coding Agent 跑 Long-running 的開發流程，重點其實不是 long-running 本身，是「怎麼設計一個屬於自己的開發流程」。

我覺得最好玩的部分是，可以從這個 Long-Running 再擴充出自己專屬的子元件 - Research Agent, KB Retrieval, Testing Agent 等等等。

之前寫過一篇文：Long-running Agent 的核心是「交接零成本」— 不是讓一個 session 撐很久，是讓無限個 session 可以接力跑下去。

Anthropic 在《Effective Harnesses for Long-running Agents》裡用了一個很精準的比喻：Agent 跨 session 工作就像工程師輪班，每個新來的工程師對上一班發生了什麼完全沒有記憶。如果交班紀錄寫得好，新人幾分鐘就能上手；如果什麼都沒留，就是花第一個小時重建 context，而且通常會理解錯。

Anthropic 的解法是 Initializer + Coding Agent 雙 Prompt 架構 — 第一個 session 建環境、拆 feature list，之後每個 session 只做一個 feature，做完 commit + 寫交班日誌，保持 codebase 隨時可 merge。

落地的時候馬上遇到一個問題：session 之間到底要傳遞什麼？用什麼格式？誰決定下一步做什麼？做完怎麼驗收？這些問題好像也沒有什麼標準答案，每個人的開發方式不一樣。

Flywheel — 一個開發流程的框架

根據這個架構做了一個 scaffolding 叫 Flywheel (gitHub: romanticamaj/flywheel)，它是一個 Claude Code plugin，本質上是一個「開發流程的框架」。

整個流程長這樣：

Spec → 自動規劃 feature list → 每個 session 實作一個 feature → multi-agent code review → 寫交班日誌 → 下一個 session 接手。

Relay 給下一個 new Session，接著循環，直到 Spec 完成。

每個環節我都根據自己在意的東西做了選擇：

規劃：feature checklist 用 JSON 不用 markdown — Anthropic 在實驗中發現 Agent 會偷改 markdown 的結構，JSON 的 schema 讓它更難亂動
實作：一個 session 只做一個 feature，做完必須是可以 merge 的狀態，沒有半成品
Review：四層 pipeline（cleanup → peer review → cross-model → E2E），可以根據 feature 重要性選擇跑幾層（Anthropic 的 Agentic Coding Trends Report 提到工程師用 AI 做約 60% 的工作，但能完全委派的只有 0-20% — review 的重要性是被放大的，不是縮小的）
交接：machine-readable 的交班日誌（JSONL），下一個 session 讀完就能直接動工

這些選擇反映的是我對「什麼算一個好的開發流程」的定義，你的定義一定跟我不一樣，所以你的 scaffolding 也會長不同的樣子：

有人在意速度 — 流程越輕越好，規劃完就直接衝
有人在意品質 — 四層 review 全開，寧可慢也不要漏
有人在意可追溯性 — 每個 session 結束要有 compliance table，誰做了什麼一目瞭然

你在意什麼，你的流程就會長什麼樣子；除此之外，還可搭配 token 用量跟開發時間去衡量。

不只適用於軟體開發

這個思路不只適用於軟體開發，任何需要「拆解 → 執行 → 驗收 → 接力」的工作都行：

寫一系列的技術文件 — 每個 session 完成一個章節，交班日誌記錄大綱進度和風格決定
做一份研究報告 — 每個 session 處理一個主題，review 確保引用正確、論述一致 (參考超級紅的 AutoResearch Repo)
經營內容 — 每個 session 產出一篇貼文，交接時帶上品牌語氣和已發布的脈絡

Anthropic 最新的 harness design 研究也在往這個方向走 — 從純 coding agent 擴展到 planning / generation / evaluation 三角色分離的通用架構，處理的已經不只是寫 code，而是任何需要長時間迭代的創作任務。

核心都一樣：把一個大目標拆成可以一棒一棒傳下去的單位，每一棒結束的時候狀態是乾淨的，下一棒能直接接手。

重要的東西寫在磁碟上，不是留在 context window Context Window = RAM，Filesystem = Disk

在用 AI agent 做任何持續性的工作，不管是寫 code、寫文件、做研究，我會試著想一下：

我最在意什麼？
每一棒之間需要傳遞什麼？
怎樣算「做完」？

把這些想清楚，scaffold 出來，讓它可以跨 session 一直跑。

這就是我們專屬的 Flywheel。