給 Claude 一個足夠大的任務，它就會做到一半就放棄，自以為已經完成了。工作根本還沒做完，只是它不記得自己開始過。
一個 Agent 處理長時間任務的方式，跟你想像的不一樣。它採輪班制。
想像一個軟體專案，由輪班的工程師們負責，但每個新來的工程師對上一班發生的事完全沒有記憶。這不是比喻 Agent 的感受，而是它們機械上的本質。上下文視窗有限，大多數真正的工作無法塞進單一個視窗，所以 Agent 必須在離散的會話中工作——而每次新的會話，都對上一次的會話毫無記憶。
Anthropic 確實做了這個實驗，並公佈了哪些地方出了問題。這部分值得一讀，因為這不是某個部落客說這個工具很弱，而是打造 Claude 的團隊在記錄 Claude 在哪裡失敗。
為什麼一個視窗無法完成任務
給一個前沿的程式碼模型一個高階提示——"建立一個 claude.ai 的複製品"——讓它在多個上下文視窗中循環執行，結果它無法產出一個可以運作的應用程式。不是偶爾，而是必然。而且這還是 Opus 在 Anthropic 自己的 Agent 框架上運行的結果，啟用了上下文壓縮，整個設定都是為了讓它持續運作。
它以兩種特定的方式失敗，而這兩種方式都是換班交接的問題。
第一種：Agent 試圖一次做完所有事情。它試圖在單一視窗中一次性完成整個應用程式，然後在實作某個功能到一半時就用光了上下文，會話結束，留下一個半成品且沒有文件的東西。下一班的人來接班，看到一個不是自己造成的爛攤子，必須猜測之前發生了什麼事。結果它整個會話時間都花在讓基本應用程式再次能運作，而不是推進進度。
第二種問題在稍後出現，當某些功能已經存在時。一個新的 Agent 環顧四周，看到已經取得了實質進展，於是就斷定整個事情已經完成了。但其實沒有——一半的功能根本沒被建立，也沒有人記錄下來哪些功能完成了。這班人就這樣交差了，沒有檢查清單。
這兩種失敗都有同樣的根源。交班的人沒有留下任何東西，所以接班的人只能盲目操作。解決方案不是更聰明的模型，而是交班的人在打卡下班前寫下了什麼。
交班的人該寫下什麼
Anthropic 得出的解決方案有兩個部分：一個是在任何工作開始之前就設定好網站的 Agent，然後是那些一個會話接一個會話來推進進度的輪班工人。
設定 Agent 只執行一次，就在最開始的時候。它的全部工作就是讓環境處於一個狀態，使得未來每一班的人都知道「完成」是什麼樣子。它寫下的關鍵部分是一個功能清單——一個結構化的檔案，詳細說明完成後的應用程式需要做哪些事情。
對於 claude.ai 的複製品來說，這意味著超過 200 個功能。像是「用戶可以開啟一個新聊天、輸入查詢、按下 Enter 鍵，然後看到回應」。每一個功能在開始時都被標記為失敗。每個條目大致如下：
1{2 "description": "新聊天按鈕建立一個全新的對話",3 "steps": ["點擊「新聊天」", "驗證全新的對話", "檢查歡迎狀態"],4 "passes": false5}
每個條目上的「passes: false」就是重點。這是一個未勾選的方框，而且有 200 個。
這個失敗清單，就是阻止 Agent 過早宣告勝利的東西。一班人無法環顧四周就斷定工作完成了，因為那裡有個檔案，清清楚楚地寫著 200 個未勾選的方框。工作在第一行程式碼被寫出來之前就已經定義好了。
有一個小細節說明了這必須有多小心：他們使用了 JSON 格式來儲存這個檔案，而不是 Markdown。原因是模型比較不會悄悄改寫或刪除一個 JSON 檔案，但卻可能對 Markdown 檔案這麼做。而圍繞這個檔案的指令也刻意寫得很直接——刪除或修改測試是不可接受的，因為刪除一個測試，就是讓一個功能默默地消失。這班人可以勾選一個方框，但不能擦掉一個。
桌上的筆記
設定好工作只是成功的一半。另一半是確保每一班的人都把環境整理得夠乾淨，讓下一班的人可以順利接手。
有兩件事可以做到這點。Agent 將它的工作提交到 Git，並附上一個真實的訊息描述變更了什麼，同時它還會寫一個簡單的進度檔案——一個記錄已完成事項的持續更新日誌。這個日誌，連同 Git 歷史記錄，能讓一個全新的 Agent 在剛開始時，幾分鐘內就了解狀況，而不是花一個小時反向工程。
Git 在這裡還有另一個作用。當一班人做出了糟糕的變更，下一班人可以回滾到最後一個可運作的版本，而不是試圖釐清造成的混亂。進度檔案告訴我們現在在哪裡，提交歷史記錄就是復原按鈕。
而「乾淨」有特定的意義。它指的是那種你可以放心合併到主分支的程式碼——沒有重大錯誤、有條理、有文件。不是「技術上來說我有所進展」。標準是：下一個人可以開始一個新的功能，而不需要先清理你的爛攤子。
下一班人如何上工
把這兩個東西準備好，那麼每一班人都以同樣的方式開始。在接觸任何新東西之前，Agent 會執行一個固定的開場例行程序來掌握狀況——就像一個好的工程師接手一個很久沒看的專案時會做的事情。
1執行 pwd 查看你目前所在的目錄——那是你唯一可以編輯的地方2閱讀進度檔案和 Git 日誌，了解最近發生了什麼事3閱讀功能清單，挑選最高優先級但尚未完成的事項4啟動應用程式並執行基本檢查，確認核心功能仍然正常運作5然後，才開始進行建構
第四個步驟的重要性比看起來還大。在撰寫任何一個新功能之前，Agent 會啟動應用程式並確認基本功能仍然正常運作——開啟聊天、發送訊息、得到回應。如果上一班的人留下了什麼壞掉的東西，這一步會立刻發現，避免新的一班在一個壞掉的基礎上疊加新工作，讓情況變得更糟。
這就是整個訣竅，簡單到幾乎無聊。交班的人記下它做了什麼以及還剩下什麼。接班的人在動手之前先閱讀這些資訊。交接就是一切。
你的長期任務也需要輪班
這些其實都不是關於建立網頁應用程式。Anthropic 用程式碼來測試，是因為程式碼容易驗證，但其底層的模式，與你交給 Agent 的每一個長期任務的模式是一樣的。
任何無法容納在單一視窗內的工作都需要輪班。一章一章地寫一篇長篇報告。在十幾個聊天對話中執行一個研究專案。花好幾天時間進行一個大型分析。每次你在同一個任務上開始一個新的會話，就等於一個新的工人在報到，對上一次的任務毫無記憶——而如果你沒有留下交接資訊，它就從猜測開始。
所以，留下交接資訊吧。在一個長會話結束前，讓模型寫下完成了什麼、還有哪些待辦事項、以及下一次會話應該優先處理什麼。把這份筆記放在它進來時會讀到的地方。這就是一個專案能每次會話都向前推進，還是不斷重複建構同一件事的關鍵差異。
今晚和明天都是用同樣的模型。唯一改變的，是明天的會話是摸黑上工，還是帶著昨晚的筆記開始。
重點從來不是這班人有多聰明，而是它為下一班的人留下了什麼。
更多類似的深入分析 - https://t.me/+xYv1MgmIuds5YTli
