1. 详细介绍一下你负责的项目，系统架构是怎么设计的？答：项目背景：介绍业务场景、用户规模、日活量、并发量等关键指标，说明团队规模和你的角色定位技术架构： 接入层：Gateway网关统一入口，负责路由转发、限流、鉴权服务层：按业务拆分微服务，Feign做同步调用，MQ做异步通信，Nacos做注册中心和配置中心数据层：MySQL主从读写分离，Redis缓存，MQ削峰填谷技术难点：重点说高并发优化（多级缓存、限流、异步）和分布式事务（MQ最终一致性）监控运维：Skywalking链路追踪，ELK日志分析，Prometheus+Grafana监控告警关键：每个技术选型要说清楚为什么这么选，有没有考虑...

总时长35分钟，无手撕，感觉遇到KPI面了，唉35分钟一直在问实习，八股就问了下面的1.redis与数据库的缓存一致性2.redis的zset数据结构3.redis的两个持久化机制4.分布式cap理论5.什么时候ap，什么时候cp6.进程线程协程问怎么没手撕，说一面撕过了，业务是应用宝游戏商城，后面过了还有一面技术面，问面试表现，说挺顺的，可以再关注一下运维数据，然后问转go有难度嘛，就结束了

有一个问题：Multi-Agent 架构到底适合什么场景？ 很多人第一反应是：“任务复杂的时候就用多 Agent。” 然后面试官就会继续追问：什么叫复杂？复杂体现在哪？引入多 Agent 的代价是什么？有没有明确不该用的场景？ 如果这些问题答不清楚，这道题基本就丢分了。 真正成熟的回答，不是“复杂任务适合拆分”，而是要给出一套可操作的判断框架。结合 Claude Code、Codex 类产品的实战经验，可以把这个问题归结为一句话： 默认先用单 Agent，只有在单 Agent 已经暴露出明显瓶颈时，才引入 Multi-Agent。 好像也是很扯。 为什么不能默认上 Multi-Agent？ 很...