OpenAI 推出的 GPT-5 延续了熟悉的目标——更高的准确性、速度与开发者可控性——同时配备了一套全新的 API 参数与工具集成，改变了团队设计提示词、调用模型以及将模型连接到外部运行时的方式。本文解释关键变化、展示具体使用模式，并给出安全且具成本效益的采用最佳实践。
我需要了解哪些新的 GPT-5 模型、参数和工具？
什么是 GPT-5？
OpenAI 现以多种版本发布 GPT-5，便于开发者在延迟、成本与能力之间权衡：gpt-5（完整推理模型）、gpt-5-mini（均衡版）以及 gpt-5-nano（低成本、低延迟）。这些规格让你能够选择最适合短查询、批处理或重度推理任务的模型。在 ChatGPT 中，GPT-5 以包含“思考”组件的系统呈现；API 版本则直接面向推理模型，供开发者使用。
新的 API 参数（高层概览）
一些影响输出与成本控制的公开参数尤其值得关注：
- 重要新参数：
verbosity（low/medium/high）用于控制答案的长度/结构；reasoning_effort（现为：minimal、low、medium、high）用于控制模型在回复前的思考投入。当你更重视速度而非深度思维链时，使用minimal。 - minimal / reasoning 模式——在偏好更快、较低推理（适用于简短事实检索）与扩展推理（“思考”）之间进行选择，当需要更深的思维链时使用扩展推理。
- 长上下文与令牌：GPT-5 支持超大上下文（总计约 400k tokens：文档中约 272k 输入 + 128k 输出）——可用于超大文档、代码库或长对话。
这些参数让你在调用层面（而不仅仅通过选择模型大小）调整质量、延迟与成本之间的权衡。
新的工具类型与原始负载支持
GPT-5 最实用的新增之一是新的 custom 工具类型，它允许模型向你的工具运行时发送原始文本负载（例如：Python 脚本、SQL 语句、Shell 命令或任意配置文本），无需 JSON 封装的函数调用。这在将模型连接到沙箱、解释器或数据库时降低了摩擦，并使更丰富的“按需软件”模式成为可能。
约束输出：你可以强制使用语法/契约（上下文无关文法，Context-Free Grammar，CFG），以确保工具负载在你的运行时中语法有效。并行工具调用 + CFG 能让你安全地自动化多步骤的代理式工作流。
我如何在 API 中调用这些新参数与工具？
（使用官方 Python SDK 模式 from openai import OpenAI 和文档中的 Responses API。）
1) 设置 verbosity + reasoning_effort
from openai import OpenAI
client = OpenAI(
base_url="https://api.cometapi.com/v1/responses",
api_key="<YOUR_CometAPI_KEY>",
)
resp = client.responses.create(
model="gpt-5",
input="请用一个简短段落总结以下会议记录：...",
parameters={
"verbosity": "low", # 低 / 中 / 高
"reasoning_effort": "minimal", # minimal / low / medium / high
"max_output_tokens": 200
}
)
print(resp.output_text) # SDK 的便捷属性会聚合返回的文本
当你需要低延迟与简洁时，这将返回简短且快速的答案。
2) 使用原始文本负载调用自定义工具（自由格式）
# 示例：向你的 "sql_runner" 自定义工具发送原始 SQL 查询（非 JSON）
from openai import OpenAI
client = OpenAI(
base_url="https://api.cometapi.com/v1/responses",
api_key="<YOUR_CometAPI_KEY>",
)
resp = client.responses.create(
model="gpt-5",
input="获取上个月的平均订单金额，并仅返回一条 SQL 查询。",
tools=[
{
"name": "sql_runner",
"type": "custom",
"description": "执行原始 SQL 并返回结果。"
}
],
parameters={
"verbosity": "medium"
}
)
# 模型可以发出文本，工具将直接接收（原始 SQL）
# 你的后端如何接收并执行模型->工具的负载取决于你的 webhook/运行时。
print(resp.output_text)
如果 SQL 必须遵循严格语法或允许的模式，请使用 CFG。 (, )
3) 示例：使用 CFG 约束输出
# 附加语法到工具调用的伪代码/概念示例。
client.responses.create(
model="gpt-5",
input="生成一个用于列出 .txt 文件的安全 shell 命令。",
tools=[{
"name":"shell_exec",
"type":"custom",
"description":"在沙箱中运行 shell 命令",
"grammar": "COMMAND -> 'ls' ' ' DIR_FILTER; DIR_FILTER -> '*.txt' | '-la *.txt'"
}],
parameters={"verbosity":"low"}
)
grammar/CFG 确保 GPT-5 只输出你的运行器所接受的命令模式。
如何注册并使用 custom 工具发送原始负载？
custom 工具在你系统中注册工具时定义。该工具接收纯文本（非结构化 JSON），因此你的运行时必须准备好解析与验证。
- 注册工具（服务器端；伪定义）：
{
"name": "code_executor",
"type": "custom",
"description": "在沙箱中运行 Python 代码并返回输出或错误。"
}
- 模型调用该工具——示例助手指令（当模型希望调用该工具时会生成的内容）：
<tool name="code_executor">
print(run_tests_on_module('payment_processor'))
</tool>
- 你的运行时安全地（沙箱中）执行原始文本，将输出字符串返回给 API 或你的代理循环，模型使用返回的文本继续对话。
面对 GPT-5 新选项，提示词工程应如何调整？
何时使用“思考”（扩展推理）与何时选择最简回复？
将“思考”/扩展推理用于需要逐步推导、多阶段规划或必须遵循约束的代码生成等任务。将最小推理或 mini/nano 保留给短查询、检索任务以及大规模扇出工作负载（例如对大量候选进行评分）。当准确性至关重要（金融、法律、诊断），优先选择更高推理/默认的 gpt-5 并添加后置检查。OpenAI 仍强调 GPT-5 并非 AGI——它增强了能力但并非完美的真实来源——因此请根据需求选择推理模式。
将 GPT-5 与外部运行时和工具集成的最佳实践
工具运行时架构应如何设计？
- 隔离工具执行环境：每请求的临时容器或专用的沙箱进程。
- 单独对工具使用进行速率限制与配额控制，以管理成本与风险。
- 审计日志：记录工具输入、输出，以及模型调用工具的决策，用于事后分析与合规。
- 错误处理：设计运行时返回结构化错误代码与简短可读信息，以便模型重试、回退或解释错误。
必要的安全控制有哪些？
- 对以原始文本接收的代码进行静态分析，白名单允许的模块与运行时 API。
- 对容器进行网络隔离，并设置严格的出口规则。
- 机密管理——切勿直接向模型暴露服务账号密钥；如需远程访问，使用后端生成的短期令牌。
- 对高风险操作（金融交易、部署）设置人机环节把关。这些是启用工具的代理的标准安全模式。
实用技巧与最佳实践
- 优先使用
verbosity而非反复改写提示词来调整长度/细节级别。 - 使用
reasoning_effort做成本/延迟权衡。UI 或快速事实检索设为minimal，复杂推理任务设为high。 - 工具安全：在执行之前始终验证/转义模型输出的任何原始文本。使用 CFG 与服务端的净化作为第二道防线。（Cookbook 对工具安全有警示。）
- 并行工具调用：可同时发出多个工具调用以提升速度（例如，网页搜索 + 数据库查询），再由模型综合结果。适用于代理式流程。
- 当消费者需要 JSON 时使用结构化输出/JSON Schema 支持。仅在原始文本更自然于目标运行时时使用自由格式。
- 流式与长输出：在生成过程中使用流式处理长输出（尤其是在巨大令牌预算下）。
如何衡量、测试与优化性能和成本？
应该跟踪哪些指标？
- 每次请求的令牌数与每次调用成本（使用模型大小 + verbosity 估算）。
- 延迟（p95/p99）与错误率——尤其是触发外部工具执行的请求。
- 质量指标：自动化检查通过率、人工验证通过率、在金标准测试上的幻觉频率。
如何开展实验
- 在代表性工作负载上对模型大小进行 A/B（
gpt-5与gpt-5-mini），衡量准确性与成本。在需要大量短答案的工作负载中，mini或nano往往能在保持可接受准确性的同时显著降低成本。厂商与媒体早期基准强调了这些权衡；在关键任务上运行你自己的测试。
限制与负责任使用的注意事项
GPT-5 是 AGI 或绝对可靠的吗？
OpenAI 将 GPT-5 定位为在可用性与推理方面的重大改进，而非 AGI。预计在编码、数学与多步推理方面有显著提升，但也会有偶发错误与幻觉。请在产品工作流中规划对模型输出的正确性验证，尤其是在敏感领域自动执行之前。
合规、隐私与数据治理
- 将提示与模型输出视为敏感信息：若你的政策禁止向 API 发送此类数据，请在发送前对 PII 进行掩蔽。
- 理解你的账号/地区在 OpenAI 条款中的保留与使用政策。若需要更强的数据保护，请使用企业合约。
- 在模型对用户产生实质性影响的决策中，向终端用户记录并披露模型的角色（许多司法辖区有透明度要求）。
快速检查清单与上手代码模式
预发布检查清单
- 选择目标模型（准确性 vs 成本）：
gpt-5、gpt-5-mini或gpt-5-nano。 - 为各端点定义
verbosity默认值（例如驱动快速搜索 vs 深度分析的端点）。 - 注册并加固
custom工具运行时（沙箱、验证器、日志）。 - 为在你的系统上执行的任何工具输出添加自动化验证步骤。
- 为令牌、延迟与模型质量指标创建监控看板。
编排模式示例（伪代码）
- 用户请求 → 选择模型与 verbosity（路由逻辑）。
- 系统提示定义工具语法与推理模式。
- 发送聊天补全请求。
- 若助手调用
custom工具：验证负载 → 在沙箱执行 → 将结果返回给助手 → 助手完成最终响应。 - 若操作为高风险：要求人工审批。
在 CometAPI 中使用 GPT-5
CometAPI 是一个统一的 API 平台，将包括 OpenAI 的 GPT 系列、Google 的 Gemini、Anthropic 的 Claude、Midjourney、Suno 等在内的 500 多个领先供应商的 AI 模型聚合到一个对开发者友好的接口中。通过提供一致的认证、请求格式与响应处理，CometAPI 显著简化了将 AI 能力集成到你的应用中的过程。无论你在构建聊天机器人、图像生成器、音乐作曲，还是数据驱动的分析管道，CometAPI 都能让你更快迭代、控制成本并保持供应商无关性，同时利用 AI 生态的最新突破。
权威参考请查阅 OpenAI 的 Cookbook 中关于 GPT-5 参数与工具的条目——这些是 API 字段、工具注册与使用模式的主要来源。
最后思考
GPT-5 将模型大小、verbosity 等新参数与 custom 工具的原始负载支持相结合，为产品团队创造了强大的新选项——从低成本的大规模评分作业到“按需软件”工作流，在其中模型生成代码或 SQL 由你安全的运行时执行。权衡依旧熟悉：能力 vs 成本、速度 vs 深度，以及自动化 vs 人类监督。小步起步（选择一个单一的探索用例）、完善监测并迭代——将你的工具运行时与提示词设计为使模型输出在成为行动之前是可验证的。
开发者可以通过 CometAPI 访问 GPT-5、GPT-5 Nano 与 GPT-5 Mini，文章发布时列出了最新的模型版本。开始之前，请在 Playground 中探索模型能力，并查阅 API guide 获取详细说明。访问前请确保已登录 CometAPI 并获取 API Key。CometAPI 提供远低于官方价格的方案，帮助你集成。
你可以使用 Cpmr 的 gpt-5 API 来试验新参数。只需将 openAI 的密钥替换为 CometAPI 的密钥。你也可以使用 CometAPI 的 gpt-5 API 来试验新参数。只需将 openAI 的密钥替换为 CometAPI 的密钥。两种选择：Chat Completions function-calling pattern 与 Response function-calling pattern.
Passing CoT（思维链）仅存在于 Responses API 中，这将提升智能、减少生成的推理令牌数量、提高缓存命中率并降低延迟。多数其他参数保持不变，但格式有所不同。因此我们建议使用 Response 格式在 CometAPI 中访问 gpt-5。