Cursor週三宣布其TypeScript SDK進入公測(npm install @cursor/sdk),讓原本跑在Cursor桌面、CLI、Web應用裡的代理,現在可以透過幾行程式碼以程式化方式被呼叫。公告裡那一組架構件讀起來就像是一份「2026年代理式程式設計平台長什麼樣」的規格說明。每一個代理拿到一台帶強沙箱的專屬VM、一份目標repo的複製,以及一套完整配置好的開發環境。代理能熬過筆電休眠、斷網;對話可以被串流傳輸、斷後重連。當代理完成時,它可以開PR、推分支,或者附上示範和截圖。模型是可插拔的(任意前沿模型——和iter #72中Microsoft Copilot同樣的多模型路由模式)。外部工具透過MCP伺服器接入(就是iter #56裡SAS採納的同一份Anthropic公開協定)。儲存庫級技能放在`.cursor/skills/`。鉤子讓你能觀察並擴展代理迴圈。子代理委派讓一個代理可以spawn子代理處理子任務。
戰略定位才是最值得讀的部分。Cursor在公告裡很直白:「程式設計代理正在從面向個體開發者的互動工具,演化成面向組織的可程式設計基礎設施。」這種措辭是有意為之的:Cursor正在把自己從「帶AI的IDE」重新定位為「部署程式設計代理的平台」。可對標的形態是React(UI原語)、Stripe(支付原語)、Twilio(訊息原語)——SDK這一招把Cursor的代理從一個功能,變成一種供其他公司在其上建造的原語。被列舉的用例包括:在CI/CD管線裡呼叫、端到端工作流自動化,以及把代理嵌入面向客戶的產品裡。最後這條最重要:Cursor現在主動鼓勵第三方SaaS公司在自家產品裡出貨「Cursor代理驅動」的功能,把Cursor當作代理脊椎。對照GitHub Copilot那種更縱向整合的路徑(微軟同時擁有代理+IDE+雲)和Claude Code(Anthropic擁有代理,使用者擁有IDE)——Cursor的SDK是第三種押注:不管IDE和模型從哪裡來,Cursor都做代理平台。
MCP採用這一細節,在結構上很重要。Cursor本可以自造一套專有的工具呼叫格式——就像OpenAI的function calling最初的樣子、或像LangChain的工具抽象、或像Salesforce Einstein actions的定義方式。採用Anthropic開放的Model Context Protocol,意味著Cursor的代理可以與任何暴露MCP伺服器的工具互通,包括SAS的Viya分析(iter #56)、GitHub的repo工具、檔案系統存取,以及社群建構的MCP伺服器長尾。這與微軟在M365 Copilot多模型路由上的架構選擇相同;Anthropic、GitHub和如今SAS都已收斂到的同一種模式。MCP作為「AI代理與外部工具之間的連接層」如今已經是事實上的標準——而那些抗拒採納的,越來越只是出於戰略原因想要分裂(iter #60中OpenAI Codex CLI的提示結構沒有以MCP打頭陣,雖然它支援MCP)。對評估「我的產品要不要支援MCP」的builder來說,如果你想被主要的程式設計代理觸達,答案現在已經在結構上是「是」。
對builder而言,有三點收穫。第一,「每個代理一台VM沙箱」正在成為「任何執行程式碼的代理」的生產級標準。Cursor SDK的「每代理一台帶完整開發環境的專屬VM」與Replit代理、GitHub Codespaces、Claude Code的終端沙箱所做的事是同一種架構模式。如果你做的產品要跑LLM產生的程式碼,請按「VM-per-task」做隔離規劃,而不是「行程-per-task」或「容器-per-task」——在如今這個代理產品的生命週期階段,安全性和持久性的重要性超過了資源成本。第二,子代理委派是被低估得最厲害的一項技術細節。「Cursor代理spawn子Cursor代理」就是Rogo的Felix所用的「代理-of-代理」模式(iter #73:Felix把交易篩選、CIM生成、盡調拆分給若干子代理),也正是Anthropic多代理編排研究一直在推動的方向。在公開SDK裡把子代理委派提供出來,意味著這個模式正從研究走向標準實踐;請圍繞它來構建。第三,留意未來六個月內有哪些大型企業SaaS公司宣布Cursor-SDK的整合。那些在自家產品裡出貨「由Cursor驅動」功能的公司,就是那些不願從零自建代理棧的公司——這是平台層的「買 vs 自建」訊號,與垂直AI(iter #82 Aidoc、iter #73 Rogo、Harvey等)在垂直層呈現的「買 vs 自建」訊號是平行的。兩條訊號都指向同一結論:在2026年,從零自建你自己的AI代理基礎設施,除非你有明確的差異化理由,否則越來越像是一個錯誤的選擇。