Agent 开发岗知识地图（七）：Memory 与上下文工程——从上下文解剖到长期记忆范式

2401_84957377

14人浏览 · 2026-10-13 11:26:16

2401_84957377 · 2026-10-13 11:26:16 发布

「Agent 开发岗知识地图」系列 · 第 7 篇 / 共 12 篇

上一篇：（六）框架与工程选型——从 LangGraph 到部署与成本工程。这一篇讲 Memory 与上下文工程——2026 年 Agent 面试最热的主题区：上下文窗口六组成与 token 账本、Context Engineering 概念界定、长对话管理（截断 / 滚动摘要 / 关键信息保护区）、Memory 分层体系与长期记忆三范式（mem0 / Letta / 文件式）、记忆写入时机与记忆污染治理、多 Agent 间上下文传递、上下文压缩技术、Lost in the Middle 与长上下文可靠性，最后给出「上下文管理怎么做」的四段式分层答法模板。每个考点按「一句话版本 → 完整展开 → 高频追问 → 关联真题」四段展开：先建立框架，再补底层原理，最后用高频追问检验掌握程度。

后续章节将陆续发布：08 Agent 评测 · 09 安全与对齐 · 10 模型层与应用配合 · 11 系统设计题满分模板 · 12 项目深挖与手撕代码。

想看工程实践向的可以先读：给 MCP 服务端加限流：为什么额度按「页数」加权而不是按请求数

考点 1：上下文窗口解剖——一段 Agent 请求里到底有什么

一句话版本

一次 Agent 的 LLM 调用，上下文由六部分组成：system prompt（角色与规则，几百～千 token）+ 工具 schema（每个 50–300 token，十个工具就是 1–3k）+ 对话历史（每轮几百，工具结果每条可上千，随轮数线性膨胀）+ 检索注入内容（每个 chunk 几百～两千）+ scratchpad/思考与中间产物 + 本轮 tool results。做上下文工程的第一步永远是先测出自己场景里各部分的实际占比——不同业务的膨胀源完全不同（客服是历史、数据分析是工具结果、RAG 是检索块）。

完整展开

1) 组成与量级表（拿数字说话显经验）

组成部分	内容	典型量级	增长方式
system prompt	人设、规则、输出格式要求	300–2000 tok	固定
工具 schema	全部工具的 name/description/参数 JSON Schema	每工具 50–300 tok；20 个工具可达 3–6k	挂载即占
对话历史	用户/助手消息	每轮 100–500 tok	线性
工具结果回填	历史 tool results 滚动留在 messages 里	每条 200–5000 tok（查库/网页最肥）	线性、最易爆炸
检索内容	RAG 召回 chunks	每块 300–1500 tok，top5 就是几千	按次注入
scratchpad/中间态	思考摘要、计划、子 Agent 结果摘要	数百～数千	看实现

2) 关键认知：历史里的大头往往是 tool results，不是对话文本
一个数据分析 Agent 跑 10 步，每步查库回填 2000 token，历史里就压了 2 万 token 的表格——而其中大部分在后续步骤毫无价值。这就是为什么上下文压缩的主战场是工具结果（见考点 8）。

3) 工程动作：先做 token 账本
用 token 计数接口（而非肉眼估算）对线上 trace 抽样统计各部分占比，得出"我的场景膨胀源"，再针对性下药——面试时给出这个"度量先行"的顺序本身就是加分项（考点 10 的模板正是从这里开始）。

高频追问

「工具 schema 也占上下文吗？」→ 占，而且是每一轮都占的固定成本；工具多时的解法是工具检索/按需挂载（RAG over tools），只把候选工具的 schema 注入本轮。
「为什么我 20 个工具 prompt 就变慢变贵？」→ 前缀里光 schema 就几千 token，且模型在 20 选 1 里的选择准确率会降——工具不是越多越好。
「上下文窗口不是已经到 1M 了吗，还管这些？」→ 窗口大≠免管理：成本随 token 线性涨、长上下文有 Lost in the middle（考点 9）、且缓存/延迟都吃影响。大窗口改变的是"崩溃阈值"，不是"最优策略"。

关联真题

上下文组成是各家高频考点，此类题见百度、腾讯、美团方向的上下文管理题。

考点 2：Context Engineering 是什么——2025–2026 最热概念

一句话版本

Context Engineering（上下文工程）的定义：在每一步推理前，为模型动态组装"恰到好处"的上下文——放什么进窗口、以什么形式放、放多少，是一个信息系统设计问题。它和 prompt engineering 的区别：后者研究"这段话怎么措辞"，前者研究"窗口里该有哪些信息"。核心操作四个：写入（write）——决定什么信息进窗口；选择（select）——每步检索/注入什么；压缩（compress）——超限时保真降体积；隔离（isolate）——把不必要的信息隔离在子上下文（子 Agent）里处理，只回传摘要。

完整展开

1) 为什么 2025 年这个词取代了 prompt engineering

能力边界变了：模型"说得好"已经不够，瓶颈移到"知道什么"——窗口里的信息质量直接决定推理质量（garbage in, garbage out 的字面含义）；
Agent 化了：单次调用的 prompt 变成了持续运行的循环，上下文从"一段静态文本"变成"一个随步骤演化的状态"——它是动态的、每步重组的；
业界共识的表述（可引用）：Karpathy 把它总结为"为下一步填入恰当信息的精致艺术"；Anthropic 的工程博客把 agent 的上下文工程归纳为长任务下的信息流管理——compaction（压缩）、structured note-taking（结构化笔记）、just-in-time context（按需检索）、sub-agent 隔离四大手段。

2) 四大核心操作（框架如下）

操作	问题	手段
写入 write	什么值得进上下文	工具结果截断策略、结构化笔记（Agent 自己写 scratchpad）、记忆写入
选择 select	这一步需要什么	RAG 检索、记忆检索、工具按需挂载、字段级裁剪
压缩 compress	超限了怎么保真	滚动摘要 compaction、抽取式压缩（考点 8）
隔离 isolate	上下文互相污染/撑爆	子 Agent 干活只回传摘要、黑板模式（考点 7）

3) 与 prompt engineering 的关系（防被追问"那 prompt engineering 没用了？"）
不是取代而是包含：prompt engineering 处理窗口内每段文本的质量（工具描述怎么写、指令怎么排），context engineering 处理窗口内容的集合与预算分配。类比：前者是"写好每一页 PPT"，后者是"决定这本 PPT 放哪几页、按什么顺序讲"。

4) 一条贯穿的原则：上下文是稀缺资源，要有预算管理
把窗口当内存管理：system/工具 schema 是常驻段、历史是可淘汰段（可压缩/换出成摘要）、检索内容是按需加载段、scratchpad 是工作区。所有后续考点（截断/摘要/记忆/压缩）都是这个内存管理模型下的具体页面置换算法。

高频追问

「context engineering 一词的出处？」→ 2025 年由业界（Karpathy 的推文、Shopify CEO Tobi Lütke 的内部备忘录流出、Anthropic 的 agent 工程文章）共同推热；答出"从措辞优化到信息系统设计的范式转移"即可，别纠结单个出处。
「你觉得最被低估的上下文工程手段？」→ 好答法：结构化笔记（让 Agent 边干边把关键事实写进 scratchpad，后续步骤读笔记而非重读原始工具结果）——它把"重算/重读"变成"读结论"，是成本和可靠性的双赢。

关联真题

Context Engineering 是 2025H2 起的新热点题，此类题见蚂蚁集团、腾讯（AgenticRAG 一面）、字节跳动方向。

考点 3：长对话上下文管理（截断 / 滚动摘要 / 检索式历史 / 关键信息保护区）

一句话版本

长对话管理四板斧按复杂度递进：滑动窗口截断（保最近 N 轮，简单粗暴丢早期信息）→ 滚动摘要 compaction（超阈值时把旧历史压成摘要，保留语义连续性）→ 检索式历史（把历史消息向量化存库，每轮按当前问题检索相关片段注入——历史变成一种记忆资源）→ 关键信息保护区（用户偏好、任务目标、已确认事实等"宪法级"信息单独存放，永不参与压缩）。生产实践是四者组合：保护区 + 滚动摘要 + 近窗口，检索式作为超长会话的补充。

完整展开

1) 滑动窗口截断

实现：只保留最近 N 轮或 token 预算内的消息；首条用户消息（任务原目标）建议永久保留——最常见的低级 bug 是"截断把任务目标截没了，Agent 干着干着忘了自己要干嘛"。
优点：零成本零延迟；缺点：硬丢信息，只适合闲聊类。

2) 滚动摘要（compaction）

async def maybe_compact(state, max_tokens=60_000):
    if count_tokens(state.messages) < max_tokens * 0.8:
        return state
    old, recent = split(state.messages, keep_last=6)      # 近几轮原文保留
    summary = await llm_summarize(old, focus="任务目标/已确认事实/未决问题/关键工具结果")
    return state.with_messages(
        [SystemNote(f"[历史摘要]\n{summary}")] + recent)

设计要点：(a) 触发阈值留 20% 余量防抖动；(b) 摘要 prompt 要结构化（目标/事实/待办/关键结果分节），不是一段散文；© 旧消息原始内容转冷存储，badcase 排查时可回看（别物理删除）；
权衡：摘要压缩比通常 5–10 倍，但会失真 + 打碎 prompt cache（前缀变了，见 06 考点 9）——所以触发频率要克制，别每轮都压。

3) 检索式历史（把历史变成记忆）

做法：每轮结束把消息（或摘要）embedding 入库；每轮开始用当前 query 检索 top-k 历史片段 + 最近窗口一起组装；
适合超长跨天会话与"用户三周前提过的偏好"这类远期引用；
坑：检索引入非确定性（该召回没召回 → Agent"失忆"），要做"远期信息只用检索、近期信息必在窗口"的双通道，而不是全靠检索。

4) 关键信息保护区（protected / pinned context）

内容：任务目标与约束、用户身份与偏好、已确认的关键事实、安全规则；
实现：单独字段/文件（如 state.pinned），每轮组装时无条件注入到 system 附近显眼位置，不参与任何压缩与截断；
进阶：让 Agent 自己维护（提供 update_pins 工具，模型在发现"用户改了需求"时主动更新）——这就是向结构化笔记/Claude Code 式文件记忆的过渡（考点 5）。

5) 组合策略（面试给全景）

最终上下文 = system + 工具schema + 保护区(pinned) + 历史摘要 + 最近K轮原文 + 本轮检索结果

高频追问

「摘要什么时候触发？」→ token 阈值（如上下文的 70–80%）或轮次阈值；更精细的是"检测到token增速异常的工具结果大量堆积"时先做工具结果压缩再考虑全局摘要。
「压缩会不会丢关键信息导致 Agent 行为变化？」→ 会，所以必须配套：结构化摘要模板（降低漏信息率）+ 保护区兜底 + 压缩前后跑回归评测（08 的评测门禁）。
「多轮改写了历史，缓存全失效，怎么办？」→ 承认权衡：compaction 是"缓存收益 vs 窗口爆炸"的取舍；策略是低频触发 + 压缩后接受一次缓存重建。

关联真题

长对话/上下文管理是高频必考，此类题见百度、美团、月之暗面方向。

考点 4：Memory 分层体系（短期 / 中期 / 长期）

一句话版本

记忆按生命周期分三层：短期记忆 = 当前会话的工作集（就在上下文窗口里，形态就是 messages）；中期记忆 = 任务级（一个长任务跨多天/多次会话的中间产物、计划、已完成步骤，通常是结构化状态 + 文件）；长期记忆 = 跨会话的用户画像与事实（偏好、历史决策、领域知识，存储形态是向量库 + 结构化 KV + 文件的混合）。核心设计问题是每一层的存储形态、读写时机、淘汰策略——把三层混为一谈（比如什么都往向量库塞）是典型新手错误。

完整展开

1) 三层对照表

层	生命周期	内容	存储形态	读写方式
短期	单次会话	对话历史、当前工具结果	内存/上下文窗口本身 + checkpoint	每轮全量在场（配合压缩）
中期	任务/项目级（小时～天）	计划、进度、关键中间产物	结构化状态（DB/文件），如 TODO list、结果清单	Agent 显式读写（笔记/文件）
长期	永久（跨会话）	用户画像、偏好、事实记忆	向量库（语义检索）+ KV（确定性查询）+ 文件（可编辑全景）	每轮检索注入 / 按需加载

2) 各层存储形态的选择逻辑（为什么是混合而不是单一）

向量库解决"模糊回忆"（“这个用户之前好像说过喜欢靠窗座位”）——语义相似召回；
结构化 KV/表解决"精确事实"（用户 ID、会员等级、上次订单号）——这类信息走向量检索会翻车（top-k 召回不准就答错），必须确定性读写；
文件/文档解决"可编辑的全景画像"——Agent 和人都能读能改，版本可追溯（Claude Code 的 MEMORY.md 路线，见考点 5）；
面试表述：「事实用表、回忆用向量、画像用文件，三层各司其职」。

3) 短期与长期的边界问题

短期→长期的迁移就是"记忆写入"（考点 6 的核心问题）：什么信息值得沉淀？何时沉淀？
中期记忆常被忽略但很实用：长任务的"进度文件"（已完成/待办/关键发现）本质是给断点续跑和 compaction 用的结构化笔记——重启后 Agent 读进度文件就能接上，比读全量历史便宜得多。

高频追问

「会话记忆和长期记忆的读写都发生在什么时机？」→ 转考点 6 的完整答案（写入：会话结束批量 + 关键事实实时；读取：每轮检索注入 + 确定性字段直取）。
「为什么不全部塞进向量库？」→ 精确事实检索不可靠、无结构关系（时序/因果）、更新冲突难处理、且检索式记忆有召回失败风险——单一存储形态是把记忆问题过度简化。
「用户要删除记忆怎么办（合规）？」→ 结构化层可删（按用户 ID 级联），向量层需要"删除向量 + 重建涉及的记忆项"，文件层版本化可回滚——合规是长期记忆系统设计的硬约束。

关联真题

Memory 分层见字节跳动、智谱AI、MiniMax 方向的记忆系统题。

考点 5：长期记忆三种实现范式（mem0 / Letta(MemGPT) / 文件式）

一句话版本

长期记忆三条技术路线：mem0 范式 = 管线式——两阶段"提取-更新"：先从对话提取候选事实，再由 LLM 对每条事实做 ADD/UPDATE/DELETE/NOOP 决策并做冲突消解，维护一份精炼的事实库；Letta(MemGPT) 范式 = 操作系统式内存分页——把上下文窗口当 RAM、外部存储当磁盘，Agent 通过函数调用自己换页（编辑核心记忆块、检索归档记忆）；文件式（Claude Code 的 MEMORY.md 模式）= 朴素但极有效——就是一份 Agent 可读可写的 Markdown，人类可审计、可版本化、无基础设施依赖。三者代表了"智能管线 vs 自管理内存 vs 极简文件"的谱系。

完整展开

1) mem0：提取-更新两阶段管线

对话轮 → [阶段1: 提取] LLM 抽出候选事实（"用户在深圳工作"）
       → [阶段2: 更新] 对每条候选，检索现有相关记忆，LLM 判定：
            ADD（新事实）/ UPDATE（修正旧事实）/ DELETE（矛盾且旧事实作废）
            / NOOP（重复或无关）
       → 写回向量库 + 结构化存储

核心洞见：记忆的质量瓶颈不在存储而在更新策略——没有冲突消解的记忆库会充满"用户在北京"和"用户已搬到深圳"的矛盾对，检索时随机命中哪条都错；
冲突消解依赖"新信息覆盖旧信息"的时序假设 + LLM 判断语义矛盾；
工程优点：管线与主 Agent 解耦（可异步、可离线）、每步可观测可评测；缺点：提取有损、管线延迟、记忆 schema 偏平（事实条目），复杂关系表达弱。

2) Letta（前 MemGPT）：内存分页 / OS 隐喻

分层：core memory（核心记忆块，常驻上下文——用户画像块 + 任务状态块，Agent 可用 core_memory_append/replace 直接编辑自己的系统提示）；recall memory（对话历史，分页可检索 conversation_search）；archival memory（归档大库，archival_memory_insert/search）；
核心洞见：让 Agent 自己管理内存——像操作系统进程一样，Agent 决定什么驻留（core）、什么换出（archival）、何时检索换入（search）；上下文溢出时不是被动截断而是主动"换页"；
这个思想已被 API 层吸收（如 Claude 的 memory 工具：客户端存取、模型在对话中主动调 memory 工具读写长期记忆），说明"自管理内存"是被验证过的方向；
优点：自适应（Agent 比离线管线更知道当前任务需要什么）；缺点：把关键工程决策交给模型，行为不可控性上升、评测复杂。

3) 文件式：Claude Code 的 MEMORY.md 模式

做法：给 Agent 配 Read/Write/Edit 文件工具 + 一个记忆文件（如 MEMORY.md，"用户偏好/项目约定/踩过的坑"分节）；Agent 在判断某信息值得长期记住时主动编辑该文件，每次会话开始读入；
优点：人类可读可审计可手改（发现记忆错了直接编辑）、git 版本化天然免费、零基础设施、可扩展为目录（每个项目一个记忆文件，按需加载——这本身就是 context engineering 的按需选择）；
局限：无语义检索（靠模型自己组织结构）、规模上限低（几千行内）、多设备同步要靠文件同步机制；
为什么它反而代表 2025–2026 的主流取向：简单可审计的东西在生产上跑得住——比"聪明的管线"更少意外行为。

4) 三范式对比表（建议收藏）

维度	mem0 管线式	Letta 分页式	文件式
记忆写入者	离线管线（LLM 判定）	Agent 自己（工具调用）	Agent 自己（文件编辑）
一致性维护	提取-更新-冲突消解	Agent 自编辑 core blocks	Agent 自编辑 + 人工审计
可控/可审计	中（管线可观测）	低（行为模型决定）	高（人可直接改）
基础设施	向量库+管线服务	框架/内存抽象	文件系统
规模	大（可检索）	大	小（单文件量级）
适合	用户量大、记忆条目多	长任务自适应	个人助手/编码 Agent、小规模

5) 选型话术
「量小且要可控 → 文件式起步；用户量与记忆规模上来了 → mem0 式管线做结构化事实沉淀；Agent 任务长且记忆访问模式多变 → Letta 式自管理。三者不互斥——生产系统常是文件式做画像 + 管线式做大规模事实库。」

高频追问

「mem0 的两阶段为什么不能合成一步？」→ 提取只看增量对话（无状态、便宜），更新必须对照全量相关记忆做冲突判定（有状态、贵）；合一步会让"对照旧记忆"的上下文每轮都变巨大，且两阶段各自可评测、可重跑。
「MEMORY.md 会不会被 Agent 写爆/写坏？」→ 会——实践中要配约定（分节模板、写入判据"值得记 = 跨会话仍有用且不派生可得"）+ 定期人工 review；这暴露了文件式依赖模型自觉的固有风险。
「向量记忆检索 top-k 应该注入多少？」→ 记忆注入要克制：每条记忆注入都有污染与 token 成本，通常 3–5 条、加相似度阈值过滤，宁缺勿滥（记忆污染见考点 6）。

关联真题

mem0/Letta 是 2025H2 起的高频新题，此类题见蚂蚁集团、字节跳动、智谱AI 方向。

考点 6：记忆的写入与读取时机（含记忆污染）

一句话版本

写入时机两种：会话结束批量写入（便宜、不打断主流程，但会话中断就丢）与关键事实实时写入（用户明确表达偏好/身份变更时立刻沉淀）；生产用"实时写关键事实 + 结束时全量回顾"的混合。读取方式按类型分：画像类每轮检索注入 system 附近，事实类按需加载（相关任务出现才取），确定性字段（ID 类）直接查表不走向量。最大隐患是记忆污染——错误或过期的记忆每轮注入持续误导 Agent，解法是置信度、时间戳、来源可追溯与"记忆也要能被证伪和淘汰"。

完整展开

1) 写入时机对比

策略	触发	优点	缺点
会话结束批量	会话 close	成本低、全局视角（一次看全对话判重要性）	崩溃/中途流失即丢；下次会话前才生效
实时写入	轮内检测到"值得记"事件	及时生效；不怕中断	每轮多一次 LLM 判断成本；局部视角易误判重要性
混合（推荐）	实时写高置信关键事实 + 结束时回顾补全	平衡	实现复杂

实时写入的判断可以轻量：规则触发（用户说"记住…"、身份字段变更）+ 小模型分类（这轮有没有值得沉淀的事实）。
写入判据（防记忆库变垃圾场）：跨会话仍有用 + 不是从现有数据可派生 + 置信度够高。宁可漏记（下次还能再学），不可错记（污染持续存在）。

2) 读取策略

画像/偏好类：每轮检索注入（少量、显式标注来源"根据历史记忆：用户偏好…"）；
事实类（历史订单、过往结论）：按需——当前任务涉及时由 Agent 主动调 memory 检索工具，而不是每轮盲注；
确定性字段：直接 KV 查询，严禁走向量检索；
注入格式要带时间戳与来源：“（2025-12 用户自述）偏好靠窗座位”——让模型能自己对新旧信息做仲裁。

3) 记忆污染（production war story 高发区）

来源：模型提取错误（把假设当事实写入）、一次性状态被当成长期偏好（“这周在出差"→永久"常驻出差”）、恶意输入诱导写入（注入攻击污染记忆影响后续所有会话）；
危害放大机制：错误记忆每轮注入= 持续性误导，且用户难以察觉（“AI 为什么总觉得我是新手”）；
防御：(a) 写入门槛（置信度、双阶段确认）；(b) 元数据（时间戳、来源轮次、有效期——"出差到 12 月 20 日"应带 TTL）；© 冲突检测读取时呈现矛盾让模型仲裁；(d) 用户可见可编辑的记忆面板（最有效的纠错通道是让人看）；(e) 记忆写操作本身过权限与注入检测。

高频追问

「记忆系统怎么评测？」→ 记忆命中率（该用的记忆用了没）、误注入率（不该用的注入了）、污染率（错误记忆存活时长）；构造"多会话连续性"测试集（第一会话告诉偏好，第二会话验证是否生效）——这是 08 评测里轨迹级评测的应用。
「用户当面纠正了记忆错误，怎么处理？」→ 理想链路：检测到冲突 → 更新/作废旧记忆（带 supersede 关系而非物理删除）→ 本次会话立即生效。答出"作废而非删除 + 保留溯源"是亮点。

关联真题

记忆读写时机与污染见美团、快手、百度方向的记忆系统深挖题。

考点 7：多 Agent 间上下文传递（handoff / 黑板 / 结果回传）

一句话版本

多 Agent 的上下文传递核心是最小必要原则：handoff 时带"任务目标 + 已确认事实 + 相关中间结果"，丢"原始全量历史与无关工具结果"——全量透传等于上下文炸弹加互相污染。三种模式：handoff 摘要交接（A 把 B 需要的打包）、共享黑板/scratchpad（多个 Agent 读写同一块结构化状态区，通过黑板解耦而非点对点传）、结果摘要回传（子 Agent 完成后只把结论与关键产物回传 orchestrator）。共同本质：把上下文传递当作受控的信息流设计，而不是消息转发。

完整展开

1) handoff：带什么、丢什么

必带：任务描述（B 的目标）、完成标准、A 已确认的关键事实（去噪后的）、相关实体引用（如订单 id）、A 失败尝试的教训（防止 B 重复踩坑）；
必丢：A 的全量对话历史、与 B 无关的工具结果、A 的内部推理过程；
形态：结构化 handoff payload（JSON）而非自由文本，字段显式（goal / facts / constraints / prior_attempts / handoff_reason）；
坑：丢太多导致 B 缺上下文重新问用户（体验断裂），带太多导致污染 + 成本——"带什么"要按 B 的任务类型设计，这本身就是 context engineering。

2) 共享黑板（blackboard / shared scratchpad）模式

一个所有 Agent 可读写的结构化状态区：任务清单、当前事实集、各 Agent 的产出槽位；
优点：解耦（A 不需要知道谁会消费它的产出）、可审计（黑板即全链路现场）、支持并行（多 worker 各写各的槽位）；
实现：数据库表/Redis 结构 + 读写约定（谁负责哪个命名空间、冲突时以谁为准）；
与"子 Agent 各自私有上下文"不矛盾：黑板是共享的结论层，私有上下文是各自的探索过程——过程不上黑板，只有结论上。

3) 结果摘要回传（sub-agent → orchestrator）

orchestrator-worker 架构的标准回路：worker 的完整过程（读了 50 个文件、调了 20 次工具）留在 worker 自己的上下文里，只回传结构化结论（答案 + 关键证据 + 置信度）；
这正是子 Agent 存在的核心理由之一：上下文隔离——脏活累活的 token 消耗被隔离在子上下文，主上下文保持干净（Anthropic 的多 Agent 研究系统的实践要点）；
回传摘要的质量决定 orchestrator 决策质量——摘要 prompt 要求"结论先行 + 证据引用 + 不确定性显式标注"。

4) 面试标准句
「多 Agent 系统里，上下文传递的信息量是设计出来的：传结论不传过程，传结构不传原文，传必要不传全部。」

高频追问

「为什么不全量透传，模型自己会筛选吧？」→ 不会可靠地筛选：无关历史会稀释关键信息（lost in the middle）、成本随 Agent 数量乘积爆炸、一个 Agent 的错误推理会污染下游——全量透传在三个方面都是最差解。
「黑板会不会成为瓶颈/单点？」→ 会——读写竞争（需要命名空间隔离与乐观锁）、一致性问题（A 读到 B 写了一半的状态，需要原子写或版本号）；规模大了上消息总线 + 事件溯源。

关联真题

多 Agent 上下文传递是知识地图标注的加分项，此类题见小红书、智谱AI、MiniMax 方向。

考点 8：上下文压缩技术（LLM 摘要 / 抽取式 / 工具结果截断）

一句话版本

压缩三档按保真度与成本排：LLM 摘要压缩（语义保真但贵且慢、有损）→ 抽取式压缩（只保留"调了什么工具、什么参数、结论一行"的骨架，丢弃原始输出，便宜且行为可复现）→ 工具结果截断（源头治理：头尾保留、结构化摘要、超限截断——在结果产生的瞬间就压，不进历史堆积）。生产组合拳：工具结果在写入时就截断/结构化，历史用抽取式骨架，只有整段历史超限才上 LLM 摘要。

完整展开

1) LLM 摘要压缩

适用：对话历史、多文档阅读结果这类需要语义连续性的内容；
已在考点 3 展开；这里补一点：摘要的分层——先做工具结果级摘要（局部），再做历史级摘要（全局），比一步到位的全局摘要保真得多。

2) 抽取式压缩（骨架化）

思路：多步 Agent 的历史里，后续步骤真正依赖的是"做过什么决定 + 关键产出"，不是工具原始输出；
实现：把旧步骤压成结构化骨架——

step 3: 调用 query_orders(user_id=U1, status=paid) → 命中 2 单（订单号 A1024/A1025，总金额 ¥860）→ 结论：用户本月有 2 笔已支付订单

可以由规则 + 小模型生成：规则抽工具名与参数，小模型抽一行结论；
优点：便宜、token 缩减 10–100 倍、关键信息（工具调用序列）无损——后续步骤要"引用之前查过的数据"时引用的是结论而非原始表格；
与"结构化笔记"的关系：骨架化本质就是让历史从"过程记录"退化为"结论记录"，等价于让 Agent 边干边记笔记后再丢过程。

3) 工具结果截断策略（源头治理，工程价值最高）

策略	做法	适用
头尾保留	保结果开头 N + 结尾 M token，中间折叠成 `...[省略 X 行]...`	长列表、日志
结构化摘要	结果进历史前先过一层小模型/模板转成"字段：值"摘要	网页、文档
行数/字段裁剪	只保留请求时声明的需要的字段（工具设计时就支持 `fields` 参数）	数据库查询
引用化	大结果存对象存储，历史里只留引用 id + 一行摘要，Agent 需要时再取	报告、大文件
置信度提示	明确标注"此结果已截断"	防 Agent 把截断当全量

铁律：截断必须显式告知模型（“以上为截断结果”），否则模型会把部分数据当全部数据得出错误结论——真实 badcase 高发点。

4) 压缩的验证（闭环意识）
压缩策略是改动就会影响行为的组件，必须挂回归评测：用固定任务集对比压缩前后任务成功率与关键信息引用准确率（08 的评测门禁思想同样适用于上下文策略变更）。

高频追问

「压缩比能到多少？」→ 工具结果源头截断常见 5–20 倍，抽取式骨架 10–100 倍，LLM 摘要 5–10 倍；但正确表述是"压缩比服从保真需求"而不是越大越好。
「哪些信息绝对不能压？」→ 任务目标、用户显式约束、尚未消费的关键 tool result（模型还没基于它行动过）、保护区内容（考点 3）。

关联真题

压缩与截断策略见百度、月之暗面、蚂蚁集团方向（长上下文/压缩是月之暗面特色题）。

考点 9：Lost in the Middle 与长上下文可靠性

一句话版本

LLM 对上下文中信息的利用率不是均匀的，呈 U 形：开头与结尾的信息被有效利用，中段信息显著更容易被忽略（Lost in the Middle, Liu et al. 2023——多文档 QA 中把正确文档放中间，准确率大幅下降）。对 Agent 的含义：窗口大≠窗口每一格都可靠。工程对策：关键信息前置或后置（指令放头、重要检索结果放尾、摘要紧贴问题）、控制"有效上下文"长度（宁精勿多）、多文档时做位置轮换或让模型先建索引再引用。

完整展开

1) 现象与机理

实验事实：20 个文档的 QA，答案文档放第 1 位准确率 >80%，放中间跌到 ~50% 上下，放末位又回升；
直观解释（可口述，不必深究理论）：因果注意力与位置编码使开头成为"锚"、结尾临近生成天然被强关注，中段信息梯度弱；
对长上下文 Agent 的推论：1M 窗口允许塞进去 ≠ 模型能可靠利用中段的每一条；“大海捞针"全绿只证明"找得到”，不证明"综合推理时都用得上"。

2) 工程对策（记住这四条）

位置策略：system/规则在头（且可重复在尾放关键约束提醒——重要约束"首尾双置"是廉价保险）；检索结果按相关度降序排列且最相关的放最后（贴近问题）；指令紧贴内容（"基于以下文档回答"放在文档之后而不是之前，效果更好）；
精简优先：每轮注入的内容做预算（top-k 限制 + 相关度阈值），"多塞点总没错"是幻觉；
分而治之：内容太多时拆子任务（子 Agent / 分段处理 + 汇总），让每次调用的有效上下文保持"每个信息都有明确职责"；
评测验证：自己的场景做位置敏感性测试（把关键事实挪到不同位置跑一遍），得到"我的模型 × 我的任务"的真实可靠性曲线，而不是引用论文数字。

3) 与 memory/RAG 的联动
检索注入本质是把"信息选择"变成工程可控项——RAG 的 k 和排序就是你对 lost-in-the-middle 的直接干预面；长期记忆注入同理（放 system 附近 = 前置策略）。

高频追问

「lost in the middle 在新模型上还有吗？」→ 程度减轻但未消失，且从"检索不到"演变为"综合推理时利用不足"——答题时表述为"现象弱化、原则仍成立：位置与信息密度影响利用率"。
「怎么快速自测？」→ 构造 N 个文档的 QA，答案文档依次放到 1/N/最后各跑一遍看方差；方差大 → 你的场景需要位置策略。

关联真题

lost in the middle 与大海捞针见月之暗面（长上下文特色）、百度、快手方向。

考点 10：面试答法框架——「上下文管理怎么做」分层模板

一句话版本

被问"你的 Agent 上下文管理怎么做的"，用四段式：① 度量先行（token 账本：我们的场景里历史占 X%、工具结果占 Y%）→ ② 分层策略（保护区/滚动摘要/近窗口/检索注入的组合与各层预算）→ ③ 压缩手段（源头截断 + 骨架化 + compaction 的分级使用与触发阈值）→ ④ 验证闭环（压缩策略变更过回归评测；线上监控上下文长度分布与离群 trace）。这个顺序体现的是"工程决策由数据驱动"——也是面试官区分纸上谈兵者和实践者的分水岭。

完整展开

逐段展开（可直接套用的骨架）

度量先行：「第一步是做 token 账本：抽样线上 trace 统计上下文六个组成部分的占比和 p95 长度。我们场景（举例：客服）的结论是历史占 55%、其中工具结果又占历史的大头——这决定了优化主战场在工具结果治理，而不是盲目上摘要。」
- 亮点：先说"测了什么、发现了什么"，任何优化策略都有数据出处。
分层策略：「组装公式是：system + 工具 schema + 保护区（任务目标、用户约束，永不压缩）+ 历史摘要（超 80% 阈值触发 compaction，结构化模板：目标/事实/待办）+ 最近 K 轮原文 + 本轮检索内容（top-k 限 5、相关度阈值 0.5）。」
- 亮点：说出具体阈值与公式结构，且每个组件对应一个失败模式（保护区对应对话跑偏、K 轮原文对应近期细节、检索对应远期召回）。
压缩手段：「分级：写入时截断（头尾保留 + 显式截断标注）→ 历史骨架化（工具调用序列 + 结论一行）→ 全局 compaction 兜底。原则是便宜的先做、语义保真的最后做，且压缩低频触发以保护 prompt cache。」
- 亮点：提到成本与缓存的联动（与 06 考点 9 呼应）。
验证闭环：「任何压缩策略变更跑固定回归集对比任务成功率与关键信息引用准确率；线上监控上下文长度分布、超长 trace 告警（离群 trace 往往是死循环或结果堆积的信号）。」
- 亮点：上下文策略被当作"可回归验证的工程组件"而不是玄学调参。

使用要领

30 秒版只说四层名字 + 一句结论；面试官追问哪层就展开哪层——每一层你都有 2–3 分钟的展开弹药（就是本章考点 1/3/8/9）；
全程扣一个数字锚点（"我们 p95 上下文 48k，压缩后 12k，任务成功率持平"之类——用自己项目真实数字），有数字的答案可信度完全不同。

高频追问

「上线后上下文管理出过什么问题？」→ 准备一个真实 war story，最通用的模板：截断没标注导致模型把部分数据当全量 → 错误结论 → 修复 = 截断显式标注 + 回归用例固化。
「如果上下文窗口成本无限，你还会做这些吗？」→ 会——lost in the middle（可靠性）、成本、延迟、缓存四个理由里只有一个跟钱有关。这个反问是考察你是否理解上下文管理的本质。

关联真题

此模板适用于几乎所有公司的"上下文管理/长对话"开放题，重点演练蚂蚁集团、阿里（淘天）、腾讯方向的深挖式追问。

附：本章一页速记

考点	一句话锚点
窗口解剖	六段组成；先做 token 账本；大头常是 tool results
Context Engineering	每步动态组装最优上下文；写/选/压/隔四操作；窗口=稀缺资源
长对话管理	保护区 + 滚动摘要 + 近窗口 + 检索式历史，四件组合
Memory 分层	短期=窗口、中期=任务级结构化、长期=向量+KV+文件混合
长期记忆三范式	mem0 提取-更新管线 / Letta 内存分页 / MEMORY.md 文件
读写时机	实时写关键+结束回顾；画像每轮注入、事实按需取；防污染靠置信度+TTL+人可改
多 Agent 传递	传结论不传过程；handoff 结构化 payload；黑板=共享结论层
压缩	源头截断 > 骨架化 > LLM 摘要；截断必须显式标注
Lost in middle	U 形利用率；关键信息首尾置；窗口大≠窗口可靠
答法模板	度量→分层→压缩→验证，四段带数字

下一篇《08 · Agent 评测》正在整理中，系列完整目录见开头。如果这篇对你有帮助，点个赞收个藏，后续更新更容易被刷到。

2048 AI社区

有“AI”的1024 = 2048，欢迎大家加入2048 AI社区

更多推荐

杭州AI外呼怎么选？库阔AgiKoc四标准

作者：库阔AI 内容组｜更新于 2026-10-12 ｜库阔AI 官网：deepsop.cn。文中公司信息与发展历程来自库阔AI 官网公开页面（关于页、产品页、联系我们页）。竞品信息为各厂商官网公开自述，具体以其官方说明为准。本文含 AI 辅助生成内容，已按《人工智能生成合成内容标识办法》添加标识，内容经人工审核。文中涉及的服务内容、计费方式与交付范围，以双方实际约定为准。