原來我一直以來都搞錯 Long-running Agent / Loop Agent 的概念。
讀完 Anthropic 發的《2026 Agentic Coding Trends Report》才發現「long-running 是一個 session 跑很久，context window 越大越好」完全不是這麼回事。
Long-running 的核心是「交接零成本」
最常遇到的痛點就是，這個 session 做得很開心，但是 Context 要爆的時候就開始 compact，甚至要 Reset 這個 Session。除非靠 Coding Agent 自己做的記憶管理，不然根本沒辦法延續做，我們必須更「工程化」地來延續這個 Session （沒有人想要靠 Vibe Coding 一直祈禱）。
所以問題從來就不是「怎麼讓一個 Session 撐得更久」，而是無止境的 session 接龍，不斷地傳遞 Context 下去，直到這個任務完成，甚至未來的 Maintenance。
讀完整份報告加上 Anthropic 自家工程團隊的建議，記錄一下四個我覺得比較有興趣的工程範式：
1. Planning — 計畫要寫在磁碟上，不是 context 裡
Coding Agent 的 Plan Mode 的 Plan 通常只存在 context window 裡面，/clear 就沒了。
可以用 planning-with-files 這個 skill，它會把計畫寫成三個 markdown 檔（task_plan.md、findings.md、progress.md）直接存在專案目錄。
Context Window = RAM，Filesystem = Disk。我們不會把重要資料只存在 RAM 裡，Agent 的工作記憶也一樣。
2. Long-running — 不是一個 session 一直跑、跑很久，是交接零成本
Anthropic 的工程團隊讓 Claude 自主建造了一個 claude.ai clone（200+ features），過程中發現三個失敗模式：
- Agent 嘗試 one-shot 整個 app → context 在實作中途燒完，下一個 session 接手一個半成品爛攤子
- 後面的 Agent 看到前面已經有進度 → 直接宣布完成，提早下班
- Agent 寫完 code 跑個 unit test 就標記 done → 但 E2E 根本是壞的
（聽起來像某些人類同事😳）
他們的解法叫做 Initializer + Coding Agent 雙 Prompt 架構：
- 第一個 session（Initializer）建立環境 — 一份完整的 feature checklist（用 JSON 不用 markdown，因為 Agent 會偷改 markdown 的結構 🫠）
- 一個
init.sh開機腳本、一份空的交班日誌claude-progress.txt、還有一個 initial git commit
之後每個 session（Coding Agent）都跑類似 git flow 流程：
- 讀交班日誌 + git log
- 讀 feature list，挑最高優先做
- 跑
init.sh啟動 dev server - 跑 smoke test 確認 app 還活著
- 實作一個 feature — 只做一個，不用多
- E2E 驗證這個 feature 真的 work
- git commit + 更新交班日誌
每個 session 結束時 code 必須是「可以 merge 到 main」的狀態，沒有半成品。
這才是 long-running 的真正意思啊啊啊啊啊，session 接力賽啦～
3. Multi-Agent — 不是多開 terminal，是每個 Agent 有角色
報告提到 2026 年的關鍵轉變之一是 single agent → coordinated teams。
實際操作上，Claude Code 原生的 –worktree 可以給你 session 隔離；但光有隔離不夠，我們還是需要一個 「流程」。
gstack（Garry Tan 開源的 Claude Code setup）提供角色化的 workflow：
/plan-ceo-review— CEO 視角，先定義「建什麼、為什麼」/plan-eng-review— 工程Manager 視角，鎖定架構和 edge cases/review— Staff Engineer 級 code review/qa— 用真正的 Chromium 瀏覽器做 E2E 測試/ship— deploy checklist + test coverage audit
一個人可以同時跑多個 parallel session，每個有明確的角色和停止條件。
工程師的角色從 coder 變成 orchestrator。
4. Review — 多層、多模型、不只看一次
報告提到一個數據：工程師用 AI 做約 60% 的工作，但能「完全委派」的只有 0-20%。
意思是 review 的重要性被放大了，不是縮小了。
實際的多層 review stack：
/simplify— 做完 feature 馬上跑，3 個平行 agent 分別看 code reuse / quality / efficiency/review— PR-level review，找 bugs、logic errors、edge cases、security issues/codex— gstack 獨有，用 OpenAI Codex CLI 做完全獨立的 cross-model review （兩個不同 AI 看同一份 code，重疊的 findings = 高信心問題，各自獨有的 = 需要人判斷）/qa— 真瀏覽器 E2E 測試，不是跑 unit test 就算了
這對應報告裡說「Human oversight shifts from reviewing everything to reviewing what matters」，不是所有東西都要人看，而是讓 Agent 先篩過，人只看真正需要判斷力的部分 （我覺得這步驟最累，心智負擔超重….）。
馬上可以試的工程範式轉移
- 裝
planning-with-files→ 所有計畫從 context 搬到 filesystem - 在
CLAUDE.md寫入 Session Protocol → 每個 session 自動遵守 long-running 的 7 步 loop - 裝 gstack → 角色化多 Agent workflow
- 做完 feature 的 SOP 改成
/simplify→/review→/codex三層 review - 建一個 Initializer prompt template 存成 custom skill → 每個新專案一鍵建立 long-running 環境
新東西學不完，有夠累，比以前更累捏。
今天研究完，整個癱在沙發上···