我們推出 Cursor Automations，讓你能建立永遠在線的代理。

這些代理可以依排程執行，或由事件觸發，例如傳送一則 Slack 訊息、新建立的 Linear issue、已合併的 GitHub PR (拉取請求) ，或是一則 PagerDuty 事故。除了這些內建整合外，你也可以透過 webhook 設定自己的自訂事件。

#升級軟體工程流程管線

隨著程式碼 Agent 的興起，每位工程師都能產出更多程式碼。但程式碼審查、監控與維護的速度卻尚未同步提升。在 Cursor，我們一直運用各種自動化來協助擴充開發生命周期中的這些其他環節。

當被觸發時，自動化 Agent 會啟動一個雲端沙盒，使用你事先設定好的 MCP 與模型，依照你的指示行事，並自行驗證輸出結果。Agents 也能使用一個記憶工具，讓它們從過往的執行中學習，並透過反覆運行持續改進。

在過去幾週裡，隨著我們在 Cursor 自身的程式碼庫上執行越來越多自動化 Agent，已經浮現出兩大類型的自動化模式。

#審查與監控

自動化流程非常適合用來審查變更。從風格細節與不一致之處，到安全性弱點與效能退化，全都能加以偵測與修正。

事實上，Bugbot 在許多方面就是最早的自動化範例！它會在 PR (拉取請求) 建立或更新時執行，每天被觸發數千次，自我們首次推出以來已經抓到了數百萬個錯誤。透過自動化，你可以為不同目的自訂各種審查用代理。以下是我們在 Cursor 使用的三種範例：

安全性審查

我們的安全性審查自動化會在每次推送到 main 時觸發。如此一來，代理就能花更長的時間尋找更細微的問題，而不會阻塞 PR。它會稽核差異 (diff) 中的安全性弱點，略過已在 PR 中討論過的問題，並將高風險發現張貼到 Slack。這項自動化在 Cursor 已經攔截了多個弱點與嚴重錯誤。

代理驅動的程式碼擁有者

在每次 PR 開啟或推送時，這個自動化會依據影響範圍、複雜度與基礎設施衝擊來分類風險。低風險 PR 會自動核准。較高風險的 PR 則會依照貢獻紀錄指派最多兩位審查者。決策會先在 Slack 中彙總摘要，並透過 MCP 記錄到 Notion 資料庫，讓我們可以稽核代理的工作並微調指令。

事故回應

當 PagerDuty 事故觸發這個自動化時，它會啟動一個代理，使用 Datadog MCP 來調查日誌，並檢查程式碼庫中最近的變更。接著，它會在 Slack 頻道中傳送訊息給我們的待命工程師，包含對應的監控訊息，以及一個包含建議修復內容的 PR。這大幅縮短了我們的事故回應時間。

#例行雜務

我們也發現，自動化對於日常任務和知識型工作非常有用，特別適合需要在不同工具間串聯資訊的情境。

每週變更摘要

這個自動化會在 Slack 張貼每週摘要，整理過去 7 天內此程式庫中的重要變更。代理會特別標註主要已合併的 PR (拉取請求)、bug 修復、技術負債，以及安全性或相依性更新。

測試涵蓋率

每天早上，一個自動化代理會檢視最近合併的程式碼，並找出需要新增測試涵蓋率的區塊。它在新增測試時會遵循現有慣例，且只在必要時才變更正式環境 (production) 的行為。接著，該代理會先執行相關的測試目標，之後再開 PR (拉取請求) 。

Bug 回報分類與處理

當一則 bug 回報出現在某個 Slack 頻道時，這個自動化會檢查是否有重複，並透過 Linear MCP 建立 issue。之後代理會在程式碼庫中調查根本原因、嘗試修復，並在原始討論串中回覆摘要。

#Rippling 如何使用自動化

在 Cursor 之外的團隊已經開始建立自動化流程。Rippling 的 Abhishek Singh 設置了一個個人助理。他會在一天當中，把會議紀錄、行動項目、待辦清單 (TODO) ，以及 Loom 連結丟進一個 Slack 頻道。一個 cron 代理程式每兩小時執行一次，讀取這些內容以及他的 GitHub PR (拉取請求) 、Jira issue 和 Slack 提及，跨來源去重，然後發布一個清晰的儀表板。

他也執行由 Slack 觸發的自動化流程，從討論串建立 Jira issue，並在 Confluence 中彙總討論內容。Singh 和 Rippling 進一步擴展自動化的使用範圍，用來處理像是事件分級、每週狀態報告、輪值交接等任務。最有用的自動化流程會在整個團隊中分享。

#打造你的軟體工廠

這些自動化都是由雲端代理驅動，它們會使用自己的電腦來建置、測試和展示它們的工作成果。現在，你可以透過設定代理，讓它們持續監控並改進你的程式碼庫，從而打造出生產你軟體的工廠。

試著在 cursor.com/automations 建立一個自動化流程，或從範本開始。想了解更多，請參閱文件。