Anthropic 提升 AI 效率：兩階段架構如何讓 Claude 代理程式完成「長期複雜任務」
Anthropic 採雙代理程式，解決 AI 跨會話健忘問題，像輪班工程師般，讓複雜專案穩定推進
為什麼 AI 助理會「健忘」？長期任務的大挑戰
隨著 AI 科技越來越厲害，我們開始要求 AI 助理（例如 Claude）去執行一些複雜的任務，這些任務可能需要花費好幾個小時，甚至好幾天的時間才能完成。
AI 在處理這類「長期任務」時，面臨一個核心難題：記憶限制。
像換班工程師一樣，每次都從零開始
目前的 AI 模型必須在「離散的會話」（discrete sessions）中工作，就像軟體專案由多位輪班工程師負責一樣。由於 AI 每次能處理的資訊量（稱為「上下文窗口」, context window）是有限的，複雜的專案通常無法在單次會話中完成。
想像一下，一個軟體專案由輪班的工程師負責，但每一位來接班的工程師，都完全不記得上一位工程師做了什麼事。這就是 AI 助理在跨越多個上下文窗口工作時所遇到的挑戰。即使使用了上下文管理功能（如「壓縮」, compaction），AI 仍然難以持續有效地工作。
AI 容易犯的兩大錯誤
當 AI 試圖在多個會話中完成一個複雜的專案時，經常會出現兩種失敗模式：
錯誤一：一次想做太多事，導致半途而廢
AI 助理常會試圖「一步到位」（one-shot）地完成整個應用程式。這樣做的結果是，模型往往在實作到一半時，就因為上下文用盡而「忘記」了正在做的事情，留下了半成品且沒有文件紀錄的程式碼。當下一位 AI 助理開始工作時，它必須花費大量的時間去猜測前一位做了什麼，並嘗試讓基礎的應用程式重新運作。
錯誤二：進度剛開始，就宣布大功告成
另一個失敗模式發生在專案後期：當 AI 助理看到已經有一些功能完成後，它可能會誤以為整個工作已經結束了。
Anthropic 的聰明解法：兩階段工作法
為了解決這些問題，Anthropic 開發了一套雙重解決方案，讓 Claude 代理程式工具包（Claude Agent SDK）能夠有效地跨越多個上下文窗口工作。這個方法將問題分解成兩個部分。
第一階段：初始化代理程式 (Initializer Agent)
在第一個執行環節，會使用一個專門的提示詞來啟動初始化代理程式。
初始化代理程式的任務是為所有功能奠定基礎，讓後續的代理程式可以一步一步、逐個功能地工作。
它會設定初始環境，包括：
- 寫下功能清單： 為了避免 AI 試圖一次完成整個應用程式或過早宣布專案完成，初始化代理程式會根據使用者提供的高階提示，撰寫一份功能需求的全面文件。例如，在一個模擬
claude.ai的專案中，清單可能包含超過 200 個功能。 - 設定初始狀態： 這些功能在一開始都會被標記為「未通過」（failing），這樣後續的編碼代理程式就會有一個清晰的藍圖，知道什麼才是完整的功能。
- 建立關鍵文件： 它會建立一個
init.sh腳本來設定環境，一個claude-progress.txt文件來記錄所有代理程式所做的工作，以及一個初始的 Git 提交（commit）紀錄。
💡 為了確保 AI 不會不當地修改或覆蓋功能清單，實驗發現使用 JSON 格式比 Markdown 格式更為可靠。
{
"category": "functional",
"description": "New chat button creates a fresh conversation",
"steps": [
"Navigate to main interface",
"Click the 'New Chat' button",
"Verify a new conversation is created",
"Check that chat area shows welcome state",
"Verify conversation appears in sidebar"
],
"passes": false
}
第二階段：編碼代理程式 (Coding Agent)
每一次後續的工作會話，都由編碼代理程式負責。它的任務是穩步地推進工作進度，並在每個會話結束時，為下一班 AI 留下清晰的「文物」（artifacts）。
聚焦於增量進度 (Incremental Progress)
編碼代理程式被要求一次只專注於處理清單上的一個功能。這種增量方法對於解決 AI 傾向於一次做太多事情的問題至關重要。
保持環境的「整潔狀態」
一旦完成了程式碼更改，AI 必須將環境保持在「整潔狀態」（clean state）。所謂的「整潔狀態」指的是程式碼應該是適合合併到主分支的品質：沒有重大錯誤、程式碼有條理且文件完善，讓下一位開發者可以輕鬆開始新功能的工作，而不需要先清理殘局。
為了實現這一點，AI 會將進度提交到 Git，並附上具體的提交訊息，同時在進度文件中寫下總結。這讓 AI 能夠利用 Git 來恢復到程式碼的工作狀態，或是復原錯誤的程式碼更改。這些做法也提高了效率，因為 AI 不必浪費時間去猜測前一位做了什麼。
確保程式碼「沒壞」：高效的測試與啟動流程
有效的軟體工程師每天都會做的事情，為 Anthropic 如何設計 AI 代理程式的實踐提供了靈感。
每次啟動前，先確認專案無誤
在每次會話開始時，編碼代理程式會被要求執行一系列步驟來「掌握狀況」：
首先，AI 會執行像 pwd 這樣的基本指令來查看它正在工作的目錄。接著，它會閱讀 Git 紀錄和進度文件，以了解最近的工作內容。
然後，AI 會讀取功能清單文件，並選擇下一個最高優先級、尚未完成的功能來著手工作。
為了確保它能快速識別應用程式是否被留在了損壞的狀態，AI 會執行以下動作：
它會要求初始化代理程式寫一個 init.sh 腳本，用來啟動開發伺服器。然後，在實作新功能之前，AI 會先運行基本的端對端測試。
在模擬 claude.ai 的專案中，這意味著代理程式總會先啟動本地開發伺服器，然後使用測試工具來執行「開始一個新聊天、發送一條訊息、接收回應」的流程。這確保了 Claude 可以快速發現是否有任何現存的 Bug，並立即修復它們。如果這時候它直接開始實作新功能，問題很可能會變得更糟。
不再假裝完成：強制端對端測試
Anthropic 觀察到的另一個主要失敗模式是：Claude 傾向於在沒有適當測試的情況下，就將功能標記為完成。即使它進行了單元測試（unit tests），也可能無法識別出功能是否在實際的端對端流程中正常運作。
因此，現在明確要求 Claude 像人類使用者一樣，使用瀏覽器自動化工具（例如 Puppeteer MCP 伺服器）來進行所有的測試。透過提供這些測試工具，AI 能夠識別並修復那些光從程式碼中看不出來的 Bug，大大提高了效能。同時，代理程式被嚴格指示，只有在經過仔細測試後，才能將功能清單中的狀態標記為「通過」（passing）。
💡 總結：
這種兩階段工作法就像把一棟大樓的建造任務交給 AI。
- 初始化代理程式是建築師，它先畫好藍圖（功能清單）和地基（初始環境）。
- 接著，編碼代理程式就是一位輪班、有紀律的工匠，他們每次只砌一塊磚（一個功能），每天收工前都會把工地整理乾淨（乾淨的 Git 提交和進度紀錄），並在開工前先檢查地基是否穩固，確保工作持續且穩定地向前推進。
未來展望：下一步的 AI 代理程式
雖然 Anthropic 提出的兩階段解決方案（初始化代理程式與編碼代理程式）已經有效地證明了 AI 能夠在跨越多個上下文窗口的長期任務中取得增量進展，但這項研究仍存在一些開放性的問題與未來的發展方向。
專業分工：多代理程式架構的可能性
一個值得探索的未來方向是：單一的、通用型編碼代理程式是否是最佳的解決方案。
目前的研究將工作分解為兩大核心步驟（初始化與編碼），但未來的架構或許可以透過多代理程式（multi-agent architecture）來實現更優異的性能。
這意味著可以建立專業化的代理程式，例如：
- 測試代理程式（A testing agent）：專門負責執行和驗證程式碼的正確性。
- 品質保證代理程式（A quality assurance agent）：確保程式碼符合標準。
- 程式碼清理代理程式（A code cleanup agent）：專注於提升程式碼的整潔度和可讀性。
透過將軟體開發生命週期中的子任務交給專門的代理程式處理，或許能讓整體的工作流程更加有效率和精確。
應用範圍的拓展
目前的示範和研究主要針對全端網頁應用程式開發（full-stack web app development）進行了優化。
Anthropic 認為，未來的方向是將這些長期任務的解決方案推廣到其他領域。這些在長期代理程式中學到的經驗教訓，很可能可以應用於其他需要耗費長時間的代理程式任務，例如在科學研究或金融建模等領域所需的長期自主性任務。
💡 簡而言之，未來的 AI 助理可能會像一支專業的團隊。 現在的解決方案是讓一個全能工程師（編碼代理程式）輪班工作；但未來，這個團隊可能會細分成專門的測試員、品管員和架構師，讓 AI 系統能夠在更複雜、更廣泛的領域中，安全且自主地完成長期任務。
