高频面试题

什么是 Agent 的上下文窗口？为什么它是 Agent 工程中最核心的约束？

这道题看起来在问模型能塞多少 token，实际是在考 Agent 工程里最基础的资源管理：每一轮到底该让模型看见什么、忘掉什么、压缩什么。

适合阶段：Agent 工程 / 上下文工程面核心能力：Context Window · Context Engineering · Memory · Cost

面试官角度分析，想考什么

• 什么是 Agent 的上下文窗口？
  考你能否把它说成模型一次调用能看见的 token 预算，而不是模糊说成“记忆”。

• 为什么它是 Agent 工程的核心约束？
  考你是否理解 Agent 每轮都会往窗口里塞历史、工具定义、工具结果和状态，跑得越久越胀；窗口变大也不能省掉管理，因为还有成本、延迟、噪声和 Lost in the Middle。

• 上下文该怎么管？
  考工程取舍：哪些信息常驻、哪些按需召回、快满时怎么摘要或外置，以及能不能从 trace 里看出 token 构成和质量有没有掉。

可直接抄走的 30 秒参考答案

上下文窗口就是模型一次调用能看到的 token 上限。对 Agent 来说，它特别关键，因为每一轮都会把系统提示词、用户目标、工具定义、历史轨迹、工具结果和任务状态塞进去，任务跑得越久，上下文就越容易膨胀。窗口满了会丢信息；窗口太长又会贵、慢，还可能出现 Lost in the Middle，关键信息明明在上下文里，模型却没抓住。所以生产 Agent 一定要做上下文管理，比如历史摘要、工具结果截断、动态工具加载、检索式记忆和结构化状态外置。

面试回答详解，知其所以然

这道题的核心不是“某个模型支持多少 token”，而是 Agent 每一步决策都受限于一个有限的信息预算。你要让模型看到足够的信息，但又不能把所有历史和工具结果都塞进去。

1. 上下文窗口是什么

上下文窗口是大模型一次调用中能处理的输入和输出总 token 上限。这里的 token 可以粗略理解为模型内部处理文本的单位，不完全等于中文字符或英文单词。

对普通 ChatBot 来说，窗口里主要是：

系统提示词 + 用户消息 + 少量历史 + 模型回复

对 Agent 来说，窗口明显更拥挤：

系统提示词 + 开发者约束 + 用户目标 + 工具定义 + 历史轨迹
  + 检索资料 + 工具结果 + 当前任务状态 + 错误反馈 + 输出预算

所以 Agent 的上下文窗口不是单纯的“聊天记录长度”，而是每一轮行动前的完整信息环境。

2. 为什么 Agent 更容易撞到上下文限制

Agent 是多轮执行系统，每一轮通常都会产生新的 action、tool call、observation、状态变化和中间结论。任务越长，上下文就越容易膨胀。

例如一个编程 Agent 做重构：

• 读取多个文件，文件内容进入上下文。
• 修改代码，diff 和设计理由进入上下文。
• 跑测试，测试输出和报错进入上下文。
• 修复失败，新的错误轨迹继续进入上下文。
• 用户追加要求，原始目标和新约束都要保留。

如果不管理，后面几轮模型看到的是一大团历史噪声。它可能忘掉最初目标，重复读同一个文件，把已修复的问题当成仍未修复，或者基于过期工具结果继续推理。

3. 它为什么是核心约束

上下文窗口同时约束质量、成本、延迟和可靠性。

• 质量约束：窗口有限，关键信息被截断或埋在中间，模型就会漏看、误判或答非所问。
• 成本约束：输入 token 越多，模型调用越贵。Agent 多轮循环会把这个成本放大。
• 延迟约束：长 prompt 需要更长 prefill 时间，首 token 延迟和端到端响应都会变慢。
• 调试约束：上下文里信息太杂，失败时很难判断是模型能力问题、资料缺失、历史污染还是工具结果被误读。

这也是为什么 Anthropic、LangChain 等都把 context engineering 单独拿出来讲：Agent 的表现往往取决于它每一轮看到的信息是否正确、足够、干净，而不是只取决于 prompt 写得漂不漂亮。

4. 长上下文不等于无限记忆

长上下文模型确实能缓解“塞不下”的问题，但不能消除上下文工程。

原因有三点：

• 第一，模型不一定均匀利用所有位置。Lost in the Middle 研究指出，相关信息放在开头或结尾时更容易被利用，放在长上下文中间时效果会明显变差。
• 第二，长上下文会带来更高成本和更长延迟。即使有 prompt caching，也只是优化重复前缀的成本和延迟，不代表可以无脑塞所有历史。
• 第三，噪声会干扰决策。上下文变大后，错误工具结果、过期约束、无关文档和重复历史也更容易混进来。

所以窗口变大只是给了更大的工作台，不代表不用整理桌面。生产 Agent 仍然要决定什么常驻、什么按需加载、什么压缩、什么删除。

5. 工程上怎么管理上下文

实战里可以按信息类型分层处理：

• 稳定指令：系统提示词、角色边界、安全规则放在开头，尽量保持稳定，便于缓存和复用。
• 当前目标：用户最新目标、当前步骤、验收条件放在靠近末尾的位置，降低被历史淹没的概率。
• 对话历史：保留最近关键轮次，较早历史压缩成摘要。
• 工具定义：不要一次性暴露所有工具，按任务阶段动态加载工具白名单。
• 工具结果：只保留必要字段和摘要，超长结果截断、分页或落盘。
• 检索资料：优先 rerank 后放少量高相关证据，而不是 top-K 越大越好。
• 任务状态：把“已完成、待办、阻塞、关键决策”抽成结构化 state，不依赖原始聊天历史。
• 长期记忆：跨会话信息放到外部存储，按需检索召回，并做过期、冲突和权限治理。

一个更稳的 Agent 循环通常是：

统计 token -> 选择上下文 -> 压缩或清理 -> 调用模型
  -> 执行工具 -> 写入结构化状态 -> 再进入下一轮

6. 判断好坏的标准不是“塞得多”，而是“信噪比高”

上下文管理的目标不是把窗口填满，而是让模型在当前这一步看到最该看的信息。

可以用几个问题判断上下文质量：

• 当前目标是不是清楚，并且离模型输出位置足够近？
• 必要证据是否在上下文里，而不是只存在外部文件或早期历史中？
• 工具定义是否刚好够用，还是把无关工具也塞进来了？
• 工具结果是否结构化、可读、可验证？
• 历史摘要是否保留了用户约束、关键决策和未完成事项？
• 是否记录了每次压缩、截断、召回和清理，方便复盘？

面试里能讲到这一步，基本就从“知道 token 有上限”上升到“懂 Agent 上下文工程”了。

面试官追问3个问题

追问一：实际项目中怎么监控 Agent 的上下文使用情况？到了上限怎么办？

• 考察点：是否能从工程监控而不是口头经验回答。
• 回答方向：每轮调用前做 token 计数，记录 system、tools、history、retrieval、memory、tool results 的 token 占比。达到阈值时触发压缩：先摘要早期历史，再截断或分页工具结果，再减少检索证据和工具定义。如果仍然超限，就把关键状态持久化，开启新 session 或 checkpoint 继续。

追问二：Lost in the Middle 有什么工程缓解办法？

• 考察点：是否知道位置偏置和 prompt 布局有关。
• 回答方向：把系统硬约束放开头，把当前目标、验收条件、最新状态放末尾；中间放摘要和低优先级历史。关键事实用结构化标签标出，检索证据先 rerank 再注入，长任务用 checkpoint 和外部 state 避免原始目标被历史淹没。

追问三：工具定义太多占 token 怎么优化？

• 考察点：是否理解 tool schema 也是上下文成本。
• 回答方向：做 tool registry 和动态工具白名单，当前阶段只暴露相关工具；精简 description，突出适用场景和互斥边界；相似工具可以按业务域合并，但不要合成过大的万能工具；也可以两阶段选择，先给工具名称和简述，选中后再加载完整 schema。

扩展知识

Context engineering 管的是整个信息环境

Prompt engineering 关注“这一句指令怎么写”，context engineering 关注“这一轮模型应该看到什么”。对 Agent 来说，context 可能来自很多地方：

system prompt + user goal + messages + tools + retrieval + memory + state + observations

Anthropic 在 context engineering 文章里强调，context 是 Agent 的有限资源。LangChain 也把 Agent 上下文策略概括为 write、select、compress、isolate：写入外部状态、选择相关信息、压缩历史、隔离子任务上下文。

面试里可以用一句话概括：上下文工程不是润色 prompt，而是在每一步帮模型搭一个干净、足够、便宜的信息环境。

Lost in the Middle 为什么重要

Lost in the Middle 指的是：长上下文里，模型对开头和结尾的信息往往更敏感，对中间位置的信息利用较差。Liu 等人的论文在多文档问答和 key-value retrieval 任务上展示了这种位置偏置。

这对 Agent 很致命，因为 Agent 的原始目标、早期约束或关键工具结果，很容易在多轮循环后落到上下文中间。信息还在，但模型像没看见一样。

工程缓解方式包括：

• 把最重要的目标、约束和当前状态放在末尾附近。
• 用结构化摘要保留早期关键决策。
• 对检索结果做 rerank，不把大量低相关 chunk 塞进窗口。
• 对长任务做 checkpoint，让任务状态外置，而不是依赖完整 history。
• 让关键事实有显式标签，例如“当前验收条件”“禁止事项”“未完成事项”。

为什么不能只等模型窗口变大

模型窗口变大当然有价值，尤其适合长文档、代码库、多文件分析和复杂检索。但对 Agent 来说，它只解决“能不能放下”，没有解决“该不该放、放哪里、怎么更新、怎么遗忘”。

就像桌子变大后可以摊更多资料，但如果没有分类、索引和清理，找东西还是会慢，错误材料也更容易混在里面。Agent 的上下文也是这样：窗口越大，越需要治理。

上下文窗口、记忆和 RAG 的关系

三者不是替代关系：

• 上下文窗口：模型这一轮实际能看到的工作区，容量有限，成本和延迟随长度增长。
• 记忆：把跨轮次或跨会话的重要信息保存到外部，再按需召回进入窗口。
• RAG：从外部知识库找证据，解决模型不知道或不该凭记忆回答的问题。
• 压缩：把长历史、长工具结果或长文档变成更短的高信噪比上下文。

可以这样理解：上下文窗口是模型当前工作台，记忆和 RAG 是外部资料库，压缩是整理资料的方式。Agent 工程的难点，是每一轮从资料库里挑对材料，整理后放到工作台上。