跳到主要內容
AI News HubLIVE
站內改寫2 分鐘閱讀

構建雲代理的教訓:Cursor的經驗分享

文章摘要

本文分享了Cursor團隊在構建雲代理(cloud agents)過程中學到的關鍵教訓。雲代理執行在專用虛擬機器上,具有獨立環境、依賴和網路訪問許可權,能夠並行工作、無人值守執行,並承擔比本地代理更長時間的任務。文章強調了開發環境的重要性、長期執行的可靠性挑戰、解耦元件架構、何時信任代理以及自愈環境的未來方向。

構建雲代理的教訓:Cursor的經驗分享
回報錯誤

更正管道尚未開通,可先複製下方文章資訊留存。

查看更正說明
直接讀正文

Cursor團隊在構建雲代理的過程中積累了豐富的經驗。最初,他們認為雲代理只是本地代理的自然延伸,但很快發現,由於雲代理執行在獨立虛擬機器上,擁有自己的環境、依賴和網路訪問許可權,它們能夠並行工作、無需人工值守,並處理更長時間的任務。然而,這也帶來了環境搭建、可靠性和編排方面的挑戰。

開發環境是影響雲代理輸出質量的最關鍵因素。本地代理可以直接繼承開發者的工作環境,但在雲端,必須從頭重建整個環境。即使環境不完美,也不一定會導致崩潰或錯誤資訊,而只是輸出質量的微妙下降。隨著模型能力增強,環境配置已成為決定代理能否充分發揮潛力的關鍵因素。為此,Cursor團隊重建了大量基礎設施,包括更好的使用者工具、高效的休眠與恢復機制、快速檢查點與恢復以及緊密的整合。

長期執行的雲代理面臨可靠性挑戰。它們執行在隔離的虛擬機器中,容易受到推理提供商故障、節點替換等中斷的影響。起初,Cursor採用了“工作竊取”架構,但可靠性僅達到一個9。後來遷移到Temporal平臺,實現了耐久執行,能夠抵禦推理中斷、pod休眠與恢復等問題,可靠性提升到兩個9以上。目前,Temporal每天處理超過5000萬次操作,Cursor內部超過40%的PR來自雲代理。

為了實現靈活性和可擴充套件性,Cursor將代理迴圈、機器狀態和對話狀態解耦。代理迴圈執行在Temporal上,而非虛擬機器內,從而可以獨立管理pod生命週期。對話儲存和流式傳輸層與核心代理工作流分離,採用高效的追加儲存機制,並支援重試和流回退。

隨著模型智慧的提升,Cursor逐漸減少了對代理的嚴格控制。早期,系統會在每個任務後強制提交和推送;現在,代理可以自主決定如何工作。例如,多倉庫設定不再需要硬編碼的行為,CI自動修復功能也賦予了代理更多工具。計算機使用功能目前仍需要專門的子代理和定製提示,但代理可以自行決定何時呼叫。此外,雲代理的提示鼓勵更高自主性,因為等待人工響應的成本更高。

展望未來,Cursor致力於讓雲代理具備自愈能力,能夠報告問題並自主修復。例如,代理可以檢測缺失的金鑰或網路阻塞,並採取行動。近期研究中的“自動安裝”是實現這一目標的一個方向。雲代理的能力在過去幾個月顯著提升,預計還將加速發展。Cursor的雲代理讓團隊能夠利用這一廣闊空間,而無需自行構建和維護基礎設施。

展開要點與分析

文章情報

工程師進階

要點

  • 雲代理的執行質量很大程度上取決於其是否擁有完整的開發環境。
  • 採用Temporal實現了耐久執行,將可靠性從一個9提升到兩個9。
  • 將代理迴圈、機器狀態和對話狀態解耦,實現獨立管理。
  • 隨著模型能力提升,代理的腳手架(harness)逐漸從嚴格控制轉向賦予代理更多自主權。

要點與分析由自動化流程生成,可能有誤,請結合原始來源核實。