Binance AI 全栈开发实习一面面经

《面试题目》

1. 自我介绍。
2. 上一段经历做的项目是什么，背景是什么，有什么产出？
3. 为什么要用 multi-agent，是怎么编排的？
4. 质量检查 agent 一直不通过怎么办？
5. RAG 是怎么做的？出现新的情形和规则时怎么维护？
6. 遇到最大的困难和挑战是什么？
7. 这个项目是你自己想做的，还是公司安排分配的？为什么会想到做这样一个项目？
8. 你平常怎么用 AI？（答了有 vibecoding 项目，面试官顺势追问这个新项目）
9. 介绍一下这个新项目。
10. 如果我输入一段话，这个项目会发生什么？
11. 这个 agent 有哪些 tool？你怎么理解 MCP、skill？在项目里是怎么运用的？
12. 这个 agent 的异步路由是做什么的，怎么做的？
13. 用什么 AI 写的？

（准备手撕时卡在 LeetCode 页面加载不出来，一边等一边又聊了几个偏闲聊的问题）

14. 上一份工作做什么的，什么职责？
15. 如果让你现在回去重新做这个项目，你觉得会有什么不一样？
16. 你觉得 Jev 和其他模型相比有什么特点？
17. 手撕：输入存钱或者取钱及其金额，存钱输出账户余额，取钱输出一行取钱信息、一行账户余额。
18. 把代码粘贴给 AI，让 AI 改一下。
19. 解释一下 AI 改完的代码，你觉得它有什么问题？
20. 那要怎么优化？
21. 进阶：取钱可以先大于余额，等存钱满足要求时再输出取钱信息和余额，用什么思路，要用哪种数据结构？
22. 让 AI 写出来，并解释一下代码。

反问：使用什么技术栈和语言？

《参考解析》

1. 为什么要用 multi-agent、怎么编排（第 3 题）：先用「单 agent 为什么不够」回答反面：单 agent 把检索、推理、校验、生成塞在一条链上，职责混在一起，出错时无法定位是哪一步坏了，prompt 也会越写越长、相互干扰。拆成多 agent 的价值在于把不同职责隔离成独立上下文与独立模型档位——检索用便宜模型、推理用强模型、校验用带明确判据的模型，每个环节可单独评测和替换。编排方式要讲具体的：常见是编排者（orchestrator）模式，由一个调度器决定下一步交给谁，配合状态机或 DAG 约束合法转移；另一类是流水线式固定顺序传下去。要主动说清取舍——编排者模式灵活但成本高、延迟长、容易在循环里打转，所以工程上一般给最大步数、给终止条件、给每步超时。

2. 质量检查 agent 一直不通过怎么办（第 4 题）：这是最容易被追问穿的一题，因为它考的是「循环收敛」而不是「有没有校验」。答案要分层：先设上限，重试 N 次（通常 2 到 3 次）仍未通过就跳出循环，绝不无限重试，否则一次请求能把成本和延迟吃光。跳出后不能静默返回坏结果，要带上「哪条校验没过、失败证据是什么」降级返回给人或上游，让人决定。再往下是修根因：如果同一类问题反复失败，说明校验规则本身太严或生成侧的上下文不足，这时应该改 prompt、补检索证据、或把这条规则拆细，而不是调大重试次数。另外要对校验 agent 本身做误判分析——它也会错杀，所以校验最好做成可解释的规则加模型判断两层，规则先拦硬性错误。

3. RAG 与新规则维护（第 5 题）：RAG 讲三件事——切分、召回、重排。切分要按语义边界切而不是按固定长度切，块太大噪声多、太小丢上下文，通常还要给每块带上标题路径作为上下文；召回一般向量检索加关键词检索并行，避免专有名词被向量化后失真；重排用交叉编码器或模型打一遍相关性，把最相关的几条压到前面再喂给模型。「出现新情形和规则怎么维护」才是这题真正的考点：把规则从 prompt 里挪出去做成可维护的数据（规则库或知识条目），检索时与业务知识一起召回，这样加规则不用改代码、不用重训；同时给规则加版本与生效时间，避免新规则回溯影响历史结论。再补一句评测——固定一批问题做回归，改完规则跑一遍，否则「维护」就是盲改。

4. tool、MCP、skill 的区别（第 11 题）：tool 是模型能调用的一个具体函数，有明确的入参出参 schema，模型负责决定何时调；MCP 是把工具与数据源按统一协议暴露出去的标准层，好处是同一个服务端能被不同宿主复用，不用为每个客户端重写适配；skill 更上层，通常是一份写给模型的流程说明加上它需要的脚本和工具，解决的是「这类任务该怎么做」而不是「能调什么」。落到项目里要说清自己怎么用：哪些能力包成 tool 给模型自主选择，哪些写成 skill 固定流程以降低不确定性，哪些数据源用 MCP 接进来。能画出这三层的边界，这题就稳了。

5. 异步路由的作用（第 12 题）：目的通常是两类——按任务复杂度分流到不同模型或不同链路以控成本，以及把耗时的外部调用（检索、抓取、长生成）异步化以免阻塞主链路。实现上一般是一个分类步骤（规则命中优先，命中不了再用小模型判定）产出路由决策，再配合队列或任务表把每个分支的进度与结果落库，主链路只负责聚合与超时兜底。要主动说清难点：分流判错时的回退路径、异步任务的幂等（同一请求重放不能重复产生副作用）、以及超时后如何告知用户而不是静默卡住。

6. 手撕题与 AI 改代码（第 17 到 22 题）：第 17 题是基础的状态机，维护一个余额变量，存款累加、取款先判余额充足再输出流水与余额。第 19、20 题考的是「读得懂 AI 的代码」——AI 生成的版本最典型的漏洞就是没处理取款金额大于余额，导致余额为负数，正确做法是加前置校验、拒绝这笔交易并给出明确错误。第 21 题的进阶是本场真正的分水岭：需求从「立即失败」变成「允许挂账、等后续存款满足时再结算」，这已经不是单变量的题，而是待处理队列加结算循环。思路是维护一个按到达顺序排列的待结算请求队列（FIFO，保证先到先满足），存款时把金额灌进一个可用的结算池，然后循环从队头取出请求，够就扣减并输出该笔的流水与余额、不够就停下等待下一笔存款；数据结构上可以用队列或双端队列，队列元素记录金额与原请求序号。面试官接着让 AI 把这版写出来并要求解释，考的是你能不能判断 AI 写出的循环有没有正确终止、会不会漏掉队头阻塞的场景。