百度 Agent 秋招算法岗一面二面面经（多智能体与三级记忆）

《面试题目》

一面

1. 简单做一下自我介绍。
2. 讲讲多 Agent 这套方案的整体业务背景，说说你对多 Agent 整体架构设计的理解。
3. 在多 Agent 系统内部，各个智能体分别承担什么样的职责分工？
4. 整个多 Agent 体系采用了分层架构，具体分层逻辑是如何设计落地的？
5. 如果某个子 Agent 运行异常，出现崩溃、超时或者任务执行失败的情况，系统会设计什么样的容错兜底机制？
6. 当前这套多 Agent 系统整体任务完成成功率表现如何？
7. 在项目流程当中，是否会由 Agent 自主调用工具 skills？
8. 是否可以交由大模型本身来动态编写 skills？
9. 系统的长期记忆模块选用什么存储方案，记忆片段的匹配检索逻辑如何实现？
10. 聊聊你项目采用的整套评估手段。
11. 介绍下你校园相关项目，讲清楚项目整体实现思路。
12. 动态路由模块拆解之后，包含哪些子模块？
13. 项目里面因果驱动的机制是怎么实现的？
14. 实验所使用数据集，是直接使用公开现成数据集吗？
15. 最终验证效果，主要依靠下游任务指标做对比吗？
16. 算法题：区间差集。

二面

1. 请做一个简单自我介绍。
2. 挑选一个你最熟悉的项目，完整展开介绍。
3. 结合真实业务场景，讲讲这套方案的实际落地使用案例。
4. 项目架构设计了三级记忆体系，为什么不能直接用单级架构完成，引入三级结构的必要性是什么？
5. 短期记忆直接复用对话上下文即可，那中长期记忆部分是如何做处理维护？
6. 记忆数据需要落库保存，记忆相关标注工作是否交由大模型自主完成？如何校验落库记忆数据的正确性？
7. 项目里面记忆数据整体规模大概是什么量级？
8. 如果要对记忆模块做效果评估，会设计哪些评估指标？
9. 是不是依据这份知识被调用之后是否成功解决问题，反过来给文档打上可信度标签？
10. 项目提到双引擎存储 + 混合检索策略，请问具体是哪两套存储引擎？
11. 两套存储引擎分别服务中期记忆、长期记忆，还是分配别的用途？
12. 生成向量嵌入的时候选用什么向量模型？
13. 混合检索由向量检索 + 字面检索共同构成，字面检索的实现原理是什么？
14. 算法题：生成有效括号；面试官继续追问多种不同实现思路，探讨两种、三种解法的优劣。
15. 确认实习情况：如果正式入职，是否接受 base 定在实习所在城市？

《参考解析》

多 Agent 的分层架构与子 Agent 容错：多智能体真正的收益只有两条——上下文隔离（每个子 Agent 只装自己那段信息，避免超长上下文稀释注意力）与并行（独立子任务同时推进）。落到分层上，一般是「编排层 / 执行层 / 支撑层」：编排层负责意图识别、任务拆解、依赖排序与结果汇总；执行层是各领域子 Agent 与工具调用；支撑层是记忆、检索、沙箱、日志与评测。子 Agent 的职责划分要按能力边界而不是按对话轮次来切（检索型、计算型、写作型、校验型），每个子 Agent 的输入输出都用 schema 固定，避免自然语言长文传状态。容错这块面试官要的是分层答案：① 调用级——超时预算（每步设 deadline，避免长尾拖垮全局）、指数退避重试（只对幂等操作）、限流与断路器；② 任务级——子任务失败不直接崩掉全局，编排层按依赖判断是「换一条路径重试」「降级到简版能力」还是「跳过并标注该子任务未完成」；③ 状态级——每步产出落检查点（中间产物写工作区/库），进程崩了能从最后一个检查点续跑，写操作带幂等键避免重复副作用；④ 兜底层——所有尝试都失败时给用户一个诚实的、带缺失说明的结果，并落结构化日志供复盘。还有一个常被追问的点：成功率要能被度量，所以要按任务类型分解统计（而不是只报一个总成功率），把失败归因到「规划错、检索空、工具报错、模型胡编」四类，才谈得上优化。

三级记忆体系为什么必要：单级记忆只有两种极端——要么全塞上下文（贵、会被截断、注意力被稀释），要么全落库靠检索（丢会话的连贯性，指代和省略都接不上）。三级是把「时间尺度」和「存取方式」对齐：短期记忆就是当前会话的原始上下文，延迟最低、随对话滑动窗口或摘要压缩；中期记忆是会话级的结构化沉淀——任务状态、已确认的事实、约束与偏好，通常随会话结束做一次抽取与去重后写库；长期记忆是跨会话稳定的知识（用户画像、历史结论、领域事实），必须持久化并支持语义检索。三级的分工决定了各自的读写策略：短期只读不检索、靠裁剪控制 token；中期「会话内高频读、会话末批量写」；长期「写入要谨慎（错的事实会污染所有后续会话）、读取靠召回 + 重排」。面试官追问「为什么不能单级」时，落到这三个量化理由最有力：上下文窗口与成本的硬上限、跨会话持久性要求（进程重启后要还在）、以及检索粒度要求（长期记忆需要按语义片段召回，而上下文只能按时间顺序整体携带）。

双引擎存储与混合检索：字面检索的原理：双引擎的典型组合是「向量库 + 倒排索引库」——向量库存 embedding，负责语义相似（同义改写、跨语言、模糊表述）；倒排库存原始词项，负责精确匹配（型号、错误码、人名、API 名这类「查不到就是查不到」的 token）。字面检索的主流实现是 BM25：把文档切成词项建倒排表，打分由三部分构成——词频 TF 经饱和函数处理（出现 10 次并不比出现 3 次重要 3 倍，避免长文堆词占优）、逆文档频率 IDF（越罕见的词权重越高，让「Kubernetes」这种词压过「的/是」）、以及文档长度归一化（长文档天然更容易命中，需要按平均长度做惩罚），再乘上查询词项的权重求和。它的边界很清晰：同义词、拼写变体、语义改写一律召回不到；而向量检索恰好相反，语义泛化好但对稀有专有名词容易「漂移」到语义相近但事实错误的段落。所以工程上是混合召回 + 融合：两路各取 top-k，用 RRF（按排名倒数加权，不依赖两路分数量纲）或加权归一化分数融合，再交给交叉编码器 rerank 精排。回答时再加一句中文场景的坑：BM25 依赖分词，中文要先分词（或改用 n-gram/字符级倒排），领域词还需要自定义词典，否则专业术语会被切碎导致召回骤降。

手撕「生成有效括号」的多种解法对比：① 回溯 + 剪枝（最常写）：递归维护当前串、已用左括号数 open、右括号数 close，剪枝条件是 open < n 才能加左括号、close < open 才能加右括号，到 open == close == n 收集答案。它的搜索树被剪得只剩合法前缀，复杂度等于答案规模 × 串长（第 n 个卡特兰数 C(2n,n)/(n+1)），是面试里最不容易写错的版本。② 按长度 DP / 括号拼接：dp[i] 存 i 对括号的所有合法串，dp[i] 由 "(" + dp[j] + ")" + dp[i-1-j] 枚举 j 构造，逻辑上覆盖了所有「最外层括号匹配位置」的组合；好处是天然去重、便于按字典序回答，坏处是字符串拼接多、内存高。③ BFS / 队列逐层扩展：用队列按层生成，每层只保留 open>=close 的合法前缀，适合需要「按长度递增输出」或加 early-stop 的场景，代价是空间占用比回溯大。④ 值得一提的闭包/迭代法：从 {""} 出发反复做 "(" + s + ")" 与拼接，思路直观但去重成本高。优劣对比的落点是：时间空间上回溯最优、DP 最好解释「为什么不会漏」、BFS 最适合流式或限长输出；面试官继续追问时通常想看你能不能说出剪枝条件为什么充分（任何合法前缀都满足 close <= open <= n），以及 n 较大时应不应该真的把结果全枚举出来（很多时候该返回计数而不是列表，计数用卡特兰数公式或 DP 直接算）。