前言
大家好，我是木斯佳。
相信很多人都感受到了，在AI浪潮的席卷之下，前端领域的门槛在变高，纯粹的"增删改查"岗位正在肉眼可见地减少。曾经热闹非凡的面经分享，如今也沉寂了许多。但我们都知道，市场的潮水退去，留下的才是真正在踏实准备、努力沉淀的人。学习的需求，从未消失，只是变得更加务实和深入。
这个专栏的初衷很简单：拒绝过时的、流水线式的PDF引流贴，专注于收集和整理当下最新、最真实的前端面试资料。我会在每一份面经和八股文的基础上，尝试从面试官的角度去拆解问题背后的逻辑，而不仅仅是提供一份静态的背诵答案。无论你是校招还是社招，目标是中大厂还是新兴团队，只要是真实发生、有价值的面试经历，我都会在这个专栏里为你沉淀下来。专栏快速地址
温馨提示：市面上的面经鱼龙混杂，甄别真伪、把握时效，是我们对抗内卷最有效的武器。
面经原文内容
📍面试公司：海底捞
🕐面试时间：近期
💻面试岗位：前端开发二面
⏱️面试时长：1小时10分钟
📝面试体验：面试官超级好，引导式回答，但用户状态不好熬夜了，手撕想复杂了没撕出来
❓面试问题：
- 说说是什么契机开始接触并开发AI Agent？
- 你的职业方向偏向前端还是AI Agent？两者如何平衡、结合？
- 聊聊你学前端、AI相关技术的方法和心得？
- 介绍视频剪辑AI Agent的业务背景和整体架构？
- LangChain在剪辑Agent里的核心作用是什么？设计了哪些Chain链路？
- 为什么选用RabbitMQ作为任务队列，对比其他中间件有什么考量？
- 剪辑任务从30分钟压缩到5分钟，核心优化点有哪些？
- 讲讲Agent任务完整流转流程，以及内部有限状态机的设计思路？
- 前端、FFmpeg/MoviePy、AI Agent、消息队列四者的调用时序与协作逻辑？
- 项目中如何用JSON Schema约束大模型输出？实操遇到过哪些坑？
- 大模型输出不符合剪辑业务要求（非格式问题），你如何处理？
- 项目中遇到过LLM上下文窗口限制的问题吗？如何解决？
- 什么是任务幂等性？剪辑Agent里如何实现防重复执行？
- 为什么采用指数退避重试，而不是固定间隔重试？
- 大模型超时、宕机、响应异常时，项目的降级和兜底逻辑是什么？
- 分布式Celery多Worker消费队列，怎么做负载均衡？
- 消息队列出现消息积压、丢失，如何排查和解决？
- 线上会监控哪些核心指标？怎么配置告警？
- 为什么用P95/P99分位值统计耗时，而不用平均值？线上大致数据如何？
- 视频素材损坏、格式不兼容等前端异常，Agent层如何拦截处理？
- 异步架构相比同步架构，在AI Agent项目中的优势和弊端？
- 多用户同时发起剪辑请求，如何避免资源抢占导致卡顿？
- 谈谈你对RAG技术的理解，是否考虑融入当前剪辑Agent？
- 业务量翻倍，现有架构的瓶颈在哪，如何扩容改造？
- 能否把AI Agent和前端埋点系统结合，说说设计思路？
- 让你开发智能客服Agent，如何设计整体流程？
- 从开发、测试、上线到运维，讲讲AI Agent项目的落地全流程？
- 谈谈前端+AI Agent方向的未来学习和规划。
反问
- 有没有Landing期
- 您对loop的看法
来源：牛客网 晨时念
💡 木木有话说（刷前先看）
最近经过市场的洗礼，明显看出，AI 前端的要求比半年前要难不少了，从固定的套路题，延伸到工程化、架构等更深的内容，这也是在AI时代要求我们具备快速学习、快速适应的能力。
📝 海底捞前端二面·深度解析
🎯 面试整体画像
| 维度 | 特征 |
|---|---|
| 面试风格 | AI Agent系统设计型 + 架构深挖型 + 全链路追问型 |
| 难度评级 | ⭐⭐⭐⭐（四星，分布式任务队列、幂等性、降级兜底极深） |
| 考察重心 | Agent架构设计、消息队列、任务调度、性能优化、监控告警、系统扩展 |
| 特殊之处 | 28个问题全部围绕一个AI Agent项目，从架构到运维全链路覆盖 |
🔍 逐题深度解析
五、LangChain在剪辑Agent里的核心作用与Chain链路设计
回答思路 ：LangChain是Agent的"编排框架"，核心是Chain（任务链）。
核心作用：
- 任务编排：将复杂剪辑任务拆解成多个步骤（分析脚本→生成分镜→选择素材→合成输出）
- 工具调用：Agent调用FFmpeg/MoviePy等工具执行具体操作
- 状态管理：维护任务状态在链中的传递
Chain链路设计：
- 理解链：解析用户需求 → 生成剪辑大纲
- 规划链：分镜规划 → 素材匹配
- 执行链：调用FFmpeg执行剪辑 → 输出结果
- 校验链：验证输出是否符合预期
六、为什么选用RabbitMQ，对比其他中间件
回答思路：从消息可靠性、功能特性、生态成熟度等维度对比。
| 中间件 | 优势 | 劣势 | 适用场景 |
|---|---|---|---|
| RabbitMQ | 成熟稳定、支持ACK确认、死信队列、路由灵活 | 吞吐量相对Kafka低 | 需要可靠消息、复杂路由 |
| Kafka | 高吞吐、持久化好 | 延迟较高、运维复杂 | 日志收集、流处理 |
| Redis Stream | 轻量、低延迟 | 数据持久性弱 | 低延迟、非关键场景 |
选型理由 ：剪辑任务需要可靠交付 （ACK确认防止丢消息）和死信队列（处理失败任务），RabbitMQ最合适。
七、剪辑任务从30分钟压缩到5分钟，核心优化点
回答思路：分维度说明优化策略。
| 优化方向 | 具体手段 | 效果 |
|---|---|---|
| 并行化 | 将素材预处理、渲染分段并行执行 | 缩短总耗时 |
| FFmpeg参数优化 | 使用硬件加速（GPU编码）、调整编码参数 | 提升编码速度 |
| 缓存复用 | 缓存预处理后的素材，避免重复处理 | 减少重复计算 |
| 任务粒度 | 将大任务拆分成子任务，失败时只重试子任务 | 提升成功率 |
| 资源预留 | 预热FFmpeg进程池，减少启动开销 | 降低冷启动延迟 |
八、Agent任务完整流转流程与有限状态机设计
回答思路：状态机管理任务在不同阶段的状态转换。
状态定义：
pending → queued → processing → rendering → completed
↓ ↓ ↓
failed retrying cancelled状态机设计：
- 每个状态定义：进入动作、退出动作、允许的转换
- 使用**有限状态机（FSM）**模式管理
- 异常时进入
failed或retrying状态
十、JSON Schema约束大模型输出及踩坑
回答思路：JSON Schema定义输出结构，让LLM按指定格式返回。
踩坑点：
- LLM不严格遵守 ：有时返回
null或错误格式 - 复杂嵌套结构：LLM容易出错
- 枚举值精确匹配：LLM可能返回相似词而非指定枚举
- Schema描述不够清晰：LLM理解偏差
解决方案：
- 在Prompt中重复强调格式要求
- 使用后处理校验，不符合时重试或修正
- 用Few-shot示例展示正确格式
十一、大模型输出不符合剪辑业务要求（非格式问题）
回答思路：格式正确但内容不符合业务逻辑。
处理方案：
- 结果校验：用规则引擎校验剪辑指令是否合理（如时间戳不重叠、素材存在）
- 异常反馈：将校验失败信息反馈给LLM，要求重新生成
- 兜底策略：多次失败后使用默认剪辑模板
python
# 校验示例
def validate_clip_instruction(instruction):
if instruction['start_time'] >= instruction['end_time']:
raise ValueError("开始时间必须小于结束时间")
if instruction['duration'] > 60:
raise ValueError("单个片段不能超过60秒")十二、LLM上下文窗口限制及解决方案
回答思路：用户提到了"上下文窗口限制"，可以这样回答。
解决方案：
- 滑动窗口：只保留最近N轮对话，丢弃更早的
- 摘要压缩：对历史对话生成摘要，替代原始内容
- 分块处理：将长文档分块，逐块让LLM处理
- RAG检索：不保留全量历史，按需检索
十三、任务幂等性及防重复执行
回答思路：幂等性指同一操作执行多次结果相同。
实现方式：
- 任务ID去重：每个任务生成唯一ID，执行前检查是否已处理
- 分布式锁：同一任务ID只允许一个Worker执行
- 状态标记 ：任务执行完成后标记为
completed，再次请求直接返回结果
十四、为什么采用指数退避重试而非固定间隔
回答思路：指数退避可以避免"重试风暴"。
指数退避：延迟时间递增（1s → 2s → 4s → 8s），加上随机抖动。
优势：
- 避免惊群效应：防止大量失败任务同时重试压垮服务
- 给系统恢复时间：临时故障有时间恢复
- 减少无效请求：重试间隔越长，成功率越高
十五、大模型超时、宕机、响应异常的降级与兜底
回答思路：分层降级策略。
| 异常场景 | 降级策略 | 兜底逻辑 |
|---|---|---|
| 超时 | 重试（指数退避） | 超时3次后标记失败，人工介入 |
| 宕机 | 切换到备用模型 | 返回默认剪辑结果 |
| 响应异常 | 校验失败 → 重试 | 重试失败后使用模板 |
python
def call_llm_with_fallback(prompt):
try:
return call_primary_llm(prompt)
except TimeoutError:
return call_backup_llm(prompt)
except Exception:
return get_default_response(prompt)十七、消息积压、丢失排查与解决
回答思路：分维度排查。
消息积压排查：
- 检查消费者数量是否足够
- 检查单个任务处理耗时是否增加
- 检查生产者速度是否突然增大
消息丢失排查：
- 确认是否开启了持久化（
durable=true） - 确认消费者是否使用
auto_ack=False+ 手动ACK - 检查死信交换机是否配置正确
十八、线上监控核心指标与告警配置
核心指标：
- 任务量：QPS、积压数量
- 任务耗时：P50/P95/P99
- 成功率：任务成功率、重试率
- LLM调用：调用次数、延迟、错误率
- 基础设施：CPU、内存、网络
告警配置：
- 任务积压 > 1000 → 告警
- P95耗时 > 10s → 告警
- 成功率 < 95% → 告警
十九、P95/P99分位值 vs 平均值
回答思路：平均值会掩盖异常值，P95/P99反映"大多数用户的真实体验"。
示例：99个请求耗时1s，1个请求耗时100s
- 平均值 ≈ 2s（看起来很好）
- P99 ≈ 100s（反映真实体验）
线上数据：剪辑任务P95约8分钟，P99约15分钟。
二十二、多用户资源抢占导致卡顿的解决方案
回答思路：资源隔离与配额控制。
方案：
- 队列隔离：每个用户有独立任务队列
- 配额限制：限制单个用户的并发任务数
- 优先级调度：付费用户优先处理
- 资源池划分：为不同用户分配不同数量的Worker
二十五~二十六：AI Agent + 前端埋点结合 & 智能客服设计
埋点结合思路：
- 前端埋点 → 数据汇总 → Agent分析用户行为
- 输出个性化推荐、异常告警、A/B测试建议
智能客服Agent流程：
- 用户提问 → 问题分类（咨询/投诉/售后）
- 知识库检索（RAG）→ 获取相关FAQ
- LLM生成回答 → 返回用户
- 需要人工介入时 → 转接人工
📚 知识点速查表
| 知识点 | 核心要点 |
|---|---|
| LangChain | 任务编排、工具调用、Chain链路设计 |
| RabbitMQ选型 | 可靠交付、ACK确认、死信队列 |
| 性能优化 | 并行化、硬件加速、缓存复用、资源预热 |
| 状态机 | pending→queued→processing→completed |
| JSON Schema | 约束LLM输出格式，后处理校验 |
| 幂等性 | 任务ID去重、分布式锁、状态标记 |
| 指数退避 | 避免重试风暴、给系统恢复时间 |
| 降级兜底 | 备用模型、默认结果、人工介入 |
| P95/P99 | 反映真实用户体验，平均值易掩盖异常 |
| 资源隔离 | 队列隔离、配额限制、优先级调度 |
| 智能客服 | 问题分类→RAG检索→LLM生成→人工转接 |
📌 最后一句：
海底捞这场二面，是一场"AI Agent系统设计"的巅峰对决。从LangChain链设计、RabbitMQ选型、30分钟→5分钟优化，到幂等性、指数退避、降级兜底、P95监控，再到多用户资源隔离、智能客服设计、落地全流程，面试官用28个问题构建了一个完整的AI Agent系统设计框架。值得参考。