大模型面试8题：从Transformer原理到Agent容错实战

我做过不少回LLM方向的面试官，也带过一轮又一轮候选人。这几年下来特别明显的一件事是：简历上人人都会写“熟悉大模型、掌握LangChain、做过RAG应用”，但只要把问题往深里问一层，淘汰率立刻上来了。不是他们背得不够，而是很多人的知识是“列表型”的——知道有哪些名词，却不知道这些名词之间怎么咬合、怎么算账、怎么在失败时兜底。

这篇文章想做的，是把我在面试现场反复用来做一票否决的8个问题整理出来。它们覆盖了从Transformer原理、推理显存、对齐训练到RAG、评估、Agent工程的完整链路。准备LLM算法岗或大模型应用岗面试的朋友，可以把它当一份自查清单；已经在做相关项目的工程师，也可以拿这些问题检验一下自己是不是真的“手上有系统”，而不只是“嘴上有名词”。

1. 从复杂度公式到FlashAttention：Self-Attention为什么是必考题

1.1 这道题筛的是：你对“LLM为什么慢”有没有体感

面试官通常会这么问：“Transformer的核心是Self-Attention，它的时间复杂度是多少？为什么序列一长就卡？”这个问题看起来基础，实际上是整场面试的分水岭。因为LLM后来所有关于长上下文、推理成本、稀疏注意力、序列压缩的讨论，全都从这一个复杂度出发。如果候选人连“平方复杂度”都答不利索，后面基本没得聊。

我看见过很多候选人能背出“O(n²)”，但问他n是什么、d是什么，就开始含糊。n是序列长度，d是每个token的向量维度。真正的复杂度写法是O(n²·d)，面试时把这个说出来就已经超过一半人了。

1.2 推导与内存：O(n²)到底烧在哪

Self-Attention的核心公式是：

Attention(Q, K, V) = softmax(QK^T / √d) · V

Q、K、V的维度都是(n, d)。第一步计算QK^T，一个是n×d矩阵，一个是d×n矩阵，两者相乘要算n²个元素，每个元素做d次乘法，所以这部分是O(n²·d)。第二步softmax是对n×n的矩阵逐行做归一化，O(n²)。第三步再乘V，又是O(n²·d)。

所以时间和显存都逃不开这个n²。我曾经在面试时追问过一个细节：“这个n×n的注意力矩阵需要存下来吗？”很多人没意识到，这一步很关键：中间结果logits矩阵是要驻留在显存里的，序列长度1024时这个矩阵是1024×1024，4096时是4096×4096，再乘上batch size和注意力头数，显存涨得飞快。

1.3 让面试官眼睛发亮的进阶：FlashAttention与注意力之外的选择

复杂度这道题，能答到O(n²)、能算出内存占用，只能算及格。真正拉开差距的是下一个追问：“既然平方复杂度这么贵，你了解哪些优化？”

这时候最稳妥的答案是FlashAttention。它的核心思路不是降低计算量，而是重新组织计算顺序：把Q、K、V分块（tiling），让每个块在SRAM里完成局部softmax的统计，再用在线softmax（online softmax）的方式合并局部结果，最后把完整输出写回显存。这样n×n的注意力矩阵不用整体落盘，显存占用从O(n²)降到O(n)，省下的主要不是计算，而是IO。GPU算得快但显存带宽是瓶颈，FlashAttention就是围绕这一点做的。

再往深处讲，还有稀疏注意力（只让部分位置互相注意）、线性注意力（把attention近似成核函数形式）、状态空间模型（Mamba这类），它们都在试着突破平方复杂度。但如果候选人只是罗列名词，我会继续问：“那为什么到今天大家还在用Transformer？”正确的思路是：全局、动态、输入相关的token交互是Transformer表达力的根基，CNN是局部感受野，RNN是顺序压缩，Attention让任意两个位置直接通信，而且矩阵乘法在GPU上极其友好。你能把这个逻辑讲圆，这道题基本就满分了。

2. 现场算显存：KV Cache这道题专杀“只会调库的工程师”

2.1 先搞懂KV Cache缓存了什么

大模型做自回归生成时，每生成一个新token，理论上都要重新看一遍之前所有token。如果每次重算历史token的K和V，代价极大。KV Cache的做法是：在生成第一个token时，把每层每头的K、V缓存下来，后续生成只需要用当前token的Q去和缓存的K做attention，再更新一次K、V缓存。这让每个token的生成成本从O(n²)降到了O(n)，但也带来一个新问题：缓存本身要占显存，而且随着序列变长线性增长。

淘汰往往从这里开始。有人会把KV Cache和“降低Attention平方复杂度”混为一谈，这属于概念性错误。KV Cache解决的是解码阶段重复计算问题，跟注意力矩阵的平方复杂度是两码事。

2.2 带参数算一笔账：16GB是怎么来的

我常让候选人现场算一道题：一个7B参数量的模型，假设32层、32个注意力头、每头128维，用fp16推理，batch size=16，序列长度2048，KV Cache要占多少显存？

来一步步推。每个token在每一层要缓存两组向量，一组K、一组V。每组大小是32头×128维=4096个元素，两组就是8192个元素。fp16下每个元素2字节，所以每层每个token的KV缓存是16KB。序列长度2048，一个序列就有32MB；batch size=16，就是512MB；再乘32层，总共约16GB。

注意，这还只是KV Cache。模型权重本身在fp16下还要占约14GB。两笔账一合计，显存怎么爆的就一目了然了。我见过不少候选人一直说“上下文太长显存不够”，却说不清到底哪个模块在吃显存，这就是没做过部署的典型表现。

2.3 只报公式不够，至少补两种优化手段

算完账，面试官必然会问：“那怎么省？”至少要能说两到三种手段。

第一是GQA（分组查询注意力）和MQA（多查询注意力）。MQA让多个Q头共享同一组K、V头，KV缓存直接除以头数；GQA是折中方案，让一组KV头服务多个Q头，Mistral和Llama 2 70B都在用。第二是KV Cache量化。把缓存的K、V从fp16压到int8甚至int4，单体上KV缓存立刻减半或减到四分之一，代价是精度损失，需要评估。第三是PagedAttention，它按页管理KV缓存，避免显存碎片，vLLM就是靠它把吞吐拉上去的。第四是投机采样，用小模型先草拟多个token，大模型一次校验，减少自回归步数，间接省显存带宽。

这里还能顺带提一句本地部署。现在很多人喜欢在安卓手机、笔记本上跑GGUF格式的量化模型，比如用各类本地推理工具加载Q4/Q5的权重量化模型。但GGUF主要量化的是权重矩阵，KV Cache在很多实现里仍然用fp16。所以你经常能看到一个现象：模型文件才4GB，跑起来把上下文拉到8K、16K时照样爆显存或内存，罪魁祸首往往就是没量化的KV Cache。这是我实际跑本地模型时的体会，也是面试时能体现工程经验的好素材。

3. 幻觉治理不是“用RAG就行”：面试官想听的是一套体系

3.1 幻觉的四种形态，以及它为什么是“特性而非bug”

“大模型会一本正经地胡说八道，你有办法根治吗？”这个问题问出来，淘汰的人往往分两种：一种说“用RAG就好”，另一种说“这是无解的，只能接受”。前者说明只有浅层认知，后者说明没有工程解决问题的习惯。

先说幻觉的形态。事实性幻觉，把不存在的事实说得有鼻子有眼；逻辑性幻觉，推理链条中间断掉但语言很通顺；指令性幻觉，模型执行了用户根本没要求的动作；上下文幻觉，给的资料里明明没有这个信息，它非要编一个。面试时能把这四类分清楚，本身就说明你有过实际处理经验。

根源上也值得说透。LLM本质是下一个词预测器，它学习的是文本分布，不是一个可靠的事实数据库。生成阶段的采样随机性、长上下文里注意力被噪声分散、训练语料本身包含错误内容，都是幻觉的来源。所以准确讲，幻觉不是“修一下就好”的bug，而是模型追求流畅预测带来的副产品，工程上能做的是治理，不是根治。

3.2 从训练到推理再到外挂，一条完整的治理链路

完整的幻觉治理体系，我一般按四条路来讲。

训练侧，SFT阶段清洗数据、把错误标注剔除；RLHF/DPO阶段把“胡编乱造”作为负样本压低。推理侧，降低temperature和top_p，减少采样随机性；系统提示词里明确写“不确定就说不确定”。外挂侧，RAG用检索结果约束生成范围，更重要的是给输出加引用溯源，并设定检索置信度阈值，低于阈值直接拒绝回答。后处理侧，用事实核查模型做一遍验证，或者做self-consistency采样，让模型生成多次，取一致结果，不一致的要人工介入。

我曾经搭过一个客服问答系统，单靠降低temperature只能把幻觉率从11%压到9%，后来加了引用溯源加不可回答即拒绝，才真正降到3%左右。这类数字不夸张，但很能说明问题：单一手段效果有限，组合拳才有效。

3.3 Agent场景为什么把幻觉放大

Agent场景里，幻觉的风险会明显放大，这也是现在面试经常追着问的。普通对话里模型胡说八道，用户顶多觉得不靠谱；Agent里模型一旦胡说八道，下一步就是拿着编造的参数去调工具、发请求、改配置，错误会从“回答层”下沉到“执行层”，产生真实副作用。

有一次我遇到过一个agent例子：让它查询某城市的天气，模型没有调用工具，直接编了个“晴天25度”，还在回答里把“城市天气接口返回”说成是实时数据。问题就在于系统没有对工具调用结果做校验。后来我们加了一条硬约束：只要回答里声称调用了工具，就必须有真实的tool call记录和返回值，否则这个回答直接作废。这就是典型的重试与校验循环，后面第8题我还会细讲。面试官想听的恰恰是这套“把幻觉当作执行风险来处理”的体系化思路，而不是一句轻飘飘的“加个RAG”。

4. SFT都做了，为什么还要RLHF？GRPO公式应该能默写

4.1 SFT学的是“像不像”，RL学的是“好不好”

很多候选人简历上写着“做过SFT微调”，但当被问到“SFT之后为什么还要RLHF”时，答不上来。这道题淘汰的就是“只会跑训练脚本、不理解优化目标”的人。

SFT是最大似然估计：给定输入，最大化参考输出中每个token的概率。它擅长模仿格式和风格，但有个关键缺陷——它无法区分“像人类写的”和“人类真正满意的”。如果训练数据里有一条低质量回答，SFT也会认真把它学进去。所以SFT之后模型可能很流畅，但不一定说人话、不一定遵循复杂指令。

RLHF做的事情是完全不同的：优化目标从“模仿特定文本”换成“最大化人类偏好”。它不再一个token一个token地评判，而是拿两段完整回答让模型判断哪段更好，同时加一个KL散度约束，防止模型为了刷奖励而偏离参考策略太远。这本质上是把“像不像”换成“好不好”，是两种不同的学习范式。

4.2 RLHF的骨架，以及KL散度为什么不能少

RLHF经典流程是四个模型：Actor初始策略、Reference基准策略、Reward奖励模型、Critic价值模型。Actor生成多轮回答，Reward给每段回答打分，同时计算与Reference的KL散度作为惩罚，Critic估计状态价值，最后用PPO做策略更新。

KL散度在这一条里根本不是可选项。没有它，模型会疯狂钻奖励模型的空子，生成一堆“让奖励模型开心但人类看了想骂人”的内容，这就是reward hacking。KL散度相当于给策略拴了一根绳子，让它不能离初始模型太远，更新节奏因此稳定很多。

面试时如果你能顺手把这个逻辑讲出来，面试官基本可以确认你是真跑过RLHF的。至于RLHF里的数据标注，这也是个常见追问：偏好数据不只是“好/坏”二分类，更要有“好在哪里、坏在哪里”的理由，标注规范要明确规定对格式、语气、事实性分别怎么打分，否则训练出来的奖励模型自己就充满噪声。这一问把工程细节和训练质量串起来了。

4.3 GRPO凭什么砍掉Critic：组内相对优势公式

近两年面试的高频点变成了GRPO，因为DeepSeek开源系列把这一招带火了。追问形式一般是：“你知道GRPO和PPO的区别吗？”

先说PPO为什么贵：为了估计优势函数，要训练一个Critic网络来拟合状态价值，这个网络本身和Actor一样大，显存、时间、调参成本都翻倍，训练还不稳定。GRPO的思路很直接：不要Critic了，让同一个prompt生成一组输出，组内互相比较。

GRPO对每个prompt采样G个输出，分别算每个输出的奖励r_i（包含KL惩罚），然后做组内标准化：

A_i = (r_i − mean(r)) / std(r)

直觉上，这组输出里谁超过平均分越多，谁的优势越大。因为优势是相对同一组其他回答算出来的，所以不需要一个绝对的价值函数来估计“这个状态大概值多少”，直接从组内相对好坏里学就够了。训练少了一个大模型，稳定性和成本都改善了。

面试的时候能在白板上把这个公式写出来，再讲清楚它省在哪，这题就稳了。比吞吞吐吐说“GRPO比PPO便宜”强十倍。

4.4 追问：LoRA为什么能用低秩矩阵微调，秩r怎么定

RLHF那一串问题之后，面试官经常顺势追问LoRA，因为现在SFT和RLHF基本都用LoRA来做。

LoRA的假设是：预训练矩阵已经包含强大特征，微调阶段需要调整的增量方向落在低维子空间里。具体做法是把权重增量ΔW分解成A×B，A是r×d，B是d×r，r远小于d，需要训练参数量从d²变成2dr，大幅下降。QLoRA在此基础上把基座模型4-bit量化后冻结，只训练低秩分支，所以单卡也能微调7B、13B模型。

追问“秩r怎么定”时，我的经验是：常见16或32起步，任务简单可以降到8，太小容易欠拟合，太大浪费算力还可能过拟合。面试到这儿，你还能补一句“微调和RLHF里都可以用LoRA，效果不一定比全参数差，关键是可以用更少资源做更多实验”，这句话听起来就是有实战经验的人说的。

5. 上下文窗口为什么卡在训练长度？RoPE、NTK与YaRN的直觉

5.1 RoPE为什么能把位置问题变成相对问题

现在的LLM基本都用RoPE旋转位置编码。它做的事情很巧妙：把每个token的位置信息编码成旋转角度，作用在Q和K向量上。两个向量做完旋转再求内积，结果只取决于它们的相对位置差，而不是绝对位置。这个性质让RoPE天然适合外推，比早期绝对位置编码强不少。

面试官问“为什么RoPE外推还是差”的时候，大多数候选人会卡住。要解释清楚，必须回到一个细节：模型训练时见过的最大相对距离是有限的。假设模型在4K长度上训练，那么两个token的相对位置差最大也只有4095。外推到8K时，就会出现从未见过的相对距离组合，模型面对这些新相位，softmax分布会失去原有规律，效果快速崩坏。

5.2 外推失效的本质：模型没见过超出的相对距离

这里可以做个类比：一个人只在10米长的走廊里走过，突然把他放到20米走廊，他能走，但他对空间远近的判断是基于10米内建立的，超出的部分全靠猜。RoPE外推也一样，不是数学上不能用，而是模型对“超过训练范围的相对旋转相位”没有经验。

5.3 PI、NTK、YaRN各自补哪块短板

接下来就是经典三连问：位置插值、NTK-aware、YaRN各解决什么问题？

位置插值（PI）的思路是把新位置下标压缩回训练区间：原本2048的位置，外推到4096时只要把位置除以2。模型看到的相对距离还是训练范围内的，自然能work。代价是旋转角度被压缩，“分辨率”下降，高频分量变得模糊。

NTK-aware的思路相反，它不改位置下标，而是调大旋转频率基数base。RoPE的base默认是10000，把base调大，相当于让高频分量保持切片分辨率、让低频分量转得更慢，把模型没见过的相位容纳进来。训练分布没有被压缩，你不需要微调就能获得一定外推能力。实际调参中常用500000甚至1000000，但注意不是越大越好，越大代表对低频位置信息越不敏感，需要结合任务验证。

YaRN是升级版：按维度做不同缩放，把NTK思路和插值结合，同时对注意力logits乘一个温度系数，抑制长上下文时注意力熵升高导致的“所有位置都均匀”问题。

5.4 别被位置编码带偏：长文本的真正瓶颈

最后我想说一个经常被忽略的点：长上下文能力不是只靠位置编码。很多人以为“把RoPE的base调大就能支持32K”，但真正限制长文本质量的是训练数据里的长距离依赖不足。你让模型在4K数据上训练，期望它推到32K还能理解长文逻辑，本身就违反直觉。长文档里前后跨越多段的关键信息关联，模型如果没有在训练中见过足够多这样的样本，位置编码再先进也没用。回答里能主动补上这一层，面试官会另眼相看。

6. RAG的灵魂三问：chunk怎么切、embedding怎么选、为什么要rerank

6.1 embedding选型，先分清开源闭源和维度取舍

RAG是现在大模型应用落地的最广组合，面试必问，而且追问极细。第一刀通常是：“给一批私有文档做知识库问答，你的向量化怎么做？”

选embedding模型，先分清开源和闭源托管接口。闭源接口方便省事，但数据要出域，很多企业直接排除；开源模型可以私有化部署，数据不出内网，这也是我大部分情况下的首选项。中文场景常用的有bge-large-zh-v1.5、m3e、acge-text-embedding这类，都比较成熟。维度是个容易被忽略的指标：1024维效果通常最好，但要更大的向量库和更慢的检索；768维是平衡点；512维则偏轻量。选型不能只看一个公开榜单分数，要用自己的业务语料实测召回效果。

6.2 chunk策略：固定大小只是兜底，结构切分才见功夫

问到切块策略，很多候选人只会说“512 token加一段重叠”，这样答不够。固定大小切块是兜底方案，比如384 token切一块、留48 token重叠，大约是15%的重叠率，目的是防止句子在边界被切断导致embedding语义丢失。但真正见功夫的是结构切分：按Markdown标题、段落、代码块来切，表格单独处理，文档层级清晰时让每个chunk保持语义完整。

这里顺便提一个可以讲的点：现在流行的知识库工具、Obsidian的“第二大脑”类插件和方案，原理上就是一个个人版RAG。你在Obsidian里写卡片笔记，怎么切块、怎么定嵌入向量、怎么设置相似度阈值，跟企业RAG是同一套逻辑。面试时提到这类实践，说明你真的在日常工具里用过这套技术，而不只是看过教程。

6.3 rerank和召回指标：top5命中率会骗人

再往下问就是：为什么召回之后还要rerank？双塔向量检索速度快，但把整段文本压成一个向量之后是“粗粒度”匹配；rerank是交叉编码器，把query和文档拼在一起过一遍深度模型，精确但慢。工程上标配是两段式：向量召回top50，再rerank取top5给LLM。

指标上，很多人只报“top5命中率80%”，这个数字不够。命中率高只说明正确答案在候选里，不代表正确答案排在最前面。要看到排序质量，用MRR（第一个正确答案排多靠前）或者NDCG（整个排序质量的折损）。如果不能区分“召回了”和“排对了”，你根本无法定位RAG链路到底哪一环有问题。

6.4 进阶加分项：查询改写、多路召回与引用溯源

能答出上面这些算合格。想加分，可以主动聊几个进阶方向。查询改写：用户问“上次那个故障最后怎么解决的”，直接拿原句去检索，往往不如改写成一个清晰的信息需求；HyDE思路是先用LLM生成一个伪答案，再用伪答案去检索，有时候效果提升很明显。多路召回：BM25关键词召回加向量召回，两者互补，再合并去重。引用溯源：回答里每个关键论断都要带来源文档段落，既方便用户核对，也让模型收敛到检索范围，是治理幻觉最有效的一招之一。

7. 你说效果很好，我凭什么信？大模型评估的系统性方法

7.1 公开benchmark的三个陷阱

面试到后半场，面试官经常会问：“你做完这个项目，怎么证明它效果好？”这时候如果只回一句“感觉还不错”，基本凉了。我在这一题上淘汰过不少人，不是效果差，而是没有评估方法论。

公开benchmark有三个陷阱。第一是数据污染，预训练语料可能已经包含了测试题的相似内容，模型在训练时见过答案，测试分数虚高。第二是天花板效应，老榜单大家都刷到99%，失去区分度。第三是分布不一致，公开benchmark覆盖的是通用能力，你业务里的问答类型它根本测不到。我见过一个开源模型在某个知名榜单上分数很高，拿到真实业务里失败率却不低，原因就是业务样本分布和榜单分布差太远。所以公开benchmark只能当“健康检查”，不能当“验收标准”。用lm-evaluation-harness这类工具跑跑通用能力可以，但项目交付必须靠自己的评测集。

7.2 指标别只报一个准确率

评估体系要看任务类型。分类任务看精确率、召回率、F1，不能只看准确率，类别不平衡时准确率会骗人。检索任务看HitRate@K、MRR、NDCG，分别反映“有没有召回”“排得靠不靠前”“排序整体质量”。生成任务要分两层：字面相似度可以用ROUGE/BERTScore，但内容质量和事实一致性要靠LLM裁判或人工抽检。Agent任务维度更多，任务完成率、平均步数、工具调用正确率、幻觉率、安全护栏触发率都要分开统计。

一个常见错误是微调完模型只报一个“整体准确率提升2%”，却不说是哪个子集提升、哪个子集下降。面试官听到这种话，第一反应就是这人没有做过细粒度分析。正确的说法应该是：按问题类型拆开，比如“计算题提升了，多跳推理题不变，指令遵循题略有下降”，再给原因分析。

7.3 LLM-as-Judge的三类偏见与校准办法

现在大家普遍用LLM当裁判，但裁判模型本身有偏见，这个必须能说出来。最典型的三类：长度偏见，裁判倾向于把更长的回答评为更好，哪怕长的部分全是废话；位置偏见，两个回答并排展示时，不同裁判模型会对特定位置有偏好；自我偏见，裁判模型对自己风格的答案给分更高。

校准办法有两个方向。一个是流程层面：匿名化、交换位置评两遍取平均、把评分标准写成结构化rubric再让裁判逐项打分。另一个是统计层面：定期抽一批样本让人类标注，算裁判和人类的一致性，低于阈值就换裁判模型或调整提示词。面试的时候能把这个闭环讲出来，说明你真的做过评估，不是拍脑袋说“效果挺好”。

7.4 自建评测集和bad case回归才是真资产

最后是我最看重的一个点：自建评测集。做法不复杂但需要坚持：从真实用户问题里随机采样一部分做种子集，再把历次线上bad case不断补充进去，形成一个“回归集”。每次改prompt、换模型、调RAG参数，都拿这个回归集刷一遍，确保没把之前修好的问题改回去。维护这样一个回归集比任何公开榜单都更能防漏。

我自己的习惯是每周新增两三条线上发现的bad case。积累几个月后，这个回归集基本就成了团队最值钱的数据资产之一。面试中你能讲出这样一套工作习惯，含金量远高于“我跑过GPT-4评测”。

8. 能Chat不能干活：Agent工程化与多智能体系统的容错设计

8.1 Agent失败是一场算术灾难

最后一道题，也是现在最热门的方向。面试官问：“LLM做Agent，从Demo到生产最大的差距是什么？”

先给一组数字：单步成功率90%，一个10步的流程，整体成功率只有0.9^10≈35%；单步成功率95%，20步流程，0.95^20≈36%。这就是Agent的数学噩梦。对话任务里单轮说错可以原谅，但流程任务里错误会累积，一步错后面全错。所以Agent工程的核心不是把单步成功率从92%调到94%，而是设计一套机制，让单步失败不至于拖垮整个流程，变成可以重试、可以回退、可以被拦截的瞬时噪声。

8.2 五个高频失败点与对应的工程对策

结合我自己的踩坑经历，Agent生产环境里最常见五类失败：

这五类里，工具格式错误最常见的，也是最容易被忽略的。很多Demo里模型随便说一句“我要调用某接口”就算完，但生产环境里工具调用必须结构化，最好把工具定义成schema，模型按schema输出JSON，系统侧先校验再执行。参数校验不过就反馈给模型修正，而不是让流程卡死或继续错下去。有一次我遇到agent因为一个订单号格式不对，连续三次调用失败，最后把用户晾在原地。后来加了参数正则校验加修正重试，同一场景直接通过。

8.3 我踩过的坑：工具调用校验要形成循环

具体踩坑经历是这样的：早期做个调度agent，模型经常在工具调用不完整的情况下继续对话——它以为工具已经执行了，实际系统侧根本没收到合法请求。后来我意识到，关键不是训模型“必须完整调用工具”，而是要在工程上形成一个闭环：解析模型输出，做schema校验，校验失败就把错误信息返回给模型，让它修正后再来一次。这相当于把“工具调用”当成一个有重试语义的操作，而不是一次性的祈祷。

生产级的Agent，每一步都应该有trace：模型当时的输出、工具接收的参数、返回的结果、状态变化，全部结构化记录。不然出了事故根本没法定位是“模型选错工具”还是“工具返回了脏数据”。这些工程细节，是能chat的Demo和能交付的系统之间真正的分界线。

8.4 多智能体不是默认选项：少即是多

面试时说到Agent，总有候选人兴奋地拿出复杂的多智能体架构图：一个主控，四个子agent，每个还有自己的记忆和工具。遇到这种情况，我通常会反问一句：“你加了这么多角色之后，整体错误率是变大了还是变小了？”

多个智能体之间的通信本身就是新的错误来源。每个子agent都可能误解指令、延迟响应、返回脏数据，上下文被反复搬来搬去。除非任务确实需要隔离不同领域的知识和状态，否则一个模型加多个工具就是最稳定的结构。能主动说“我这里先用单agent，等复杂度上来再拆”，这是工程判断力，比堆架构高级得多。

8.5 具身LLM的容错控制：把兜底下放到执行层

如果聊到更前沿的“具身LLM智能体”，这道题还有个延伸。具身智能体里LLM一旦做出错误规划，直接变成物理动作，没法靠对话兜底。所以容错控制必须下放到执行层：规划器给每个动作设置前置条件断言，比如“只有检测到机械臂到位且目标物体在抓取范围内，才允许执行抓取”；动作设计成可回滚或可降级的，比如“先试探性抓取，校验成功后，再加大力度”；硬件层面再保留急停和限位这些独立于模型的安全约束。这套思路跟第8.2里的工程对策本质相同，只是把“工具调用校验”换成了“物理动作校验”。

面试时能把这段讲出来，等于把话题从“会用LangChain”拉到了“理解如何构建可靠AI系统”的层面，这是所有人都想看到的候选人气场。

最后再分享一点个人体会。我每次面完试都告诉候选人：面试官要的不是你背答案，而是看到你在遇到一个问题时愿不愿意把推导过程完整走一遍。上面这8题，每一题都应该能自己白纸黑字推出来，而不只是“知道答案”。准备的时候，找一道题写一篇千字笔记，或者拿自己手头的真实项目复盘一遍，效果比刷十篇面经都好。等你能在纸上把KV Cache显存算出来、把GRPO公式默写出来、把Agent的失败链路讲清楚，你会发现面试其实没有那么多“必考”题，真正在考的是你对这套系统有没有手感。