当前位置：首页 > news >正文

【agent第3篇】agent上下文+面经

news 2026/6/6 0:40:39

9.上下文工程

在之前的章节中，我们为智能体引入了记忆与工具能力。然而，要让Agent在真实复杂场景中稳定地“思考”与“行动”，仅有记忆与检索还不够——我们还需要一套系统化的工程方法，持续为模型构造恰当的上下文。这就是本章的主题：上下文工程（Context Engineering）。

到2026年，上下文工程已成为AI Agent开发中最受关注的技术领域之一。这份总结将基于当前最新的理论框架与工程实践，为你完整呈现这一领域的发展现状。

9.1 从Prompt到Context再到Harness

9.1.1 三层架构的演进

你可能会好奇：上下文工程和提示词工程有什么区别？

提示词工程关注的是如何表达任务（怎么把任务说清楚），而上下文工程关注的是模型工作时应该处于什么信息环境里（模型在做决策时能看到什么）。然而，随着Agent系统变得越来越复杂，单纯管理上下文也已不够用。到2026年，行业已经形成了清晰的三层架构认知：

层级	核心问题	典型技术	适用范围
Prompt Engineering	怎么把任务说清楚	结构化提示、思维链、角色设定	单轮、边界清晰的任务
Context Engineering	模型做决策时看到什么	RAG、记忆管理、动态检索、压缩	多步骤、长周期Agent任务
Harness Engineering	模型运行在什么样的系统里	状态机、权限控制、可观测性、审计	企业级、大规模多Agent系统

这三层不是替代关系，而是分层协作的——好的Agent系统需要在每一层都做对。正如Karpathy所比喻的：LLM就像一种新型操作系统，上下文窗口就是工作内存（RAM），上下文工程本质上是为这个操作系统构建完整的内存管理系统。

9.1.2 上下文工程的精确定义

上下文工程是在每次模型调用时，精心策划进入上下文窗口的全部信息内容的工程学科。它的核心问题只有一个：在有限的上下文窗口里，用最少的token、最高信号密度的信息，来最大化获得期望结果的概率。

Anthropic给出的定义是：当Agent朝向更长的时间跨度和多轮推理演进时，核心挑战变成了管理整个上下文状态，其中包括系统指令、工具、MCP服务器、外部数据和消息历史。

9.2 为什么上下文工程如此重要

9.2.1 上下文有边际收益递减

这是生产环境中Agent失败的最隐蔽原因——模型在长上下文中表现会显著下降。

研究发现，当前模型的有效上下文利用率通常只有50%-65%，从4K到128K的上下文中，大多数模型会损失15%-30%的准确率。Llama 3.1-70B在4K时准确率96.5%，到128K时降至66.6%——这是接近30%的性能滑坡。

这种现象被称为上下文腐蚀。造成腐蚀的原因主要有三个：U形注意力曲线（Lost in the Middle）——模型对上下文中间位置信息的关注度远低于两端；长度诱导的性能崩溃——2025年的研究证实，即使强迫模型只看需要的信息（把无关内容全部遮掉），性能还是会下滑13.9%到85%；以及任务类型导致的利用率差异——检索任务利用率高，推理任务中等，聚合任务最低。

对工程实践的启示：更大的上下文窗口并不能解决腐蚀问题，甚至可能让问题更糟。因此，不要假设模型能有效利用你给它的全部信息，必须有意识地管理。

9.2.2 注意力是有限资源

上下文工程的稀缺性源于Transformer的架构约束——每个token与上下文中的所有token建立注意力关系，形成n²级别的两两注意力矩阵。随着上下文增长，注意力预算被“拉薄”。模型在训练时接触的短序列远多于长序列，因此缺乏对长上下文依赖的经验。

正如Anthropic所指出的，优秀的Agent与普通Agent的差距，往往不是因为原始请求的措辞，而是取决于关键信号是否在正确时刻出现在上下文窗口内。

9.3 上下文工程的四大核心策略

在生产环境中，优秀的上下文工程实践围绕四个核心策略展开：信息卸载、压缩整合、按需检索与渐进式披露、注意力操纵。

策略一：信息卸载

信息卸载是最基础也最被低估的策略——不要把大量信息都放在上下文窗口里，而是把它们卸载到外部存储。

Manus的经验：Manus团队是这方面的先行者。他们将工具输出（如网络搜索结果）直接写入沙箱文件系统，而不是保留在消息历史中，Agent只获得必要的简短信息（如文件路径），在需要时再引用完整上下文。这样既大幅减少了上下文消耗，又做到了无损保留。

文件系统本身就是结构化记忆——Agent学会按需读写文件，记忆大小不受限制，本质上持久存在。Manus采用分层动作空间：Level 1用函数调用处理原子操作，Level 2用语言命令处理复杂任务。KV缓存命中率是Manus团队最重要的生产指标——在典型Agent工作流中，输入与输出token比例高达100:1，缓存命中率直接影响成本和延迟。

策略二：压缩整合

压缩是把长历史对话“高保真”总结，用一个摘要替代原始冗长历史，以维持长程连贯性。

实践经验：先优化召回（确保不遗漏关键信息），再优化精确度；一种安全的“轻触式”压缩是对“深历史中的工具调用和结果”进行精简。业界已有技术如CompactPrompt——将硬提示压缩与轻量级文件级压缩融合，实现端到端压缩。OpenAI最新模型引入的“压缩”机制，允许智能保留关键信息并丢弃无关细节。

策略三：按需检索与渐进式披露

Agent不需要一次性加载所有信息，而是维护轻量化引用（文件路径、存储查询），在运行时按需动态加载所需数据。

文件系统即上下文：不再需要为所有内容提前建立向量索引。Agent直接用命令行工具（grep、find、cat）进行即时探索——查看日志文件几行、搜索代码中的某个模式、快速了解目录结构。

渐进式披露：每步交互产生新的上下文，反过来指导下一步决策——文件大小暗示复杂度，命名暗示用途，时间戳暗示相关性，Agent得以构建分层理解，只在工作记忆中保留“当前必要子集”。

策略四：注意力操纵

KV缓存管理：生产Agent指标中KV缓存命中率最重要——直接决定延迟和成本。在Manus，平均输入输出token比例约为100:1，预填充远大于解码，缓存优化是最直接的杠杆。

待办事项操控注意力：将关键任务以清单形式置于上下文开头或结尾——“中间”易被遗忘，“两端”更受关注。

保留错误信息：让Agent从失败中学习，而不是简单丢弃错误记录。

9.4 上下文工程的三大前沿演进

如果你想让自己的系统具备更高级的上下文管理能力，以下是2026年最值得关注的方向。

9.4.1 Agentic Context Engineering (ACE)

ACE是斯坦福大学、SambaNova Systems与UC Berkeley的联合研究（ICLR 2026收录），将上下文视为一个可以不断演化、反思和优化的“操作手册”。

ACE的核心贡献是将知识表示为带元数据的结构化条目（标识符、有用性计数），每次更新时应用增量增量更新。在评估中，ACE相比强基线在Agent任务上提升+10.6%，在金融任务上提升+8.6%，显著减少了适应延迟和Rollout成本。一个值得关注的成就是：ACE用一个更小的开源模型（DeepSeek）在AppWorld上匹配了顶级生产的GPT-4.1 Agent性能。

9.4.2 Meta Context Engineering (MCE)

MCE是同一团队提出的配套框架，旨在自动发现并优化那些超越人类直觉的策略——用AI来优化AI的上下文。其核心通过双层优化架构，解耦上下文工程策略与被优化的上下文工件，实现两者共同演化，并利用LLM自身的语言先验优势进行策略发现。

9.4.3 Harness Engineering

Harness Engineering是2026年的新主线——它关注的是为Agent建立一个系统级的“控制框架”，通过状态机、权限系统、验证与可观测性等机制，在拥抱不确定性的同时建立安全与可控边界。

Harness的核心组件包括状态持久化（将中间结果存储至外部数据库而非全部保留在上下文窗口），工具调用隔离与权限控制（执行沙箱，白名单机制），人机协作路由（关键节点设置人工确认），以及全面的可观测性（日志、追踪、评估指标）。

9.5 总结与展望

本章的核心框架可概括为一个金字塔模型：

基座——策略执行：信息卸载、压缩整合、按需检索、注意力操纵
中台——系统能力：KV缓存、文件系统即记忆、分层动作空间、人机协作
顶层——自主演进：Agentic CE（自我优化的上下文） + Meta CE（自动发现策略）

最后的建议：上下文工程是一门“实验科学”。Manus创始人季逸超有句名言——通过大量试错来寻找局部最优解，团队亲切地称之为“随机梯度下降”。这揭示了上下文工程的实践本质：它需要持续的测量、分析和迭代，而不是一劳永逸的配置。

一、基础认知篇

Q1：Prompt Engineering 和 Context Engineering 的核心区别是什么？

这是Agent面试的必考入口题，面试官想听的是视野升级。

维度	Prompt Engineering	Context Engineering
关注点	怎么把一句话写得更好	系统层面怎么组织输入环境
生命周期	单次请求	会话级/跨会话管理
核心手段	系统提示词优化、Few-shot	RAG、记忆管理、动态检索
回答信号	“我仔细拆解了你的问题”	“我在合适的时候给了模型正确的信息”

可理解为“微观调词”与“宏观信息架构”的升级。

Q2：Agent 为什么离不开 Context Engineering？

面试官不是要你背诵定义，而是看你有没有工程落地的真实体感。

满分回答：Agent的核心是放在LLM外面的一整套控制回路。上下文决定模型在决策时能看到什么——上下文质量不对，模型看到的信息要么缺失、要么混乱、要么过载，后面所有推理都会出问题。

在真实生产环境里，上下文工程要解决四个核心问题：

工程问题	产生原因	上下文工程的应对
上下文腐蚀	token增加后模型准确回忆信息的能力下降	通过压缩整合（Compaction）和摘要缓冲保持高信号密度
Lost in the Middle	模型对上下文中间位置信息的关注度显著低于两端	关键信息放在开头或结尾（注意力操纵）
上下文溢出	长对话累积超窗口限制	信息分层和按需检索
信号稀释	大量低质量信息混入上下文	基于相关性和新近性的智能筛选

二、上下文管理策略篇

Q3：上下文窗口不够用了怎么办？

字节面试高频题，面试官想听的是你有分层策略意识。

四个层次的处理方案：

策略	实现方式	适用场景	成本
滑动窗口	保留最近N轮，最早的消息直接截断	聊天机器人、快速问答	Token低
对话摘要	LLM将早期对话压缩成摘要	客服、研究助理	LLM调用增加
Token缓冲区	按token精确截断而非消息条数	精细控制预算的场景	复杂度高
按重要性丢弃	LLM评估每条消息的重要性，只保留重要信息	优先级分明的任务	依赖评估质量

生产环境里的推荐做法是分层结合：工作记忆只持有当前会话的高频数据，会话摘要缓冲滚动压缩，长期记忆按需向量检索。

附加追问：“如果只做滑动窗口，早期重要的系统指令被截断了怎么办？”

参考答案：把系统指令放在context的开头，利用模型对开头位置的高注意力来保护。这也是Manus团队采用的思路：将关键上下文标记为“高保留优先级”，在截断时优先保留。

Q4：上下文工程的 GSSC 四阶段是什么？

Gather-Select-Structure-Compress 是工业界公认的四阶段流水线。

阶段	操作	核心价值	工程挑战
Gather	汇集候选信息	确保信息覆盖度	多来源去重、质量过滤
Select	基于相关性和新近性评分	在预算内选择最相关信息	评分权重的调优、相关性计算
Structure	分区输出信息	提升模型理解和可调试性	分区逻辑设计
Compress	超限时压缩兜底	确保系统稳定运行	压缩质量与信息完整性平衡

评分公式的核心：combined_score = relevance_weight × relevance_score + recency_weight × recency_score，其中relevance_weight + recency_weight = 1.0，常见配置是relevance_weight = 0.7，recency_weight = 0.3。公式背后的工程逻辑是：在有限token预算内选择综合得分最高的信息。

面试官追问：“这4个阶段如果某个阶段失效了，会对最终模型表现产生什么影响？”

参考答案：Gather失效→信息缺失，无法回答；Select失效→选择无关信息淹没关键信号，影响推理；Structure失效→模型难以定位关键信息；Compress失效→token超限，API调用失败。

Q5：Context Window 越长越好吗？

❌ 不是。面试官想听你暴露对实际性能表征的理解。

三个核心局限：

上下文腐蚀：即使支持长窗口，模型从长上下文中准确检索信息的能力也会下降。有效利用率通常只有50-65%
注意力预算被稀释：Transformer架构下，每个token与上下文中的所有token形成注意力关系，随着上下文增长，注意力被“拉薄”
位置编码插值的精度损失：训练时处理的是短序列，推理时长上下文需位置编码插值，会牺牲部分位置精度

参考数据：Llama 3.1-70B在4K时准确率96.5%，到128K时降至66.6%，性能下降接近30%。

Q6：什么是“Lost in the Middle”现象？

简洁回答：LLM对上下文中间位置的信息关注度显著低于开头和结尾。这会导致两类问题：关键信息放中间可能被忽略；上下文中间的内容检索准确率下降10-20%。

工程启示：将有价值的信息尽量放在上下文窗口的开头或结尾。Manus团队正是利用了这一点优化KV缓存命中率。

Q7：上下文压缩是怎么做的？

答案分三个层次：

层次	策略	适用场景
轻触式	清理深历史中工具调用和输出	常规长对话
摘要式	将早期对话压缩为高保真摘要	多步任务长时运行
结构压缩	利用分区结构保留核心信息	分区上下文结构明确的场景

高级策略：当对话接近上下文上限时，对其进行高保真总结，用摘要替代原始历史。先优化召回再优化精确度，确保不遗漏关键信息。

Q8：长上下文窗口下，模型不会自己“记住”内容吗？

Agent开发岗的灵魂拷问。面试官想听你具备工程现实感，能讲出“为什么长上下文不是万能药”。

参考答案：长上下文窗口并不等同于模型能有效利用。原因有三：

上下文腐蚀：即使支持长窗口，模型从长上下文中准确检索信息的能力也会下降
注意力是有限资源：上下文窗口越大，注意力预算越被稀释
训练分布偏差：模型在训练时接触的短序列远多于长序列
“Lost in the Middle”：模型对上下文中间位置信息的关注度显著低于两端

更关键的一层：即便未来上下文再扩展，信息组织、筛选、压缩的策略也不会消失。因为信息不是“能塞进去就行”，而是要确保“模型能在正确的时候看到正确的信息”。上下文工程不是模型能力的临时补丁，而是信息架构的长期职能。

三、记忆分层设计篇

Q9：Agent的记忆一般怎么设计？

阿里淘天必考题，面试官最期待听到的关键词是“分层”。

标准答案：

工作记忆 (Working Memory)：当前对话的状态和关键结论，存在context window里，进程内存储，毫秒级延迟，容量受限
会话记忆 (Summary Buffer)：摘要滚动，跨会话语义压缩，分钟级到小时级
长期记忆 (External Memory)：向量检索/结构化库存储历史信息，持久化存储，按需查询，支持语义检索

四层记忆模型（进阶版）：感知记忆（Sensory）→ 短期记忆（Working）→ 长期记忆（External）→ 实体记忆（Entity）。面试官追问时一定要能展开“存什么、怎么存、何时取”这三大核心问题。

Q10：短期记忆和长期记忆的区别？分别怎么存储？

维度	短期记忆（Working Memory）	长期记忆（External Memory）
生命周期	当前会话	跨会话持久化
存储介质	Context Window	向量数据库/图数据库/关系数据库
访问模式	即时读取	按需语义检索
容量	有限（token限制）	可扩展（GB-TB级）
核心技术	进程内存储 + TTL	向量化 + 相似度搜索

两层结构是数据规模和访问频率的自然分层——高频、短时数据留在内存，低频、长时数据外存。

Q11：工作记忆只存“当前任务的上下文信息”——怎么做到的？

腾讯高频题。面试官想验证你是否亲手调过生产级Agent。

参考答案：工作记忆的维护采用分层策略：

进程内状态容器：存储会话运行时状态（当前任务阶段、已确认偏好、工具调用中间结果）
接收当前用户输入、持有最近N轮对话历史（注意：不是所有历史）
内存生命周期管理：用TTL机制实现过期自动清理

关键设计：工作记忆的核心职责只有三个——接收输入、持有最近N轮对话、维护会话运行时状态。不要把它当成“万能容器”，把所有用户偏好和知识都往里塞。正确做法是工作记忆只持有当前会话窗口内高频访问的数据。

面试官追问示例：“用户注册信息（姓名、偏好、等级）是存在工作记忆还是长期记忆？为什么？”

参考答案：长期记忆。工作记忆会在会话结束后清空，用户的身份信息属于需要跨会话保留的陈述性知识，应写入长期记忆。

Q12：多用户场景下，如何实现记忆隔离？（阿里淘天一面真题）

这道题本质是在考你有没有在脑子里构建过一套完整的状态管理世界观。

工程答案：

session_id统一管理：每个用户独立的session_id，写入记忆时带上元数据（user_id、session_id、timestamp）
存储设计：结构化数据库加user_id字段过滤；向量数据库用metadata过滤；键值存储用命名空间隔离
检索时用过滤条件确保只命中当前用户数据
多租户架构：schema隔离 vs 数据库隔离，按业务规模和合规需求选择

四、工程优化与安全

Q13：KV缓存命中率为什么是生产Agent最重要的指标？

Manus团队核心经验。参考答案：在典型Agent工作流中，输入输出token比例约为100:1，预填充远大于解码。KV缓存命中率直接影响成本和延迟——命中率高意味着复用之前计算过的键值对，重复使用计算结果，大幅降低成本和延迟。

衡量一个Agent系统是否成熟，看它对KV缓存命中率的重视程度就足够了。从系统优化的视角看，KV缓存命中率是这些优化中最立竿见影的指标。无状态的Agent调用天然是KV cache友好的。

Q14：工具数量超过50个，怎么防止工具描述爆炸？

这是Pinterest、Uber等大厂真实的工程经验。高分回答：三层防御 + 渐进式工具发现。

策略	具体做法	效果
渐进式工具发现	当工具描述可能超过上下文10%时自动延迟加载	Token降低约85%
领域特定服务器	将工具按领域拆分隔离，避免所有工具定义全部挤进上下文	控制上下文膨胀
工具数量掩码	根据查询类型动态过滤可用工具列表	避免工具选择混乱

Claude Code的基准测试结果显示，token使用量大约降低了85%。

Q15：上下文爆炸怎么预防？

参考答案：

分层架构：Working Memory + Summary Buffer + External Memory三层记忆体系，信息按生命周期分层存储
容量上限 + 优先级策略：关键信息（如用户问题、系统指令、Agent身份）分配高优先级token预算，低价值信息先淘汰
定期压缩整合：当对话接近上限时对历史进行高保真总结
主动检索：长期记忆按需查询，而不是被动加载

Q16：长时程任务（跨会话、需几小时甚至几天）的上下文怎么管理？

参考答案：需要三大核心策略协同：

压缩整合：定期对累积对话进行高保真总结，用摘要替换原始历史
结构化笔记：将关键信息（任务阶段、结论、阻塞点、行动项）写入外部文件持久化保存
子代理架构：主代理高层规划，各专业子代理独立上下文窗口深挖，仅回传凝练摘要

面试官追问：“生产环境里，结构化笔记通常用什么格式？”

参考答案：Markdown + YAML前置元数据。YAML便于机器提取结构化信息，Markdown正文方便人类阅读和手动编辑，纯文本天然支持Git版本控制，这是工业界最佳实践。

Q17：如何防止Agent忘记重要的跨会话信息？

参考答案：

写入长时记忆时设置importance阈值，核心信息自动存储
引入“记忆整合”机制，重要性超过阈值（如0.7）的工作记忆自动转入情景记忆或长期记忆
设计定期回顾机制，让Agent在对话开始时主动加载用户的关键记忆（如偏好、上次对话结论）
结合向量检索语义召回，确保相关信息能在需要时被主动发现

Q18：上下文质量怎么评估？在生产中怎么衡量？

参考答案：从五个维度构建评估体系：

评估维度	衡量方法	健康标准
相关性	检索top-k文档与问题的语义相似度分布	avg相似度>0.6
充分性	答案所需信息是否均在上下文中覆盖	盲测覆盖率>90%
经济性	每任务平均token消耗	基线vs优化版本对比
新鲜度	上下文信息的时效性	关键信息更新时间
可溯源	是否能追溯到信息来源	每条证据都能溯源

Q19：多源上下文冲突（如记忆和RAG同时查到矛盾信息），怎么解决？

参考答案：三阶段处理：

冲突检测阶段：LLM识别矛盾信息，标注置信度和来源，低置信度标记待解决
消歧决策阶段：采用分层仲裁——自动条件（时间戳、来源权威性、重要性）用规则；LLM判断（语义分析后决策）；人工干预（高风险场景）需反馈
记录与修复阶段：冲突记录到记忆，优化信息来源

五、RAG与HyDE/MQE深度篇

Q20：RAG核心流程是什么？

数据准备（文档接入、清洗切分、向量化、索引构建） + 在线查询（查询理解、检索召回、rerank、上下文构造、大模型生成、答案校验），线上还需补充权限过滤和可观测。分块策略、向量维度一致性、检索质量这些点经常被追问。

Q21：RAG到底解决了什么问题？

参考答案：RAG通过检索+生成双引擎架构解决LLM的三大知识缺陷：

知识时效性：训练数据有截止期 → RAG可实时访问最新文档
私有数据无法触达：企业内部数据不在训练集中 → RAG通过向量化安全访问
容易幻觉：模型无依据瞎编 → RAG让LLM基于检索的事实回答

Q22：纯向量检索有什么问题？

向量检索语义理解强但精确词匹配弱（搜“K8s HPA配置”可能找到“Kubernetes自动扩能算法”，语义相关但没具体内容）。BM25正好相反：精确匹配强、速度快，但语义理解弱。

混合检索：两路结果合并取长补短，通过RRF公式融合排序：RRF_score(d) = Σ 1/(k + rank_i(d))

Q23：RAG的幻觉怎么处理？

四层防御体系：

检索兜底：低相似度自动拒答
生成约束：强制LLM引用检索内容，标注置信度
事后验证：Self-RAG——LLM在生成答案时对每个句子自我评估（是否基于检索内容？是否有事实错误？）
多源交叉验证：多路检索相互印证

Q24：MQE 和 HyDE 分别是做什么的？有什么区别？

这是资深RAG开发者的必修题。面试官想考察你对召回率优化策略的理解深度：

维度	MQE（多查询扩展）	HyDE（假设文档嵌入）
核心思想	生成多样化表达	用“答案”找“答案”
做法	用LLM生成n个不同表述的查询（如“如何学Python”→“Python入门教程”“Python学习方法”），并行检索合并去重	先让LLM生成假设性答案段落，用此段落向量去检索真实文档
适用场景	用词多样性差异大的查询	查询与文档在语义空间分布存在偏移的场景
成本	n次检索 + 1次LLM调用	1次LLM生成 + 1次检索