怎么做 Long-running Agents，Cursor、Anthropic 給了兩種截然不同的思路

今天的 Agent，在一個獨立的、短時間任務上的表現已經很不錯了。

下一步，是怎么讓 Agent 能夠更長時間地運行，執行更復雜的任務，業界其實一直沒有共識。

更強大的模型？更長的上下文能力？更復雜的 Multi-Agent 架構？

最近 Cursor 和 Anthropic 分享了他們在「Long-running Agents」上的工程實踐，有意思的是：思路不一樣，解決方案也不同。

Cursor 專注通過大規模并行地運行多個 Agent 來執行復雜的、長時任務；Claude Code 則是側重解決單個 Agent 在跨越多個工作周期時的「記憶連續性」問題。

以下為兩篇博客文章，Founder Park 在不改變原意的前提下，進行了編譯、微調。

Cursor：《Scaling long-running autonomous coding》

Anthropic：《Effective harnesses for long-running agents》

??關注 Founder Park，最及時最干貨的創業分享

超 19000 人的「AI 產品市集」社群！不錯過每一款有價值的 AI 應用。

邀請從業者、開發人員和創業者，飛書掃碼加群：

進群后，你有機會得到：

• 最新、最值得關注的 AI 新品資訊；
  

• 不定期贈送熱門新品的邀請碼、會員碼；
  

• 最精準的AI產品曝光渠道

01Cursor：

多 Agent 并行協作，引入角色分工

Cursor 的思路是，通過大規模并行地運行多個 Agent 來執行復雜的、長時任務。

Cursor 認為，目前單個 Agent 在處理目標明確、范圍有限的「單點任務」時，已經表現得相當出色了。但是針對復雜「項目」時，比如從零開始搭一個全新的軟件，能力存在上限。

下一步的方向是像組建人類團隊一樣，投入成百上千個 Agent 并行工作。但這里的難題是，如何有效地協調這些 Agent，寫下超過一百萬行代碼，處理數以萬億計的 Token。

Stripe CEO 對這項研究的評價

1.1 在失敗中學習：協調機制的兩次迭代

Cursor 研究員最初的直覺是，大型項目的開發路徑充滿了不確定性，在項目啟動之初，很難清晰地劃分工作。因此，決定從「動態協調」入手：讓每個 Agent 根據其他同伴的實時動態，來決定自己下一步該做什么。

第一次嘗試：引入鎖定機制，扁平化協作

Cursor 構建了一個完全扁平化的系統，在這個系統里，所有 Agent 地位平等，通過訪問一個共享文件來進行自我協調。

流程如下：

1. 一個 Agent 首先讀取這個共享文件，查看其他同伴正在進行的任務；

2. 然后，它從任務列表中認領一個尚未被執行的任務；

3. 為了防止其他 Agent 同時認領同一個任務，引入了鎖定機制，給任務設置一個 lock。

4. 完成任務后，它會更新共享文件中的狀態，并釋放這個 lock。

但這個方案嘗試失敗了。

首先是，有的 Agent 在執行任務時會鎖定過長時間，甚至在任務完成后忘記釋放鎖，導致其他 Agent 只能排隊等待。20 個 Agent 同時工作時，有效吞吐量會驟降到只相當于兩三個 Agent 的水平，大量時間被浪費在排隊等待上。

其次，這個系統非常脆弱，任何一個環節出錯都可能導致連鎖反應。比如，一個持有鎖的 Agent 可能會因為某些原因意外崩潰，那這個鎖就可能永遠無法被釋放，對應的任務也就被永久阻塞。

此外，還存在 Agent 重復申請自己已持有的鎖，甚至在未獲得鎖的情況下強行更新協調文件，導致整個協作系統陷入癱瘓。

第二次嘗試：引入「樂觀并發控制」

意識到到鎖定機制的局限之后，Cursor 嘗試用「樂觀并發控制（optimistic concurrency control）」機制來替代原方案。

簡單來說，「樂觀并發控制（optimistic concurrency control）」機制的邏輯是：

• Agent 可以隨時自由地讀取共享文件的狀態，不需要等待；

• 當一個 Agent 完成任務并準備寫入更新時，系統會檢查自它上次讀取以來，狀態文件是否被其他 Agent 修改過；

• 如果狀態未變，寫入成功。如果狀態已被修改，本次寫入失敗，Agent 需要重新讀取最新狀態，并重新執行任務。

這個方案比「鎖定機制」更簡潔、也更穩健，但暴露了一個更深層次的問題。

群體性的「畏懼風險」。在一個沒有任何層級、所有個體都平等的結構中，Agent 們表現出了一種強烈的「風險規避」傾向。會主動避開復雜的、具有挑戰性的核心任務，傾向于執行細小、安全的代碼修改。沒有任何一個 Agent 愿意承擔起攻克核心難題或負責端到端功能實現的重任。這導致項目在很長一段時間里「原地打轉」，毫無進展。

1.2「規劃者」與「工作者」：引入角色分工

從前兩次的失敗中汲取教訓后，Cursor 決定徹底摒棄扁平化的結構，創建一個職責分明的流水線式協作體系，其中包含三個核心角色：

• 規劃者（Planner）：這個角色的定位類似于團隊中的架構師或技術負責人。核心職責不是寫代碼，是持續地探索和分析整個代碼庫，理解項目需求。可以為特定的代碼模塊派生出「子規劃者」，讓規劃過程本身也能實現并行化；

• 工作者（Worker）：這個角色是團隊中的主力工程師，是純粹的執行者。從任務池中領取一個任務，然后心無旁騖地完成它。不需要與其他「工作者」進行任何形式的溝通或協調，也完全不必關心項目全局。它們只是專注于執行分配給自己的任務，直到完成，然后提交代碼。

• 裁判（Judge）：這個角色像是項目經理或質量保證工程師。在每一個工作周期結束時，比如，每隔幾小時或完成一定數量的任務后，會有一個JudgeAgent 來評估當前進展，并決定是否繼續開始下一輪迭代。

這套體系解決了絕大部分的協調難題，能夠將項目規模擴展到前所未有的程度，同時避免了任何單個 Agent 因為過度專注于局部陷入到「隧道視野（tunnel vision）」中。

1.3 實驗：數周的持續運行

為了檢驗這個系統的有效性，Cursor 設定了幾個很有挑戰性的任務。

從零構建網頁瀏覽器。

Agent 團隊持續運行了將近一周的時間，在 1,000 個獨立文件中，編寫了超過 100 萬行代碼，成功跑出了一個基礎的瀏覽器。

盡管代碼庫規模驚人，新加入的 Agent 依然能夠快速理解上下文并做出有意義的貢獻。數百個「工作者（Agent）」能同時向同一個代碼分支提交代碼，且沖突率極低。

雖然看起來像是一張簡單的截圖，但從零開始構建瀏覽器極其困難。

大型代碼庫原地遷移

另一項實驗是在 Cursor 自己的代碼庫中，將一個大型項目的前端框架從 Solid 原地遷移到 React。這個任務耗時三周多，產生了+266,000 行新增和-193,000 行刪除。雖然這些代碼仍然需要人類進行最終的細致審查，但它已經成功通過了「持續集成（CI）」系統和初步的自動化檢查。

從 Solid 遷移到 React 的代碼合并請求

產品性能與功能優化

還有一個實驗是改進 Cursor 即將發布的一款新產品。讓一個長期運行的 Agent 負責優化視頻渲染模塊，用 Rust 語言重寫了該模塊，將渲染速度提升了 25 倍。同時，還增加了平滑的縮放和平移功能，能夠跟隨光標，并帶有自然的彈簧過渡和運動模糊效果。這部分完全由 AI 生成的代碼已經被直接合并到主干，很快就會在生產環境中上線。

1.4 經驗與教訓

最后，Cursor 研究員進行了經驗總結：

對于超長期任務，模型選擇至關重要。我們發現，GPT-5.2 模型在長時間自主工作中表現更佳：它們能更好地遵循指令、保持專注、避免偏離，并且能精確、完整地實現功能。

相比之下，Opus 4.5 模型傾向于提早結束任務，在方便的時候選擇「走捷徑」，并迅速交還控制權。同時，我們還發現，不同模型擅長扮演不同角色。例如，GPT-5.2 是比 GPT-5.1-Codex 更優秀的「規劃者」，雖然 GPT-5.1-Codex 是專門為編碼優化的模型。現在，我們不再使用通用模型，而是為每個角色選擇最適合的模型。

我們的許多改進，來「做減法」而不是「做加法」。我們最初設立了一個「集成者」角色，負責質量控制和解決代碼沖突，結果發現它制造的瓶頸比解決的問題還多。事實上，「工作者」Agent 其實已經具備了自行處理沖突的能力。

最好的系統，往往比你想象的更簡單。我們起初試圖模仿分布式計算和組織設計中的復雜系統，但后來發現，并不是所有的理論都適用于 Agent。

恰到好處的結構，是關鍵所在。結構太松散，Agent 之間會互相沖突、重復勞動、偏離目標。如果結構太嚴密，系統又會變得脆弱不堪。

系統的絕大部分行為最終都歸結于我們如何編寫 prompt。如何讓 Agent 高效協調、避免異常行為，并在長時間內保持專注，這些都是需要通過大量的實驗來優化 prompt。協作框架和模型本身雖然重要，但 prompt才是重中之重。

此外，Cursor 研究員也坦言：多 Agent 協調依然是一個難題，仍然需要進一步探索。目前的系統雖然可行，但遠沒有達到最優狀態。比如，「規劃者」應該在任務完成后被自動喚醒，以規劃下一步工作；Agent 偶爾會出現運行時間過長的問題；我們仍需通過定期重啟來對抗系統性的目標偏離和「隧道視野」。

Michael Truell 的回應

02Claude Code：

解決單個 Agent 跨上下文窗口的記憶問題

相比 Cursor，Anthropic 實現「Long Time Run」的思路更輕松一些，核心是：解決單個 Agent 在跨越多個工作周期時的「記憶連續性」問題。

想象一下，一個軟件團隊在做一個大項目，但有一個奇怪的規定：每個工程師只能工作幾十分鐘，最多幾小時，干完就要換一個新的工程師。所以讓這個團隊完成簡單項目任務還行，復雜一點需要長時間運行的項目，比如你讓它克隆一個 claude.ai，它就做不到。

這其實就是 Coding Agent 的現狀：沒有記憶，上下文窗口長度有限。所以要它執行長時間任務，它還做不好。

所以，Anthropic 把重點放在了：如何讓 Agent 在跨越多個上下文窗口時依然能持續推進任務。

2.1 Agent 在長任務中遇到的主要問題是什么

主要有三種：

• 一口氣干太多。比如讓 Agent 克隆一個 claude.ai 這樣的網站，它會試圖一次性搞定整個應用。結果上下文還沒用完，功能寫了一半，代碼亂成一鍋粥。下一個會話進來，面對半成品只能干瞪眼，花很多時間猜測前面到底做了什么。

• 過早宣布勝利。項目做了一部分，后來的 Agent 看看環境，覺得好像差不多了，就直接收工。功能缺一大堆也不管。

• 測試敷衍。Agent 改完代碼，跑幾個單元測試或者 curl 一下接口就覺得萬事大吉，根本沒有像真實用戶那樣端到端地走一遍流程。

這三種失敗模式的共同點是 Agent 不知道全局目標，也不知道該在哪里停下來、該留下什么給下一位。

2.2 參考人類團隊的分工協作機制，設計雙 Agent 方案

針對這種情況，Anthropic 的解決思路是，通過引入一個類似人類團隊的分工協作機制，將復雜任務拆解成小的可跟蹤驗證的任務，清晰的交接機制，并且嚴格驗證任務結果。

研究人員將問題拆成兩部分：

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

• 第二步，每次會話中的 Agent 必須每次推進一小步，同時將環境保持在「干凈狀態」。即能隨時安全合并到主分支：沒有明顯 bug、代碼整潔、有清晰文檔，開發者隨時可以繼續加新功能。

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

• 初始化 Agent（Initializer Agent）

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

• 編碼 Agent（Coding Agent）

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

初始化 Agent

只在項目啟動時出場一次，任務是搭好項目運行環境。初始化 Agent 要搭建好所有未來編碼會話需要的環境上下文，包括功能清單（Feature List）、漸進式推進（Incremental Progress）、測試（Testing）。

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

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

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

{
"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
}

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

而且，這里有個細節，這個清單不是用 Markdown 來寫的，是一個 JSON 數組，因為 Anthropic 在實驗后發現，相比 Markdown，模型在處理 JSON 時更不容易隨意篡改或覆蓋文件。

編碼 Agent

在初始化項目后，后續就是編碼 Agent 來干活。核心行為準則只有兩條：一次只做一個功能，做完要留下干凈的環境。

編碼 Agent 的行為模式被嚴格地設定為「漸進式推進」，并且遵循一套嚴謹的工作流程：

• 理解現狀：在每個會話開始時，它首先會去閱讀 claude-progress.txt 日志文件和 git log 提交歷史，來快速了解項目的當前狀態。

• 單一任務：從一個明確的功能清單中，選擇一個優先級最高的、尚未完成的任務來執行。被嚴格禁止同時處理多個任務。

• 專注實現：在明確了單一目標后，全力投入到該功能的編碼、調試和測試中。

• 留下痕跡：在完成功能開發后，必須將所做的代碼修改，連同一條描述清晰的提交信息（commit message），提交到 Git 倉庫。同時，還需要在 claude-progress.txt 文件中追加一段新的工作摘要。

這個設計的巧妙之處在于，它把「記憶」外化成了文件和 Git 歷史。每一輪的 Agent 不需要依賴上下文窗口里的碎片信息，而是模仿靠譜的人類工程師每天上班會做的事。先同步進度，確認環境正常，再動手干活。

測試環節的改進

研究員發現，Claude 經常在沒有充分測試的情況下，就把功能標記為「完成」。它會跑單元測試，甚至用 curl 命令測一下接口，但是發現不了端到端流程里的問題。問題是很多 bug 只有用戶真正操作頁面時才會暴露。

解決方案是，給 Agent 配一個瀏覽器自動化工具，比如 Puppeteer MCP，并且明確要求它像一個真實用戶一樣去操作和驗證。

Agent 像真人一樣打開瀏覽器、點按鈕、填表單、看頁面渲染結果。

Anthropic 放了一張動圖，展示 Agent 測試克隆版 claude.ai 時的截圖，確實是在像真實用戶一樣操作。

這個方法大幅提升了功能驗證的準確率。很多只看代碼發現不了的 Bug，Agent 自己能定位并修復。當然也有盲區，比如瀏覽器原生的 alert 彈窗，Puppeteer 捕捉不到，依賴彈窗的功能容易出 bug。

2.3 Agent「開工」的標準流程

所有準備就緒后，每個編碼 Agent「上班」第一件事，就是按流程熟悉環境：

1. 運行 pwd 命令，查看當前工作目錄：確認當前在哪。

2. 閱讀 Git 日志和進度文件：快速了解近期完成的工作。

3. 閱讀功能清單文件：找到優先級最高的未完成任務。

4. 運行 init.sh 腳本：啟動開發服務器，跑一遍基礎測試，確保開工前一切正常。

這種方法為 Claude 的每個會話節省了一些 Token，因為它不需要再費力思考如何測試代碼。

在這樣的設定下，一個典型的會話開始是這樣的：

[Assistant] I'll start by getting my bearings and understanding the current state of the project.
[Tool Use]
[Tool Use]
[Tool Use]
[Assistant] Let me check the git log to see recent work.
[Tool Use]
[Assistant] Now let me check if there's an init.sh script to restart the servers.

[Assistant] Excellent! Now let me navigate to the application and verify that some fundamental features are still working.

[Assistant] Based on my verification testing, I can see that the fundamental functionality is working well. The core chat features, theme switching, conversation loading, and error handling are all functioning correctly. Now let me review the tests.json file more comprehensively to understand what needs to be implemented next.

此外，研究員還總結了，長時間運行的 AI Agent 中四種常見的失敗模式和解決方案，如下：

2.4 開放性問題

同樣，在最后，Anthropic 也留了一些開放性問題，待進一步探索。

一個全能 Agent 還是一個專家團隊？

未來是不是需要一個專門的測試 Agent、一個質檢 Agent、一個代碼清理 Agent，組成一個多 Agent（multi-agent）架構？

能否跨界？

這套方法為 Web 開發優化過，未來需要推廣到其他領域，比如科學研究、金融建模等等。

轉載原創文章請添加微信：founderparker