把大模型从演示变成能值班的系统时，长上下文工程几乎总会先露出工程缺口。下面按可执行的顺序来拆：先讲它解决什么、卡在哪，再讲选型时看哪些数字，最后落到智能体和网关该怎么接。本文面向要上线的工程师，不写空泛趋势。

一、为什么要更长的上下文

2022 年 GPT-3.5 上下文 4K token，2024 年 Claude 3 做到 200K，Gemini 1.5 Pro 冲到 1M、实验版本 2M；2025 年 GPT-4.1、Qwen2.5-1M、GLM-4-Long 等陆续把 1M 级上下文推向生产。对 infra 工程师而言，这不是简单”把 max_position 调大”就能解决的问题——注意力的 O(n²) 计算、KV cache 的 O(n) 显存、位置编码外推的精度崩塌、长样本稀缺导致的训练困难、长序列的通信与负载不均，每一环都需要重构。

这里系统梳理长上下文的工程栈：从 RoPE、YaRN、LongRoPE 等位置编码扩展，到 Mamba / 线性 attention / NSA 等计算复杂度优化，再到 Ring Attention / Ulysses 序列并行、MLA / StreamingLLM 等 KV 压缩策略，最后落到评测（NIAH、RULER、LongBench）与 Agent 场景的 KV 复用。

二、位置编码的扩展

注意到一个变化：早期长上下文的 killer app 是”一次性喂一本书”，现在 Agent 轨迹 和 长思维链 成为更关键的需求——模型输出自己也要消耗上下文。

工程上永远有 “RAG vs long-context” 的争论。真实答案是两者互补：

三、Attention 计算复杂度

生产上普遍的做法是： RAG 做召回 + long-context 模型做 reasoning ，第 17–18 篇会详细讨论。

数据来源：各模型官方 API 文档与技术报告（Gemini 2.5 Pro 官方为 1,048,576 输入 token；GPT-5 官方说明总窗口 400K、输入上限 272K；Kimi K2 技术报告以 YaRN 扩到 128K，K2-0905 更新到 256K）。

四、稀疏与近似 Attention

注意： 官方宣称长度 ≠ 实际有效长度 。Needle-in-a-Haystack 和 RULER 都显示，几乎所有 1M+ 模型在 256K 以上精度明显下滑；MiniMax-01 由于采用线性 attention，4M 在长距离检索任务上还有不小差距。

Transformer 本身对序列顺序不敏感，位置编码（Positional Encoding, PE）是注入顺序信息的关键。长上下文工程的第一个战场就是 PE。

五、长上下文训练

绝对位置编码 （如 BERT 的可学习 PE、Transformer 原论文的 sinusoidal）直接给每个位置一个 embedding，长度外推非常差——训练时没见过的位置，embedding 无从查起。

RoPE（Rotary Position Embedding, Su et al. 2021） 把位置以”旋转”形式注入到 Q、K 向量：对每对通道 ((x_{2i}, x_{2i+1})) 按角度 (theta_i = text{base}^{-2i/d}) 旋转 (mtheta_i) （ (m) 为位置索引）。

六、Ring Attention 与序列并行

def rope(x, position_ids, base = 10000.0 ): # x: [B, H, T, D], D must be even half = x.shape[ – 1 ] // 2 freqs = base ** ( – torch.arange( 0 , half, device = x.device) * 2 / x.shape[ – 1 ]) angles = position_ids[:, None ] * freqs[ None , :] # [T, half] cos, sin = angles.cos(), angles.sin() x1, x2 = x[…, :half], x[…, half:] return torch.cat([x1 * cos – x2 * sin, x1 * sin + x2 * cos], dim =- 1 ) RoPE 的优点： – 相对位置 ：

缺点： 直接外推到训练长度以外效果差 ——高频分量在超长位置下摆动剧烈，注意力分布”混乱”。

落地时建议先做的 5 件事

1. 用自己的 20 条真实请求测 TTFT / TPOT / 失败原因，不要只看公开榜。
2. 先写显存和 KV 缓存账，再决定卡数、量化和并发上限。
3. 网关层把鉴权、配额、审计和模型路由收口，应用里不要各接各的 Key。
4. 工具调用默认拒绝，按白名单放开，高风险动作必须人审。
5. 模型升级准备回滚：旧权重、旧 Prompt、旧评测集要能一键切回。

和智能体产品怎么接

对龙虾PRO这类要把 OpenClaw 落到中国业务场景的平台来说，长上下文工程决定的是延迟能不能进对话、成本能不能规模化、出了问题能不能追溯。技能市场、数字员工和网关都应该吃同一套观测与权限，而不是文章里的概念演示。

本文侧重全链路风控方法论。落地时请用自身业务单据做回放验证，不要把示例阈值直接当生产策略。 相关：风控体检 · 方案资源