上下文长度
2026年4月26日大约 3 分钟
上下文长度
大模型（包括 Claude Agent、所有LLM）的最大上下文长度，核心就是：Transformer 架构的「注意力机制」决定物理上限，再由训练+工程锁死实际可用长度。
一、最核心：为什么是「架构」决定上限？
所有现代大模型都是 Transformer，关键模块：
1. 自注意力 Self-Attention（致命关键）
注意力的本质：
序列里每一个字（token），都要和前面所有字做一次计算、关联、理解
举个例子：
- 上下文 1000 字：每个字只看前面1000个字
- 上下文 1000000 字（1M）：每个字要关联前面一百万token
数学本质
标准注意力复杂度： $$O(n^2)$$ $n$ = 上下文长度 长度翻倍 → 计算量平方级爆炸。
👉 结论： 原生 Transformer 天生不支持超长上下文，架构本身就有物理瓶颈。 这就是为什么早年模型只有 2k、4k 上下文——纯架构扛不住。
二、那 Claude 怎么做到 200K / 1M 超长上下文？
Anthropic 改了架构+注意力算法，这就是你问的「训练架构决定」：
1. 改用「稀疏注意力 / 滑动窗口注意力」
不再让每一个token都全局两两计算
- 只让每个token，关注「局部窗口+关键全局信息」
- 跳过大量无关位置的注意力计算 复杂度从 $O(n^2)$ 压到接近 $O(n)$ 👉 架构改造，是超长上下文的前提
2. 训练时「必须用长文本喂进去训练」
关键点：
- 模型权重、位置编码，是在长文本数据上训练出来的
- 如果训练只用 4k 短文，你强行塞 100k 长文进去：
- 位置编码失效
- 上下文混乱、乱码、逻辑断裂
- 完全理解不了长文档
👉 能读多长，完全取决于：训练时架构适配了多长、数据喂了多长。
3. 位置编码（Position Encoding）架构设计
LLM 不知道文字顺序，靠「位置编码」识别先后：
- 短上下文模型：短距离位置编码
- Claude 长上下文版本：超长距离外推位置编码架构 天生支持远距离语义关联 这也是架构层面锁死的。
三、分两层：理论上限 & 实际上限
① 理论上限（纯架构决定）
由这三点硬锁死：
- 注意力算法（全量/稀疏/滑动/分片）
- 位置编码外推能力
- 模型层数、头数的并行设计
这一层：改不了，出厂就定死 比如：Sonnet/Opus 架构设计就是原生支持 1M 窗口
② 实际可用上限（官方人为限制）
在架构能支持的前提下，官方再做限制：
- 免费版：锁 200K
- 付费Pro：放开到 1M
- Agent 客户端（Claude Code）：再加一层本地截断、自动压缩
四、结合你关心的「Agent 上下文」
Agent 比普通对话更吃上下文：
- 多轮工具调用、历史动作、代码片段、日志
- 系统Prompt、工具描述、Agent 指令常驻占用
所以：
- 底层：Transformer改良架构 决定它最多能装1M
- 中层：训练数据 决定它长文本会不会乱、能不能读懂
- 上层：官方配置+Agent压缩策略 决定你实际能用多少
五、极简总结
- 原生Transformer注意力是平方复杂度，架构天生短文本；
- Claude 通过稀疏注意力+长距离位置编码改造架构，才有超长上下文能力；
- 再用长文本专属训练，让模型学会超长逻辑；
- 架构定「天花板」，官方配额、Agent压缩定「你实际能用多少」。