BIGO 后台开发 秋招二面面经

《面试题目》

1. 请先做一下自我介绍
2. 项目拷打
3. 如何设计客户端与服务端之间的图片安全上传链路？
4. 如果恶意客户端绕过正常流程直接访问网关接口，网关层需要做哪些防护？
5. 在一个包含 Skill、Agent、RAG 和 MCP 的完整调用链中，如何划分各层职责？
6. Agent 执行任务时，Skill、MCP 工具和模型之间应该如何确定加载顺序？
7. 如何解决客户端 AI 功能中的模型版本升级问题？
8. 如何设计客户端 AI 功能的离线评测和线上指标？
9. 如果客户端请求 AI 服务时网络断开，如何保证用户体验和服务端状态一致？
10. 如何设计高并发用户行为数据上报系统，保证数据尽量不丢失且不会无限阻塞客户端？
11. 实时高优先级事件和大批量普通事件同时上报时，如何避免普通数据挤占关键数据的资源？

---

《参考解析》

1. 图片安全上传链路：客户端校验只能算第一道门槛（限制后缀、大小、像素），真正的判断必须在服务端做。要点是：不信任 Content-Type，从文件头解析真实类型；限制尺寸与像素数，防止「小文件解压成超大位图」的炸弹；检查是否夹带脚本或路径穿越内容（../、SVG 里的 <script>）；重新编码一遍再落盘，顺便清掉 EXIF 元数据；上传后先进隔离存储，扫描通过再迁到业务存储；对外访问用短时效签名 URL，不暴露内部路径。整条链路的判据是「最终以解码后的真实文件为准」。
2. 网关层防护：身份上校验短期 token 和签名，签名要覆盖 method + path + timestamp + nonce + body 哈希——只签少数字段等于给攻击者留了替换未签名参数的余地；防重放靠时间戳有效期加 nonce 去重表；权限上按租户 / 资源 / 接口三个维度校验，不能采信客户端传来的用户 ID；流量侧按用户、设备、IP、接口分别限流，并对请求体大小和格式设上限；高风险接口加二次验证，异常请求全部留审计日志。网关是最后一道公共防线，业务侧不能假设「请求一定是客户端发来的」。
3. Skill / Agent / RAG / MCP 的分层：Skill 描述面向业务的能力和执行流程（比如「生成穿搭建议」）；Agent 负责理解目标、选 Skill、决定顺序、根据中间结果调整策略；RAG 负责从知识库补充事实（尺码规则、品牌规范），但不替代实时业务查询；MCP 以统一协议暴露工具和资源（商品、库存、审核状态）。一条链路是：用户请求 → Agent 识别意图 → Skill 生成任务流程 → RAG 取知识 → MCP 调工具 → Agent 汇总 → 返回结构化结果。关键约定是层与层之间传结构化数据，并记录版本、权限和来源，而不是把逻辑全堆进 prompt。
4. 工具与 Skill 的加载顺序：不能一次性把所有 Skill 和工具塞给模型，上下文变长会同时抬高成本和选错工具的概率。做法是分阶段加载：先按意图加载候选 Skill，Skill 声明本阶段需要的工具，进入具体步骤再加载对应 MCP 工具的描述，执行完根据结果决定是否加载下一组。工具描述要写清输入约束、权限要求、失败类型和幂等语义。还有一条硬约束——高风险工具不能仅凭「模型选了它」就获得执行资格，必须再过一层服务端的权限校验。
5. 模型版本升级怎么管：模型名只是其中一项，Prompt 版本、工具协议版本、后处理逻辑、评测数据集版本都要一起管。上线前做历史请求回放、固定数据集回归、边界样本测试、多设备多网络环境验证、延迟与成本对比，再小流量灰度。客户端不应该把模型名和协议细节散落硬编码在各个页面里，而应由服务端下发能力配置统一管理。如果新模型在部分任务上更好、部分更差，就用能力路由按任务分流，而不是一刀切全量切换。
6. 离线评测与线上指标：离线要覆盖正常样本、困难样本、边界样本和恶意输入，指标不能只看「输出读起来通不通顺」。可拆成意图识别准确率、结构化字段正确率、图片目标定位准确率、工具参数合法率、事实引用准确率、拒答与降级正确率、端到端任务完成率。线上关注首次响应时间、完整任务耗时、用户重试率与修改率、人工接管率、崩溃率和单次请求成本。生成类结果最好规则检查 + 模型评审 + 人工抽检三者结合，单靠自动评分容易自己骗自己。
7. 断网时的状态一致性：先分清「请求有没有到达服务端」——客户端断网不等于服务端没执行成功。查询类请求可以带请求 ID 安全重试；创建、修改、扣费类操作必须带幂等键，重试前先查原请求状态。客户端状态机可以是 CREATED → SENDING → UNKNOWN → SUCCESS / FAILED，进 UNKNOWN 时既不能直接显示失败，也不能盲目重复提交，而应优先调状态查询接口按服务端记录收敛。超时上要区分连接超时、读取超时和总超时，重试用指数退避，并且防止多个页面同时对同一操作重复提交。
8. 高并发行为数据上报：客户端不能为每次点击同步等服务端响应，应该走本地批量队列——事件先暂存，按批量大小或时间窗口批量上报。队列要设容量上限、事件优先级、过期时间，并处理应用异常退出后的恢复与敏感字段脱敏。服务端收到后先做快速校验再写消息队列，由消费者异步处理；关键事件给更高优先级和更长保存时间，普通曝光事件允许采样或丢弃。所有事件必须带唯一 ID，服务端用幂等表或去重缓存避免重复统计。
9. 优先级隔离怎么做：核心是别让所有数据共用一个无界队列。高优先级事件走独立队列和连接池，普通事件走批量异步上报；高峰时优先保留关键事件，普通事件到达上限就采样或丢弃；消费端也按优先级分配线程和资源。服务端可以用多级队列或不同 Topic 隔离。光隔离还不够，生产端必须对队列长度、发送失败率、积压时间和丢弃数量做监控——没有这些指标，隔离是否生效是看不出来的。