Agent 的 Context Engineering / Management
P1 · agent_architecture
🏷 标签：agent, context, engineering, management
1️⃣ 考察意图
面试官想考察你对 Agent 系统核心瓶颈——上下文窗口的理解深度，而非简单背诵“长上下文模型”。真正刁钻的点在于：你能否在有限窗口内，通过工程手段最大化信息密度与决策质量。这属于系统设计+工程取舍类问题。答好了能展示你对 Token 经济学、信息检索、记忆分层、以及模型注意力机制的底层理解，证明你有能力设计一个稳定、可扩展的 Agent 系统，而非只会调 API。
2️⃣ 标准答
Agent 的 Context Engineering 核心是解决“窗口有限，信息无限”的矛盾。我从三个层面展开：信息筛选、结构编排、动态管理。
信息筛选：只放最有用的
- 检索增强：用 BM25（k1=1.5, b=0.75）做关键词召回，结合 DPR 或 ColBERT 做语义检索，Top-K 取 10-20 条。为什么：BM25 对精确匹配好，DPR 对语义泛化好，混合检索比单一方法召回率提升 15-20%（通用经验）。
- 重排序（Rerank）：用 Cross-encoder（如 Cohere Rerank 3 或 BGE-Reranker）对检索结果打分，取 Top-5。坑：Rerank 模型计算量大，必须异步执行，否则阻塞 Agent 主循环。解法：将 Rerank 放到独立线程池，超时 200ms 后降级为 BM25 结果。
- 上下文压缩：用 LLM 对长文档做摘要（如“用 50 字总结核心事实”），或直接用 LLMLingua 等工具做 token 级压缩。取舍：压缩会丢失细节，适合历史对话，不适合需要精确数字的代码或 SQL。
结构编排：让模型看懂
- 分层结构：将上下文分为三层：系统层：固定指令、工具定义、安全约束（占 10% 窗口）。
- 任务层：当前用户问题、检索到的相关文档、中间推理步骤（占 60%）。
- 记忆层：历史对话摘要、长期记忆（占 30%）。 位置编码：利用 RoPE 的“近端优先”特性，把最关键信息（如用户最新指令）放在上下文末尾。为什么：LLM 对末尾 token 的注意力权重更高（尤其是 GPT-4 等模型），放末尾能提升响应准确率 5-10%（通用经验）。格式化：用 Markdown 或 JSON 结构化，避免纯文本。例如工具调用用 <tool_call> 标签包裹，让模型更容易解析。
动态管理：窗口不够就换
- 滑动窗口：历史对话超过窗口 80% 时，丢弃最早 20% 的 token。坑：直接丢弃会丢失关键上下文。解法：对丢弃部分做摘要，存到长期记忆库（如 Redis），需要时再检索。
- 记忆分层：参考 MemGPT（论文名）的架构：工作记忆：当前对话上下文，窗口内。
- 长期记忆：用户偏好、关键事实，用向量数据库（如 Chroma）存储，按需检索。
- 存档记忆：过时信息，压缩后存到磁盘，仅当 Agent 主动查询时加载。 Token 预算：为每个模块分配固定 token 数（如系统层 2K、任务层 8K、记忆层 4K），超限时触发压缩或丢弃。取舍：固定预算简单但不够灵活，可改用动态预算（如根据任务复杂度调整），但实现复杂度高。
实际落地坑
- 坑：Rerank 延迟导致 Agent 超时。解法：将 Rerank 设为异步，并设置 fallback（直接返回检索结果）。在字节的 Agent 系统中，我们曾因 Rerank 耗时 500ms 导致用户等待，改为异步后延迟降到 100ms。
- 坑：摘要丢失关键数字。解法：对包含数字、代码、日期的片段做“保留标记”，摘要时强制保留。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从信息筛选、结构编排、动态管理三个层面回答。信息筛选上，用 BM25+DPR 混合检索，配合 Rerank 和上下文压缩，只放高价值信息。结构编排上，将上下文分为系统层、任务层、记忆层，利用 RoPE 特性把关键信息放末尾。动态管理上，用滑动窗口+记忆分层，参考 MemGPT 架构，为每个模块设 Token 预算。总结一句：Context Engineering 的核心是‘在有限窗口内，通过检索、压缩、分层，让模型看到最该看的东西’。”
4️⃣ 高频追问 & 应对
追问 1：如果用户问题需要引用 50 页文档，窗口只有 128K，你怎么处理？
先做文档分段（chunking），每段 512 token，用 BM25+DPR 检索 Top-20 段。然后对 Top-20 段做 Rerank，取 Top-5。如果 Top-5 仍不够，用 LLM 对 Top-20 段做摘要（每段 100 token），把摘要放入上下文。最后，如果用户追问细节，再按需检索原始段落。关键取舍：摘要会丢失细节，但能覆盖更多文档；适合“概览型”问题，不适合“精确数字型”。
追问 2：Agent 在对话中频繁切换任务，历史上下文怎么管理？
用“任务切换标记”分割上下文。每次切换时，将当前任务的关键信息（如用户意图、已执行工具）压缩成摘要，存入长期记忆。新任务开始时，只加载系统层和任务层，记忆层从长期记忆中检索相关摘要。坑：摘要可能丢失跨任务依赖。解法：在摘要中保留“未完成任务列表”，新任务启动时检查是否有依赖。
追问 3：你怎么评估 Context Engineering 的效果？
用三个指标：① 召回率：Agent 能否找到正确答案（用人工标注的 QA 对测试）。② Token 利用率：有效 token 数 / 总 token 数，目标 > 70%。③ 响应延迟：从用户提问到 Agent 回复的时间，目标 < 2s。取舍：召回率提升通常需要更多 token，导致延迟增加。需要根据业务场景做平衡，比如客服系统优先延迟，文档分析优先召回率。
5️⃣ 避坑 · 常见错误答法
- ❌ 说“直接用长上下文模型（如 Gemini 1M）就行，不需要 Context Engineering” → ✅ 长上下文模型只是降低了压力，但窗口越大，模型对无关信息的注意力越分散（注意力衰减问题），且成本线性增长。Context Engineering 是必要优化，不是可选项。
- ❌ 说“把所有历史对话都塞进上下文，用滑动窗口丢弃最早的部分” → ✅ 直接丢弃会丢失关键上下文。正确做法是对丢弃部分做摘要，存到长期记忆库，需要时再检索。滑动窗口只适合“对话无长期依赖”的场景。
6️⃣ 简历呼应
- 如果你有 RAG 项目：从“检索增强+上下文压缩”角度切入，强调你在项目中如何用 BM25+DPR 混合检索，以及如何用 Rerank 减少噪声。举例：在 XX 项目中，通过 Context Engineering 将召回率从 70% 提升到 85%。
- 如果你只做过传统 NLP：用“文本摘要+信息提取”类比，说明你如何将长文档压缩成关键事实，再放入上下文。强调你对 Token 预算和结构化的理解。
- 如果你是校招无项目：聚焦 MemGPT 论文复现 demo，说明你如何实现记忆分层和滑动窗口。强调你对 RoPE 位置编码和注意力机制的理解。
7️⃣ 延伸阅读
- MemGPT: Towards LLMs as Operating Systems（论文）
- LLMLingua: Compressing Prompts for Accelerated Inference（论文）
- ColBERT: Efficient and Effective Passage Search via Contextualized Late Interaction（论文）
- Cohere Rerank 3 官方文档（工具）
- LangChain Agent 上下文管理最佳实践（博客）