老实了 死磕第一道 想了会分类没想明白 想回溯去了 回溯也没想明白

1. 自我介绍2. RocketMQ 里顺序消息、普通消息、事务消息分别适合什么场景，为什么不能混着用普通消息适合最终一致、无严格顺序约束的场景，比如日志分发、画像更新、通知投递。顺序消息适合同一业务键必须按时间线推进状态的链路，比如同一工单、同一订单、同一会话的状态演进，但顺序消息的吞吐和容错设计会受到队列粒度限制。事务消息适合本地事务与异步投递之间要建立“发送承诺”的场景，比如主库先落事实，再由 MQ 推动旁路索引或下游补偿。三者不能混着用，是因为它们解决的问题不同，消费模型、失败恢复方式和成本模型也完全不同。3. 如果 RocketMQ 出现消息积压，你会怎样定位，不要只说“扩容消费者”...

上周公众号收到了第二轮技术面通过的通知，面试官表示应该只有二轮技术面，并且已经在积极给我推进了。想请问下大家这种情况还会横向嘛？感觉已经接近暑期实习offer阶段的中后期了，大家蚂蚁技术面后多久收到的HR面呀？

1. 自我介绍2. 介绍一下你的项目3. Coze 新旧两种编排方式的差异是什么，你在设计节点时怎么取舍拖拽式编排适合流程稳定、路径清晰、节点边界明确的场景，比如固定审批、FAQ 问答、标准化信息抽取。Agent 化编排更适合目标不稳定、路径动态变化、需要中间决策的场景，比如多轮任务执行、复杂信息搜集、跨工具协作。节点设计时不能按功能菜单式地乱拆，而要按状态边界和失败恢复边界去拆。一个节点如果既负责理解问题、又负责查知识、又负责生成结果，那一旦出错很难定位，也很难重试。真正稳的节点应该输入清晰、输出结构化、失败可恢复。4. 你写过哪些 MCP 工具，设计一个 MCP 工具协议时最关键的是什么M...