在人工智慧（AI）代理能力日益增強的時代，開發者們對其寄予厚望，期待它們能獨力承擔需要數小時甚至數天才能完成的複雜任務，例如開發一款完整的軟體應用程式。然而，這些雄心壯志卻常常在一個關鍵環節上受挫：AI代理難以在多個「上下文視窗」（Context Window）之間保持連貫的記憶與進度。這好比一場馬拉松接力賽，每位接力者卻對前一位跑者的努力一無所知，導致工作無法無縫銜接。Anthropic 工程團隊的最新研究，正是為了解決這項核心挑戰，提出了一套借鑒人類軟體工程最佳實踐的「有效控制架構」（Effective Harnesses）。
這項突破性研究的核心觀點並非等待一個擁有無限記憶的「超級模型」問世，而是將重心從單純追求模型能力，轉向系統工程與流程設計的重大典範轉移。正如奧斯卡·王爾德（Oscar Wilde）所言：「記憶…是我們每個人隨身攜帶的日記。」對於缺乏內建持久記憶的AI代理而言，外部的「日記」與「工作日誌」便成了其維繫連貫性的關鍵。
AI代理的「失憶症」：長時間運作的核心障礙
儘管諸如 Claude 3.5 Sonnet 等頂尖大型語言模型（LLMs）擁有強大的單次互動能力，但在面對「建立一個 claude.ai 的複製品」這樣的高層次、長週期指令時，它們往往會遭遇滑鐵盧。其根本原因在於上下文視窗的物理限制，導致代理在每次新的互動會話（Session）開始時，便會「失憶」，忘記之前已經完成的工作與決策。
研究歸納出幾種主要的失敗模式：
一次性完成所有工作（One-shotting）：代理傾向於試圖在單一上下文視窗內完成過多任務。這猶如要求一位工程師在沒有任何筆記或休息的情況下，獨自從頭到尾寫完整個專案。結果往往是在中途耗盡記憶體，留下未完成、無文檔的半成品，導致後續的代理實例需要花費大量時間去猜測和修復。
過早宣告完成（Premature Completion）：
當後續代理實例看到部分已實現的功能後，可能會錯誤地判斷整個專案已經結束，從而停止工作，導致專案最終未能達到預期目標。
缺乏上下文的錯誤修復：
當代理產生的程式碼存在錯誤（Bug）時，新的代理實例由於缺乏完整的歷史記錄，難以定位和修復問題，甚至可能在修復過程中引入新的錯誤。
環境不一致：代理在每次啟動時，都可能需要花費大量時間重新探索和設置開發環境，這不僅降低了效率，也增加了出錯的風險。
環境不一致：代理在每次啟動時，都可能需要花費大量時間重新探索和設置開發環境，這不僅降低了效率，也增加了出錯的風險。
Anthropic的解決方案：雙代理系統與外部記憶架構
為了克服這些挑戰，Anthropic 的「控制架構」借鑒了人類工程師輪班工作的模式。這套架構的核心思想是將代理的工作流程結構化，並強制其將所有狀態和進度持久化寫入外部系統。這構成了一個精妙的雙代理系統：
1. 初始化代理（Initializer Agent）
初始化代理僅在專案開始時運行一次，其職責在於為整個專案建立一個標準化、結構化的工作環境。它像一位經驗豐富的專案經理，在專案啟動之初就規劃好藍圖、設置好工具、並建立明確的溝通機制。其關鍵產出物（Artifacts）包括：init.sh：一個自動化腳本，用於安裝依賴、啟動開發伺服器等，確保每次編碼代理啟動時，開發環境都能保持一致且隨時可用。這就像亞伯拉罕·林肯（Abraham Lincoln）那句名言所強調的：「給我六小時砍一棵樹，我會花前四小時磨利斧頭。」充分的準備是成功的基石。
claude-progress.txt：
一個詳細的進度日誌，記錄了代理的思考過程、已完成的步驟以及後續計劃。它作為不同代理實例之間重要的「交接日誌」，確保知識的傳遞。
feature_list.json：
一份將龐大任務分解為數百個可管理子任務的詳細功能列表。所有功能的初始狀態都被標記為「failing」（測試失敗），迫使代理以測試驅動開發（TDD）的思維模式前進。
Git Repository：
建立一個初始的 Git 程式碼倉庫並進行首次提交，為後續的版本控制和進度追蹤奠定基礎。
2. 編碼代理（Coding Agent）
編碼代理是實際執行開發工作的核心。在每個後續的會話中，它都嚴格遵循一套標準作業程序（SOP），以實現增量式的開發進度：情境定位（Getting up to speed）：啟動時，編碼代理首先會閱讀 init.sh、claude-progress.txt 和 git log，以快速理解當前專案的狀態和最近的變更。這就像工程師上班後，首先檢查日誌、閱讀最新的提交訊息，以了解前一個班次的工作進度。
任務選擇：代理會讀取 feature_list.json，選擇一個狀態仍為「failing」的高優先級功能來處理。這種明確的、單一的目標設定，有效地避免了「One-shotting」的傾向。
增量開發（Incremental Development）：代理會專注於實現這一個選定的功能，避免同時處理多個任務，確保每個步驟都是可控且可驗證的。
自我驗證（Self-Verification）：為了確保功能的正確性，代理會利用如 Puppeteer（透過 Anthropic 的 MCP 協議）等瀏覽器自動化工具進行端到端（End-to-End）測試，模擬真實用戶操作，確認功能不僅能運行，而且 UI/UX 也符合預期。這超越了簡單的單元測試，提供了一個更全面的驗證機制。
狀態持久化（State Persistence）：完成並測試通過後，代理會執行以下關鍵操作：Git Commit：將程式碼變更提交到 Git，並撰寫詳細的提交訊息，為版本歷史留下清晰的記錄。
更新進度日誌，在 claude-progress.txt 中記錄已完成的工作，供下一個代理實例參考。
更新功能列表，將 feature_list.json 中對應功能的狀態從「failing」修改為「passing」。
核心設計理念，工程化AI的自主性
Anthropic 的這項研究不僅提供了一個實用的解決方案，更揭示了構建可靠AI代理背後的深層次設計理念：狀態的具象化（Reification of State）：此架構的核心是將代理腦中的抽象「專案進度」轉化為外部、持久化、機器可讀的文件（JSON、TXT、Git Log）。這有效地解決了模型本身的無狀態（Stateless）問題。值得一提的是，研究團隊選擇 JSON 而非 Markdown 來儲存功能列表，是因為其嚴格的語法結構能有效防止模型在編輯時意外破壞格式。
類測試驅動開發（TDD-like Workflow）：
透過預先生成包含數百個「failing」測試的功能列表，系統強制代理進入「紅燈（失敗） -> 綠燈（通過） -> 重構」的循環。這為代理提供了清晰、單一的目標，有效防止了其「過早宣告完成」的傾向，並引導其有條不紊地推進開發。
標準作業程序（SOP）的重要性：
為編碼代理定義一套嚴格的啟動和結束流程，如同為AI員工制定了詳盡的工作手冊。這確保了不同代理實例之間行為的一致性和可預測性。在複雜的長期任務中，標準化流程對於維護秩序和效率至關重要。
環境即上下文（Environment as Context）：
對於長週期任務而言，最有價值的上下文並非將數千行的對話歷史塞入 Prompt，而是提供一個結構化、自我解釋的工作環境。代理透過讀取文件和日誌來獲取上下文，遠比依賴有限的記憶體更高效。
工具使用與自我驗證：
強調代理必須具備使用外部工具（如 Puppeteer）來驗證其工作成果的能力。這超越了簡單的程式碼生成，邁向了更高階的自主解決問題能力，讓代理能夠像人類工程師一樣，不僅能「寫」也能「測」。
未來方向與對開發者的啟示
Anthropic 指出，當前的架構主要圍繞一個通用的編碼代理。未來的研究方向包括：多代理協作（Multi-Agent Systems）：探索使用專門化代理團隊，例如由負責編寫和執行測試的「測試代理」、驗證功能是否符合需求的「QA代理」、以及專門清理和優化程式碼的「重構代理」共同協作。這呼應了亞里士多德（Aristotle）的哲學思想：「整體大於部分之和。」透過分工協作，AI系統的整體效能有望超越單一通用代理的極限。
領域泛化（Domain Generalization）：將這套在 Web 開發中驗證成功的框架，應用到其他需要長週期思考和執行的領域，如科學研究、金融建模、法律文件分析等，拓寬其應用場景。
這項研究為構建實用、可靠的AI代理系統提供了清晰的藍圖。它證明了當前階段的關鍵突破口不在於等待一個擁有無限上下文的「超級模型」，而在於設計精良的系統工程和流程控制。通過為AI代理建立類似於人類最佳實踐的 Scaffolding，開發者可以讓現有模型的能力在複雜、長期的任務中得到極大擴展，使其表現遠超單次交互的極限。這不僅是技術上的飛躍，更是AI系統設計理念的一次深刻變革。
留言
張貼留言