面试常见错误：忽视多 Agent 系统中的内存管理与上下文限制
一句话总结
多 Agent 系统的面试不是考你怎么让 Agent 说话，而是考你怎么让它们忘记。大多数候选人把 80% 的时间花在编排逻辑上，却在内存回收和上下文压缩环节露馅，最终拿到的是"strong no hire"而非"lean hire"。你不是不懂 LLM，是你没意识到面试官坐在对面，等的就是你主动说出"这个场景的 token 预算该怎么切分"这句话。真正过关的人，在第五分钟就已经把对话引向了内存架构，而不是还在解释 LangChain 的 chain 怎么串。
适合谁看
正在面 Google、Meta、OpenAI、Anthropic 以及国内头部大厂 AI Infra 或应用团队的候选人。具体画像：有 2-5 年后端或 ML 工程经验，能写 prompt 但说不清为什么某个 prompt 在 20 轮后失效；拿过 $180K-$220K base 的 offer 但总在系统设计轮被压一级；自认为理解 RAG 却在面试中被追问"如果检索结果本身超出上下文窗口怎么办"时卡壳的人。
也包括正在组建 AI 团队的 hiring manager。你司给的 package 大概是 base $160K-$240K，RSU $80K-$200K/年，bonus 15%-20%，你见过的候选人里，十个有八个能画出 Agent 协作图，只有两个能解释清楚为什么某个 Agent 的 memory 不能简单用 Redis TTL 处理。这篇文章帮你识别谁是那 20%。
不适合：刚转行的 prompt engineering 初学者，以及只关心单 Agent 聊天机器人实现的开发者。
面试流程拆解：五轮里的隐形战场
第一轮：Recruiter Screen（45 分钟）
recruiter 的问题很套路："说说你做过的一个多 Agent 项目。" 大多数人开始讲业务价值，比如"我们提升了客服效率 30%"。死局。recruiter 的 checklist 里有一项是"是否主动提及技术约束"，你不开口，他不会追问。
正确版本的开场白："我们做了一个三 Agent 系统，但上线第一周就发现第一个 Agent 的上下文膨胀导致后续两个 Agent 的可用 token 被挤压，最终把对话轮数从设计的 15 轮压缩到 8 轮。" 这句话里包含三个信号：多 Agent 架构、内存问题意识、量化结果。recruiter 会在系统里标注"technical depth confirmed"，直通下一轮。
这轮不考代码，考的是你的问题嗅觉。recruiter 手里有 20 个候选，他要筛到 5 个给 hiring manager。你的任务是让他觉得"这个人面试时能顶得住"。
第二轮：Hiring Manager 技术深挖（60 分钟）
hiring manager 叫 Alex，管着一个 12 人的 AI Platform 团队。他没有让你画架构图，而是抛出一个场景："假设你在做一个电商客服系统，用户咨询、订单查询、退换货三个 Agent。用户跟咨询 Agent 聊了 10 轮，突然说'那我上次那个订单怎么办'，你怎么处理上下文传递？"
大多数候选人的第一反应是"把对话历史拼起来传给订单 Agent"。Alex 会追问："拼起来多少 token？" 你愣住。他继续："咨询 Agent 的对话历史里有大量寒暄，订单 Agent 需要吗？如果用户之前还问过退换货，那段历史现在在哪里？"
这里的关键不是答案，是你的思考路径。Alex 后来在一次 debrief 里说："我要看的是候选人会不会下意识地去算 token 账。不会算的人，上线后就是生产事故的源头。"
正确版本的回答结构：先定义每个 Agent 的 memory scope（咨询 Agent 保留情感标签和意图摘要，而非原始对话），再定义 handoff 协议（传递的是结构化摘要 + 待办事项，不是 raw history），最后给出 fallback（如果摘要本身超出预算，触发压缩策略）。Alex 听到这里会在笔记本上写"systematic"。
第三轮：System Design（90 分钟）
这是决胜轮。白人工程师 Mark，在 Google 干了八年，说话慢但刀刀见血。白板上写着："Design a multi-agent research assistant that can read papers, write summaries, and answer follow-up questions."
你画了三个 Agent：Reader、Writer、QA。Mark 点头，然后问："Reader 读了 50 篇论文，每篇平均 8K token。QA Agent 被问到'第三篇和第四篇的方法论区别'，你怎么处理？"
这是陷阱。50 篇 × 8K = 400K token，远超任何模型的上下文窗口。候选人的经典错误是开始讲 RAG："我们把它切 chunk 放进向量数据库。" Mark 等的就是这个。他会追问："QA Agent 的上下文窗口只有 128K，检索返回 10 个 chunk 已经占了一半，剩下的历史对话呢？如果用户之前还问过'再帮我对比第五篇'，你的历史怎么存？"
正确版本不是"用 RAG"，而是"分层内存架构"。第一层：工作上下文（active working memory），当前对话轮 + 本次检索的精炼摘要，严格控制在 32K 以内。第二层：短期摘要（episodic memory），每轮对话结束后由专用 Agent 生成结构化摘要，存进支持语义检索的数据库。第三层：长期知识（semantic memory），论文的实体关系图、方法论标签、结论摘要，与具体对话解耦。
Mark 会追问摘要生成的时机和触发条件。答案：不是每轮都做，而是在对话主题漂移检测触发时、或用户显式切换话题时、或工作上下文达到 80% 容量阈值时。这里有个具体数字：阈值设 80% 而非 100%，是为了预留突发膨胀空间——用户可能一次 paste 一大段文字。
这轮结束，Mark 的反馈通常是："has strong opinion on memory management, would push back on product for scope" 或者 "thinks RAG solves everything, concerns on production readiness"。
第四轮：Coding + Debug（60 分钟）
不是 leetcode。题目是一个简化的多 Agent 调度器，有 bug：Agent 切换时上下文没有正确清理，导致新 Agent 继承了前任的 system prompt 片段。
你需要在 40 分钟内定位并修复。隐藏测试用例里有一个极端场景：快速连续切换 10 次 Agent，模拟用户反复撤回和重选。内存泄漏的候选会让上下文膨胀到超出限制，健壮实现需要显式的 context reset 和 token 预算审计。
这轮的评分标准不是代码跑通，是你的 debug 思路。面试官会观察你：是否先写 token 计数器来定位问题，还是直接看逻辑流？是否在修复后补充了防御性检查？是否考虑了异步场景下的 race condition？
第五轮：Behavioral / 文化匹配（45 分钟）
总监级别，叫 Sarah。她问的不是"你最大的缺点是什么"，而是："讲一个你和 PM 发生冲突的场景。"
内部场景：候选人讲了一个多 Agent 项目的 deadline 冲突。PM 要求两周上线，他坚持需要三周来做内存压力测试。他的原话是："我跟 PM 说，你现在要的是 demo，我要的是上线后用户聊 20 轮不崩。这两个目标差一个周末搞不定。"
Sarah 追问结果。他说上线后第三周，竞品同类产品出了上下文泄漏导致用户数据串台的 bug，上了新闻。他的系统在用户突破 10 万 DAUs 时零事故。
这个回答的精巧之处：不是炫耀自己正确，而是展示了对"内存管理是风险而非 feature"的认知。Sarah 在 HC 上的原话是："这个人知道什么时候该跟业务方拍桌子。"
核心判断：为什么内存管理是区分线
"上下文窗口够用"是最危险的幻觉
不是模型上下文变大了，你的内存问题就消失了。而是模型上下文变大后，你的内存架构缺陷会被更晚暴露，一旦暴露就是灾难性的。
具体场景：Anthropic 的 Claude 3 支持 200K token，某团队把整本手册塞进 system prompt，前 10 轮体验极佳。第 11 轮用户开始追问细节，对话历史累积，突然某轮响应时间从 2 秒跳到 15 秒，然后超时。根因：虽然总 token 未超，但 attention 计算的复杂度是 quadratic，长上下文下的实际延迟不是线性的。该团队没有实现动态截断策略，也没有预估"可用 token"和"可用时间"是两个独立约束。
多 Agent 不是分担记忆，而是争夺记忆
不是每个 Agent 有自己的内存就解决问题了，而是 Agent 之间的内存边界才是复杂度所在。
具体场景：两个 Agent 协作完成一份报告，Research Agent 负责收集，Writing Agent 负责撰写。Research Agent 的 memory 里存了 20 条 source，Writing Agent 需要引用时，Research Agent 传过去的是完整记录还是引用编号？如果传完整记录，Writing Agent 的上下文被挤压；如果传编号，Writing Agent 需要时怎么快速回溯？大多数候选人的架构图里，Agent 之间是箭头，不是协议。
正确设计：定义显式的 memory contract。Research Agent 输出的是结构化摘要（含关键 quote 的精确位置），Writing Agent 的引用需求通过独立接口异步获取，不占用实时上下文。这个 contract 需要版本管理，因为 Research Agent 的 source 可能被更新或撤回。
压缩不是删除，是语义蒸馏
不是把长文本截断就叫压缩，而是截断后的信息密度决定了下游 Agent 的表现。
反直觉观察：实验数据显示，同样 4K token 的预算，人工撰写的结构化摘要比 naive 截断的原始文本，在下游问答任务上的准确率高 23%。但结构化摘要的生成本身需要消耗 token 和延迟，这个成本该由哪个 Agent 承担、在什么时机承担，是架构设计的关键决策。
内部场景：某候选人在 HC 上被质疑"为什么不用更便宜的 summarization 模型来处理压缩"。他的回答是："我们评估过，轻量模型的摘要丢失关键否定词的概率是 12%，在医疗咨询场景不可接受。我们选择了主模型异步生成摘要，接受 5 分钟的 eventual consistency。" 这个回答展示了技术决策与业务场景的绑定，而非追求技术指标的最优。
准备清单
- 系统性地拆解一次你参与的多 Agent 项目，用 token 审计的视角重新叙述：每个 Agent 的输入输出各多少 token，handoff 时传递多少 token，哪些信息被丢弃、哪些被保留、保留的理由是什么。准备一个具体数字：比如"我们发现咨询 Agent 的 history 平均 3.2K token，但有效信息只有 800 token，压缩后节省了 67% 的传递成本"。
- 手写一个最小化的内存管理模块，支持：固定容量环形缓冲区、基于相关性的智能淘汰、跨 Agent 的摘要传递。不要依赖 LangChain 的 memory 类，面试官要看到的是你对底层机制的理解，不是调包能力。
- 准备三个"我们差点出事"的真实场景，分别对应：上下文爆炸、内存泄漏、handoff 信息丢失。每个场景讲清楚：怎么发现的、怎么定位的、最终怎么修的、如果重来会在架构层面做什么不同。
- 系统性拆解面试结构，PM 面试手册里有完整的多 Agent 系统设计与内存管理实战复盘可以参考，特别是其中关于"如何在 90 分钟 system design 中主动引导面试官关注内存架构"的策略。
- 复习至少两个主流模型的上下文特性细节：Claude 3 的 200K 窗口中 system prompt 和 user message 的计费差异，GPT-4 Turbo 的 function calling 占用 token 的计算方式，Gemini 1.5 Pro 的长上下文优化机制。面试中能随口说出"Claude 的 system prompt 是按 message 计费而非按 token 计费"这种细节，会让面试官眼睛亮一下。
- 准备一份你自己的"内存架构决策矩阵"：什么场景用向量检索、什么场景用结构化摘要、什么场景用图数据库、什么场景必须接受信息丢失。这个矩阵不是标准答案，是你的思考框架，面试中可以用来结构化回答。
- 找一轮 mock interview，专门练"被追问到答不上来"的环节。真正面试中，Mark 这种面试官会在你流畅回答后突然加压："如果用户要求不能丢失任何信息呢？" 你的反应不是慌，而是说"那我们需要重新定义问题约束，因为无遗忘和多 Agent 在当前技术条件下是互斥的，业务上愿意接受什么 trade-off？"
常见错误
错误一：把对话历史当黑盒传递
BAD：候选人描述 handoff 时说"我把 Agent A 的对话历史传给 Agent B，让它继续"。面试官追问"传了多少 token"，候选人回答"就用整个 history 啊"。
GOOD：候选人主动说"我们定义了三种传递模式：完整 history（仅在用户明确要求时，且需用户确认 token 消耗）、轮次截断版（保留最近 N 轮，N 根据目标 Agent 的可用窗口动态计算）、以及摘要版（默认，由专门的 summarization layer 生成，包含实体状态、待办事项、用户情绪标签）"。
区别：前者是"功能实现了"，后者是"成本可控地实现了"。在落地场景中，一个 10 轮对话的 history 可能占 8K token，而精炼摘要只需 400 token，这个差距在多 Agent 级联时会指数级放大。
错误二：忽视 system prompt 的内存属性
BAD：候选人说"我的 system prompt 是固定的，不会变，所以不占内存预算"。面试官追问"如果用户要求'以后都用中文回答'，这个指令存在哪里"，候选人愣住，然后说"存在对话历史里"。
GOOD：候选人解释"我们把持久化偏好存在 profile memory 里，每次对话初始化时注入 system prompt；临时性指令存在 working memory，对话结束后丢弃。profile memory 的更新需要用户显式确认，避免 prompt injection 导致的持久化污染"。
区别：system prompt 不是静态配置，是动态加载的内存区域。一个 2K token 的 system prompt 在长对话中的影响不是一次性的，它会参与每一轮的 attention 计算。更重要的是，多 Agent 场景下，不同 Agent 的 system prompt 可能冲突——客服 Agent 的"简洁回答"和共情 Agent 的"详细安抚"怎么调和，需要显式的优先级协议。
错误三：用缓存策略替代内存架构
BAD：候选人提到"我们用 Redis 缓存对话历史，TTL 设 24 小时"。面试官问"如果两个 Agent 同时访问同一个用户的对话历史"，候选人回答"Redis 是单线程的，不会冲突"。
GOOD：候选人说明"我们区分了三种存储语义：cache（可接受失效，如生成的摘要草稿）、session（需保证一致性，如当前对话状态）、archive（不可丢失，如已确认的订单信息）。三种语义对应不同的存储后端和一致性协议，Redis 仅用于 cache 层，session 用支持 CAS 的存储，archive 写入时追加 WAL"。
区别：把内存管理等同于缓存优化，是概念级别的错误。缓存解决的是"快"的问题，内存管理解决的是"对"的问题——信息在正确的时间出现在正确的 Agent 的正确位置。一个 Agent 读到过期的缓存可能只是回答慢一点，读到错误的历史摘要却可能给出危险的医疗建议。
FAQ
面试官问"你会怎么设计一个不会遗忘的多 Agent 系统"，这是在考什么？
这是在考你是否能识别不可能三角。真正正确的判断是：当前技术条件下，"不会遗忘"、"多 Agent 协作"、"实时响应"三者不可兼得，你需要展示的是在给定约束下的优先级排序能力，而不是假装有完美方案。
具体案例：某候选人在 OpenAI 的面试中被这个问题直接问住，试图用"无限上下文窗口"来回应，被面试官打断："我们的窗口不是无限的，而且即使 200K，100 轮对话后你怎么处理？" 最终过关的候选人回答："如果业务定义'不会遗忘'为 100% 信息保留，我们需要接受分钟级响应延迟，采用分层检索 + 全量日志 replay 的架构；如果业务要求秒级响应，我们需要定义遗忘策略，比如用户主动标记的关键信息永不丢失，其余信息按重要性衰减。" 这个回答的价值在于：把技术约束翻译成了业务决策，展示了 PM 思维与工程思维的结合。该候选人最终拿到 $210K base、$160K RSU/year、18% bonus 的 package。
为什么我总是在系统设计轮被追问"如果用户突然 paste 了 50 页 PDF"，这和我准备的 Agent 架构有什么关系？
因为这就是内存管理的经典压力测试。面试官不关心 PDF 本身，关心的是你的架构在输入突发膨胀时的稳定性。大多数候选人的架构图是静态的，假设了理想的输入规模；面试官要看的，是你的系统在遇到异常输入时的行为定义。
具体案例：某候选人在 Meta 的面试中，被追问后承认"这种情况下我们会截断到上下文窗口大小"。面试官继续："截断策略是什么？头部截断、尾部截断、还是关键句提取？如果 PDF 的结论是啥重要的，但出现在中间呢？" 候选人最终没有通过。后来复盘，正确的回答应该包含：输入预处理的显式预算（如先提取目录结构，让用户选择章节）、流式处理的支持（而非一次性加载）、以及超出预算时的用户交互设计（"文档过长，我选择摘要了前 30%，你可以指定重点章节"）。这不仅是技术问题，是技术决策与用户体验的接口设计。
我在面试中应该主动提及内存管理，还是等面试官问到再说？
主动提及。但不是炫耀式地主动，而是在叙述中自然暴露你的深度。
具体案例：某候选人在 Google 的面试中，描述项目时用了这个结构："我们做了 X，遇到了 Y 问题，当时有两种方案，A 方案更快但内存不可控，B 方案需要多一周开发但每轮对话的 token 消耗可预测。我们选了 B，因为..." 面试官在这里打断追问："如果 PM 逼你选 A 呢？" 候选人回答："我会给 PM 看我们压测的数据，不可控内存意味着 P99 延迟从 2 秒跳到 20 秒，以及 3% 的对话会超出上下文窗口直接失败。" 这种叙述方式把内存管理嵌入到了决策故事中，而不是作为独立知识点背诵。该候选人在 debrief 中被评价为"has operational maturity"，最终拿到 L5 offer，base $185K，RSU $120K/year，bonus 15%。
与之对比的失败案例：另一候选人被问到项目细节时，突然说"我还要提一下我做的内存管理优化"，然后开始背诵 LRU、LFU 原理，与之前的项目叙述脱节。面试官的反馈是"knows concepts but lacks system thinking"，即知识点正确但无法与应用场景绑定。
正确的主动策略：在讲述任何多 Agent 项目时，确保你的叙述包含"规模 - 约束 - 权衡"三层结构。规模：我们的系统处理多少轮对话、多少 token；约束：在这个规模下，什么资源是瓶颈；权衡：我们在瓶颈处做了什么选择，放弃了什么、保全了什么。内存管理自然出现在约束层，不需要额外强调。
准备好系统化备战PM面试了吗？
也可在 Gumroad 获取完整手册。