隨著模型能力不斷增強，AI Agent 正在從「單輪對話助手」向「能夠連續運行數小時甚至數天的自主系統」進化。然而，工程實務一再證明：讓一個 Agent 在長時任務中持續、穩定地推進，遠比想像困難。上下文視窗有限、會話之間沒有記憶、反覆返工、誤判進度等問題，會讓一個複雜專案在數輪執行後徹底失控。
就在昨天，Anthropic 發布了一套非常重要的工程方案，專門針對這些挑戰而設計：基於「Initializer Agent + Coding Agent」的雙 Agent 架構。
它的意義在於，它不是透過更大的模型、更長的上下文來對抗問題，而是透過一種工程化的工作流程設計，確保 Agent 即使在「失憶」的多視窗條件下，也能像人類工程師一樣一步步推進任務。
目錄
• 為什麼單 Agent 架構無法勝任長時任務？
• 雙 Agent 架構：讓 Agent 真正「像一個工程團隊工作」
• Initializer Agent：一次性奠定整個專案的工程基礎
• Coding Agent：每一輪只做一件事，但把它做好
• 雙 Agent 如何解決長時任務中的結構性難題？
• 未來的方向：從雙 Agent 到「Agent 工程團隊」
為什麼單 Agent 架構無法勝任長時任務？
要理解雙 Agent 架構的價值，必須先理解單 Agent 為什麼會失敗。
一個長時任務，例如建構一個完整的網頁應用程式，往往涉及數十到數百個功能、多個模組、持續的除錯與驗證。而目前的模型雖然強大，但每一輪仍然必須在有限的上下文中工作。這意味著，每一次執行都是一次「記憶重置」。模型需要在短時間內重新理解專案、評估狀態，並決定下一步行動。
在這種情況下，單 Agent 容易出現兩類典型問題：
• 第一類問題是試圖「一口气完成所有事情」。模型看到使用者需求後，會選擇實施一個非常激進的策略：直接開始大規模程式碼編寫，直到上下文耗盡為止。但這種策略的後果是，它只能寫出「半截程式碼」，不僅未完成、也未記錄、沒有測試，下一輪 Agent 接手時完全無法判斷目前專案進展，從而花費大量時間摸索現場。
• 第二類問題則剛好相反：模型在看到部分成果後，誤以為專案已經完成。由於缺乏清晰的目標清單與結構化任務定義，模型可能在看到一些 UI、一些 API 或一些回應後，得出「功能齊全」的誤解，進而直接終止任務。這種「過早宣布完成」的情況非常常見。
也就是說，Anthropic 認為，目前 AI Agent 無法長時間穩定運行的核心問題不在模型能力，而在缺乏一種能夠跨上下文繼承任務邏輯的結構化工作方式。
為此，Anthropic 提出了雙 Agent 架構。
雙 Agent 架構：讓 Agent 真正「像一個工程團隊工作」
Anthropic 的解決方案非常工程化：不是讓一個 Agent 解決所有事情，而是將長時任務拆分為兩種角色——一個負責奠基，一個負責迭代。
這個方法和此前大家逆向 Claude Code 非常相似：
其核心思想：
Claude Code 的核心邏輯建立在一個單一的主迴圈之上。所有歷史訊息都被維護在一個扁平的訊息清單中，而不是層層嵌套的多代理對話樹。
這次是 Anthropic 官方解密這個雙 Agent 架構，即 Initializer Agent 和 Coding Agent。
Initializer Agent：一次性奠定整個專案的工程基礎
Initializer Agent 的職責集中在第一次運行，它更像是一位「首席架構師」。
它不會立即進入程式碼編寫，而是根據使用者給出的高層需求，將專案轉換為一個可長期維護的工程結構。
這包括三項關鍵內容：
第一，生成一個「可操作的需求體系」。
Initializer 不會讓模型自己猜哪些功能是必要的，而是將使用者需求分解為一份詳盡的 JSON 結構的功能清單。每項功能都有描述、步驟和驗收條件，並全部標記為「未完成」。這使得 Coding Agent 在未來的所有的會話中都能明確自己的目標，不會誤判進度，也不會跳過必要環節。
第二，創建狀態記錄機制。
Initializer 會寫入一個 progress 檔案，記錄專案結構、重要說明和之後用於交接的上下文。它同時建立 git 儲存庫，讓每個迭代都能被提交、恢復和追蹤。狀態記錄機制使得未來的 Agent 不必猜測，而是能夠基於事實繼續推進工作。
第三，提供一個標準化的啟動腳本。
Initializer 還會生成一個 init.sh，用於啟動開發伺服器並進行基礎測試。這使得後續所有的會話都能迅速驗證目前環境是否健康，從而降低「接手時發現專案已壞」的風險。
這樣，一個乾淨、結構化且可持續繼承的工程現場就奠定完成了。
Coding Agent：每一輪只做一件事，但把它做好
在完成初始化之後，專案的推進交給 Coding Agent。它的工作方式不再是「盡可能寫更多程式碼」，而是「每一輪修改都要增量、可靠、可驗證」。
Coding Agent 的啟動流程非常像工程師上班的第一小時：
它會先檢查目前目錄結構，閱讀 git 記錄，查看 progress 檔案，運行 init.sh，並進行一次基本的端到端測試。它不是為了完成新功能，而是為了確認「現場是否正常」，避免在未知狀態下開始工作。
接下來，Coding Agent 會從功能清單中選擇一個未完成的功能，閱讀它的驗收步驟，然後進入真正的實作。
關鍵在於：
它每一輪只做一件事情。
且在程式碼編寫完成後，它必須自行完成端到端測試，例如使用 Puppeteer 驅動瀏覽器，像真正使用者那樣操作應用程式：開啟頁面、點擊按鈕、輸入內容、觀察結果。
功能通過後，它會將 "passes": true 寫回 JSON 清單，並提交一次 git commit，同時更新 progress 檔案，讓下一輪 Agent 一眼就能理解變化。
這種節奏雖然緩慢，但極其可靠。
它將「無人監督的長時任務」轉換為「每輪可驗證的開發迭代」，從而大幅提升任務的穩定性。
雙 Agent 如何解決長時任務中的結構性難題？
這套方案之所以有效，是因為它從工程結構層面解決了單 Agent 無法克服的問題。
在這裡，我們稍微總結一下：
難題：缺乏任務目標體系；單 Agent 的表現：容易誤判已完成；雙 Agent 的行為：功能清單定義完整需求空間。
難題：無法繼承狀態；單 Agent 的表現：每輪重頭理解專案；雙 Agent 的行為：progress + git 確保上下文可讀。
難題：容易寫到一半崩潰；單 Agent 的表現：爆上下文，留下爛尾；雙 Agent 的行為：Coding Agent 每輪只做一項功能。
難題：缺乏真實測試；單 Agent 的表現：程式碼可運行≠功能完整；雙 Agent 的行為：自動化 e2e 測試確保真實效能。
難題：環境可能已損壞；單 Agent 的表現：下一輪無法判斷為何損壞；雙 Agent 的行為：init.sh 的統一自檢流程使問題可見。
本質上，這是第一次有人把「軟體工程的工作流程」正式編碼進 Agent 架構中。
未來的方向：從雙 Agent 到「Agent 工程團隊」
Anthropic 的實作，是一個重要的基點，但遠沒有結束。
他們提到，下一步可能會著手將這些角色進一步拆分為：
• 測試 Agent
• QA Agent
• 程式碼清理 Agent
• 文件 Agent
• 效能 Agent
從而形成真正意義上的「Agent 工程團隊」。
這種趨勢值得高度關注，因為它可能改寫未來的軟體開發方式。
這次的 Anthropic 推出的方案不是模型能力的提升，而是工程方法論的突破。結合此前 Claude Skills 等，Anthropic 正在試圖用工程方法來解決實際問題。不過也有人批評說，Anthropic 無非是把實際過程遇到的問題寫出來，甚至是之前用 MCP 創造問題，現在再來解決。
不過，可能本來 AI Agent 的發展就不是一帆風順，會有各種問題，所以即使是這樣的領先企業可能也有很多坑要來回踩。