面试面经 · 深信服
【深信服】【Agent 开发】【暑期实习HR面】面经（八股+大模型项目+手撕）
背景
海外一年制硕士，投递深信服 Agent 开发暑期实习，简历上有一段基于开源 LLM 的客服 Agent 项目，主打 RAG + 工具调用，无大厂实习。
题目摘要
面试整体节奏快，约 50 分钟，技术深度中等偏上，重点围绕项目真实性和工程落地细节。考点分布如下：
- Go 语言基础：goroutine 与 channel 的协作模式、GMP 调度模型简述、内存逃逸分析场景
- MySQL 八股：聚簇索引与非聚簇索引区别、最左前缀原则、事务隔离级别（RR 下幻读如何解决）
- Redis 八股：缓存穿透/击穿/雪崩的区分与应对，ZSET 底层跳表结构，以及一个实际场景设计题
- Agent 项目深挖：RAG 检索效果优化、Function Calling 的触发机制与容错、多轮对话上下文管理、推理成本优化手段
- 手撕算法：实现一个带过期时间的 LRU Cache（要求 get/put 均为 O(1) 复杂度）
项目深挖
面试官提前看过简历，上来直接问项目细节，没有寒暄。以下是最有代表性的三个追问方向：
追问一：你 RAG 检索效果不好时，具体怎么排查和优化的？
参考回答方向：先分模块定位问题——召回阶段还是生成阶段。召回阶段我做了三件事：第一，对比了纯向量检索和混合检索（BM25 + 向量）的命中率，发现长尾专有名词用关键词召回更准；第二，对 chunk 大小做了消融实验，从固定 512 字符改为按语义边界切分，并加了 20% 的 overlap；第三，加了 rerank 层，用 bge-reranker 对 top-20 结果重排取 top-5。生成阶段主要处理了 prompt 中检索片段过多导致的注意力分散，限制为最多 3 段相关文本。
追问二：Function Calling 是怎么实现的？如果模型调用了不存在的函数怎么办？
参考回答方向：我用的是 OpenAI 兼容的 function calling 协议，底层模型支持 tools 参数。实现上维护了一个函数注册表，每个函数有 name、description、parameters JSON Schema。模型返回 tool_calls 后，先做参数校验再执行。对于非法函数名或参数格式错误的情况，做了两层容错：第一层是 catch 异常后把错误信息拼回对话历史，让模型重新生成调用；第二层是设置最大重试次数（3 次），超过后返回兜底话术而不是直接报错。另外，所有函数执行有超时控制，防止工具卡死拖垮整个 Agent 响应。
追问三：多轮对话上下文越来越长，你是怎么控制成本的？
参考回答方向：这里我做了三层优化。第一层是对话历史裁剪，用滑动窗口保留最近 N 轮，同时用摘要模型把更早的历史压缩成一段摘要注入系统提示词；第二层是检索上下文压缩，RAG 召回的文档片段不全部塞进 prompt，而是先做相关度过滤，再按 token 预算截断；第三层是模型分级——简单意图用便宜的小模型，复杂推理才用大模型，通过一个意图分类器做路由。整体下来单轮推理成本降了约 40%。
手撕算法：带过期时间的 LRU Cache
题意：设计一个数据结构，支持 get(key) 和 put(key, value, ttl) 操作，ttl 为过期时间戳。get 时若 key 已过期视为未命中并删除。要求 get 和 put 的平均时间复杂度 O(1)。
关键思路：在标准 LRU（哈希表 + 双向链表）基础上，每个节点额外存储 expireAt 时间戳。get 时先检查是否过期，过期则删除节点并返回 -1。put 时若 key 存在则更新值和过期时间并移到链表头部；若不存在则插入头部，若容量超限则淘汰尾部节点（同时删除哈希表映射）。
面试官追问：如果同一个 key 被重复 put，旧的过期时间怎么处理？——直接覆盖为新的过期时间即可，不需要额外处理。另一个追问：如果 TTL 很短且写入频繁，有没有优化空间？——可以用惰性删除 + 定时清理结合，避免每次 get 都检查所有过期节点。面试官点头后没有继续深入。
准备建议
- 项目必须能讲出量化指标。面试官对"效果好了"这种描述完全不买账，每个优化点都要有数据支撑——召回率提升多少、延迟降低多少、成本节省多少。建议提前把项目的基线指标和优化后指标列成表格，烂熟于心。
- 八股准备要结合业务场景。深信服的面试官不喜欢直接背定义，MySQL 会问"你项目里这个查询为什么慢，怎么优化"，Redis 会问"缓存雪崩了你线上怎么处理"。建议把常见八股点都套在自己的项目场景里过一遍，准备出"场景→问题→方案"的叙事线。
- 手撕题务必练熟 LRU/LFU 和堆相关的变体。这次考的带过期时间 LRU 是经典题的常见变形，面试官关注的是边界条件处理（过期、容量满、重复 key）。建议在 LeetCode 146 基础上自己扩展实现 2-3 个变体，并手写流畅度要达到 10 分钟内完成。
结果反馈
一面通过，约 3 天后收到二面邮件通知，二面为技术 Leader 面，侧重点转向系统设计和工程落地。
想系统备战大厂大模型/Agent 开发？NiceOffer 提供 SDE+LLM 双轨 1v1 陪跑，合同保底 40w 年薪，文末扫码咨询。
