哔哩哔哩大模型面试岗，我悟了！！！

大家好，我是Yuki。周末跟一个在B站面试大模型算法实习岗的学员聊了整整两个小时，他说这场面试让他“一边冒汗一边开窍”。我让他把面试题完整复述了一遍，今天就把这场高质量的技术对话分享给大家。

说实话，这几道题问得是真有水平——不是那种背八股文能应付的，而是实打实考察你做项目的深度和思考力。

面试复盘：一场关于Agent的技术拷问

第一关：你现在做的Agent到底是什么？

面试官开门见山，没有废话。

如果你回答“就是一个能调用工具的AI”，那基本就凉了。面试官要听的是：你对自己做的事情有没有系统性的理解。

正确的打开方式是这样的：

“我负责的是一个面向科研场景的辅助Agent。它的核心定位不是替代研究者，而是解决科研流程中的三个痛点：文献检索碎片化、实验记录不规范、代码复现困难。我们把它设计成一个多角色协作系统，每个Agent负责科研环节中的一个具体任务。”

看出来差别了吗？先说痛点，再说方案，最后说架构。这是第一道门槛。

第二关：整个流程怎么设计的？

面试官追问流程设计，意思是在问：你有没有真正理解业务流和技术流的映射关系。

这里我画了一张图帮助大家理解：

面试官真正想看的是：你能不能把“一个Agent”拆解成“一组Agent”，并且说清楚它们之间怎么配合。

我那位学员答得不错，他提到了一个关键设计：反馈闭环。子Agent的执行结果会回流到主Agent，主Agent根据结果决定是直接输出还是启动修正流程。这个细节让面试官点了点头。

第三关：你说文献检索，是Deep Research吗？代码层面怎么实现的？

这个问题很刁钻。面试官在测试两件事：一是你能不能区分概念，二是你有没有真的写过代码。

先区分概念：Deep Research是一个完整的自主研究流程，包含假设生成、实验验证、结果整合；而你做的文献检索只是其中的一个模块。不要给自己脸上贴金，也不要妄自菲薄，准确表达即可。

再谈实现，这才是重头戏。这位学员当时是这么回答的：

“代码层面主要解决三个问题：检索策略、结果解析、质量评估。”
检索策略用的是查询扩展——用户输入‘LLM推理效率’，我们通过同义词库和领域本体扩展成3-5个检索式，并行访问arXiv、Semantic Scholar、PubMed等多个数据源。
结果解析麻烦的是PDF。我们用了一种分层解析方案：先用PyMuPDF快速提取文本和基础元数据，对包含公式和复杂表格的论文再调起Grobid做结构化解析。
质量评估这块，我们做了一个轻量级的相关性打分模型，基于SBERT，对标题和摘要做向量召回，过滤掉相关性低于阈值的结果。”

面试官接着问了一句：“那你们怎么处理检索结果的去重？”——这位学员说他们用了SimHash加上DOI精确匹配，双重去重。面试官明显对这个回答比较满意。

第四关：主Agent和子Agent共用同一个上下文吗？

这个问题考察的是对多Agent通信机制的理解。

正确答案是：分场景讨论，没有银弹。

这位学员的回答逻辑是：

共享场景：当多个Agents需要协作完成一个连贯任务时，比如文献调研→提炼观点→生成综述，共享上下文能避免信息断层。
不共享场景：当一个子Agent只负责独立子任务（比如纯代码生成）时，让它共享主Agent的完整历史只会引入噪声，降低性能，还容易泄露不该泄露的信息。

他最后总结了一句：“我们的方案是选择性共享——主Agent维护一个核心上下文窗口，子Agent只接收过滤后的相关片段。”这个回答有深度，说明他真的踩过坑。

第五关：讲一讲Tool Calling的具体实现

这道题是实打实的技术考察。大模型本身不能调用工具，它只能“表示想调用的意图”——这是很多新手容易搞混的点。

完整的实现流程是这样的：

技术细节上需要关注三层：

工具描述层：用OpenAI的Function Calling格式或Anthropic的Tool Use格式，把工具的名称、描述、参数schema传给大模型。
解析执行层：大模型返回的是一个JSON结构，你需要解析出tool名称和参数，然后去注册中心找到对应工具的真实函数，执行它。
结果回填层：工具执行的输出要重新喂给大模型，让它基于工具结果生成自然语言回复。

面试官可能会追问：“如果工具执行失败怎么办？”——这位学员回答了他们做了重试机制和降级策略。比如搜索引擎超时了，会尝试备用源；如果所有源都失败了，会明确告诉用户“工具调用失败，以下是根据模型自身知识生成的回答”，并且标注出来。这个细节很加分。

第六关：知道渐进式披露吗？解释一下

这个问题问得非常聪明。渐进式披露最初是UI/UX领域的概念，放到Agent场景里，指的是不要一次性给用户塞太多信息，而是按需、分层次地展示。

举几个例子你就明白了：

文献检索：先展示标题、作者、年份、摘要摘要，用户点开才显示全文解析结果和关键图表
代码生成：先展示代码的整体结构和核心函数，用户确认逻辑后再展开细节实现和依赖说明
多步推理：Agent先给出最终结论，用户追问“为什么”时才展开推理链

这位学员还举了一个反面案例：他们刚开始做Agent的时候，每次返回直接把几千字的完整分析全甩给用户，结果用户反馈“看着很炫酷但不知道怎么用”。后来改成分层展示，用户停留时长反而提升了。

面试官听完微微一笑——这说明你真的用过、踩过坑、优化过。

第七关：用LangGraph遇到的最大困难是什么？

这道题是压轴题。面试官不是在问你LangGraph的缺点，而是在问：你在复杂系统里解决问题的能力。

这位学员的回答很真诚，他说最大的困难是状态管理的不可预测性。

具体来说：

“LangGraph虽然提供了状态图的概念，但当你的Graph有十几个节点、几十条条件边时，状态在节点间的传递经常出现‘幽灵变量’——某些字段莫名其妙变成了None。我们排查了很久，最后发现是LangGraph在深拷贝状态时的bug。我们的解决方案是重新封装了状态传递层，所有跨节点的关键数据强制用JSON序列化后再反序列化，防止引用传递带来的副作用。”

他还补充了第二个困难：调试体验差。LangGraph没有像LangSmith那样好用的可视化调试工具，他们被迫自己写了一个状态日志记录器，每个节点进出都打印状态快照，才能追踪问题的根源。

这个回答好在哪里？承认了困难，但没有甩锅给框架，而是说了自己怎么解决和规避的。这就是面试官想看到的态度。