今天的 Agent，在一個(gè)獨(dú)立的、短時(shí)間任務(wù)上的表現(xiàn)已經(jīng)很不錯(cuò)了。

下一步，是怎么讓 Agent 能夠更長(zhǎng)時(shí)間地運(yùn)行，執(zhí)行更復(fù)雜的任務(wù)，業(yè)界其實(shí)一直沒有共識(shí)。

更強(qiáng)大的模型？更長(zhǎng)的上下文能力？更復(fù)雜的 Multi-Agent 架構(gòu)？

最近 Cursor 和 Anthropic 分享了他們?cè)凇窵ong-running Agents」上的工程實(shí)踐，有意思的是：思路不一樣，解決方案也不同。

Cursor 專注通過大規(guī)模并行地運(yùn)行多個(gè) Agent 來(lái)執(zhí)行復(fù)雜的、長(zhǎng)時(shí)任務(wù)；Claude Code 則是側(cè)重解決單個(gè) Agent 在跨越多個(gè)工作周期時(shí)的「記憶連續(xù)性」問題。

以下為兩篇博客文章，F(xiàn)ounder Park 在不改變?cè)獾那疤嵯?，進(jìn)行了編譯、微調(diào)。

Cursor：《Scaling long-running autonomous coding》

Anthropic：《Effective harnesses for long-running agents》

??關(guān)注 Founder Park，最及時(shí)最干貨的創(chuàng)業(yè)分享

超 19000 人的「AI 產(chǎn)品市集」社群！不錯(cuò)過每一款有價(jià)值的 AI 應(yīng)用。

邀請(qǐng)從業(yè)者、開發(fā)人員和創(chuàng)業(yè)者，飛書掃碼加群：

進(jìn)群后，你有機(jī)會(huì)得到：

• 最新、最值得關(guān)注的 AI 新品資訊；
  

• 不定期贈(zèng)送熱門新品的邀請(qǐng)碼、會(huì)員碼；
  

• 最精準(zhǔn)的AI產(chǎn)品曝光渠道

01Cursor：

多 Agent 并行協(xié)作，引入角色分工

Cursor 的思路是，通過大規(guī)模并行地運(yùn)行多個(gè) Agent 來(lái)執(zhí)行復(fù)雜的、長(zhǎng)時(shí)任務(wù)。

Cursor 認(rèn)為，目前單個(gè) Agent 在處理目標(biāo)明確、范圍有限的「單點(diǎn)任務(wù)」時(shí)，已經(jīng)表現(xiàn)得相當(dāng)出色了。但是針對(duì)復(fù)雜「項(xiàng)目」時(shí)，比如從零開始搭一個(gè)全新的軟件，能力存在上限。

下一步的方向是像組建人類團(tuán)隊(duì)一樣，投入成百上千個(gè) Agent 并行工作。但這里的難題是，如何有效地協(xié)調(diào)這些 Agent，寫下超過一百萬(wàn)行代碼，處理數(shù)以萬(wàn)億計(jì)的 Token。

Stripe CEO 對(duì)這項(xiàng)研究的評(píng)價(jià)

1.1 在失敗中學(xué)習(xí)：協(xié)調(diào)機(jī)制的兩次迭代

Cursor 研究員最初的直覺是，大型項(xiàng)目的開發(fā)路徑充滿了不確定性，在項(xiàng)目啟動(dòng)之初，很難清晰地劃分工作。因此，決定從「動(dòng)態(tài)協(xié)調(diào)」入手：讓每個(gè) Agent 根據(jù)其他同伴的實(shí)時(shí)動(dòng)態(tài)，來(lái)決定自己下一步該做什么。

第一次嘗試：引入鎖定機(jī)制，扁平化協(xié)作

Cursor 構(gòu)建了一個(gè)完全扁平化的系統(tǒng)，在這個(gè)系統(tǒng)里，所有 Agent 地位平等，通過訪問一個(gè)共享文件來(lái)進(jìn)行自我協(xié)調(diào)。

流程如下：

1. 一個(gè) Agent 首先讀取這個(gè)共享文件，查看其他同伴正在進(jìn)行的任務(wù)；

2. 然后，它從任務(wù)列表中認(rèn)領(lǐng)一個(gè)尚未被執(zhí)行的任務(wù)；

3. 為了防止其他 Agent 同時(shí)認(rèn)領(lǐng)同一個(gè)任務(wù)，引入了鎖定機(jī)制，給任務(wù)設(shè)置一個(gè) lock。

4. 完成任務(wù)后，它會(huì)更新共享文件中的狀態(tài)，并釋放這個(gè) lock。

但這個(gè)方案嘗試失敗了。

首先是，有的 Agent 在執(zhí)行任務(wù)時(shí)會(huì)鎖定過長(zhǎng)時(shí)間，甚至在任務(wù)完成后忘記釋放鎖，導(dǎo)致其他 Agent 只能排隊(duì)等待。20 個(gè) Agent 同時(shí)工作時(shí)，有效吞吐量會(huì)驟降到只相當(dāng)于兩三個(gè) Agent 的水平，大量時(shí)間被浪費(fèi)在排隊(duì)等待上。

其次，這個(gè)系統(tǒng)非常脆弱，任何一個(gè)環(huán)節(jié)出錯(cuò)都可能導(dǎo)致連鎖反應(yīng)。比如，一個(gè)持有鎖的 Agent 可能會(huì)因?yàn)槟承┰蛞馔獗罎?，那這個(gè)鎖就可能永遠(yuǎn)無(wú)法被釋放，對(duì)應(yīng)的任務(wù)也就被永久阻塞。

此外，還存在 Agent 重復(fù)申請(qǐng)自己已持有的鎖，甚至在未獲得鎖的情況下強(qiáng)行更新協(xié)調(diào)文件，導(dǎo)致整個(gè)協(xié)作系統(tǒng)陷入癱瘓。

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

意識(shí)到到鎖定機(jī)制的局限之后，Cursor 嘗試用「樂觀并發(fā)控制（optimistic concurrency control）」機(jī)制來(lái)替代原方案。

簡(jiǎn)單來(lái)說，「樂觀并發(fā)控制（optimistic concurrency control）」機(jī)制的邏輯是：

• Agent 可以隨時(shí)自由地讀取共享文件的狀態(tài)，不需要等待；

• 當(dāng)一個(gè) Agent 完成任務(wù)并準(zhǔn)備寫入更新時(shí)，系統(tǒng)會(huì)檢查自它上次讀取以來(lái)，狀態(tài)文件是否被其他 Agent 修改過；

• 如果狀態(tài)未變，寫入成功。如果狀態(tài)已被修改，本次寫入失敗，Agent 需要重新讀取最新狀態(tài)，并重新執(zhí)行任務(wù)。

這個(gè)方案比「鎖定機(jī)制」更簡(jiǎn)潔、也更穩(wěn)健，但暴露了一個(gè)更深層次的問題。

群體性的「畏懼風(fēng)險(xiǎn)」。在一個(gè)沒有任何層級(jí)、所有個(gè)體都平等的結(jié)構(gòu)中，Agent 們表現(xiàn)出了一種強(qiáng)烈的「風(fēng)險(xiǎn)規(guī)避」傾向。會(huì)主動(dòng)避開復(fù)雜的、具有挑戰(zhàn)性的核心任務(wù)，傾向于執(zhí)行細(xì)小、安全的代碼修改。沒有任何一個(gè) Agent 愿意承擔(dān)起攻克核心難題或負(fù)責(zé)端到端功能實(shí)現(xiàn)的重任。這導(dǎo)致項(xiàng)目在很長(zhǎng)一段時(shí)間里「原地打轉(zhuǎn)」，毫無(wú)進(jìn)展。

1.2「規(guī)劃者」與「工作者」：引入角色分工

從前兩次的失敗中汲取教訓(xùn)后，Cursor 決定徹底摒棄扁平化的結(jié)構(gòu)，創(chuàng)建一個(gè)職責(zé)分明的流水線式協(xié)作體系，其中包含三個(gè)核心角色：

• 規(guī)劃者（Planner）：這個(gè)角色的定位類似于團(tuán)隊(duì)中的架構(gòu)師或技術(shù)負(fù)責(zé)人。核心職責(zé)不是寫代碼，是持續(xù)地探索和分析整個(gè)代碼庫(kù)，理解項(xiàng)目需求?？梢詾樘囟ǖ拇a模塊派生出「子規(guī)劃者」，讓規(guī)劃過程本身也能實(shí)現(xiàn)并行化；

• 工作者（Worker）：這個(gè)角色是團(tuán)隊(duì)中的主力工程師，是純粹的執(zhí)行者。從任務(wù)池中領(lǐng)取一個(gè)任務(wù)，然后心無(wú)旁騖地完成它。不需要與其他「工作者」進(jìn)行任何形式的溝通或協(xié)調(diào)，也完全不必關(guān)心項(xiàng)目全局。它們只是專注于執(zhí)行分配給自己的任務(wù)，直到完成，然后提交代碼。

• 裁判（Judge）：這個(gè)角色像是項(xiàng)目經(jīng)理或質(zhì)量保證工程師。在每一個(gè)工作周期結(jié)束時(shí)，比如，每隔幾小時(shí)或完成一定數(shù)量的任務(wù)后，會(huì)有一個(gè)JudgeAgent 來(lái)評(píng)估當(dāng)前進(jìn)展，并決定是否繼續(xù)開始下一輪迭代。

這套體系解決了絕大部分的協(xié)調(diào)難題，能夠?qū)㈨?xiàng)目規(guī)模擴(kuò)展到前所未有的程度，同時(shí)避免了任何單個(gè) Agent 因?yàn)檫^度專注于局部陷入到「隧道視野（tunnel vision）」中。

1.3 實(shí)驗(yàn)：數(shù)周的持續(xù)運(yùn)行

為了檢驗(yàn)這個(gè)系統(tǒng)的有效性，Cursor 設(shè)定了幾個(gè)很有挑戰(zhàn)性的任務(wù)。

從零構(gòu)建網(wǎng)頁(yè)瀏覽器。

Agent 團(tuán)隊(duì)持續(xù)運(yùn)行了將近一周的時(shí)間，在 1,000 個(gè)獨(dú)立文件中，編寫了超過 100 萬(wàn)行代碼，成功跑出了一個(gè)基礎(chǔ)的瀏覽器。

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

雖然看起來(lái)像是一張簡(jiǎn)單的截圖，但從零開始構(gòu)建瀏覽器極其困難。

大型代碼庫(kù)原地遷移

另一項(xiàng)實(shí)驗(yàn)是在 Cursor 自己的代碼庫(kù)中，將一個(gè)大型項(xiàng)目的前端框架從 Solid 原地遷移到 React。這個(gè)任務(wù)耗時(shí)三周多，產(chǎn)生了+266,000 行新增和-193,000 行刪除。雖然這些代碼仍然需要人類進(jìn)行最終的細(xì)致審查，但它已經(jīng)成功通過了「持續(xù)集成（CI）」系統(tǒng)和初步的自動(dòng)化檢查。

從 Solid 遷移到 React 的代碼合并請(qǐng)求

產(chǎn)品性能與功能優(yōu)化

還有一個(gè)實(shí)驗(yàn)是改進(jìn) Cursor 即將發(fā)布的一款新產(chǎn)品。讓一個(gè)長(zhǎng)期運(yùn)行的 Agent 負(fù)責(zé)優(yōu)化視頻渲染模塊，用 Rust 語(yǔ)言重寫了該模塊，將渲染速度提升了 25 倍。同時(shí)，還增加了平滑的縮放和平移功能，能夠跟隨光標(biāo)，并帶有自然的彈簧過渡和運(yùn)動(dòng)模糊效果。這部分完全由 AI 生成的代碼已經(jīng)被直接合并到主干，很快就會(huì)在生產(chǎn)環(huán)境中上線。

1.4 經(jīng)驗(yàn)與教訓(xùn)

最后，Cursor 研究員進(jìn)行了經(jīng)驗(yàn)總結(jié)：

對(duì)于超長(zhǎng)期任務(wù)，模型選擇至關(guān)重要。我們發(fā)現(xiàn)，GPT-5.2 模型在長(zhǎng)時(shí)間自主工作中表現(xiàn)更佳：它們能更好地遵循指令、保持專注、避免偏離，并且能精確、完整地實(shí)現(xiàn)功能。

相比之下，Opus 4.5 模型傾向于提早結(jié)束任務(wù)，在方便的時(shí)候選擇「走捷徑」，并迅速交還控制權(quán)。同時(shí)，我們還發(fā)現(xiàn)，不同模型擅長(zhǎng)扮演不同角色。例如，GPT-5.2 是比 GPT-5.1-Codex 更優(yōu)秀的「規(guī)劃者」，雖然 GPT-5.1-Codex 是專門為編碼優(yōu)化的模型。現(xiàn)在，我們不再使用通用模型，而是為每個(gè)角色選擇最適合的模型。

我們的許多改進(jìn)，來(lái)「做減法」而不是「做加法」。我們最初設(shè)立了一個(gè)「集成者」角色，負(fù)責(zé)質(zhì)量控制和解決代碼沖突，結(jié)果發(fā)現(xiàn)它制造的瓶頸比解決的問題還多。事實(shí)上，「工作者」Agent 其實(shí)已經(jīng)具備了自行處理沖突的能力。

最好的系統(tǒng)，往往比你想象的更簡(jiǎn)單。我們起初試圖模仿分布式計(jì)算和組織設(shè)計(jì)中的復(fù)雜系統(tǒng)，但后來(lái)發(fā)現(xiàn)，并不是所有的理論都適用于 Agent。

恰到好處的結(jié)構(gòu)，是關(guān)鍵所在。結(jié)構(gòu)太松散，Agent 之間會(huì)互相沖突、重復(fù)勞動(dòng)、偏離目標(biāo)。如果結(jié)構(gòu)太嚴(yán)密，系統(tǒng)又會(huì)變得脆弱不堪。

系統(tǒng)的絕大部分行為最終都?xì)w結(jié)于我們?nèi)绾尉帉?prompt。如何讓 Agent 高效協(xié)調(diào)、避免異常行為，并在長(zhǎng)時(shí)間內(nèi)保持專注，這些都是需要通過大量的實(shí)驗(yàn)來(lái)優(yōu)化 prompt。協(xié)作框架和模型本身雖然重要，但 prompt才是重中之重。

此外，Cursor 研究員也坦言：多 Agent 協(xié)調(diào)依然是一個(gè)難題，仍然需要進(jìn)一步探索。目前的系統(tǒng)雖然可行，但遠(yuǎn)沒有達(dá)到最優(yōu)狀態(tài)。比如，「規(guī)劃者」應(yīng)該在任務(wù)完成后被自動(dòng)喚醒，以規(guī)劃下一步工作；Agent 偶爾會(huì)出現(xiàn)運(yùn)行時(shí)間過長(zhǎng)的問題；我們?nèi)孕柰ㄟ^定期重啟來(lái)對(duì)抗系統(tǒng)性的目標(biāo)偏離和「隧道視野」。

Michael Truell 的回應(yīng)

02Claude Code：

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

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

想象一下，一個(gè)軟件團(tuán)隊(duì)在做一個(gè)大項(xiàng)目，但有一個(gè)奇怪的規(guī)定：每個(gè)工程師只能工作幾十分鐘，最多幾小時(shí)，干完就要換一個(gè)新的工程師。所以讓這個(gè)團(tuán)隊(duì)完成簡(jiǎn)單項(xiàng)目任務(wù)還行，復(fù)雜一點(diǎn)需要長(zhǎng)時(shí)間運(yùn)行的項(xiàng)目，比如你讓它克隆一個(gè) claude.ai，它就做不到。

這其實(shí)就是 Coding Agent 的現(xiàn)狀：沒有記憶，上下文窗口長(zhǎng)度有限。所以要它執(zhí)行長(zhǎng)時(shí)間任務(wù)，它還做不好。

所以，Anthropic 把重點(diǎn)放在了：如何讓 Agent 在跨越多個(gè)上下文窗口時(shí)依然能持續(xù)推進(jìn)任務(wù)。

2.1 Agent 在長(zhǎng)任務(wù)中遇到的主要問題是什么

主要有三種：

• 一口氣干太多。比如讓 Agent 克隆一個(gè) claude.ai 這樣的網(wǎng)站，它會(huì)試圖一次性搞定整個(gè)應(yīng)用。結(jié)果上下文還沒用完，功能寫了一半，代碼亂成一鍋粥。下一個(gè)會(huì)話進(jìn)來(lái)，面對(duì)半成品只能干瞪眼，花很多時(shí)間猜測(cè)前面到底做了什么。

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

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

這三種失敗模式的共同點(diǎn)是 Agent 不知道全局目標(biāo)，也不知道該在哪里停下來(lái)、該留下什么給下一位。

2.2 參考人類團(tuán)隊(duì)的分工協(xié)作機(jī)制，設(shè)計(jì)雙 Agent 方案

針對(duì)這種情況，Anthropic 的解決思路是，通過引入一個(gè)類似人類團(tuán)隊(duì)的分工協(xié)作機(jī)制，將復(fù)雜任務(wù)拆解成小的可跟蹤驗(yàn)證的任務(wù)，清晰的交接機(jī)制，并且嚴(yán)格驗(yàn)證任務(wù)結(jié)果。

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

• 第一步，需要在初始環(huán)境中搭建好提示詞要求的全部功能基礎(chǔ)，讓 Agent 能按步驟、按功能推進(jìn)。

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

按照這種思路，Anthropic 給 Claude Agent SDK 設(shè)計(jì)了一個(gè)雙 Agent 方案：

• 初始化 Agent（Initializer Agent）

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

• 編碼 Agent（Coding Agent）

在后續(xù)會(huì)話中接手工作，每次只推進(jìn)一小步，并為下一輪工作留下清晰信息。

初始化 Agent

只在項(xiàng)目啟動(dòng)時(shí)出場(chǎng)一次，任務(wù)是搭好項(xiàng)目運(yùn)行環(huán)境。初始化 Agent 要搭建好所有未來(lái)編碼會(huì)話需要的環(huán)境上下文，包括功能清單（Feature List）、漸進(jìn)式推進(jìn)（Incremental Progress）、測(cè)試（Testing）。

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

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

這些功能一開始都標(biāo)記為「failing」，讓后續(xù) 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 字段的狀態(tài)，并明確強(qiáng)調(diào)：「不允許刪除或修改測(cè)試，否則可能導(dǎo)致功能缺失或出現(xiàn) bug。」

而且，這里有個(gè)細(xì)節(jié)，這個(gè)清單不是用 Markdown 來(lái)寫的，是一個(gè) JSON 數(shù)組，因?yàn)?Anthropic 在實(shí)驗(yàn)后發(fā)現(xiàn)，相比 Markdown，模型在處理 JSON 時(shí)更不容易隨意篡改或覆蓋文件。

編碼 Agent

在初始化項(xiàng)目后，后續(xù)就是編碼 Agent 來(lái)干活。核心行為準(zhǔn)則只有兩條：一次只做一個(gè)功能，做完要留下干凈的環(huán)境。

編碼 Agent 的行為模式被嚴(yán)格地設(shè)定為「漸進(jìn)式推進(jìn)」，并且遵循一套嚴(yán)謹(jǐn)?shù)墓ぷ髁鞒蹋?/p>

• 理解現(xiàn)狀：在每個(gè)會(huì)話開始時(shí)，它首先會(huì)去閱讀 claude-progress.txt 日志文件和 git log 提交歷史，來(lái)快速了解項(xiàng)目的當(dāng)前狀態(tài)。

• 單一任務(wù)：從一個(gè)明確的功能清單中，選擇一個(gè)優(yōu)先級(jí)最高的、尚未完成的任務(wù)來(lái)執(zhí)行。被嚴(yán)格禁止同時(shí)處理多個(gè)任務(wù)。

• 專注實(shí)現(xiàn)：在明確了單一目標(biāo)后，全力投入到該功能的編碼、調(diào)試和測(cè)試中。

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

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

測(cè)試環(huán)節(jié)的改進(jìn)

研究員發(fā)現(xiàn)，Claude 經(jīng)常在沒有充分測(cè)試的情況下，就把功能標(biāo)記為「完成」。它會(huì)跑單元測(cè)試，甚至用 curl 命令測(cè)一下接口，但是發(fā)現(xiàn)不了端到端流程里的問題。問題是很多 bug 只有用戶真正操作頁(yè)面時(shí)才會(huì)暴露。

解決方案是，給 Agent 配一個(gè)瀏覽器自動(dòng)化工具，比如 Puppeteer MCP，并且明確要求它像一個(gè)真實(shí)用戶一樣去操作和驗(yàn)證。

Agent 像真人一樣打開瀏覽器、點(diǎn)按鈕、填表單、看頁(yè)面渲染結(jié)果。

Anthropic 放了一張動(dòng)圖，展示 Agent 測(cè)試克隆版 claude.ai 時(shí)的截圖，確實(shí)是在像真實(shí)用戶一樣操作。

這個(gè)方法大幅提升了功能驗(yàn)證的準(zhǔn)確率。很多只看代碼發(fā)現(xiàn)不了的 Bug，Agent 自己能定位并修復(fù)。當(dāng)然也有盲區(qū)，比如瀏覽器原生的 alert 彈窗，Puppeteer 捕捉不到，依賴彈窗的功能容易出 bug。

2.3 Agent「開工」的標(biāo)準(zhǔn)流程

所有準(zhǔn)備就緒后，每個(gè)編碼 Agent「上班」第一件事，就是按流程熟悉環(huán)境：

1. 運(yùn)行 pwd 命令，查看當(dāng)前工作目錄：確認(rèn)當(dāng)前在哪。

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

3. 閱讀功能清單文件：找到優(yōu)先級(jí)最高的未完成任務(wù)。

4. 運(yùn)行 init.sh 腳本：?jiǎn)?dòng)開發(fā)服務(wù)器，跑一遍基礎(chǔ)測(cè)試，確保開工前一切正常。

這種方法為 Claude 的每個(gè)會(huì)話節(jié)省了一些 Token，因?yàn)樗恍枰儋M(fèi)力思考如何測(cè)試代碼。

在這樣的設(shè)定下，一個(gè)典型的會(huì)話開始是這樣的：

[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.

此外，研究員還總結(jié)了，長(zhǎng)時(shí)間運(yùn)行的 AI Agent 中四種常見的失敗模式和解決方案，如下：

2.4 開放性問題

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

一個(gè)全能 Agent 還是一個(gè)專家團(tuán)隊(duì)？

未來(lái)是不是需要一個(gè)專門的測(cè)試 Agent、一個(gè)質(zhì)檢 Agent、一個(gè)代碼清理 Agent，組成一個(gè)多 Agent（multi-agent）架構(gòu)？

能否跨界？

這套方法為 Web 開發(fā)優(yōu)化過，未來(lái)需要推廣到其他領(lǐng)域，比如科學(xué)研究、金融建模等等。

轉(zhuǎn)載原創(chuàng)文章請(qǐng)?zhí)砑游⑿牛篺ounderparker