【黑芝麻智能】【Agent 开发】【暑期实习三面】面经（八股+大模型项目+手撕）

背景

海外一年制硕士，投递黑芝麻智能 Agent 开发暑期实习，三面技术面，面试官为 Agent 平台方向的技术负责人，全程约 70 分钟，节奏紧凑，项目追问占了大头。

题目摘要

1. Go 语言基础：defer 的执行顺序与闭包捕获、slice 扩容机制、map 并发读写为什么会 panic、context 的取消传播。
2. MySQL / Redis 八股：InnoDB 聚簇索引与回表，EXPLAIN 中 type 的等级；Redis 缓存穿透/击穿/雪崩的区分与各自解法，zset 底层跳表为什么不用红黑树。
3. RAG 链路深挖：文档切分策略怎么选、向量检索召回率低怎么排查、rerank 模型加在什么位置、如何评估 RAG 效果。
4. Function Calling 与上下文管理：工具 schema 怎么设计、多轮对话里上下文超长怎么裁剪、工具调用失败如何回滚。
5. 推理成本优化：prompt 缓存、模型分级路由、批量推理、流式输出对首 token 延迟的影响。
6. 手撕算法：给一个日志文件，每行格式为 timestamp user_id action，求「每个用户最近 N 条操作记录」，要求时间复杂度 O(n)、空间可控。关键思路：单次遍历 + 哈希表存每个 user 的定长双端队列（或环形缓冲），超出 N 就淘汰最旧记录，避免全量排序。

项目深挖

简历上写了一个自研的多工具 Agent 项目（支持搜索、代码执行、数据库查询三类工具），面试官几乎没问「做了什么」，全程在问「为什么这么做、出问题怎么办」。

追问一：你的工具路由是怎么做的？如果用户 query 模糊，模型选错工具怎么办？

参考回答方向：先说清路由机制——是把所有工具 schema 塞进 system prompt 让模型自己选，还是先做意图分类再缩小候选工具集。然后承认模糊 query 是真实痛点，给出兜底：一是工具描述里补充「不适用场景」和反例，降低误选；二是加一层校验，比如数据库查询工具在执行前先解析 SQL 做白名单校验，发现明显不匹配就返回结构化错误让模型重选；三是记录误选 case 做 few-shot 补充。不要只说「靠模型能力」，要体现工程兜底思维。

追问二：多轮对话上下文越来越长，你怎么控制 token 成本又不丢关键信息？

参考回答方向：分层讲。第一层是滑动窗口，保留最近 K 轮原文；第二层是对更早的对话做摘要压缩，摘要本身也控制长度；第三层是把结构化信息（用户偏好、已确认参数）抽出来单独存，不依赖原始对话。可以提一句「摘要会丢细节，所以涉及具体数值、ID 的信息我会单独落库，不放进摘要」。如果能顺带说 token 用量监控和按轮次统计成本，会加分。

追问三：你的 RAG 召回效果怎么评估的？有没有量化指标？

参考回答方向：坦白说清楚评估集怎么构造——从真实 query 里抽样，人工标注正确文档，算 Recall@K 和 MRR。然后说检索侧和生成侧分开评估：检索看召回率和排序，生成看答案是否忠实于召回文档（可以用 LLM 做 judge，但要说明 judge 也有偏差）。如果项目里没做完整评估，就诚实说「当时只做了人工抽检，后来意识到应该建评估集」，比硬编指标更可信。

准备建议

1. 把项目里的每个技术选型都准备一个「为什么不选另一个」。面试官高频问「为什么用向量库不用 ES」「为什么切 512 不用 1024」，答不上来会显得是照抄教程。花两小时把项目里 5 个关键决策的替代方案列出来，各写三行理由。

1. 八股不要背结论，背「排查路径」。比如缓存穿透，别只背布隆过滤器，要能说出「先看监控里是大量不存在的 key 还是热点 key 过期，前者用布隆/空值缓存，后者用互斥锁或逻辑过期」。面试官更想听你怎么定位问题。

1. 手撕题控制节奏，先讲思路再写代码。这次算法题不难但边界多（N 可能大于总记录数、时间戳乱序），写之前先和面试官确认输入假设，写完主动跑两个边界 case。很多人栽在闷头写、不沟通。

结果

三面通过，三天后 HR 约了终面沟通薪资与入职时间。

想系统备战大厂大模型/Agent 开发？NiceOffer 提供 SDE+LLM 双轨 1v1 陪跑，合同保底 40w 年薪，文末扫码咨询。