北京某小厂的AI实习岗，看看难度如何

你以为 AI 实习岗就是接接大模型 API、写写 Prompt？ 训练营有个朋友去面，北京这场直接上强度：RAG 怎么做、Agent 怎么编排、SSE 断线重连怎么补流、知识库怎么迭代更新还不全量重算。场景题一环扣一环，没真做过真的很难扛住。

我下面站在我的角度，把他的面经按题目顺序复盘一遍：每题我都给一份可直接复述的示例答案。

1）自我介绍

这题不是让你背简历，是让你把自己定位成能干活的人。

示例答案（面试者口吻） 我主要做后端和 AI 应用工程化落地，最近在做一个面试类的 AI Agent 服务：用户上传简历，系统解析简历后，通过 RAG 从题库/知识库里检索相关内容，再用多 Agent 编排生成连续追问，并通过 SSE 流式输出把整个面试过程实时推到前端。 我在项目里重点负责三块：RAG 知识库链路、Agent 编排和状态机、以及流式输出的稳定性设计，比如取消、超时、断线重连思路和可观测性。

你看，短，但信息密度高，后面所有题都能接上。

2）RAG 知识库实现策略

面试官问这题，一般不是要你背定义，而是让你讲清楚你是怎么做链路的。

示例答案 RAG 我会按完整链路来讲：数据接入、清洗、切片、向量化、索引存储、检索召回、过滤重排、上下文组装、生成与评估。 我们实现上核心策略是：

• 数据源：题库和知识文档统一成结构化文档，保留来源、语言、分类等元数据
• 切片：可配置 chunk size 和 overlap，避免切得太碎或语义断裂
• 向量化：统一 embedding 服务，支持批量、超时、重试
• 向量库：用 Milvus 存向量与元数据，检索时用元数据做过滤，比如按技术栈、难度、类别筛选
• 召回之后：按 TopK 取回内容，拼到上下文，再让模型生成更贴合简历的追问

加分点你可以顺嘴带一句：RAG 的质量瓶颈通常不在模型，而在切片和检索策略，切片差会导致召回差，召回差生成就必然飘。

3）Eino 的优势是什么？对比 LangGraph

这题容易翻车，因为很多人只会说哪个好用，却说不出为什么。

示例答案 我理解 LangGraph 更常见在 Python 生态里做图编排，优势是生态和样例丰富。我们选 Eino 的原因主要是工程侧：

• 我们后端是 Go，高并发和流式输出是强需求，Eino 在 Go 侧的 Agent、Graph 编排、流式能力都比较顺手
• 我们同时用到了两种编排形态：简单链路用 Agent Runner 流式输出；复杂链路用 Graph 把面试状态机显式化，方便做分支、循环和收口
• 可观测性更好做：能在一次 Agent run 的开始、结束、错误处统一埋点，后面排查延迟和失败原因更快

你会发现，这个回答的关键不是踩谁捧谁，而是把选型和业务需求绑定。

4）为什么用 Hertz？

面试官并不在乎你是不是 Hertz 粉，他关心你是不是理解你系统的性能形态。

示例答案 我们有两个特征：并发量高、而且有 SSE 长连接。Hertz 的定位就是高性能网络服务框架，适合这种连接数多、请求频繁的场景。

另外我们在 Go 生态里做 AI Agent 工程化，框架和周边的中间件体系成熟，上手快、工程落地成本低。

5）多 Agent 的编排问题：项目的 Agent 怎么设计的

这题通常是全场重点，面试官想看你是不是只会单模型问答。

示例答案 我们是主控 Agent + 专家 Agent 的结构：

• 主控 Agent 负责节奏控制：开场、追问推进、何时切换到技术面或项目面、以及收尾
• 技术专家 Agent 专门做技术深挖：比如 Go、MySQL、Redis、分布式系统这些，走多轮追问
• 项目专家 Agent 专门核验项目真实性：按 STAR 追问，逼出细节和取舍
• 主控 Agent 不直接把所有问题都自己生成，它会在合适的时机调用专家 Agent，把专家输出原样作为面试内容发给前端

这里你要讲清楚一句话：主控负责调度，专家负责深挖，职责分离才可控。

6）为什么需要分布式锁保证群面效果？父子 Agent 集群按理不需要？

这题是并发一致性题，面试官在考你有没有踩过坑。

示例答案 分布式锁的目标不是保证 Agent 协作，而是保证同一个会话的唯一执行权。 即使是父子 Agent 架构，多实例部署后仍会遇到：

• 用户刷新/重试导致同一个会话重复发起，多个实例同时开始跑面试循环
• 同一个会话被多端同时连接或重复订阅，出现重复推流、状态错乱
• 断线重连如果没有唯一写入者，可能出现补发和实时推送交织，导致顺序错乱

所以我会按部署形态区分：

• 单实例：进程内互斥和状态机就够
• 多实例：需要按 session_id 做分布式互斥，保证同一时刻只有一个执行者在写流、写状态

7）Agent 的状态设计、判断

你只说我有状态机不行，面试官会追：状态长啥样，怎么流转，怎么判断分支。

示例答案 我会把状态分成三类：

• 会话基础状态：session_id、用户信息、面试类型、难度、当前题号、最后活跃时间
• 面试过程状态：最近问答历史、当前话题、累计得分、当前评估结果、下一步动作提示
• 控制状态：是否需要停止、是否超时、是否取消、错误原因

分支判断一般在评估节点做：

• 如果回答质量高，进入加深追问
• 如果一般，继续当前话题
• 如果偏弱，降低难度或切换话题 再加一个硬条件：达到最大题数或用户退出就收口。

你说清楚这套逻辑，面试官基本就知道你不是背的。

8）SSE 流式输出中用户断开连接，如何重连后还能看到之前内容？

这题很实战，而且很容易被问到你到底做没做。

示例答案 我会把 SSE 拆成两层：实时推送和可恢复推送。

• 实时推送：服务端持续发事件，前端不断渲染
• 断线恢复：核心是补发机制。每条事件要有递增的 event_id 或 message_id，然后把事件写入一个可回放的存储

重连时客户端带上最后收到的 event_id，服务端先把缺失区间补发，再继续实时推送。 存储实现可以根据成本选：

• 轻量方案：Redis Stream 或 List 按 session 存一段时间
• 稳妥方案：落 MySQL（方便审计、回放、复盘）

关键点：只靠内存不行，多实例会丢；只靠实时推送不行，断线体验会断崖式下降。

9）如何设计可修改的 RAG 知识库？如何降低开销？分片策略怎么做？

这题就是在问你有没有考虑长期运营：内容会更新、会迭代。

示例答案 我会把更新分成两种：

• 文档整体大改：直接按版本导入，检索只取最新版本；旧版本异步清理
• 文档局部小改：做增量更新，只重算变更片段的向量，不全量重切

降低开销的关键是两点： 1）chunk 的 ID 要尽量稳定，别每次导入都变一套 2）元数据要能定位到文档、章节、片段，方便精准更新

10）分片更新怎么避免牵一发而动全身？如何定位到某片段做局部更新？

这题是第 9 题的加速版，很多人会卡住。

示例答案 核心思路是：不要用字符偏移去定位片段，要用结构锚点和内容指纹。

• 先把文档按标题/段落等结构切成块，块边界尽量语义稳定
• 对每个块计算 hash，hash 不变就认为块未变，不需要重算 embedding
• 更新时对比新旧块的 hash 列表，定位到变化的那几块，只对变化块做删除和新增

这样即使前面删了一个字，也不会导致后面所有块都被当成全新内容。

他的复盘（也是你最该准备的点）

他回来总结得很实在，我也赞同：

• Eino 对比 LangGraph 要提前准备：不需要背百科，但要能讲清为什么选、怎么落地、哪里是边界
• 场景题很多：SSE 断线恢复、RAG 增量更新、多实例一致性，这些不做设计就很难临场圆
• Agent 状态设计容易暴露短板：你必须能说清状态有哪些字段、在哪些节点更新、怎么决定分支
• 项目整体架构要复习：接口链路、数据流、依赖组件、异常与兜底，面试官会从一个点一路追