2026.10.15-大厂云游戏AI全栈二面面经与复盘

这场只有十分钟，感觉是被迅速斩杀了，但是还是可以总结一些问题出来

1.开场技术匹配问答

这波真的是打了我一个措手不及了，头一次见到上来不自我介绍，直接问当前技术积累与岗位匹配度，开始自由介绍的

于是一时间有点手忙脚乱，只能边想边说

大致是讲了个人的Agent开发流程，以及评测、可观测性、受控隔离环境，还有实现的初期Agent Runtime一个普通的ReAct的Loop，再到RAG以及受控代码任务

复盘整理一下措辞

我目前的学习和项目方向主要集中于Agent的底层架构以及应用落地，在三个方面做了深入的实践

首先是Agent Runtime与工程化流程，我自主开发了一个名为Tomato Agent的可恢复Agent运行环境，从最基础的ReAct循环切入，演进到了支持状态机与结构化实施计划的架构；同时，我总结了一套规范的Agent协作开发流程，通过绘制状态图，将太任务切片并设定门禁，记录开发日志与上下文恢复，保障了Agent生成代码与执行任务的稳定性

第二个是代码任务以及沙箱隔离，为了能够让Agent安全地执行复杂代码任务，我在工作区注册了自动化测试和代码修改等Tools，针对代码运行的安全性，我搭建了基于Docker以及NVIDIA开源的OpenShell的双重隔离沙箱，确保Agent运行Test和改写代码时的环境安全与可控

最后则是RAG系统与可观测性评估，我将自己的个人博客作为语料库建立了向量索引，搭建了RAG知识库系统，为了避免凭感觉评估系统，我引入了MRR等Benchmark量化指标，对召回率、稳定性和系统有效性进行了精准的量化，同时也深入了解了Agent的可观测性与评测体系

---

2.场景题：每秒实时候补人数因子对项目系统重构

针对我的铁路票价搜索系统项目，面试官询问如果铁路部门引入一个实时的候补人数作为票价因子，并且每秒抖动，如何根据这个来重构系统

这里可能因为太紧张，听成余票数量了，然后随便答了一个TTL和缓存回写，显然是非常垃圾的答案

重新考虑一下，这个属于一个多层次的问题

首先在算法层面，我们需要考虑对数据进行降噪

为什么？因为每秒都在抖动的人数，如果强求实时准确性，服务器毫无疑问会被打爆

第一做一个区间分级，候补人数从45变到47，对运力紧张程度并没有明显的提升，所以我们做一个阶梯桶，比如0-50，51-100，101-200这样，只有跨档才触发价格因子的大幅跳变，桶内微小抖动不计

第二做一个滑动窗口或者指数移动平均，用数学方式讲瞬时峰值平滑掉，防止黄牛脚本引起的剧烈价格波动

随后是架构层面，尽量不要让搜索请求去打到后端

进行一个事件驱动和写扩散，候补人数的实时变动，应该由数据流推送到后端集群，用一个后台Worker去消费、计算最新的动态价格，然后实时写入Redis中

读写彻底分离，用户的每次搜索请求，只去Redis中拿算好的最新价格，不然大量用户对后端请求和计算，会造成极大压力

最后是业务一致性层面，给价格上一个防崩溃锁

用户在前端看到某个价格的那一秒起，系统必须在Redis里给这个价格打个快照，设置一个5-10分钟的有效期，在这个期限内，用户下单价锁死