Cursor 可與所有用於程式開發的最先進 AI（人工智慧）模型整合。

每個模型都需要對我們的代理執行框架進行特定的指令與調校，以提升輸出品質、避免回覆變得怠惰、更有效率地呼叫工具等。

我們持續與 OpenAI 合作，透過 Cursor 的 Agent 讓開發者能在其中使用他們的模型。這篇文章將說明我們如何更新 Agent 的執行框架，以支援他們最新、最先進的程式編寫模型 GPT-5.1-Codex-Max。

建構穩健的代理框架

Cursor 的 Agent 框架中的每個模型，都有特定的指示與可用工具，以便在 Cursor 環境中發揮該模型的最佳效能。

AI（人工智慧）實驗室會使用各式各樣的指令與工具來訓練新模型。在像程式開發這類的特定領域中，模型可能會偏好與其訓練時已見過的模式較為相似的用法。當我們把新模型加入 Cursor 時，我們的工作就是在整合既有、熟悉的指令與工具的同時，搭配 Cursor 專用的指令與工具，並再依據 Cursor Bench（我們的內部評測套件）進行調校。

我們根據模型的成功率、調用工具的能力，以及在使用者間的整體使用情況與普及度來衡量其品質與穩健性。以下是我們針對 Codex 的 Agent 測試框架所做的一些更新。

更新至最新的 Codex 模型

OpenAI 的 Codex 模型是其最新尖端模型的變體，並特別針對代理式程式設計進行訓練。

OpenAI 團隊與我們緊密合作，將工具和提示詞調整為能與 Codex CLI harness 相配合。以下是我們做出的一些變更：

更以 Shell 為中心的方式

OpenAI 的 Codex CLI 專注於以 shell 為中心的工作流程。因此，Codex 模型在訓練期間僅接觸到一小部分工具，而是學習透過 shell 來搜尋、讀取檔案並進行編輯。

如果模型在處理複雜的編輯工作時表現吃力，有時會退而改用內嵌的 Python 腳本來寫入檔案。這類腳本功能強大，但在 Cursor 中進行編輯時，透過工具呼叫的方式既更安全，也能提供更佳的使用體驗。

為了鼓勵呼叫工具，我們將 Cursor 中工具的名稱與定義調整得更接近其在 shell 中的對應工具，例如 rg（ripgrep）。我們已在測試框架中的所有模型上完成這項變更。我們也新增了類似以下的指示：

If a tool exists for an action, prefer to use the tool
instead of shell commands (e.g. read_file over `cat`).

沙盒隔離機制在 Cursor 中，能在不需要使用者手動核准每一道指令的情況下，防止未經授權的檔案存取與網路活動；即使模型仍選擇執行 shell 指令，也有助於提升此處的安全性。

前置提示

與 GPT-5 主系列模型不同，Codex 模型系列目前會在執行工作時使用推理摘要，向使用者說明最新進度。這些內容可能以單行標題或完整訊息的形式呈現。

對於這些推理摘要，我們希望在讓使用者能跟上 Agent 的進度並及早辨識出不佳路徑的同時，又不會因為過於頻繁的訊息而產生干擾、進而選擇忽略。為此，我們為模型制定了指引，要求將推理摘要限制在 1 到 2 句，在發現新資訊或啟動新策略時加以註記，並避免評論自身的溝通行為（例如「I'm explaining to the user…」）。

由於 Codex 模型在一個代理回合結束前無法正常與使用者「對話」，我們移除了提示詞中所有與在回合中途與使用者溝通有關的語句。我們發現這麼做能提升模型最終輸出的程式碼效能。

閱讀 Lint 訊息

Cursor 在我們的整合環境中，為所有模型提供讀取 linter 錯誤（例如 ESLint、Biome）的工具，並讓 Agent 能自動加以修正。

我們發現，只把工具定義提供給 Codex，並不足以讓它傾向於呼叫我們的 read_lints 工具。相反地，若明確、直接地指示在什麼情況下應該呼叫這個工具，Codex 的表現會顯著提升：

After substantive edits, use the read_lints tool to check
recently edited files for linter errors. If you've introduced
any, fix them if you can easily figure out how.

保留推理過程

OpenAI 的推理模型會在工具呼叫之間產生內部推理軌跡，實際上就是一種「chain of thought（思維鏈）」，用來說明模型為何選擇各個動作。Responses API旨在擷取並傳遞這些推理內容（或在敏感情境中傳遞加密的推理內容），讓模型能在多輪互動中維持連貫性，而不必每次都從頭重新構建其計畫。

Codex 尤其仰賴這種連續性。當推理軌跡被丟棄時，模型必須自行推斷先前的思考過程，這往往會導致子目標遺失、規劃能力下降、工具呼叫順序錯亂，或是反覆重新推導先前步驟。在我們的 Cursor Bench 實驗中，從 GPT-5-Codex 移除推理軌跡造成了 30% 的效能下降。相比之下，OpenAIobserved的 GPT-5 在 SWE-bench 上於省略推理軌跡時僅有 3% 的效能下降。

鑑於這種影響的程度，我們加入了警報機制，以確保推理軌跡始終能被保留並正確轉發。這能維持 Agent 的內部規劃完整，並避免在模型被迫在多個工具呼叫之間「補齊空白」時，所產生的效能下降。

讓模型更傾向採取行動

在 Cursor 的預設 Agent 模式中，你會希望 Agent 能依照使用者的請求，自主閱讀並編輯檔案。然而，當你切換到其他分頁後才發現，Agent 一直在等你同意才能繼續時，難免會讓人感到相當挫折。

我們一直在嘗試使用更具體的指令，以更好地引導 Codex：

Unless the user explicitly asks for a plan or some other intent that
makes it clear that code should not be written, assume the user wants
you to make code changes or run tools to solve the user's problem. In
these cases, it's bad to output your proposed solution in a message, you
should go ahead and actually implement the change. If you encounter
challenges or blockers, you should attempt to resolve them yourself.

在Cloud Agents（我們的非同步遠端工作流程）中，我們進一步強化了這種語言。

訊息順序

OpenAI 模型經過訓練，會嚴格遵守並優先處理訊息的先後順序。例如，system 提示詞一律優先於使用者訊息和工具結果。

雖然這樣很有幫助，但這也代表我們必須調整測試框架，確保 Cursor 提供的提示詞不會包含可能意外與使用者訊息相牴觸的指示。否則，Codex 可能會進入一種不願配合使用者請求的狀態。

舉例來說，有段時間我們告訴 Codex 應該注意節省 tokens，避免浪費。不過我們發現，這段提示影響了模型執行更有野心的任務或進行大規模探索的意願。有時它會中途停下來，固執地說：我不應該浪費 tokens，而且我不覺得繼續做這個任務是值得的！

未來展望

模型發佈的速度正不斷提升。我們的目標是，在 Cursor Agent 框架中，充分發揮每一個最先進模型的實力。還有許多工作要完成，我們也會持續分享我們為 Cursor 所做的各項改進。