Anthropic 有效的長時程代理人架構 (Harnesses)

Anthropic 開發了一種專門的代理人架構，用以解決 AI 代理人在跨越多個離散工作階段時出現的「記憶喪失」和進度不一致的問題。透過將工作流程拆分為初始化代理人 (initializer agent) 與編碼代理人 (coding agent)，開發者可以讓 Opus 4.5 等模型完成超出單一上下文窗口限制的複雜、生產級專案。

長時程代理人的挑戰

標準的代理人架構在處理複雜的多工作階段任務時經常失敗，因為每個新工作階段在開始時都沒有先前動作的記憶。Anthropic 在使用 Claude Agent SDK 處理長時程任務時，發現了兩種主要的失敗模式：

1. 過度雄心 (One-shotting)： 代理人試圖一次實作過多功能，導致上下文窗口耗盡，並使專案處於半實作、缺乏文件的狀態。
2. 過早完成： 後續的代理人實例可能會看到現有的進度，並在所有需求尚未滿足之前，錯誤地宣稱整個專案已完成。

雖然上下文壓縮 (context compaction) 有所幫助，但通常不足以提供清晰、結構化的指令，讓後續代理人能夠在不靠猜測或浪費 token 來恢復工作的情況下重新開始工作。

雙代理人解決方案

為了彌補工作階段之間的差距，Anthropic 採用了兩部分的提示策略。雖然底層的系統提示 (system prompt) 和工具保持不變，但初始的使用者提示有所不同，以建立兩個不同的角色：

1. 初始化代理人 (The Initializer Agent)

初始化代理人僅用於第一個工作階段。其主要目標是建立一個引導所有未來代理人的基礎。關鍵輸出包括：

• 功能列表 (Feature List)： 一個全面的 JSON 檔案，將使用者的的高層次提示擴展為詳細的需求（例如，為一個 claude.ai 複製品建立超過 200 個功能）。每個功能最初都被標記為 "passes": false。
• 環境設定 (Environment Setup)： 一個 init.sh 腳本，用於自動化啟動開發伺服器和基本的端到端測試。
• 追蹤基礎設施 (Tracking Infrastructure)： 一個用於記錄進度的 claude-progress.txt 檔案，以及一個初始的 git commit 以建立程式碼庫狀態。

2. 編碼代理人 (The Coding Agent)

後續的工作階段使用編碼代理人，其任務是取得增量式的進度。為了防止上述失敗模式，編碼代理人遵循嚴格的操作循環：

• 定向 (Orientation)： 每個工作階段開始時，都會執行 pwd、讀取 claude-progress.txt、查看 git log，並讀取 feature_list.json 檔案。
• 增量實作 (Incremental Implementation)： 代理人一次只處理一個功能，以防止上下文窗口耗盡。
• 驗證 (Verification)： 代理人必須使用瀏覽器自動化工具（例如 Puppeteer MCP server）來進行端到端的驗證，如同人類使用者一樣，而不是僅僅依賴單元測試或程式碼檢查。
• 乾淨的交接 (Clean Handoff)： 在結束工作階段之前，代理人必須使用具描述性的訊息將其進度提交至 git，並更新進度檔案，確保環境處於適合下一個代理人的「合併就緒 (merge-ready)」狀態。

失敗模式與緩解措施摘要

| 問題 | 初始化代理人動作 | 編碼代理人動作 | | :--- | :--- | :--- | | | 過早宣稱專案完成 | 建立結構化的 JSON 功能列表 | 讀取功能列表；一次只處理一個功能 | | 程式碼錯誤/缺乏文件 | 建立 git 儲存庫與進度檔案 | 讀取日誌/進度；開始時執行基本測試；結束時提交/更新 | | 功能過早完成 | 建立功能列表 | 在標記為「通過」之前，透過端到端測試進行自我驗證 | | 設定摩擦 | 寫入 init.sh 腳本 | 執行 init.sh 以啟動伺服器並驗證狀態 |

技術限制與未來方向

儘管有所改進，Anthropic 指出目前瀏覽器自動化存在特定的限制。例如，Claude 無法透過 Puppeteer MCP 看到瀏覽器原生的彈窗 (alert modals)，這可能導致依賴這些彈窗的功能出現錯誤。

未來的研究將探索多代理人架構——利用專門用於測試、QA 和程式碼清理的代理人——是否比單一通用型編碼代理人表現更佳。此外，Anthropic 目標是將這些架構模式推廣到網頁開發之外，應用於金融建模和科學研究等領域。