Cursor Projects 多人協作指南（2026 Beta）

2026 年 11 月 10 日，Cursor 將 Projects 從單人協調工具，重構成可供團隊共同作業的多人工作空間。現在，你的協調代理可與隊友的協調代理互傳訊息、標示重疊的程式碼變更，並交接尚未完成的 pull request。不過，若要安全地導入這套流程，你需要 Teams 帳號、Cursor 3.26.13 以上版本，還得先訂好共享上下文檔案的規範，避免某個代理未經確認的假設覆寫了其他工程師在 repository 中的計畫。

11 月 10 日改了什麼：從單一協調者走向多人協作

Cursor Multiplayer Projects 將 2026 年 9 月 10 日推出、限單一使用者的 Projects beta，升級為多人共用工作空間。每位隊友都能操作一個獨立的一對一協調者聊天，同時共用同一個 Task Board 與 Project Agent Store（/cursor/stores/self）。依據官方 Cursor Projects 文件，11 月 10 日的更新從八個核心面向，將個人的執行管道與團隊共享狀態分開：

使用資格、邀請方式與兩階段建立流程

依Cursor Projects 文件說明，要分享多人 Project，必須使用 Cursor Teams 或 Enterprise 帳號、3.26.13 以上用戶端版本，而且每位受邀者都要各自擁有 repository 存取權。Free、Plus 與 Legacy Hobby 方案無法使用多人分享；若啟用 Privacy Mode (Legacy)、Project 在自架機器上執行，或 Project 已封存，也無法邀請隊友。

第一階段：建立基礎 Project（4 個步驟）

邀請協作者之前，Project 擁有者要先在 Cursor 的 Agents Window 中初始化工作空間：

1. 在左側導覽列開啟 Projects：開啟 Agents Window，在側欄找到 Projects，然後選擇 New Project。
2. 為 Project 命名：選擇圖示，並填入範圍明確、以成果為導向的名稱；若留白，預設名稱為 New Project。不要為每個 repository 建一個龐大的單一 Project，而應按交付項目拆分，例如 schema migration、多個 PR 組成的功能，或例行 CI 維護各自建立 Project。
3. 選擇 Workspace 與 Coordinator Model：在 Workspace 下選取目標 GitHub repository；若尚未連結 GitHub，請點選 Connect GitHub。接著在 Model 下選擇擔任協調者的模型。
4. 點選 Create Project：Cursor 會為此 Project 配置一台雲端電腦，並開啟你與協調代理的一對一對話串。

若你已在符合資格的頂層 Cloud Agent 聊天中開始釐清工作範圍，可將該聊天從側欄拖到 Project 列上；或開啟其側欄選單，選擇 Add to Project，讓協調者讀取先前的對話記錄。若對本機聊天使用此選項，Cursor 會先將它轉換為 Remote Control，再加入 Project。

第二階段：3 步驟邀請隊友

Project 啟用並連上 repository 後，擁有者或任何既有成員都能依照文件中的三個步驟邀請隊友：

1. 開啟邀請選單：在 Project 頂端選擇 Invite。首次發出邀請後，這個按鈕會改為一排頭像。
2. 邀請隊友或複製分享連結：在 Invite teammates to this project 下方，依姓名或 email 搜尋隊友並送出邀請；也可選擇 Copy link，將 Project URL 分享到 Slack 或 Linear。
3. 隊友接受邀請並取得專屬聊天：受邀者在 Project 邀請卡上點選 Accept Invite 後，便會取得自己的 Project 聊天、自己的協調代理，以及共享 Project context 的讀寫權限。

成員與連結的存取控制

存取邊界同時由 Cursor 團隊與 Git repository 層級控管：

• 必須同隊且有 repository 權限：個人帳號使用者與其他 Cursor team 的開發者無法加入。受邀隊友也必須自行擁有 Project repository 的存取權。
• 撤銷外流連結：只有既有 Project 成員可以複製邀請連結。若連結被過度散布，Project 擁有者可開啟邀請選單，選擇 Reset Share Link，使所有舊連結失效。
• 離開或移除成員：任何參與者都可從側欄選單選擇 Leave Project，之後可透過有效邀請或連結重新加入；Project 擁有者則可在邀請選單中點選 Remove 移除成員。

共享上下文 /cursor/stores/self 與個人 Store /cursor/stores/user 的差別

根據Cursor Projects Context and Personal Store 文件，Cursor Multiplayer Projects 透過掛載兩個不同的檔案系統路徑，將開發者的私人設定與團隊知識分開：/cursor/stores/self 用於共享 Project context，/cursor/stores/user 則是個人 user store。官方 store 規則指出，隊友加入共享 Project 時，其協調者可提議將相關工作偏好從 /cursor/stores/user 複製到 Project rules；只有使用者明確核准的項目會被複製。

協調代理如何透過不受信任的側邊聊天互傳訊息

當某位協調者需要了解隊友的工作狀況時，Cursor Projects 多人規格允許它直接向隊友的協調者發訊息。系統會從接收方的一般聊天中分支出名為 Chat with {name}'s agent 的側邊聊天。Cursor 對這種分支側邊聊天可執行的操作設下限制，避免傳入查詢中斷接收者原本的工作流程，或造成機密外洩。

在 Cursor 的2026 年 11 月 10 日多人協作公告中，產品經理 Aryaman Khandelwal 提出兩個主要的跨代理協作情境：

• UI 與功能重疊：某工程師在商品頁加入顧客評價，同時設計師正在重設該頁面。雙方協調者可及早發現重疊範圍，直接把評價元件納入新版版面，而非之後再重構。
• Schema 與讀取端的執行順序：一位開發者修改資料庫 schema，另一位隊友正開發讀取該資料庫的功能；代理會預先協調操作順序，避免 merge 時發生整合衝突。

官方 Cursor Projects 文件的 How coordinators message each other 一節，對這類交換訂出四項嚴格規則：

1. 發送查詢：隊友 A 的協調者發現工作依賴隊友 B 的成果，便直接向隊友 B 的協調者發訊息。
2. 建立分支側邊聊天：收到訊息後，系統會從隊友 B 的一般聊天分支出側邊聊天，名稱為 Chat with {Teammate A}'s agent。
3. 以不受信任內容評估：傳入的協調者訊息會標記為 agent input，接收者會得知是哪位隊友的代理送出訊息；接收代理必須把它當成待評估的不受信任內容，而不是自己使用者的直接要求。
4. 依主聊天知識回答，並於下一輪提示：側邊聊天會用接收者主聊天可取得的知識回答，再將回覆傳回發送方協調者。隊友 B 的主聊天不會立刻被打斷，而是在下一輪收到這次交換的提示。

Cursor Projects 文件也明確定義了每個分支 Chat with {name}'s agent 側邊聊天的權限邊界：

理想流程與 Beta 現實：共享決策最容易在哪裡失效

Cursor 的官方案例強調內部 on-call 輪值：接手的工程師可讓協調者承接進行中的 incidents、Linear boards 與 Slack threads。不過，單人 Projects beta 報告揭露了四個貫穿四階段專案生命週期的操作失敗模式；在多人環境中，團隊應先設好防護規則：

可變動 Project Notes 與「共享錯誤」問題

開發者 Lutz Leonhardt 在 Cursor Community Forum 發表了為期 3 天的 Cursor Projects beta 單人實測。他檢查同步的 context folder 與 orchestrator 對話記錄；測試涵蓋 5 個 sessions、約 14 小時、20 個 agents、32 項 tasks、49 個 agent turns，以及 5 個 pull requests，其中 4 個已 merge。雖然委派與交付結果成功，修正了 Codex review bot 找出的全部 18 項問題，但專案記憶層出現兩種失敗模式。若推展到共享多人 store，風險更大：

• 111 次重寫，僅 1 次明確讀取：在這 3 天測試中，協調者透過完整檔案取代方式重寫 Project Notes 檔案111 次，卻只明確讀取該檔案一次。第 1 個里程碑在第 2 天開始封存前就從 notes 消失；對 podcast LLM analysis 的明確核准，也在兩次重寫後被壓縮為 "done"，導致協調者隔天又為同一項核准卡住。
• 將未核准的預設值記錄為決策：協調者列出 5 個 keywords 與 3 個 open questions 後，開發者詢問 API key，並問能否開始 Milestone 2。協調者卻把尚未確認的預設值視為 "accepted for the start"，接著啟動代理實作 always-on cron adapter，與自己先前的建議矛盾。在另一次互動中，協調者否認收過一個其實已執行的 worker handoff，並將這段錯誤歷史寫進 context folder，成為 workflow rule。

Leonhardt 的報告雖然測的是單人 Projects，但進入多人模式後，每位隊友的代理都能讀寫 /cursor/stores/self。因此，一份受污染的 note 或未驗證的代理預設值，都可能影響之後讀取共享 store 的任何隊友代理。正如開發者 @avisinghdotdev 在 X 上於多人功能推出後所說：

"老實說，我不喜歡代理跟我隊友的代理交談的想法，尤其是彼此有不同規則和 skills 的情況。一個糟糕輸出就可能拉低品質。" — @avisinghdotdev

多人 Projects 的建議防護規則：不要讓協調者把 /cursor/stores/self 裡單一可變動的 Markdown 檔，同時當成草稿區與決策紀錄。應在 Project rules 中將狀態拆分為兩份檔案：

1. 可變動的 plan.md，用於記錄任務狀態與目前 branch 指標。
2. 提交至 repository 的 decisions.md，以僅追加的 agent rule 控管；若需嚴格落實，可搭配 Git diff review 或 branch protection。內容記錄 date、decided_by（human:@handle 或 agent:proposed）、status（proposed、accepted、superseded）、applies_to（檔案路徑 glob），以及一行 rationale。

過時 checkout、雲端 MCP 不一致與本機 worktree 交接

第二類 Beta 問題源於 Cursor 預設以雲端執行的架構。根據 Day 7 Cursor Projects receipt 與 r/cursor 討論串中的已驗證使用者回報，團隊導入 Projects 時要注意四個操作陷阱：

1. 長期 Project 的過時 Git checkout：長期運作的雲端 Project 不會自動 pull 已 merge 到 main 的變更（Day 7 Report R1；Cursor 員工確認這是預期行為，並建議要求協調者 pull）。多人模式下，每次委派新任務前都應明確要求協調者執行 git pull。
2. 僅從雲端載入 MCP server：協調者以 Cloud Agent 身分執行，因此只會讀取你在 Cursor 雲端設定中配置的 Model Context Protocol（MCP）servers（Day 7 Report R6）。只設在本機桌面 editor 的 MCP servers 不會載入 Project coordinator。
3. 「No self-hosted workers available」開關陷阱：若要從雲端 Project 執行本機測試，需在 Settings > Agents 下啟用 Remote Control（本機 self-hosted workers），並在 repository root 執行 agent login，再執行 agent worker start。不過，啟用 Remote Control 也可能開啟 Self-hosted Machines，並在 team dashboard 啟動 Require Self-hosted Machines and Personal Machines，使 Cloud Agents 與 Projects 無法在 Cursor 雲端執行。團隊管理員應關閉這個 Require 開關，保留雲端與本機混合執行能力。
4. 雲端 token 消耗：同時執行 10 到 20 個平行雲端 subagents，會快速耗盡方案用量。正如 r/cursor 使用者 u/Shirc 在 Reddit 所說：

"Projects 很有潛力，但目前有點混亂，而且絕對會大量吞掉 tokens。" — u/Shirc in r/cursor

在同一串 r/cursor 討論中，開發者 u/dryu12 建議將 Composer 設為協調者模型，並明確撰寫規則，指定哪些模型該接收哪些委派任務。若團隊也在 Cursor 內建計費以外，執行外部 CI review bots 或自訂 agent scripts，可透過 AIReiter 路由這些 API calls，以單一隨用隨付餘額，同時搭配 DeepSeek V4.1 Flash 等低成本模型與 Claude Opus 5.5 等審查模型。

PR 審查碰撞：每個 Pull Request 都應有唯一負責人

依Cursor Projects subscriptions 文件說明，只要至少存在 1 個 subscription，例如監控 Slack channel、PR activity、特定 branch 的 CI runs，或 every day at 8:00 AM 這類排程，聊天輸入框上方就會顯示 Listening 標籤。

Leonhardt 的 3 天單人測試中，PR review 的處理權責已經不清，因為協調者、原始實作 worker 與新建的修正 agents 都可能回應 review events。某個 PR 裡，協調者兩度向作者詢問原始 agent 已在處理的修正；另一個 PR 中，3 個 agents 重寫了同一份 status file，並留下錯誤的作者紀錄。

當多位隊友在同一個 repository 執行協調者時，若讓多個協調者訂閱廣泛的 repository PR events，就會提高重複提交修正 commit 與浪費雲端 turns 的風險。正如開發者 @LabubuNoBB 在 X 上所言：

"困難的從來不是讓代理彼此交談，而是當兩個代理都想動同一個檔案時，要決定到底誰負責什麼。" — @LabubuNoBB

建議的 PR 所有權規則：在共享 Task Board 中，為每個 PR 指派一位真人負責人與一個指定代理，由其負責該 branch 上所有 review comments；每位隊友協調者的 subscriptions 只應涵蓋自己的 PR，而非整個 repository 的萬用監控條件。

團隊導入決策表：何時該共用 Project，何時該分開聊天

在將團隊工作流程搬進共享 Cursor Project 前，請先依據 3.26.13+ Beta 已驗證的限制，檢視任務結構：