上一篇解決了長期任務的連續性：通過任務清單、進度與 Git，讓新 Context 接續工作。接下來還有一個不同的問題：Agent 能一直開發，不代表應用的功能、交互和設計已經達到要求。
“做完了哪些任務”與“做出來的東西是否好用”，需要不同的檢查。前者依賴狀態管理，後者依賴明確標準、實際操作和修正反饋。
Anthropic 在《Harness design for long-running application development》中，從前端設計評價走向完整應用開發，又通過實驗簡化了自己的 Harness。這裏重點整理：
- 質量反饋： 為什麼把生成與評價分開，怎樣把抽象要求轉成具體標準。
- 開發組織： Planner、Generator、Evaluator 怎樣配合，Sprint Contract 怎樣連接規格與驗收。
- 流程優化： 哪些組件彌補了模型的不足，哪些已經成為額外負擔。
一、長期開發需要什麼質量反饋h2
任務接續與成果驗收處理不同的問題。先區分這兩層，再看獨立評價提供什麼反饋。
1. Context Management 與 Self-Evaluation：長任務的兩類問題h3
Context 越來越長，模型可能難以穩定使用已有信息；即使任務能夠繼續，它也可能遺漏功能或接受不夠好的結果。這是兩個問題，不能只靠“再運行幾輪”一起解決。
Context Reset 與 Compaction
兩種方式都能處理歷史增長，但保留信息的方式不同：
| 方式 | 怎樣繼續任務 | 需要承擔的代價 |
|---|---|---|
| Compaction | 壓縮已有歷史，在縮短後的上下文上繼續 | 摘要可能遺漏信息，原有判斷也可能延續 |
| Context Reset | 清空當前上下文，通過交接材料重新建立工作狀態 | 恢復材料必須充分，重新讀取增加開銷 |
Reset 的收益來自重新建立一個更清晰的起點，代價是切斷上下文連續性。Compaction 更直接地保留前後關係，但不是所有偏差都會因歷史變短而消失。
持續執行與質量判斷
假設一個筆記應用已經能編輯和保存，模型仍可能忽略搜索反饋、內容丟失提示或頁面層級。運行時間變長，並不會自然給它增加一個更嚴格的驗收標準。
原文將生成與評價分開，正是在補充這條反饋鏈：不是隻讓 Agent 繼續做，而是讓它知道哪裏與要求不同、應該依據什麼修改。
2. Generator–Evaluator：分開產出與評價h3
Generator 負責產出，Evaluator 負責依據標準檢查產物，再把問題反饋給 Generator。兩者分開，能減少開發者圍繞自己的實現解釋“為什麼已經足夠好”的傾向。
但換一個 Agent 並不自動得到可靠評價。Evaluator 仍可能寬鬆，也可能重複模板式意見。它需要明確標準、可觀察證據，以及用於校準判斷的例子。
怎樣把“好看、好用”變成可以討論的要求？
以前端為例，可以分別檢查：
- 整體設計： 色彩、字體、佈局與視覺重點是否形成一致表達。
- 獨特性： 是否針對內容作出具體設計，而不是隻套用默認組件。
- 製作質量： 間距、對齊、對比度和層級是否穩定。
- 功能可用性： 用户能否找到主要操作並完成任務。
這些維度不是一個通用審美公式，而是讓評價從“感覺不錯”進入有依據的討論。實際權重應服務於產品目標：閲讀型博客與密集操作的工作台，不應照搬同一套偏好。
反饋要指向可以修改的位置
“搜索體驗不好”太寬泛；“輸入關鍵詞後沒有加載狀態，空結果與請求失敗顯示相同文案”才指出了行為缺口。
對 Generator 來説，有價值的反饋包含預期、觀察和差異。它可以據此修改，再由 Evaluator 重走同一條路徑，確認問題是否消失。
獨立評價形成的是改進循環，不是無限修改的理由。標準達成、收益趨於停滯或成本達到約定邊界時，都需要明確停止。
二、規劃、實現與驗收怎樣配合h2
產品規格確定要交付什麼，開發約定細化完成條件，實際 QA 再檢查運行結果。
3. Planner、Generator 與 Evaluator：組織三類職責h3
應用開發比單頁設計多了一層需求組織：一句“做一個課程筆記應用”，並沒有説明完整的使用路徑、功能範圍和質量要求。
三種角色可以分別處理：
| 角色 | 主要產出 | 不應混淆的責任 |
|---|---|---|
| Planner | 產品規格、用户路徑、交付範圍與高層設計 | 不提前鎖死所有實現細節 |
| Generator | 可運行實現、自測結果和待驗收產物 | 不以自評代替獨立驗收 |
| Evaluator | 實際檢查、問題證據與驗收判斷 | 不只閲讀實現者的完成報告 |
Planner 要讓產品範圍足夠明確，同時保留開發中的判斷空間。例如，它可以要求“編輯完成後能夠重新打開並看到保存內容”，不必提前規定每個函數和數據庫操作的具體寫法。
Generator 則負責把規格落實為軟件。開發過程中仍然需要自測，獨立 QA 不是允許它跳過基本檢查的理由。
Evaluator 連接的是規格與真實結果。它既要理解應該交付什麼，也要能夠訪問運行中的應用，檢驗實現是否只停在界面展示。
原文的完整應用版本分別檢查產品深度、功能、視覺設計和代碼質量，併為各項設置最低門檻；任一項未達標，都需要返修，而不是靠其他維度的高分抵消功能缺口。
這張圖描述的是原文帶 Sprint 的版本，並不表示所有長期開發都必須採用固定 Sprint。後面的簡化實驗，正是在檢查這個結構裏哪些部分仍然必要。
4. Sprint Contract：約定本輪範圍與完成標準h3
產品規格通常描述“應該有什麼”，Sprint Contract 則進一步明確：這一輪交付哪些行為，怎樣判斷它們完成。
Generator 提出實現範圍和驗證方式，Evaluator 在開發前檢查是否遺漏關鍵路徑。這樣驗收不是開發結束後臨時追加要求，而是圍繞雙方已經確認的範圍進行。
以“筆記自動保存”為例，一份自擬的簡化約定可以寫成：
範圍： 編輯正文並自動保存，不包含多人協作。
驗收： 修改內容後出現保存狀態；重新打開筆記仍能看到修改；請求失敗時保留本地輸入並顯示可重試提示。
檢查方式： 瀏覽器操作、保存請求與重新讀取的數據相互對應。
這個約定比“完成自動保存功能”多了三類信息：用户能觀察的行為、失敗情況下的要求、驗證依據。
同時，Contract 不應變成提前寫完所有代碼的設計書。把實現路徑規定得過細，會把規劃階段的錯誤強加給後續開發；把驗收寫得過鬆，又容易出現有界面、沒有完整行為的佔位實現。
它的作用是約束交付結果，而不是消除開發者的全部判斷。
5. Real-world QA：檢查交互、接口與數據狀態h3
獨立 QA 的重點是驗證應用怎樣運行，而不只是檢查源碼裏是否存在相關函數。
仍以自動保存為例，可以分三層觀察：
- 界面行為： 輸入是否保留，保存反饋是否清楚，失敗後是否能夠繼續操作。
- 接口行為： 發出了什麼請求，成功與失敗怎樣返回。
- 數據狀態： 重新讀取後是否得到剛才的內容，而不是舊數據或只存在前端內存中的值。
Playwright 等瀏覽器工具讓 Evaluator 能夠像用户一樣操作應用，再結合接口與數據檢查判斷斷點。三層證據相互補充：接口成功不能代替頁面驗證，截圖正確也不能證明數據已持久化。
QA 返回的問題記錄也應包含復現步驟與實際結果。比如“斷網後繼續輸入，再恢復網絡，內容沒有重新保存”，比“存在網絡異常問題”更容易驅動下一輪修正。
評價仍有能力與工具邊界。新增一個 Evaluator 不等於覆蓋了所有功能；如果它只點擊首頁，就無法檢驗深層編輯流程。需要檢查的既包括應用，也包括 Evaluator 實際執行了哪些路徑。
三、Harness 怎樣通過實驗持續簡化h2
模型與任務變化以後，需要重新檢查每個組件仍在解決什麼問題。
6. Component Ablation：逐項移除並比較流程效果h3
Harness 的每個額外步驟，都在補償某種不足：容易失去任務連貫性，就增加交接；容易縮小需求，就增加 Planner；容易漏掉功能，就增加 QA。
這些不足會隨模型、任務和工具變化。因此，過去有效的組件，不一定永遠值得保留。
原文呈現了兩個不同階段的調整：
- 較早使用 Sonnet 4.5 時，Context Reset 用於緩解長任務中的過早收尾；換用 Opus 4.5 後，這個實驗能夠取消強制 Reset，使用自動 Compaction 繼續運行。
- 後來使用 Opus 4.6 時，作者移除了固定 Sprint，保留 Planner 與 Evaluator，將 QA 從逐 Sprint 檢查改為整段開發後的檢查與返修。
這不是“新模型不需要 Harness”的結論，而是模型可靠完成任務的範圍發生了變化。一部分工作已經能夠直接做好，另一部分邊緣能力仍需要外部反饋。
怎樣判斷刪除是否合理？
可以把組件與它原來要解決的問題一一對應，再逐項移除，比較結果：
| 組件 | 刪除時應重點觀察 |
|---|---|
| Planner | 功能範圍是否縮小，關鍵用户路徑是否遺漏 |
| 固定 Sprint | 實現是否失去連貫性，返工是否增加 |
| 獨立 Evaluator | 真實功能缺口是否更多地進入最終產物 |
| 強制 Reset | 長任務是否再次過早收尾，交接成本是否值得 |
這些是用於分析的檢查問題，不是實驗已經證明適用於所有項目的結論。比較時還要看總耗時、調用成本和修正次數，而不能只看最終頁面是否更豐富。
我更關注這個方法本身：先説明組件承擔的職責，再用移除實驗檢查它是否仍然有效。Harness 的改進既包括增加必要反饋，也包括刪除已經不再承擔關鍵作用的流程。
幾個關鍵問題，串起規劃、獨立驗收與流程簡化h2
為什麼長期運行不等於成果質量提高？
持續性只保證工作能夠接續。需求覆蓋、設計質量和真實功能是否達標，仍需要獨立標準與驗證反饋。
Context Reset 比 Compaction 更好嗎？
沒有固定優劣。Reset 換取更清晰的起點，但依賴充分交接；Compaction 保留連續性，卻可能延續此前偏差。應根據實際失敗判斷，而不是默認每輪重置。
Evaluator 獨立運行，是否就足夠可靠？
不夠。它需要可操作標準、真實觀察和判斷校準，也要檢查其測試範圍。角色分離改善反饋結構，不保證每次評價正確。
Sprint Contract 與普通任務列表有什麼區別？
任務列表説明要做什麼；Contract 明確本輪結果、驗收路徑與完成條件。它把高層規格連接到可以實際檢查的行為。
為什麼獨立 QA 不能只看截圖？
截圖觀察視覺狀態，無法完整證明交互、接口和持久化行為。真實操作與底層狀態需要配合檢查。
取消 Sprint 是否等於放棄規劃和驗收？
不是。原文簡化版仍保留 Planner 與 Evaluator，改變的是工作切分與檢查時機，而不是取消目標與質量要求。
模型升級後，為什麼要重新檢查 Harness？
因為組件建立在舊能力邊界上。應確認原有問題是否仍存在、組件是否仍帶來收益，以及它增加的成本是否值得。