Cursor於9月10日推出Projects功能，目前為測試版，向所有使用者開放。這項功能鎖定的是跨越多個PR、持續數週甚至數個月的工作：開發新功能、遷移框架，或是從零打造一個完整應用程式。
架構分為兩層。上層是一個協調者代理人，本身不寫程式碼，只負責把工作分派給下層的代理人。按照Cursor的說法，協調者只做委派、不做執行，因此不會被單一任務卡住，隨時可以接收新的指示。下層則是實際撰寫程式碼的子代理人，官方表示一個專案可以指揮數千個。
"It doesn't write code itself but directs other agents that do."
（它本身不寫程式碼，只指揮那些負責寫程式碼的代理人。）
三項底層能力
Projects靠三件事撐起來：
- 雲端優先：專案運行在專屬伺服器上，闔上筆電也不會中斷；
- 共享情境：檔案在雲端與本機之間同步，前面代理人摸清楚的東西，後面的可以直接拿來用；
- 訂閱機制：專案可以盯著一個Slack頻道、按排程定時執行，或是跟著PR狀態自動回應。
Cursor給出三種典型用法。開發新功能時，多個代理人先並行研究現有系統，再分頭實作不同元件；進行遷移時，團隊用它在數百個PR裡逐步替換框架與樣式系統；日常維護時，協調者持續盯著程式碼品質與回歸問題。
設計系統那個範例
Cursor部落格裡寫得最具體的例子是設計系統維護：協調者掃描每一個新PR，把應該收進設計系統的元件抽出來，同一個錯誤第二次出現時，就加上一條lint規則。按Cursor的估計，這類專案一天要處理20到100個PR。
把這個量換算成人力，會是什麼概念。假設仔細審查一個中等規模的PR要花15到30分鐘，一天20個就是5到10小時，一個人勉強能撐住；一天100個就是25到50小時，以每人每天8小時計算，需要三到六名審查人員全職投入。當機器產出的速度提升之後，卡住的環節就會移到審查上，除非團隊願意接受部分PR只通過自動檢查就直接合併。Projects產出的PR裡有多少經過人工審查才合併，Cursor並未說明。
六倍從哪裡來
Cursor提出的成效數字有兩個：公司內部，新使用者合併的PR多出30%；主要靠Projects工作的使用者，合併量是原本的六倍。這兩個數字都來自Cursor自家員工，衡量的只有合併PR的數量，沒有涉及PR大小、返工與回滾，30%對比的基準是什麼也沒有交代。外部團隊的數據目前還拿不到。
價格方面，部落格文章沒有提到Projects是否要另外收費，也沒說數千個子代理人跑起來要按什麼標準計費。在雲端長時間掛著成百上千個代理人，成本不會小，這部分還要等Cursor進一步說明。
兩步接成一條線
放回Cursor這半年的動作裡看，Projects是往下接的一環。4月推出3.0版時，Cursor把IDE重新定位成管理代理人的介面；9月初又讓雲端代理人能夠跑進企業自有的機器裡。Projects把這兩步接了起來：人管協調者，協調者管執行代理人，執行代理人可以在雲端運作，也可以在公司自己的伺服器上運作。
同一天OpenAI推出的Agents API，同樣支援讓主代理人把任務拆給子代理人，但兩家賣的東西不同：OpenAI賣給開發者的是搭建自有代理人的底層基礎，Cursor賣的則是直接替團隊做事的成品。Projects的入口在左側導覽列，官方建議只在跨越多個PR或持續較長時間的工作上使用它。
參考來源：Cursor官方部落格、CocoLoop、MarkTechPost；子代理人規模、PR合併增幅口徑與案例細節皆以Cursor部落格文章核實。