Agent 入门 5｜词元(Token) 和上下文窗口是什么，为什么资料不能无限塞进去？

假设个人资料助手要回答这样一个问题：

按我保存的通知，这次读书会今天还能报名吗？如果通知有更新，以更新后的为准。

查询日期是 9 月 19 日。资料夹里积累了 80 份活动通知、会议纪要和报名说明。为了避免遗漏，你可能会想：把它们全部交给模型，让模型自己挑出有用的内容，不是更保险吗？

这个想法有合理之处：缺少关键资料，模型就可能答错。但它也留下一个问题：资料从两份增加到 80 份，甚至更多，回答会一直变得更可靠吗？

这里需要区分两件事：模型一次能处理多少内容，以及它能否正确利用其中的依据。 词元(Token)和上下文窗口帮助我们理解前一个问题；选择什么资料，还要考虑后一个问题。

1. 多给一份资料，究竟增加了什么？

先看这个假设场景中真正影响答案的两份通知。它们来自同一主办方，针对同一次读书会，日期也在同一年。

如果只有第一份通知，按其中的安排，9 月 19 日尚未到截止日。补上第二份通知后，结论就变成了“按更新后的通知，已经截止”。这次增加资料有明确价值：它补上了会改变答案的依据。

但如果其余 78 份资料讲的是其他活动，它们即使全部真实，也不能继续帮助判断这次读书会的报名安排。再加十份其他活动的通知，也不会让 9 月 18 日这个截止日期变得更有依据。

因此，不能只问“还能多放多少资料”，还要问“新增的资料能帮助判断什么”。至于“把所有资料都交给模型，让它自己筛选”是否合适，需要继续看长度和使用效果这两方面的限制。

2. 资料有多长，模型怎样计算？

模型处理文字时，会先通过分词器把文本拆成较小的片段，每个片段称为一个词元(Token)。一个词元(Token)可能对应一个词、一部分文字或标点；一个汉字也不一定恰好对应一个词元(Token)。

例如，下面这句话把汉字、数字和标点都算上，共有 15 个字符：

报名截止时间提前到9月18日。

使用 o200k_base 编码计数，结果是 10 个词元(Token)；使用 cl100k_base 编码，则是 14 个词元(Token)。这是两种不同的分词编码，不代表所有模型都使用它们。这个例子说明：字符数与词元(Token)数之间，没有适用于所有文本和模型的固定换算关系。

因此，判断一段资料占用多少输入长度，需要使用与目标模型对应的计数方式。

可以把上面的句子放进 AI 词元(Token)计数器，切换两种编码，观察数字和分词片段怎样变化。它适合观察纯文本；完整模型请求还可能包含消息结构、工具说明等内容，最终用量要以对应服务的计数或返回结果为准。

有了这个长度单位，才能说明模型一次最多处理多少内容。

3. 上下文窗口为什么有上限，超过后会怎样？

模型处理一次请求时能够使用的内容构成这次请求的上下文；它能容纳的最大词元(Token)数量，通常称为上下文窗口。

文字进入模型后，为什么比存文件更费资源？

把一份通知存在硬盘上，只需要保存文件。让模型根据通知回答问题，还要把文字转换成可计算的数字表示，经过多层计算，利用词句之间的关系来生成回答。例如，要回答报名是否截止，就需要把“这次读书会”“截止日期”和“原时间作废”联系起来。

这些计算会产生中间数据。在常见实现中，程序会保留其中一部分，让模型生成后续内容时可以重复使用，减少从头计算的工作。输入越长，通常需要处理的内容越多，保存这些中间数据所需的空间也越大。 这里用到的是计算时的内存，包括显卡上的内存，也叫显存；原始文件只有几百 KB，并不意味着计算时也只占几百 KB。

继续看通知的例子。假设每份通知长度接近，而且都是本次首次处理，把两份增加到 80 份，新增通知也要经过输入计算。因此，即使最后只回答“已经截止”，开始出现这几个字之前，也可能需要等待更久。生成回答时，程序还需要读取前面保留的数据。资料量增加，既可能影响开始回答前的等待，也可能影响后续生成速度；具体增加多少，取决于模型、硬件和缓存情况，不能按文件数量直接换算成秒数。

阿里云的大模型推理加速说明介绍了这类中间数据如何占用显存，以及输入计算与响应时间的关系。它展示的是一种具体实现，这里借它说明计算和存储开销的来源。

所以，模型服务需要在模型本身支持的长度、运行程序的实现和可提供的资源范围内，设定一次请求的长度上限。这个数值不一定就是机器内存耗尽的临界点，也不能只把配置中的数字调大，就认为模型能够可靠处理任意长度。

如果自行运行模型，强行处理超出机器承受能力的内容，程序可能因无法分配足够的内存而报错或中止；即使运行资源足够，超出模型原本支持的长度后，能否正确利用远处的信息，也需要额外验证。增大窗口需要模型能力和运行条件共同支持。

为什么输入没有超限，也可能没有空间回答？

回答不是在输入结束后，另找一块无限大的空间写出来。对常见的输入与生成内容共享窗口的模型，回答要求、问题、资料、聊天记录，以及接着生成的内容，都要计入同一次请求的总长度。

下面假设窗口上限是 10,000 个词元(Token)。数字只用于理解关系，不对应某个真实模型；表中的输入已经包括资料、问题等全部输入内容。

第二种情况虽然还没达到 10,000，但只剩下 500 个词元(Token)。如果任务需要逐项整理多份通知，预计要生成约 1,500 个词元(Token)，就已经没有足够空间。把“最多生成多少”设成 1,500，也不会让这次请求的总容量变成 11,000。

持续生成也会消耗计算时间和资源，所以服务通常还会单独限制一次最多生成多少；发起请求时，也可以按任务需要设置更小的限制。这就是输出上限。它与上下文窗口上限约束的范围不同：窗口管输入与生成内容的合计长度，输出上限只管生成部分。

例如，窗口中还剩 1,500 个词元(Token)，但本次输出上限设为 500，就只能最多生成 500；如果窗口只剩 500，把输出上限设得更大也无法增加剩余空间。

留出生成空间不代表必须写满，简短回答可以提前结束。对于会生成内部推理内容的模型，这部分内容也可能计入生成用量，因此预留 1,500 个词元(Token)，不一定能得到同样长度的可见回答。

真正超过限制时，会在哪一步出问题？

关键是看限制在什么时候被检查、程序如何处理。下面几种情况的后果不同，具体采用哪种行为取决于模型服务和应用设置：

• 提交时就被拒绝。 例如输入本身已有 10,500 个词元(Token)，超过示意窗口的 10,000 上限，服务可以直接返回长度错误。这次模型没有机会按完整资料生成答案；继续提交同样长的内容，并不能解决问题。
• 先删掉部分内容，再交给模型。 如果应用或接口启用了截断，它可能把输入缩短到允许范围。但“变短”不代表“关键依据都还在”：假如 9 月 16 日的调整通知恰好被删掉，只剩 9 月 10 日的旧通知，模型收到的依据就仍是“9 月 20 日截止”。它可能据此回答还能报名，读者却以为它看过两份通知。这里丢失的是本次输入中的依据，不能理解成模型完整读过后又忘记了。
• 开始生成了，但没能写完。 输入符合要求，不代表剩余空间足够完成任务。生成过程中达到窗口或输出上限，结果可能就此停止。例如逐项整理通知时，只写完前几项便结束，后面的结论和出处尚未输出。此时返回了文字，也不等于任务已经完成。

例如，DeepSeek 的中文接口说明明确区分了正常结束与因长度限制停止生成，并说明输入与输出的总长度受到上下文长度限制。它是一个具体接口的依据，不能据此假定所有接口都会自动截断，或以完全相同的方式报错。

这里讨论的是两个“最多允许多少”的上限，没有一个要求资料必须凑够的通用下限。只提供两份通知，只要足以支撑当前判断，就不必为了填满窗口继续添加内容；如果遗漏了调整通知，问题在于依据不完整，而不是输入太短。

4. 即使放得下，为什么也不必全部交给模型？

假设 80 份资料都没有超过窗口上限，容量问题暂时解决了，但回答是否可靠，还没有得到保证。

模型仍然要分清每份通知说的是哪场活动，哪些日期与当前问题有关，以及哪份调整通知替代了旧安排。其他活动也可能出现“9 月 18 日截止”这样的文字，但只有日期相同，不能证明它就是当前问题的依据。输入被接受，只说明请求符合了长度等接口要求，不能证明这些关系都已经判断正确。

例如，两份关键通知都完整保留了，模型仍可能没有正确识别“原时间作废”与旧通知的关系。此时即使窗口还有大量余量，答案也可能出错。窗口大小不能代替对答案的检查，仍要核对模型是否采用了对应活动的最新安排，并保留了结论成立的条件。

除了前面提到的处理时间和运行资源，在按输入长度计费的服务中，更多资料还可能增加费用。是否值得付出这些成本，应看它们有没有补上当前判断所需的依据。

所以，把 80 份资料全部交给模型，并不自动比提供两份关键通知更保险。它可能让依据更完整，也可能只是增加了无关内容和处理成本，需要看新增资料是否对当前问题有用。

这也不意味着资料越少越好。如果任务是比较全年所有读书会的报名安排，多场活动的通知就都可能有用。应当保留多少资料，由问题需要哪些依据来决定。

5. 给资料之前，先判断它能帮助回答什么

回到开头的报名问题，准备资料时可以把握三个原则：

• 保留能支持当前判断的依据。 核对活动、通知正文和来源；不能只看文件名，也不能只留下一个脱离出处的日期。
• 保留会改变结论的条件。 “原时间作废”“仅限某类报名者”等说明，可能比一整段无关背景更重要，不能为了缩短输入而删掉。
• 确认这些资料和生成内容能一起放下。 如果都与任务有关却一次放不下，可以缩小本次问题的范围，或分批处理并保留来源，不能任意删去一部分后仍声称回答了全部问题。

如果两份相关通知都已提供，下面是一种预期回答：

按 9 月 16 日《读书会报名调整通知》，截止日期已改为 9 月 18 日，原定 9 月 20 日的安排作废。因此，按这些通知，9 月 19 日已经不能报名。

这段回答有依据，是因为它使用了对应活动的通知、发布日期和更新关系。如果只取得旧通知，就应说明当前结论依据的是旧安排，尚未核实是否存在后续调整；多加入几份其他活动的通知，补不上这个缺口。

可以换个条件检查自己的理解：假如用户问的是“今年所有读书会的报名截止日期分别是什么”，还能只保留这两份通知吗？

不能。问题的范围扩大了，需要覆盖的活动也变多了。此时增加相关资料是必要的；如果一次放不下，应调整处理方式，而不是把不完整的资料当成全年依据。

资料不能无限塞进去，是因为文字进入模型后需要计算、占用运行空间，回答生成也需要这些资源，所以一次请求必须有长度边界。越过边界，可能得到的是长度错误、依据被删减后的回答，或没有写完的结果；在边界以内，多加资料也不保证答案更可靠。词元(Token)帮助我们衡量长度，上下文窗口说明一次可用的范围，而当前问题决定哪些资料值得放进去。