Harness 讓長任務編程更像真開發

以前的智能體編程總在點頭，現在 Harness 讓它能自己跑長任務。

我折騰 AI 編程工具很久了。代碼補全、對話式改 code、自己修 bug，我都試過。短任務看起來很會，真碰到長一點的工作流就開始飄：前後不一致、改到一半忘了目標、UI 做得像 demo，根本不能交付。我最煩的不是它不會寫，而是它總像個只會附和的實習生，問什麼都說可以，真讓它自己扛一段時間就露餡。

這次讓我重新看這件事的，是 Anthropic 的工程文章 Anthropic News，裡面談長時間運行的智能體編程和前端設計品質。作者是 Anthropic Labs 的 Prithvi Rajasekaran。原文我沒看到公開標註的觀看數或書籤數，所以我不亂寫數字。這篇更像工程筆記，講的是怎麼把一個會聊天的模型，改造成能在長任務裡保持方向感的工作單元。相關討論也被轉到 知乎。

我最在意的，不是它會不會寫，是它會不會撐住

Anthropic 這篇工程文章談的是長時間運行的智能體編程，以及前端設計品質怎麼往上拉。

翻譯一下就是：他們關心的不是一次性生成一段 code，而是讓智能體在一段持續時間裡完成一整串動作，而且中間不丟目標、不亂改方向、不把自己繞暈。這個差別很大。短 code 生成像答題，長任務編程更像做專案。你得先讀 repo，再找入口，再改 code，再跑測試，再看失敗，再回頭修，最後還得把改動收束成一個能合併的 patch。

我以前也踩過這個坑。給模型一個「幫我重構這個頁面」的指令，它前面兩步都對，到了第三步開始亂加抽象層，第四步又把樣式拆散。它不是不會做，而是沒有持續工作的骨架。Harness 這類東西的價值，就在於把「持續工作」變成流程，而不是祈禱模型自己記得住上下文。

實操上，我現在會先把長任務切成三到五個檢查點。每個檢查點都要有可驗證產物，像文件列表、diff、測試結果。只要你不把「完成」定義成一次回覆，模型就比較不容易胡來。

• 把長任務切成 3 到 5 個檢查點。
• 每個檢查點都要求可驗證產物，比如文件列表、diff、測試結果。
• 不要讓模型在沒有回饋的情況下連續做太多步。

Harness 真正幹的事，是把智能體關進流程裡

很多人聽到 AI coding tool 就以為重點在模型本身。其實不是。模型負責生成，Harness 負責約束。沒有外殼的模型，像一個很會說話但沒有工位的人；有了 Harness，它才像被塞進一個明確的工作台：輸入是什麼、可以呼叫什麼工具、什麼時候停、什麼時候回看、什麼時候交差，全都寫清楚。

我對這種設計是有偏愛的，因為我見過太多「全能代理」最後變成「全亂代理」。你給它開放式工具權限，它會一會兒去搜文件，一會兒去改配置，一會兒又開始寫測試，結果每一步都像在做正確的事，但合起來沒有閉環。Harness 的思路更像是把權限和節奏都收緊，讓它只能在你允許的軌道裡跑。

這點和 Claude 這類模型的產品化方向也很一致。模型越強，越不能讓它自由放飛。真實專案裡，最值錢的不是「它能想到很多」，而是「它能穩定做完」。

實操寫法很簡單：給你的 agent 加三個硬限制。第一，工具白名單，只給它必要的讀寫權限。第二，步數上限，防止無限自嗨。第三，狀態回寫，每做完一步都把當前目標、已完成項、待辦項寫回去。這樣哪怕它中途跑偏，你也能把它拉回來。

• 工具只開讀 repo、改文件、跑測試這幾類。
• 每輪輸出都要求包含「我做了什麼 / 下一步是什麼」。
• 把失敗也當成狀態的一部分，不要讓它默默吞掉。

長任務裡最怕的不是錯，是忘

智能體編程最常見的問題，不是某一行語法錯了，而是它忘了自己為什麼開始。前一輪還在修登入頁，下一輪突然開始重構整個路由層。你看 log 會很氣，因為每一步都像是合理推理，最後卻把專案帶進歪路。

Anthropic 這類實踐背後的重點，其實就是「記憶不是聊天記錄，記憶是工作狀態」。這句話我自己吃過虧以後特別有感。以前我讓模型做一個兩小時的前端修復，它中間把某個按鈕文案改了三次，每次都和上一次衝突。不是它記性差，而是我沒給它一個足夠明確的工作狀態檔。沒有狀態檔，模型只能靠上下文猜，猜著猜著就開始編。

也就是說，你要給 agent 一個能持續更新的任務板，而不是一段越來越長的 prompt。任務板裡應該有目標、約束、當前進度、已驗證項、未驗證項、風險點。這樣它每次回到工作台時，都知道自己在做哪一塊，而不是重新開機。

我現在最常用的做法，是把長期記憶外置成檔案，比如 task.md 或 state.json。每輪執行前先讀它，執行後再寫回去。這樣模型不是靠猜，而是靠狀態推進。

前端品質這件事，靠生成器自己救不回來

原文提到前端設計品質提升，我一點都不意外。因為這恰好是 AI 編程最容易翻車的地方。代碼能跑，不等於 UI 能看。元件能渲染，不等於資訊層級清楚。頁面能打開，不等於互動像樣。

我見過太多工具把「生成前端」理解成「把元素堆上去」。結果就是按鈕太多、間距亂、字體大小像抽籤，最後你還得自己收拾。Harness 如果真要在前端場景裡有用，就不能只看 code 正確，還得看設計約束是否被持續執行。也就是說，它不是只管「寫出來」，還得管「長得像樣」。

這部分我最認同的地方是：前端不是一次性生成物，它是迭代產物。你需要在每輪改動裡檢查布局、層級、響應式和可讀性。否則模型只會把設計當成 CSS 語法題。

實操寫法：給前端 agent 加一套審美檢查清單。別笑，這比你想像得有用。比如主次按鈕是否清楚、標題層級是否一致、空狀態是否友好、手機版是否還能讀。然後讓 agent 在每輪改動後自檢一次，再進入下一步。

• 把設計約束寫成可執行清單，而不是口頭要求。
• 讓模型在改 code 後輸出「視覺檢查結果」。
• 如果有截圖或預覽工具，就把它納入回路。

我更看重的是反覆校準，不是一次生成

我現在對 AI coding tool 的判斷標準已經變了。以前我會問：它會不會一次寫對？現在我更關心：它能不能在失敗後自己回到正軌？這就是長任務智能體和普通生成器的分水嶺。前者允許你糾偏，後者只會繼續往前衝，衝到牆上還覺得自己完成了。

Anthropic 這篇實踐讓我確認了一件事：真正有價值的系統，不是讓模型少犯錯，而是讓錯誤能被及時發現、及時修正。Harness 的意義就在這裡。它把生成變成執行、檢查、修正的循環。這個循環一旦立住，模型就不再只是回答問題，而是在做事。

我自己在專案裡最常用的做法，就是把每一步都做成可回滾的最小改動。別讓 agent 一口氣改十個文件。先改一個點，跑一次驗證，確認沒歪，再繼續。聽起來慢，但這才是能交付的速度。你省掉的是返工，不是時間。

實操寫法：你可以要求 agent 每次只提交一個可審查 patch。patch 裡必須包含改動目標、影響文件、驗證結果、下一步建議。這樣你審它的時候，不是在審一坨大泥，而是在審一小塊明確變化。

這類工具最後拼的，是工程紀律，不是口才

AI coding tool 現在很容易陷入口才競賽。誰都能 demo「我只說一句話，它就寫完了」。但真正進 repo 以後，你會發現口才沒用，工程紀律才有用。Harness 這種思路，本質上就是把工程紀律重新塞回 agent 裡。

我很喜歡這條路，因為它誠實。它承認模型會飄、會忘、會過擬合局部目標，所以它不指望模型天生自律，而是用流程逼它自律。說白了，這才像 software engineering。軟體工程從來不是相信某個元件永遠正確，而是設計系統讓錯誤不至於擴散。

如果你準備自己做一個類似的 agent workflow，別先問怎麼讓它更強，先問怎麼讓它更可控。只要你把可控性做出來，模型能力上升時，收益才會被真正吃到。否則能力越強，翻車越快。

實操寫法：把你的 agent workflow 寫成標準作業流程。每次任務都按同樣節奏走：理解問題、列計畫、執行一小步、驗證、記錄狀態、繼續。別把它當聊天機器人，把它當需要簽字交接的同事，會省很多事。

可抄的模板

# Long-running coding agent harness template

## Goal
- What I am trying to change:
- Why it matters:
- Definition of done:

## Constraints
- Allowed tools:
- Forbidden actions:
- Files that must not be changed:
- Performance / design / UX constraints:

## Current state
- Repo / app context:
- Relevant files:
- Known issues:
- Risks:

## Execution loop
1. Read the current state file.
2. Inspect the codebase or UI only within the allowed scope.
3. Propose the next smallest step.
4. Make one change.
5. Run the smallest useful validation.
6. Write back the updated state.
7. Stop and report.

## Status file format
- goal:
- completed:
- in_progress:
- blocked:
- next_step:
- validation:
- notes:

## Prompt to the agent
You are working on a long-running coding task.
Follow the execution loop exactly.
Do not expand scope.
Do not make unrelated refactors.
After each step, update the status file.
If validation fails, explain the failure, update the state, and stop.

## Frontend quality checklist
- Layout hierarchy is clear
- Primary action is obvious
- Spacing is consistent
- Copy is readable
- Mobile layout is acceptable
- Empty / loading / error states are handled
- No unnecessary visual noise

## Review output format
- What changed:
- Why I changed it:
- What I validated:
- What remains:
- Risks / follow-up:

這份模板不是為了讓模型更像人，而是讓它更像一個能交接的工程任務。你把目標、約束、狀態、循環、審查標準都寫死，agent 才不會一邊做一邊發散。尤其是長任務和前端工作流，這套東西比空談 prompt 優化有用得多。

如果你要把它接到自己的專案裡，我建議先從最小閉環開始：一個狀態檔、一個執行循環、一個驗證步驟。別一上來就做全自動。全自動通常是全失控的委婉說法。

原始來源是 Anthropic News，相關討論可看 這條知乎轉載。我上面拆的是 Anthropic 的工程思路，不是原文逐句復述；模板部分是我按這個思路整理出來的可直接使用版本。