Cursor 可与所有最前沿的 AI 编码模型集成。

每个模型都需要特定的指令和对我们代理运行框架的微调，以提升输出质量、避免“偷懒”、更高效地调用工具等。

我们一直与 OpenAI 合作，通过 Cursor 的 Agent 向开发者提供其模型。本文将介绍我们如何更新 Agent 的运行框架，以支持其最新的前沿编码模型 GPT-5.1-Codex-Max。

构建健壮的 Agent 测试框架

Cursor 的代理执行框架中的每个模型，都提供了专用的指令和工具，以便在 Cursor 环境中对该模型进行优化。

AI 实验室会基于多种不同的指令和工具来训练新模型。在编码这类特定领域中，模型可能会更偏好与其在训练中已经见过的模式相似的做法。在将新模型接入 Cursor 时，我们的工作是把这些模型已经熟悉的通用指令和工具与 Cursor 专属的指令和工具一并集成，并基于 Cursor Bench（我们内部的一套评测套件）对它们进行调优。

我们根据模型的成功率、工具调用能力以及在用户中的整体使用情况来评估其质量和健壮性。以下是我们对 Codex 代理测试框架所做的一些更新。

更新到最新的 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 句话内，在发现新信息或启动新策略时加以说明，并避免对自身的交流行为进行评论（例如“我正在向用户解释……”）。

由于 Codex 模型在一个代理轮次结束之前无法正常“说话”，我们移除了提示词中所有与在轮次中途与用户交流相关的表述。我们发现，这提升了模型最终生成代码的质量。

查看 Lint 提示

Cursor 在我们的运行环境中向所有模型提供工具，使其能够读取 linter 错误（如 ESLint、Biome），并让智能代理自动进行修复。

我们发现，仅向 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%。相比之下，OpenAI观察到，在 SWE-bench 上，当省略推理轨迹时，GPT-5 的性能仅有 3% 的小幅下降。

鉴于这一影响的程度，我们新增了告警机制，以确保推理轨迹始终被完整保留并正确转发。这样可以保持智能体的内部计划完整一致，并防止在模型被迫在多次工具调用之间“补全空白”时出现性能退化。

让模型更倾向于采取行动

在 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 上所做的改进。