当模型遇上产品，光有智商不够#

你拿到了一个强大的编程模型，把它接入你的 IDE，然后满怀期待地点击 “Run Agent”。

结果呢？它要么呆在那里等你确认每一步操作，要么自顾自地写一堆 shell 脚本把你的项目搞得一团糟，又或者在中途突然 “失忆”，忘记了自己刚才在干什么。

这不是模型不够聪明，而是它不够 “懂” 你的产品。

最近，Cursor 团队发布了一篇技术博客，详细分享了他们如何为 OpenAI 最新的 Codex 模型（GPT-5.1-Codex-Max）定制 Agent 框架。这篇文章的价值不在于 Cursor 有多厉害，而在于它揭示了一个被很多人忽略的事实：把一个强大的模型变成一个好用的 Agent，中间隔着大量的工程打磨。

今天我们就来拆解 Cursor 的实战经验，看看他们到底做了哪些事情。

核心挑战：每个模型都有自己的 “脾气”#

Cursor 支持所有主流的编程模型，从 Claude 到 GPT 再到 Gemini。但每个模型的训练方式不同，导致它们在实际使用中表现出截然不同的偏好和行为模式。

Codex 模型是 OpenAI 基于 GPT-5 系列专门为 Agent 编程场景训练的版本。它在训练过程中接触到的工具和指令，和 Cursor 提供的环境有很大差异。Cursor 的工作就是弥合这个差距，让模型在 Cursor 的环境中也能发挥最佳水平。

他们用内部的评测套件 Cursor Bench 来衡量每个模型的表现，关注三个维度：任务成功率、工具调用质量、以及用户的实际采纳率。

第一招：让工具更像 shell#

Codex CLI 的训练环境是以 shell 为核心的。模型在训练时学到的是：用 rg（ripgrep）搜索文件，用 cat 读取内容，用 shell 脚本做编辑。

但 Cursor 提供的是结构化的工具调用（read_file、edit_file 等）。这就产生了一个冲突：模型更习惯用 shell，但 Cursor 的工具更安全、体验更好。

Cursor 的解决方案很聪明：

  1. 把工具命名变得更像 shell 等价物，降低模型的认知切换成本
  2. 在提示词中明确指示：“如果某个工具有对应的 action，请优先使用工具而非 shell 命令（比如用 read_file 而不是 cat）”
  3. 保留 Sandbox 机制，即使模型仍然选择执行 shell 命令，Sandbox 也能阻止未授权的文件访问和网络活动

这个策略的精髓在于：不是强迫模型改变习惯，而是在它的习惯和你的需求之间架一座桥。

第二招：管好模型的 “话痨” 倾向#

Codex 模型和 GPT-5 主线模型有一个重要区别：它使用推理摘要（reasoning summaries）来和用户沟通进度。这些摘要可能是一行标题，也可能是一整段说明。

问题是，如果放任不管，模型会产生大量冗余的中间输出，用户很快就会信息过载然后彻底忽略。

Cursor 给模型制定了几条规则：

  • 推理摘要控制在 1 到 2 句话
  • 只在发现新信息或切换策略时才输出摘要
  • 禁止自我指涉（比如 “我正在向用户解释…"）

更有趣的是，Cursor 发现 Codex 模型在 Agent 轮次中无法像普通聊天模型那样 “说话”。它只能通过推理摘要来沟通，直到整个轮次结束后才能生成正式回复。因此，Cursor 从提示词中移除了所有与 “中途和用户对话” 相关的指令，结果模型的代码输出质量反而提升了。

这给我们的启示是：有时候，少说话的 Agent 才是好 Agent。

第三招：别让模型假装没看见 lint 错误#

Cursor 为所有模型都提供了读取 linter 错误的工具（比如 ESLint、Biome），理论上模型可以自动修复这些错误。

但 Codex 模型有个问题：光给它工具定义不够，它不会主动去调用。你需要用非常直白的语言告诉它：

“在做了实质性编辑之后，使用 read_lints 工具检查最近编辑过的文件是否有 linter 错误。如果有，且你能轻松修复，就修复它。”

这种 “明确指令优于隐含暗示” 的现象，在 Codex 模型上特别明显。相比其他模型，Codex 更依赖字面上的指令，而不是从上下文推断意图。

对于 Agent 工程师来说，这意味着你需要重新审视你的提示词策略。那些你觉得 “模型应该能理解” 的隐含规则，在 Codex 身上可能需要被显式地写出来。

第四招：推理链是 Codex 的命脉#

这是整篇文章中最让人震惊的发现。

OpenAI 的推理模型会在工具调用之间产生内部推理链（reasoning traces），本质上是模型的 “思考过程”。Responses API 被设计用来捕获和传递这些推理项，让模型在多轮交互中保持思维的连续性。

Codex 模型对这种连续性的依赖程度远超其他模型。Cursor 的实验数据表明：

  • 移除推理链后，Codex 在 Cursor Bench 上的性能下降了 30%
  • 作为对比，GPT-5 在 SWE-bench 上去掉推理链只下降了 3%

30% vs 3%，这个差距说明了什么？Codex 模型把推理链当作自己的 “工作记忆”。一旦丢失，它就需要从头推断之前的思考过程，导致子目标遗忘、规划退化、工具调用顺序混乱，甚至反复重新推导已经完成的步骤。

Cursor 因此增加了告警机制，确保推理链始终被正确保留和传递。这对所有使用 Codex 模型的开发者都是一个重要提醒：如果你在构建基于 Codex 的 Agent，推理链的完整性是性能的生命线。

第五招：推着模型去行动#

在 Cursor 的默认 Agent 模式下，用户期望的是：提出需求，然后 Agent 自主完成读取文件、编辑代码、运行测试等一系列操作。

但 Codex 模型有时会表现得过于 “谨慎”，停下来等待用户确认下一步操作。你切到别的窗口干了五分钟活，回来看到 Agent 还在问 “您确定要我继续吗？”

Cursor 的解决方案是在提示词中加入更强的行动导向指令：

“除非用户明确要求制定计划，或者有其他明确信号表明不应该写代码，否则假设用户希望你直接修改代码或运行工具来解决问题。在这种情况下，输出你的方案而不是直接实现是不好的做法。如果遇到困难或阻碍，你应该尝试自己解决。”

在 Cloud Agents（Cursor 的异步远程工作流）中，这种指令的措辞甚至更强。

第六招：小心消息优先级的陷阱#

OpenAI 模型有一个训练特性：它们会严格尊重消息的优先级顺序。系统提示词（system prompt）的优先级始终高于用户消息和工具结果。

这个特性本身是好事，确保了安全指令不会被用户消息覆盖。但它也带来了一个隐患：如果系统提示词中的某些指令和用户的实际需求产生了矛盾，模型可能会拒绝执行用户的请求。

Cursor 分享了一个真实的踩坑经历。他们曾经在提示词中告诉 Codex “要注意节省 token，不要浪费”。结果这个指令严重影响了模型执行复杂任务的意愿。模型有时会固执地说：“我觉得不应该继续浪费 token 来完成这个任务！”

这个案例生动地说明了提示词工程中的一个常见陷阱：你以为在约束浪费行为，实际上在扼杀创造力。

对 Agent 开发者的启示#

Cursor 的这篇分享，表面上是在讲如何适配 Codex 模型，但背后蕴含的工程智慧对所有 Agent 开发者都有价值：

1. 了解你的模型的训练背景。模型在训练时接触了什么样的工具和指令，会深刻影响它在你的产品中的行为。适配不是从零开始，而是在模型已有的能力和你的需求之间找到平衡点。

2. 明确指令优于隐含暗示。不同模型对指令的解读方式不同。Codex 更偏向字面理解，这意味着你的提示词需要更加直白和具体。

3. 推理链不是可选项。对于依赖推理链的模型，确保推理过程的完整性是性能的基本保障。任何导致推理链丢失的架构设计都需要重新审视。

4. 行动导向需要显式引导。不要假设模型会自动变得积极主动。如果你想让 Agent 自主行动，就需要在提示词中明确表达这个期望。

5. 警惕好心办坏事的约束。那些看似合理的 “不要做 X” 指令，可能会产生远超预期的副作用。每个约束都需要在真实场景中验证。

写在最后#

AI 编程工具的竞争正在从 “谁的模型更聪明” 转向 “谁的工程做得更好”。Cursor 的这篇文章让我们看到了这个转变的缩影。

模型是引擎，Agent 框架是底盘。没有好的底盘，再强的引擎也跑不出好成绩。对于正在构建 AI 编程工具的团队来说，Cursor 分享的这些经验，值得反复研读。

参考来源：Improving Cursor’s agent for OpenAI Codex models，Cursor Team，2026 年 5 月