长鑫存储员工：落地后疯狂扩招，月薪两万多的工程师扎堆涌入，周边房租直接暴涨50%（附Agent面试题）

看到这样一则爆料，挺有意思。

长鑫存储落地合肥之后，原来的偏僻区域也热闹起来了。最猛的时候疯狂扩招，大量两万+月薪的工程师往里冲，附近公寓、小区、商场一起被带热，房租直接涨了50%。

可想而知，在AI时代，最缺的两样，算力资源和AI人才有多紧俏。

作为国内 DRAM（动态随机存取记忆体）的龙头，长鑫存储恰好处于国产缺口、产能扩张和技术升级的交汇点，被视为 AI 存储黄金赛道的最大受益者之一。

PS：DRAM 是一种半导体记忆体，主要负责暂存电脑、手机正在运行的程序和资料。

我去帮大家调研了一下，长鑫存储近期确实在大力招募 AI Agent 方向的研发人员，岗位主要集中在合肥总部和上海。

长鑫存储本身并不做Agent，但Agent的规模化必然会间接增加两类内存需求。

云端 Agent 拉动 DDR5（第五代双倍数据率同步动态随机存取内存，目前主流电脑和服务器的最新一代主内存标准），端侧 Agent 拉动 LPDDR5X（低功耗第五代双倍数据率内存的增强版，专门为智能手机、轻薄本及移动端 AI 设备设计的高性能、超低功耗主内存芯片）。

Agent 的任务链更长、上下文更大、工具调用更频繁、并发量更高。模型权重主要放在 HBM（High Bandwidth Memory，高带宽内存）里，但服务器还需要大量 DRAM 承担请求调度与预处理、Agent 运行状态、RAG 检索结果、KV Cache 卸载、数据缓存、多 Agent 并发任务、数据库和工具服务。

如果你是一位愿意相信努力、相信过程、相信一步一个脚印、相信自己能在 AI 时代分一杯羹的人，那接下来这份硬核的面经，希望你能认真读一读。

（全文比较肝，保证大家能学到很多很多，系好安全带，我们粗粗粗发～）

content

文中涉及的PaiCLI Agent 已经开源到GitHub，Go版本也有：https://github.com/itwanger/PaiCLI-Python

01、Agent 系统中的 Memory，与计算机硬件中的 DRAM 有什么联系？

老王推了推眼镜，翻了翻简历。“开门见山问一个基础的。Agent 系统中的 Memory，和计算机硬件中的 DRAM，有什么联系？”

“DRAM 是物理存储介质，按地址读写，断电数据就没了。它不关心存的是什么内容，只负责往指定地址写入、从指定地址读取。”

“Agent Memory 是软件抽象层，按语义检索，可以选择持久化到磁盘或数据库。它关心的是‘记住什么、什么时候该想起来用’。”

“主板上插了多大的内存条 DRAM 的容量就多大。Agent Memory 的容量受上下文窗口限制，但可以把事实记忆存到磁盘，需要的时候再检索回来注入上下文。”

02、大模型上下文变长后，为什么 KV Cache 会快速占用显存和内存？

“KV Cache 是 Transformer 推理时的核心缓存。每生成一个新 token，模型都要回顾之前所有 token 的 Key 和 Value 向量来计算注意力。如果每次都重新算，计算量会随序列长度平方增长。KV Cache 的做法是把已经算过的 Key 和 Value 缓存下来，新 token 只需要算自己的 Query，然后和缓存里的 Key、Value 做注意力计算。”

“占用之所以大，是因为 KV Cache 的体积和序列长度成正比。”

“具体来说，KV Cache 的大小等于 2 乘以模型层数、乘以 KV 头数、乘以每个头的维度、乘以序列长度、乘以 batch size、再乘以每个元素的字节数。”

“以一个 70B 参数的模型为例。假设 80 层，用 GQA（Grouped Query Attention，分组查询注意力）做了优化，8 个 KV 头，每个头 128 维，BF16（半精度浮点）精度下每个元素 2 字节。单个 token 的 KV Cache 占用大约 320KB。上下文 4K 的时候差不多 1.3GB，到 128K 就飙到大约 40GB——接近模型权重本身的大小了。”

“如果同时服务多个用户，每个用户一份独立的 KV Cache，再乘以 batch size。这就是为什么长上下文加上高并发的场景下，KV Cache 会成为显存和内存的最大消耗者。”

03、大模型推理什么时候是算力瓶颈，什么时候是内存带宽瓶颈？

老王端起茶杯喝了口水。“接着上一题，推理的瓶颈不是一直不变的。什么时候卡算力，什么时候卡带宽？”

“第一个阶段叫预填充（Prefill），就是处理用户输入的整段 prompt。这个阶段所有 token 并行计算矩阵乘法，计算密度非常高，GPU 的算力利用率能到 90% 以上。瓶颈在算力——GPU 的浮点计算能力决定了这个阶段的速度。”

“第二个阶段叫解码（Decode），就是逐个生成输出 token。每生成一个 token，都要把整个 KV Cache 从显存里读一遍来做注意力计算，但每次只产出一个 token 的计算量。计算量小，数据搬运量大，GPU 大部分时间在等数据从显存传过来。这时候瓶颈在内存带宽。”

“一句话概括就是，Prefill 阶段是算得慢，Decode 阶段是读得慢。”

04、多 Agent 并发运行为什么更容易产生 OOM？

“原因是每个 Agent 都有自己独立的内存开销，N 个 Agent 并发就是 N 倍。”

“单个 Agent 运行时至少要维护三份数据：当前对话的上下文窗口、工具调用返回的结果缓存、还有从记忆库检索回来的历史信息。”

“多 Agent 并发的问题在于，这些开销不共享。每个 Agent 有自己的对话历史，有自己的工具调用结果，有自己的任务状态。就算 system prompt 相同可以共享缓存，动态生成的部分也没办法复用。”

05、Agent 的工作记忆、情景记忆和长期记忆应该如何分层？

老王放下茶杯，翻了翻简历背面。“说说你对 Agent 记忆分层的理解。工作记忆、情景记忆、长期记忆，怎么分？”

“工作记忆对应当前的上下文窗口。当前对话的内容、system prompt、工具调用的结果，全在这里。”

“情景记忆存的是过往交互的日志。比如上周和用户聊过什么、之前执行过哪些任务、哪些成功了哪些失败了。按时间和场景索引，需要的时候检索出来注入工作记忆。”

“语义记忆，也就是知识库。用户手册、产品文档、领域知识，切成块之后做向量索引。检索方式是语义相似度匹配，和情景记忆按时间检索不同。”

“程序记忆，存的是技能和执行模式。Skill 定义文件、工作流模板、常用的操作序列，这些是‘怎么做事’的知识，不是‘知道什么’的知识。”

“PaiCLI 目前实现了前两层：短期的对话记忆和长期的事实记忆。事实记忆持久化到本地文件，跨会话可用。情景记忆和程序记忆目前是隐式的——对话历史里天然包含了过往交互，Skill 文件天然就是程序记忆。”

为什么不把所有记忆都放进上下文窗口？

“两个原因。”

“第一，上下文窗口有上限。”

“第二，注意力稀释。Transformer 的注意力机制在上下文越长的时候，对每个 token 的关注度越分散。塞进去太多无关信息，模型反而更容易忽略真正重要的内容。分层的目的就是让工作记忆里只保留当前任务最需要的信息，其余的按需检索。”

06、Redis、向量数据库、关系数据库和对象存储分别适合保存什么 Agent 数据？

“Redis 适合存会话状态和短期缓存。Agent 的当前会话 ID、最近几轮对话历史、工具调用的临时结果，这些数据访问频率高、生命周期短。Redis 的读写速度快，TTL（自动过期）机制能自动清理过期数据。PaiCLI 的会话状态就存在 Redis 里，7 天自动过期。”

“向量数据库适合存语义记忆。知识库文档切块之后生成向量索引，用户提问时做相似度检索。关键词匹配找不到的东西，语义检索能找到。派聪明用的是 Elasticsearch 的混合检索，BM25 关键词匹配和向量语义检索并行跑，结果合并排序。”

“关系数据库适合存结构化的业务数据。用户信息、任务执行记录、审计日志、评估结果，这些数据需要事务保障和复杂查询能力。Agent 的审计日志尤其重要——谁在什么时间调用了什么工具、结果是什么、有没有经过人工审批，这些都要可追溯。”

“对象存储适合存大文件和长期归档。用户上传的文档、Agent 生成的报告、对话历史的原始日志，数据量大但访问频率低。对象存储容量大、成本低，适合做冷数据的落盘。”

07、如何设计上下文压缩，避免 Agent 运行时间越长、Token 消耗越大？

老王看了一眼手表，无名指上的戒指反了一下光。“上下文管理是 Agent 工程化绕不开的问题。聊聊你们怎么做压缩的。”

“思路是‘近处保全、远处摘要’。”

“最近 N 轮对话保持原样，一个字都不动。PaiCLI 默认保留最近 3 轮。因为用户最近说的话大概率和当前任务直接相关，压缩了会丢失关键信息。”

“再往前的历史消息，做 Map-Reduce 摘要。每 5 条消息分成一组，每组让 LLM 生成一段摘要，然后把所有摘要合并成一段总结。压缩后的总结加上最近 3 轮的原始对话，替换掉原来的完整历史。”

“触发时机是 token 占用达到预算的 70% 左右。不能等到快满了才压缩，因为压缩本身需要调用 LLM 做摘要，也要消耗 token 和时间。留出余量才能从容处理。”

“摘要的时候有一个细节很重要：区分临时信息和稳定事实。‘用户让我写一个排序函数’这种临时请求，压缩后可以丢掉。但‘项目路径是 /Users/xxx/project’‘用户偏好 TypeScript’这种稳定事实，必须保留。PaiCLI 的压缩模块会做这个区分，临时的过滤掉，稳定的提取出来放进长期记忆。”

为什么不直接截断旧消息？

“截断是最简单的方案，但容易丢信息。”

“假如 Agent 在第 3 轮和用户确认了一个重要的设计决策，到第 20 轮的时候这条消息被截断了。Agent 就忘了这个决策。摘要至少能把关键信息的语义保留下来，虽然细节模糊了，但核心结论还在。”

“当然，如果 LLM 摘要调用失败了，PaiCLI 也会降级到简单截断。”

08、KV Cache 量化、分页和卸载分别解决什么问题？

“量化解决的是‘单个 KV 太大’的问题。把 KV Cache 从 BF16 精度降到 INT8，每个元素从 2 字节变成 1 字节，显存占用直接减半。INT8 量化几乎无损，对生成质量的影响很小。继续降到 INT4 可以再减半，但精度损失会比较明显，适合对质量要求不那么高的场景。”

“分页解决的是‘内存碎片’的问题。传统做法是给每个序列预分配一块连续的显存来放 KV Cache，但序列长度事先不确定——分多了浪费，分少了不够用。vLLM 的 PagedAttention 把 KV Cache 切成固定大小的页，按需分配，不要求连续存储。就像操作系统的虚拟内存分页一样。好处是多个序列可以共享相同前缀的页，比如 system prompt 部分只存一份。”

“卸载解决的是‘显存放不下’的问题。把暂时用不到的 KV Cache 搬到 SSD 上，需要的时候再搬回来。本质是拿延迟换容量，适合超长上下文的离线任务。”

09、一个长时间运行的 Agent，如何实现状态持久化和故障恢复？

“靠快照机制。”

“思路是每轮执行前后各打一次快照。pre-turn 快照在 LLM 调用之前保存当前状态，post-turn 快照在这一轮执行完之后异步保存。”

“快照里存的是 Agent 的完整运行状态：对话历史、记忆内容、任务进度、工具调用结果、当前执行到哪个步骤。这些信息整合在一起，才能完整还原 Agent 中断前的状态。”

“PaiCLI 用的是本地文件系统，在项目目录下有一个专门的快照目录。也可以用数据库，取决于部署环境。”

“恢复的时候，找到最近一个完整的 post-turn 快照，加载回来，跳过已经完成的步骤，从下一个待执行的步骤继续。如果某一轮的 post-turn 快照写到一半 Agent 就挂了，就回退到 pre-turn 快照，重新执行这一轮。”

为什么不用数据库事务来保障一致性？

“数据库事务保障的是单行或多行数据的原子性。但 Agent 的状态横跨对话历史、记忆存储、任务进度、工具调用结果，这些可能分布在不同的存储里。跨存储的分布式事务成本太高，快照做全量保存、恢复时全量加载，反而更简单可靠。”

10、如果 Agent 突然出现延迟升高，应当监控 Token、显存、内存和工具调用中的哪些指标？

老王把简历翻回正面放好。“最后一题，偏实际运维的。Agent 突然变慢了，你怎么排查？”

“分四个维度看。”

“Token 维度先查输入 token 数。如果最近几轮的输入 token 突然变大，说明上下文在膨胀——可能是压缩没触发，也可能是某次工具调用返回了大量数据没做截断。再查 Prompt Cache 的命中率，命中率下降意味着每次请求都要重新计算完整的上下文，延迟和成本同时上升。”

“显存和内存维度看 KV Cache 的占用量和 batch 队列深度。KV Cache 占用接近显存上限的时候，新请求只能排队等老请求释放，延迟自然上升。内存方面看进程的常驻内存占用，如果持续增长不回落，可能有内存泄漏或者某个 Agent 的上下文一直在膨胀没被压缩。”

“工具调用维度查三个指标：单次工具调用的耗时、是否有超时重试、调用频率有没有异常增长。PaiCLI 的审计日志里记录了每次工具调用的名称、参数、耗时和结果状态，查日志一眼就能定位到是哪个工具拖慢了整体。”

“系统维度看 GPU 利用率和网络延迟。GPU 利用率打满说明算力不够用了，利用率很低但延迟高说明瓶颈不在计算而在数据传输或排队。如果 Agent 要调用外部 API，网络延迟的波动也需要关注。”

PaiCLI 如何写到简历上？

项目名称：PaiCLI — 终端 AI Agent 命令行工具

项目简介：对标 Claude Code 的 Java 版终端 Agent，支持 ReAct、Plan-and-Execute、Multi-Agent Team 三种执行模式，具备多轮对话、代码搜索、工具调用、上下文压缩和状态恢复等能力。

技术栈：Java 21 + Spring AI + Redis + Elasticsearch + MCP 协议

核心职责：

• 设计并实现 Agent 双层记忆架构，短期记忆存储当前会话上下文并按 token 预算动态裁剪，长期记忆持久化到本地文件并通过时间衰减和语义相关度加权检索，跨会话复用用户偏好和项目信息
• 实现 Map-Reduce 上下文压缩机制，保留最近 3 轮完整对话，旧消息按 5 条一批生成摘要后合并，触发阈值设在 token 预算的 70%，配合事实提取过滤临时请求保留稳定信息，支撑 Agent 长时间运行
• 构建 pre-turn/post-turn 快照系统，在每轮 LLM 调用前后分别保存 Agent 完整运行状态（对话历史、记忆、任务进度、工具调用结果），支持从最近有效快照恢复执行，实现故障自动回退
• 设计 Multi-Agent Team 模式下的资源隔离策略，每个 Worker 维护独立对话历史和工具集，通过并发上限控制（默认 2 个 Worker）防止多 Agent 内存叠加导致 OOM
• 搭建结构化审计日志系统，记录每次工具调用的名称、参数、耗时、审批状态和执行结果，自动脱敏 API Key 和 Token 等敏感信息，支撑延迟排查和安全审计

ending

以前面试聊的是八股文、并发、中间件。现在聊的是 KV Cache 怎么优化、Agent 的记忆怎么分层、上下文膨胀了怎么压缩。

知识结构在变，但工程能力的内核没变——谁能把系统做稳、把问题想清楚、把方案落到代码里，谁就是稀缺的。

加油吧，兄弟姐妹们。

下期见。