Round 1:  System(500) + User(100) + AI(200)          = 800 tokensRound 2:  System(500) + H1(300) + User(100) + AI(200) = 1,100 tokensRound 3:  System(500) + H2(600) + User(100) + AI(200) = 1,400 tokens...Round N:  System(500) + H(N-1)(...) + User + AI       → ∞

预填充注意力计算量 ∝ n² × d（d 为模型维度 d_model）当 n 从 4K → 128K 时：计算量增长 = (128/4)² = 1024 倍

信息召回率分布：位置:  [开始] ████████████████░░░░░░████████████████ [结尾]权重:   高              低                    高        ↑ 开头信息        ↑ 中间信息被稀释      ↑ 结尾信息          保留良好          容易被忽略            保留良好

上下文填充率 vs 指令遵循度（示意）：0-25%  ████████████████████  95-100%  指令遵循优秀25-50% ████████████████░░░░  75-90%   偶有偏差50-75% ████████████░░░░░░░░  55-75%   明显退化75-100%████████░░░░░░░░░░░░  30-55%   严重退化

费用 = Input Tokens × 单价 + Output Tokens × 单价典型定价（GPT-4 Turbo 级别）：- Input:  $10 / 1M tokens- Output: $30 / 1M tokens每轮对话的输入 token 增长：  第1轮输入: 1K  → 第2轮输入: 2K  → 第3轮输入: 3K ... → 第N轮输入: ~N×平均轮长度  · 单轮输入量 ∝ N（线性增长）  · N轮总输入量 = 1K + 2K + 3K + ... ≈ N×(N+1)/2 × 平均轮长度 → O(N²)一个 50 轮对话的估算：- 第50轮输入: ~80K input tokens → $0.8/轮（对比新对话 $0.01/轮，差距 80 倍）- 50轮总输入: ~1,275K tokens → 累计 $12.75

原始历史: [Sys] [M1][M2][M3][M4][M5][M6][M7][M8][M9][M10]  系统提示    ↑ 超出窗口                               ↑截断后:   [Sys]                [M6][M7][M8][M9][M10]          保留系统提示           保留最近的对话

原始历史（5000 tokens）:  User: 帮我写一个登录页面  AI: 好的，这是登录页面代码...[长代码]  User: 加上记住密码功能  AI: 已添加...[修改代码]  User: 修改颜色为蓝色  AI: 已修改...压缩摘要（500 tokens）:  [对话摘要：用户要求创建登录页面，包含记住密码功能，   主色调为蓝色。当前文件：login.vue，主要组件：   LoginForm、RememberPassword。]当前对话:  User: 再加一个注册入口

传统方式：  Context = 全部知识(100K tokens) + 对话(10K) = 110K tokensRAG 方式：  1. 用户提问 → 向量化查询  2. 检索最相关的 K 个片段（~2K tokens）  3. Context = 检索结果(2K) + 对话(10K) = 12K tokens节省：~90% 的上下文空间

上下文组成（优先级从高到低）：1. 系统提示词          → 始终完整保留2. 当前用户输入        → 始终完整保留3. 工具定义           → 始终完整保留4. 最近 3-5 轮对话     → 完整保留（工作记忆）5. 更早对话的摘要      → 压缩保留（短期记忆）6. RAG 检索结果       → 按需注入7. 长期记忆检索       → 按需注入总目标：控制在上下文窗口的 60-70% 以内

Lexical error on line 4. Unrecognized text....{上下文预算<br/>目标: 60-70%}    BUDGET --> AL-----------------------^

每次对话中，系统自动注入：┌─ 系统层 ─────────────────────────────┐│  角色定义 + 行为约束 + 输出格式要求      ││  工具定义（所有可用工具的 schema）        ││  集成状态（已连接的服务信息）             ││  项目上下文（文件结构、打开的文件）       ││  用户偏好（语言、OS、Shell 类型）        │├─ 对话层 ─────────────────────────────┤│  多轮对话历史（含工具调用和返回）         │├─ 增强层 ─────────────────────────────┤│  搜索/读取的文件内容                    ││  代码诊断信息（linter 错误）            ││  IDE 状态（光标位置、选中内容）          │└───────────────────────────────────────┘

策略1: 按需读取  - 不预加载整个项目，只在需要时读取特定文件  - 优先使用搜索而非全文读取策略2: 智能截断  - 工具返回结果超长时自动截断  - 保留文件首尾，中间用 "... existing code ..." 替代策略3: 子代理分流  - 复杂搜索任务委托给子代理  - 子代理只返回结论，不返回中间过程  - 主上下文不被搜索过程污染策略4: 对话轮次限制  - 超过一定轮次后提示用户开启新对话  - 或自动压缩早期对话为摘要策略5: Todo 列表替代对话记忆  - 用结构化的 Todo 列表替代线性对话历史  - 状态信息存储在 Todo 中而非反复提及

记忆存储（Memory System）：  ┌─────────────┐     ┌─────────────┐  │  当前上下文   │     │  持久化记忆   │  │  (临时)      │ ←─→ │  (跨会话)    │  │  对话历史    │     │  用户偏好     │  │  工具结果    │     │  项目知识     │  └─────────────┘     │  决策记录     │                      └─────────────┘                           ↑                     按需检索注入上下文

核心问题：模型训练时只见过有限长度，如何外推到更长序列？主流方案：  ┌─ 位置插值 (PI)  ─────────┐  等比压缩位置索引，信息密度下降  ┌─ NTK-aware 插值     ─────┐  非均匀缩放，保留高频分辨率  ┌─ YaRN                ────┐  结合 NTK + 注意力温度调整  ┌─ 动态 NTK            ────┐  根据序列长度自适应缩放  ┌─ LongRoPE            ────┐  搜索最优缩放因子效果：可将 4K 训练长度外推至 32K-128K，但远距离精度仍有损失

Needle In A Haystack（大海捞针）：  - 在长文本中随机位置插入关键信息  - 测试模型能否准确召回  - 结果：多数模型在中间位置表现显著下降LongBench：  - 多任务长上下文评测  - 涵盖摘要、QA、代码完成等InfiniteBench：  - 测试 100K+ token 场景  - 包含检索、计数、代码调试等

Needle In A Haystack（大海捞针）：  - 在长文本中随机位置插入关键信息  - 测试模型能否准确召回  - 结果：多数模型在中间位置表现显著下降LongBench：  - 多任务长上下文评测  - 涵盖摘要、QA、代码完成等InfiniteBench：  - 测试 100K+ token 场景  - 包含检索、计数、代码调试等

无缓存：  每次请求都重新处理全部上下文有缓存：  ┌─ 缓存层 ─────────────┐  │  System Prompt (命中)  │  ← 不重复计算  │  工具定义 (命中)       │  ← 不重复计算  │  历史对话 (部分命中)   │  ← 增量计算  │  新增内容 (未命中)     │  ← 需要计算  └───────────────────────┘效果：减少 50-90% 的输入 token 计费（因提供商而异：OpenAI 缓存命中 50% 折扣，Anthropic 约 90% 折扣但写入时额外收费），处理时间同步大幅缩短

Lexical error on line 29. Unrecognized text....[组合最终结果<br/>节省 50-90% 处理时间]    DELTA -------------------------^

Parse error on line 9:...A --> A1[稀疏注意力<br/>O(n²) → O(n√n)]    A-----------------------^Expecting 'SQE', 'DOUBLECIRCLEEND', 'PE', '-)', 'STADIUMEND', 'SUBROUTINEEND', 'PIPE', 'CYLINDEREND', 'DIAMOND_STOP', 'TAGEND', 'TRAPEND', 'INVTRAPEND', 'UNICODE_TEXT', 'TEXT', 'TAGSTART', got 'PS'

上下文利用效率 = f(填充率, 信息密度, 位置分布)关键发现：1. 0-50% 填充率：效率下降平缓（~5%）2. 50-75% 填充率：效率下降加速（~15%）3. 75-90% 填充率：效率急剧下降（~30%）4. 90%+ 填充率：效率断崖式下跌（~50%+）→ 最优策略：将上下文控制在窗口的 60-70%