AI 全栈开发工程师二面面经

大家好，我是Yuka。

9.20下午面的，9.22收到意向书。面试官全程笑着聊，但问题一点都不水，特别喜欢问"如果让你设计，你会怎么做"。我面完感觉还行，结果真过了，反馈说项目匹配度高、技术深度够。

上来先手撕LRU，写完追问泛型和过期时间，再追问多线程安全。后面全程场景题，从RAG切分问到Agent编排，从缓存一致性问到Agent评测。

能过不是因为运气。RAG和Agent编排我答得稳，业务异常、成本、评测和一致性这几块也扛住了，因为都是我自己踩过坑的地方。

手撕：LRU，追问泛型和过期时间，再追问多线程安全
标准LRU用哈希表加双向链表。哈希表O(1)查找，双向链表O(1)插入删除。get时把节点移到头部，put时如果满了就淘汰尾部。

泛型：用Java的泛型，节点类也带泛型。过期时间：每个节点加expireTime字段，get时检查是否过期，过期就删除并返回null。后台起一个定时线程定期清理过期节点。

多线程安全：给get和put加锁，用ReentrantLock或synchronized。但要注意锁粒度，get和put都要加锁，因为会修改链表。更高效的是用ConcurrentHashMap加分段锁，或者用读写锁，读多写少时性能更好。我顺带说了ConcurrentHashMap在JDK8之后是CAS+synchronized，锁粒度到桶级别，面试官点头。

我现场写了基础版LRU，泛型和过期时间是面试官追问后改的，多线程安全答了加锁，还补了分段锁和读写锁的取舍，面试官继续追了一句"读写锁会不会饿死写线程"，我答了公平锁和降级策略，这轮过了。

1. 自我介绍
   常规。我重点讲了智能运维Agent项目，强调了对Agent架构、RAG、工具调用的理解，以及实际踩过的坑。

2. 你这个智能运维Agent为什么做？解决什么痛点
   智能运维Agent解决的是运维人员排查故障效率低的问题。传统运维靠人看监控、查日志、翻文档，一个故障排查可能几小时。Agent自动收集监控指标、分析日志、匹配知识库、生成诊断建议，把排查时间压到分钟级。

具体场景：服务告警触发，Agent自动拉取最近1小时的CPU、内存、GC、慢查询指标，分析日志里的异常堆栈，检索知识库里的历史故障案例，生成诊断报告和修复建议。

我踩过的坑：早期Agent乱给建议，因为它不懂业务上下文。后来加了知识库检索和规则校验，建议准确率从50%提到85%。

1. 系统整体运转流程讲一下，中间件选型依据是什么
   流程：告警触发→Agent接收事件→并行拉取监控、日志、链路数据→多模态融合分析→知识库检索→LLM生成诊断→推送给运维。

中间件选型：消息队列用Kafka，因为告警量大需要削峰。缓存用Redis，存会话状态和热点数据。向量库用Milvus，存知识库embedding。存储用MySQL加对象存储，结构化数据存MySQL，原始日志存对象存储。

选型依据：Kafka吞吐高，适合告警洪峰。Redis读写快，适合会话状态。Milvus支持大规模向量检索。我踩过坑：早期用RabbitMQ，吞吐不够，告警积压。后来换Kafka才解决。

1. 为什么用RAG？现在上下文窗口很大，为什么不直接把原始文档都给Agent
   上下文窗口再大也有上限，而且成本高。直接把所有文档塞进上下文，token消耗巨大，推理延迟也高。更重要的是，信息太多反而会稀释关键信息，导致Lost in the Middle问题——模型对中间部分的内容注意力下降，关键信息可能被忽略。

RAG的优势是精准检索——只把最相关的文档片段注入上下文，token少、延迟低、准确率高。我实际对比过，同样的问题，RAG的准确率比全量文档高20%，成本只有十分之一。

2026年虽然有些模型支持1M甚至10M上下文，但长上下文下的推理质量并不稳定，而且成本极高。RAG仍然是生产环境的主流方案。

1. RAG和"把文件交给Agent，让它自己grep检索"各有什么优劣
   RAG是预索引，检索快，但索引构建有成本，而且索引是静态的，文档更新需要重建。Agent grep是动态检索，灵活，不需要预索引，但每次都要读文件，速度慢，而且大文件读不进来。

RAG适合知识库相对稳定的场景，比如产品文档、技术手册。Agent grep适合代码仓库这种频繁变更的场景，直接grep最新代码，不用维护索引。

我实际项目里两者结合：知识库用RAG，代码仓库用grep。2026年有些团队用Agentic RAG，让Agent自己决定什么时候用RAG、什么时候直接读文件，比固定流程更灵活。

1. RAG里切块、索引、存储、检索、排序，哪些步骤最影响最终效果
   切块和排序影响最大。切块决定了召回的基本单元，切得不好，再好的检索也白搭。排序决定了最终注入上下文的顺序，顺序不对，关键信息被淹没。

切块的关键是语义完整性——不能把一个完整的段落切碎。排序的关键是相关性——最相关的放开头和结尾，避免Lost in the Middle。

我踩过坑：早期切块用固定长度，把代码块切断了，召回效果很差。后来改成按语义边界切分，召回率从60%提到85%。排序上，加了Reranker后准确率又提了10%。

1. Markdown文件没有标题，怎么切分
   按段落和空行切分。连续两个换行视为段落边界，代码块和表格整体保留不切。如果段落超长，按句子边界切——句号、问号、感叹号。

更细的可以用Markdown的语法特征：列表项整体保留，引用块整体保留，代码块整体保留。这些结构如果被切断，语义就不完整了。

我踩过坑：把代码块切断了，检索到一半的代码，模型看不懂。后来加了一个规则，代码块和表格永远不切，即使超过chunk size也整体保留。

1. chunk size怎么定？切太大切太小分别有什么问题
   chunk size要看文档类型。技术文档512 tokens，法律合同256 tokens，代码按函数切分。没有一个万能值。

切太大：检索粒度粗，一个chunk里可能包含多个主题，检索时匹配不精准。而且注入上下文时token多，成本高。

切太小：语义碎片化，一个完整的段落被切碎，模型拿到碎片理解不了。而且召回时可能只召回一部分，信息不完整。

我实际对比过256、512、1024三种，512在Recall@5和MRR上平衡最好。256召回率高但精确率低，1024精确率高但召回率低。

1. BM25关键词检索和向量检索各有什么优缺点
   BM25优点是精确匹配强，对专有名词、数字、代码符号敏感，不需要训练，解释性好。缺点是语义泛化差，同义词匹配不到，比如"降价"匹配不到"促销"。

向量检索优点是语义理解好，能匹配同义词和相关概念。缺点是对低频词和专有名词不敏感，而且需要embedding模型，有训练和推理成本。

两者互补，所以生产环境用混合检索。我踩过坑：只用向量检索，搜"B站"匹配到"哔哩哔哩"，但搜"UP主"匹配不到"up主"，因为大小写敏感。后来加了BM25才解决。

1. 两路召回结果怎么融合？RRF的k值怎么设
   用RRF（倒数排名融合）。每路召回Top-K，按排名算分：score = Σ 1/(k + rank_i)。RRF不需要归一化分数，直接融合排名，简单有效。

k值通常设60。k越小，排名靠前的权重越大；k越大，排名影响越平滑。我实际用60，效果稳定。融合后再用Reranker做二次精排，取Top-5送LLM。

踩过的坑：k值设太小，头部结果权重过大，长尾好结果被淹没。后来调回60才平衡。另外，RRF之后一定要Rerank，不然融合结果还是粗排，准确率不够。

1. 短query和长chunk向量化后怎么比较？有没有做过对比
   短query信息密度低，长chunk信息密度高，直接算余弦相似度会有偏差。解决方案是Query扩展——把"降价"改写成"商品降价促销优惠折扣"，用扩展后的query去匹配chunk。

或者用HyDE——让LLM先生成一个假设答案，再用假设答案的embedding去检索。假设答案和长chunk在语义空间更接近。

我做过对比：直接用短query检索，Recall@5是0.72；用Query扩展后，Recall@5提到0.85；用HyDE，提到0.87。HyDE效果最好但成本最高，Query扩展性价比最高。

1. 如果知识库里没有答案，怎么让模型不乱说
   三层防护。第一层：Prompt里明确指令"如果信息不足，请说'根据目前的信息，我无法确定'，不要编造"。

第二层：检索结果置信度过滤，相似度低于阈值的不注入上下文，直接返回"未找到相关信息"。

第三层：输出后做事实核查，把生成的答案和检索结果做一致性校验，如果答案里出现了检索结果中没有的信息，标记为可疑，重新生成或拒绝回答。

我踩过坑：模型编造了知识库里没有的API用法，用户照着用出了bug。后来加了事实核查才解决。防止幻觉的核心是让模型"有依据地说话"，没有依据就不说。

1. 多Agent协作时，任务怎么分配？状态怎么管理？结果怎么汇总
   任务分配：Planner把任务分解成子任务DAG，按依赖关系和优先级分配到不同Worker。没有依赖的并行，有依赖的串行。

状态管理：全局状态存Redis，每个Worker有自己的局部状态。全局状态记录任务进度、已完成子任务、中间结果。局部状态记录Worker自己的上下文和推理历史。

结果汇总：Supervisor收集所有Worker的结果，做冲突检测和仲裁。如果多个Worker结果冲突，用加权投票或LLM仲裁。最终结果由Supervisor统一输出。

我踩过坑：早期没有全局状态，Worker之间不知道彼此进度，重复执行。后来加了全局状态管理器才解决。

1. 多Agent并行执行，怎么防止上下文和状态互相污染
   上下文隔离：每个Agent有独立的上下文窗口，不共享对话历史。Agent之间通过消息传递通信，不直接读对方的上下文。

状态隔离：每个Agent有独立的局部状态，全局状态只读不写。写全局状态要通过Supervisor，避免并发写冲突。

资源隔离：每个Agent有独立的沙箱或命名空间，工具调用互不干扰。

我踩过坑：早期Agent共享上下文，结果A的对话历史被B看到，B的回答跑偏了。后来加了上下文隔离才解决。2026年A2A协议里有任务编排和状态管理，多Agent协作可以通过标准协议避免污染，比自研隔离更可靠。

1. 工具调用失败、超时、重复调用，分别怎么处理
   失败：区分可重试和不可重试。超时、网络抖动、限流可重试，参数错误、权限错误不可重试。可重试的用指数退避，最多3次。

超时：设置超时时间（比如10秒），超时后先检查工具是否支持幂等。支持幂等就重试，不支持就返回失败让模型换方案。

重复调用：记录调用历史，相同工具加相同参数在短时间内只调一次，返回缓存结果。我踩过坑：Agent反复调同一个搜索工具，后来加了去重缓存才解决。

重试要有全局限流，避免重试风暴打垮下游。下单类工具调用前先生成唯一request_id，工具端用request_id做幂等键，防止重复下单。

1. 设计"智能行程规划Agent"：用户说"周末去南京玩两天，预算2000"，你怎么做工具编排
   先做意图解析，提取目的地南京、时间两天、预算2000。然后Planner拆成四个并行子任务：查天气、搜酒店、推荐景点、规划路线。

工具编排：天气API查南京周末天气，酒店API按价格区间和位置搜，景点API按热度和类型推荐，路线API算景点间交通。四个任务并行执行，Supervisor汇总生成行程表。

预算控制：2000元要分配到交通、住宿、餐饮、门票。Agent先算大交通和住宿，剩下的分配到餐饮和门票。如果超预算，自动调整——降低酒店星级、减少收费景点。

我踩过坑：早期没做预算控制，生成的行程超预算，用户不满意。后来加了预算分配和动态调整才解决。

1. 如果第二天南京下雨，Agent怎么应对
   触发动态重规划。Agent检测到天气API返回"雨"，自动把第二天的户外景点替换成室内景点——博物馆、美术馆、商场。同时调整路线，把室内景点按距离重新排序，避免用户在雨里走太远。

如果用户已经出发，推送通知："第二天有雨，已为您把中山陵换成南京博物院，路线已更新。"

我踩过坑：早期没做动态重规划，用户到了景点才发现下雨，体验很差。后来加了天气监听和自动重规划才解决。

1. 如果用户临时想把两天压缩成一天，怎么处理
   Agent先评估哪些景点可以合并或跳过。按优先级排序——用户最想去的排前面，次要的砍掉。然后重新计算路线，把两天的行程压缩成一天的高密度版本。

同时提醒用户"行程较紧，建议早点出发"。预算也重新分配，酒店可能从两晚改成一晚，省下的钱加到餐饮或门票上。

我踩过坑：压缩后行程太赶，用户玩得很累。后来加了"松紧度"评估，如果压缩后每个景点停留时间少于1小时，就提醒用户"建议保留两天"。

1. 用户需求很模糊，比如"我想找个好吃的"，怎么做多轮澄清
   第一轮问品类——"您想吃什么类型的？中餐、西餐还是日料？"第二轮问位置——"您大概在哪个区域？"第三轮问预算——"人均预算大概多少？"第四轮问场景——"是约会、家庭聚餐还是一个人随便吃？"

收集够四个关键维度就自动退出澄清，开始搜索。如果用户三轮都不回答，给默认推荐——热门高分餐厅，不无限追问。

我踩过坑：早期追问太多，用户不耐烦。后来限制最多3轮澄清，超过就给默认推荐。澄清的目的是提高准确率，不是把用户问烦。

1. 设计"电商搜索排序Agent"，用户搜"连衣裙"，你怎么设计排序模型？特征有哪些
   排序模型用LambdaMART或双塔DNN。特征分四类：文本相关性、商品质量、用户偏好、实时行为。

文本相关性：query和标题的BM25分、embedding余弦相似度。商品质量：销量、评分、退货率。用户偏好：历史点击品类、价格带偏好。实时行为：近1小时点击、加购、收藏加权。

评分公式：score = 0.4×文本相关性 + 0.25×商品质量 + 0.2×用户偏好 + 0.15×实时行为。权重通过线上A/B测试调优。

Agent的角色是动态调整权重——如果用户搜索词很具体，文本相关性权重调高；如果搜索词泛，用户偏好权重调高。

1. AI Coding：电商搜索排序题，给你query和商品特征，输出排序分数，提升NDCG@10，你会怎么搭链路
   链路：特征工程→模型选型→训练→预测→评估。

特征工程：文本特征（BM25、embedding相似度）、商品特征（价格、销量、评分）、交叉特征（query和品牌的匹配度）。

模型选型：LambdaMART，对NDCG优化好。训练时按搜索词分组，组内排序，损失函数直接优化NDCG。

评估：NDCG@10，重点看前10个位置的排序质量。线上A/B测试对比新旧版本。

我踩过坑：早期用pointwise模型，每个商品独立打分，没有考虑组内排序。后来改成listwise，NDCG提升了15%。

1. 缓存穿透、缓存击穿、缓存雪崩区别是什么？分别怎么解决
   穿透：查不存在的数据，缓存和数据库都没有。解决：布隆过滤器拦截，或者空值缓存设短TTL。

击穿：热点key失效瞬间大量请求打到DB。解决：互斥锁，只允许一个线程查DB，其他等待。

雪崩：大量key同时失效或Redis挂了。解决：过期时间加随机偏移，Redis高可用，本地缓存兜底，限流熔断。

我踩过坑：热点key没加互斥锁，失效瞬间DB被打爆。后来加了互斥锁才解决。三者的共同点是都会导致DB压力大，但原因不同，解法也不同。

1. Redis分布式锁怎么实现？锁过期了业务还没执行完怎么办
   加锁用SET key value NX EX 30，value存唯一标识（UUID），释放锁用Lua脚本校验value再删除，保证原子性。

锁过期业务没执行完：用Watch Dog自动续期。获取锁后启动后台线程，每隔过期时间的1/3检查锁是否还在、是不是自己持有的，是就执行EXPIRE延长过期时间。

我踩过坑：没做续期，业务执行到一半锁过期，其他线程抢到锁，导致并发问题。后来加了Watch Dog才解决。续期也要设最大次数，防止业务真的卡死时锁永远不释放。

1. 先更新数据库再删缓存，还是先删缓存再更新数据库？为什么
   先更新数据库再删缓存。因为如果先删缓存再更新数据库，在删缓存和更新数据库之间，如果有读请求进来，会把旧值重新加载到缓存，导致缓存里是旧值，数据库是新值，不一致。

先更新数据库再删缓存，即使删缓存失败，缓存里是旧值，但数据库是新值。下次读请求会从数据库加载新值到缓存。不一致的时间窗口更短。

更彻底的是延迟双删：更新数据库后删一次缓存，延迟几百毫秒再删一次。或者用binlog订阅，数据库变更后自动删缓存。

1. MySQL索引底层为什么用B+树？和B树有什么区别
   B+树非叶子节点只存索引不存数据，每个节点能存更多索引，树更矮，磁盘IO更少。B树所有节点都存数据，树更高，查询路径更长。

B+树叶子节点有双向链表，范围查询和排序效率高。B树做范围查询需要中序遍历，效率低。

我踩过坑：早期用B树，范围查询慢，后来换成B+树才解决。B+树是MySQL InnoDB的默认索引结构，3-4层能存千万级数据。

1. 如果Agent服务挂了，怎么保证用户无感知？有没有做熔断、降级、重试
   熔断：连续失败超阈值就切断，过段时间半开试探。降级：主模型挂了切备用模型，Agent挂了切Workflow，都挂了返回友好错误。重试：可重试错误用指数退避，最多3次。

用户无感知：降级要透明，用户不知道背后切换了。比如主模型挂了切备用模型，用户只感觉回答稍慢，但还能用。

我踩过坑：早期没做降级，模型API挂了整个服务不可用。后来加了备用模型和Workflow降级才解决。熔断要有监控告警，让运维知道服务降级了。

1. 你怎么评估一个Agent的效果？准确率、召回率、转人工率、端到端成功率怎么设计
   多层评估。最终结果：端到端成功率、用户满意度、平均交互轮数、成本。中间步骤：工具选择准确率、规划质量、ReAct效率。系统指标：P95延迟、错误率、Token消耗。

准确率和召回率要看场景：审核场景看准确率和召回率，问答场景看答案正确率，推荐场景看点击率。

转人工率是关键指标——Agent解决不了转人工的比例。转人工率高说明Agent能力不够，或者用户不信任Agent。

我踩过坑：只看端到端成功率，忽略了中间步骤。后来加了黄金测试集，对比实际执行轨迹和预期轨迹，能定位到具体哪一步出了问题。

反问
我问了三个问题：团队主要做AI全栈还是Agent平台？答：都有，看项目。业务场景偏内部提效还是C端？答：内部提效为主。实习生进去一般负责哪一块？答：看能力，可能做Agent开发也可能做平台。

写在最后
美团二面过了，但我知道不是侥幸。RAG和Agent编排我答得稳，业务异常、成本、评测和一致性这几块也扛住了，因为都是我踩过坑、真做过的东西。

面试官笑着问，但每个问题都在问"你怎么设计""出问题了怎么办"。尤其是缓存一致性和Agent评测那几道，问得很深，没踩过坑的人真答不上来——我刚好都踩过。

面完感觉还行，结果真过了，说明我对自己的评估比较准。以后面试继续从面试官角度想——他问这个问题的目的是什么，我答的是不是他想要的深度。

祝大家面试顺利，都能拿到心仪的offer 🙏