Cursor 推出 Projects：常駐協調代理調度子代理，重度用戶 PR 合併六倍

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

9 月 10 日，Cursor 在官方部落格發表新工作架構 Projects，即日起進入公開測試，向所有使用者滾動推送，官方 X 帳號隨後在台北時間 11 日清晨 5 點 31 分同步宣布。這次改動的本體，是把工作的單位從「一次任務一個對話」換成「一個專案、一個常駐的協調代理」：你在同一條持久對話裡下指令，協調代理（coordinator agent）拆解工作、派給一群在雲端執行的子代理（subagents），闔上筆電，任務照樣推進。

官方 X 宣布文把它濃縮成一句話：與其為每個任務開一個新對話，你改為與一位協調代理在單一、持久的對話裡工作；這位代理隨時待命、主動以子代理管理工作，而且會隨時間變得更好。公告對 Projects 的定位也寫得明確：它處理的是「活得比單一對話久」的大型工作，例如一個要發多個 PR 的功能、一場大規模遷移，或一件你人不在時也希望能被處理的工作。入口在 Cursor 左側導覽列，建立專案、描述你想完成的目標，協調代理就接手。初次上手可以先記一個心智模型：把專案想成一位隨時找得到的技術主管，子代理是它底下的施工人員，你的對話則是跟它開的工作會議。

Pin

對話不再是工作的單位，協調代理也不寫程式碼

過去幾年 AI 編程工具的基本節奏，是開一個對話、交代背景、等它跑完、再開下一個。上下文用完就散，隔天的新對話對昨天的踩坑一無所知。Projects 把「協調」與「執行」拆開來處理這件事，公告原文寫得直白：協調代理自己不寫程式碼，只指揮其他寫程式碼的代理；也因為它只委派、不執行，永遠不會被卡住，你隨時能插話改方向。

同日的 changelog 對這個分工補了更具體的描述：協調代理負責規劃工作、派給實作的代理，再把完成的工作帶回來給你檢查；它會替你建立並管理代理，工作需要多少就開多少、彼此平行跑。對使用者來說，角色從盯著單一代理的監工，換成審核者與指揮者，這條分工線也劃出了新的工作紀律：代理群產出的是待你驗收的成品，而非可以直接吞下去的答案。

Pin

讓工作在你關機後繼續的三個設計

公告列出支撐 Projects 的三個核心能力。「預設雲端、需要時本機」排在最前面：每個專案跑在自己的雲端電腦上，關掉筆電不會讓它停下來，也能同時開比你筆電負荷得起的更多子代理；當某件事需要在你機器上驗證，協調代理會在你本機叫起一個本地代理去執行。雲端與本機兩邊，照工作當下的需要互相接手。

共享脈絡（shared context）是另一層。官方的說法是「你不應該每次開始任務都重新帶一次代理上手」：每個專案維護一組檔案，在所有雲端與本機機器間同步，代理把研究成果、產出文件，以及對程式碼庫和你偏好的認識不斷寫進去。公告舉的例子是，只要有一個代理搞清楚怎麼測某個服務，之後每個代理都能直接沿用那套說明；脈絡隨專案成長，協調代理越用越順。想把這類「專案層級共享記憶」抽成獨立檔案帶著走的讀者，可以對照我們先前介紹過的ai-memory 共享專案記憶工具，兩邊把記憶放在不同層級，一個是產品內建，一個是你可自己搬移的檔案。

訂閱（subscriptions）讓它從被動變主動：協調代理可以盯一個 Slack 頻道、照排程執行，或追蹤你所有的 PR，在 CI 壞掉時修復、在 PR 開立或合併時行動。changelog 給的例子更落地：把 Slack 接上、指到錯誤回報頻道，之後每有問題進來，它就自動派工。AI 工具從「你打一句、它動一下」，變成會被事件觸發的常駐工作者。

官方對功能開發的完整生命週期也有描繪：功能開發通常由多個代理先研究系統、把學到的東西記進共享脈絡開場，協調代理接著產出計畫，把實作與測試拆給不同代理平行跑；每一輪回饋都會讓專案更了解你的架構與偏好。功能要驗收時，協調代理可以在你電腦上叫起代理本機試跑；上線之後，同一個專案還能帶著當初所有架構決策的上下文，盯著 log、處理錯誤回報。研究、實作、驗收、維運被收在同一條脈絡裡，這是「活得比對話久」最具體的兌現。

這條路線其實二月就畫好了。Cursor 在 2 月 26 日的願景文（Michael Truell 執筆）提出軟體開發的第三個時代：按鍵自動補全之後是對話式代理，最後交棒給能獨立承接大型任務的代理群；當時並透露內部超過三分之一的合併 PR，已經由雲端上自主運行的代理建立。從 8 月 17 日的 Origin 程式碼託管、9 月 2 日的 self-hosted machines，到 9 月 10 日的 Projects，一個月內把託管、私有機器、專案層調度三塊拼圖接連補上。

六倍這個數字，要連著另一個數字一起讀

公告裡最搶眼的成效宣稱是：以 Projects 為主要工作方式的工程師，PR 合併量達六倍。但同一段還有另一個常被略過的數字：新使用者合併的 PR 多 30%。兩個數字講的是兩個群體，六倍屬於把工作重心整個搬進 Projects 的重度使用者，官方未公布衡量方式與全體平均，這組數字先當內部觀察值看，別直接拿來推估自己的情境。

把二月那個數字跟這次的宣稱放在一起看，趨勢線相當陡：半年前內部已有超過三分之一的合併 PR 由代理建立，現在重度使用者的合併量放到六倍。兩個數字口徑不同，前者是佔比、後者是倍數，但方向一致，代理承接的工作量在 Cursor 內部已是主力等級。問題也因此從「代理能不能做」，移向「怎麼驗收」與「怎麼計價」。

內部使用本身有值得參考的細節。Cursor 團隊已經用 Projects 好幾個月，做過的事包含：數百個 PR 規模的遷移、維持設計系統一致，以及用 Projects 開發 Projects 本身。三種官方總結的使用模式裡，「gardening（園圃維護）」的案例最生動：一位工程師的設計系統專案會掃每個新進 PR，把該進設計系統的元件抽出來，同一個錯誤再犯就補一條 lint 規則；公告寫這個專案「朝每天觸及 20 到 100 個 PR 的規模前進」，這是進行中的目標軌跡，官方並未表示已經達成現況。

遷移（migrations）模式的描述同樣誠實：遷移類工作「好開始、難收尾」，做法是你先跟協調代理一起訂出安全做法，前期逐個 PR 嚴審，隨著修正站得住腳、審查密度遞減，剩下的交給它一路做完。這套敘述把人的角色講得很清楚：把關品質，而不是逐行施工。講得更白一點，生產力的放大來自施工被平行化，驗收與把關仍是人類的份內事，而且件數變多之後，審查本身會成為新的瓶頸與新技能。

哪些工作該交給它，帳單會長在哪裡

可用性先講清楚：beta 版即日起向所有使用者滾動推送，但推送時程沒有公布，帳號上還沒看到 Projects 圖示屬正常現象。入口在左側導覽列，描述完想完成的目標即可開工；官方提醒它最適合「活得比單一對話久」的工作，一次性的小修改不必動用。beta 首波的功能範圍以公告與 changelog 為準：常駐協調、雲端與本機互相接手、共享脈絡，加上盯 Slack 頻道、照排程執行、追蹤 PR 三類訂閱，都在清單內。

計費要看底層。changelog 明言 Projects 由雲端代理（Cloud Agents）驅動，而雲端代理的文件寫得明白：按所選模型的 API 價格計費，上下文視窗可以選，視窗越大、token 用量與成本可能越高，開始使用時會先要求你設定支出上限。同頁的疑難排解也載明，代理跑不起來時的檢查項包含「需在付費 Cursor 方案上」。換句話說，子代理開得越兇、帳單滾得越快，動手前先把支出上限設好，比什麼都重要。也留意一個細節：這套計費說明掛在雲端代理的文件名下，官方還沒有為 Projects 另立條目，之後若出現專屬計費頁，規則要重看一次。已經在追蹤 Cursor 帳單歸因的讀者，可以搭配我們介紹過的CodeBurn AI 編程帳單工具，把錢花在哪個任務看清楚。

Pin

這裡也藏著 Projects 與一般 AI 對話工具最不一樣的成本結構：過去你的成本大致上就是自己的對話用量，現在還要加上一群雲端機器與子代理的用量，而且它們在你下線後照樣消耗。支出上限因此是把「代理群失控燒錢」框住的基本閘門，在「你睡覺、代理工作」的模式下特別重要。

放進同一週的產業脈絡看，方向更清楚：OpenAI 剛把支撐 Codex 的代理框架開放成Agents API 公開測試，把代管沙盒與自架環境做成 API 品項；Cursor 的 Projects 則把同樣的「代理群＋代管環境」包進編輯器的工作流。開發者工具的競爭軸，已經從模型比價移到「誰能把代理部隊的日常維運接過去」。對台灣開發團隊，還有兩個實際問題值得先想：程式碼要在 Cursor 的雲端環境跑，官方 9 月 2 日也另外提供了 self-hosted machines 讓執行留在自己網路內；計費按 API 價滾動，代表試用本身就有成本，跟過去裝個外掛免費玩玩不同。

還沒確定的事，與回查時程

幾件事到目前為止沒有答案：滾動推送（rollout）到每個帳號的時程未載明；30% 與六倍的衡量方式未公開；官方文件站截至 9 月 11 日還沒有 Projects 專頁，現有的雲端代理文件是最接近的參考；beta 期的功能細節與計費規則也都可能再調整。回查時具體看三件事：官方文件站是否補上 Projects 專頁（目前計費與疑難排解都掛在雲端代理文件下）、滾動推送是否完成到所有帳號、beta 是否調整計費或功能範圍。任何一項變動，這篇的結論都要跟著更新；時效性以一週為度，9 月 18 日前建議回查官方文件與 changelog 一次。

現在能做的事依族群分流：免費方案的使用者，等帳號拿到入口、確定願意投入付費用量再試；付費使用者想試，先建一個小專案、把支出上限設低，從一件「活得比對話久」的真實任務開始，小型遷移或例行維護比全新功能更能驗證它的價值；團隊評估者，可以先從園圃維護型的旁支工作試起，別一開始就把核心交付押上去。beta 產品的通則在這裡完全適用：先證明它在你的程式碼庫上靠得住，再放大。

從自動補全到對話代理，再到常駐的代理群，Cursor 把二月寫下的願景變成了左側導覽列上一個按得下去的入口。按下去之後，帳單與驗收會是兩門新功課：前者交給支出上限，後者交給你的審查紀律。