百度测试开发岗面经合集：Agent 评测与 Langfuse 实践

轮次: 多轮面试合集
时间: 2026-09
来源: 牛客网

测试开发 AI测试 Langfuse Agent评测 Checkpointer SQL 算法题

《面试题目》

自我介绍
拷打项目：如何构建测试集？怎么评测 Agent 输出的效果？并行节点遇到冲突怎么解决？
项目开发系统怎么构建 trace，如何定位问题？Agent 返回结果不理想怎么排查问题？
讲讲 checkpointer 机制，以及它的原理
项目中是如何用 state 构建的数据？
主流大模型有哪些区别
如何用 codex 进行自动化测试
skill 的原理，讲述一个应用场景
mcp 服务有什么作用
算法题：删除排序链表中的重复元素
SQL 题：找出至少连续出现三次的数字
如果让 Agent 完成一份竞品分析报告，如何拆解任务？
任务中的哪些环节需要人工把控？
大模型获取竞品销量等外部数据时，如何判断数据准确性？
在 Agent 工作流中，人的核心作用是什么？
使用大模型检索外部资料时，如何识别和规避版权风险？
手撕：合并两个有序数组
如何为合并有序数组函数设计测试用例？
如何快速判断一个数组是否有序？
对外提供函数或接口时，工程上需要遵循哪些步骤？
合并大规模有序数组时，如何处理性能、内存和线程安全问题？
两个有序数组达到百万级数据量时，如何优化？
大模型从零开发到落地会经历哪些阶段？预训练、中训练和后训练分别包含什么内容、解决什么问题？
是否了解 SWE 数据集？
如何理解 AI 测试开发岗位？
你刚才提到用 Langfuse Evaluator 做评估，能具体展开讲讲是怎么做的、做了什么吗？
能否结合一个实际场景，说明你具体怎样使用 Evaluator，以及评估了哪些内容？
你关注过 Evaluator 机器评估结果的可信度吗？是否会通过人工标注或复核来验证机器评估的准确率？
Langfuse 中既有预置的评估 Prompt，也可以自定义，你们一般使用预置的还是自己设计？自定义评估 Prompt 时有哪些注意点？
评估 Prompt 需要包含哪些内容？追问：具体应该怎样设计？
根据实际打分和人工检查结果，你们会继续优化预设的评估 Prompt 吗？面对规则遗漏、设置不准或评测标准更新时，具体迭代流程是什么？
你的两段实习都是 Java 开发或 AI 应用开发，为什么选择投 AI 测试开发，而不是 AI 应用开发岗位？
如果要保障企微侧边栏助手的 RAG 线上问答效果，除了 Langfuse Evaluator 自动评估外，还需要做哪些工作？
对意图识别、工具编排和工具调度成功率，你们是否做过评估或效果保障？目前准确率大约是多少？
你们是否做过端到端评估，例如从真实页面输入问题，综合评估回答内容、工具调用和最终产物的整体可用性？
Hakimi Code 是跟着开源项目做的，还是业务中实际使用的项目？
在你们日常的 Coding 工作中，大约有多少比例的代码是通过 AI Coding 或 Vibe Coding 生成的？对 AI 生成的代码，你们会逐行或比较仔细地 Review 吗？
涉及实现逻辑、代码复用等问题时会怎样处理？
你现在还有手写代码相关的工作吗？
如果要测试这段程序，你会设计哪些测试用例？如果输入内容全部是数字，会有什么问题？如果输入的数字非常长，Python 的 int 会出现溢出吗？
最近有学习什么新知识吗？你提到的 LLM Wiki 和普通的 Wiki 知识库有什么区别？

《参考解析》

1. checkpointer 机制与 state 设计。在 LangGraph 这类 Agent 框架里，图被编译成「超级步」执行：每一步执行完若干个节点后，框架会把当前的 state 快照连同执行位置、待执行的下一批节点、以及必要的元数据（线程 id、checkpoint id、父 checkpoint）持久化成一条记录，这就是 checkpointer。它的价值有三层：断点续跑（进程挂了或用户中途插话，从最近的 checkpoint 恢复而不是从头执行）、人工介入（在某个节点前中断，等人确认后继续，即 human-in-the-loop）、以及时间旅行调试（回到任意历史快照重放，定位是哪一步跑偏）。存储后端通常选 Postgres（事务性强、便于并发控制与查询）或 Redis（快、适合高频写但要注意持久化策略），线程/会话 id 决定恢复点，所以同一会话的 checkpoint 必须按 id 隔离。state 的设计原则是「可序列化、显式、最小」：只放真正需要在节点间传递的数据（消息列表、已收集证据、任务状态枚举、重试计数），不放数据库连接、模型客户端这类运行时对象；对并行分支要明确每个字段的归并语义——LangGraph 用 reducer 定义同一字段被多路并发写入时怎么合并（追加列表、取最大值、后者覆盖），如果一个字段被两个并行节点同时写而没有 reducer，框架会直接报冲突，这正是「并行节点遇到冲突怎么解决」的标准答法：要么给字段配一个语义正确的 reducer，要么把共享字段拆到各自分支的私有字段再在汇合节点显式合并，别用锁去硬扛。

2. 如何评测 Agent 的输出，以及 trace 怎么建。Agent 的输出不是一段文本，而是「最终答复 + 调用链 + 中间产物」，所以评测要分层：单步评测工具选择是否正确、参数是否正确、检索结果是否相关；轨迹评测整条链路是否走了合理的最短路径（步数、有无冗余调用、错误重试次数）；端到端评测最终产物是否可用（答案正确性、是否引用了真实证据、是否越权操作、延迟与成本）。测试集构建分三来源：线上真实流量分层抽样（覆盖高频意图）、人工设计的边缘场景（空输入、多轮指代、超长上下文、工具返回异常）、对抗样本（诱导编造、prompt 注入、越权提问）。trace 的构建靠框架自带的可观测层（Langfuse、LangSmith、OpenTelemetry 语义约定）：一次请求一个 trace，每个节点/模型调用/工具调用一个 span，span 上挂输入输出、耗时、token 数、模型名、检索命中 id 和状态码，用统一的 session/thread id 串起多轮。排查「Agent 返回结果不理想」的正确姿势是从 trace 自上而下看：先看检索命中的文档对不对（数据问题），再看工具是否被正确调用、参数是否合理（编排问题），再看模型拿到的上下文里有没有答案（上下文问题），最后才怪模型（生成问题）——这样每一步都能用 trace 里的证据排除，而不是靠猜。

3. Langfuse Evaluator 的用法与可信度校准。用法上分三块：数据集（dataset）承载黄金样例，每条含输入与期望输出/关键事实；评估器（evaluator）分两类，一类是无模型的确定性检查（正则、JSON schema 校验、关键词命中、工具调用断言，便宜且稳定，应该优先覆盖），另一类是用 LLM 打分的 judge（相关性、忠实度、答案正确性、语气合规），在 trace 或 dataset run 上批量跑，产出可比较的分数趋势；再配上线上采样评估，对真实流量按比例打分并把低分 trace 挑出来人工看。评估 Prompt 的设计要点：给出明确的评分维度与分档定义（每题 1~5 分要写清每档什么样子）、要求先复述事实依据再打分（迫使模型看上下文而不是凭感觉）、给出无答案/无法判断时的处理方式、输出强结构化字段便于统计、少样本示例里必须包含「看起来对但实际错」的负例。可信度校准是面试官最爱追的点：LLM judge 会系统性偏乐观，所以要做三件事——固定一批人工标注样本作为「金标准」，算 judge 与人的一致性（准确率、Kappa），一致率不达标就改 prompt 或换模型；用人工标注做定期抽检（例如每周几百条）而不是一次性校准；把「规则检查 + LLM judge + 人工抽检」三层组合起来，凡是 judge 判高分但人工看是错的样本，都要回收进负例集反哺评估 Prompt。迭代流程则是标准闭环：发现漏检 → 归类错因（规则缺失 / 分档模糊 / 场景未覆盖）→ 改评估规则或 prompt → 在固定回归集上验证不会把原来的好样本判坏 → 再上线。

4. RAG 线上效果保障与端到端评估。自动评估只覆盖了「模型输出文本质量」这一层，要保障线上问答效果还得补齐这些：检索侧监控召回质量（人工标注小批量线上的「问题 → 正确文档」对，看 Recall@K；再看无召回时的空结果率），数据侧保证知识库新鲜度（文档更新后多久能进索引、有没有增量同步的失败告警、过期文档有没有下线），性能侧盯首 token 延迟与超时率，安全侧做越权与敏感信息泄漏的抽查。业务层还要拆细指标：意图识别准确率（用混淆矩阵看哪两类在混）、工具编排成功率（是否选了正确的工具）、工具调度成功率（参数是否合法、下游是否返回成功），这三者要分别设阈值告警，因为它们的修法完全不同。端到端评估是最有说服力的：从真实页面入口跑一批标准任务，断言最终产物（报告、表格、工单）是否满足可用性要求，而不只是看聊天回复是否通顺；配上会话级指标（一次解决率、用户追问次数、人工返工率），才算真正闭环。

5. 合并两个有序数组：从手撕到百万级优化。基础解法用双指针从后往前填（nums1 尾部预留了空间时）可以做到 O(m+n) 时间、O(1) 额外空间，比新建数组再拷贝更优；面试时要顺手说出边界：其中一个数组为空、有重复元素、相等时取哪一个（影响稳定性）。测试用例设计要覆盖：空数组、单元素、全部相等、一个数组整体小于/大于另一个、含重复值、超大规模、nums1 尾部空间刚好够用。工程化封装（对外提供接口时）要讲清契约：入参是原地修改还是返回新数组、是否允许修改输入、空间复杂度承诺、异常与非法输入如何处理（长度越界、容量不足），再配文档与单测。百万级 / 超大数组要谈的是性能与内存：单机内存放不下时分块处理，把两个数组按块读入、用败者树或小顶堆做 k 路归并（k 路归并是「合并 k 个有序数组」的推广），块间用顺序 IO 流式写盘降低内存峰值；多线程并行归并要注意线程安全——每个线程只写自己负责的输出区间（按前缀和预先切分边界），避免共享写；还要考虑缓存友好（顺序访问、避免随机跳写）与是否值得用并行（规模不够时线程开销反而更大）。判断数组是否有序用一次顺序扫描即可，O(n) 且可以对逆序或局部有序做提前返回。

6. SQL：找出至少连续出现三次的数字。经典写法有几种。窗口函数法最清晰：用 ROW_NUMBER() 减去行号构造分组键，让连续相同的值落到同一组，再 GROUP BY 筛出计数 ≥ 3 的组：

SELECT DISTINCT num AS ConsecutiveNums
FROM (
  SELECT num,
         id - ROW_NUMBER() OVER (ORDER BY id) AS grp
  FROM Logs
) t
GROUP BY num, grp
HAVING COUNT(*) >= 3;

这里的关键洞察是「连续」等价于「值相同且 id 与行号的差恒定」。自连接法（l1.id = l2.id - 1 AND l2.id = l3.id - 1 AND l1.num = l2.num AND l2.num = l3.num）直观但只能处理固定长度 3，扩展到「连续 N 次」就得写 N 个自连接，不通用；窗口函数法把 N 当成常量参数，还天然支持「连续出现至少 N 次并给出区间起止」。要主动提的坑：如果 id 不连续（有删除）自连接法会漏判，而 id - ROW_NUMBER() 的写法正好能容忍空洞；去重用 DISTINCT；如果要求返回所有连续区间而不只是数字，就用 MIN(id)/MAX(id) 聚合；MySQL 8.0 以下没有窗口函数，只能退化成自连接或用户变量法。

7. 关于「AI 测试开发」这个岗位的理解。它和传统测开的区别在于被测对象的输出不再是确定性的：同一输入可能得到不同文本，断言不能只靠等值比较，所以工作重心从「写用例执行用例」转向「建评测体系 + 建可观测 + 建回归门禁」。日常大概包含：为 Agent/RAG 系统建数据集与评测流水线（确定性检查 + LLM judge + 人工抽检），做线上 trace 分析与 bad case 归因（定位到检索、编排还是生成），把评测接进 CI 做成发布门禁（指标回退就拦住上线），以及传统的接口/性能/自动化测试能力打底。回答「为什么从 AI 应用开发转测试开发」时，比较有说服力的角度是：自己既写过 Agent 应用、熟悉它的失效模式，又愿意把精力放在「怎么证明它是好的」这件事上，这比纯开发视角更容易发现系统性问题；同时要准备好被追问「你更想写代码还是做质量」，别回避。

《面试题目》

《参考解析》

相关面经