← 返回概念解读

Concept Fable精修版

上下文窗口

Context Window · LLM

先读故事。这里不急着给定义,先让问题自己长出来。

寓言故事

只能看见一张案桌的法官

老法院有位法官读案极快,但他有个限制:每次只看得见案桌上的纸。桌外卷宗再重要,没有摆上来,他就当作不存在。

早年案子薄,书记官把诉状、证词和规则放上桌就够了。后来案子牵涉合同、旧信、历史投诉、工具回执和判例,案桌开始拥挤。

书记官先把字写小,塞进更多纸。法官确实看到更多材料,也更容易漏掉关键句;新证据和过期规则挤在一起,先后顺序变得混乱。

他们又换了更大的案桌。大家高兴一阵,不久又堆满。更大的桌面让懒惰整理活得更久,也让无关材料堂而皇之进入判断。

一次审判中,决定赔付的条款被挤到最后,法官没看到。另一次,过期政策放在最显眼处,反倒影响了判决。

新书记官改问:本案必须知道什么,哪些只是背景,哪些要摘要,哪些必须原文保留,哪些根本不该上桌。案桌仍有限,结果却稳了。边界大小重要,摆什么上去更重要。

书记官还学会了给材料排座次。必须遵守的规矩放在固定位置,当前问题紧挨着它,证据按新旧和相关程度排列,容易混淆的旧材料要标清来源。

案桌没有因此无限扩大,却变得像一间有秩序的屋子。法官读得快,仍会受桌面影响;书记官的本事,就是让有限桌面承载最有用的线索。 后来新手入门时,老师傅不再先讲抽象名目,而是让他们复盘那次失误:原先哪里靠直觉,第一次修补为什么不够,新的安排怎样把风险留在能检查的位置。等他们能说清这些细节,还能指出什么时候该沿用、什么时候该升级,才算真正懂了这套办法。 后来他们还把这套办法交给新人演练:先让新人按旧办法做一遍,看错误怎样出现;再按新规矩重做,看哪一步被提前拦住,哪一步留下了证据。新人若只会背名字,仍会在相似场景里乱用;只有能说出适用边界、代价和失败后的补救,才被允许独立接活。

揭示

这个故事讲的是:上下文窗口

Context Window 是模型在一次请求中能处理的输入和输出总量,通常以 token 衡量。它决定了 prompt、检索材料、历史消息、工具结果和生成答案能共同占用的空间。长上下文模型降低了截断风险,但不会自动解决相关性、顺序、污染、成本和注意力稀释问题。企业 Agent 需要围绕上下文窗口做选择、排序、压缩和预算管理。

它重要的地方在于:它不只是一个术语,而是在真实 AI / Agent 系统里会反复出现的结构性问题。理解它,才能判断什么时候该加模型,什么时候该改流程,什么时候该补治理。

隐喻映射

  • 案桌:模型的一次上下文窗口
  • 桌外卷宗:未进入当前请求的信息
  • 把字写小:粗暴压缩或塞入更多材料
  • 更大的案桌:更长的 context window
  • 过期政策放在显眼处:低质量上下文影响输出
  • 上桌规则:上下文选择、排序和压缩策略
  • 最后洞察:Context Window 是容量边界,不能替代上下文工程

Soloharness 判断

这个概念的实战价值,是帮你把“看起来聪明的 AI 功能”拆成可交付、可验收、可治理的工作单元。

tokenpromptlong-context modelattentiontruncation

相关辨析

这个概念容易和相邻概念混用,建议继续看对比页。