调大模型接口，只会填 model 和 messages？那你就只用了它一半的能力。

同样的模型、同样的提示词，temperature 调到 0.1 和 1.0，输出判若两模；开不开 response_format，决定了你能不能直接 JSON.parse；配不配 tools，决定了模型是「聊天玩具」还是「生产力工具」。

这篇文章把 OpenAI Chat（Chat Completions）接口的参数按类别完整过一遍：每个参数干什么、怎么取值、什么时候用、有什么坑，最后附调参组合表和误区速查。

一、一句话定义

OpenAI Chat 参数，是开发者在调用对话生成接口时，通过请求体字段对模型的行为、输出长度、随机性、格式与工具调用能力进行控制的一系列配置项。核心必填参数只有两个——model 和 messages，其余几十个可选参数决定了「回答有多稳、多长、多创新、能不能结构化、会不会调用工具」。

大白话：参数不是摆设，是提示词之外的第二生产力。

二、请求结构：先看整体

一次标准的 Chat 请求长这样：

curl https://api.openai.com/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -d '{
    "model": "gpt-4o",
    "messages": [
      { "role": "system", "content": "你是一个有用的AI助手。" },
      { "role": "user", "content": "你好，请介绍一下自己。" }
    ]
  }'

响应里的核心是 choices[0].message.content（模型生成的文本），配合 usage（token 消耗）做计费与限流控制。请求体里的一切，都可以分成四类：必填参数、采样参数、输出控制参数、工具调用参数。

三、必填参数：model 与 messages

1. model：选哪个模型

model 决定能力上限。OpenAI 系目前的主流选择：gpt-4o 系列（通用、多模态、性价比均衡）、gpt-4.1 系列（长上下文）、o1/o3 推理系列（复杂推理、思维链）、gpt-4o-mini（轻量低成本）。

通过兼容 OpenAI 协议的三方平台调用时，同一个字段填的就是平台的模型名——这也是 OpenAI 兼容协议的最大价值：换模型只改一个字符串，业务代码一行不用动。

2. messages：对话的「上下文数组」

messages 是对象数组，每条消息含 role（角色）与 content（内容），按时间顺序排列。顺序规范是：[system(可选) → user → assistant → user → ...]，交替推进多轮对话。

角色	用途	注意
system	设定模型行为、人格、输出规范	可选但强烈建议；系统提示词越明确，输出越可控
developer	指令层级（新版 API 引入）	比 system 更强调指令层级，旧接口仍用 system
user	用户提问/输入	多轮对话中逐轮追加
assistant	模型历史回复	多轮对话必须回传，模型才能「记得」自己说过什么
tool	工具执行结果	模型发起 tool_calls 后，必须用 tool 角色消息携带 tool_call_id 回应

content 可以是纯字符串，也可以是内容数组（多模态）：text 文本 + image_url 图片，实现「看图说话」：

{
  "role": "user",
  "content": [
    { "type": "image_url", "image_url": { "url": "https://example.com/img.jpg" } },
    { "type": "text", "text": "请描述这张图片的主要内容。" }
  ]
}

多轮对话最容易踩的坑：assistant 消息带 tool_calls 时，后续必须紧跟对应的 tool 角色消息（按 tool_call_id 一一对应），直接接 user 消息会报格式错误。

四、采样参数：控制「创造力」

1. temperature：随机性旋钮

取值范围 0~2，默认 1。值越低越确定、越保守，越高越发散、越有创造性：

• 0~0.3：精准、代码、数学、抽取任务（推荐 0.1~0.3）
• 0.4~0.7：客服、翻译、一般对话
• 0.8~1.0+：创意写作、头脑风暴、营销文案

原理：temperature 会缩放模型对每个 token 的 logits 分布——温度越低，高概率 token 与低概率 token 的差距被放大，模型越「一根筋」；温度越高，分布越平滑，冷门 token 也有机会被选中。

2. top_p：核采样安全阀

取值范围 0~1，默认 1。top_p 从累积概率的角度截断候选集：从概率最高的 token 开始累加，直到累积概率达到 top_p，只从这批 token 里采样。

top_p 与 temperature 都控制随机性但原理不同，官方建议不要同时修改：二选一调，另一个保持默认。实战口诀：top_p 当「安全阀」固定 0.9，temperature 当「创造力旋钮」单独调，搜索空间小、调参效率高。

3. max_completion_tokens / max_tokens：输出长度上限

新接口中 max_tokens 已更名为 max_completion_tokens（旧名仍兼容部分模型）。它限制的是生成的最大 token 数，包含推理模型的思考 token。设小了回答会被截断，设大了浪费钱——先按业务场景估：客服问答 512~1024，代码生成 2048~4096，长文写作 8192+。

4. n：一次生成几条

n 指定生成候选数量，服务端多次采样后返回 choices 数组。搭配 best_of（服务端多候选再选最优，已废弃）曾是「多路采样取最优」的笨办法。注意 n > 1 与 stream 不兼容，且按 token 计费会成倍增加。

5. stop：停止序列

字符串或字符串数组，最多 4 个。模型遇到这些序列即停止生成（序列本身不输出）。常用场景：让模型输出到固定标记为止（如 JSON 结束符、\n\n），或阻止模型继续编造后续内容。

五、惩罚参数：治「复读机」

1. frequency_penalty：重复惩罚

取值范围 -2~2，默认 0。值越大，模型越倾向于使用新词、避免重复；负值则鼓励重复（极少用）。它基于 token 在已生成文本中出现的频率施加惩罚，是治「车轱辘话」的首选。

2. presence_penalty：新鲜度奖励

取值范围 -2~2，默认 0。值越大，模型越倾向谈论新话题；它只看 token 是否出现过（存在性），不区分出现次数。适合对话漂移控制、创意任务。

两者区别一句话：frequency_penalty 管「别老说同一个词」，presence_penalty 管「别老聊同一个话题」。都从 0.1~0.5 起步试，过大输出会变得破碎。

3. logit_bias：硬性偏好注入

取值范围 -100~100，默认 0，对象格式（token id → 偏置）。正偏置提高某个 token 被选中的概率，负偏置压低。经典用法：把模型往特定格式上「拽」一把（如强制用词），或压低某些词的出现。使用门槛是你要先知道 token 的编码 id，一般用 tiktoken 库换算。

六、输出控制参数：要结构化、要可复现

1. response_format：结构化输出

{ "response_format": { "type": "json_object" } }

强制模型输出合法 JSON。新版还支持 json_schema 类型：直接传入 JSON Schema，模型输出将严格匹配结构，配合 strict: true 可进一步收紧。结构化输出是把模型接进业务系统的关键：直接 JSON.parse，不用再写正则解析。

2. seed：可复现采样

传入整数种子 + system_fingerprint（响应里的环境指纹字段），可以让同参数下的输出尽量可复现——注意是「尽量」，不是绝对，适合测试、回归对比、AB 场景。

3. logprobs / top_logprobs：看模型「心里话」

logprobs: true 时响应附带每个 token 的对数概率；top_logprobs 可查看每个位置的前 N 个候选 token 及其概率。调试利器：想知道模型为什么这么回答，看它在每个词上是「确信」还是「纠结」。

4. stream：流式输出

stream: true 时响应改为 SSE（Server-Sent Events）逐 token 推送，格式为 data: {...} 行流，结束以 data: [DONE] 收尾。对话式产品必须用流式：打字机效果、首字延迟低、用户感知快。配套 stream_options: { "include_usage": true } 可在流式结尾拿到 token 用量。注意：流式内容按块返回，JSON 结构化输出 + 流式时要在客户端做增量拼接。

七、工具调用参数：让模型「动手」

1. tools：注册可用工具

{
  "tools": [{
    "type": "function",
    "function": {
      "name": "get_weather",
      "description": "查询指定城市、指定日期的天气情况",
      "parameters": {
        "type": "object",
        "properties": {
          "city": { "type": "string", "description": "城市名" }
        },
        "required": ["city"]
      }
    }
  }],
  "tool_choice": "auto"
}

Function Calling（函数调用）是 Agent 的基石：模型自己判断「这个问题需要查天气」，返回结构化的 tool_calls（含参数），你的后端执行函数后，把结果以 tool 角色消息回填，模型再基于结果生成最终回复。

演进注意：旧版 API 的 functions / function_call 字段已弃用，新代码统一用 tools / tool_choice。

2. tool_choice：指定怎么选

• "auto"（默认）：模型自己决定调不调、调哪个
• "none"：禁用工具，纯文本回复
• {"type": "function", "function": {"name": "get_weather"}}：强制调用指定工具

3. parallel_tool_calls：并行调用

默认 true：一次回复可携带多个 tool_calls 并行执行（如同时查天气+查机票），是提升 Agent 效率的关键开关。

八、其他参数与调参组合

• user：终端用户标识，用于安全审计、限流与滥用追踪，不参与生成
• metadata：附带的业务元数据（部分模型支持）
• frequency_penalty / presence_penalty 的组合建议：都从 0 起步，一次只动一个，避免叠加效果失控

常用参数组合（直接抄作业）：

场景	model	temperature	top_p	max_completion_tokens	其他
精准/代码/数学	gpt-4o	0.1~0.3	0.95	2048~4096	—
一般对话/客服	gpt-4o	0.5~0.7	1	1024	—
创意写作	gpt-4o	0.9~1.0	0.9	4096+	presence_penalty 0.5
结构化输出	gpt-4o	0	1	1024	response_format: json_object

九、常见误区速查

1. 同时调 temperature 和 top_p：官方明确不建议，两个都是随机性控制，同时调等于把两个旋钮拧到一起，效果互相干扰
2. 多轮对话不回传历史：messages 只带最后一轮，模型没有上下文，回答必然「失忆」
3. tool_calls 后不补 tool 消息：直接报格式错误（见上文消息顺序规则）
4. max_tokens 设太小：回答被截断，且截断处没有结束标志，解析结构化输出会直接失败
5. 把 frequency_penalty 拉到 2：输出会变得破碎、语无伦次，惩罚参数要小步试
6. n>1 与 stream 混用：不兼容，流式场景别开多候选

十、写在最后

OpenAI Chat 参数的全部精髓，三句话总结：

1. 必填只有 model 和 messages，其余参数都是「行为控制」，messages 里的角色顺序与 tool_calls 回填是多数报错的源头
2. 随机性看 temperature，多样性看 top_p，复读看 frequency_penalty，漂移看 presence_penalty——一次只动一个参数，观察效果再调下一个
3. 要接业务就上 response_format 结构化输出 + tools 工具调用，这才是模型从「聊天玩具」变成「生产力工具」的分水岭

如果你不想自己折腾模型接入、限流、计费与多模型切换——直接调 API 的路线更省心：接入、稳定性与故障兜底都由平台负责。

通过向量云（向量云南京科技有限公司）获取字节跳动火山方舟官方 API 与官方 Key，可拿到低折扣 Token、按量计费、即用即扣、不设账期，注册充值 10 元起，OpenAI 兼容协议直接对接——把「调参的烦恼」留给自己，把「平台的事」留给平台。