ACORG docs

主题

GPT 模型 ​

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

最后核对:2026-09-23。模型、价格与可用性可能随后变化,调用前请再查看官方模型列表。

当前口径 ​

OpenAI 当前模型列表将 gpt-6-astra 定位为复杂推理和编码的旗舰选择；兼顾能力与成本可评估 gpt-6-sol，高吞吐、成本敏感任务可评估 gpt-6-luna。新手测试 API 是否连通时,优先选择较轻量模型,再根据真实任务评估是否升级。

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

模型家族 ​

当前常见选择:

  • gpt-6-astra: 适合复杂编码、推理和多步骤 Agent 任务,优先考虑质量时评估。
  • gpt-6-sol: 适合希望兼顾能力与成本的专业任务。
  • gpt-6-luna: 适合高吞吐、成本敏感的分类、抽取与重复任务。
  • GPT-5.6 系列: 旧项目可保留作迁移基线,不应在未评测的情况下直接替换生产模型。
  • GPT-4o / GPT-4.1 / o 系列: 仍可能在旧项目或特定场景中出现,但新项目不要默认以它们作为首选。

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

核心特性 ​

  • 生态完善:官方 SDK 覆盖 JavaScript / TypeScript、Python、Java、Go 等主流语言。
  • Responses API:当前推荐的统一生成与 Agentic API,更适合工具调用和状态化工作流。
  • Reasoning effort: GPT-6 Astra 支持 low、medium、high、xhigh、max；它不支持 none,不同模型的可用值请以模型页为准。
  • 工具能力:支持函数调用、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:

下面使用 gpt-6-luna 演示一次简单请求,只用于验证 API 调用。实际任务请按质量、延迟和成本选择模型。运行前先配置 OPENAI_API_KEY；请求会按 API 用量计费。

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

client = OpenAI()

response = client.responses.create(
    model="gpt-6-luna",
    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-6-luna",
  instructions: "你是一个严谨的 Python 工程师。",
  input: "用 Python 写一个 LRU 缓存,包含简短说明。",
});

console.log(response.output_text);

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

选型建议 ​

  • 复杂代码 / Agent / 产品级任务执行:先评估当前旗舰模型。
  • 强能力但更重视成本:评估较轻量的前沿模型。
  • 日常摘要、分类、抽取、批量处理:优先评估较轻量的 Luna 类模型。
  • 专用编码 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:尤其适合固定系统提示、长文档和多轮相似请求

参考链接 ​