百度 Agent 秋招算法岗一面二面面经（附 Top-K 采样手撕）

《面试题目》

一面

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. 算法题：区间差集问题。
17. 编码实现带温度系数的 Top-K 采样，入参包含 logits、Top-K 数值、温度 temperature 参数。
18. 面试官反问：你主观上会不会和咱们这块业务存在适配问题，是否会对该业务方向缺乏兴趣？

二面

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

《参考解析》

带温度系数的 Top-K 采样怎么实现：顺序是「除以温度 → 取 top-k → softmax → 按概率采样」。第一步数值稳定处理：先减去 max(logits) 再除以 temperature，否则 logits 稍大就会 exp 溢出；温度为 0 或极小值时应退化成贪心（直接取 argmax），避免除零和 one-hot 数值问题。第二步取 top-k：对缩放后的 logits 做一次部分排序（std::partial_sort 或维护大小为 k 的小顶堆），拿到第 k 大的阈值 theta，把小于 theta 的位置置为 -inf；k 的边界要处理（k <= 0 视为不裁剪、k >= vocab_size 视为全保留）。第三步 softmax 只在保留的 k 个位置上做（分母只累加这 k 项，这样才真正改变分布形状），最后用累积分布 + 均匀随机数采样。常被追问的细节有三点：① k 裁剪与温度缩放的顺序——必须先缩放再裁剪，否则温度会改变候选集合（温度高时分布更平，同一个 k 保留的集合会变）；② 「top-k 采样」与「top-p / 典型采样」的区别——前者按固定个数截断，后者按累积概率截断，候选数随分布自适应；③ 工程实现上不要真的 sort 整个词表（vocab 十几万，每次都排序很浪费），partial sort 或堆足够；另外采样要能接随机种子以便复现实验。用 PyTorch 写核心就是 logits = logits / temperature; v, i = torch.topk(logits, k); p = torch.softmax(v, -1); j = torch.multinomial(p, 1); return i[j]。

记忆模块的评估指标与记忆覆盖率怎么测：记忆系统的评估要拆成「写得对不对」和「读得准不准」两层。写入侧看：抽取准确率/召回率（对照人工标注的应记事实清单，看漏抽了什么、编造了什么）、去重与冲突率（同一事实是否被写成多条、新事实有没有覆盖旧事实、矛盾条目的比例）、时效性（过期的偏好是否被标记失效）。读取侧看：检索命中率 Recall@k / MRR（构造「这个问题必须用到某条记忆」的评测集，看那条记忆是否出现在 top-k）、答案有据性（模型回答里的关键断言能否被召回的记忆支撑，即忠实度）、以及不该召回时的正确拒答率（用户没提过的事不要假装记得）。记忆覆盖率是写入侧指标，可操作的定义是：从会话里由人工或强模型标注出「值得长期记住的事实集合 G」，再看系统实际落库的集合 M 与 G 的交集，|M ∩ G| / |G| 就是覆盖率；分母用标注集合而不是全部 token，才能避免「记得越多分越高」的假象，同时要配一个精确率一起看，否则堆量就能刷分。再加一层端到端指标：跨会话任务成功率、需要用户重复交代信息的比例、以及长期使用后个人化回答的采纳率。最后补一句评测纪律：评测集要固定并版本化，改了抽取 prompt 或 embedding 模型必须回归，不然指标变化分不清是改好了还是评测集漂了。

中长期记忆的落库、标注与校验：会话结束后做一次「抽取—归并—落库」的批处理：抽取出候选记忆（按实体/偏好/事实/任务状态分类，每条带来源消息 id 与时间戳），与库中已有条目做相似度比对，走「新增 / 更新（保留历史版本）/ 标记失效」三条路，写入时带 source、confidence、valid_from、version 字段。标注要不要交给大模型自主完成？实践中是分层策略：低风险、易验证的信息（用户自述的偏好、明确的结论）由模型抽取后直接落库，但必须带来源引用；高风险或推断类信息（对用户能力的判断、涉及金额与健康的结论）只作为「候选」入待确认区，或干脆不写。校验落库数据正确性有四道闸：① 溯源校验——每条记忆必须指回原始消息，抽取结果无法引用来源就丢弃；② 交叉一致性——与库中已有条目比对，矛盾时按时间与置信度择新不择旧、并保留冲突记录；③ 抽样人工/强模型复核——固定周期抽检并计算准确率，作为这条链路的回归指标；④ 线上反馈闭环——用户纠正（「不是这样」）要能反写回记忆并降低该类抽取的权重。此外要区分事实与推断：推断必须显式标记，回答时以「你之前提到过……」这类可被否认的方式呈现，避免把模型的猜测当成用户的真实情况。

混合检索里的字面检索与区间差集思路：字面检索的主流实现是 BM25 倒排索引，打分 = 查询词项的 IDF 加权 × 词频饱和项 × 文档长度归一化项，强在精确 token（型号、错误码、API 名、人名），弱在同义改写；向量检索恰好相反，语义泛化好但稀有专有名词容易漂移。所以工程上是两路召回后融合——用 RRF 按排名倒数加权（不依赖两路分数量纲），再上交叉编码器 rerank；中文还有分词的坑，术语要加自定义词典，否则专有名词会被切碎导致召回骤降。至于「区间差集」这类手撕题，写之前先跟面试官确认定义：常见两种——给定若干区间求它们的并集补集（即未被覆盖的部分），或给定两个区间集合求 A 中有而 B 中没有的部分。以「求补集」为例，解法是先把区间按左端点排序、合并重叠（注意边界相等是否算重叠要和面试官对齐，闭区间 [1,2] 与 [2,3] 不同处理会影响结果），再在合并后的相邻区间之间取空隙；如果是两个集合求差，则用双指针扫两个有序区间列表，按 max(l1,l2)、min(r1,r2) 逐段裁剪，复杂度都是 O(n log n)（排序主导）。要主动说清的边界：空输入、单点区间、完全包含、以及结果是否需要合并输出。