面试官问：“Agent 对话太长了，上下文爆了怎么办？“

AAI机器之心

191人浏览 · 2026-03-29 08:45:00

AAI机器之心 · 2026-03-29 08:45:00 发布

面试官问：“Agent 对话太长了，上下文爆了怎么办？”

“2 年 Agent 开发经验，主导过多个 Agent 项目上线，熟悉 LangChain/LangGraph”

这份简历挺漂亮的。

但我发现一个有意思的现象：能把 Agent 跑起来的人很多，能回答"上下文超了怎么处理"的人很少。

这场面试，候选人就在这个问题上栽了跟头。

Round 1：上下文窗口满了，你怎么处理？

面试官：“假设你的 Agent 跑了 50 轮工具调用，上下文快超了，你会怎么处理？”

候选人：“呃…直接截断？保留最近的消息？”

正解：

直接截断是最差的选择——你可能把关键信息给丢了。

上下文管理有两种主流方案：Observation Masking（观察遮蔽）和 LLM Summarization（摘要压缩）。

Observation Masking

把较早的观察结果替换成占位符，告诉模型"此处省略了部分内容"。

工程配置：

保留最近 10 轮对话效果最好（来源：JetBrains Research）
再早的内容用占位符标记，不是直接删除
好处是快、便宜，不需要额外调用 LLM

LLM Summarization

用一个独立的 LLM（通常是小模型）对历史内容做摘要，压缩成几句话。

工程配置：

每 21 轮做一次摘要，同时保留最近 10 轮原文
摘要模型用 GPT-4o-mini 或 Claude Haiku，成本低
摘要后 token 通常能压缩 5-10 倍

混合方案

JetBrains Research 的研究表明，混合使用两种方案效果最好：

比纯 Observation Masking 成本低 7%
比纯 LLM Summarization 成本低 11%
成功率还提升了约 2.6%

要点速记

别直接截断，会丢关键信息

两种主流方案：Observation Masking（快但粗糙）、LLM Summarization（准但有成本）

混合方案：保留最近 10 轮原文 + 更早内容做摘要

每 20-25 轮触发一次摘要是常见配置

Round 2：什么时候触发压缩？阈值怎么设？

面试官：“摘要压缩不是免费的，你怎么决定什么时候触发？”

候选人：“呃…等上下文快满了再压缩？”

（面试官内心 OS）：这么被动，生产环境早就炸了…

正解：

等上下文满了才压缩是最笨的做法——你已经来不及了。

压缩触发有两种策略：被动触发和主动触发。

被动触发（基于阈值）

当上下文使用量达到某个比例时触发压缩。

关键参数：

Tmax

（触发阈值）：通常设 80%-95%，比如 128k 窗口设 100k 触发

Tretained

（保留量）：压缩后保留多少 token，通常是窗口的 30%-50%

Factory.ai 的配置参考：

触发阈值：80% 上下文窗口
压缩后保留：最近 10 轮原文 + 摘要

主动触发（基于任务阶段）

不等 token 堆积，而是在任务完成时主动压缩。

触发时机：

每完成一个子任务后
每执行完一次 tool call 后
每 10-15 轮对话后

Google ADK 的做法：

默认在 85% 上下文时触发
研究发现，设成 25% 反而能收集更多事件用于分析

任务类型决定阈值

不同任务对上下文的依赖程度不同：

任务类型	推荐触发阈值	原因
调试 Debug	90%-95%	状态依赖强，晚压缩
代码审查	80%-85%	需要前后对比
简单问答	50%-60%	可以激进压缩
文档生成	70%-80%	中等依赖

要点速记

被动触发：80%-95% 上下文使用率时启动

主动触发：每 10-15 轮或每个子任务完成后

调试任务阈值设高（90%+），问答任务可以设低（50-60%）

Tmax（触发线）和 Tretained（保留量）是两个核心参数

Round 3：压缩过度导致信息丢失怎么办？

面试官：“我们实际项目里遇到一个问题——压缩后 Agent 老是忘记之前做过什么，反复重复操作。怎么解决？”

候选人：“…这个确实没遇到过。”

正解：

这是典型的过度压缩问题，压得太狠会适得其反。

为什么会出问题？

压缩把关键信息摘要掉了，Agent 需要时必须重新获取，导致：

额外的 API 调用（re-fetch）
更高的延迟
任务循环（做了忘、忘了做）

Factory.ai 的研究显示：在迭代式代码审查这种场景，激进压缩的 round-trip 成本可能超过省下的 token 费用（来源：Factory.ai）。

结构化摘要 vs 通用摘要

通用摘要：把所有内容压成一段话，信息损失大。

结构化摘要：按类别保留关键信息，信息损失小。

结构化摘要需要保留的内容：

Session Intent

：用户这次会话想做什么

关键标识符

：文件路径、函数名、变量名

操作记录

：做过哪些操作，结果是什么

待办事项

：还有什么没完成

代码示例（LangChain 风格）：

python

`summarization_prompt = “”"
请按以下结构摘要对话历史：

会话目标

{用户想要完成什么}

已完成操作

操作1：{结果}
操作2：{结果}

关键信息

文件路径：{paths}
函数/类：{identifiers}

待办事项

{还没完成的}
“”"`

Factory.ai 的测试结果：结构化摘要比 OpenAI 和 Anthropic 的通用摘要保留了更多有用信息（来源：Factory.ai）。

压缩 + 检索的混合方案

把摘要当作索引，详细信息存到外部存储：

摘要保留关键标识符（文件名、函数名）
详细内容存到 recall storage 或 archival storage
需要时通过标识符检索完整内容

这就是 MemGPT 的核心思想——把 LLM 当成操作系统，上下文窗口当成 RAM，外部存储当成硬盘。

要点速记

过度压缩会导致 re-fetch，成本可能更高

用结构化摘要替代通用摘要，保留：目标、操作记录、关键标识符

摘要只是索引，详细内容存到外部存储

MemGPT 思路：上下文是 RAM，外部存储是硬盘

Round 4：LLMLingua 听说过吗？和摘要有什么区别？

面试官：“除了摘要，还有没有其他压缩方法？比如 LLMLingua？”

候选人：“听说过，但没用过…”

正解：

LLMLingua 是另一种思路——不是语义压缩，而是 token 级别的剪枝。

工作原理

LLMLingua 用一个小模型（如 GPT-2 或 LLaMA-7B）计算每个 token 的困惑度（perplexity）：

困惑度低的 token → 信息量小 → 可以删
困惑度高的 token → 信息量大 → 保留

三个核心模块

Budget Controller：控制不同部分的压缩比例

指令部分：10%-20% 压缩（要保留清晰度）
Few-shot 示例：60%-80% 压缩（冗余度高）
问题部分：0%-10% 压缩（必须保留）

Token-level Compression：逐 token 判断是否删除
Alignment：对齐到目标 LLM（通过指令微调）

LLMLingua 家族

LLMLingua

：20x 压缩，性能损失约 1.5%（来源：Microsoft Research）

LongLLMLingua

：针对长上下文优化，能缓解中间迷失问题，RAG 场景性能提升 21.4%

LLMLingua-2

：BERT 级别编码器，速度快 3-6 倍

摘要 vs LLMLingua

维度	摘要压缩	LLMLingua
压缩方式	语义理解	Token 剪枝
压缩比	5-10x	最高 20x
速度	慢（需调 LLM）	快（小模型计算）
信息保留	可能丢细节	保留原始表述
适用场景	对话历史	RAG 检索结果、长文档

实际建议：

对话历史用摘要压缩
RAG 检索结果用 LLMLingua（已集成 LangChain、LlamaIndex）
两者可以组合使用

要点速记

LLMLingua 是 token 级剪枝，不是语义压缩

三模块：Budget Controller + Token Compression + Alignment

压缩比最高 20x，性能损失仅 1.5%

对话用摘要，RAG 结果用 LLMLingua，可组合

Round 5：如何避免 Context Poisoning？

面试官：“听说过 Context Poisoning 吗？你们怎么防止的？”

候选人：“Context…Poisoning？这是什么？”

正解：

Context Poisoning 是指错误信息进入上下文后被反复引用，导致 Agent 持续犯错。

典型症状

Agent 反复尝试已经失败过的方案
输出越来越离谱，却不自我纠正
工具调用和用户指令对不上
暂时修好了，过几轮又出问题

Gemini 玩宝可梦的案例：Agent 幻觉了一个不存在的目标，然后一直朝着这个目标行动，完全偏离轨道。

Context Rot（上下文腐烂）

相关概念：即使没有错误信息，上下文太长本身就会导致性能下降。

Chroma Research 的发现：

模型的有效上下文窗口远小于宣称的窗口大小
大多数模型在 256k token 以内表现良好
超过这个范围，性能显著下降
Stanford 研究：上下文变长，性能下降 15%-47%

防护措施

验证工具输出

工具返回结果先校验再写入上下文
发现明显错误立即删除，不让模型学坏

周期性清理

用 LangGraph 的 RemoveMessage 删除特定消息
或用 REMOVE_ALL_MESSAGES 清空重来

设置上下文护栏

明确告诉模型不要重试已失败的方案
超过 N 次循环强制终止

分阶段处理

大任务拆成小任务
每个小任务用独立会话
只传递最终结果，不传递中间过程

压缩优先级

raw（原文）> compaction（紧凑化）> summarization（摘要）
只有紧凑化不够用时才做摘要

工程配置参考：

python

`# 触发阈值
CONTEXT_ROT_THRESHOLD = 128_000 # 128k tokens

压缩策略

if context_size > CONTEXT_ROT_THRESHOLD:

# 保留最近 3 轮原文

recent_messages = messages[-3:]

# 最老的 20 轮做摘要

old_messages = messages[:-3][:20]
summary = summarize(old_messages)

# 重组上下文

new_context = system_prompt + summary + recent_messages`