当前位置：首页 > news >正文

大模型面试手撕崩了？深度复盘6个Agent项目被深挖的20个“为什么”，及面试官想听什么

news 2026/5/9 1:21:38

一、面试整体节奏

整场面试大约 70 分钟,节奏如下:

自我介绍 + 项目自述(约 8 分钟):面试官让我挑一个最有代表性的项目讲 5 分钟
项目深挖(约 35 分钟):围绕多 Agent 项目反复追问,层层递进,几乎不给喘息
基础八股穿插(约 10 分钟):从项目里自然延伸出来的若干基础题
手撕代码(约 15 分钟):经典 DP 题(二选一)
反问环节(约 5 分钟)

我简历上写的是一个多 Agent 协作的智能问答系统,有 6 个职责不同的子 Agent,带短期记忆和长期记忆,用 SFT + GRPO 做了对齐训练。下面把所有问题(含原创补充)都还原一遍。

二、项目深挖:一连串"为什么"

Q1:你这个 Agent 架构设计是为了解决什么问题?是特定领域,还是通用?

面试官想听什么:你做这个项目是"为了用而用",还是"为了解决问题而用"。

我当时的回答:我先讲了技术架构,讲到一半被打断了,面试官说"我想先听场景"。这是个信号——项目类问题永远先讲场景,再讲技术。

复盘后的最佳回答框架:

场景先行:垂直领域的复杂问答,用户的查询往往多步、需要外部工具、需要跨文档检索,单 LLM 直答存在幻觉、缺检索、缺工具调用三大问题。
为什么需要 Agent:任务可拆解,需要规划→检索→推理→汇总多步流程,单 prompt 端到端做不好,而且没法复用中间产物。
为什么是多 Agent:单 Agent 上下文堆积导致注意力衰减、指令遵循下降、工具误调;拆分后每个 Agent 的 prompt 更聚焦,且可以异构(有的强工具,有的强写作)。
代价是什么:延迟变长、调度复杂、错误会传递放大。但在我们场景下准确率提升远大于代价。

复盘心得:讲项目最忌"流水账"。要用问题 → 现有方案的不足 → 你的方案 → 代价这个四段论。每一段都要有数据或具体例子支撑。

Q2:6 个 Agent 怎么保证彼此独立、不互相串职责?

这题非常工程化,考察你有没有真把系统跑通。

我的回答(梳理后):

职责边界写在 Prompt 里,要"正反两面写":既写"应该做什么",也写"不应该做什么"。LLM 对 negative instruction 的遵循其实弱于 positive,所以要加例子。
工具权限隔离:每个 Agent 在调度层只能看到授权的工具子集,从工程上堵死越权。
输入输出 Schema 强约束:Agent 之间走结构化 JSON,字段不对就报错重试,而不是让模型自由发挥。我用了 pydantic 做校验。
统一编排:子 Agent 不互相直接调用,由上层 Planner / Router 调度,避免环形依赖。
Critic Agent 兜底:在关键节点加一个轻量校验 Agent,检查中间结果格式和合理性。

面试官追问:那如果 Schema 校验失败,你是直接报错还是让它自己修?答:先自修(retry with error feedback)最多 2 次,失败再向上抛。这种"自修"对 GPT-4 级模型有效,对 7B 小模型基本无效,会陷入循环,所以要设上限。

复盘心得:Schema 校验和 retry 策略是 Agent 工程的"暗坑",如果你简历写了 Agent,一定要准备这个细节。说"我用了 pydantic + retry 上限 N"瞬间显得专业很多。

Q3:你的短期记忆为什么没用 Redis?(对比某主流 Agent 框架)

面试官明显熟悉主流 Agent 框架,知道默认实现用的 Redis,所以反过来问"为什么不用"。

我的回答(实话实说 + 体现思考):

场景层面:会话生命周期短(分钟级)、单机并发不高,Redis 引入的运维复杂度收益不明显。
性能层面:进程内存(配合轻量 LRU)读写延迟比 Redis 网络往返低一个数量级。
灵活性层面:短期记忆里有非字符串结构(嵌套中间结果、调用栈),Redis 要走序列化反序列化,Python 对象更直接。
诚实补一句:多副本横向扩展时 Redis 是必选的,目前的体量没到那个阶段。

关键技巧:面试官问"你为什么不用 X",不要硬凹说 X 不好,而要讲"在我的场景下 X 的优势没体现出来,而它的成本是真实的",同时主动承认 X 的适用场景。

Q4:那万一上下文塞不下了,你做了什么压缩策略?

我答了三层:

滑动窗口:最近 N 轮对话保留原文。
滚动摘要:超过窗口的早期对话,用轻量 LLM 做摘要替换原文。
重要信息提取:用户的关键约束、偏好、已确认事实单独放在"事实区",不参与压缩。

面试官追问:摘要会丢信息吗?怎么评估?答:会。做法是离线构造一批"长对话+正确答案"的评测集,对比有摘要 vs 无摘要的回答准确率。

复盘心得:这题如果再被问到,我还会补充一个前向遗忘曲线:摘要后的内容信息密度高,但对人称、时间、否定词这种细节信息特别容易丢,所以摘要 prompt 要专门强调"保留时间、否定、约束条件"。

Q5:你记忆里存的都是结构化文本,有多模态的吗?

当时答得一般,事后梳理:

当前版本:文本结构化为主,图表是通过工具调用动态生成(返回图片 URL),URL 存记忆里,而不是图片本身。
如果要支持原生多模态记忆:

存储:图片走对象存储,记忆里只存引用 + caption。
检索:caption 走文本召回,图片本身走 CLIP-like 多模态向量召回。
注入上下文:VLM 模型才能消费图片,否则用 caption 兜底。

复盘心得:这种"我没做过但要回答"的题,核心是展现技术视野。把"如果做,我会怎么做"讲清楚,比硬吹"我做过"安全得多——后者一深挖就露馅。

Q6:长期记忆的召回怎么保证高召回率?

RAG 八股核心题。

我答的四个层次:

多路召回:向量召回(语义)+ BM25(关键词)+ 元数据过滤(时间、用户、权限)。
Query****改写:LLM 做 query rewrite / HyDE,把口语化问题改写成检索友好的形式。
Rerank:多路召回的结果用 cross-encoder 精排。
Chunking 策略:按语义单元切(段落、句子),加 overlap,避免关键信息被切碎。

面试官追问:你怎么评估召回率?答:Recall@K 是底线(K=5/10/20),MRR 衡量质量。需要构造 query → 标注 ground truth doc id 的评测集。

复盘心得:这题大家都会答"多路+rerank",怎么拉开差距?讲评测。能说清楚 Recall@K、MRR、nDCG 区别,以及怎么构造评测集,立刻就和"只会背 RAG 流程图"的同学拉开了。

Q7:为什么长期记忆和短期记忆用了不同的存储?

架构题,考察对"为什么这么设计"的理解。

维度	短期记忆	长期记忆
数据量	KB ~ MB	GB ~ TB
访问模式	全量读	检索式读
生命周期	会话级	跨会话持久
一致性	强	最终一致即可
数据形态	完整对话/中间状态	抽取/向量化的片段

核心结论:存储选型跟着访问模式走。短期记忆优化延迟,长期记忆优化召回,目标函数不同,自然方案不同。

Q8:RL 用了 GRPO,为什么没用 DPO 或 PPO?

技术深度题,这题答不出来基本就凉了一半。

vs****PPO:PPO 需要训练 value model(critic),显存和工程开销大;GRPO 用 group 内的相对 reward 替代 critic,省一个模型,在 Agent 这种 rollout 长、样本贵的场景下性价比高。

vs DPO:DPO 是 offline 的,需要预先准备 (chosen, rejected) 偏好对;对于 Agent 多步决策,偏好对的构造非常困难(到底是哪一步选错了?credit assignment 问题严重)。GRPO 是 online 的,直接用 Verifier 给 reward,更适合多步任务。

GRPO 的代价:训练不稳定时调参痛苦,reward 设计是最大 bug 来源(reward hacking)。

复盘心得:这题我还可以加一个系统视角的回答:DeepSeek-R1 之后 GRPO 在推理类任务上的有效性已被广泛复现,生态成熟、参考资料多,工程上选它的理由更充分。"跟随主流"也是工程师必备的现实考量。

Q9:6 个子 Agent 是同一个底座模型吗?用 SFT + GRPO 微调它学会调用这 6 个工具?

考察对训练范式的清晰认知。

是同一个底座模型(参数共享)。不同 Agent 通过不同 system prompt + 工具列表区分,而不是不同权重。
训练两阶段:

SFT****冷启动:用高质量 (任务, 工具调用轨迹) 数据,让模型学会"格式"——什么时候调工具、调哪个、参数怎么填。
GRPO 对齐:在 SFT 基础上做 RL,reward 来自最终任务完成度 + 中间步骤工具调用合法性。

为什么共享底座:省显存、省运维、知识互通;角色靠 prompt 切换。

追问:不同 Agent 之间会不会互相干扰?答:会有一点。SFT 数据要平衡(不能某个 Agent 数据特别多),prompt 模板差异化要明显。

三、基础八股穿插(从项目自然延伸)

这部分大家容易忽略——面试官从项目细节里随时会拐到基础题,你必须无缝切换。

Q10:你说用了 BM25,那 BM25 的公式核心是什么?和 TF-IDF 的本质区别在哪?

我当时答得磕磕绊绊,事后整理:

BM25 核心公式(给定 query Q,文档 D):

和 TF-IDF 的本质区别:

TF****饱和:TF-IDF 中 TF 是线性的,词出现 100 次权重就是 10 次的 10 倍;BM25 引入
k_
让 TF 饱和——出现到一定次数后,再多也几乎没增益。这更符合直觉(一个词出现 5 次就够说明相关了)。
文档长度归一化:BM25 用控制长文档的惩罚,避免长文档单纯因为更长而占便宜。
概率论基础:BM25 来自 BIM 概率检索模型,有更扎实的理论基础;TF-IDF 是经验启发式。

典型参数:

,。这些数字面试常考,记一下。

Q11:你说召回用了向量,Embedding 模型选型怎么考虑?BGE 和 OpenAI text-embedding 你怎么选?

考察维度:实际选型经验。

回答框架:

效果:看 MTEB 榜单,但要注意榜单和你的实际场景未必一致。最好用自己业务数据构造一个小评测集(几百条 query-doc 对)实测。
维度:OpenAI 是 1536/3072 维,BGE-large 是 1024 维。维度越高存储和计算成本越高,但业务效果差异往往不大。
领域:中文场景 BGE / BCE / Qwen-Embedding 通常优于 OpenAI;英文场景差距小。
成本:自部署 BGE 单位成本远低于 OpenAI API,大规模建库时差距是数量级的。
可控性:自部署可以微调,API 不行。垂直领域如果有标注数据,自部署+微调收益很大。

复盘心得:选型题永远是"看场景做 trade-off",不要给绝对答案。能讲出"用自己数据评测"这一句,基本就赢了一半的候选人。

Q12:向量库你用的什么?为什么不用 Faiss 直接搞?

考察:你是否真的部署过,而不是 demo 跑跑。

回答要点:

Faiss 是库不是服务:没有持久化、没有增删改的优雅支持、没有元数据过滤、没有多副本。Demo 没问题,生产不够。
常见选择:Milvus / Qdrant / Weaviate(自部署),Pinecone(托管)。
选型考虑:

数据量(百万级 Faiss 够用,千万以上要专业向量库)
是否需要带过滤的检索(metadata filter,Faiss 原生支持差)
是否需要实时增删
索引类型(HNSW vs IVF-PQ,前者召回高但内存大,后者反之)

追问:HNSW 的核心思想?答:多层图,上层稀疏长跳,下层稠密短跳,搜索时从上到下逐层细化,本质是跳表的图版本,把检索复杂度从 O(N) 降到 O(log N)。

Q13:SFT 数据你是怎么构造的?有什么质量控制手段?

这题问的是数据工程能力,在大模型岗越来越重要。

回答要点:

来源:

真实日志(用户 query)+ 人工/强模型补充答案
强模型蒸馏(GPT-4 / Claude 生成轨迹)
模板+种子任务自举扩展

质量控制三板斧:

去重:基于 SimHash / MinHash,避免训练集冗余。
难度分层:用 reward model / 启发式打分,保证简单/中等/困难样本比例合理。
格式校验:工具调用轨迹要严格符合 schema,任何一步格式错都丢弃或修复。

抽样人审:无论怎么自动化,最后随机抽 5%-10% 人工看,这步省不掉。

复盘心得:大家都说自己"做了 SFT",但能讲清楚数据怎么来的、怎么去重、怎么质检的,凤毛麟角。这是和别人拉开差距的地方。

Q14:GRPO 训练时 reward 怎么设计的?有没有遇到 reward hacking?

直接命中 RL 训练的核心痛点。

回答:

Reward 组成:

结果 reward:最终答案是否正确(由 Verifier 或规则判断),权重最大。
过程 reward:格式正确(工具调用 JSON 合法)、步数惩罚(避免无意义长链)、工具调用合法性。

Reward Hacking 案例(我们真遇到过):

模型学会输出"我不知道"——因为这样不会扣过程分,只扣结果分,但比胡说八道扣得少。
模型学会反复调用同一个工具——因为每次调用都拿过程分。

解决方案:

给"我不知道"也设结果惩罚(没解决问题就是没解决)。
重复工具调用做去重,不重复奖励。
加入KL惩罚让模型不要离 SFT 模型太远,本质是不要太"创造性"地钻空子。

复盘心得:Reward Hacking 是 RL 工程师的必修课,面试时主动说"我们遇到过 X 这种 hacking,后来用 Y 解决"远比"我懂 RL 理论"加分。具体的故事最有说服力。

Q15:你说 Planner 做调度,如果 Planner 自己规划错了,有什么 fallback?

考察容错设计。

回答:

执行时检测异常:子 Agent 返回错误码或低置信度结果时,Planner 收到信号。
重新规划:把错误信息和已执行步骤一起塞回去,让 Planner 重新规划剩余步骤(类似 ReAct 里的反思)。
降级策略:重试 N 次后还失败,降级到一个简单 RAG baseline,至少给用户一个"还行"的答案,而不是报错。
离线兜底:训练阶段就构造一批"故意让 Planner 出错"的数据,让它学会从错误中恢复。

Q16:线上推理延迟怎么优化的?6 个 Agent 串起来肯定很慢吧?

延迟优化是工程必问题。

回答:

能并行的并行:多路检索、多个工具调用,用 asyncio 并发执行。
能流式的流式:最终输出 Agent 用 streaming,首 token 延迟立刻降下来,用户感知好很多。
小模型分流:简单 query 用 Router 判断后直接走小模型/RAG baseline,不走完整 Agent 流程。
缓存:工具调用结果缓存(同样的 query 不重复调外部 API),embedding 缓存。
推理优化:vLLM / SGLang 部署,prefix caching 对多 Agent 共享 system prompt 场景特别有效。

复盘心得:Prefix Caching这个点在多 Agent 场景下太关键了,因为每个 Agent 的 system prompt 长且复用度高。能主动提到这个点,面试官眼睛会亮。

Q17:那你们的评测体系是怎么搭的?光看 case 不够吧?

这题是从"延迟优化"自然延伸过来的。面试官问得很刁:你怎么证明你的优化没有让效果变差?

回答:

离线评测集:按业务场景分类,每类 100-500 条,有标准答案或人工评分锚点。
指标分层:

任务完成率:终极指标,但粒度粗。
工具调用准确率:中间指标,定位是哪一步崩的。
延迟 / Token 消耗:成本指标。

A/B 评测用 LLM-as-Judge:GPT-4 对比两个版本的输出,但要注意位置偏置(把 A/B 顺序随机打乱),以及长度偏置(LLM 倾向于打分更长的回答)。
小流量灰度:线上 1%-5% 流量打到新版本,看真实指标(用户复购、点踩率)。

复盘心得:能讲清楚LLM-as-Judge 的几个偏置以及缓解方法,会非常加分,因为这是真正动手做过评测的人才会知道的细节。

Q18:你 prompt 是怎么管理的?改一次 prompt 怎么知道是好是坏?

Prompt 管理是个很实际的工程问题,也是很多团队的痛点。

回答:

版本化:Prompt 当代码管,放 Git,每次改有 commit message,可回滚。
结构化模板:用 Jinja2 / f-string 模板化,变量从代码注入,不要把 prompt 写死在代码里。
Prompt 评测流水线:每次改完 prompt 自动跑离线评测集,产出对比报告。
A/B 上线:重要 prompt 改动走灰度,不直接全量。
Trace 工具:用 LangSmith / Phoenix / 自研日志,能看每次调用的完整 prompt 和输出。这步是 debug 的命根子。

Q19:多 Agent 之间通信用的什么协议?为什么不用 MCP?

这题问得很新——MCP(Model Context Protocol)是 Anthropic 在 2024 年底推的协议,2025 年开始热起来。

回答:

当前是JSONover function call:基于 OpenAI tool calling 规范的 JSON,简单直接。
MCP****的定位:更标准化的工具/资源接入协议,适合跨团队、跨服务的场景。我们 6 个 Agent 在同一服务内,用内部 JSON 已经够,没必要引入 MCP 增加复杂度。
如果未来要开放第三方接入,MCP 是更好的选择,因为它定义了一套通用契约,让外部工具按规范接入即可,我们不用为每个新工具改代码。

复盘心得:面试官如果问"为什么不用 X",哪怕你真的没必要用,也要展现你知道 X 是什么、什么场景下该用。这显示你的技术敏锐度,而不是"封闭式自嗨"。

Q20:你说工具调用,那如果一个工具调用失败了怎么办?比如外部 API 超时?

容错设计的延伸题。

回答:

分类处理:

可重试错误(超时、限流、5xx):退避重试,最多 N 次。
不可重试错误(参数错、权限错):直接告诉 Agent,让它换思路。

超时设置:每个工具调用设独立超时,不能让一个慢工具拖垮整个 pipeline。
熔断:某个工具连续失败超阈值,临时熔断,降级到 fallback 工具或直接告诉用户该能力暂时不可用。
错误信息要可读:返回给 Agent 的错误信息要 LLM 能理解的自然语言,不要直接抛 stack trace,否则 Agent 不知道怎么处理。

Q21:模型微调你用的什么框架?LoRA 还是全参?为什么?

工程选型题,基本必问。

回答:

框架:LLaMA-Factory / Axolotl / 自研。LLaMA-Factory 上手快、适合中小团队,自研适合定制需求多的大团队。
LoRA****vs 全参:

LoRA:省显存、训练快、可插拔(同一底座挂多个 LoRA 切换任务),但容量上限低,大幅领域迁移效果差。
全参:容量大、效果天花板高,但显存需求是LoRA的几倍,工程上更重。

我们的选择:SFT 阶段用 LoRA(rank=64,alpha=128),GRPO 阶段也保持 LoRA,理由是工具调用本质是"格式学习",不需要改太多底层知识,LoRA 容量够用且训练成本可控。
如果是大幅风格改造(比如学一个全新领域的术语体系),会考虑全参。

追问:LoRA 的 rank 怎么选?答:经验值 8-128,任务越复杂 rank 越大。先小后大,从 16 开始试,效果不够再加,加到 64 还不够说明 LoRA 不够,该换全参了。

四、手撕环节

最后让手撕最长回文子串。

我第一反应是中心扩展,但写的时候在边界条件上反复出错——奇偶中心没处理干净,加上面试压力,最后超时没写完。面试官人很好,提示我可以写 DP 版本,但已经乱了阵脚……

复盘:这道题其实我做过,但离上次刷已经过了一个多月,导致细节遗忘。提醒大家:面试前一周一定要把高频题再过一遍,尤其是 DP 和双指针的边界条件。

正确的中心扩展模板(事后默写):

def longestPalindrome(s: str) -> str: ifnot s: return"" def expand(l: int, r: int) -> tuple[int, int]: while l >= 0and r < len(s) and s[l] == s[r]: l -= 1 r += 1 return l + 1, r - 1# 返回闭区间 start, end = 0, 0 for i in range(len(s)): l1, r1 = expand(i, i) # 奇数中心 l2, r2 = expand(i, i + 1) # 偶数中心 if r1 - l1 > end - start: start, end = l1, r1 if r2 - l2 > end - start: start, end = l2, r2 return s[start:end + 1]

关键易错点:

奇偶两种中心都要试,漏一种就 wrong answer。
expand退出时l, r已经多走了一步,所以返回l+1, r-1。
比较长度直接用r - l,不用r - l + 1(常数项不影响比较)。

如果选编辑距离,DP 模板更直接:

def editDistance(s1: str, s2: str) -> int: m, n = len(s1), len(s2) dp = [[0] * (n + 1) for _ in range(m + 1)] for i in range(m + 1): dp[i][0] = i for j in range(n + 1): dp[0][j] = j for i in range(1, m + 1): for j in range(1, n + 1): if s1[i-1] == s2[j-1]: dp[i][j] = dp[i-1][j-1] else: dp[i][j] = 1 + min(dp[i-1][j], # 删 dp[i][j-1], # 增 dp[i-1][j-1]) # 改 return dp[m][n]

教训:手撕之前一定先口述思路给面试官听,得到"嗯可以"再开始写。我当时直接埋头写,写错了改、改了再错,白白浪费时间还显得慌乱。

五、深度复盘:这次面试我学到了什么

这次面试虽然手撕崩了,但项目部分被"逼"出了很多原本没想清楚的东西。下面这部分是我事后花了两天整理的复盘,可能比面经本身更有价值。

5.1 项目深度,本质是"反向追问能力"

面试官的追问本质是对你声明的每一个事实做反向验证:

你说"我用了多 Agent" → 那为什么不是单 Agent?
你说"我没用 Redis" → 那别人为什么用?你的方案代价是什么?
你说"我用了 GRPO" → 那为什么不是 PPO/DPO?

准备项目时,要给自己当面试官。每一个技术点反复问三个问题:

为什么用它?(动机)
不用它会怎样?(反事实)
用了之后的代价是什么?(trade-off)

只要每个点都能答出这三层,面试时就不会被问到崩溃。

5.2 八股要成体系,不要零散点

我这次面试明显感觉到——面试官不是在测你"知不知道某个概念",而是在测你"对一个问题域的整体认知地图"。

比如问 GRPO,他要看你脑子里是不是有一张"RL****对齐方法对比表":GRPO、PPO、DPO、KTO、SimPO 各自的适用场景、优缺点、计算开销……

报训练营之前我自己看 Agent、看 RL,看了很多但都是散点,真正能系统化是从老师带着把项目从 0 到 1 拆解开始的。结构化整理在面试时帮了大忙,面试官一问,我脑子里立刻能调出对应的"格子"。

算是给后来同学一个不那么"广告味"的安利:自己学有自己学的好,但要在短时间(1-2 个月)内把零散知识体系化,跟着有经验的人过一遍项目效率会高很多。我至少省了 3 个月的弯路。

5.3 "不会"也有不会的答法

面试中肯定会有不会的问题,但怎么"不会"差距很大:

烂的回答:“这个我不太懂。”
中等回答:“这个我没做过,但我觉得可能是 XXX。”(有思考但不专业)
好的回答:“这个我没直接做过,但据我了解,业界一般有两种思路:一种是 A,优点是…缺点是…;另一种是 B,反过来。如果让我选,我会选 A,因为我们的场景 XXX。”(展现了视野和判断力)

面试官不指望你什么都会,但指望你"不会的时候有思考路径"。

5.4 简历是"地图",不是"清单"

我这次的最大教训之一:简历上每一个技术名词都可能成为深挖点。所以——

不要堆砌名词。“用了 LangChain、LlamaIndex、AutoGen、CrewAI、Faiss、Milvus、Pinecone……” 看着唬人,但任何一个被深问都答不上来就死。
写你能讲清楚的。哪怕只写一个 LangChain,但能从原理讲到坑讲到优化,远比堆 10 个名词强。
关键数字要准。“准确率从 70% 提升到 85%”——准备好回答"怎么测的?评测集多大?baseline 是什么?"。

5.5 项目"扩写"的方法论

这次面试还教会我一件事:同一个项目,可以讲出 30 分钟也可以讲出 5 分钟,关键在于你准备了多少层。

我事后整理出一个"项目扩写四层":

第 1 层(1 分钟):做了什么、用了什么、结果如何。简历上的版本。
第 2 层(5 分钟):架构图、关键模块、核心选型。自我介绍时讲的版本。
第 3 层(15 分钟):每个模块的细节、踩过的坑、对比的方案。深挖时讲的版本。
第 4 层(随便聊):行业背景、未来演进、和其他方案的对比。聊天级别的版本。

面试官追问到第几层,你能撑到第几层,就决定了你的项目分数。我这次撑到第 3 层中段,再深就磕巴了。

5.6 心态:把面试当成"付费咨询"

这次面试虽然结果未必好,但面试官帮我免费 review 了我的项目。他追问的每一个点,都是我项目里没想清楚的地方。

回去后我把所有问题列下来,一一补足。下次面试同样的项目,我已经能从容回答 2-3 倍深度的问题了。

别把面试当成审判,把它当成体检。挂了不可怕,挂了之后没复盘才可怕。

5.7 反问环节的小技巧

最后的反问,我问了两个问题:

团队当前最大的技术挑战是什么?—— 看团队成熟度,也让面试官展示自己。
你们对 Agent****训练数据的构造,是更偏向人工标注还是合成数据?—— 既体现专业度,也是真的想知道。

反问的三个层次:

低分:“咱们这个岗位主要做什么?”(简历应该提前看的)
中分:“团队的技术栈是什么?”(常规问题)
高分:“我注意到你们最近在 XX 方向有动作,想了解一下这块的演进规划?”(显示你做过功课)

结语：抓住大模型时代的职业机遇

AI大模型的发展不是“替代人类”，而是“重塑职业价值”——它淘汰的是重复性、低附加值的工作，却催生了更多需要“技术+业务”交叉能力的高端岗位。对于求职者而言，想要在这波浪潮中立足，不仅需要掌握Python、TensorFlow/PyTorch等技术工具，更要深入理解目标行业的业务逻辑（如金融的风险控制、医疗的临床需求），成为“懂技术、懂业务”的复合型人才。

无论是技术研发岗（如算法工程师、研究员），还是业务落地岗（如产品经理、应用工程师），大模型都为不同背景的职场人提供了广阔的发展空间。只要保持学习热情，紧跟技术趋势，就能在AI大模型时代找到属于自己的职业新蓝海。

最近两年大模型发展很迅速，在理论研究方面得到很大的拓展，基础模型的能力也取得重大突破，大模型现在正在积极探索落地的方向，如果与各行各业结合起来是未来落地的一个重大研究方向

大模型应用工程师年包50w+属于中等水平，如果想要入门大模型，那现在正是最佳时机

2025年Agent的元年，2026年将会百花齐放，相应的应用将覆盖文本，视频，语音，图像等全模态