Anthropic 的工程部落格發了一篇 Effective Harnesses for Long-Running Agents。
如果 OpenAI 的 Harness Engineering 是在講「怎麼讓 agent 在一個 repo 裡持續交付」，Anthropic 這篇則是在回答一個更底層的問題：
當一個任務大到塞不進一個 context window，agent 要怎麼跨 session 接力完成？
TL;DR
- AI agent 的 context window 是有限的。複雜專案不可能在一個 session 裡完成
- 每個新 session 開始時，agent 完全失憶——不知道上一輪做了什麼、做到哪裡、哪些東西壞了
- Anthropic 的解法：雙 Agent 架構——Initializer Agent 建基礎設施，Coding Agent 每 session 做增量交付
- 核心洞察：把 agent session 當成輪班制——像護理師交班一樣，靠交接文件和結構化紀錄維持連續性
- 本文用三層深度拆解：問題本質 → 機制分析 → 應用框架
一、問題本質：為什麼長時間任務對 AI 這麼難
1.1 Context window 是一堵硬牆
不管模型多強，context window 就是那麼大。Claude 目前的 context window 雖然已經很長，但面對一個需要幾千行 code 的完整應用，一個 session 就是不夠用。
更關鍵的是：**每個新 session 開始時，agent 完全歸零。**它不記得上一輪做了什麼、改了哪些檔案、哪個 feature 做到一半、哪些測試是壞的。
這就像每天早上有一個新員工來上班，但昨天那個員工已經離職了，而且沒留任何交接。
1.2 沒有 harness 的 agent 會怎樣？
Anthropic 在實驗中觀察到兩個致命的失敗模式：
失敗模式 1：一口氣吞（One-shot）
Agent 試圖在一個 session 裡把整個應用寫完。結果 context 用到一半就爆了，留下一堆半成品——沒有 commit、沒有文件、下一個 session 根本不知道從哪裡接。
失敗模式 2：提早宣佈完工
新的 agent session 進來後，沒有辦法準確評估專案狀態，直接宣佈「全部做完了」。實際上一堆 feature 根本沒測、沒完成、甚至根本沒寫。
我的經驗：我用 Claude Code 做過一個稍大的重構任務。第一輪 session 做到一半 context 快滿了，它開始「加速收尾」——把好幾個步驟壓在一起、跳過測試、省略 error handling。結果那次的產出品質明顯比正常差。問題不是模型變笨了，而是它「知道自己快沒空間了」所以開始走捷徑。
二、機制分析：雙 Agent 架構逐層拆解
Anthropic 的解法很優雅：不是做一個超級 agent，而是用兩種角色 + 外部記憶體來建立跨 session 的連續性。
2.1 整體架構
Session 1（Initializer Agent）
├── 產出 init.sh ← 開發環境啟動腳本
├── 產出 features.json ← 200+ 項功能清單（全部標記 passes: false）
├── 產出 claude-progress.txt ← 跨 session 交接日誌
└── 初始 git commit ← 基線版本
Session 2..N（Coding Agent）
├── 讀 git log + claude-progress.txt ← 「交班」
├── 跑 init.sh 啟動 dev server ← 恢復環境
├── 跑 E2E 測試 ← 確認現況
├── 選一個 feature 做 ← 增量交付
├── commit + 更新 progress ← 留交接紀錄
└── 確保 codebase 可 merge ← 乾淨交班
注意一個精妙的細節：這兩個 agent 其實用的是同一個系統、同一套工具，差別只在 user prompt 不同。它們不是兩個不同的程式，而是兩種不同的「角色指引」。
2.2 Initializer Agent：打地基的那一班
Initializer Agent 只在第一個 session 跑一次，負責建立所有後續 session 需要的基礎設施。
產出 1：init.sh — 開發環境啟動腳本
讓每個後續 session 不用浪費時間搞「怎麼把 dev server 跑起來」。一個指令就能恢復工作環境。
產出 2：features.json — 結構化功能清單
這是整個架構最聰明的部分。Initializer 會把使用者的高階描述（例如「做一個 claude.ai 的 clone」），展開成 200+ 個具體、可測試的 feature，用 JSON 格式儲存。
為什麼用 JSON 而不是 Markdown？
- 防止 agent 偷改規格：Markdown 格式太容易被 agent 在實作過程中「順手」修改，把做不到的需求改成做得到的
- 每個 feature 有 passes 欄位：初始全部標記
passes: false，agent 必須通過測試才能改成true - 結構化 = 可機械檢查：你可以用 script 算出完成率、找出卡住的 feature、追蹤進度
產出 3：claude-progress.txt — 交接日誌
這是 agent 版的「護理師交班紀錄」。每個 session 結束前必須更新：做了什麼、做到哪裡、遇到什麼問題、下一步建議做什麼。
產出 4：初始 git commit — 基線版本
建立一個乾淨的起點。後續 session 如果搞砸了，可以 revert 回已知的好狀態。
2.3 Coding Agent：接力跑的每一棒
每個後續 session 都由 Coding Agent 執行，它有一個嚴格的啟動儀式（Startup Protocol）：
Step 1: pwd ← 確認自己在哪
Step 2: 讀 git log + progress.txt ← 「昨天那位做了什麼？」
Step 3: 讀 features.json ← 「哪些還沒做？」
Step 4: 跑 init.sh ← 恢復開發環境
Step 5: 跑 E2E 測試 ← 「現在的 code 是好的嗎？」
Step 6: 開始做一個 feature ← 增量交付
最關鍵的設計約束：
- 一次只做一個 feature：不要貪多，做完一個再做下一個
- 做完必須 commit：帶描述性訊息，讓下一個 session 看得懂
- 做完必須更新 progress.txt：交班紀錄不能省
- code 必須維持在可 merge 狀態：不要留半成品給下一個人
- 不准刪除或修改既有測試：prompt 裡直接寫 "It is unacceptable to remove or edit tests"
2.4 測試策略的演進
一開始他們用 unit tests + curl 指令做驗證，發現不夠——很多 UI bug 這樣抓不到。
後來加入 Puppeteer MCP（Model Context Protocol） 做瀏覽器自動化測試，讓 agent 能：
- 像使用者一樣操作瀏覽器
- 截圖驗證 UI 狀態
- 執行端到端的使用者旅程
- 發現純 code inspection 看不到的 bug
他們也很誠實地指出一個限制：瀏覽器原生 alert modals 對 Puppeteer 不可見，導致依賴 modal 的 feature 品質一直比較差。
我的經驗：這跟我在 Claude Code 裡的感受完全一致——AI 寫的 code 可以通過型別檢查和 lint，但 UI 行為是不是對的，你不讓它「看」就永遠不知道。測試不是裝飾，是 agent 的另一組眼睛。
三、深層洞察：為什麼這個設計有效
3.1 它把「AI 的弱點」轉化成「軟體工程的強項」
AI 的弱點：短期記憶、跨 session 失憶、容易走捷徑。
軟體工程的強項：版本控制、文件、測試、增量交付、code review。
Anthropic 做的事情就是：用成熟的軟體工程實踐來補償 AI 的認知限制。 Git commit 是 checkpoint。Progress file 是交接。Feature list 是 acceptance criteria。E2E test 是驗收。
這不是什麼新發明，而是把人類工程師做了幾十年的事情，系統化地套到 agent 上。
3.2 外部記憶 > 內部記憶
agent 的「記憶」不應該靠 context window，而應該靠外部 artifact：
| 外部 artifact | 功能 | 為什麼比 context 好 |
|---|---|---|
| git history | checkpoint + 可回滾 | 永久保存、可追溯 |
| claude-progress.txt | 跨 session 交接 | 不受 context 限制 |
| features.json | 進度追蹤 + 防止偷改 | 結構化、可機械檢查 |
| init.sh | 環境復原 | 一鍵恢復、不靠記憶 |
這個設計的啟示：不要把重要資訊只放在 prompt 裡。 Prompt 會過期（context 用完就沒了），但 file 會留下來。
3.3 「增量交付」不是建議，是必須
他們發現 one-shot（一口氣做完）的失敗率極高，而 incremental（一次做一個 feature）的成功率大幅提升。
這跟人類軟體開發的經驗完全一致：
- 小 PR 比大 PR 好 review
- 頻繁 commit 比一次大 commit 安全
- 做完一個功能再做下一個，比同時做五個更可靠
差別只是：對人類來說這是「最佳實踐」；對 agent 來說這是「生存必需」。因為 context window 的硬限制，agent 不增量就會死。
3.4 對比 OpenAI 的 Harness Engineering
兩篇文章解決的問題不同，但互補：
| 面向 | OpenAI Harness Engineering | Anthropic Long-Running Harness |
|---|---|---|
| 核心問題 | 高吞吐量下如何維持品質與一致性 | 跨 context window 如何維持連續性 |
| 時間尺度 | 單 session 內（可長達 6 小時） | 多 session 跨天/跨週 |
| Agent 數量 | 多 agent 協作（agent-to-agent review） | 單 agent 接力（同一角色換班） |
| 記憶機制 | repo 內文件 + linters + CI | progress file + git + feature list |
| 核心比喻 | 控制系統（sensors / actuators / controller） | 輪班工人（handoff notes / shift protocol） |
| 人類角色 | 系統設計者 | 班長 / 品質把關者 |
它們不衝突，可以疊加使用。 OpenAI 的方法解決「agent 在一個 session 裡怎麼做好」，Anthropic 的方法解決「多個 session 之間怎麼銜接」。
四、誠實的批判：它沒說的事
4.1 沒有量化指標
文章沒有公佈具體的完成率、bug 率、token 效率、或每個 feature 的成本。我們只知道「效果大幅改善」，但改善了多少？沒有數字。
4.2 只在 Web 開發上驗證
他們的實驗是「clone 一個 claude.ai」——一個全端 Web 應用。文章自己也承認：「questions remain about generalization to other domains like scientific research or financial modeling」。
4.3 需要精心設計的 prompt
他們明確說這需要「sophisticated, carefully crafted prompts」和「strongly-worded instructions」。這不是一個你隨便丟個任務就能用的框架——你需要花時間設計 prompt，而且措辭要夠強硬（例如「It is unacceptable to remove or edit tests」）。
4.4 用的是最強模型
文章用 Opus 4.5 做實驗。一般開發者用 Sonnet 或更小的模型，效果不一定相同。模型越弱，可能越需要更嚴格的 prompt 和更強的護欄。
4.5 安全性問題未深入
Agent 自動 commit code、自動跑 shell script——這裡面的安全隱患很大。自動 commit 的 code 可能有 vulnerability、init.sh 可能被注入惡意指令。文章對此著墨不多。
五、應用框架：你今天就能套用的多 Session 開發流程
不需要 Claude Agent SDK，不需要 Opus 4.5。以下是用任何 AI 工具都能套用的增量交付框架，按投資報酬率排序。
Level 1：交接日誌（投入 5 分鐘 / session，立即見效）
做什麼：每次 session 結束前，讓 AI 產出一份交接紀錄。
在你的 repo 根目錄建一個 ai-progress.md：
# AI 開發進度日誌
## Session 3 — 2026-02-22
### 完成
- 實作了 BlogCard 元件的 hover 動畫
- 修復了 dark mode 下文字顏色問題
### 未完成
- Tag 篩選功能做到一半，filter logic 寫好了但 UI 還沒接
### 已知問題
- mobile 上 hover 效果需要改成 tap
### 下一步建議
- 先完成 Tag 篩選的 UI 接線
- 再做 search 功能
每次新 session 開始，先讓 AI 讀這個檔案。
為什麼有效：解決了 90% 的跨 session 失憶問題。成本幾乎為零。
Anthropic 對應：claude-progress.txt。
Level 2：結構化功能清單（投入 15 分鐘）
做什麼：在開始大型任務前，先讓 AI 把需求展開成結構化的 feature list。
{
"features": [
{
"id": "F001",
"category": "UI",
"description": "BlogCard 元件顯示標題、摘要、日期、標籤",
"test_steps": "1. 開啟首頁 2. 確認每張卡片顯示四個欄位",
"status": "done"
},
{
"id": "F002",
"category": "UI",
"description": "Tag 點擊後篩選文章列表",
"test_steps": "1. 點擊任一 tag 2. 確認列表只顯示該 tag 的文章",
"status": "pending"
}
]
}
為什麼用 JSON 不用 Markdown：
- AI 比較不會在實作過程中「順手」改 Markdown 的需求描述
- JSON 可以用 script 統計完成率：
jq '[.features[] | select(.status=="done")] | length' features.json - 結構固定，每個 feature 都有明確的測試步驟和狀態
為什麼有效：防止 agent 提早宣佈完工或偷改需求。你隨時可以算出「做了幾個、還剩幾個」。
Anthropic 對應：200+ features 的 JSON feature list，全部初始標記 passes: false。
Level 3：Session 啟動儀式（投入 10 分鐘設計，每次自動執行）
做什麼：在每個新 session 的第一個 prompt 裡強制一個「啟動儀式」。
在開始任何工作之前，請按以下順序執行：
1. 讀 ai-progress.md，理解上一輪做了什麼
2. 讀 features.json，找出最高優先級的未完成 feature
3. 跑 npm run dev 確認 dev server 正常
4. 跑 npm test 確認現有測試全部通過
5. 如果有測試失敗，先修好再開始新工作
6. 確認以上步驟後，告訴我你打算做哪個 feature
不要跳過任何步驟。
為什麼有效：防止 agent 一上來就開始寫 code。先恢復環境、確認現況、選定目標，再動手。這跟 Anthropic 的 Startup Protocol 是同一個邏輯。
Anthropic 對應：pwd → git log → progress file → init.sh → E2E test → 選 feature。
Level 4：增量 Commit 紀律（每個 feature 完成後）
做什麼：要求 AI 每完成一個 feature 就 commit + 更新進度。
在 prompt 裡加上：
完成一個 feature 後，必須：
1. git commit 帶描述性訊息（說明做了什麼、為什麼）
2. 更新 ai-progress.md
3. 更新 features.json 的 status 欄位
4. 確保 code 在可 merge 的狀態——不要留半成品
絕對不要刪除或修改既有的測試。
為什麼有效：每個 commit 都是一個 checkpoint。如果下一個 feature 搞砸了，可以 revert 到已知的好狀態。這是你的安全網。
Anthropic 對應：descriptive git commits + mandatory progress updates + "unacceptable to remove or edit tests"。
Level 5：環境一鍵恢復（投入 30 分鐘）
做什麼：寫一個 init.sh（或 init.ps1），讓每個 session 能一鍵恢復開發環境。
#!/bin/bash
# init.sh — 開發環境啟動腳本
echo "=== 安裝依賴 ==="
npm install
echo "=== 啟動 dev server ==="
npm run dev &
DEV_PID=$!
echo "=== 等待 server 就緒 ==="
sleep 5
echo "=== 跑 smoke test ==="
curl -s http://localhost:3000 > /dev/null && echo "Server OK" || echo "Server FAILED"
echo "=== Dev server PID: $DEV_PID ==="
為什麼有效：Agent 不需要「記得」怎麼把環境跑起來，也不會浪費 context 去探索。一個指令就恢復到可以工作的狀態。
Anthropic 對應：init.sh 作為 Initializer Agent 的核心產出之一。
Level 6：瀏覽器驗證（進階，投入 1-2 小時）
做什麼：如果你的專案有 UI，加入 Playwright 或 Puppeteer 讓 AI 能「看見」自己寫的東西。
# AI 可以跑這個來驗證 UI 行為
npx playwright test
或者如果你用 Claude Code，可以用 MCP 工具讓它操作瀏覽器截圖。
為什麼有效：Unit test 測邏輯、E2E test 測行為。很多 bug 只有在瀏覽器裡才看得到。Anthropic 也說「Claude mostly did well at verifying features end-to-end once explicitly prompted to use browser automation tools」。
Anthropic 對應：Puppeteer MCP 做 E2E 瀏覽器自動化測試。
六、一張圖總結：多 Session 增量交付的投資階梯
投資少 ──────────────────────────────────── 投資多
效果立即 ────────────────────────────────── 效果長期
Level 1 Level 2 Level 3 Level 4 Level 5 Level 6
交接日誌 → 功能清單 → 啟動儀式 → 增量 Commit → 環境一鍵復原→ 瀏覽器驗證
progress.md features.json Startup git commit init.sh Playwright
5 min/session 15 min 一次 Protocol 每 feature 30 min 一次 1-2 hr 一次
防提早完工 防亂做 checkpoint 不浪費 context AI 看得見 UI
[今天就做] [今天就做] [明天設計] [每次遵守] [本週完成] [適合 UI 專案]
七、結語：讓 AI 像輪班工人一樣工作
Anthropic 這篇文章最精彩的洞察是那個比喻：把 agent session 當成輪班。
每個新 session 就像一個新來的輪班工人：
- 它不知道上一班做了什麼 → 所以需要交接日誌（progress file）
- 它不知道整個專案的全貌 → 所以需要功能清單（feature list）
- 它不知道環境怎麼跑 → 所以需要標準作業程序（init.sh）
- 它可能想一口氣把事情做完 → 所以需要**「一次只做一個」的紀律**
- 它可能宣佈做完了但其實沒有 → 所以需要可測試的 acceptance criteria
這些不是什麼 AI 特有的新發明。這就是人類軟體工程做了幾十年的事情——版本控制、文件、測試、增量交付、code review——只是現在我們把同樣的紀律套到了一個記憶力只有一個 context window 的合作夥伴身上。
如果你已經讀過 我分析的 OpenAI Harness Engineering，你會發現兩篇文章形成一個完整的拼圖：
- OpenAI 回答：agent 在單一 session 裡怎麼做好（護欄 + 架構 + GC）
- Anthropic 回答：多個 session 之間怎麼銜接（交接 + 增量 + 驗證）
把兩者結合，你就有了一個從「單次任務」到「長期專案」都能覆蓋的 AI 協作框架。
而且起步成本很低：一個 ai-progress.md + 一個 features.json + 一句「做完記得 commit」，你今天就能開始。