最近在使用 GPT、DeepSeek、Qwen、Codex、DSH 等 AI 模型和 Agent 工具时，经常会看到这样的参数：
32K
128K
256K
1M
1.05M
例如：
上下文窗口：256K
最大输出 Token：32K
或者：
Context Window：1M
刚开始看到这些参数很容易懵：
K 是什么意思？
M 又是什么意思？
Token 是什么？
256K 到底有多大？
上下文窗口又是干什么的？
其实这些概念并不复杂。
先看最简单的单位换算。
K 可以简单理解成：
1K = 1,000
所以：
8K = 8,000
32K = 32,000
128K = 128,000
256K = 256,000
换成我们平常习惯的“万”：
32K = 3.2 万
128K = 12.8 万
256K = 25.6 万
M 可以理解成：
1M = 1,000,000
也就是：
1M
=
1,000K
=
1,000,000
=
100 万
所以：
1.05M
=
1,050,000
=
105 万
以后看到：
Context Window：1M
就可以马上理解成：
上下文窗口大约是 100 万 Token。
Token 可以简单理解成：
大模型处理内容时使用的计量单位。
模型读取：
中文
英文
代码
数字
标点符号
最终都会被转换成 Token 进行处理。
但是有一点非常重要：
Token ≠ 字数
例如：
256K Token
不能直接理解成：
25.6 万个汉字
因为中文、英文、代码的 Token 切分方式并不完全一样。
所以我们平时更适合直接把 Token 当成：
AI 处理内容时使用的一种“容量单位”。
假设一个模型写着：
Context Window：256K
也就是：
256K
=
256,000 Token
=
25.6 万 Token
可以把上下文窗口想象成：
模型面前的一张办公桌。
这张桌子一次能放多少资料，就是这个模型的上下文容量。
例如这张桌子上可能会放：
系统提示词
+
用户 Prompt
+
历史聊天记录
+
项目规则
+
代码
+
文档
+
图片相关信息
+
Tool 返回结果
+
错误日志
+
模型输出
这些内容都需要占用模型的上下文空间。
所以：
Context Window
=
模型一次能够同时处理的内容容量
简单理解就是：
模型一次脑子里最多能放多少东西。
例如使用 Codex 开发一个 Spring Boot 项目。
我只输入一句话：
帮我开发一个用户反馈模块。
看起来我只发了十几个字。
但模型真正处理的内容可能还有：
Codex 自己的 Instructions
+
AGENTS.md
+
当前环境信息
+
Tools 定义
+
历史对话
+
读取到的 Java 代码
+
读取到的前端代码
+
数据库 SQL
+
mvn test 返回的日志
+
我的 Prompt
这些东西都会占用 Context。
所以：
我们在聊天框里输入的 Prompt，只是模型上下文中的一部分。
一般不会。
比如一个 Spring Boot 项目有：
1000 个文件
30 万行代码
Codex 通常不会第一次就把：
30 万行代码
全部发送给模型。
通常会经历：
用户提出需求
↓
模型判断需要看什么
↓
Codex 搜索相关文件
↓
读取相关 Controller
↓
读取相关 Service
↓
读取相关 Mapper
↓
读取相关前端页面
↓
这些真正读取到的代码
逐步进入 Context
所以：
项目总代码量
≠
模型当前真正看到的代码量
真正占用上下文的主要是：
当前任务过程中，Agent 实际读取并提供给模型的代码和资料。
这也是为什么现在 Agent 都很重视：
Context Management
也就是：
上下文管理。
好的 Agent 并不是把所有东西一股脑塞给模型，而是在正确的时候，把正确的信息提供给模型。
不是。
有时候会看到：
上下文窗口：256K
最大输出 Token：32K
这两个参数分别解决不同的问题。
例如：
256K
=
256,000 Token
表示：
模型一次处理任务时能够使用的整体上下文容量。
可以理解成：
模型的“办公桌有多大”。
例如：
32K
=
32,000 Token
表示：
模型单次回答最多允许生成多少 Token。
可以理解成：
模型一次最多允许“说多少话”。
所以：
上下文窗口
=
模型脑子一次能装多少
最大输出 Token
=
模型一次最多能输出多少
通常可以把上下文窗口理解成：
一次模型请求中可使用的总 Token 空间。
也就是说，输入内容和输出内容需要共同受上下文限制。
可以简单理解成：
输入 Token
+
输出 Token
≤
上下文窗口
例如：
上下文窗口：256K
最大输出：32K
为了方便理解，可以想成：
输入约 224K
+
输出约 32K
=
256K
不过这只是帮助理解的简单例子。
实际模型通常还会单独规定：
最大输入 Token
最大输出 Token
Context Window
推理 Token
不同厂商的具体计算方式可能有所不同。
所以真正使用 API 时：
应该以对应模型官方给出的“最大输入、最大输出、上下文窗口”参数为准。
不要简单认为：
上下文窗口 256K
+
最大输出 32K
=
总共可以使用 288K
通常不能这么直接相加。
下面这张表比较实用：
| 写法 | Token 数 | 换算成“万” |
|---|---|---|
| 8K | 8,000 | 0.8 万 |
| 32K | 32,000 | 3.2 万 |
| 64K | 64,000 | 6.4 万 |
| 128K | 128,000 | 12.8 万 |
| 200K | 200,000 | 20 万 |
| 256K | 256,000 | 25.6 万 |
| 400K | 400,000 | 40 万 |
| 512K | 512,000 | 51.2 万 |
| 1M | 1,000,000 | 100 万 |
| 1.05M | 1,050,000 | 105 万 |
所以以后看到：
256K
就可以直接想到：
25.6 万 Token
看到：
1M
就可以想到：
100 万 Token
不同模型的上下文窗口差别比较大。
下面列几个常见模型作为参考。
以下参数是截至 2026 年 9 月公开模型参数的简单整理，模型升级以后可能发生变化，实际使用时应以模型厂商最新官方文档为准。
| 模型 | 上下文窗口 | 换算 |
|---|---|---|
| GPT-5.6 | 1.05M | 1,050,000 Token |
| DeepSeek-V4-Pro | 1M | 1,000,000 Token |
| DeepSeek-V4-Flash | 1M | 1,000,000 Token |
| Qwen3.8-Max | 1M | 1,000,000 Token |
| Qwen3.7-Max | 1M | 1,000,000 Token |
| GLM-5.2 | 1M | 1,000,000 Token |
现在很多新一代大模型已经开始进入：
1M Context
也就是：
百万 Token 上下文。
GPT-5.6 的上下文窗口是：
1.05M
换算：
1.05M
=
1,050K
=
1,050,000 Token
=
105 万 Token
也就是说：
GPT-5.6 一次请求的上下文容量大约是 105 万 Token。
它的最大输出 Token 是：
128K
=
128,000 Token
=
12.8 万 Token
所以会看到类似：
Context Window：
1,050,000
Max Output Tokens：
128,000
注意：
Context Window 和 Max Output Tokens 不能简单相加。
Qwen3.8-Max 的上下文窗口是：
1M
=
1,000,000 Token
=
100 万 Token
官方同时还会给出：
最大输入长度
最大输出长度
上下文长度
例如它的上下文：
1,000,000 Token
但最大输入和最大输出还会有各自单独的限制。
这也说明：
看模型参数的时候，不能只看一个 Context Window。
最好同时看：
Context Window
Max Input Tokens
Max Output Tokens
DeepSeek-V4-Pro 和 DeepSeek-V4-Flash 当前官方服务的上下文长度也是：
1M
=
1,000,000 Token
=
100 万 Token
所以现在主流大模型的上下文正在从以前常见的：
32K
128K
256K
逐渐发展到：
1M
甚至未来可能继续提高。
不是。
这是一个非常容易产生的误区。
例如：
模型 A：256K Context
模型 B：1M Context
并不能直接得出：
模型 B 比模型 A 聪明 4 倍。
上下文窗口主要代表：
模型一次可以处理多少内容。
但是模型能力还和很多因素有关，例如：
推理能力
代码能力
知识能力
模型架构
训练数据
多模态能力
Tool Calling
Agent 能力
指令遵循能力
所以：
Context 大
≠
模型一定更聪明
更准确的说法是：
Context 越大，模型一次能够容纳的资料越多。
也不能简单这么理解。
上下文越大，确实意味着：
可以读取更多代码
可以读取更多文档
可以保留更多聊天历史
可以完成更大的 Agent 任务
但是如果什么东西都往里面塞：
大量无关代码
+
大量历史日志
+
大量无关文档
+
大量重复 Prompt
也可能出现问题。
例如：
Token 消耗增加
推理成本增加
无关信息增加
真正重要的信息反而被淹没
所以好的 Agent 并不是：
Context 越大，就把所有资料全部塞进去。
而是：
根据当前任务，尽量只给模型真正需要的信息。
这就是现在经常提到的：
Context Engineering
或者：
Context Management
因为普通聊天可能只是：
用户问问题
↓
模型回答
但是 Codex、DSH 这样的 Agent 可能是：
用户提出任务
↓
模型分析
↓
搜索代码
↓
读取 Java 文件
↓
再次分析
↓
读取 Vue 文件
↓
修改代码
↓
执行 mvn test
↓
返回错误日志
↓
模型分析错误
↓
继续修改
↓
再次测试
整个过程中：
代码
+
聊天历史
+
Tool 调用
+
Tool 返回结果
+
错误日志
+
项目 Instructions
都会不断进入 Context。
所以 Agent 做复杂任务时：
上下文管理非常重要。
这里还有一个容易混淆的概念。
假设看到：
Context Window：
256K
但是一次 Codex 长任务统计出来：
Token Usage：
800K
这并不矛盾。
因为：
表示：
模型某一时刻一次能够同时处理多少内容。
例如：
256K
相当于：
办公桌一次最多放 256K Token 的资料。
表示：
整个任务或者会话累计处理过多少 Token。
Codex 一次任务可能调用模型很多次：
模型调用 1：50K
模型调用 2：80K
模型调用 3：100K
模型调用 4：120K
……
累计以后完全可能达到：
800K
1M
甚至更多
可以这样理解：
Context Window
=
办公桌一次能放多少页资料
Token Usage
=
今天累计翻过多少页资料
办公桌一次可能只能放：
500 页
但是你一天完全可以累计翻：
5000 页
这两个并不冲突。
最后把几个最常见的概念放到一起。
1K
=
1,000
1M
=
1,000,000
=
100 万
Token
=
大模型处理内容时使用的计量单位
Context Window
=
模型一次能够处理的上下文总容量
可以简单理解成：
模型的“办公桌”有多大。
Max Output Tokens
=
模型一次最多允许生成多少 Token
可以简单理解成：
模型一次最多能“说多少”。
Token Usage
=
整个任务或者会话累计处理了多少 Token
它和 Context Window 不是一回事。
以后再看到：
32K
128K
256K
1M
1.05M
可以直接理解成：
32K
=
3.2 万 Token
128K
=
12.8 万 Token
256K
=
25.6 万 Token
1M
=
100 万 Token
1.05M
=
105 万 Token
而所谓：
Context Window
最简单的理解就是：
模型一次能够同时“看到、记住并处理”的内容容量。
对于 Codex、DSH 这样的 AI Agent 来说，上下文里不仅仅有你输入的 Prompt，还可能包括：
系统 Instructions
+
AGENTS.md
+
聊天历史
+
代码
+
文档
+
Tool 定义
+
Tool 返回结果
+
错误日志
+
模型输出
所以：
上下文越大，AI 一次可以处理的代码和资料通常越多；但真正优秀的 Agent 并不是把所有内容全部塞进去，而是在正确的时候，把真正需要的信息提供给模型。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。