![文章封面](https://developer.qcloudimg.com/http-save/yehe-11715263/c55bbcf43b8d369336299166cb420b60.png)

**简介：temperature、top\_p、max\_tokens 各自控制什么、不解决什么；Context Window 是容量而不是无限记忆，上下文预算由 Harness 管理**

## 参数不是「质量旋钮」

**简介：回答不满意先查目标和上下文，参数永远排在最后**

-   常见误区
    -   **回答不满意，就把 temperature 调高**
-   三个参数真正控制什么

| 参数 | 真正控制的对象 | 不解决的问题 |
| --- | --- | --- |
| `temperature` | 采样随机性，同输入可出现不同输出 | 事实正确性 · 上下文缺失 · 工具失败 |
| `top_p` | 候选 token 的概率质量范围 | 任务理解 · 输出契约 |
| `max_tokens` | 单次输出预算上限，决定何时停止生成 | 上下文容量 · 思考质量 · 整体任务理解 |

-   质量问题的排查顺序
    -   **先查目标 · 上下文 · 模型能力 · 工具证据 · 输出约束，参数永远排在这五项之后**
    -   调高温度救不了输出时，问题几乎一定出在 prompt / 上下文 / schema / 工具证据，而不在参数上

## temperature：控制随机性，不是控制聪明程度

**简介：需要被程序消费、需要回归评测的输出，用低随机性加明确契约**

```python
client.chat.completions.create(
    model="deepseek-v4-flash",
    messages=messages,
    temperature=0.2,
)
```

| 区间 | 效果 | 适合 | 代价 |
| --- | --- | --- | --- |
| **低 0.0~0.3** | 更稳定、更易复现，降低回归波动，输出更收敛 | 分类 · 抽取 · 代码修改计划 · 任何被程序消费的输出 | — |
| **高 0.7~1.0** | 更多表达与路径探索 | 头脑风暴 · 文案备选 · 多种实现思路并行探索 | 回归测试波动，不能直接被消费 |

-   默认选择 `T = 0.2`：稳定、可复现、回归可比
-   **需要被程序消费、需要回归评测的输出 → 低随机性 + 明确契约**
-   注意点
    -   同一参数不一定被所有模型、所有模式支持或生效
        -   调用前查模型能力，不要把某个厂商的经验复制到所有模型
    -   **一些推理类 API 在 thinking 模式下不允许修改 temperature**
        -   T=0.2 没用时，先确认模型文档，再考虑调整其他维度

## top\_p：与 temperature 二选一作为主旋钮

**简介：一次实验只改变一个变量，参数像代码一样版本化**

```python
# 默认策略：只控制一个采样维度
generation = {"temperature": 0.2, "max_tokens": 800}

# 只有在模型文档与实验均证明必要时改为：
# generation = {"top_p": 0.9, "max_tokens": 800}

# 不要同时大力度调节 —— 难以解释、难以回归
```

-   同时大幅调节 temperature 与 top\_p 的问题
    -   ① 解释困难
    -   ② 难做基线对照
    -   ③ 输出分布不可复现
    -   ④ 评审时无法定位是哪个变量在起作用
-   只用一只旋钮
    -   默认用 `temperature`：可解释、好观测
    -   需要候选多样性时再切 `top_p`
-   **一次实验只改变一个变量，参数版本与测试集绑定**
    -   像 git commit 一样管理参数：`gen-config-v3.json` + `regression-set-2026-08.json`
    -   把参数当代码资产管理，这件事远比「调高温度」更影响输出质量

## max\_tokens：输出预算，更是停止条件

**简介：控制生成成本、延迟与被截断的概率，不是「希望模型多写点」**

```python
result = client.chat.completions.create(
    model="deepseek-v4-flash",
    messages=messages,
    max_tokens=400,
)

if result.choices[0].finish_reason == "length":
    raise OutputTruncated("输出被预算截断，不能当作完整结果使用")
```

| 维度 | 说明 |
| --- | --- |
| **控制** | 本次输出最长多少 token，决定模型何时停止 |
| **影响** | 成本、延迟与截断概率；过小 → 任务无法完成，过大 → 消耗预算 |
| **不等于** | Context Window 容量：输入 token 与输出 token 共同占用上下文，输入越长可用输出空间越少 |

-   截断处理
    -   **finish\_reason == "length" 视为失败，而不是「尽量解析」**
    -   被截断的 JSON 看起来像 JSON，但语义已经残缺
    -   把截断当作错误信号：扩大预算或拆分任务后再次生成
    -   残缺的结构化输出带来的代价，远大于再请求一次
-   输入越短，可分配给输出的预算越大 → 上下文预算需要为输出预留 token

## Token 与 Context Window：容量不是无限记忆

**简介：一次调用的所有内容加起来不能超过窗口，Harness 负责喂「足够且必要」的上下文**

-   一次调用的预算

```text
system + 用户输入 + 历史消息 + 工具结果 + 预留输出 ≤ context window
```

-   三个陷阱

| 陷阱 | 表现 |
| --- | --- |
| **输入越长，可用输出越少** | 预设的 max\_tokens 不会随输入增加而自动增大，模型最后一次思考需要的输出空间不足 |
| **工具结果挤掉任务信息** | 搜索全文、grep 输出、长日志塞进上下文，任务指令与历史决策反而被挤出窗外 |
| **超窗处理 → 粗暴截断** | 直接报错，或应用层把中间消息砍掉，模型实际看到的是「残缺的世界」，任务失真 |

-   Harness 的责任
    -   **给模型喂「足够且必要」的上下文**
    -   裁剪冗余 · 保留关键 · 预留输出 · 监控用量
    -   模型没有「无限记忆」，Harness 才是上下文的真正管理者

## 上下文预算的最小实现

**简介：倒序保留最近的历史，直到预算用尽，再拼装成 system + 历史 + 本次任务**

```python
def build_messages(history, task, max_history_chars=12_000):
    recent = []
    used = 0
    for message in reversed(history):
        size = len(message["content"])
        if used + size > max_history_chars:
            break
        recent.append(message)
        used += size

    return [
        {"role": "system", "content": "你是谨慎的 Coding Agent。"},
        *reversed(recent),
        {"role": "user", "content": task},
    ]
```
![上下文预算算法](https://developer.qcloudimg.com/http-save/yehe-11715263/d82c543e31d8dd7384fd9dd32d12feee.png)

-   行为、原则与边界
    -   行为：倒序扫描历史，直到预算用尽
    -   原则：保留最近发生的事，丢掉久远的
    -   边界：system 与 user（本次任务）始终保留
-   教学版缺什么
    -   用字符而非 token 估算，不精确
    -   没有为 max\_tokens 预留输出空间
    -   工具结果大小未单独控制
    -   没有摘要降级策略
-   注意点
    -   **生产环境要基于目标模型的 tokenizer 计数、为输出预留 token，并采用摘要 + RAG 降级策略**
    -   教学版只是近似，不要直接复制到生产
    -   **最近的事最重要，久远的可以丢掉或摘要**：这就是上下文预算的全部思路

## 面试/考试记忆点

-   **参数不是质量旋钮：质量问题先查目标、上下文、模型能力、工具证据、输出约束，最后才轮到参数**
-   temperature 控制采样随机性而不是聪明程度，被程序消费的输出默认用 0.2 左右的低温度
-   temperature 与 top\_p 二选一作为主旋钮，一次实验只改一个变量，参数版本与测试集绑定
-   同一参数不一定被所有模型支持，部分推理类 API 在 thinking 模式下不允许改 temperature
-   max\_tokens 是输出预算和停止条件，不等于 Context Window 容量
-   `finish_reason == "length"` 表示输出被截断，应视为失败，扩大预算或拆分任务后重新生成
-   一次调用的预算：system + 用户输入 + 历史 + 工具结果 + 预留输出 ≤ context window
-   上下文预算的核心思路是保留最近的、丢弃或摘要久远的，生产环境要按 tokenizer 计数并预留输出

模型参数、Token 与 Context Window

人工智能

本文详解LLM参数temperature、top_p、max_tokens的真实作用与局限，指出参数非质量旋钮。质量问题应优先排查目标、上下文、模型能力等，并阐述上下文窗口容量管理与预算分配策略，强调保留最近信息、预留输出空间的核心原则。

回归测试

DeepSeek

Agent

JSON

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

模型参数、Token 与 Context Window-腾讯云开发者社区-腾讯云

模型参数、Token 与 Context Window

模型参数、Token 与 Context Window

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐