小米 Agent 岗：知识库更新与 MCP 通信两道工程题
Agent 岗（大模型应用方向）
岗位：小米 Agent 岗（大模型应用方向） 轮次：二面、三面的单题深挖记录，融合整理 一句话定性：这是一场「生产经验」面试，两道题都是 Demo 阶段碰不到、上线后躲不掉的问题。 素材时间线：2026 年多场小米 Agent 岗面试的单题记录，整理时间 2026-09-28
0. 一分钟速览
| 项目 | 内容 |
|---|---|
| 公司 / 岗位 | 小米 · Agent 岗 |
| 考察重心 | RAG 知识库的增量更新方案、MCP 的传输方式与消息格式 |
| 追问风格 | 顺着你的方案找漏洞：chunk 边界变了怎么办、系统怎么感知变更 |
| 典型挂点 | 以为局部更新一个 chunk 就行；以为 MCP 用 WebSocket |
| 准备方向 | 每道工程题准备「方案、变更感知、异常路径」三段 |
1. 二面真题：知识库上线后文档更新怎么办
问法：「你们 RAG 知识库上线之后，文档更新了怎么办？总不能每次改个文档就整个知识库重建一遍吧？」
错误示范：答「找到变了的那个 chunk，更新它的向量就行」。面试官指出：文档内容一变，切割结果可能完全不同，chunk 边界都对不上，没法一一对应做局部更新。
答题要点：
为什么不能像数据库那样直接 UPDATE：一篇文档被切成几十上百个 chunk 分别向量化入库，文档和向量是一对多关系；内容变了，chunk 的数量、边界、内容全可能变。
可靠方案是「先删后增」：删除该文档对应的所有旧 chunk，重新切割、Embedding、入库。局部更新只在 Chunking 策略完全稳定（比如固定 token 窗口）时理论上可行，生产环境里 chunk 边界一变就乱，不赌这个不确定性。
变更感知（追问必到）：给每个文档算内容 hash，通过轮询或监听数据源变更，检测新增、修改、删除三种事件；实时性要求高的场景用消息队列（如 Kafka）做事件驱动，做到秒级入库。
追问链：「更新期间用户查到新旧混杂的数据怎么办？」答：向量库写入用版本化索引，切换原子生效；或双写新旧索引、灰度切流。这里能主动说出一致性方案，是区分「做过」和「背过」的地方。
2. 三面真题：MCP 用什么通信方式
问法：「MCP 协议通常采用什么通信方式？」
错误示范：答「WebSocket 吧，双向通信正好」。面试官反问：MCP 有本地工具和远程工具两种场景，本地需要走网络吗？
答题要点：
本地场景用 stdio：Client 把 Server 作为子进程启动，通过标准输入输出通信。延迟极低、不开端口、没有网络安全问题。Claude Desktop 接本地工具走的就是这条通道。
远程场景用 Streamable HTTP：Server 作为独立 HTTP 服务部署，多个 Client 共享同一个 Server，适合团队统一管理。注意不是 WebSocket。早期规范的 HTTP+SSE 双端点方案在 2025 年 3 月的规范更新里标记为 deprecated，新项目用 Streamable HTTP。
消息格式统一 JSON-RPC 2.0：传输方式只影响「怎么传」，消息协议不变，两层解耦是 MCP 灵活性的关键，也是这题的隐藏得分点。
追问链：「为什么本地不用 HTTP？」答：本地子进程用 stdio 免掉网络栈开销和端口管理，简单且快；远程才需要 HTTP 的可部署、可共享、可鉴权。
3. 复盘与准备清单
- 小米这两道题的共性：都有一个「看起来对的直觉答案」（更新单个 chunk、用 WebSocket），而正确答案都在否定这个直觉。生产经验和 Demo 经验的差距就体现在这里。
- RAG 更新题按「先删后增、hash 感知、事件驱动、版本化切换」四件套准备，能应对全部追问。
- MCP 通信题按「本地 stdio、远程 Streamable HTTP、消息格式 JSON-RPC 2.0」三句准备，加上两层解耦的设计原因。
相关题目：站内题库的「RAG 知识库怎么增量更新」「MCP 的传输方式」「向量库和数据库的一致性怎么保证」都对应这场面试的原题。