奇 奇连 AI
学习路线图课程工具计算器企业服务关于加入会员

上下文窗口要你手填的那几家：这个数字从哪儿取、填错会怎样

2026-08-07

**你在客户端填的那个上下文窗口数字，不会让服务端多给你一个 token，也不会让它少给你一个。它是你告诉本地工具”这个模型大概能吃多少”的一份声明，真正的硬上限在服务端。**把这两件事分开，后面所有的困惑就都好解释了：为什么填错了不一定当场报错，为什么它有时表现得像”没生效”，为什么这个值不能拍脑袋。

本站讲上下文的文章不止一篇，跟本篇最容易混的是下面这三篇，分工是这样的：上下文窗口是什么 讲概念——窗口装的是什么、为什么会满；上下文长度怎么选 讲选型——面对不同窗口规格的模型该怎么挑；大仓库上下文不足怎么办 讲工程对策——代码库塞不下时怎么切。这一篇只管一件很窄的事：当你在编辑器/终端 Agent 里接自定义模型、工具要求你手动填一个窗口数值时，这个数字该怎么办。

一、先把两个”上下文窗口”分开

先统一口径，免得后面串。

上下文窗口，指一次请求里模型能同时处理的 token 总量（你的系统提示、历史对话、贴进去的代码、加上模型这一轮要生成的内容，都在这个盘子里）。这个上限由模型和服务端决定，写在服务商的模型文档里，你在本地改不了。

OpenAI 兼容端点，指服务商提供了一套和 OpenAI 请求/响应格式一致的 HTTP 接口，于是各家客户端只要填个 Base URL 和密钥就能接上，不用为每家单独写适配。绝大多数”接自定义模型”走的都是这条路，本站另有一篇 OpenAI 兼容端点是什么 讲协议这一层。

问题就出在中间这道缝：兼容端点这套协议里，没有一个标准字段能让客户端问出”你这个模型的窗口到底多大”。服务端只有在你请求超限时才会用报错告诉你。于是客户端要么内置一张模型规格表，要么——对它不认识的模型——把这一栏交给你填。

所以你填的那个值，性质是本地侧的元数据。它不参与鉴权，不改变服务端行为。

二、这几家分别要你填什么（逐字对照）

下面这张表里的字段名，全部按截至 2026-08-07 各家官方文档页面上的写法逐字抄录，出处 URL 见文末。

产品这一项逐字叫什么它出现在哪里出处
ClineContext Window size（同区还有 Max Output Tokens）官方文档所述的 Model Configuration 区，属于可自定义的高级项Cline 官方文档 OpenAI Compatible 页
Roo CodeContext Window（另可自定义 Max Output Tokens）与 Base URL、API Key、Model 三个主参数并列的可自定义项Roo Code 官方文档 OpenAI Compatible 页
Zedmax_tokenssettings.json 里 available_models 数组的每一项，与 name、display_name 同级Zed 官方文档
aidermax_input_tokens / max_output_tokens（同文件还有 max_tokens）.aider.model.metadata.json，用于给 aider 不认识的模型注册上下文上限与价格aider 官方文档该页（URL 见文末）

几点必须说清楚，否则容易被这张表误导：

第一，字段名不等于字段用途。Cline 与 Roo Code 的文档在本篇依据的那两页上，是把这些项作为”可自定义的高级项”列出来的，并没有逐条说明客户端内部拿这个数去做什么。所以本文不会写”某某产品拿这个数决定何时压缩历史”之类的句子——那属于替产品定行为。你要判断具体行为，请以官方文档最新版和你实际观察到的结果为准。

第二，只有 Zed 和 aider 这两处，文档本身给了含义。Zed 文档说明 available_models 每项的 max_tokens 是上下文窗口上限；aider 文档说明 .aider.model.metadata.json 是给它不认识的模型注册上下文上限与价格用的。这两条可以放心当依据。

第三，“本篇依据的这几页记录里没出现某一项”不等于该产品没有这一项。各家文档还有别的页面，产品也会更新。表里只覆盖了本文核对过的那几页。

第四，Zed 那份 settings.json 里，available_models 是手写的模型数组，也就是说模型标识和窗口值都由你自己维护；Continue 同样在 models 块里手写；而 Kilo Code 的做法是凭据有效时从 /v1/models 端点自动拉取模型列表，自动检测失败再手填。能不能自动发现模型，和窗口值要不要你填，是两个独立的事，别混为一谈。

三、这个数字应该从哪里取

按可靠性从高到低，只有三个来源值得用：

第一来源：你实际调用的那家服务商的模型文档。 注意是”你实际调用的那家”，不是这个模型的原始发布方。同一个开源权重放在不同推理平台上，各家开出来的窗口上限可以不一样——窗口上限是部署方在自家环境里定下的，不是模型权重自带的固定属性。你走谁的端点，就查谁的文档。

第二来源：服务端自己吐出来的结构化信息。 兼容端点通常有 /v1/models（Kilo Code 就是从这个端点拉模型列表的）。不同服务商在这个响应里放的字段并不统一，有的会带窗口信息，有的只给一个模型 ID 列表。能拿到就用，拿不到就回到第一来源。

第三来源：受控的试探。 逐步加大输入，看服务端从哪个量级开始拒绝。这个办法能得到一个下界，但成本不低，而且服务端的报错阈值未必等于文档标称值。只在前两条都断了的时候用。

不该用的来源：模型名字里的数字（128k、1m 这类后缀是命名习惯，不是承诺）、社区帖子里的口口相传、以及某家客户端内置规格表里对同名模型的取值——那是它对另一个端点的判断，不见得适用于你这个端点。

取到数之后还有一步：把这个数换算成你能感知的量，否则 128000 这种数字对多数人是没有体感的。本站的上下文长度计算器做的就是这件事——填入一个 token 数（比如你刚写进配置的那个窗口值）和一个单价，它给出这个量大致相当于多少中文字符、多少英文单词，以及按该单价算一次调用的成本。用法是拿它做对照：估一估你日常一次会话要塞进去多少字的代码和文档，跟窗口值的字符当量比一比，就知道余量是宽还是紧、该不该拆任务。它算不出的东西也要讲明白：它不知道你那家服务商的真实上限是多少（那只能查文档），也不知道各家客户端内部怎么组装最终请求，而且字符与 token 的换算本身是近似的（精确切分以各服务商的 tokenizer 为准），所以它给的是量级参考，不是精确账单。

四、填大了、填小了，分别会怎么样

先声明性质：下面这一段是 OpenAI 兼容协议层面的机制推理，不是上述任何一家产品文档里写着的行为。 各家客户端拿这个值做什么，文档没有逐条说明，实际表现请以官方文档和你自己的观察为准。

填得比服务端真实上限大。 本地这一侧会以为还有余量，于是继续往请求里塞。真正的把关发生在服务端：请求超过它的硬上限时，HTTP 层面会返回一个错误。这类失败的特征是”平时都好好的，只有长会话/大文件时才炸”，而且往往在你以为最需要它的那一刻炸。更麻烦的变体是：有些客户端会在窗口快满时做压缩或裁剪，你把值填大，等于把这个保护动作往后推了——它可能根本来不及触发。

填得比服务端真实上限小。 服务端不会有任何抱怨，因为你的请求本来就合法。代价是你花了大窗口的钱、只用上了小窗口：本地这一侧会更早地认为”装不下了”，该带的历史和文件被提前挤掉，模型看不到关键上下文，输出质量下滑。这种翻车最难查，因为它不报错——你只会觉得”这个模型好像变笨了”。

关于最大输出这一项。 Cline 与 Roo Code 的可自定义项里都列了 Max Output Tokens，aider 的 metadata 示例里有 max_output_tokens。同样按协议层机制说：最大输出限制的是模型这一轮能生成多少 token，设得过小，长回答会在生成到一半时被截断（表现是代码块没写完、diff 缺尾巴）；它和上下文窗口共享同一个总盘子，所以两个数不是各管各的。

一个反直觉的点：填错窗口值不一定当场被拦下。配置能不能保存、什么时候校验、拦不拦得住，取决于各家实现，本文不做描述——以你实际看到的界面为准。你能确定的只有一件事：服务端的上限永远说了算。

五、边界与代价：手填这套设计放弃了什么

手填窗口值，本质是把”模型规格”这件事的责任从客户端转移给了你。这个转移有明确的代价：

它放弃了自动正确。 客户端不再保证这个值对，你也就失去了”装上就能用”的兜底。服务商换了部署、模型升了版本、窗口规格调整了，你这边的配置文件不会跟着动——它会一直用那个过时的数，直到某天以一次莫名其妙的失败提醒你。

它不管跨端点漂移。 你在 Zed 的 settings.json 里为某个 provider 写死的 max_tokens，只对那个 provider 条目有效。你换一家服务商跑同名模型，这个值需要重新核。配置文件不会替你发现”换端点了”。

它不管质量，只管容量。 窗口值再准，也不解决”塞进去的内容对不对”这个问题。上下文里有半份过期文档、有三个不相干的文件，模型照样会被带偏。窗口是容器尺寸，装什么是另一门功夫。

它不适用于这些场景：如果你用的是客户端已经内置规格的官方模型，通常不需要碰这一项；如果你的瓶颈是仓库整体规模而不是单次请求，调这个数没用，该做的是检索与切分（见大仓库上下文不足怎么办）。

它明确不管的事：不管鉴权，不管计费口径，不管模型有没有你需要的能力。特别是工具调用——Roo Code 官方文档有一句很硬的说明，原文是 “Roo Code uses native tool calling exclusively. This is the only supported tool protocol — there is no XML-based fallback.”（这是该产品官方文档的说法，不是本文的判断）。意思是它只走原生工具调用，没有基于 XML 的回退方案。**原生工具调用（function calling）**指的是模型按接口规定的结构化格式直接返回”要调用哪个工具、参数是什么”，而不是靠在自然语言里夹标记再由客户端解析。该文档建议先查服务商文档确认所选模型是否支持工具调用。窗口值填得再准，模型不支持这一条，事情也走不下去。

六、避坑清单

坑一：拿模型原厂的窗口规格去填第三方端点。 为什么会踩：同一个模型名在多家平台上架，你查到的第一份文档往往是原厂的。 怎么避：认端点不认模型名。你的 Base URL 指向谁，就查谁的模型文档。

坑二：把值填成”越大越保险”。 为什么会踩：直觉上大一点留余量更安全。实际上填大是把本地的保护动作推后，风险朝服务端报错的方向走。 怎么避：宁可按文档标称值填，也不要往上加”保险量”。不确定就取文档值，别自己加余量。

坑三：把一家的字段名套到另一家。 为什么会踩：这几家的概念长得像，脑子里就自动画等号了。实际上 Cline / Roo Code 的界面里叫 Base URL，Continue 叫 apiBase，Zed 叫 api_url，goose 用 OPENAI_HOST（另有 OPENAI_BASE_PATH），Crush 是命令行参数 --base-url——名字不同，形态也不同。 怎么避：配哪家就只看哪家的文档，不要凭另一家的记忆推。

坑四：只填了窗口，没管最大输出。 为什么会踩：两栏挨着，容易只改一个。 怎么避：当你观察到”回答总是在差不多的长度上断掉”，先回头看最大输出这一项，而不是怀疑模型能力。

坑五：把密钥和窗口值一起提交进版本库。 为什么会踩：窗口值该进版本库（团队共享才有意义），密钥不该，但它们经常写在同一个文件里。 怎么避：按各家文档给的分离办法来。Zed 文档明确写着 “Do not put API keys in settings.json.”，并说明通过 Zed 保存的 provider 密钥存在系统 keychain（keychain 即操作系统提供的凭据保管服务，由系统而非应用来加密保存），另一条路是环境变量，命名规则是 <PROVIDER_NAME>_API_KEY——provider 名为 my-provider 时对应 MY_PROVIDER_API_KEY。Gemini CLI 则支持在 settings.json 里用 $VAR_NAME 或 ${VAR_NAME} 做环境变量插值（配置文件里只写变量名，加载时才从环境里取实际值），这样配置能进版本库而密钥不进。

坑六：改完配置忘了记来源。 为什么会踩：填的时候查过文档，三个月后没人记得这个 128000 是哪来的。 怎么避：在 PR 描述或团队文档里写一句”该值取自某某服务商某年某月的模型文档”，下次核对有据可查。aider 这类走文件的做法天然好一些——.aider.model.metadata.json 本身就是一份可以进版本库、可以被 review 的记录。顺带一提，aider 的 .aider.model.settings.yml 可以放在四个位置（home 目录、git 仓库根目录、启动 aider 的当前目录，以及 --model-settings-file <filename> 指定的路径），按顺序加载、后加载的优先——排查”配置没生效”时，先确认你改的是不是优先级最高的那一份。

如果你还没走到填窗口这一步，本站另有一篇 编辑器接入自定义 API 讲更前面的接入流程。

数据来源与核对日期

本篇涉及的产品事实全部来自下列官方文档页面，核对日期均为 2026-08-07。文档会更新，请以官方最新版为准。

本篇没有写什么，以及为什么：

  • 不写任何产品的价格、免费额度、订阅档位、限速数字。这类信息变动频繁，本次也未做核实；请直接看各服务商官网的定价页与用量页。aider 官方文档 metadata 示例里出现的 input_cost_per_token / output_cost_per_token 数值是文档的示例值，不是任何真实模型的报价，本文不据此推算成本。
  • 不写完整模型清单，也不写任何模型的具体窗口数字。原因正是第三节讲的：同一模型在不同端点上的窗口上限可能不同，任何写死在文章里的数字都会误导人。这个数请你从自己实际调用的服务商文档里取。
  • 不描述任何一家的界面长什么样——面板位置、菜单层级、提示文案、什么时候做校验，本篇依据的是配置层文档，不含界面细节，请以你实际看到的界面为准。
  • 不对各家文档或产品排座次。上面的差异只是设计取向不同，不构成优劣判断。
  • 第四节关于”填大填小会怎样”的推演，属于 OpenAI 兼容协议的通用机制分析，不是上述任何一家产品文档记载的行为，已在该节开头标明。

延伸阅读：同一组里的 接自定义模型前先确认工具调用、自定义 provider 的 ID、显示名、模型名撞在一起；接完之后照 接完自定义模型别急着干活 逐项过一遍，才算真接通。

想系统学会用 AI？报名体系课或加入会员，照着学、照着用。

浏览课程 加入会员