AI 面试全景知识体系¶

本文档整合自《Agent 面试全景梳理》与《AI 面试知识体系整合手册》两份材料，按照"基础理论 → 核心技术 → 面试实战 → 项目落地 → 趋势展望"的逻辑链条重新组织，覆盖大模型微调、RAG 检索、Agent 核心概念、上下文工程、面试经验、AI 测试、Java 后端及前沿趋势，形成一份全方位的 AI 面试备战资料。

目录¶

大模型微调技术：LoRA 与 LoRA-SVD
1.1 经典 LoRA 原理
1.2 LoRA 的局限性
1.3 LoRA-SVD（"龙虾"算法）核心原理
1.4 LoRA-SVD 优势对比
1.5 面试回答框架
Agent 面试核心要点
2.1 项目场景选择
2.2 技术选型原则
2.3 Agent 核心概念深挖
- 2.3.5 ReAct 模式：Chain vs Tool vs ReAct
- 2.3.6 Agent 五要素
- 2.3.7 ReAct Loop 循环详解
2.4 工程化思维
2.5 评测（Eval）
2.6 软实力考察
RAG 检索增强架构
3.1 RAG 基础工作流程
3.2 传统 RAG 的痛点：上下文碎片化
3.3 Claude Contextual Retrieval
3.4 Agentic Search：Grep 与 RAG 的路线之争
3.5 混合检索方案与工程落地
3.6 长上下文 vs RAG：面试陷阱题
3.7 向量数据工程全流程
上下文工程：TRAE + MCP 实操体系
4.1 写入（持久化上下文）
4.2 选取（动态筛选上下文）
4.3 压缩（精简上下文）
4.4 隔离（多智能体上下文管理）
大厂面试经验对比
5.1 字节跳动
5.2 腾讯
5.3 阿里巴巴
5.4 三家对比总结
小厂面试经验
面试题汇总
7.1 字节 AI 全栈一面题
7.2 小厂 AI 应用开发面试题
AI 测试精华
8.1 AI 测试核心要点
8.2 大模型评测方法
8.3 AI 测试简历写法
RAG 企业智能知识库项目实战
9.1 项目架构与难点攻克
9.2 向量检索优化
9.3 混合检索与权限控制
9.4 记忆机制与流式输出
- 9.4.1 三层记忆架构（面试高分设计）
- 9.4.2 异步影子 Agent（自我进化）
- 9.4.3 面试总结三关键词
- 9.4.4 短期记忆与长期记忆
Java 后端面试核心知识点
- 10.1 MySQL 事务与锁
- 10.2 ThreadLocal
- 10.3 JVM 深度问答
前沿技术趋势
- 11.1 Mamba 状态空间模型
- 11.2 2026 年招聘趋势
Transformer 长上下文优化
- 12.1 三大瓶颈
- 12.2 四大优化方案
- 12.3 面试总结话术

一、大模型微调技术：LoRA 与 LoRA-SVD¶

1.1 经典 LoRA 原理¶

经典 LoRA（Low-Rank Adaptation，低秩适应）的核心思想是：在预训练冻结的权重矩阵 $W_0 \in \mathbb{R}^{d \times k}$ 旁并联一个旁路。这个旁路通过两个低秩矩阵 $A \in \mathbb{R}^{r \times k}$ 和 $B \in \mathbb{R}^{d \times r}$ 的乘积来模拟权重的增量更新 $\Delta W$：

\[\Delta W = B \cdot A\]

其中，秩 $r \ll \min(d, k)$。

初始化策略： - 矩阵 $A$ 采用高斯随机分布进行初始化。 - 矩阵 $B$ 采用全零（Zeros）进行初始化。

目的： 在训练开始的初始阶段（$t=0$），$\Delta W = B \cdot A = 0$，确保微调开始时旁路对主网络无副作用，模型输出完全等价于原始预训练模型。

1.2 经典 LoRA 的局限性¶

方向盲目性（Blind Initialization）： 矩阵 $A$ 的随机初始化导致微调初期探索方向完全随机，未利用预训练模型本身蕴含的丰富特征空间方向。
收敛较慢： 初始方向随机，网络需要较多 step 去调整并寻找真正优化的低秩子空间。

1.3 LoRA-SVD（"龙虾"算法）核心原理¶

LoRA-SVD 的核心逻辑是：利用奇异值分解（SVD），直接从预训练权重的特征空间中提取最重要的低秩基底，来指导微调旁路的初始化。

1.3.1 SVD（奇异值分解）基础¶

对于任意矩阵 $M \in \mathbb{R}^{d \times k}$，可分解为：

\[M = U \cdot \Sigma \cdot V^T\]

$U$ 和 $V^T$ 是正交矩阵，分别代表左奇异向量和右奇异向量，指明空间的特征方向。
$\Sigma$ 是对角矩阵，对角线元素 $\sigma_i$ 从大到小排列，代表对应特征方向的能量（信息量/重要程度）。

1.3.2 LoRA-SVD 的初始化策略¶

提取前 $r$ 个特征： $$W_0 \approx U_r \cdot \Sigma_r \cdot V_r^T$$ 其中 $U_r \in \mathbb{R}^{d \times r}$，$\Sigma_r \in \mathbb{R}^{r \times r}$，$V_r^T \in \mathbb{R}^{r \times k}$。
构建旁路矩阵： 将提取的优质特征直接赋予 LoRA 的 $A$ 和 $B$ 矩阵：
令 $B = U_r$
令 $A = \Sigma_r \cdot V_r^T$
零值平滑过渡： 为保持经典 LoRA 在 $t=0$ 时 $\Delta W = 0$ 的特性，LoRA-SVD 通常引入学得的缩放因子或残差矩阵。

1.4 LoRA-SVD 优势对比¶

特性	经典 LoRA	LoRA-SVD
A 矩阵初始化	随机高斯分布（盲目搜索）	SVD 提取的右奇异向量（沿主成分方向）
B 矩阵初始化	全零矩阵	SVD 提取的左奇异向量
初始优化方向	随机，需较多迭代步数校正	对齐预训练模型最优特征子空间
收敛速度	较慢	极快（起点即高点）
微调效果	数据量少时易陷入局部最优	更鲁棒，能更好保留预训练知识

核心原理解析： - 站在巨人的肩膀上： SVD 精准定位预训练权重特征表示中"能量"最大的前 $r$ 个方向。 - 精准打击： 微调一开始就精确定位模型最重要的主成分空间，后续梯度更新用极少的训练步数即可达到甚至超越经典 LoRA 的效果。

1.5 面试回答框架¶

按三步法作答：

亮出定义，说明背景：

"LoRA-SVD 是针对经典 LoRA 初始化盲目性的改进方案。经典 LoRA 由于 A 矩阵采用随机高斯初始化，导致微调初期优化方向随机、收敛较慢。"
硬核拆解，阐述机制：

"LoRA-SVD 通过对预训练权重矩阵进行 SVD 分解，提取前 r 个最大奇异值对应的左、右奇异向量，分别初始化 LoRA 的 B 和 A 矩阵。同时通过消去机制确保初始时刻微调旁路对原模型的增量为 0。"
总结优势，体现落地思考：

"本质是让模型微调直接在预训练模型最核心的特征子空间中优化，带来更快的收敛速度，在小样本微调或下游任务与预训练任务差异较大的场景下表现更优。"

二、Agent 面试核心要点¶

2.1 项目场景选择¶

面试官看简历的前 30 秒决定追问方向，核心看场景是否适合做 Agent。

不好的场景： 一个场景用豆包（或普通对话模型）就能解决，硬上 Agent 属于伪需求。

好的场景： 需要多步推理、跨多个数据源整合信息、处理异步任务——一次对话搞不定，面试官才会觉得值得深挖。

2.2 技术选型原则¶

技术方案不是越多越好。常见减分写法：LangGraph、Agent、Neo4j、Milvus、Chroma、RAG、LoRA 微调七八个列在一起。

面试官会问： - 数据量多大？为什么用 Milvus？（几千条数据用分布式向量数据库是选型失误） - 为什么用这个技术而不是别的？

关键点：写清楚为什么选它。

2.3 Agent 核心概念深挖¶

2.3.1 Workflow 与 Multi-Agent 的区别¶

不是加了 Router 分发任务就是 Multi-Agent。

维度	Workflow（工作流）	Multi-Agent（多智能体）
决策方式	固定流程、代码控制	自主决策
通信方式	流程编排传递数据	相互调用、自主通信
典型结构	DAG 编排	A2A 协议协作

Anthropic《Building Effective Agents》已基本形成行业共识：Agent 之间要自主决策、能相互调用、能通信才算 Multi-Agent。实际最佳实践是两者组合使用——Workflow 做规定动作，Agent 做自主决策。

2.3.2 Memory 在 System Prompt 中的位置¶

Memory 应放在 System Prompt 的最前面。原因是 Prompt 变化少的部分放在前面，缓存命中率高，可降低成本。如果认为"模型对最近的内容更敏感"而放最后，是把因果关系搞反了。

2.3.3 Skills 和 MCP 的关系¶

Skills 和 MCP 不是同一层次的概念。MCP（Model Context Protocol）是 Agent 通信协议，相当于多 Agent 协作通信的"语言"。

2.3.4 循环消息格式¶

高频考点：Tool 的 response 用 user 还是 assistant 角色传回？

正确答案：user 角色。 因为它是外部系统反馈的内容，不是模型自己生成的，否则后续推理会乱。

2.3.5 ReAct 模式：Chain vs Tool vs ReAct¶

高频面试题：为什么选择 ReAct 而不是纯 Chain 或者 Tool Use？

这是腾讯 AI 应用开发一面经典题，核心考察对 Agent 本质的理解。

模式	说明	特点
纯 Chain（纯链条）	A → B → C → D 的固定流程	线性顺序执行，无分支无决策
Tool Use（工具调用）	调用外部工具（地图、浏览器、计算器等）	能使用工具，但无推理循环
ReAct（推理 + 行动）	Reasoning + Acting，推理加行动	推理结合行动，能根据观察继续决策

ReAct 的核心优势： 将推理（Reasoning）和行动（Acting）结合起来，让 Agent 能根据观察结果（Observation）继续决策，而非单一生成回复。Cursor、Claude Code、Codex 等能真正干活的 Agent 工具，底层都离不开 ReAct 这种"推理 → 行动 → 观察 → 再决策"的思想。

ReAct 这个名字源自 2022 年的研究论文 "ReAct: Synergizing Reasoning and Acting in Language Models"，并非最近才流行起来。

2.3.6 Agent 五要素¶

判断是不是 Agent，看以下五个要素：

目标（Goal）： Agent 要完成什么任务
大脑（Brain）： 大语言模型作为推理核心
工具（Tools）： 可调用的外部能力（API、搜索、代码执行等）
循环（Loop）： 反复推理-行动-观察的过程
记忆（Memory）： 短期记忆（上下文窗口）+ 长期记忆（外部存储）

2.3.7 ReAct Loop 循环详解¶

理解 Agent 怎么工作，核心看这个循环：

循环流程： 思考（Think）→ 任务规划 → 行动（Act）→ 观察结果（Observe）→ 反思不足 → 重复以上过程直到完成。

最简 Agent 循环伪代码示例：

while True:
    # 1. 让大模型根据当前信息和可用工具，思考下一步
    next_action = llm.think(context, available_tools)

    # 2. 如果大模型不需要再调用工具，说明任务完成
    if next_action.is_final():
        return next_action.result

    # 3. 如果大模型决定调用工具，系统执行该工具
    observation = execute_tool(next_action.tool)

    # 4. 将工具执行结果加入上下文，继续循环
    context += observation

生活例子——AI 点外卖：

你跟 AI 说："帮我点一份 30 元以内清淡点的晚饭。"

思考： 先看看附近有什么店
行动： 打开外卖工具
观察： 有粥店、沙拉、麻辣烫
反思： 清淡 + 30 元以内 → 粥店最合适
行动： 下单青菜粥和鸡蛋豆浆
观察： 鸡蛋售罄
重试： 换成青菜粥 + 豆浆
完成： 下单成功

注意： 涉及付款下单这类动作，最好让用户确认后再执行。

误区提醒： 不是所有问题都需要 Agent。简单任务（翻译、总结、润色、写邮件、写文案）单次调用反而更好——硬上 Agent 成本更高、速度更慢、效果未必更好。现实世界的不确定性越高，Agent 的价值越大。

2.4 工程化思维¶

这是很多人低估的部分，也是翻车最惨的地方。

2.4.1 上下文管理¶

上下文怎么分层？
每层什么时候触发清理/压缩？
长对话如何防止 token 爆炸？
超出限制时：滑动窗口还是动态摘要？

2.4.2 异常处理¶

Agent 的三个崩溃点： - 最大迭代次数限制 - 循环模式检测 - 异常回流的策略（重试、降级、人工介入）

2.4.3 系统设计题示例¶

"如果让你做一个抖音创作者 AI 助手，你会怎么设计 Agent 框架？"

回答要点： 先聊业务流程，再聊技术栈。不要一上来就聊框架——AI 团队缺的是真正能把产品落地的人。

2.4.4 多 Agent 协作的异常处理¶

面试追问： - 如果其中一个 Agent 持续输出低质量结果，怎么动态调整整个工作流？ - Multi-Agent 架构的三层结构：路由层、管理层、执行层 - Agent 之间怎么通信？→ A2A 协议 - 怎么避免死锁？→ 超时信号 + 终止信号 - 结果聚合方案？→ 投票、权威仲裁、分层汇总

2.5 评测（Eval）¶

很多人简历上要么没数据，要么写个准确率 90%+。面试官追问： - 测试集怎么构建的？ - 覆盖哪些 case？ - 评估指标是什么？ - 怎么自动化回归？

建议： 哪怕项目很小，也要加上评测。哪怕手动测了 50 个 case，也非常有价值。

2.6 软实力考察¶

平时怎么写代码、看哪些信息源？
是否深度使用 AI 工具？能否讲清楚 prompt 怎么写、MCP 怎么搭、工作流怎么构建？
信息源：Hacker News、YC、OpenAI 员工在 X 上的发言、前沿 blog——这个行业变化以周为单位，面试官通过信息源判断你的参与度。

三、RAG 检索增强架构¶

3.1 RAG 基础工作流程¶

传统 RAG 核心流程分为四步：

文档切割（Chunking）： 将长文档按固定大小切分为文本块。
Embedding 向量化存储： 通过 Embedding 模型将文本块转化为向量，存入向量数据库。
语义相似度匹配检索： 计算用户问题向量与库中向量的相似度，召回 Top-K 个 Chunk。
增强生成： 将召回的文本块与用户问题一起送入大模型生成答案。

3.2 传统 RAG 的痛点：上下文碎片化¶

传统 RAG 按固定大小硬性切分文档，导致单个 Chunk 丢失其在整篇文档中的背景信息（Context）。例如：

一个 Chunk 内容为："由于研发投入加大，该季度的运营利润下降了 10%。"

当用户搜索"2024 年第二季度 Google 的运营利润变化"时，该 Chunk 因不包含"2024 年""第二季度""Google"等上下文实体而无法被检索匹配。这就是上下文碎片化（Contextual Fragmentation）。

3.3 Claude Contextual Retrieval¶

3.3.1 解决方案：三步增强法¶

步骤一： 将"整篇文档"和"当前单个文本块"同时输入 LLM，让模型生成一段 50-100 token 的上下文描述。

步骤二（Pre-pending）： 将生成的上下文背景直接拼接在原始 Chunk 最前面。

步骤三： 将增强后的 Chunk 进行 Embedding 并存入向量数据库；BM25 关键词索引同样基于增强后的文本建立。

效果对比： - 传统 Chunk： "由于研发投入加大，该季度的运营利润下降了 10%。" - 增强 Chunk： "[由 Claude 生成的上下文]：这份文档是关于 Google 公司 2024 年第二季度的财务业绩报告。... [原始文本]：由于研发投入加大，该季度的运营利润下降了 10%。"

3.3.2 官方实验数据¶

检索方案	传统 RAG 错误率	上下文检索错误率	性能提升
仅向量检索（Embedding Only）	27%	17%	相对提升 37%
混合检索（Embedding + BM25）	12.3%	5.3%	相对提升 57%

核心结论：当 Embedding + BM25 混合检索与 Contextual Retrieval 结合时，检索失败率降至 5.3%。

3.3.3 工程落地与成本优化¶

Prompt Caching： 同一文档的不同 Chunk 共享相同完整文档前缀，缓存后可降低 90% 输入成本。
低成本小模型： 使用 Claude 3.5 Haiku 等轻量模型生成上下文。

3.4 Agentic Search：Grep 与 RAG 的路线之争¶

3.4.1 Claude Code 的选择¶

Claude Code 创造者 Boris Cherny 明确表示：早期版本使用了 RAG 加本地向量数据库，但测试发现 Agentic Search（基于 grep/glob 的主动检索）效果"好很多"。

3.4.2 为什么 Grep 在代码检索中往往优于 RAG？¶

痛点一（时效性）： 代码库一天改动几十次，RAG 索引建完即过时。

痛点二（精确性）： 代码检索需要搜索函数名、类名等精确字符串，语义搜索会捞出一堆不相关的干扰项。

痛点三（安全隐私）： 代码是企业核心资产，多一套外部系统就多一重风险。

3.4.3 Agentic Search 的工程细节¶

每轮 grep 的结果成为下一轮搜索的判断依据，不断收窄范围直至锁定目标——本质是复现资深程序员排查 Bug 的工作方式。

加分细节——隔离噪音： Claude Code 在处理复杂检索时拉起独立子进程跑 grep/glob/read，用响应最快的 Haiku 模型，只给主模型递送摘要，防止原始输出塞满上下文窗口。

3.4.4 两种路线的本质分歧¶

维度	Cursor（RAG 路线）	Claude Code（Agentic Search）
设计哲学	投资基础设施换语义能力	保持极简换可靠性和可控性
定位	产品化工具	Unix 工具
优势	大型陌生代码库更"聪明"	实时性好，安全可控
代价	索引同步、加密处理、权限边界	大规模 Monorepo 场景遇瓶颈

3.4.5 Grep 的短板与混合方案¶

对于超大型 Monorepo（几百万文件、命名惯例混乱），纯 grep 会遇天花板，提前建索引做语义预筛 + grep 精确确认是更合理的混合方案。

3.5 混合检索方案与工程落地¶

综合最佳实践：Embedding + BM25 + Rerank 的组合方案能将错误率压至 5% 左右。关键在于数据驱动的选型而非技术新旧论。

3.6 长上下文 vs RAG：面试陷阱题¶

面试题：长上下文（Long Context）最终会杀死 RAG 吗？

这是典型的面试陷阱题。答"会"显得没有工程落地经验、不懂成本算账；答"不会"又好像在否定技术进步。正确答案：不会，但它们的协作关系变了。

3.6.1 混合式 RAG 架构（漏斗模型）¶

长上下文和 RAG 不是竞争关系，而是最佳拍档，构成一个从广到深的漏斗：

第一阶段——检索增强（RAG）：解决广度问题 - 企业数据量远超模型窗口（如 1B 数据、全互联网信息） - 物理存储上限永远比模型窗口大 - RAG 的核心任务：从海量数据中挑出最相关的几百本文档 - 好比去图书馆查资料，虽然模型能背下一书架书，但整个图书馆有几百万本书，你不可能都搬回家

第二阶段——上下文构建（Context Building）：解决质量问题 - 挑出 50 本文档后，不能一股脑全扔给模型 - 需要做重排序（Rerank）和清洗，去掉无关广告、错误旧数据 - 构建出 5 万~10 万 token 的高质量 Prompt

第三阶段——长窗口模型（Long Context）：解决深度问题 - 模型在高质量长上下文上进行深度推理，看懂跨段落的逻辑 - RAG 负责缩小范围，长上下文负责精读

3.6.2 三个核心指标证明 RAG 不可替代¶

指标	问题	解决方案
钱（Token 成本）	每次把 100 本书重复算一遍，费用惊人	RAG 减少 99% 输入量，省真金白银
慢（首字延迟）	超大上下文首字延迟可达分钟级	RAG 只检索必要信息，控制在秒级
准（中间迷失）	过长上下文导致模型"中间迷失"	RAG 先去粗取精，回答反而更准确

核心公式： RAG 解决"知道得广"，Long Context 解决"理解得深"。未来的趋势是 Long RAG——利用 RAG 检索出高质量长内容，再让模型精读。

3.7 向量数据工程全流程¶

面试题：向量数据如何从原始文档最终入库？

这是大模型专家级面试题，远超"把文档切开直接上传"的回答。完整的工业级流程如下：

3.7.1 第一步：格式标准化（数据清洗）¶

原始文档形式多样：扫描件 PDF、格式混乱的 HTML、堆满表格的 Word。直接用切片工具处理，里面全是乱码和广告噪音。

方案： 使用 Unstructured 或布局分析算法做格式标准化，提取干净的文本内容。

RAG 名言： Garbage in, garbage out. 垃圾进去，出来的也必然是垃圾。

3.7.2 第二步：元数据提取¶

为什么必须提取元数据？ 元数据就是给文档打标签（发布时间、作者、保密级别等）。有了元数据，检索时可以只搜"2024 年以后的文档"或"技术部的文档"，这叫元数据过滤——没有这一步检索就是盲目的大海捞针。

3.7.3 第三步：高级切片策略¶

固定 500 字符切分会导致语义断裂——一句话讲到一半被切断，怎么可能搜得准？

工业级方案——父子块架构（Small-to-Big）：

层级	用途	特点
子块（Small Chunk）	入库检索	向量特征更明显，搜得准
父块（Big Chunk）	送大模型生成	上下文足够丰富

工程要点： - 使用递归切分而非固定长度切分 - 设置 10%~20% 的滑动窗口重叠，给上下文留缓冲带 - 入库存小块（保证搜索精度），检索出小块后返回对应的大块给大模型（保证生成质量）

3.7.4 第四步：向量化（Embedding）¶

模型选择： 通用场景用通用 Embedding 模型；医疗、法律等专业领域需对 BGE-M3 或 M3E 等模型做微调，让模型听懂行业术语。

维度选择权衡： 维度过高→无关信息过多；维度过低→特征不明显。

3.7.5 第五步：索引算法与入库优化¶

索引选择： - Flat（暴力搜索）： 适合千万级以下数据 - HNSW（基于图的索引）： 千万级以上数据，速度和精度的最佳平衡

批处理优化： 入库时不能一条一条发请求，大工程必须考虑吞吐量，做批处理优化。

3.7.6 第六步：闭环验证——混合检索 + 重排序¶

向量检索有时会产生语义幻觉——比如搜"如何开户"可能召回"如何销户"，因为语义太像了。

破局方案——混合检索流程：

向量检索（海选）： 从向量库召回 Top 50
关键词检索（BM25）： 精确匹配关键词
Rerank 重排序（精选）： 从 Top 50 中选出最靠谱的 Top 5

进阶技巧——HyDE 技术： 让 AI 先模拟一个答案，拿着答案去检索，召回率直接翻倍。

3.7.7 专家级总结三关键词¶

关键词	说明
精细化预处理	数据质量永远是 RAG 系统的天花板
上下文保湿	用父子块和重叠机制守护语义完整性，不让 AI 断章取义
工程化闭环	入库后持续通过混合检索 + 重排序调优召回精度

四、上下文工程：TRAE + MCP 实操体系¶

TRAE 结合 MCP 落地的上下文工程包含四大核心技巧：写入、选取、压缩、隔离。

4.1 写入（持久化上下文，跨会话复用）¶

核心说明： 将用户偏好、项目配置、核心结论等高价值信息持久化，突破单次对话限制；依托 MCP 对接向量数据库、知识库完成上下文持久存储。

操作步骤： 1. 添加存储型 MCP Server，优先选用 Knowledge Graph Memory MCP，以知识图谱结构化存储上下文。 2. 新建自定义智能体，绑定上述 MCP Server。 3. 通过系统提示词划定持久化信息类型与存储逻辑。

4.2 选取（动态筛选相关上下文，提升准确性）¶

核心说明： 依靠 MCP 调用外部检索工具，动态抓取与当前任务强相关的信息，屏蔽无关干扰；典型搭配 RAG 检索增强。

操作步骤： 1. 前置部署 Sequential Thinking MCP Server，用于分步拆解检索逻辑。 2. 切换内置 MCP 智能体（@builder with MCP）。 3. 选用高能力大模型（如 Gemini 2.5 Pro）。 4. 输入标准化检索提示词。

4.3 压缩（精简上下文，降低 Token 消耗）¶

核心说明： 上下文文本过长时，借助 MCP 调用压缩工具，用更少 Token 承载完整核心信息。

操作步骤： 1. 双服务部署：文本压缩 MCP Server + Sequential Thinking MCP Server（划定压缩优先级：优先保留 API 参数、步骤要点，删减描述性文字）。 2. 配置压缩策略提示词。

实践效果： 1000 字项目文档经 MCP 压缩至 300 字关键要点，信息无丢失。

4.4 隔离（多智能体上下文管理，避免信息干扰）¶

核心说明： 依托多智能体架构 + MCP 资源隔离配置。各子智能体只处理自身业务域信息，仅向主智能体上报核心结论，解决多模块项目跨域长上下文互相干扰、性能下滑问题。

操作步骤： 1. 为每个业务模块搭建专属知识库 MCP Server，模块间资源完全独立。 2. 搭建分层多智能体：子智能体绑定专属 MCP，仅处理自身模块查询分析，只输出核心结论。

五、大厂面试经验对比¶

5.1 字节跳动¶

特点： 技术密度最高，追问工程实践细节。

面试流程： - 一面：基础扎实度考查 - 二面：项目深度挖掘 - 三面：Agent 系统设计和业务落地

高频考点： - 循环消息格式：Tool response 用 user 还是 assistant 角色传回？ - 训练流程：SFT → RL（RLHF 三阶段） - Agent 异常处理：最大迭代限制、循环检测、异常回流、重试降级、人工介入 - Rex 框架实现细节 - 如果召回结果质量越来越差，会先排查哪一层？（分块策略、嵌入模型、检索方式等）

面试风格： 面试官会"不太信"你的简历，通过追问验证是不是你自己做的。不会让背定义，而是顺着项目一点点往下刨。

5.2 腾讯¶

特点： 偏重工程协议和生态视野。

高频考点： - Workflow 与 Agent 的区别 - MCP（Model Context Protocol）和 A2A 协议 - 记忆系统：短期记忆、长期记忆、上下文传递 - 超限处理：滑动窗口还是动态摘要？

5.3 阿里巴巴¶

特点： 架构和业务都要考，要求最全面。

高频考点： - Workflow、Agent、Multi-Agent 三者的区别 - Multi-Agent 架构题：画出路由层、管理层、执行层三层结构 - 通信方式：A2A 协议 - 死锁避免：超时信号 + 终止信号 - 结果聚合：投票、权威仲裁、分层汇总 - 务实追问："做了这么多 Agent 项目，最终最大的瓶颈是什么？"

5.4 三家对比总结¶

维度	字节跳动	腾讯	阿里巴巴
侧重点	工程实践、技术深度	协议生态、工程视野	架构设计、业务落地
技术密度	最高	中	中高
典型追问	循环消息格式、异常处理	Workflow vs Agent、MCP	三层架构、通信协议
面试风格	深挖项目，验证真实性	考察工程视野	架构+业务并重

误区提醒： 不要把三家的考点混在一起统一准备。应该以自己的项目为核心，把难点提前准备好，引导面试官跟着你的节奏走。面试十家里：两家非常难，几家正常难度，还有几家感觉随便问问就过了。

六、小厂面试经验¶

6.1 0-20 人小厂 AI 应用开发面经¶

面试风格： 更务实，关注基础能力和实际工具使用。

常见问题：

问项目
项目用的是千问的什么模型？准确率怎么样？
是用 LangChain 做的吗？
怎么部署的？
了解过 K8s 和 Docker 吗？
Git 熟悉吗？
RAG 文档切分用的什么方式？几种切分方式有什么不一样？
chunk_size = 500 怎么得出来的？
Claude Code、Codex、Cursor 哪个用得多？
几个项目里 Codex 写代码的占比
大学都学哪些课程？
聊聊 Transformer 架构
注意力机制和 Encoder、Decoder 有什么关系？
Coze 和 Dify 使用过吗？有没有接过 API？

七、面试题汇总¶

7.1 字节 AI 全栈一面题¶

第一部分：项目实战、中间件、Java 并发与代理 AOP¶

项目中有没有遇到过重难点问题？能体现自己思考或解决手段的？
秒杀热点场景中，Lua 脚本是用来做什么的？为什么需要它？
Redis 分布式锁需要考虑哪些因素？
Redis 分布式锁还需要考虑哪些异常问题？对应解法？
除了看门狗和数据库兜底，还有其他异常情况吗？
Kafka 怎么保证消息不丢失？
方法调用时指定超时时间，超过就抛异常，怎么实现？
方案中涉及多少线程？每个请求都创建线程做定时器，生产环境能用吗？
这个思路行得通吗？
线程池用过吗？有哪些重要参数？
把任务交给线程池执行，能拿到什么对象？
Runnable 和 Callable 的区别？什么时候用哪个？
提交到线程池后，拿到的对象如何指定等待时间？超时后如何抛异常？
如果不希望业务方感知线程池，直接调用方法就有超时时间限制，怎么做？
能不能往代理方面想？静态代理和动态代理的区别？
什么时候需要动态代理？解决什么问题？
动态代理能不能和方法超时问题结合？
用环绕通知时，什么情况下需要用到？
HashMap 和 ConcurrentHashMap 的区别？

第二部分：Java 集合、BIO/NIO、MySQL 事务与索引¶

HashMap 为什么线程不安全？
ConcurrentHashMap 如何保证线程安全？弱一致性体现在哪？
强一致性和弱一致性分别是什么意思？
volatile 可见性和弱一致性是一回事吗？
BIO 和 NIO 的区别？
BIO 为什么通常一个连接对应一个线程？
NIO 为什么一个线程可以对应多个请求？
NIO 有哪些重要组件？Selector 是做什么的？
MySQL 有几种事务隔离级别？默认是哪一种？
可重复读隔离级别下，能彻底解决幻读吗？什么情况下会出现幻读？
MVCC 相关原理？
数据库事务的四个特性是什么？InnoDB 引擎如何实现 ACID？
索引有哪几种？联合索引用来做什么？
数据库建表时，对主键的选择需要考虑什么？

第三部分：数据库主键优化、网络协议、加密算法、多线程手撕¶

使用 UUID 做主键会有什么问题？UUID 唯一，为什么还会影响索引结构？
为什么 UUID 可能导致页分裂？
什么是 Agent？
HTTP 和 HTTPS 的区别？HTTPS 为什么更安全？
HTTPS 如何防止数据被篡改或中间人攻击？
HTTPS 访问网站时信息怎么流动的？
TLS/HTTPS 使用对称加密还是非对称加密？
证书从哪里获取？如何检查网站是否合法？
了解哪些对称/非对称加密算法？
手撕：三个线程按顺序交替打印，打印 10 次如何实现？

7.2 小厂 AI 应用开发面试题¶

（见第六章面试题列表）

八、AI 测试精华¶

8.1 AI 测试核心要点¶

AI 测试测什么¶

AI 测试要关注 AI 应用在真实业务中的质量： - 回答是否正确、是否稳定、是否安全、是否符合业务预期 - 是否能处理边界问题、是否存在幻觉 - 是否会泄露敏感信息 - 是否能被自动化评测持续监控

传统测试关注确定性输入输出，AI 测试面对的是非确定性、开放式输出和概率性质量问题。

AI 测试 vs 传统测试¶

维度	传统测试	AI 测试
输出确定性	有明确预期结果	不完全确定，多种正确答案
断言方式	简单断言	复杂断言
评估重点	功能正确性	语义质量
特殊风险	较少	需关注幻觉
安全合规	基础安全	需安全和合规测试
评测集	用例即可	需构建评测集
评估方式	自动化为主	人工 + 自动结合

Prompt 测试¶

指令是否清晰、输出格式是否稳定、角色设定是否生效
边界问题是否处理、是否容易被越狱
是否能拒答敏感问题
多轮对话上下文是否一致

Prompt 改动可能导致输出风格、准确性和安全性变化，需要回归测试。

RAG 测试¶

同时关注召回质量和生成质量： - 文档解析是否正确、分块是否合理 - 向量检索是否召回相关内容 - 答案是否基于知识库、引用是否准确 - 不知道时是否拒答、知识更新后是否生效 - 权限隔离是否正确

Agent 测试¶

Agent 测试更像流程测试、安全测试和异常测试的结合： - 任务分解是否合理、工具选择是否正确 - 工具参数是否正确、调用失败是否重试 - 是否越权调用工具、是否产生不可控操作 - 多步流程是否可追踪、最终结果是否符合预期

自动化评测¶

构建评测集 → 批量请求模型 → 保存输入输出 → 规则评分 / 模型评分 → 人工抽检 → 对比不同 Prompt 或模型版本 → 生成评测报告

AI 安全测试¶

Prompt 注入、越狱、敏感信息泄露、有害内容、隐私数据

8.2 大模型评测方法¶

评测目标¶

比较不同模型效果、评估模型升级影响
验证 Prompt 改动效果、发现模型弱点
监控模型质量变化、支撑业务上线决策

评测集构建¶

包含：高频业务问题、真实用户问题、边界问题、模糊问题、未知问题、恶意问题、多轮对话、长文本问题、格式要求问题、高风险问题。

每条数据最好包含：问题、标准答案或评分参考、标签、难度、业务场景。

评测维度¶

维度	说明
准确性	事实是否正确
完整性	是否覆盖关键点
相关性	是否答非所问
稳定性	多次回答是否一致
安全性	是否有害、是否泄露
格式遵循	是否按要求格式输出
业务适配	是否符合业务预期

评分方式¶

人工评分： 最准确，但成本高
规则评分： 正则、关键词匹配，适合格式/敏感词检测
模型评分： 用更强模型当裁判，适合开放性评估
对比评分： A/B 测试

评测流程¶

确定评测目标 → 2. 构建评测集 → 3. 定义评分标准 → 4. 批量执行 → 5. 自动评分 → 6. 人工抽检 → 7. 分析结果 → 8. 输出报告

8.3 AI 测试简历写法¶

推荐方向： 智能客服测试、RAG 测试、大模型评测、Prompt 回归评测、Agent 工具调用测试、AI 搜索测试、AI 自动化评测平台、AI 安全测试。

项目描述结构： - 项目背景：什么业务、什么模型、什么场景 - 职责：你负责什么 - 测试方法：评测集、评分维度、自动化方案 - 成果：发现了什么问题、提升了什么指标

九、RAG 企业智能知识库项目实战¶

9.1 项目架构与难点攻克¶

9.1.1 大文件分片上传与断点续传¶

问题： 大文件整体上传，网络波动导致上传失败需重新上传。

方案： 1. 将大文件分片上传，每片加上 MD5 指纹标识。 2. 用 Redis Bitmap 管理分片状态（0/1），内存占用小、响应速度快。 3. 所有分片上传完成后，通过 MinIO 的 compose object 方法按顺序合并。 4. 断点续传：根据 Redis Bitmap 只传输未上传的分片。

9.1.2 Kafka 异步流水线¶

Kafka 作为文档处理的异步流水线，负责文档上传、解析和向量化的异步解耦。
核心作用：削峰填谷——将高峰请求放入消息队列缓存，平稳推给后端。

9.2 向量检索优化¶

9.2.1 向量库选型：为什么选 Elasticsearch？¶

团队成员熟悉 ES，能开箱即用。
ES 同时支持向量检索 + 关键词检索 + 权限过滤。
企业级知识库项目涉及关键词匹配、权限过滤等条件，ES 能一站式解决。

9.2.2 Embedding 模型与维度选择¶

模型： 通义千问 2048 维词嵌入模型。
维度选择逻辑： 维度过高则无关信息过多；维度过低则特征不明显。2048 维平衡了语义表达与检索效率。

9.2.3 向量检索性能优化¶

最初未建索引时响应约 200 毫秒，建立索引后优化到 20 毫秒，提升 10 倍。

9.2.4 中文文档切割策略¶

切割过小：信息不完整，语义断裂。
切割过大：向量表示不精确，包含无关内容。
优化方案： 固定长度 + 滑动窗口，确保语句完整。
IK 分词器： ES 原生 standard 分词器按空格分词（适用英文），IK 分词器按中文短语、词语分词，适配中文场景。

9.3 混合检索与权限控制¶

9.3.1 混合检索流程¶

混合检索 = 向量检索 + 关键词检索（BM25）：

用户问题向量化 → 从向量库召回 Top 300。
BM25 关键词重排（关键词权重 1.0，向量相似度权重 0.2）。
取 Top 10，与问题一起送入大模型生成答案。

9.3.2 Prompt 设计原则¶

严格按用户上传的文档检索回答，不可编造。
每次回答必须标注来源。
系统指令为最高指令，不可修改——防止 Prompt 注入和泄露。
核心目标：满足企业知识库可控、安全、可信三个条件。

9.3.3 权限控制方案¶

方案： 组织标签 + RBAC / ABAC 权限模型。
流程：
文档上传时打组织标签。
用户登录生成 JWT Token，存储角色与组织信息。
权限过滤器拦截请求，提取组织标签。
校验文档公开状态、用户是否为所有者、组织标签是否匹配。
权限信息缓存至 Redis。

9.4 记忆机制与流式输出¶

9.4.1 三层记忆架构（面试高分设计）¶

面试题：如何设计记忆机制，让 AI 在第 100 轮对话时还能精准记得第一轮细节？

如果只是记大概意思，把 100 轮历史全塞进 Prompt 会导致：① Token 爆炸，成本受不了；② 上下文太长，模型抓不住重点。这道题考的不是怎么存，而是怎么扔和怎么找。

参考人类大脑机制，将记忆分为三层：

记忆层级	类型	存储方式	用途
短期记忆（短期记忆）	原始对话	保留最近 N 轮对话原文	保证对话连贯性
实体画像记忆（实体画像记忆）	结构化数据	提取为键值对存数据库	精准记忆用户事实
长期情景记忆（长期情景记忆）	语义向量	切片→向量化→向量数据库	模糊召回历史片段

第一层——短期记忆（保鲜）： 最近 N 轮对话必须原封不动保留，直接喂给模型。比如上一句说"我看了一部电影"，下一句问"好看吗？"，如果模型不记得上一句就不知道"它"指的是电影。这是为了连贯性。

第二层——实体画像记忆（精准记忆）： 用户说"我叫大鹏，我小时候被狗追过，所以我怕狗"。如果只把这句话转成向量存进数据库是很不保险的——因为"怕狗"是一个事实。

方案： 用后台程序提取成结构化数据 → user: 大鹏, fear: 狗。这就像给用户建了个档案袋，不管聊到第几千轮，只要用户问"我怕什么"，直接查档案袋绝对不会错。这是最核心的精准记忆。

第三层——长期情景记忆（模糊召回）： 不是所有话都是事实。比如聊了一段感悟、一个笑话，这些怎么存？切成片段转成向量存进向量数据库。到第 100 轮用户问"咱们之前聊过什么开心事来着？"，通过语义检索去数据库里捞出相关片段，这叫模糊召回。

中枢处理——第 100 轮时的 Prompt 拼装：

Prompt = System Prompt + 画像记忆(结构化数据) + 检索到的历史片段 + 最近对话

模型输出时既能回答当前问题，又能自然带出第一轮细节："记得呀，你第一轮说过怕狗。"——这就显得 AI 特别有灵魂。

9.4.2 异步影子 Agent（自我进化）¶

提取画像、存向量是耗时操作，不能让用户干等。设计异步架构：

用户说完话 → AI 先回复（快速响应）
后台启动一个影子 Agent，默默分析刚才的对话
把新的知识点存进库里，把旧的冲突清洗掉

这就叫不仅记得住，还能自我进化。

9.4.3 面试总结三关键词¶

分层存储： 别一股脑全存，分短期、结构化和向量三层
精准检索： 事实靠数据库，语境靠向量
动态更新： 记忆是活的，要有遗忘机制

9.4.4 短期记忆与长期记忆（原始补充）¶

短期记忆： 用 Redis 存储 7 天对话历史，结合上下文压缩和工具调用返回结果。
长期记忆： 用户上传的文档等信息存储到外部向量知识库进行持久化。

9.4.2 流式输出：WebSocket vs SSE¶

特性	SSE（Server-Sent Events）	WebSocket
通信方向	单向（服务端→客户端）	双向通信
适用场景	大模型对话单向推送	需要双向交互的场景
性能	实现简单，性能消耗小	全双工，功能更强

项目选型： RAG 知识库项目需要双向交互，选用 WebSocket；Agent Flow 项目只需单向推送，选用 SSE。

十、Java 后端面试核心知识点¶

10.1 MySQL 事务与锁¶

事务四大特性与实现：

原子性： undo log
一致性： 由其他三大特性保证
隔离性： MVCC + 间隙锁（临键锁）
持久性： 预写 redo log、双写机制、两阶段提交、checkpoint 刷盘机制

两阶段提交（2PC）： 先 prepare（写 redo log），再 commit（写 binlog），崩溃恢复时若 redo log 为 prepare 而 binlog 不完整则回滚事务。

事务隔离级别：

级别	脏读	不可重复读	幻读
读未提交	是	是	是
读已提交	否	是	是
可重复读（InnoDB 默认）	否	否	MVCC + 临键锁解决
串行化	否	否	否

锁机制：

SELECT ... FOR UPDATE 加意向排他锁（行锁），必须在事务中使用，必须命中索引否则锁全表。
行锁细分： 记录锁、间隙锁、临键锁。临键锁 = 记录锁 + 间隙锁，用于解决幻读。
意向锁： 表级锁，快速判断表中是否有行锁。

10.2 ThreadLocal¶

作用： 维持线程本地成员变量，实现线程隔离，常用于存储用户登录信息。
底层结构： 维护 ThreadLocalMap，Key 是 ThreadLocal 对象（弱引用），Value 是存储的变量。
核心问题： 内存泄漏——Key 为弱引用可被 GC 回收，但 Value 为强引用无法回收，严重时导致 OOM。
解决方案： 使用完必须调用 remove() 方法。
跨线程传递： InheritableThreadLocal 支持父子线程传递（线程池场景失效）；TransmittableThreadLocal（TTL）解决线程池上下文传递问题。

10.3 JVM 深度问答¶

内存分区：

分区	线程共享	内容
堆	共享	对象实例
方法区	共享	类信息、常量、静态变量
虚拟机栈	私有	方法调用栈帧
本地方法栈	私有	Native 方法调用
程序计数器	私有	当前执行指令地址

运行流程： Java 源码 → .class 字节码 → 类加载到运行时数据区 → 执行引擎将字节码转换为机器指令。

类加载机制——双亲委派模型：

子类加载器收到请求 → 委托父类 → 直到顶层。父类无法加载时子类才尝试。
破坏方式： 重写 ClassLoader 的 loadClass() 方法。
典型场景： Tomcat——需要运行多个相同类的应用，双亲委派无法满足。

内存泄漏 vs 内存溢出：

内存泄漏： 程序使用完后内存未回收，长期占用。
内存溢出（OOM）： 请求分配内存时无足够空间，抛出异常。
排查工具： VisualVM、JConsole、jmap、jstat。

垃圾回收（GC）：

判断算法： 可达性分析（GC Roots）。
回收算法： 标记清除、标记复制（新生代）、标记整理（老年代）。
CMS 收集器： 第一个关注 GC 停顿时间（STW）的收集器；流程：初始标记（STW）→ 并发标记 → 重新标记（STW）→ 并发清除。基于标记清除，会产生内存碎片。
三色标记法： 白色（未访问）→ 灰色（已访问引用未处理）→ 黑色（已处理完成）。
频繁 Full GC： 通常因新生代空间太小，对象频繁进入老年代。

逃逸分析： 对象不一定分配在堆中。未逃逸的对象分配在栈上，方法结束自动销毁；逃逸对象分配在堆中。

十一、前沿技术趋势¶

11.1 Mamba 状态空间模型¶

定义： Mamba 基于选择性状态空间模型（SSM） 的新一代序列建模架构。
核心优势：
以线性时间复杂度 $O(n)$ 替代 Transformer 自注意力的 $O(n^2)$ 复杂度，超长序列下速度更快、显存更低、推理延迟恒定。
通过内容感知的选择性机制实现高效长程记忆与信息过滤。
依靠硬件友好的并行扫描设计大幅提升实际运行效率。
发展趋势： 能媲美 Transformer 的表达能力，又能解决长文本、端侧部署等瓶颈。常与 Transformer 混合搭配、配合动态路由使用，成为下一代高效大模型的核心技术方向。

11.2 2026 年大厂招聘趋势¶

（建议结合实际最新招聘动态补充。）

十二、Transformer 长上下文优化¶

12.1 三大瓶颈¶

面试题：为什么 Transformer 在处理超长上下文时会变慢？瓶颈在哪？怎么解决？

如果只回答"计算量大"，只能拿 60 分。要从算法原理挖到硬件底层。

12.1.1 瓶颈一：O(n²) 计算复杂度¶

在 Transformer 的自注意力机制中，每个词都要和句子里其他所有词计算注意力关系。输入长度 N 翻一倍，计算量和显存占用不是翻两倍，而是直接飙升四倍——这就是二次方爆炸。

12.1.2 瓶颈二：显存带宽瓶颈（搬得慢）¶

真正的瓶颈往往不是算得慢，而是搬得慢（显存墙）。GPU 计算核心像个吃很快的胖子，但显存带宽是根细吸管。处理长文本推理时，需要反复搬运庞大的 KV Cache（键值缓存），计算核心大部分时间在等数据，而不是在算数据——这就是变慢的物理本质。

12.1.3 瓶颈三：外推性差¶

很多模型在短文本上训练（如 4000 token），突然扔 2 万字进去，虽然硬件扛得住，但位置编码直接乱套，模型开始胡言乱语、困惑度飙升。

12.2 四大优化方案¶

12.2.1 Flash Attention（少搬运/算子融合）¶

思路： 一次性在高速缓存（SRAM）里算完，避免反复读写显存。就像做饭，以前是切一刀跑一次冰箱，现在把菜全拿出来在案板上一次切完。显存占用从 O(n²) 降到 O(n)，速度提升非常明显。

12.2.2 GQA——分组查询注意力（减负重）¶

思路： KV Cache 太大塞爆显存，给它瘦身。以前是一对一服务（每个 query 有自己的 key 和 value），现在是多个 query 共享一组 key 和 value。就像本来每个人都要带一个秘书，现在一个小组共享一个秘书，显存压力瞬间下降，吞吐量上升。

12.2.3 Page Attention（不浪费/碎片整理）¶

思路： 显存明明还有空地，但都是碎的，塞不进长文本。Page Attention 借鉴操作系统虚拟内存分页思想，把显存切成小块，哪有空位塞哪里，彻底解决碎片化问题，能同时处理更多并发请求。这也是 vLLM 等推理框架的核心技术。

12.2.4 RoPE Scale / ALiBi（骗模型/位置编码外推）¶

思路： 如果模型训练时只看过 4000 字的文章，突然扔 10 万字会蒙。通过 RoPE Scale 或 ALiBi 等数学技巧，用差值方法把长文章压缩或伪装成短文章的频率特征，欺骗模型让它觉得"这个长度我好像见过"，从而保证长文本效果不崩塌。

12.3 面试总结话术¶

"长文本变慢的本质，是 O(n²) 的计算复杂度撞上了硬件的 I/O 访问瓶颈。我们的解决思路是一套组合拳：用 Flash Attention 做算子层面的融合解决 I/O 问题，用 GQA 做架构层面的压缩解决显存问题，用 Page Attention 解决显存碎片化问题，再配合位置编码的数学技巧（RoPE Scale / ALiBi）解决外推性问题。"

能把这套逻辑讲清楚，面试官就知道你不仅懂模型，还懂系统，更懂硬件。

核心要点速记¶

LoRA-SVD： 利用 SVD 从预训练权重提取最优特征方向初始化 LoRA，比经典 LoRA 收敛更快、小样本效果更优
Agent 项目场景： 必须选"一次对话搞不定"的场景，避免伪需求
技术选型： 写清楚为什么选，技术多少不是关键
Workflow vs Multi-Agent： 固定流程是 Workflow，自主决策+相互通信才是 Multi-Agent
Memory 位置： 放 System Prompt 最前面，提高缓存命中率
ReAct 模式： Chain（固定流程）→ Tool Use（工具调用）→ ReAct（推理+行动+观察+再决策）
Agent 五要素： 目标、大脑、工具、循环、记忆——缺一不可
ReAct Loop： 思考→行动→观察→反思→重复直到完成；简单任务不需要 Agent，单次调用更优
工程化思维： 上下文管理、异常处理、评测体系缺一不可
Contextual Retrieval： 为每个 Chunk 生成上下文前缀，Embedding + BM25 混合检索错误率可降至 5.3%
Agentic Search： 代码场景下 grep 迭代检索往往优于 RAG，本质是数据驱动的选型
上下文工程四技巧： 写入、选取、压缩、隔离——通过 MCP 实现
长上下文 vs RAG： 不是竞争关系——RAG 解决广度，长上下文解决深度，未来是 Long RAG
向量数据工程六步： 格式标准化→元数据提取→父子块切片→Embedding→HNSW 索引→混合检索+Rerank
HyDE 技术： AI 先模拟答案再检索，召回率翻倍
字节侧重工程实践技术深度，腾讯侧重协议生态工程视野，阿里侧重架构设计业务落地
AI 测试核心： 评估 AI 输出质量和风险，不只是接口返回 200
自动化评测： 评测集 + 批量执行 + 规则/模型评分 + 人工抽检 + 报告
ES 选型理由： 一站式支持向量检索 + 关键词检索 + 权限过滤
向量维度 2048： 平衡语义表达与检索效率
三层记忆架构： 短期记忆（保连贯）+ 实体画像记忆（精准记忆事实）+ 长期情景记忆（模糊召回）
异步影子 Agent： 后台异步提取画像存向量，不让用户干等，记忆可自我进化
Mamba： $O(n)$ 复杂度的 SSM 架构，有望突破 Transformer 长文本瓶颈
Transformer 长文本瓶颈： O(n²) 计算复杂度 + 显存带宽瓶颈 + 外推性差
四招优化： Flash Attention（算子融合）、GQA（KV 共享）、Page Attention（碎片整理）、RoPE Scale/ALiBi（位置编码外推）

文档整合说明： 本文档由《Agent 面试全景梳理》《AI 面试知识体系整合手册》《看完这期你不仅能答腾讯一面的题，还能拥有》《RAG、长上下文、向量，字节面试真会问》四份材料合并编排而成。整合过程保持全部技术内容与关键数据，按"基础理论 → 核心技术 → 面试实战 → 项目落地 → 趋势展望"的逻辑链条重组，删除重复内容，确保信息连贯、层次分明。新增内容涵盖 ReAct 模式详解、Agent 五要素、ReAct Loop 循环、长上下文 vs RAG 混合架构、向量数据工程全流程、三层记忆架构与异步影子 Agent、Transformer 长上下文优化等面试高频考点。