上下文组织与注入
2 道题目查看参考回答收起参考回答
上下文工程，是在每次调用模型前，选择、组织并维护当前任务所需的信息，让模型在有限窗口内有足够依据完成下一步。它覆盖信息如何取得、何时进入上下文、怎样更新，以及过长时如何裁剪和恢复细节。
它主要解决四类问题：缺少关键资料，模型无从判断；历史和工具结果不断累积，导致超限、成本和延迟增加；无关、过期或冲突信息干扰当前判断；长任务跨窗口后丢掉目标、约束和进度。
例如研究任务已经检索了很多网页，下一步写结论需要的是当前目标、有效证据和未解决的问题，不需要把每次搜索的完整返回都重新发送。上下文工程要做到既能收敛输入，又能在需要时找回证据，而不是单纯把文本压得越短越好。
来源 · 6 篇面经 · 16 份题集收起来源
【上下文工程概念与实践】上下文工程是什么？核心问题有哪些？做上下文工程最关键的工作是什么？ 「字节跳动、美团、蚂蚁集团」
Context Engineering
面试问题：上下文信息如何支撑多步任务？
面试问题：Context Engine 的 ingest / assemble / compact / after-turn 生命周期如何理解？
面试问题：Context Engine 的 assemble / compact / retrieve 如何协同？
面试追问：上下文工程具体要做哪些事？为什么不能把所有历史信息直接交给模型？
讲一下上下文工程（Context Engineering），Agent 的记忆（Memory）是怎么做的？
上下文有哪些部分组成，怎么做上下文工程，如何防止上下文爆炸，压缩之后上下文缩小了多少
22. 上下文怎么做的？你是拆分的嘛？
什么是上下文工程（Context Engineering）？
Context Engineering 要解决哪些问题？
Context Engineering 为什么变重要
CLI 和 IDE 的核心差异是什么？为什么长任务更依赖上下文管理？
Agent 的上下文工程怎么设计？
做上下文工程最关键的工作是什么？
Context Engine 的 assemble() 方法为什么重要？
查看参考回答收起参考回答
Agent 的上下文，是当前这次模型调用能够看到、用于判断下一步的信息。它通常有五类：
- 指令与当前任务：角色、行为边界、输出要求，以及用户本次要完成的目标和已确认条件。
- 相关对话历史：必要的用户消息、助手回复和工具交互，帮助理解指代、修改和连续任务。
- 工具与输出契约：当前可用工具的名称、用途、参数 Schema，以及需要时的结构化输出格式和示例。
- 外部证据：检索片段、文件内容、工具结果等，附上必要的来源、版本或时间。
- 记忆与任务状态：与本轮有关的偏好、已确认事实、计划、已完成步骤和待解决问题。
组织时先按当前任务筛选，再按来源和职责分块，保持消息角色及工具调用与结果的关联。注入时由宿主把这些内容适配成模型支持的消息、工具定义和输出格式；数据库里保存过的信息不一定全部进入本轮上下文。每轮调用前还要检查 Token 预算，为回答和后续工具反馈留出空间。
来源 · 6 篇面经 · 7 份题集收起来源
Claude Code 的 System Prompt 组装和普通"写一个 prompt"有什么本质区别？
【Skill分层与数据流】谈谈你对 skill 的理解，分层怎么做的？整个数据流写在哪儿？怎么读？读取策略？读之后加在哪儿？用什么方式实现？是通过启动一个线程的方式还是？具体怎么读写存？ 「字节Seed」
【上下文管理结构】上下文怎么管理？上下文结构是不是：SystemPrompt + Memory + Tools Result + Conversation？ 「美团」
静态规则、动态信息、工具结果、记忆应该如何进入上下文？
它具体管哪些东西
窗口里有哪些开销
Agent 的上下文管理和记忆机制通常如何设计，如何避免上下文过长或信息污染？
压缩策略与信息保留
3 道题目查看参考回答收起参考回答
控制上下文要区分完整历史的存储和本轮模型的输入。历史保存在 Redis 或检查点里，不代表模型会自动读到；本轮不发送旧消息，也不必删除原始记录。调用前应统计指令、工具定义、历史和工具结果的 token 占用，按模型窗口预留输出空间，在超限前处理长输入。
再按信息的后续用途选择策略：
- 保留原文：近期讨论、最新更正，以及需要精确引用的内容。
- 直接裁剪：已经结束、与当前任务无关的过程。
- 抽取或摘要：把当前目标、仍生效的约束、已确认进度和待核验事项整理成简短状态。
- 外置并按需取回：长网页、报告和旧材料放在外部存储，需要时再读取相关原文。
例如报告范围从“上半年”改成“第二季度”，摘要要保留新范围和原有的来源要求。取舍是否合理，要用多轮任务检查约束、更正和关键事实有没有丢；质量达标后，再比较 token、耗时与成本。
下面用一个 32,000 token 的预算例子，把“保留、裁剪、摘要、外置”四种处理方式放在一起比较。报告范围发生更正时，也要把新约束带入下一轮。
来源 · 67 篇面经 · 1 篇面经合集 · 36 份题集收起来源
如何处理 Agent 的长对话场景（> 10 轮）？
长对话上下文如何处理？总结后如何存储？多少轮后不支持回溯？
什么时候使用 /compact vs /clear？
上下文太长怎么办？
解决tokens不够的问题应该怎么办
【工具调用容错与上下文管理】如果Agent在多步推理过程中某一步调用工具失败，你如何设计容错和回滚机制，同时不让上下文窗口膨胀失控？ 「字节跳动」
【长上下文处理方法】长上下文是LLM的研究热点，当输入超过模型上下文长度时，有哪些方法可以解决或缓解长上下文问题？请列举长上下文压缩等方法。 「美团、腾讯、阿里巴巴」
【上下文截断策略】对长度做截断，为什么考虑这个截断长度？ 「美团」
【上下文不足】有对单条assistant做压缩吗？ 「腾讯」
【长序列处理】推理时若将大量Memory以Token形式给到大模型，Token长度过长该如何处理？ 「百度」
How does context compaction work?
Your chatbot loses context after 10 turns in a conversation. How do you maintain a long conversation context?
How do you handle long contexts efficiently in production (context compression, prefix caching)?
面试问题：上下文窗口溢出时如何处理？
面试问题：滑动窗口、摘要压缩、语义压缩如何对比？
面试追问：滑动窗口和增量摘要怎么配合，避免上下文越来越长？
2. Agent上下文超限了怎么处理？
6.1 持续对话导致上下文变长时如何处理
3.2 哪些场景适合滑动窗口，哪些场景更适合直接通过摘要进行上下文压缩？
13.了解上下文管理吗？
7. 假设已进行 10 轮并做了总结，第 11 轮开始时，总结怎么处理？是重算前 11 轮还是叠加？
9. 对话超过上下文限制后怎么处理？滑动窗口、摘要压缩和向量召回怎么选择？
生成层怎么做的，检索的上下文太长怎么办
面试问题：长上下文、chunking 和 token budget 如何用窗口思想理解？
面试问题：多轮对话中的 RAG 为什么更复杂？如何保持上下文连贯性？
如果用户跟模型对话轮次过多，超出了模型的上下文限制，但我们又希望尽可能保留用户的对话信息，该怎么办？
Token 和上下文窗口是什么？它们在工程上意味着什么？
长上下文压缩有哪些方案？
客服机器人历史会话持续增长时，如何分配 Token 预算并保留关键业务状态？
记忆太多放不下上下文窗口怎么办？
如何避免上下文过长导致模型性能下降？
什么是 Memory？短期记忆在对话轮次增加时如何持续处理上下文爆炸和重复压缩？
3.8 在BERT应用中，如何解决长文本问题？
10.如何让大模型处理更长的文本？
已进行 10 轮并做了总结，第 11 轮开始时，总结怎么处理？是重算前 11 轮还是叠加？
上下文溢出怎么处理？
查看参考回答收起参考回答
压缩时的重要性，应按信息丢失会不会改变当前任务的判断或下一步动作来评估，再结合有效时间、依赖关系和能否回查决定保留形式，不能只按“用户消息比助手消息重要”或“越近越重要”排序。
优先保留四类信息：当前有效目标和硬性条件；影响决策的已确认事实及原始证据；已完成、待执行、待确认等任务状态；尚未解决的问题、关键更正和后续步骤的依赖。金额、日期、对象 ID、否定词和适用条件，往往需要保留精确值。
重复解释、无关闲聊和已被消化的大段日志可以先精简。对仍可能有用的细节，可以保留摘要与可回查引用，而不是全部塞在窗口里。压缩后要检查关键事实是否完整、状态是否正确，并用跨窗口追问和任务继续执行验证；压缩率只能说明变短了，不能说明信息保留得好。
来源 · 6 篇面经 · 3 份题集收起来源
面试问题：选择性保留和内容裁剪适合哪些场景？
当上下文窗口不足时，如何选择保留哪些信息？
上下文预算不足时，如何按任务依赖压缩，而不是按时间删除旧消息？
查看参考回答收起参考回答
摘要是有损表示，降低损失的关键是：把任务必需的信息明确保留，把精确材料留在可回查的位置，并验证压缩后能否继续正确完成任务，不能只要求模型“总结得完整”。
- 关键状态与自由摘要分开：当前目标、有效约束、准确标识、未完成项和已发生的业务动作单独记录；数字、单位、否定条件及技术版本按需要保留原文。
- 摘要保留出处：长日志和工具结果可以概括，但保存原始版本、消息或片段标识，需要细节时能取回对应内容。
- 先保证必要信息召回，再提高压缩率：按后续任务决定哪些内容不能丢，特别检查低频技术细节、用户更正和不确定结论。
- 压缩后校验并可恢复：核对必需字段和约束，用多轮任务回放检查行为；发现遗漏时回读原文、补齐或回退摘要，不能凭摘要继续猜。
压缩率只是成本指标。摘要缩短很多，但把“只诊断，不重启”改成“排查并修复”，就已经改变了任务。
来源 · 12 篇面经 · 13 份题集收起来源
【Prompt优化与压缩】如何根据模型输出优化提示词？是否使用embedding表示或相似度检索来优化Prompt？是否尝试过Prompt压缩或embedding表示的方式？ 「美团、阿里巴巴」
11. 上下文压缩保留什么信息？如何判断哪些内容可以丢弃？
压缩或者摘要肯定会丢失信息，如何使得这个信息丢失最小化？
11. 上下文压缩时，你怎么做信息丢失的评估？——用模型打分还是规则？如果压缩丢了关键信息导致 Agent 后面决策错误，你能检测到吗？怎么恢复？
8.在Agent开发过程中，上下文为什么需要进行压缩？压缩后可能导致信息缺失，应该如何解决？
8. 如果前 10 轮都变成了总结，那之前的原始上下文就不需要了吗？
11.为什么压缩前 70%？最开始的几轮对话明确需求不是很重要吗？
如果想要优化上下文压缩，觉得是前面前置轮次更重要还是后置轮次更重要？
长上下文场景下如何做摘要压缩，既控制上下文长度又尽量避免关键信息丢失和语义扭曲？
AI 编程的上下文越来越长时，如何保留关键信息？
摘要总结往往会丢失关键细节，在长文本 Agent 中一般怎么来处理这一块？
上下文压缩在循环过程中导致之前的流程丢失，怎么解决？
压缩摘要的弊端是什么？怎么缓解？
长期记忆写入与召回
4 道题目查看参考回答收起参考回答
Agent 的记忆要围绕写入、使用和维护管理。先区分当前会话的短期状态与跨会话保留的长期信息：前者保存任务进度、消息和工具结果，后者选择性保存以后仍有价值的用户偏好、事实或经验。
写入时判断信息是否值得长期保留，并记录来源、时间和适用范围；使用时先按用户、项目等范围筛选，再检索与当前任务相关的记忆，控制进入上下文的内容；维护时处理纠错、冲突、过期、去重和删除。最后用多轮任务验证能否记对、用对、改对、忘掉，而不只检查“数据是否存进了向量库”。
例如用户平时要求中文报告，这可以成为长期偏好；本次临时要求英文，应覆盖当前任务的输出语言，但不应直接改掉长期偏好。
来源 · 41 篇面经 · 27 份题集收起来源
设计一个 Memory 管理系统（长期记忆）
Agent Memory 设计方案？（必考）
如何设计 Agent 的长期记忆机制？
你是怎么设计agent的记忆系统?
Memory 系统如何实现？（Mem0/Zep）
如果你在 KTClaw 里做过四层，在小红书面向上亿用户，最需要改什么？
你的四层记忆 + MORPHEUS + 程序性记忆 + Dreaming 怎么串成一条主线？
【Agent记忆与规划模块】针对你的 Agent 项目：记忆模块和规划模块是怎么设计的？ 「阿里巴巴」
【Mem0记忆系统】Mem0记忆系统的实现细节是什么？ 「美团」
【Memory模块设计】Memory模块怎么设计的，为什么这样设计？ 「腾讯混元」
Design a conversational AI system with memory across sessions.
面试问题：如何设计一个可长期运行的个人助理记忆系统？
10. 记忆模块是怎么设计的？
6. 长上下文与记忆管理
讲一下上下文工程（Context Engineering），Agent 的记忆（Memory）是怎么做的？
3.项目提问：它的记忆管理是如何做的？
23. Agent开发中，知识维护、记忆模块（短期/长期记忆）你是怎么考虑设计的？
有无搭建过完整的 agent，memory 管理怎么做的
4. 项目里LangChain做了哪些工具调用，有没有实现memory相关功能，还是只做prompt编排？
一个 Agent 应该如何设计？它通常由哪些核心组件构成？
Agent 记忆系统要解决哪些核心问题？
如何用 Markdown 存储 Agent 记忆？
如何做一套轻量级记忆系统
Agent 的上下文管理和记忆机制通常如何设计，如何避免上下文过长或信息污染？
请你介绍一下 AI Agent 的记忆机制，并说明在实际开发中应该如何设计记忆模块？
Work Memory 如何设计与更新？为什么能提升 Agent 的任务执行效果？
Memory 怎么做
查看参考回答收起参考回答
Agent 的分层记忆，应按信息服务什么范围、保留多久、何时读写来设计，再从存储中选出本轮模型需要的内容。一种实用组织方式是：
- 近期对话：保留当前会话最近的原始消息，延续指代、追问和用户更正；较早过程可以摘要或按需回查。
- 当前任务状态与摘要：明确保存目标、约束、已确认参数、进度和待办，避免模型每轮从聊天中重新猜测。关键事实用结构化字段，摘要补充经过与背景。它与近期对话都服务当前任务，通常属于短期信息。
- 跨会话长期记忆：保存后续仍有用的偏好、项目事实、历史决策和经过验证的经验，按用户、组织和项目限定作用域，需要时再检索。
这不是统一的“三层标准”，也不要求三套数据库。重点是把保存的信息与本轮上下文分开：Redis 或检查点负责保存，读取、筛选和注入才让模型实际用到。写入前判断价值与依据，读取时检查权限、有效期和相关性，并控制预算；发生更正、过期或删除时同步维护。
例如长期默认是“华北、按周”，本次用户要求“华南、按月”，当前任务采用新参数，长期默认暂时不变；只有用户明确改变默认，才更新相应的长期条目。
来源 · 27 篇面经 · 17 份题集收起来源
Memory 是 Agent 的一个关键模块。请问如何为 Agent 设计短期记忆和长期记忆系统？可以借助哪些外部工具或技术？
【开源Agent记忆结构】你怎么看现在一些开源Agent的记忆结构？ 「阿里巴巴」
长上下文处理方法：包括上下文窗口溢出、存储大量交互信息、长度扩展策略（如DeepSeek、Llama方案）、KV Cache污染与隔离、输入长度理论限制、长文本折中方案（摘要/分段/滑窗/关键信息抽取）、上下文机制实现、上下文超长压缩（如超过30%需压缩）、长度外推（RoPE、ALiBi、NTK Scaling、YaRN）、10k长序列建模（注意力优化、位置编码优化）、chunk问题及解决办法。另包括轻量化方案（除摘要精简外）、深度搜索框架（如DeepSeek 100k token）、MemGPT动机、解决长序列策略、截断导致语义丢失的替代方案、长期与短期记忆处理及长期记忆对当前轮次的意义。 「京东、字节Seed、字节跳动、拼多多、百度、美团、腾讯、腾讯混元、蚂蚁集团、阿里巴巴」
【短期记忆实现】短期记忆有哪几种方式实现？（除Redis） 「阿里巴巴」
【企业级RAG设计】设计企业级RAG系统，包含分层记忆架构：L1滑动窗口、L2摘要压缩（LLM与规则剪枝）、L3长期文件存储。 「字节Seed、字节跳动」
1. 详细讲解Agent系统中长短期记忆的设计逻辑，在长时对话场景下，如何实现上下文信息的动态压缩与选择性遗忘？
6.2 短期上下文和长期摘要如何分层
4.你的智能体上下文是怎么分层？怎么设计的？上下文存储在哪里？长短期记忆怎么划分？RAG数据库都有哪些，它们各自的区别？
7.Agent中的短期记忆和长期记忆分别有什么作用？通常会如何实现？
7.讲一下Agent中的短期记忆和长期记忆分别怎样存储？
12.长期记忆和短期记忆是什么？怎么设置
10. 每轮对话都要注入记忆吗？长短期记忆是同时注入吗？
11. 短期记忆和长期记忆分别怎么设计？历史对话在什么情况下会被摘要或召回？
记忆分层中，长期记忆跟短期记忆在agent中具体扮演什么功能？
18. 讲一下长时记忆和短时记忆的底层实现方式？
Memory是 Agent 的一个关键模块。请问如何为 Agent 设计短期记忆和长期记忆系统？可以借助哪些外部工具或技术？
Agent 的短期记忆和长期记忆分别怎么实现？
查看参考回答收起参考回答
长期记忆应保存未来仍有用、有明确依据、作用范围清楚且允许保留的信息。典型内容是稳定偏好、持续项目约定、可复用环境事实，以及经过验证的经验；当前任务进度、一次性选择、模型猜测和容易重新查询的临时数据，通常放在会话状态或短期缓存。
可以先抽取候选，再判断持久性、未来复用价值、证据、归属与敏感性，最后做去重、冲突处理和结构化写入。不能因为一句话出现多次，或模型给出高“重要性分数”，就直接当长期事实。
来源 · 4 篇面经 · 8 份题集收起来源
日常对话中大量无用信息，如何判断是否存入Memory？
为什么“把所有成功轨迹写入 Memory”会失败？
OpenClaw Dreaming 为什么需要三道门槛而不是一道？
【记忆重要性判断】在记忆系统中，哪些记忆是重要的，哪些是不重要的？如何进行判断？ 「百度」
面试问题：记忆污染和隐私泄露有哪些风险？
哪些东西别放进长期记忆
Memory 应该存什么、不存什么？如何避免污染和隐私风险？
你会如何判断一条历史信息该进入长期记忆，还是只留在当前会话里？
查看参考回答收起参考回答
长期记忆的实现，可以分成写入表示、持久存储、按需召回和上下文注入四步。
写入时，从交互中选出有跨会话价值的偏好、事实、决策或经验，整理为可更新的记录，保存主体、内容、来源、适用范围、有效时间和版本。存储可用数据库、KV 或文件；需要语义查找时，再为相应文本建立向量索引，不是只存一串向量。
召回时，先根据可信身份确定用户、租户和任务范围。固定偏好按用户与字段精确读取；开放式历史经验按当前问题做语义或混合检索，再检查时效、状态、来源并去重，选择有限结果放入本轮上下文。向量相似说明相关，不代表它一定属于当前用户、仍然有效或可以直接执行。
例如“以后项目报告先给结论，再给依据”可以存为用户的报告风格；新会话写报告时按用户读取即可。如果问“上次为什么选择那个方案”，则更适合检索相关项目的历史决策及证据。
来源 · 5 篇面经 · 6 份题集收起来源
在Agent中引入"记忆"机制时，为什么常用向量数据库？如何设计embedding和检索策略？
【Long-term Memory实现】如何理解Long-term Memory的实现方式？ 「百度」
Agent 的长期记忆怎么实现？
什么是长期记忆（Long-Term Memory）？
Agent 怎么实现跨会话记忆？
如何实现长期记忆的存储与检索（如基于向量数据库）？
记忆冲突、更新与隔离
3 道题目查看参考回答收起参考回答
我会先判断冲突是不是发生在同一主体、同一字段、同一适用范围和时间，再决定当前使用哪条信息，最后单独决定是否更新长期记忆。不能简单按“长期记忆更稳定”或“最后一句话永远优先”处理。
- 当前任务偏好：用户这次明确要求详细解释，就按这次要求回答；这不自动把“平时偏好简短”改成永久详细。
- 明确事实变化：用户确认已经从北京搬到上海，就把上海设为当前居住地，并保留北京曾在何时有效的历史。
- 客观状态或高风险信息：要核对来源与有效时间；冲突尚未消解时，保留待核实状态，必要时澄清，不能让一句模糊表述覆盖业务记录或重要限制。
例如“一个月前喜欢吃辣，一周前不能吃辣”，偏好和当前限制本来就是两个字段。系统应尊重仍有效的限制，必要时确认其适用时间，不能根据旧偏好推断用户现在可以吃辣。
来源 · 7 篇面经 · 8 份题集收起来源
矛盾信息怎么处理？不同来源不同时间说了不一样的事
面试问题：记忆冲突、过期和遗忘机制如何处理？
面试追问：当前用户输入和历史记忆发生冲突时，以哪个为准？为什么？
8. Agent记忆模块如何迭代更新，新旧经验冲突时该怎样取舍留存？
如何为 Agent 设计短期记忆和长期记忆系统？技术上通常怎么落地？
用户前后给了矛盾的信息，记忆系统怎么处理？
记忆压缩、记忆过期、记忆冲突应该怎么处理？
如果用户偏好、事实记忆、系统状态三者冲突了，Agent 应该信谁？
查看参考回答收起参考回答
记忆更新不应只向历史末尾追加摘要，而应经过提取候选、核对主体与证据、判断新增或替换、版本化写入、更新索引与当轮上下文。用户明确更正可以替换旧事实；含糊、引用别人或假设情景的信息不能直接写成用户事实。冲突无法解决时保留待核状态，而不是简单“最后一句话获胜”。
短期滚动窗口、摘要压缩和长期事实更新也要分开：前两者改变当前模型看到什么，长期记忆更新改变跨会话可用的持久信息，不能因为压缩了对话就丢掉原始依据。
来源 · 2 篇面经 · 1 份题集收起来源
查看参考回答收起参考回答
隔离要同时覆盖身份、会话、项目范围、存储查询和运行上下文。请求先从认证结果取得tenant_id、user_id，再确认该用户有权访问指定session；消息历史按会话读写，长期记忆按授权的用户或项目范围检索。不能只生成不同session_id，就认为所有数据已经隔离。
身份与范围由服务端传入工具和存储层，不能让模型参数覆盖。缓存、向量检索、附件、后台任务和日志也要携带同样的范围，避免主数据库分开了，其他路径仍串用户。