필사 모드: GPT-5 开发者实战指南：智能体编程、工具调用与成本优化

• 为什么 GPT-5 会改变开发工作流
• GPT-5 实际改变了什么
  • 1. 擅长编程与智能体任务
  • 2. 控制参数更清晰
  • 3. 自定义工具更灵活
  • 4. 格式约束更强
  • 5. 可以在多个 API 界面上使用
• 该怎么选模型规模
• 控制参数什么时候降、什么时候升
• 智能体编程中发生了什么变化
• 自定义工具和格式约束如何搭配使用
• Responses API 和 Chat Completions API 该什么时候用
  • Responses API
  • Chat Completions API
• 该如何降低成本和延迟
  • 提示词缓存
  • Batch API
  • 实战标准
• 生产环境上线检查清单
• FAQ
  • GPT-5 最适合哪些任务
  • gpt-5-mini 和 gpt-5-nano 该怎么选
  • reasoning_effort 什么时候该调高
  • 为什么 verbosity 很重要
  • 新项目该从 Responses API 还是 Chat Completions API 开始
• References

为什么 GPT-5 会改变开发工作流

OpenAI 于 2025 年 8 月 7 日在 Introducing GPT-5 for developers 中，将 GPT-5 介绍为面向编程与智能体任务的最佳模型。这次发布的核心，不在于多了一款更好的聊天模型，而在于开发者使用模型的方式，从「把提示词写好」这一层，提升到了同时设计工具调用、输出约束、延迟、成本、智能体执行这一整套体系的层次。

以往的开发工作流通常是这样的顺序。

• 挑一个模型
• 写提示词
• 祈祷 JSON 能正常输出
• 工具调用出错就事后修补
• 成本和速度留到后面再说

GPT-5 把这套流程变得更明确了。现在开发者不仅要决定让模型做什么，还要一起决定回答要多长、要想多深、用什么格式输出、用什么约束调用哪些工具。结果就是，在智能体编程和运营自动化上，这比单纯打磨提示词要稳定得多。

GPT-5 实际改变了什么

GPT-5 在实务中之所以重要，与其说是单纯的性能提升，不如说是开发者能控制的范围变宽了。

1. 擅长编程与智能体任务

OpenAI 把 GPT-5 描述为在代码修改、修 bug、复杂代码库问答、跨工具的智能体任务上尤其出色的模型。也就是说，它更适合执行任务，而不只是生成单次回答。

2. 控制参数更清晰

实务中首先要掌握的控制参数有两个。

• verbosity：调整回答的长度和说明的详尽程度
• reasoning_effort：调整模型思考的深度

大体上，verbosity 改变的是输出格式和阅读体验，reasoning_effort 改变的是准确率、延迟和 token 用量之间的平衡。

3. 自定义工具更灵活

GPT-5 的自定义工具不仅能接收 JSON，还能通过 plaintext 输入调用工具。这一点在 SQL、DSL、shell 风格命令、专有内部格式这类硬塞进 JSON 会显得别扭的场景中格外好用。

4. 格式约束更强

如果需要，可以用正则表达式限制输出格式，要求更严格时还可以用 CFG。实务中，比起「看起来差不多对」，往往必须严格符合格式更重要，这项能力能大幅提升智能体的可靠性。

5. 可以在多个 API 界面上使用

GPT-5 既能在 Responses API 上用，也能在 Chat Completions API 上用，还自然地融入了 OpenAI Codex CLI 的默认开发工作流。也就是说，一套摸索出来的运营原则，可以在交互式聊天、代码智能体、批处理式任务之间复用。

该怎么选模型规模

GPT-5 系列通常分为 gpt-5、gpt-5-mini、gpt-5-nano 来考虑更方便。选择标准不是「最聪明的模型」，而是任务的风险程度和重复程度。

实务上的经验很简单：核心路径用 gpt-5，辅助路径用 gpt-5-mini，大批量预处理用 gpt-5-nano，这样划分后设计会轻松很多。

控制参数什么时候降、什么时候升

把 GPT-5 用好的团队，靠的不是「好提示词」，而是好的默认值。按下面的标准来定初始值，运营会轻松不少。

推荐的思路是这样的。

• verbosity 调整的是用户阅读的感受
• reasoning_effort 调整的是模型工作的深度

一开始就把两者都调高，质量看起来会不错，但成本和延迟会急剧上升；反过来两者都调得太低，速度是快了，但智能体解不透问题。

智能体编程中发生了什么变化

比起一次性的代码生成器，GPT-5 更像是一起读代码库的协作者。所以实战中重要的不是「能不能一次写好代码」，而是下面这条流程。

1. 是否充分理解任务范围
2. 是否恰当选取所需的文件和工具
3. 是否边说明中间结果边推进
4. 变更之后是否自行验证
5. 失败后是否保留上下文重新尝试

在这类任务里，gpt-5 最合适，尤其在下面这些场景中更有优势。

• 需要在遗留代码库里做局部修改
• 需要同时改动多个文件并追踪原因
• 需要同时完成写测试、重构、更新文档
• 需要反复调用工具并随之调整计划

反过来，规则简单的小任务或大批量分类，不必上最高级的模型。这时优先考虑 gpt-5-mini 或 gpt-5-nano 会更划算。

自定义工具和格式约束如何搭配使用

自定义工具的核心价值，不在于「模型能调用工具」，而在于可以按任务调整工具输入的形式。

例如下面这些任务，用 plaintext 更自然。

• 执行 SQL 查询
• 校验公司内部 DSL
• 生成配置文件草稿
• 传递 shell 风格命令

而当格式很重要时，就加上输出约束。

• 正则表达式适合固定简单的模式。
• CFG 适合更复杂的语言语法或内部格式。

实务中可以这样组合：

1. 工具输入用 plaintext 简化。
2. 工具输出或模型响应用 regex 或 CFG 限制。
3. 失败时留下人类可读的错误信息。

这种方式能让智能体给出的不是「大致对的答案」，而是真正可以执行的答案。

Responses API 和 Chat Completions API 该什么时候用

GPT-5 在两个 API 上都能用，但实务中的角色略有不同。

Responses API

新功能和智能体型工作流更适合用 Responses API。原因是它在工具使用、流式输出、结构化流程、长周期智能体设计上更契合。

Chat Completions API

如果与现有代码库的兼容性很重要，或者服务已经围绕 Chat Completions 搭建起来了，可以逐步保留下去。不过如果是新项目，长期来看 Responses API 更容易运营。

简单来说：

• 新的智能体产品优先用 Responses API
• 既有的遗留服务保留 Chat Completions，或分阶段迁移

该如何降低成本和延迟

GPT-5 很强大，但用不好成本也会轻易膨胀。实务中最有效的两个方法是提示词缓存和 Batch API。

提示词缓存

如果系统提示词、工具说明、公共示例这类重复出现的前缀很长，提示词缓存会带来很大帮助。尤其是智能体应用会在多次请求中反复使用相同的策略和工具说明，缓存命中率通常表现很好。

好的模式大致是这样。

• 把固定指令放在前面。
• 把用户个别输入放在后面。
• 不要频繁改变工具列表和示例的顺序。

Batch API

不需要即时响应的大批量任务，很适合用 Batch API。例如下面这些任务就很适合批处理。

• 大批量分类
• 日志摘要
• 数据抽取
• 离线评估

Batch API 处理的是异步请求组，因此在延迟不那么重要的任务上，无论成本还是吞吐量都更有利。

实战标准

• 需要即时响应时，用在线请求。
• 相同前缀反复出现时，用提示词缓存。
• 不需要立即展示结果时，用 Batch API。

生产环境上线检查清单

把 GPT-5 投入生产环境时，运营设计比模型性能更重要。

1. 把核心任务和辅助任务分开。
2. 不要把 gpt-5、gpt-5-mini、gpt-5-nano 混用于同一用途。
3. 以团队为单位确定 verbosity 和 reasoning_effort 的默认值。
4. 统一自定义工具的输入格式。
5. 提前找出需要 regex 或 CFG 的位置。
6. 固定住能让提示词缓存生效的前缀。
7. 把可以交给 Batch API 的任务拆分出来。
8. 同时关注失败日志、延迟和 token 成本。
9. 对智能体产出的结果做自动校验，或转交人工审核。
10. 保持接口可以轻松更换模型。

这份清单的目的不是一次性做出完美的智能体，而是先搭好一条小而稳定的路径，再逐步扩展。

FAQ

GPT-5 最适合哪些任务

最适合复杂代码修改、跨工具的智能体任务、代码库理解、多步骤调试。

gpt-5-mini 和 gpt-5-nano 该怎么选

gpt-5-mini 适合通用产品功能和均衡型工作负载，gpt-5-nano 适合分类、抽取这类超低成本任务。

reasoning_effort 什么时候该调高

在追踪 bug 原因、工具选择困难的任务、需要经过多个步骤的智能体循环中，调高会更好。

为什么 verbosity 很重要

即使答案相同，长度和说明详尽程度不同，UI 体验和运营效率也会有很大差异。只需要简短 JSON 或操作结果时，调低会更合适。

新项目该从 Responses API 还是 Chat Completions API 开始

新项目更适合从 Responses API 开始。如果与现有服务的兼容性要求很高，可以先保留 Chat Completions，再分阶段迁移。

References

• Introducing GPT-5 for developers
• Using GPT-5
• Chat Completions API reference
• Responses API reference
• Prompt Caching guide
• Batch API guide
• OpenAI Codex CLI getting started