offer帮选，要入客户端吗

自我介绍 实习1. 实习还在进行中？还是已离职？2. 有涉及多线程吗？八股1. C++ 的主要构造函数有哪些？2. 主要用的 C++ 版本？11？3. 智能指针 share_ptr 的原理4. 情景题，问某情境下 share_ptr 的引用计数分别是多少？5. C++ 引用是什么？6. TCP 四次挥手的过程？7. 死锁的条件？手撕1. 手撕 String 拷贝构造函数2. 实现一个死锁的场景3. LRU 缓存闲聊1. 部门主要语言是 Go 可以接受吗？2. 你做的博客主页怎么样？3. 反问总结又感觉脑子像浆糊一样了...死锁也撕得非常别扭，多线程确实用得非常非常少，实际的项目基本都是听 AI 的...自己手撕根本是不会...力扣上也刷过没有这类题目...很多线程 API 手撕都不会用...项目代码写一次就过了，没招了。

1. 自我介绍2. 如果让你设计一个面向跨境售后纠纷的智能工单中台，整体架构怎么落可以把系统拆成接入层、规则与路由层、会话编排层、模型服务层、工单状态层、证据存储层和审计回放层。接入层处理 IM、邮件、表单和外部 API；规则层做租户隔离、语言识别、风险分级和触发策略；会话编排层维护案件上下文、节点执行历史和工具调用轨迹；模型服务层只负责生成和抽取，不直接持久化状态；状态层维护工单生命周期和人工接管点；证据层保存截图、订单记录、退款日志和模型引用片段；审计层负责回放每一步输入输出，便于定位误判和争议。真正难的点不在“能不能生成回复”，而在于把模型能力约束在可追踪、可回滚、可仲裁的业务流程里。3...

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

1. Agent 和传统 workflow 的本质区别是什么，什么时候该选 Agent，什么时候不该选传统 workflow 的核心是路径预定义，系统知道每一步做什么、怎么流转、失败后怎么回退，所以它更适合规则清晰、链路稳定、审计要求高的场景。Agent 的核心则是把部分决策权交给模型，让它在运行时决定下一步查什么、调什么工具、如何分解任务，因此更适合任务开放、输入噪声大、解法不唯一的场景。真正的分界线不在“有没有模型”，而在“是否允许运行时规划”。如果目标是工单分类、审批流转、固定字段抽取，workflow 往往更稳；如果目标是复杂排障、代码仓库理解、跨工具探索式分析，Agent 才更有价值...