ACORG docs

主题

GPT 模型 ​

OpenAI 推出的 GPT 系列大语言模型,覆盖对话、编程、内容生成、多模态理解和 Agent 工作流。模型、价格、上下文窗口和地区可用性变化较快,发布前应重新核对官方模型页。

最后核对:2026-06-04。

当前口径 ​

OpenAI 官方 API 文档建议,如果不确定从哪里开始,复杂推理和编码任务优先评估 gpt-5.5;如果更重视延迟和成本,再评估 mini / nano 等更轻量型号。

本文只保留可操作的选型方法和 API 写法。具体模型 ID、价格、上下文窗口、输入输出模态以官方模型列表和价格页为准。

模型家族 ​

当前常见选择:

  • gpt-5.5: 当前最新旗舰模型,适合复杂专业工作、编码、多步骤推理、工具密集型 Agent。支持文本和图像输入、文本输出,上下文窗口约 1.05M,最大输出 128K tokens。
  • gpt-5.4: 更经济的前沿模型,适合需要强能力但希望控制成本的编码和专业工作。
  • gpt-5.4-mini: 强 mini 模型,适合高吞吐、编码、computer use、subagents 等场景,上下文窗口 400K。
  • gpt-5.4-nano: GPT-5.4 级别的最低成本型号,适合分类、抽取、排序、简单数据处理和大量子任务。
  • gpt-5.3-codex: 面向 Codex / 编码 Agent 的专用模型之一。多数 API 代码生成任务仍建议先从最新通用模型 gpt-5.5 评估。
  • GPT-4o / GPT-4.1 / o 系列: 仍可能在旧项目或特定场景中出现,但新项目不要默认以它们作为首选。

实际可用模型、价格、上下文窗口和地区可用性以 OpenAI 官方模型页为准。

核心特性 ​

  • 生态完善:官方 SDK 覆盖 JavaScript / TypeScript、Python、Java、Go 等主流语言。
  • Responses API:当前推荐的统一生成与 Agentic API,更适合工具调用和状态化工作流。
  • Reasoning effort: GPT-5.5 / GPT-5.4 系列支持 none、low、medium、high、xhigh 等推理强度
  • 工具能力:支持函数调用、Web search、File search、Code Interpreter、Computer use、MCP 等工具能力。
  • 结构化输出:可约束 JSON Schema 输出,适合生产系统集成。
  • 多模态:GPT 模型覆盖文本、图像等输入场景;低延迟语音交互使用 Realtime 系列模型。
  • Agents SDK:用于构建带工具、handoff、trace、eval 的 Agent 应用。

使用方式 ​

1. 通过 ChatGPT / Codex ​

2. 通过 API ​

获取 API Key:https://platform.openai.com/api-keys

新项目建议优先使用 Responses API:

bash
curl https://api.openai.com/v1/responses \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5.5",
    "instructions": "你是一个严谨的 Python 工程师。",
    "input": "用 Python 写一个 LRU 缓存,包含简短说明。"
  }'
python
# pip install openai
from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-5.5",
    instructions="你是一个严谨的 Python 工程师。",
    input="用 Python 写一个 LRU 缓存,包含简短说明。",
)

print(response.output_text)
typescript
// npm i openai
import OpenAI from "openai";

const client = new OpenAI();

const response = await client.responses.create({
  model: "gpt-5.5",
  instructions: "你是一个严谨的 Python 工程师。",
  input: "用 Python 写一个 LRU 缓存,包含简短说明。",
});

console.log(response.output_text);

Chat Completions API 仍可用于兼容旧系统,但新代码优先评估 client.responses.create()。

选型建议 ​

  • 复杂代码 / Agent / 产品级任务执行:先评估当前旗舰模型。
  • 强能力但更重视成本:评估较轻量的前沿模型。
  • 日常摘要、分类、抽取、批量处理:优先 mini / nano 类模型。
  • 专用编码 Agent:用真实仓库任务比较通用旗舰模型与 Codex 专用模型。
  • 旧系统迁移:保留现有模型做基线,再评估新模型的质量、成本和延迟。

生产环境至少比较:

  • 任务质量和失败模式
  • 输入 / 输出 token 成本
  • 延迟和吞吐
  • 工具调用准确率
  • 结构化输出稳定性
  • 上下文窗口需求

使用技巧 ​

  1. 新项目优先用 Responses API:保留 Chat Completions 主要用于旧系统兼容。
  2. 长期约束放在 instructions 或 developer message 中:不要把所有规则混进用户输入。
  3. 根据任务调整推理强度:简单任务用低推理强度,复杂规划、编码和工具链任务再提高。
  4. 结构化输出使用 Structured Outputs:不要只靠“请输出 JSON”约束生产接口。
  5. 工具调用写清楚用途、参数和副作用:工具描述越含糊,调用错误率越高。
  6. 批量离线任务使用 Batch API:适合非实时、大规模、可排队的处理。
  7. 迁移模型要重新做基线:新模型族不要直接套旧提示词栈。
  8. 长前缀和重复上下文利用 Prompt Caching:尤其适合固定系统提示、长文档和多轮相似请求

参考链接 ​