腾讯 TEG 后端一面：RAG 多智能体与分布式 LRU
面经与参考答法
腾讯 TEG 后端一面：RAG 多智能体与分布式 LRU
原帖只披露面试月日为 8 月 12 日，未给出面试年份；原帖发布于 2026 年 8 月。本文按主题选录技术问题，省略设备操作、自我介绍、面试评价和反问；答案是教学整理，不代表候选人现场回答。RAG 多智能体题是设计题，原帖明确该系统未有实战经历，不能把教学方案当成已实现项目。
这场一面发生在 8 月 12 日，既检查 Go、缓存和零拷贝等后端基础，也要求现场设计基于 RAG 的多智能体系统，并手写分布式 LRU。回答重点不是堆术语，而是把状态、指标和一致性边界讲清楚。
（1）为什么选择 Go，Go 语言的优势是什么？
（1）为什么选择 Go，Go 语言的优势是什么？
关联知识点待核实。
Go 的协程、调度器和网络库适合承载大量 I/O 型任务，静态编译与较小运行时依赖也便于交付。面试中不能只回答“并发高”。以 Agent 后端作为教学应用时，请求通常包含模型流式响应、工具等待和任务状态推进，goroutine 能让每个等待链路保持简单；同时也要承认 GC 停顿、泛型生态和复杂数值计算并非它的绝对优势。选型最终应落到吞吐、P99 延迟、可观测性与团队维护成本。
（2）GMP 调度模型怎样影响服务设计？
（2）GMP 调度模型怎样影响服务设计？
关联知识点待核实。
G 是 goroutine，M 是操作系统线程，P 持有运行 Go 代码所需的调度资源。P 从本地队列取 G，空闲时可以从其他 P 窃取任务；网络轮询器和阻塞系统调用帮助避免一个等待拖住全部执行。工程上仍需控制并发：模型和工具调用前设置有界队列、超时与取消，把 CPU 密集工作隔离，避免无上限创建 goroutine 导致内存和下游连接耗尽。
（3）缓存雪崩是什么，怎样分层治理？
（3）缓存雪崩是什么，怎样分层治理？
关联知识点待核实。
雪崩是大量 key 同时失效或缓存服务整体不可用，使请求瞬间压向数据库或模型服务。可给 TTL 加随机抖动、对热点 key 预热并逻辑过期，用 singleflight 合并同一 key 的回源；下游还要有限流、熔断、降级和容量保护。对于 Agent 系统，Prompt、检索结果和模型回答的缓存必须把模型版本、权限范围与知识库版本纳入 key，否则命中率看似提高，却可能返回越权或过期内容。延伸阅读：Agent 缓存设计与Redis 缓存策略。
（4）零拷贝解决什么问题？
（4）零拷贝解决什么问题？
关联知识点待核实。
传统文件发送可能在内核缓冲区和用户缓冲区之间多次复制，并伴随用户态、内核态切换。sendfile、mmap 等机制能减少复制或切换，适合传输大文件、模型制品和静态资源。但“零拷贝”不是完全没有复制，也不适合需要在用户态逐字节改写的数据。回答时应先画清数据路径，再比较吞吐、CPU 占用、内存映射风险和平台约束。
（5）深拷贝和浅拷贝为什么会影响任务状态？
（5）深拷贝和浅拷贝为什么会影响任务状态？
关联知识点待核实。
浅拷贝复制外层结构，内部引用仍指向同一对象；深拷贝递归复制可变成员。多 Agent 共享计划或工具结果时，误用浅拷贝会让一个分支悄悄修改另一个分支的状态；无脑深拷贝又会放大大对象和历史消息的内存开销。更稳妥的做法是使用不可变状态、结构共享和显式版本，工具副作用只通过事件或受控 reducer 更新。
（6）怎样设计一个基于 RAG 的多智能体系统？
（6）怎样设计一个基于 RAG 的多智能体系统？
关联知识点待核实。
先明确目标和成功指标，再划分检索、规划、执行、核验等角色。请求进入后做权限过滤和查询改写，混合检索召回候选，重排后把带出处的证据交给执行 Agent；核验角色检查引用、约束和工具结果，失败时只允许有限次数的补检或重规划。共享状态应记录 run、step、证据版本和幂等键，Agent 之间传结构化消息，不直接修改彼此私有状态。相关设计见RAG 流程和多智能体协作。
（7）每个阶段应该观察哪些指标？
（7）每个阶段应该观察哪些指标？
关联知识点待核实。
检索层看召回率、nDCG、引用覆盖率和无结果率；生成层看任务成功率、事实一致性与格式通过率；工具层看调用成功率、重试率和幂等冲突；系统层看端到端 P50/P95/P99、Token 成本、队列等待和人工接管率。离线题集用于稳定对比，线上金丝雀和真实失败样本用于发现分布漂移。只报总准确率会掩盖“检索正确但执行失败”的根因，详见Agent 评测体系。
（8）如何设计分布式 LRU，哪些条件要先澄清？
（8）如何设计分布式 LRU，哪些条件要先澄清？
关联知识点待核实。
原帖仅列“手写分布式 LRU”，未给容量、全局或分片淘汰顺序、一致性、输入输出及测试要求；以下是教学设计讨论，不是现场实现还原。单机 LRU 常用哈希表加双向链表，实现近似 $O(1)$ 的查询、更新和淘汰；并发下需保护两种结构的一致性。若合同允许分片内 LRU，可按一致性哈希或固定分片把 key 路由到节点，每个分片维护自己的容量与 LRU，版本号或幂等令牌避免重试覆盖新值。节点故障时通过副本或重建恢复，迁移期间采用双读或版本校验。若只需要近似热点淘汰，可用采样 LRU 降低全局顺序维护成本。