面 Agent 岗必被问"上下文太长怎么维护"。2026 年的标准答案已经不是"压缩呗"——而是一个四象限框架：Write、Select、Compress、Isolate。能说出这个框架 + 优先级 + 反直觉结论（压缩率不是越高越好）的候选人，明显区别于背 2024 年老答案的人。

💡 答案要点

先纠正一个认知（面试官挖坑点）：

窗口都 100 万 token 了，为什么还要操心上下文？因为上下文越长，模型越"蠢"——Transformer 的 n² 注意力让每个 token 分到的注意力权重被稀释，长上下文真实能力会退化（业界用 MRCR-VR 这类指标衡量长上下文能力，各家大模型 System Card 都会报）。所以上下文管理从"容量问题"变成了"认知问题"：塞什么进去最好。

四象限框架（2026 标准答案）：

象限	含义	优先级	说明
Write	写什么进上下文	次优先	只写必要信息，从源头控制
Select	选择加载什么	⭐最高性价比	渐进式披露：先目录后正文，按需加载
Compress	压缩已有内容	保底	摘要/截断，有信息损失
Isolate	隔离敏感/冲突信息	最谨慎	上下文隔离，防污染

记忆口诀：Select > Write > Compress > Isolate——选择先于写入，压缩是保底，隔离最谨慎。

Select 为什么性价比最高（举例）：

# 三级加载（Progressive Disclosure）：Skill 标准做法
第一级：只曝目录（metadata），一个技能一行描述，中位数约 80 token
第二级：按任务语义匹配索引，命中才看详情
第三级：真正用到时才加载完整说明书

对比：一次性全塞 20 个 Skill 全文 vs 只常驻 20 行目录 + 按需加载
→ 常驻 token 从几万降到几百，且不影响能力

反直觉结论：压缩率不是越高越好

目标不是"单次请求省多少 token"，而是"完成整个任务总花多少 token"。
压得太狠 → 细节丢失 → Agent 反复回头重查 → 省下的全赔回去。
（业界有压缩对比实测：压最狠的方案完成任务的总体 token 反而最高）

过时/污染信息的四层防御（进阶加分）：

层	思路	例子
心理模型层	接受"数据会过时"，宁可多读一遍也不信旧缓存	实测大量 Agent 会话中文档重读是冗余的——这是特性不是 bug
版本化层	像 Git 一样给上下文打 Commit，可回看比对	Context Repositories 思路
强制约束层	修改前强制重读最新版本	Claude Code 的 "Read Before Edit"
数据结构层	事实修正不打删旧数据，打"失效"时间戳 + 新旧关联	双时态图谱（Graffiti 思路）

面试话术：

"上下文管理 2026 年的标准框架是 Write/Select/Compress/Isolate 四象限，优先级 Select > Write > Compress > Isolate。窗口再大也要管，因为 n² 注意力导致长上下文能力退化。性价比最高的是 Select——渐进式披露，先目录后正文按需加载，我实测装 20 多个 Skill 常驻只有几百 token。压缩是保底不是越多越好，目标是最小化整个任务的总 token 而不是单次；隔离最谨慎，防上下文污染。过时信息我按四层防御：多读一遍、版本化、改前强制重读、失效时间戳可追溯。"