將 Cursor 雲端代理的第一個任務限縮為一項可驗證的修復

把一個可重現的小缺陷交給 Cursor，等它交回供人審查的 PR，是值得先嘗試的背景代理用法。適合委派出去的任務應同時滿足三個條件：預期行為已經明確、能在遠端環境驗證，而且一位負責人就能掌握變更範圍。少了其中任何一項，先補足條件，比繼續加長提示更有用。

Cursor 目前將這類產品稱為 Cloud Agents，過去則稱為 Background Agents。它在雲端的隔離虛擬機器中工作，不會接管你目前的本機工作目錄；處理儲存庫任務時，會在獨立分支上修改並交接程式碼。以下依據官方文件分析如何選擇任務，文中的範例並未實際執行。

假設專案有一個清單 API：合法的空查詢應該回傳空陣列，卻觸發例外。團隊已確認正確行為，也有相關測試。這比「把搜尋做得更好」更適合委派，因為代理可以針對一個可觀察的結果找出原因、修改實作並補上迴歸測試，審查者也能判斷是否修對了。

同樣的標準也適用於為已知邊界條件補上測試、修正與現有介面不一致的文件範例，以及範圍明確的重複程式碼整理。不過，重構還需要既有測試來保護對外行為；若缺乏測試，應先要求釐清呼叫端並補上測試，不要同時要求大規模調整結構。

上述修復可以寫成這樣的委派要求：

• 重現清單 API 處理合法空查詢時的例外，先新增一項會在舊實作上失敗的迴歸測試。
• 將這項輸入的結果修正為成功回應與空陣列；保留現有的錯誤輸入處理方式，不更動 API 參數或回應結構。
• 只修改相關實作與測試。不升級相依套件，不更動存取權限判定、資料庫結構或部署設定；若必須超出範圍，先說明原因並停下來。
• 執行相關測試與專案既有的檢查，記錄指令、結果，以及無法執行的項目。交回草稿 PR，說明根本原因、變更檔案、驗證證據與剩餘風險，不要合併。

這是一份供分析使用的任務範例，不是宣稱這些檔案或指令確實存在、可以直接執行的腳本。實際委派時，還要補上儲存庫、基準提交版本、實際用來重現問題的輸入，以及專案測試指令。驗收時應確認新測試確實涵蓋原本的缺陷，不能只看「測試通過」：如果代理刪除了斷言，或修改測試，讓錯誤行為變成預期結果，就算亮綠燈也沒有意義。

Cursor 的環境文件說明，託管雲端代理在 Ubuntu 上執行，可以由代理引導設定，也可以使用 Dockerfile 設定。你在本機已安裝的工具、尚未提交的檔案或私人服務連線，不能因此就被視為遠端也已具備。先驗證相依套件能安裝、測試能啟動、必要服務能連線，再排入修復任務。

儲存庫、相依的儲存庫與子模組都需要相應的讀寫權限。若任務依賴只有開發者電腦上才能使用的元件，或測試必須存取尚未授權的內網服務，應先處理環境與權限問題；不要把安裝失敗或網路逾時寫成程式碼已通過驗證。可以縮小任務，只交付原因分析與建議變更，或改用能存取所需環境的本機互動式工作方式。

第一次委派時，最好選擇不需要正式環境資料與憑證的修復，並使用已去除敏感資訊的範例或測試替身。若無法建立可信的驗證環境，這個任務就還不適合在無人看管的情況下推進到可合併狀態。

Cursor 的文件說明，Cloud Agents 預設可以連上網際網路，也會自動執行終端機指令。它能持續執行測試，但也可能在讀取惡意內容後受到提示注入影響。獨立分支可以隔離程式碼變更，卻無法收回已傳送到外部的資料；把「最後會有人審 PR」當作執行時的安全界線，並不充分。

啟動前，應限制允許存取的外部目的地，並只提供任務所需的權限與憑證。官方提供 Runtime Secrets，會遮蔽工具輸出、聊天紀錄與提交內容中的值；但程式仍可透過環境變數使用這些值，透過終端機與環境互動的使用者也仍能看見。遮蔽輸出不代表憑證無法被使用，也不能取代對憑證權限範圍的限制。

因此，正式環境資料庫遷移、付款或存取權限判定規則調整，以及依賴尚未確定的產品決策的大幅變更，都不宜作為第一個無人看管的任務。這是依影響範圍提出的任務選擇建議，並不是宣稱產品無法修改這些程式碼。應先由人確認業務限制與風險，再拆分出能獨立驗證的小幅變更。

官方描述的交接流程是推送分支，並開啟供人審查的 PR，也可以要求以草稿形式交付。團隊應據此釐清責任：代理提供變更與證據，負責人決定需求是否已滿足、風險是否可接受，以及是否合併。不要把代理的完成訊息當作合併授權。

審查時，先核對差異是否仍在原定範圍內，再重新執行關鍵迴歸測試與必要的整合檢查；檢查錯誤處理分支、呼叫端、相依套件變更，以及日誌是否暴露資料。無法執行的檢查應保留在 PR 中，明確標示由誰補做。若變更範圍不斷擴大、反覆繞過失敗的測試，或需要新的業務判斷，就回到互動式討論，重新拆分任務。

背景代理能帶來多少效益，取決於交接品質。先選一個不靠正式環境權限也能重現、結果明確，而且能完整審查的小修復；只有環境與審查流程都經得起這一輪驗證，才擴大委派範圍。