OpenAI 发布 GPT-4.1 系列，助力开发

1- OpenAI 发布 GPT-4.1 系列，助力开发

注意：GPT‑4.1 仅通过 API 提供。在 ChatGPT 中，许多与指令遵从、编程和智能相关的改进已经逐步整合到了最新版本的 GPT‑4o 中，未来仍会不断加入更多改进。

文章有点长，分三部分：GPT-4.1 系列模型简介、GPT-4.1 Prompt 编写技巧以及支持免费使用 GPT-4.1 的编辑器。

2- GPT-4.1 系列

2.1- 简介

近日，OpenAI 宣布在 API 中正式推出三款全新 GPT 模型（[Introducing GPT-4.1 in the API][1]）：GPT-4.1、GPT-4.1 mini 和 GPT-4.1 nano（基本符合之前的爆料 GPT-4 即将退役，又有新模型曝光）。它们不仅在编程、指令遵从等传统优势上进一步提升，更搭载了前所未有的长上下文处理能力，最高可支持 100 万个 tokens，远超此前的 GPT-4o（可处理 128,000 tokens）。在保持优异性能的同时，GPT-4.1 系列还在成本和延迟上取得了大幅进步，并将知识截止时间更新至 2024 年 6 月。

根据官方发布的数据，这三款新模型在各大基准测试中几乎全线超越前代产品 GPT-4o 和 GPT-4o mini，并且在编程、指令遵从、长上下文、视觉理解等多方面带来了显著改进。

2.2- 模型亮点速览

2.2.1- GPT-4.1

相比 GPT-4o，4.1 在编程、指令遵从、长上下文等方面均有大幅提升；
支持最高 100 万 tokens 的上下文窗口；
在 SWE-bench Verified 上得分 54.6%（比 GPT-4o 提升 21.4% 绝对值），在 Scale 的 MultiChallenge 上得分 38.3%（比 GPT-4o 高 10.5% 绝对值）；
在多模态长上下文基准 Video-MME（长视频无字幕类别）上得分 72.0%，比 GPT-4o 提升 6.7% 绝对值。

2.2.2- GPT-4.1 mini

体量更小、延迟更低，但在诸多基准上反而超过了 GPT-4o；
智力测评表现不逊色于 GPT-4o，且延迟下降近 50%，成本降低 83%。

2.2.3- GPT-4.1 nano

追求极低延迟和最低成本；
同样支持 100 万 tokens 的上下文；
MMLU 得分 80.1%、GPQA 得分 50.3%、Aider polyglot coding 得分 9.8%，均高于 GPT-4o mini；
适用于分类、自动补全等对速度和经济性要求极高的场景。

2.3- 性能提升

2.3.1- 编程

SWE-bench Verified：GPT-4.1 完成率 54.6%，大幅超越 GPT-4o 的 33.2%；
代码 diff 表达能力：在 Aider 的多语言 diff 测试中，GPT‑4.1 表现是 GPT‑4o 的两倍多，且比 GPT-4.5 还高 8% 的绝对值；
前端开发：人类付费评审倾向 GPT-4.1 生成的网站，有 80% 的场景更喜欢其结果；
更少冗余编辑：GPT-4.1 的 " 额外编辑率 " 仅为 2%，远低于 GPT-4o 的 9%。

2.3.2- 指令遵从

集中于格式遵从、否定指令、顺序指令、内容要求、排序、过度自信（需要模型适度拒绝或认知未知信息）六大类别；
在多轮对话的连贯性上有显著增强：
- Scale MultiChallenge 提升 10.5% 绝对值；
- IFEval 得分达 87.4%（GPT-4o 为 81.0%）。
内测者反馈：GPT-4.1 有时更倾向字面理解，因此官方建议在提示词中更清晰、明确地表达需求。

2.3.3- 长上下文

最高可处理 100 万 tokens，是 GPT-4o（128,000 tokens）的近 8 倍；
针对 " 针在长上下文中藏匿 "（大海捞针）这一复杂场景，GPT-4.1 依然能在 100 万 tokens 的内容里准确检索；
OpenAI-MRCR（Multi-Round Coreference）：GPT-4.1 在不同位置插入相似请求时，依然能区分和定位到对应的版本；
Graphwalks 测试多跳推理，GPT-4.1 准确率 61.7%，远高于 GPT-4o；
真实落地案例显示，GPT-4.1 在法律、财务分析等需多文档多跳推理的场景中表现优异。

2.3.4- 视觉

GPT-4.1 系列具备出色的图像理解能力；
对于长视频内容的理解同样提升显著，在 Video-MME（长视频无字幕）上创下 72.0% 的新高。

2.4- 真实案例应用

[Windsurf][2]：内部编程基准比 GPT-4o 高出 60%，在工具调用与减少冗余编辑方面分别提升 30% 和 50%；
[Qodo][3]：在 200 个真实 GitHub PR 测试中，GPT-4.1 给出的修改建议有 55% 的情形被评为更优；
[Blue J][4]：在最复杂的税务场景上，GPT-4.1 准确率比 GPT-4o 高 53%；
[Hex][5]：GPT-4.1 在最具挑战的 SQL 测试中成绩提升近 2 倍，能更准确地选用大规模数据库中正确表格；
[Thomson Reuters][6]：与 CoCounsel（法律助手）结合时，多文档审阅准确率比 GPT‑4o 提升 17%；
[Carlyle][7]：在超大金融文档检索中，GPT-4.1 成功突破关键瓶颈，成功率提高 50%。

还有来自 [Box][8] CEO 分享的测评：

2.5- 价格 & 兼容性

价格下调：GPT-4.1 系列通过推理系统优化，价格整体比 GPT-4o 便宜约 26%；
GPT-4.1 nano：为最快、最便宜模型，专门针对极低延迟与成本需求；
提示词缓存折扣：对于重复输入相同上下文，官方提高了缓存折扣至 75%（此前为 50%）；
长上下文请求：不额外收费，依旧按照标准的每 Token 成本计算。

2.6- 弃用 GPT-4.5 Preview

官方同时宣布将于 2025 年 7 月 14 日 关闭 GPT-4.5 Preview 服务，建议开发者在此之前迁移到 GPT‑4.1。GPT-4.5 虽然曾作为 " 高算力研究预览版 " 进行探索，但实践表明 GPT‑4.1 在诸多核心能力（包括创意性、写作质量和细腻度）上已完全满足或超越需求，且具备更优的性能、成本与延迟。

2.7- 小结

GPT‑4.1 系列的发布，将针对编程、指令遵从、长上下文处理和多模态理解的性能推到了一个新的高度。尤其值得关注的是，GPT‑4.1 的长上下文能力可为法律、金融、客服等专业领域带来深远影响；增强的指令遵从能力也将使对话代理场景更可信、更易用。结合官方推出的 Responses API（浅谈 Agent、MCP、OpenAI Responses API）等基础服务，开发者能够构建更强大的自动化代理系统，大幅提升真实生产环境中的软件工程和数据处理效率。

OpenAI 方面表示，许多 GPT‑4.5 备受好评的写作质量和创意特质已在 GPT‑4.1 中融会贯通，未来将继续通过版本迭代将更多改进纳入 GPT‑4.1 系列。这些产品走向，正预示着新一轮大模型应用浪潮的到来，或将在更多维度改变人类使用智能工具的方式。开发者社区也在持续反馈、创新，相信 GPT-4.1 系列的潜力将在更多复杂场景中进一步被激发。

3- Prompt 编写指南

GPT-4.1 系列模型在编程、指令遵循、长上下文处理等方面相比 GPT-4o 有了显著提升。下面将详细介绍如何利用这一新模型的能力，构建高效的代理工作流、制定长上下文提示策略，以及实现代码差异（Diff）生成与应用，帮助开发者充分发挥 GPT-4.1 的潜力（[GPT 4.1 Prompting Guide GPT 4.1][9]）。

GPT-4.1 的优势：

严格遵循指令：模型在理解细节与执行精确指令上更为出色，能够严格按照开发者设置的系统提示和用户需求行动。
长上下文处理：支持高达 1M token 的上下文输入，使模型在检索式问答、多文档分析等长上下文任务上性能提升明显。
高度可控性：对明确和具体的提示响应十分灵敏，即使发生偏差，只需一句明确的说明即可迅速引导模型回到正确轨道。
增强代理能力：更擅长在多轮交互或连贯的动作场景下充当自动化代理，可在多次工具调用与对话之间进行规划与思考。
优异的工具调用：对通过 API 传入的工具（functions）使用更为准确可控。建议开发者将工具描述清晰地放入专用字段，使模型在调用工具时保持更高的正确率。

提示工程的基本原则：

提供丰富上下文和示例：给出尽量详细的上下文和例子，确保模型准确理解任务需求。
逐步思考与规划：GPT-4.1 虽不是原生的 " 推理模型 "（链式思考，CoT），但通过合理提示可诱导其 " 显式思考 "，即在输出中展示逐步分析过程，提升准确度。
严格遵循指令格式：模型对指令执行较为字面化，因此应明确规定做与不做的事项，尤其在工具调用和输出格式上。

3.1- 代理工作流（Agentic Workflows）

GPT-4.1 是构建 "Agent 化流程 " 的极佳平台。OpenAI 在训练阶段强化了多样化的智能代理解决问题的轨迹，因此 GPT-4.1 在不具备推理能力的模型中，于 SWE-bench Verified 基准测试上达到了 SOTA（最先进）表现，解决率达 55%。

3.1.1- 系统提示提醒（System Prompt Reminders）

为了充分利用 GPT-4.1 的代理能力，OpenAI 推荐在所有代理提示中包含三类关键提醒。以下提示针对代理编码工作流进行了专门优化，但也可方便地改编用于一般代理场景。

1. 持续性（Persistence）：确保模型理解它正处于多轮对话中，并防止其过早地将控制权交还给用户。


<!-- 中文版 -->
你是一位代理——请持续进行直至完全解决用户的问题，然后再结束你的发言并交还控制权。仅当你确信问题解决时才结束你的发言。

<!-- 英文版 -->
You are an agent - please keep going until the user's query is completely resolved, before ending your turn and yielding back to the user. Only terminate your turn when you are sure that the problem is solved.

2. 工具调用（Tool-calling）：鼓励模型充分利用其工具，降低模型凭空杜撰或猜测答案的可能性。


<!-- 中文版 -->
如果你不确定与用户请求相关的文件内容或代码结构，请使用你的工具读取文件并收集相关信息：切勿猜测或杜撰答案。

<!-- 英文版 -->
If you are not sure about file content or codebase structure pertaining to the user's request, use your tools to read files and gather the relevant information: do NOT guess or make up an answer.

3. 计划性（Planning，可选）：如果需要，这条提醒确保模型在每次进行工具调用之前会以文本形式明确进行规划与思考，而不是单纯通过一连串的工具调用来完成任务。


<!-- 中文版 -->
你必须在每次函数调用前进行充分规划，并在前一次函数调用结果出来后进行详细反思。切勿仅仅通过连续的函数调用来完成整个过程，因为这会影响你解决问题和深入思考的能力。

<!-- 英文版 -->
You MUST plan extensively before each function call, and reflect extensively on the outcomes of the previous function calls. DO NOT do this entire process by making function calls only, as this can impair your ability to solve the problem and think insightfully.

加入上述三类提醒后，SWE-bench Verified 得分提升近 20%。这三类指令会显著增强模型的主动性，使其从 " 对话机器人 " 模式转化为具备执行驱动性的 " 自主 Agent"。

3.1.2- 工具调用（Tool Calls）

GPT-4.1 在工具使用方面训练更充分，推荐仅使用 OpenAI API 的 tools 字段传入工具定义，而非像旧方法那样通过 prompt 手动注入工具描述及自定义解析器。实测中，使用 API 原生工具定义方式比手动注入 schema 的方式提高约 2% 的任务成功率。

代码示例：

from openai import OpenAI
client = OpenAI()

assistant = client.beta.assistants.create(
  instructions="You are a weather bot. Use the provided functions to answer questions.",
  model="gpt-4o",
  tools=[
    # 内部工具：有 web_search_preview、file_search、computer_use_preview 等
    {"type": "file_search"},
    {
      "type": "function",
      "function": {
        "name": "get_current_temperature",
        "description": "Get the current temperature for a specific location",
        "parameters": {
          "type": "object",
          "properties": {
            "location": {
              "type": "string",
              "description": "The city and state, e.g., San Francisco, CA"
            },
            "unit": {
              "type": "string",
              "enum": ["Celsius", "Fahrenheit"],
              "description": "The temperature unit to use. Infer this from the user's location."
            }
          },
          "required": ["location", "unit"]
        }
      }
    },
    {
      "type": "function",
      "function": {
        "name": "get_rain_probability",
        "description": "Get the probability of rain for a specific location",
        "parameters": {
          "type": "object",
          "properties": {
            "location": {
              "type": "string",
              "description": "The city and state, e.g., San Francisco, CA"
            }
          },
          "required": ["location"]
        }
      }
    }
  ]
)

在为工具命名时建议使用具说明性的名称，并在 description 字段中详细说明其用途。对于复杂工具，若需展示调用样例，请将其放置于系统提示词的 # Examples 部分，而非混入 description 字段中，以保持结构清晰。

4- 规划与链式思考 (Chain-of-Thought)

虽然 GPT-4.1 本身并不具备自动生成链式思考（CoT）的能力，也不是传统意义上的推理型模型，但开发者可以通过提示词显式诱导其在每次工具调用之间进行规划与反思。这种 " 思维外化 " 策略，能有效提升模型在复杂任务中的表现。特别是在 Agent 工作流中，若模型只是连续调用工具而缺乏中间的计划与复盘，容易出现执行路径偏差或错误判断。

因此，建议在提示中加入结构化的 " 规划提示 "，引导模型在操作前思考并在操作后自我检查。实验证明，这种方式在 SWE-bench Verified 基准测试中，将任务完成率提高了 4%。

4.1- 示例提示：SWE-bench Verified

下面是 OpenAI 在 SWE-bench Verified 测试中取得最高分数所使用的代理提示，其中详细列出了从问题理解、代码库分析、规划修复策略、逐步实现、调试、测试，到最终验证与反思的完整流程。该模式不仅适用于修复开源代码任务，也为构建更通用的 Agent 提示提供了强有力的参考范式。

# 中文版
SYS_PROMPT_SWEBENCH = """你将会接到一个修复开源仓库中问题的任务。

你的思考应当是全面的，长篇大论也是可以接受的。你可以在采取每个行动之前和之后按步骤进行思考。

你必须不断迭代，直至问题完全解决。

你已经在 /testbed 文件夹中拥有解决此问题所需的一切，即使没有网络连接也可以解决。我要求你在回来之前，完全自主地解决这个问题。

仅当你确信问题已解决时，才结束你的发言。请逐步梳理问题，并确保验证你所做的更改无误。绝不要在解决问题前结束你的发言，而且当你宣称要调用工具时，请确保你真正去调用该工具，而非结束发言。

此问题绝对可以在没有互联网的情况下解决。

请仔细思考每一步——记得严格检查你的解决方案，并注意你所做更改涉及的边界情况。你的方案必须完美。若非如此，请继续修改。在最后，你必须利用提供的工具严格测试你的代码，多次运行以捕捉所有边缘情况。如果测试不够健壮，必须继续迭代直至完美。对于这些类型的任务来说，测试代码不充分是最主要的失败原因；请确保处理所有边缘情况，如有提供现有测试则一定运行。

你必须在每次函数调用前进行充分规划，并在前一次函数调用结果出来后进行详细反思。切勿仅通过连续的函数调用来完成整个过程，因为这会损害你解决问题和深入思考的能力。

# 工作流程

## 高层次问题解决策略

1. 深入理解问题。仔细阅读问题描述并深入思考需求。
2. 调查代码库。探索相关文件，寻找关键函数，并收集上下文信息。
3. 制定清晰、分步骤的计划。将修复工作拆分为可管理、可验证的渐进步骤。
4. 逐步实现修复。进行小范围、可测试的代码更改。
5. 必要时调试。使用调试技巧来定位和解决问题。
6. 频繁测试。每次更改后运行测试以验证正确性。
7. 迭代直至根本问题得到修正并所有测试通过。
8. 综合反思和验证。在所有测试通过后，思考原始意图，编写额外测试以确保正确性，并牢记还有隐藏测试也必须通过才能真正算解决问题。

请参阅下文中的详细章节以获取每一步的更多信息。

## 1. 深入理解问题
仔细阅读问题描述，并在编写代码前充分构思解决方案。

## 2. 代码库调查
- 探索相关的文件和目录。
- 搜索与该问题相关的关键函数、类或变量。
- 阅读并理解相关代码片段。
- 找出问题的根本原因。
- 随着上下文信息的不断收集，持续验证和更新你的理解。

## 3. 制定详尽计划
- 列出一个具体、简单且可验证的步骤序列以修复问题。
- 将修复工作拆分成小的、逐步实施的改动。

## 4. 进行代码更改
- 在编辑前，请始终先阅读相关文件或部分以确保获得完整上下文信息。
- 如果补丁未正确应用，请尝试重新应用。
- 进行小、可测试的、渐进式的代码更改，这些更改应当逻辑上紧密衔接你的调查和计划。

## 5. 调试
- 仅在你有足够信心更改能解决问题时才进行代码修改
- 调试时，尝试找出问题的根本原因，而不是仅仅解决表面症状
- 调试需坚持，直至确认问题根因并找到修正办法
- 利用打印语句、日志或临时代码来检查程序状态，并提供描述性语句或错误信息以了解运行情况
- 如需验证假设，也可以添加测试语句或函数
- 如果遇到意外情况，请重新审视你的假设

## 6. 测试
- 频繁使用 `!python3 run_tests.py`（或等效命令）运行测试。
- 每次更改后，通过运行相关测试来验证正确性。
- 如果测试失败，分析失败原因并修改补丁。
- 如有必要，编写额外测试以捕捉重要行为或边缘情况。
- 在最终确定之前，确保所有测试均通过。

## 7. 最终验证
- 确认问题根本原因已经修复。
- 检查你的解决方案在逻辑和健壮性上的正确性。
- 反复迭代直至你对修复完全信心十足且所有测试均通过。

## 8. 最终反思与额外测试
- 仔细反思用户的原始意图及问题描述。
- 考虑是否存在现有测试未覆盖的边缘情况或场景。
- 编写额外测试以全面验证你方案的正确性。
- 运行这些新测试并确保全部通过。
- 注意，还有一些隐藏测试必须通过，不能仅因为可见测试通过就认为任务完成；应持续优化直至你确信修复已稳健而全面。
"""

########################

# 英文版
SYS_PROMPT_SWEBENCH = """You will be tasked to fix an issue from an open-source repository.

Your thinking should be thorough and so it's fine if it's very long. You can think step by step before and after each action you decide to take.

You MUST iterate and keep going until the problem is solved.

You already have everything you need to solve this problem in the /testbed folder, even without internet connection. I want you to fully solve this autonomously before coming back to me.

Only terminate your turn when you are sure that the problem is solved. Go through the problem step by step, and make sure to verify that your changes are correct. NEVER end your turn without having solved the problem, and when you say you are going to make a tool call, make sure you ACTUALLY make the tool call, instead of ending your turn.

THE PROBLEM CAN DEFINITELY BE SOLVED WITHOUT THE INTERNET.

Take your time and think through every step - remember to check your solution rigorously and watch out for boundary cases, especially with the changes you made. Your solution must be perfect. If not, continue working on it. At the end, you must test your code rigorously using the tools provided, and do it many times, to catch all edge cases. If it is not robust, iterate more and make it perfect. Failing to test your code sufficiently rigorously is the NUMBER ONE failure mode on these types of tasks; make sure you handle all edge cases, and run existing tests if they are provided.

You MUST plan extensively before each function call, and reflect extensively on the outcomes of the previous function calls. DO NOT do this entire process by making function calls only, as this can impair your ability to solve the problem and think insightfully.

# Workflow

## High-Level Problem Solving Strategy

1. Understand the problem deeply. Carefully read the issue and think critically about what is required.
2. Investigate the codebase. Explore relevant files, search for key functions, and gather context.
3. Develop a clear, step-by-step plan. Break down the fix into manageable, incremental steps.
4. Implement the fix incrementally. Make small, testable code changes.
5. Debug as needed. Use debugging techniques to isolate and resolve issues.
6. Test frequently. Run tests after each change to verify correctness.
7. Iterate until the root cause is fixed and all tests pass.
8. Reflect and validate comprehensively. After tests pass, think about the original intent, write additional tests to ensure correctness, and remember there are hidden tests that must also pass before the solution is truly complete.

Refer to the detailed sections below for more information on each step.

## 1. Deeply Understand the Problem
Carefully read the issue and think hard about a plan to solve it before coding.

## 2. Codebase Investigation
- Explore relevant files and directories.
- Search for key functions, classes, or variables related to the issue.
- Read and understand relevant code snippets.
- Identify the root cause of the problem.
- Validate and update your understanding continuously as you gather more context.

## 3. Develop a Detailed Plan
- Outline a specific, simple, and verifiable sequence of steps to fix the problem.
- Break down the fix into small, incremental changes.

## 4. Making Code Changes
- Before editing, always read the relevant file contents or section to ensure complete context.
- If a patch is not applied correctly, attempt to reapply it.
- Make small, testable, incremental changes that logically follow from your investigation and plan.

## 5. Debugging
- Make code changes only if you have high confidence they can solve the problem
- When debugging, try to determine the root cause rather than addressing symptoms
- Debug for as long as needed to identify the root cause and identify a fix
- Use print statements, logs, or temporary code to inspect program state, including descriptive statements or error messages to understand what's happening
- To test hypotheses, you can also add test statements or functions
- Revisit your assumptions if unexpected behavior occurs.

## 6. Testing
- Run tests frequently using `!python3 run_tests.py` (or equivalent).
- After each change, verify correctness by running relevant tests.
- If tests fail, analyze failures and revise your patch.
- Write additional tests if needed to capture important behaviors or edge cases.
- Ensure all tests pass before finalizing.

## 7. Final Verification
- Confirm the root cause is fixed.
- Review your solution for logic correctness and robustness.
- Iterate until you are extremely confident the fix is complete and all tests pass.

## 8. Final Reflection and Additional Testing
- Reflect carefully on the original intent of the user and the problem statement.
- Think about potential edge cases or scenarios that may not be covered by existing tests.
- Write additional tests that would need to pass to fully validate the correctness of your solution.
- Run these new tests and ensure they all pass.
- Be aware that there are additional hidden tests that must also pass for the solution to be successful.
- Do not assume the task is complete just because the visible tests pass; continue refining until you are confident the fix is robust and comprehensive.
"""

5- 长上下文（Long Context）

GPT-4.1 拥有高效的 1M tokens 输入上下文窗口，在各种长上下文任务中表现出色，包括结构化文档解析、重排序、在大量上下文中筛选相关信息，以及利用上下文进行多步推理。

5.1- 最优上下文大小

OpenAI 在 " 大海捞针 " 的测试中观察到：在完整的 1M tokens 上下文内，该模型表现非常出色，同时也观察到在处理包含相关与不相关代码及其他文档混杂的复杂任务时模型依然有很强的表现。但当需要检索更多项目，或进行需要全局上下文状态信息（例如进行图搜索）的复杂推理时，长上下文的表现可能会有所下降。

5.2- 调整上下文依赖

需要考虑解答问题时所依赖的外部与内部知识的比例。有时模型需要利用自身知识来连接概念或进行逻辑跳跃，而在其他情况下，则希望模型只使用所提供的上下文信息。

<!-- 中文版 -->
# 指令
// 针对内部知识
- 仅使用提供的 External Context 内的文档来回答用户问题。如果你依据这些上下文信息无法得出答案，即使用户坚持要求回答，你也必须回应“我没有足够的信息来回答这个问题”。
// 针对内部和外部知识
- 默认情况下，使用提供的外部上下文来回答用户问题，但如果需要其他基本知识来作答，并且你对答案有足够信心，可以适当使用

#科技 #人工智能

#大语言模型 #OpenAI #GPT-4.1 #开发者

GLM-Z1-Air-智谱开源模型上一篇

Cursor + Claude 3.7 一键生成惊艳的 3D 网页视觉下一篇