1. 做一下自我介绍2. 如果一个核心链路已经同步调用很多下游了，为什么还要引入消息队列，而不是继续堆线程池消息队列真正解决的不是“异步”两个字，而是削峰、解耦、容错和流量治理。同步链路堆线程池只能把等待成本从调用方挪到自己进程里，并不能改变系统容量边界；一旦下游抖动，请求会在调用链上层层堆积，最终把连接池、线程池和网关超时一起拖崩。引入 MQ 后，主链路可以只做核心事务，非核心逻辑异步化，下游能力不足时也能通过堆积和消费速率控制做缓冲。不过 MQ 不是银弹，如果业务要求强一致、低延迟、同步结果可见，盲目异步反而会把复杂度转移到补偿和状态机里。3. 从生产端到消费端，怎么把“消息不丢”这件事讲...

继上次三方毁约后，又拿到了腾讯社招offer

已拉黑：美团，百度，米哈游已点赞：快手，网易，众安，字节跳动，蚂蚁ttl：3.16投递-3.25 一面-3.30 二面-3.31 hr面-4.2 oc

最近参加了几场大厂的Agent专项面试，我最大的感触是：面试官已经不满足于听你聊怎么写Prompt了，他们更在乎你如何处理“大模型的不可控性”以及多步骤任务中的“工程闭环”。被问到最多的两个底层逻辑容错与自纠错机制：面试官一定会问：“如果Agent调用的工具返回了报错，或者结果不符合预期，你的系统会崩掉吗？”优秀的回答不应该是“重新提问”，而是你如何设计反馈循环。比如，你是否在架构中加入了一个“评价者”角色，专门审视执行结果？或者是否建立了类似于代码调试的Retry逻辑，让Agent能根据错误日志自我修正。记忆存储的“度”：“你是如何处理长对话记忆的？”如果你只说全部塞进上下文，那面试官大概率...