Cursor Agent SDK 正式開放：代理寫成程式後，如何測試、部署與管理權限？
Cursor Agent SDK 將代理指示、工具、事件與評測保存成專案，支援 Cursor 託管或自有環境。整理官方發布日期、PR 事件重播、測試副作用與部署角色，理解團隊如何管理代理變更。
團隊用 Cursor Agent SDK 這類工具讓 AI 審查程式變更，最難交接的往往不是提示詞，而是它何時開始、能用哪些工具，以及下次還會不會做出不同動作。
如果這些設定只留在聊天視窗，換人維護時就得重新拼出工作流程，也很難確認修改提示詞後，代理有沒有跳過原本必做的檢查。
Cursor 在 2026 年 10 月 20 日正式開放 Agent SDK，並於 10 月 26 日在官方 X 再次介紹。SDK 是協助開發者建立軟體的工具組，這次讓代理成為 Markdown 與 TypeScript 組成的專案。
因為提示詞、工具、事件入口與測試都跟著專案保存，開發者可以像審查一般程式那樣看差異，再檢查代理實際呼叫了什麼工具。
我認為它適合已經需要多人維護、版本管理與重複驗證的團隊。若工作只是排程執行一段提示詞，既有 Automations 會更直接。
要知道這種改變能替團隊省下哪些交接成本，得先看一個代理專案裡，哪些決定交給模型，哪些仍由程式控制。
Cursor Agent SDK 把哪些工作變成可審查的檔案？
Agent SDK 把代理的指示、工具和事件入口放進專案，讓團隊能直接看到模型被允許做什麼。模型負責理解問題與選擇動作，開發者則用程式定義那些動作如何執行。
官方公告把指示放在 Markdown 檔案，這是一種容易閱讀的純文字格式。工具則以 TypeScript 撰寫，替輸入加上明確的資料類型，讓系統先知道欄位應該是文字、數字，還是有限選項。
例如，審查工具可以只接受程式變更的網址，再取回標題、修改檔案和差異。另一個工具才負責送出審查結果。把兩個動作拆開，團隊就能分別討論資訊夠不夠、什麼情況可以對外寫入。
這種結構也讓提示詞修改更容易被看見。有人把「先讀變更內容」改成「直接依標題判斷」，差異會跟程式碼一起留下。審查者不必先猜這項設定藏在哪一段私人聊天中。
技能與工具的責任不同
技能保存代理需要時才讀取的工作方法，工具則提供真正能執行的能力。寫一份審查程序，不會因此取得新的儲存庫權限。能否讀寫外部服務，仍由工具及連線身分決定。
因此，專案化帶來的是可追蹤的維護方式，而不是文字指示必定被遵守。團隊仍需檢查代理實際如何使用工具，才能知道指示是否產生預期行為。
這也和 Cursor 的電腦操作功能不同。後者讓代理點擊應用程式，這次的 SDK 則讓團隊定義自己的代理流程，兩者不能只因為都叫代理就混成同一項更新。
延伸閱讀：Cursor Computer Use：AI 能開 iOS 模擬器驗收，哪些檢查還要自己做？
檔案可以交接之後，下一個問題就是外部訊息如何找到這個代理，而不是每次都要有人開啟對話。
The Agent SDK is now available.
— Cursor (@cursor_ai) October 26, 2026
Define agents as code, with prompts in Markdown and tools in TypeScript. Deploy them on our hosted infrastructure, or run them on your own.
Built-in evals let you measure every change and make your agents better over time. pic.twitter.com/sww7EXYBFI
GitHub、Slack 與排程如何接進同一段工作？
通道負責把外部事件轉成代理的工作，例如程式變更請求、Slack 訊息或排程。開發者因此可以把「何時開始」和「開始後怎麼判斷」分開處理。
官方列出的入口包含 GitHub、GitLab 與 Bitbucket 的變更、留言及檢查事件，也包括 Slack 提及、私訊、外部服務通知和定時工作。入口不同，仍可以使用同一份代理專案。
以官方的程式審查範例來看，通道會先挑出建立、重新開啟，以及準備接受審查的事件。如果變更仍是草稿，就不進入後面的審查工作，避免模型先花時間分析一份作者還沒準備交付的內容。
這裡的篩選是範例程式明確寫出的條件，並不是平台替所有代理做好的通用保證。團隊若有不同事件規則，仍要在自己的通道設定中表達出來。
後續訊息沿用同一段對話
同一個變更請求或 Slack 討論串的後續訊息，可以接回原本的工作階段。代理便能沿用先前看過的問題，而不必每收到一則留言就把背景重新建一次。
假設同事先請代理檢查修改，再要求只整理阻礙上線的項目，第二句就應接續前一輪的資訊。不過，能記得對話不代表判斷一定正確，還得確認它有沒有重新做出不必要的外部動作。
因此，通道解決的是工作如何開始與延續，不能直接代替行為驗證。但同一段對話接得回來，還不能證明它每次都照規則做事，這正是測試要補上的地方。
內建 Evals 能檢查工具順序，還是只看回答像不像？
內建評測可以檢查代理叫了哪些工具、帶了什麼輸入，以及回覆的形狀，不只比對最後一句話。Evals 就是一組用固定情境反覆檢查代理行為的測試。
在官方評測文件中，測試可以要求代理先呼叫檢查工具，並確認它沒有呼叫批准工具。即使最後的文字看起來都像「目前不能批准」，工具紀錄仍能揭露兩次工作是否做了不同的事。
這對會寫入外部系統的代理尤其有用。如果測試只檢查答案裡出現「需要人審」，卻沒有檢查它是否已經送出批准，就可能得到文字正確、行為錯誤的結果。
官方也支援重播真實變更請求的事件。開發者可以把事件內容保存成測試素材，下次修改指示或工具後，再用同一份輸入檢查，減少等待另一個真實事件剛好發生的時間。
測試會執行工具，寫入必須另外處理
評測並不是只在紙上模擬。文件明確說它會執行真實工具，因此工具需要辨識這是一段評測工作，保留「原本決定要做什麼」的紀錄，同時跳過真正對外送出的動作。
這樣測試仍能確認代理選擇了送出結果，卻不必每跑一次就新增一則真實留言。保護應放在實際寫入的位置，才不會只因為提示詞說「這是測試」就誤以為外部系統不會改變。
測試也可以分開檢查單輪與整段對話。例如，第二輪只要求摘要時，應確認該輪沒有再叫工具，而非把第一輪必要的查詢也算成錯誤。
測試輸入也可以包含固定的工作區檔案。這對程式審查很有用，因為若每次都讀取當前正在變動的專案，兩次評測的差異可能來自檔案變了，而不一定是代理改壞了。
把當時的程式差異保存成測試素材，就能讓修改前後面對同一個問題。團隊才比較容易判斷，新提示詞究竟多找到了問題，還是只是碰巧讀到另一份內容。
官方把回覆檢查也分成不同層次。若輸出約定是一份包含布林值與阻礙清單的資料，就可以先檢查結構。若要判斷意思是否符合事實，則可以加入模型評審。
但模型評審的分數仍是一種評估結果，不能直接換算成真實任務的正確率。因此，工具是否被呼叫、資料格式是否符合約定，以及解釋是否可信，最好各自留下能追查的依據。
失敗紀錄會保存輸入、斷言、工具呼叫與最後文字，維護者可以先找出哪一層出了問題。若工具根本沒有取得資料，先修連線或輸入，會比一味增加提示詞更接近原因。
當固定情境能反覆驗證，團隊才有依據決定是否把同一套代理部署出去。
部署到 Cursor 或自己的環境，管理責任差在哪？
同一個代理專案可以部署到 Cursor，也可以放在自己的基礎設施，但環境與權限仍要有人管理。兩種選擇的共同點，是代理的指示、工具與測試仍是團隊可以維護的檔案。
使用 Cursor 的部署方式時，系統會建立代理的網址，並提供管理秘密資料與整合服務的介面。本機使用的紀錄、評測與測試介面，也能繼續協助查看部署後的行為。
因此，團隊不必因為代理開始正式工作，就完全換一套理解問題的方法。如果一次回覆沒有先讀必要資料，仍應能沿著訊息與工具紀錄往回找，而不是只看使用者收到的最後結果。
若選擇自己的環境，則要把執行位置、連線條件與日常維護一併納入安排。官方允許自有基礎設施，不等於模型、外部服務或維運成本都會消失，也不能由此推論不再需要任何 Cursor 身分。
部署與模型測試是不同動作
官方入門範例把工具檢查、模型執行和部署分成不同步驟，這讓團隊可以先確認輸入與判斷，再決定要不要讓它持續接收事件。
模型執行需要 Cursor 登入憑證。單純把專案檔案保存下來，並不代表外部模型呼叫已經能進行。這也提醒維護者，把能讀程式和能啟動工作的人分開看，才比較容易追查失敗原因。
執行環境選好後，還得確認誰只是看結果，誰真的能換掉代理或改它的秘密資料。
誰能看代理，誰能重新部署與管理憑證？
Cursor 的部署權限分為檢視、編輯與擁有者，能開啟代理不代表能更動它。權限文件分別列出三種角色能做的事。
檢視者可以開啟代理。編輯者可以部署、停止與重新啟動。擁有者則在此之外，還能管理秘密資料，以及決定其他人如何存取。
這個差別會影響實際交接。如果營運同事只需要查看代理，沒有理由因為要讓他看結果，就一併交出更換憑證的能力。相反地，負責維護的人需要重新部署，也不一定需要替整個團隊調整授權。
新代理部署時，部署者取得擁有者角色，所屬團隊取得檢視權限。再次部署同一代理不會重設原本的存取安排，因此不能把重新發布理解成自動清掉先前的授權。
服務帳號的情況又不同。若代理由自動化流程部署，擁有者會對應建立該服務帳號的人，而不是服務帳號本身。缺少建立者時，文件也另列由團隊管理員處理的安排。
團隊管理員可以管理自己團隊擁有的代理，但不會因此取得另一個團隊所發布代理的管理權，即使那個代理已經被安裝進自己的團隊。這讓「可以使用外來代理」和「可以修改它的憑證」維持不同範圍。
這讓人員離職、工作轉交和自動部署不必全部混在同一個問題裡。維護者可以先查清楚角色從哪裡來，再處理需要更動的權限，而不是反覆部署來猜測結果。
這些角色把維護責任拆開，也讓選擇 SDK 的理由從「多一個 AI」變成「工作流程是否能被團隊管理」。
什麼工作值得搬進 Agent SDK？
當團隊反覆維護同一套判斷、工具和事件時，Agent SDK 的價值才會比單一提示詞更清楚。它把原本分散在對話、工具設定與個人習慣裡的工作，變成可以一起查看的專案。
例如，一個程式審查代理若已有固定入口、檢查順序和批准條件，就很適合把這些部分放在同一套版本紀錄中。當規則改變，團隊也能知道哪些測試需要跟著調整。
反過來，如果需求只是每週根據一段提示詞整理訊息，既有 Automations 已能處理排程與觸發，未必需要為了使用新工具而再維護一份程式專案。
官方也把 Grok Bot 放在不同位置，適合直接在應用程式設定指示、技能與連接工具。SDK 則適合希望以程式包住模型判斷，並自行審查、測試和持續改進的人。
延伸閱讀：Claude 寫了九成程式，誰來審？Claude Code 團隊公開分層審查流程
這次更新沒有讓團隊少掉判斷責任，而是讓判斷依據比較容易被留下。能重播的事件、清楚的工具紀錄與對應權限，才是同事接手後仍能理解代理的原因。
我會以一個能重播的真實工作事件及其工具紀錄作為採用依據，再決定是否擴大到更多代理。
Cursor Agent SDK 常見問題 FAQ
Agent SDK 是新的模型嗎？
不是。它是建立與管理代理的開發工具組，讓指示、工具、入口與評測成為專案。模型仍是其中負責判斷的一部分。
通過 Evals 就能自動批准所有程式變更嗎？
不能。評測只檢查提供的情境及斷言，團隊仍要決定批准條件，並防止評測工具對外造成真實寫入。
可以直接照舊公告的安裝命令操作嗎？
當日文件與早期公告的套件名稱已有差異，實際安裝應查看最新官方文件。本文沒有安裝或登入，也沒有執行對外審查。
