摘要： Cursor 在 4 月 2 日推出 Cursor 3，把介面重寫成以 agents 為中心的 unified workspace，支援 multi-repo 與單一側欄管理本地和雲端任務。新版本提供雙向 handoff、diff 與 PR 管理、內建瀏覽器、插件市集與團隊私有市集。文章提醒公告沒有定價或 benchmark，導入時應先用單一任務驗證側欄與 handoff。
過去這一年，工程師親手改檔案的比重一路下滑，取而代之的是和負責寫掉大部分程式碼的 agent 合作。Cursor 替這條路線取了名字——軟體開發的第三個時代：改進將由成群的 agent 自主出貨。藍圖清晰，官方卻也在同一份公告裡坦承現況仍有落差——工程師至今還在微管理單一 agent，於對話、終端與視窗之間來回奔波，靠自己記住每件事分別發生在哪裡。
4 月 2 日登場的 Cursor 3，就是 Cursor 對這個落差提出的解方：一套專為「用 agents 打造軟體」而生的 unified workspace。照官方的說法，它更快、更乾淨、也更強大，具備 multi-repo 佈局，local 與 cloud agents 之間能順暢交接，而且想回到傳統的 Cursor IDE，任何時候都行。以下逐一拆解每個機制實際動了什麼、這次發布沒有交代的事，以及導入前該衡量的取捨。
拋開 fork：這次從零重寫
Cursor 的出身本身就是線索：當年不做 VS Code 的 extension，而是直接 fork 下來改，圖的就是介面主導權。Cursor 3 把這條思路走得更徹底——新介面並非疊在舊 IDE 之上，而是以 agents 為中心、從零寫起。
這個決定的分量比字面更重。檔案至上的 IDE 裡，agent 只是側欄裡的過客；換到以 agents 為核心的 workspace，瀏覽檔案、檢視 diff、開啟瀏覽器，都成了驗證與深究的憑藉。想回到熟悉的編輯體驗，切回 Cursor IDE 的入口依然在——官方將其定位為漸進遷移，不是逼你非換不可。
一個側欄，收齊所有 agent 任務
新介面原生支援 multi-workspace，人類與 agents 得以橫跨多個 repo 協作。無論任務從 mobile、web、desktop、Slack、GitHub 還是 Linear 發起，所有 local 與 cloud agents 一律列在同一個側欄。cloud agents 交件時會附上 demos 與 screenshots，驗收不必再鑽進 log 裡猜結果。官方補充，這與 cursor.com/agents 的體驗相同，如今直接併入了桌面 app。
再往下看一層，這等於把開發者觀察工作的抽象層級整個抬高：率先映入眼簾的是每個任務的狀態與成果，檔案與終端留到確有需要時才深入。當多個 agent 並行運作，省下的正是切換 context 的成本——那通常才是工程師時間真正的流向。
handoff 雙向皆通：local 與雲端互相搬移
整批新機制裡最貼近日常用途的是 handoff，而且兩個方向都走得通：
| 移動方向 | 合適情境 |
|---|---|
| cloud → local | 想親自動手改程式，或在本機把服務跑起來做互動測試 |
| local → cloud | 任務耗時冗長、闔上筆電也得繼續跑，或者你想先騰出手去做下一件事 |
官方形容 agent 在兩個環境之間搬移「非常快」。模型端的搭檔是 Composer 2——Cursor 自家打造的 frontier coding model，官方給的定位是 usage limits 上限更高、適合快速迭代。handoff 化解的從來不是「雲端比較厲害」這種比較題，而是工作換了環境不必從頭再解釋一遍；對長時任務來說，交接成本往往比模型推理時間更難拿捏。
從 commit 一路到 merged PR，IDE 的看家本領都在
新的 diffs view 用更精簡的 UI 呈現，編輯與審查改動更省時；時機到了就能 stage、commit，接著管理 PRs。讀懂程式碼的基本功同樣一件不少：檔案可以檢視，editor 裡照樣能 go to definition，完整 LSPs 全數支援。此外還有一顆內建 browser，可開啟本機網站、四處導覽並直接對它下 prompt——驗前端成果時格外好用。
官方引 alpha users 的回饋指出：Cursor 3 之所以好用，在於它把 IDE 的精華與較新的 agent-first 能力收進同一個介面。這屬於質性回饋，但與各項機制的設計方向互相印證。
Marketplace：插件生態，外加團隊專屬市集
Marketplace 收錄數以百計的 plugins，能透過 MCPs、skills、subagents 等形式擴充 agent，安裝只要一下；團隊也能自設私有的 team marketplace。於是 agent 的工具箱不再是個人設定檔，而是全隊共同打理的資產——對正要鋪開 agent 工作流的團隊而言，插件有治理入口，比插件數量更要緊。
一場沒端出數字的發布
有一點得老實講明：整份公告看不到定價、百分比或任何 benchmark 數據，連 Composer 2 的 usage limits 也只給了「較高」這個定性說法。檢驗這類發布，抓得住的是機制本身的可驗證性——側欄是否真把各種來源的任務全收攏、handoff 是否真不必重建 context——而非廠商開出的量化支票。「成群 agent 自主出貨」的第三時代終究是官方立場；採用與否，判準仍應放在今天就能實際操作的機制上。
給 builder 的上手路線
啟用不難：把 Cursor 升級後執行 Cmd+Shift+P -> Agents Window。導入節奏上有三個建議。第一，先用單一任務摸熟側欄與 handoff，再考慮多 agent 並行——開的數量多不代表產出跟著多，真正決定成效的是任務邊界與驗收標準。第二，第一批搬上 cloud 的該是你最長的任務：闔上筆電不中斷，這個好處最容易驗證、也最快兌現。第三，團隊若已累積內部 MCP 或 skills，就逕行開設 team marketplace，把插件治理排在推廣工作流之前。
官方也講明白，介面不會就此定稿：模型一旦更強，新的互動模式就會跟著解鎖。對 builder 而言，Cursor 3 值得認真看待的理由不在功能清單的長度，而在它把「多 agent 協作」從願景變成今天就能上手的日常工作台。