沒KPI反而爆了？Cursor大神一人敲出核心功能！CEO上手7天不宕機，AI編程玩法全變了

整理 | 華衛

昨日，Cursor 的 CEO Michael Truell 在 X 上發帖表示，其在 Cursor 開發環境中，基于 GPT-5.2 構建了一款瀏覽器，并實現了連續一周無間斷運行。

據介紹，這款瀏覽器的代碼總量超 300 萬行，目前已具備基礎可用性。其渲染引擎為純 Rust 語言從零開發，涵蓋 HTML 解析、CSS 級聯、布局排版、文本整形、繪制渲染等核心能力，并內置了定制化 JavaScript 虛擬機。網友紛紛表示，“既然我們可以自己制作個性化瀏覽器，為什么還要花時間下載 Chrome 呢？”

同時，Truell 在帖子下方分享了一篇主題是“擴展長時間運行的自主編碼能力”的博客文章。博客中指出，Cursor 一直在嘗試讓編碼 Agent 一運行就是數周，且完全自主地工作。通過在單個項目上同時運行數百個并發 Agent、協調它們的工作，并觀察它們寫出超過一百萬行代碼和數萬億個 token，其得出的結論是：結構太少，Agent 會互相沖突、重復勞動、不斷偏離；結構太多，則會讓系統變得脆弱。運行框架和模型本身固然重要，但提示詞更重要。

從零開始構建出一個瀏覽器，就是他們在測試過程中的產物。據稱，“Agent 持續運行了將近一周，在 1000 個文件中寫出了超過 100 萬行代碼。”對此，有網友提出，“可以用 Cursor 來創建 Cursor 嗎？”而這似乎也真的正在“發生”著。

近期， Cursor 的工程負責人 Jason Ginsberg 接受了 LinkedIn 的聯合創始人兼首席執行官 Harrison Chase 的采訪。談話中，他們圍繞 Agent 和 AI 編程等話題展開交流，不僅揭秘了 Cursor 團隊內部通過并行運行多個 Agent 的大型“甩活兒”工作模式，同時透露了 Cursor 未來的開發方向、最終交互模式、產品路線圖及人員規劃。在對話尾聲，Ginsberg 還回答了許多來自訪談現場的開放問題。

下面是詳細對話內容，我們在不改變原意的基礎上進行了翻譯和刪減，以饗讀者。

一年多時間，

編碼 Agent“翻天覆地”

Harrison Chase：Jason，你能跟大家簡單介紹一下自己嗎？也給大家講講 Cursor 是什么吧。

Jason Ginsberg：好的。我目前在做一款 AI 編程工具，已經在 Cursor 工作了六個月，擔任該產品的工程負責人。不過說實話，我日常的大部分時間還是在寫代碼和做設計工作。在加入 Cursor 之前，我在 Notion 負責 Notion Mail 相關工作。幾年前，我創辦了一家名為 Skiff 的公司，后來這家公司被 Notion 收購了。所以，我一直都在從事產品開發相關的工作，而且主要聚焦在生產力工具領域。

Harrison Chase：非常棒。我有很多話題想和你探討。要不我先拋磚引玉，問問你對編碼 Agent 的發展歷程，以及這些年來人機交互模式演變的看法吧。你們可以說是這個領域的先行者之一，我認為編碼 Agent 的發展經歷了幾個階段的轉變：從最初的代碼自動補全，到集成在集成開發環境（IDE）中的對話式交互，再到如今出現的各類終端工具，以及基于云端的異步 Agent。我很想聽聽你的看法，你覺得這樣概括其用戶體驗的演變歷程是否準確？或者你們團隊是如何看待這一發展過程的？

Jason Ginsberg：我認為編碼 Agent 的發展確實可以用 “翻天覆地” 來形容，而且這些變革基本上都是在一年多一點的時間里發生的。正如你所說，Cursor 最早開啟了代碼自動補全的先河，這種模式主要是在逐行的層面上提供輔助，適用范圍也基本局限在單個文件內。而此后，幾乎每隔幾個月，我們就不得不提升產品的抽象層級，這其實是一個極具挑戰性的產品設計難題。顯然，Agent 的出現讓開發者能夠在多個文件之間靈活切換，并且可以放心地讓 Agent 自主完成代碼修改工作。

在過去兩個月左右的時間里，我發現行業又出現了新的轉變：開發者現在已經能夠做到從項目啟動到結束全程信任 Agent，并且會對整個代碼庫中多個文件的內容進行批量審核。因此，我們不得不對產品的整體布局進行大幅重新設計，將核心從逐行的代碼差異對比，轉向更偏向代碼審查的模式。

展望未來的產品開發方向，我們的工作重心其實會更多地放在多 Agent 協同運行上。我們需要實現的是，能夠快速驗證這些 Agent 是否在正常運行，并且可以讓它們并行工作，同時避免受到當前單一對話模式下各種選項和選擇的束縛。

Harrison Chase：推動這些變革的核心因素是什么？僅僅是因為大模型的性能變得越來越好，還是有其他更多的影響因素？

Jason Ginsberg：我認為大模型性能的提升是一個很關鍵的因素，這讓開發者能夠更加信任 Agent 編寫的代碼質量。要知道，以前大家必須對 Agent 生成的代碼進行非常全面細致的審查。

同時，現在也有了更完善的代碼審查工具。比如我們有 BugBot，市場上其實還有很多類似的工具，它們都能夠自動檢查代碼中存在的問題。

此外，我覺得從行業文化層面來看，開發者們對 Agent 工具的接受度和使用信心也在不斷增強，甚至可以說已經 “上癮” 于這類工具帶來的便捷。而且，一旦習慣了完全依賴 Agent 進行編碼的工作模式，再切換回傳統的編碼方式其實是很困難的。所以現在，我們能看到越來越多的開發者已經將 Agent 輔助編程作為默認的工作方式。

最頂尖工程師的干活秘訣：

全靠 Agent？

Harrison Chase：你觀察到大家使用 Cursor 的方式都有哪些不同？或者你自己平時是怎么使用 Cursor 的？

Jason Ginsberg：其實在我們公司內部，工程師們使用 Cursor 的方式就五花八門。甚至團隊里有幾位工程師，他們完全不使用 Cursor 的 Agent 功能，比如負責安全和基礎設施的同事。所以，確實有一部分用戶非常依賴代碼自動補全功能，日常使用中大部分操作都是基于補全功能完成的。但令人意外的是，我發現團隊里一些最頂尖的工程師，我們稱他們為 “核心用戶”，他們做任何工作都會完全依賴 Agent，甚至會同時運行多個 Agent 并行處理任務。

至于我個人的使用習慣，我并不會去設計那些復雜繁瑣的提示詞，也沒有什么所謂的 “Agent 使用秘籍”。我寫的提示詞往往都很簡短，甚至還會帶有拼寫錯誤。我會針對手頭不同的工作任務，或者同一個問題的不同模塊，同時啟動多個 Agent，然后等待它們返回結果。

目前我用得最多的是我們今天剛剛發布的一個新功能：調試模式。這個模式下，Agent 能夠通過生成日志來進行自我評估，之后開發者復現相關操作步驟，Agent 就會通過查看日志判斷問題是否得到解決。這個功能非常實用，因為它相當于通過投入算力去不斷嘗試解決問題，最終攻克那些手動排查起來極為棘手的難題。

Harrison Chase：調試模式具體是什么樣的？為什么需要專門設置這樣一個模式？難道不能自動完成調試嗎？直接給 Agent 下達調試指令不也可以嗎？

Jason Ginsberg：其實我也認同你的這個想法。所以在開發調試模式的時候，我們內部確實有過不少爭論。主要原因在于，Cursor 目前已經有很多功能模式了，如規劃模式、詢問模式等等，這些模式其實不太容易被用戶發現。我們一直認為，這些模式都很實用，理想的狀態應該是，Agent 能夠根據用戶的操作場景，自動匹配并啟用最合適的模式，無需用戶手動切換。

而現階段調試模式之所以需要手動開啟，是因為它的交互方式比較特殊。在運行過程中，Agent 會暫停當前的工作，向用戶提問以獲取反饋。如果用戶不熟悉這種交互邏輯，可能會覺得比較困擾。

Harrison Chase：Agent 具體會詢問哪些問題，又需要用戶提供什么樣的反饋呢？

Jason Ginsberg：我舉個例子吧。假設我正在開發一個前端應用，遇到了一個很讓人頭疼的問題：菜單總是在左上角彈出。這時候我會對Agent說：“這個菜單需要錨定到按鈕的位置。” 隨后，Agent 會啟動服務器，并在整個代碼庫中添加大量日志，同時提出一系列可能導致該問題的假設，如 “可能是某個定位參數設置錯誤”、“可能是事件綁定邏輯有問題” 等。之后，Agent 會提示我：“麻煩你點擊這個按鈕，打開菜單，看看問題是否解決。” 如果我反饋問題依然存在，Agent 就會查看生成的日志，然后分析判斷：“這個假設成立，那兩個假設不成立”。通常這樣反復兩三次之后，Agent 往往就能找出并解決問題。

Harrison Chase：你覺得人類還需要手動操作多久？就不能讓 Agent 自主完成點擊、測試這類操作嗎？

Jason Ginsberg：一兩個月內，畢竟這個行業的發展速度實在太快了。

Harrison Chase：剛才你提到了 Agent 的多種不同模式，比如規劃模式、解釋模式、調試模式等等。這些模式在實際應用中到底意味著什么？難道只是為 Agent 設置不同的提示詞這么簡單嗎？還是說背后有更復雜的邏輯？

Jason Ginsberg：很多時候，確實就是修改一下系統層面的提示詞。不過在某些情況下，我們也需要對用戶界面進行相應的調整。比如規劃模式現在也加入了交互提問功能，運行過程中會主動打斷用戶操作，尋求反饋。用戶有時也可以自行設置參數，如調整 Agent 打斷的頻率等。再比如詢問模式，它不只是依賴特定的系統提示詞，還會限制 Agent 調用某些與文件編輯相關的工具，以此來保證功能的穩定性和可靠性。

Harrison Chase：回到之前的話題，關于大家使用 Cursor 的不同方式，你覺得未來使用編碼 Agent 或者說 Cursor，存在所謂的 “最佳方式” 嗎？

Jason Ginsberg：我覺得并沒有什么 “最佳方式”，具體的使用方法很大程度上取決于工程師的個人工作習慣以及他們所處理的具體工作內容。目前行業里，既有異步運行Agent的應用場景，也有開發者深度參與、實時交互的模式，就像一邊編程、一邊像畫畫一樣實時調整代碼或者進行可視化的編輯操作。不過我經常在推特上看到一些所謂的 “Agent 使用技巧”，其實對此我是有點持保留態度的。很多人會說 “這才是使用 Agent 的最佳方式”，但在我看來，這些技巧往往是憑空杜撰的。

我們團隊內部其實并不會使用那些冗長復雜的提示詞，也不會采用多階段規劃的策略。大多數時候，我們都是快速迭代，如果 Agent 運行的結果不理想，就直接終止進程，重新啟動 Agent。通常這種方式的效率是最高的。

自然 “嘮嗑”是 Cursor

最終交互模式？

Harrison Chase：如果讓你預測一下一年后的情況，你認為開發者在 IDE、終端以及其他形態的載體上使用 Cursor 的時間占比會是怎樣的？

Jason Ginsberg：當然，我肯定會帶有一定的主觀偏向性。但我認為，終端工具并不會成為用戶的首選。我覺得，真正驅動行業發展的是用戶對Agent的信任度不斷提升，他們更希望等到Agent完成所有工作后再查看最終的修改結果，然后決定是否采納，同時也愿意讓 Agent 運行更長的時間，以實現更智能的處理。

而 IDE 之所以至關重要，是因為它是為整個軟件開發周期量身打造的工具。從項目的構思規劃，到運行代碼修改、查看代碼內容、清晰對比代碼差異、提交代碼合并請求，再到在瀏覽器中預覽效果所有這些環節，都可以無縫集成在 IDE 的模塊化功能之中。這一點其實很容易被忽視，畢竟 IDE 的這些功能是經過了數十年的發展才逐步完善起來的。

我認為，當前行業的一個明顯趨勢是，產品層面的設計變得越來越重要。現在 Cursor 用戶使用頻率最高的功能，如規劃模式，其實都需要可視化編輯器的支持，用戶需要能夠在編輯器中添加注釋，并進行實時交互。一旦脫離了按鈕、彈窗和菜單這些可視化交互元素，用戶與工具的交互難度會大大增加。

不過，我覺得未來并非所有操作都必須局限在筆記本電腦的 IDE 中完成。這種模式并不會被完全取代，具體的使用場景會根據實際需求靈活變化，適用的場景也會更加廣泛。用戶在更多場景下，都能夠使用到 Cursor 這樣的工具。

Harrison Chase：未來會有更多場景都能用上像 Cursor 這樣的工具。你們應該有對應的官網吧？用戶可以直接在網頁上進行交互操作，是這個思路嗎？

Jason Ginsberg：對，我們確實有官網。這么做的原因是用戶可以通過手機等設備隨時隨地訪問。我覺得在不遠的將來，用戶完全可以戴著 AirPods，開啟語音模式，和Agent實時溝通、碰撞想法，讓Agent不斷優化方案。等用戶到了辦公室，打開筆記本電腦，就已經有一堆代碼修改記錄或者演示視頻等著審核了，到時候只需要簡單確認通過或者駁回就行。如果某些細節還需要微調，再把項目下載到本地修改就好。

Harrison Chase：我認為 Cursor 真正的優勢，在于圍繞 Agent 交互打造的整套設計和用戶體驗體系。你之前在 Notion 工作過，我記得即便是在生成式 AI 普及之前，Notion 的設計和用戶體驗就已經廣受認可了。當然，他們在生成式 AI 時代也很好地完成了轉型。從一家在生成式 AI 普及前就擁有出色設計積淀且順利完成轉型的公司，再到如今專注 Agent 相關工作，你覺得 Agent 的出現給產品設計和用戶體驗帶來了哪些變化？現在的工作模式和之前有相似之處嗎？

Jason Ginsberg：我覺得總體來說，我們產品的大部分設計其實并不是 AI 專屬的。要知道，產品可用的交互組件和用戶體驗模式就那么多，市面上的應用本質上也都是基于一些傳統的模式搭建的，如收件箱、儀表盤、聊天界面，這些都是很成熟的設計。所以我們的工作核心，更多是把這些現有的設計模式進行合理組合，然后在產品中恰當地呈現出來。這一點和 Notion 的產品理念是相通的，同時也是 Cursor 和集成開發環境（IDE）的核心特質：極高的模塊化程度。

作為用戶，你會發現每個人的 IDE 界面布局都可以千差萬別。你可以自定義面板布局，把任意組件拖放到任意位置，和坐在你旁邊的同事設置出完全不同的界面。我認為這種模塊化設計對產品的適應性至關重要，畢竟如我之前所說，Agent 的能力發展日新月異，用戶對產品的需求和期待幾乎每隔幾周就會發生變化。幾個月前我們推出 Cursor 2.0 的時候，并沒有把原來的產品推倒重來，只是把各個功能模塊重新組合，調整為側邊欄收件箱式的管理布局，同時優化了聊天界面的信息密度而已。

Harrison Chase：聽你這么說，很多組件的底層邏輯其實是相通的。那有沒有出現新的組件？或者某些組件的優先級發生了變化？畢竟這些組件最初都是為 “人類與軟件交互”“人類通過軟件協作” 的場景設計的，現在加入了 Agent 這個新角色。這其中有沒有產生什么新的變化？還是說其實本質上沒有太大不同？

Jason Ginsberg：我認為底層的設計邏輯和核心要素其實沒有變，關鍵變化在于誰在主導界面交互。而在這個核心框架下，其實可以演變出無數種交互形式。就拿交互的抽象層級來說，一年前大家使用Agent的時候，都恨不得盯著它的每一步操作，全程 “盯梢”。但現在 Agent 的操作步驟變得無比繁雜，用戶根本看不過來。所以我們需要優化信息呈現方式：如何對操作步驟進行分組？如何提煉關鍵信息？

當用戶足夠信任 Agent 的操作后，我們就需要把重點放在文件的實際修改內容上，并且為這些修改添加更詳細的注釋說明。當然，我們也可以進一步提升交互的靈活度，比如聊天對象不再局限于單個 Agent，而是可以同時和多個 Agent 對話。這就需要一套更智能的后臺交互邏輯來支撐 ，系統要能識別用戶在和哪個子 Agent 對話，并且協調這些 Agent 完成對應的修改。未來這種交互的抽象層級還會不斷提升。

Harrison Chase：你覺得交互的抽象層級最高能達到什么程度？我知道預測未來很難，但還是想聽聽你的看法。

Jason Ginsberg：我覺得未來，我們現在看到的各種操作選項，如選擇模型、選擇功能模式、選擇運行環境這些都會逐漸消失。最終的交互模式會變得像和真人對話一樣自然。但這并不意味著任何人都能隨便寫代碼，在那個階段，這個工具依然是為專業工程師服務的。因為你還是需要具備專業的行業術語知識，清楚自己想要修改的內容是什么。做產品的人，要明確自己想要的工作流程和功能需求；做基礎設施的人，要足夠了解代碼庫，知道什么樣的架構和系統設計最適合當前要開發的項目。

而且我想強調的是，隨著抽象層級的提升，我們并不會摒棄現有的功能。用戶依然可以隨時深入底層，查看細節、調整參數。只是產品的默認交互方式會不斷優化升級。

Cursor 內部工作揭秘：

少審代碼、高頻反饋

Harrison Chase：你之前提到了人類在 Agent 工作流程中的角色，比如查看代碼差異、進行代碼審查。你覺得 AI 會給代碼審查工作帶來哪些改變？

Jason Ginsberg：首先，就我們產品團隊的工作模式來說，現在人工審查的比重已經大幅降低了。我們有一個叫 BugBot 的工具，它會自動檢測代碼問題，并且自主完成修復，還會在持續集成（CI）流程中不斷迭代優化。這個工具的表現非常出色，也讓我們對 AI 審查的代碼質量更有信心。

其次是信息的語義化分組。用戶查看代碼差異時，可以清晰地看到 Agent 做了哪些修改。我們甚至可以展示 Agent 的原始指令，更理想的狀態是，Agent 能夠像人類一樣，在處理大型代碼合并請求時，為每一處修改附上注釋，說明這么做的原因。我覺得這雖然算不上顛覆性的變革，但確實能給代碼審查工作帶來顯著的優化。

Harrison Chase：出于好奇，我想問一下，Cursor 的工程師用 Cursor 寫代碼，用 BugBot 審查代碼，那他們還需要和其他工程師溝通協作嗎？

Jason Ginsberg：哈哈，這個問題很有意思。如果你以工程師的身份加入 Cursor，會立刻發現一個現象：所有人都在深度使用自家產品。我記得我入職第一周的時候，修改了一個快捷鍵設置。那個快捷鍵是 Alt+Shift+Command+J，非常冷門，我當時覺得選這個鍵肯定沒人會注意到。結果剛改完不到半分鐘，就有三個同事在 Slack 上發來消息：“你改的這個快捷鍵直接打亂了我的工作流程！到底怎么回事？”幾乎任何產品改動，都會立刻收到同事們的強烈反饋。我覺得這其實是一件好事，大家就是在這種高頻的反饋和交流中，快速推進產品迭代的。

Harrison Chase：從組織管理的角度，你們有沒有采取什么措施來鼓勵或者引導這種高頻反饋的協作模式？畢竟大量的反饋涌進來，有時候也會讓人應接不暇。

Jason Ginsberg：在我創辦自己的公司之前，工程師們也會用郵件溝通，但用得并不多。大家甚至會說：“郵件只用來收垃圾郵件和購物通知，可別用它來發長篇大論的工作內容。”而在Agent這個賽道工作，其實完全不需要依賴郵件這種低效的溝通方式。我們團隊的所有人都全身心投入工作，畢竟這是一個競爭非常激烈的領域，大家都對產品開發充滿熱情，會自然而然地用各種即時溝通工具協作。

另外，我在規劃產品功能時，會遵循一個核心原則：我能開發什么功能，讓自己的日常工作更輕松？ 具體來說，就是思考 “做什么能幫我明天更高效地完成工作，不用再處理那些煩人的報錯和問題”。這個原則指導著我們的大部分工作。畢竟這種功能開發出來之后，我們自己能立刻受益，比如修復了一個煩人的漏洞，以后上班就不用再被這個問題困擾了。

迭代狂飆背后，核心功能

竟來自員工 “自嗨”？

Harrison Chase：你覺得你們的產品路線圖，有多大比例是由 “讓自己工作更輕松” 這個需求驅動的？又有多大比例是來自外部用戶的需求？這個比例隨著公司發展有變化嗎？

Jason Ginsberg：這個比例確實隨著公司規模的擴大在變化。現在我們也會制定月度的產品路線圖和目標，但說實話，我們很多核心功能都來自自下而上的創新。比如 Cursor 的Agent功能，這可以說是大家提到 Cursor 時最先想到的核心功能。這個功能是我們團隊的一個人開發的，最開始所有人都不看好這個想法，但他很快做出了原型。大家試用之后都驚嘆：“哇，這東西居然真的能用！”

我之前提到的調試模式也是如此。感恩節假期的時候我閑著沒事，就開發了這個自己很需要的功能，現在這個功能也即將上線。這些功能的開發初衷，都是為了解決團隊內部的需求。我們判斷一個功能是否具備發布條件，一個重要的衡量標準就是內部的使用率和認可度。

Harrison Chase：你們的產品迭代速度快得驚人，是怎么保持這種高效的開發節奏的？

Jason Ginsberg：說實話，我們的工作流程其實非常精簡，沒有太多繁瑣的制度。公司里雖然有幾間會議室，也有一兩位產品經理，但我們很少通過撰寫文檔或者開對齊會議來推進工作，大部分的討論和決策都是在代碼層面完成的。而這一切能夠實現的核心原因，是我們對人才的極高要求。今年年初的時候，公司總共也就 20 人左右。之所以團隊規模增長緩慢，就是因為我們的招聘門檻高到近乎苛刻。我們會反復評估：這個人很優秀，但他能成為團隊里最頂尖的那批人嗎？

正因為團隊里的每個人都足夠出色，所以我們可以放心地把任務交給任何一個人。團隊成員的主觀能動性都極強，從提出想法、設計用戶體驗，到在推特上回復用戶的支持請求、和企業客戶溝通需求，再到最終將功能落地，整個流程都能獨立完成。所以說，我們能保持這樣的速度，歸根結底還是人的因素。

Harrison Chase：你們是如何規劃產品路線圖的？你剛才提到了以月為單位的規劃周期，這是目前的常規規劃時長嗎？有沒有更長期的規劃？另外，行業技術迭代的速度實在太快了，你們是如何平衡 “跟進現有技術浪潮” 和 “實現技術跨越式發展” 這兩者的？會不會主動預判技術趨勢，提前布局未來方向？

Jason Ginsberg：我們確實會投入不少精力去思考未來，比如預判未來三個月可能實現的技術突破，然后主動押注相關方向，團隊里有相當一部分人都在做這類前瞻性的工作。我們制定的月度路線圖更多是圍繞核心產品功能展開，聚焦于用戶的實際需求以及那些能優化日常使用體驗的功能。而那些需要投入兩個月時間重構底層邏輯的重大項目，則會納入更長期的規劃范疇。

此外，我們的應變能力其實非常強。

有時候我們會提前拿到新模型的測試版本，試用之后如果發現它在某些方面表現特別出色，團隊成員往往會主動利用周末時間加班，爭取在新模型正式發布前就完成相關功能的開發。很多重要功能其實幾天之內就能搭建完成。

Harrison Chase：說到模型，你們發布了自研的 Composer 模型。開發這個模型的初衷是什么？目前用戶的使用情況如何？這個模型有沒有改變大家使用 Cursor 的習慣？

Jason Ginsberg：我們發現，工程師使用我們產品時的編碼場景，需要有專門適配的模型來支撐。Composer 模型就是針對這類場景打造的，它定位非常明確，具備速度快、質量高、邏輯智能三大特點，尤其適合 “人機實時協作” 場景。我自己做前端開發時就經常用它，因為我需要頻繁做出細微的交互設計決策，這就要求 Agent 能在幾秒內給出反饋。Composer 就像一個高效的協作伙伴，能快速響應需求、碰撞想法，和那些適用于長周期異步任務的模型形成了很好的互補。

Harrison Chase：Cursor 的 Agent 相關研發工作是全員參與，還是有專門的團隊負責？

Jason Ginsberg：我們確實有專門的團隊負責 Agent 的性能優化，他們主要聚焦于工具鏈、調度框架的搭建以及效果評估。但正如我之前所說，我們的團隊架構并不僵化，沒有嚴格限制大家的工作范圍。比如核心產品團隊的工程師在開發規劃模式時，如果需要對Agent進行調整，就會和Agent團隊密切協作。而且在開發過程中，我們依然會深度使用自家產品進行測試，團隊成員會分享使用感受，以此來評估功能的實際效果。

Harrison Chase：無論是 Agent 團隊的成員，還是其他團隊中擅長 Agent 研發的工程師，他們身上有沒有什么共同特質？他們的專業背景或者個人能力有沒有什么特別之處？

Jason Ginsberg：我覺得他們大多是偏產品方向的人才，而不是傳統意義上的機器學習或算法研究專家。這些人經常在不同團隊之間輪崗，因為Agent研發需要對用戶的最終使用體驗有很強的直覺，同時還要能準確解讀團隊的反饋意見。

Harrison Chase：上周你們和 OpenAI 合作發布了一篇博客，內容是針對 OpenAI 的新模型優化 Cursor 的 Agent 調度框架。我在推特上經常看到大家討論 “Agent 調度框架” 這個概念。你們是如何看待模型的底層支撐架構的？這類架構是否需要和特定模型深度綁定？比如 Composer 模型和 CodeLlama 模型，對應的架構會不會有很大差異？

Jason Ginsberg：我其實沒有深度參與這方面的工作，但據我了解，我們的核心目標是打造高度靈活的架構。畢竟我們需要不斷嘗試新技術、新功能模式，所以架構必須能夠隨著模型能力的升級快速適配。

Harrison Chase：很有道理。畢竟整個行業都在飛速變化。

開放問答

提問者 1：剛才提到了新增的可視化瀏覽器功能，我發現有些工具比如 Lovable 也有類似的功能。請問這個功能是朝著 “沉浸式可視化編碼” 的方向發展嗎？

Jason Ginsberg：我覺得它并不是為沉浸式可視化編碼設計的。就像我之前說的，這個功能最初是我為自己開發的，我本身就是一名做產品的工程師，它的核心用戶群體其實是專業工程師和設計師。大家在開發應用時，肯定都遇到過這種情況：精心設計的界面，最后卻變成了大家都看膩了的紫黃漸變配色。這個功能就是為了讓大家能夠精準把控細節，比如把內邊距調整到精確的像素值。它為用戶提供了一套更直觀的 “視覺化操作語言”，比純文本指令的精度更高。

而且就算不使用側邊欄，你也可以直接點擊頁面元素，隨時輸入提示詞下達指令。借助這個功能，你可以在幾秒內同時啟動六個 Agent。如果開啟熱重載功能，你的網站會實時呈現修改效果，用起來其實還挺有意思的。

提問者 2：我特別喜歡你們的瀏覽器 Agent，一直在用。但我發現一個小瑕疵：我想持續迭代優化設計方案，可 Agent 總是會中斷我的工作，直接提交代碼合并請求。未來有沒有可能實現不間斷的持續迭代？

Jason Ginsberg：當然可以。未來的發展方向就是讓 Agent 具備自主評估能力，根據需求長時間持續運行、循環迭代。現在的調試模式還需要人工點擊按鈕來確認日志信息，但這只是過渡方案。理想的狀態是，Agent能夠自主完成評估、迭代，直到徹底解決問題。

提問者 3：我不知道你是否深度參與 Agent 相關的研發工作，但我注意到 Cursor 的內存管理功能做得很好。它可以根據工程師個人、部門乃至整個公司的偏好、規則和流程，自主管理相關信息。我們都知道，信息和上下文對 Agent 來說至關重要。請問你們有沒有計劃進一步拓展和升級這個功能？尤其是在長上下文處理方面，你們有什么思路？

Jason Ginsberg：我們正在進行大量的實驗和探索。目前已經落地了規則管理、內存記憶、技能庫等多個功能模塊。現階段，我們主要在研究高效的信息摘要技術。另外，借助我們的自研模型，我們也在探索讓模型自主識別對話或代碼中反復出現的關鍵信息。當然，跨組織的信息共享功能也很值得探索。不過這里有個需要注意的點，相關規則和信息可能會隨著模型的迭代而過時。所以我們必須確保用戶能夠輕松更新這些內容，避免被過時的規則束縛。

提問者 4：關于你們發布的 Composer 模型，我認識一些開發者，他們基于 Gemini 模型微調了一個醫療領域的專用模型。但他們發現，這個微調后的模型效果還不如直接用原生 Gemini 模型做單次提示詞調用。他們分析的原因是，微調模型需要持續維護，要跟上 Gemini 等基礎模型的更新節奏。請問你們是如何制定策略，確保 Composer 模型不會落伍的？

Jason Ginsberg：你說的是 Composer 模型，對吧？我們會持續對它進行迭代優化，它并不是一個靜態的模型。我們的核心關注點，是在速度和智能之間找到最佳平衡點，滿足 Cursor 用戶在大部分場景下的需求。不過在長上下文處理這類特定領域，我們確實還有提升空間。

提問者 5：我自己是產品經理，一直在用 Cursor 做原型開發，甚至在團隊里還客串設計師，用它替代 Figma。我很好奇，有沒有用戶是在使用 Cursor 之前，從未安裝過任何集成開發環境（IDE）的？這類用戶會不會成為你們未來重點關注的群體？畢竟現在的編碼 Agent 已經足夠強大，很多工作都能在上面完成。

Jason Ginsberg：坦白說，我們目前并沒有把這類用戶作為核心關注點。當然，我們認同工具的使用門檻確實需要不斷降低，而且 Cursor 的易用性也在持續提升，比如新增的瀏覽器工具對設計師就很友好。但我們的核心目標，其實是賦能頂尖工程師。我們一直在思考：如何讓世界上最優秀的工程師變得更加強大？在這個過程中，我們開發的工具自然會惠及更多人群。不過在產品優化方面，我們確實還有很多工作要做，如優化新手引導和環境配置流程。畢竟設計師和產品經理在配置 GitHub 等工具時，經常會遇到困難。我們希望通過優化這些環節，吸引更多用戶嘗試 Cursor。

提問者 6：我一直在嘗試用 Cursor 做智能合約的驗證矩陣構建和試運行邏輯測試。請問在深度質量檢測和安全加固方面，有沒有什么不太為人知的實用工作流可以推薦？或者剛才提到的調試工具能不能派上用場？我對智能合約的質量檢測特別感興趣。

Jason Ginsberg：說實話，我們正在嘗試讓 Agent 自主完成測試工作，不過這項功能目前還沒有完全發布。對于從事質量檢測工作的人員來說，我強烈推薦試試我們剛發布的調試模式。這個功能定位問題的邏輯非常清晰，幾乎可以說是確定性的，用起來會很有幫助。

提問者 7：您認為未來兩到四個月，Cursor 面臨的最大機遇是什么？會不會是語音 Agent？

Jason Ginsberg：我覺得機遇不在于語音 Agent。用戶現階段最核心的需求，其實是讓 Agent 變得更智能、運行時間更長、能處理的任務更多。現在的很多 Agent，本質上只是在 “讀取代碼”，并不能真正判斷修改后的代碼是否有效。未來的發展空間非常大，我們可以投入更多算力，讓 Agent 承擔更多人類目前負責的校驗工作。我覺得未來三到六個月，整個行業都會迎來巨大的變革，非常值得期待。

https://www.youtube.com/watch?v=dKSGK-fPFyU

聲明：本文為 AI 前線整理，不代表平臺觀點，未經許可禁止轉載。

會議推薦

InfoQ 2026 全年會議規劃已上線！從 AI Infra 到 Agentic AI，從 AI 工程化到產業落地，從技術前沿到行業應用，全面覆蓋 AI 與軟件開發核心賽道！集結全球技術先鋒，拆解真實生產案例、深挖技術與產業落地痛點，探索前沿領域、聚焦產業賦能，獲取實戰落地方案與前瞻產業洞察，高效實現技術價值轉化。把握行業變革關鍵節點，搶占 2026 智能升級發展先機！

今日薦文

你也「在看」嗎？