AI也能換崗了！Anthropic教智能體交接班，不怕長任務斷片

新智元報道

編輯：元宇

【新智元導讀】如何讓沒有長時記憶的AI，完成持續數小時的復雜任務？Anthropic設計出一個更高效的長時智能體運行框架，讓AI能夠像人類工程師一樣，在跨越數小時的任務中漸進式推進。

假如你雇傭了一支24小時輪班的工程師團隊，要求他們一起開發一款復雜應用。

但有一個奇怪規定：每位工程師一上班就完全忘記上一班做過什么，只能從零開始重新干。

無論他們技術多強，工作多努力，這個項目恐怕也做不成。

而這正是「長期運行智能體」在現實中遭遇的真實困境：

「上下文窗口一關，AI就失憶」。

模型沒有真正的長期記憶，所有判斷都依賴當下能看到的文本片段，上下文窗口一滿或被關掉，就像白板被擦掉一樣。

這種「記憶缺陷」，讓智能體做不了長工程，一旦任務需要持續數小時、跨越多輪對話窗口時，這樣的問題就會暴露出來。

由于上下文窗口有限，而大多數復雜項目無法在單一窗口完成，因此智能體必須找到一種能夠跨越多輪編碼會話的有效機制。

近日，Anthropic通過「偷師」人類工程師，形成了一套適用于長期運行智能體的有效框架。

https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents

雙智能體架構

模仿人類優秀工程師的日常習慣

Claude Agent SDK是一個強大而通用的智能體框架，它不僅擅長編碼，還能查資料、調工具、規劃步驟、執行任務。

它擁有上下文管理能力，比如上下文壓縮（compaction），能讓智能體在不耗盡上下文窗口的前提下繼續干活。

但僅靠上下文壓縮還不夠。

在開箱即用的情況下，即使Opus 4.5這樣頂級的編碼模型，如果只給它一個「去做一個claude.ai的克隆網頁」這樣的模糊大指令。然后讓它在SDK里跨多個上下文窗口反復執行，它依然很難完成一個真正能上線的Web應用。

在這個過程中，Claude經常會出現兩類常見的失敗模式：

第一種，它經常一次試圖做太多事。

比如，一次性把整個應用寫完。結果常常中途耗盡上下文，留下未完成、無文檔的半成品功能，進入下一次會話時，就不得不猜測之前發生了什么。

第二種，錯誤判斷「項目已完成」。

這通常出現在項目后期。當一些功能已經實現時，后來啟動的智能體往往會掃瞄現有成果，然后直接宣布項目已經完成。

為了解決這個問題，研究人員將問題拆成兩部分：

第一步，需要在初始環境中搭建好提示詞要求的全部功能基礎，讓智能體能按步驟、按功能推進。

第二步，每次會話中的智能體必須每次推進一小步，同時將環境保持在「干凈狀態」。

即能隨時安全合并到主分支：沒有明顯bug、代碼整潔、有清晰文檔，開發者隨時可以繼續加新功能。

按照這種思路，Anthropic為Claude Agent SDK設計了一個雙組件方案：

• 初始化智能體（Initializer Agent）

第一次會話用一個專門提示詞，讓模型設置初始環境：生成init.sh腳本、claude-progress.txt工作日志文件，以及一個初始Git提交。

• 編碼智能體（Coding Agent）

在后續會話中接手工作，每次只推進一小步，并為下一輪工作留下清晰信息。

這種模式的關鍵突破點在于找到一種方式，讓每次會話在沒有歷史上下文的情況下也能快速理解當前項目狀態，而claude-progress.txt文件與Git歷史正好能做到這點。

這一靈感來自優秀軟件工程師的日常工作習慣。

環境管理「三板斧」

如何讓「接班」的智能體快速上手？

初始化智能體要搭建好所有未來編碼會話需要的環境上下文，包括功能清單（Feature List）、漸進式推進（Incremental Progress）、測試（Testing）。

功能列表

為避免智能體一次性寫完整個應用或過早宣布項目完成，研究人員讓初始化智能體將用戶的初始提示，擴展成一個完整的功能需求文件。

例如，在claude.ai克隆示例中，它寫出了超過200個功能，如「用戶可以打開新對話、輸入消息、按下Enter，并看到AI回復」。

這些功能一開始都標記為「failing」，讓后續智能體清楚還有哪些功能沒完成。

研究人員要求編碼智能體只能修改passes字段的狀態，并明確強調：「不允許刪除或修改測試，否則可能導致功能缺失或出現bug。」

反復試驗，研究人員最終選用JSON格式，這是因為比起Markdown文件，AI更不容易誤刪或覆蓋JSON內容。

漸進式推進

在初始環境搭建好之后，編碼智能體會被要求一次只做一個功能的小步驟改動。

這種漸進式推進，對于解決智能體一次做太多事的問題非常關鍵。

同時，每次修改后保持環境的「干凈」也很重要。

實驗發現，最有效的方法是要求模型把改動通過描述性的信息提交到Git，并在progress文件中總結進展。

這樣，模型就能方便地回滾錯誤改動，恢復穩定代碼狀態。

這些方式能夠大幅提升效率，因為智能體不再需要花大量時間猜測之前發生了什么。

測試

此外，研究人員還觀察到一個大問題：

Claude經常在沒有充分測試的情況下，把功能標記為完成。

這是因為，如果不提供明確指令和工具，Claude的「測試行為」大多會停留在「代碼層面」，而不是「完整用戶流程層面」。

比如，它會改代碼、跑單元測試、甚至用curl測一下開發服務器，但這些操作只能證明「代碼大致能跑」，并不能保證整個用戶操作流程從頭到尾是順暢可用的。

如果我們明確要求它使用瀏覽器自動化工具，并像真實用戶一樣進行端到端測試，它在Web應用場景中通常表現得很好，很多原本容易漏掉的bug都能被發現出來。

Claude通過Puppeteer MCP服務器在測試claude.ai克隆版時截取的屏幕截圖

因為很多問題只有在「真實運行、真實點擊」時才會暴露，而不是從代碼文本上就能看出來。

當然仍有一些限制，比如模型本身的視覺能力有限，瀏覽器自動化工具無法識別所有場景。

比如，通過Puppeteer MCP，Claude現在看不到瀏覽器自帶的alert彈窗。

對于那些「點一下按鈕就彈個原生alert，再根據用戶點擊決定后續行為」的功能，Claude在自動化測試時就很難完整覆蓋，也更容易出問題。

快速上手

通過上述機制，每次編碼智能體啟動時都會先執行一套簡單但實用的步驟：

• 運行pwd看看自己工作在什么目錄，只能編輯這個目錄里的文件。

• 閱讀 git 日志和進度文件，了解最近做了什么。

• 閱讀功能列表，并選擇最高優先級且未完成的功能。

這種方式每次都能為Claude節省不少Token，因為它不必重新思考如何測試代碼。

研究人員還讓初始化智能體編寫一個init.sh腳本，用于啟動開發服務器，并在實現新功能前跑一次基本的端到端測試。

在claude.ai克隆項目中，智能體會先啟動本地開發服務器，然后用Puppeteer MCP打開新對話、發送消息、接收回復。

這樣Claude能立即判斷項目是否處于異常狀態，并馬上修復bug。

如果它直接開始做新功能，只會讓情況更糟。

因此，一個典型的會話通常會從類似這樣的助手消息開始：

目前的雙組件架構已顯著提升了全棧 Web應用開發的穩定性，但仍然有許多開放問題。

其中最關鍵的一點是：

不清楚是否一個通用編碼智能體就足夠強，還是應該采用多智能體架構。

比如專門的「測試智能體」「質檢智能體」或「代碼清理智能體」。

這一框架主要針對Web應用進行了優化，但很可能其中一些經驗同樣適用于科研、金融建模等需要長時間運行的智能體任務。

參考資料：

https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents

秒追ASI

?點贊、轉發、在看一鍵三連?

點亮星標，鎖定新智元極速推送！