【携程】【Agent 开发】【暑期实习HR面】面经（八股+大模型项目+手撕）

海外一年制硕士，投递携程 Agent 开发暑期实习，HR 面（实为技术+HR 混合面，约 50 分钟）经历整理如下。

题目摘要

1. Go 语言基础：slice 与 array 的区别，slice 扩容机制，map 是否并发安全，如何实现一个并发安全的 map。
2. MySQL/Redis 八股：MySQL 索引为什么用 B+ 树而不是 B 树；事务隔离级别与 MVCC 实现；Redis 缓存穿透、击穿、雪崩的区别与各自解决方案；Redis 分布式锁的续期问题。
3. Agent 项目深挖：RAG 检索链路中 chunk 切分策略、召回率与准确率的权衡；Function Calling 的 schema 设计；多轮对话中上下文窗口管理；推理成本优化手段。
4. 手撕算法：给定一个字符串数组，将字母异位词组合在一起（LeetCode 49 变体）。关键思路：对每个字符串排序后作为哈希 key，或统计字符频次用数组编码成 key，时间复杂度 O(n·k log k) 或 O(n·k)。
5. 行为面：为什么选携程、对 Agent 在旅游场景落地的理解、实习时长与转正意愿。

项目深挖

追问一：你的 RAG 项目里 chunk 怎么切的？为什么这么切？

参考回答方向：不要只说“按 512 token 切”。要讲清楚切分策略与业务语料的耦合。比如旅游场景的 FAQ 文档结构规整，可以按标题层级切，保留父子关系；长文档用递归切分，设置 overlap 防止语义截断。进一步说明评估方式：构造一批 query-answer 对，对比不同 chunk size 下的召回率和答案准确率，用数据支撑选择。面试官很可能追问“如果 chunk 切得太碎导致上下文丢失怎么办”，可以答：采用 small-to-big 检索，用小块做召回、用父块做生成，兼顾召回精度和上下文完整性。

追问二：Function Calling 你怎么设计的？模型选错工具怎么办？

参考回答方向：先讲 schema 设计原则——工具名语义明确、参数描述写清楚类型和枚举值、避免功能重叠的工具。然后讲容错：在 prompt 里给出工具选择的正反例；对模型返回的工具调用做参数校验，非法参数直接返回错误信息让模型重试；设置最大重试次数防止死循环。如果面试官追问“多个工具可以并行调用吗”，可以答：取决于业务是否有依赖关系，无依赖的查询类工具可以并行，有副作用的写操作要串行并加幂等。

追问三：多轮对话上下文越来越长，你怎么管理？推理成本怎么压？

参考回答方向：分两层。上下文管理上，短期用滑动窗口保留最近 N 轮，长期用摘要压缩历史对话，关键实体（如订单号、目的地）抽出来结构化存储，不依赖模型记忆。成本优化上，能用小模型做的意图分类、槽位抽取就不要用大模型；对重复 query 做语义缓存；prompt 里去掉冗余的 few-shot 示例，改用更精简的指令；流式输出降低首 token 延迟感知。如果面试官追问“摘要压缩会不会丢信息”，可以答：摘要只压缩闲聊和确认类轮次，涉及业务关键信息的轮次原样保留，并且摘要本身也做版本管理，出问题可回溯。

准备建议

1. 八股要能落到项目里。不要背“B+ 树三层能存两千万数据”这种孤立结论，准备一个自己项目里的慢查询或缓存问题，讲清楚怎么定位、怎么改、改完效果如何。面试官对“你实际用过”的兴趣远大于“你知道”。

1. Agent 项目准备三个层次的追问。第一层讲清楚架构和链路；第二层讲清楚每个技术选型的 trade-off，比如为什么用向量检索不用关键词检索、为什么用这个 embedding 模型；第三层讲清楚失败案例和迭代过程，比如召回不准时你做了什么调整、效果提升了多少。没有第三层，项目深挖很容易被问穿。

1. 算法保持手感，重点练哈希和双指针。暑期实习手撕难度通常在 LeetCode 中等，异位词分组、三数之和、最长无重复子串这类高频题要能 15 分钟内写完并跑通边界。写之前先跟面试官确认输入输出和边界条件，写完主动跑一遍示例，这些细节比题目本身更加分。

结果反馈

一面通过，3 天后约了二面（交叉面），整体节奏比预期快。

想系统备战大厂大模型/Agent 开发？NiceOffer 提供 SDE+LLM 双轨 1v1 陪跑，合同保底 40w 年薪，文末扫码咨询。