Agent 面试通关 / 05

评估与全局观：怎么量化 Agent 好坏、落地最大挑战

评估和全局观是面试的最后一道关——通常出现在终面或 leader 面。前面的题考的是“你能不能做”，这类题考的是“你有没有运营经验”和“你对这个领域有多深的思考”。

Agent 评测体系

Q：如何量化评估一个上线的 Agent 好坏？除了准确率。

来源：腾讯 Agent 岗终面【百度 - Agent 研发岗（架构方向）追问：如何量化 Agent 的“智能程度”（除准确率外）？】【美团 - Agent 开发岗（场景设计方向）追问：任务完成率统计及避免主观评估？】【深信服Agent开发实习生一面二面，长时间被吊着，最终被横向掉了追问：最终的效果怎么样？准确率达到了多少？怎么测评？】【8.26百度二面追问：你们怎么评估这个 Agent 的效果，以及后续怎么优化？】【拼多多 复活赛 一面追问：你们用的 Agent 在实际过程中有没有评价指标？比如准确率、误报率，处理现网配置时有没有这类指标？】【PDD Agent三面追问：Agent输出效果如何量化评估？】；本轮追问：你如何定义一个好的 Coding Agent？（9.14小红书 PE（产品工程师/全栈方向–实习）二面 (流程泡到9.21挂)）；字节 aime 一面 9.10；本轮追问：你怎么评估生成内容的质量？除了人工评估还有哪些方法？ / 你怎么评估生成内容的“创意”程度？（小红书多模态秋招二面）；本轮追问：你怎么评估座舱Agent的用户体验？有哪些指标？ / 你怎么评估车辆Agent的准确性？ / 你怎么评估Agent的“拟人化”程度？（蔚来——大模型算法岗（智能座舱/自动驾驶）实习一面）；本轮追问：你们的任务质量、效率、交互成本和效用函数如何定义？ / 你的方法相对于 baseline 的效果和 Token 节省是多少？（字节算法（Agent）凉经）；(秋招) 9.16 字节中交广 - 交易与广告业务 - AI全栈开发工程师；本轮追问：如何保证你的任务完成准确率数字是可信有意义的？（华为AI开发二面）；深至科技一面丨全栈开发实习（医疗AI）；美团 正式批 一面 自动驾驶算法工程师；度小满 - AI 全栈研发 - 一面；腾讯 260824 一面面经；海底捞AI工程师实习生一面；联宝科技秋招AI应用开发AI面面经；高斯信息技术，ai开发工程师，一面；小鹏AI安全一面（10.8）；秋招-字节跳动-抖音电商-Agent开发一/二/三面

新手答：“看任务成功率和用户满意度。”

高手答：

我们有一个三维看板：

1. 效能维度：任务完成率、平均完成步数、单任务平均耗时与 Token 成本
2. 质量维度：结果准确率（人工抽检）、用户满意度（评分）、一次解决率
3. 鲁棒性维度：异常处理成功率、自修复触发率、平均无故障运行时间

最关键的是，每次失败都必须能归因到具体模块（是意图理解、规划、工具调用还是记忆的问题），并流入优化队列，驱动系统迭代。

生成质量可用规则或事实校验、引用一致性、语义相似度和经校准的 LLM-as-judge，并用人工抽样复核；创意看新颖性、多样性和约束满足。座舱重点看端到端时延、打断成功率、意图与工具准确率、误触发及满意度；Coding Agent 看测试通过率、修复成功率和回滚率。拟人化看语气自然度、角色一致性和用户偏好。用质量、耗时、Token/费用加权成效用函数，与 baseline 在同一任务集对比并报告节省比例。

任务完成准确率不能只报单次均值：先固定版本、任务集和成功判定规则，按场景、难度、风险分层抽样，并与人工标注或可执行结果交叉验证；隔离评测集防止数据泄漏，同时报告样本量、置信区间及失败类型，定期复测漂移。

追问补充：先约定指标口径：例如闭环成功率以验收通过任务数为分子，根因正确率以人工复核一致的归因数为分子，并写清分母和不可判定样本规则。“5% 噪声”必须说明来自抽样复核估计还是人为注入，二者不能混报。用脱敏的任务 ID 串起意图、检索、工具、生成和反馈；结合分层评测与事件漏斗定位损失环节。

追问补充：杂乱数据评估时先按事件时间线、异常聚类和影响范围定位关键问题，再让Agent拆解假设、证据和行动，并用可执行结果回测。业务错误通常集中在边界样本、工具参数、过期知识和多轮状态丢失。LLM评估器只作辅助，采用固定标准、参考答案和人工盲抽复核，并用多个评估器或规则交叉校验，不能自证正确。

差距在哪：新手的答案只有两个指标，且都是结果指标——只知道“好不好”，不知道“哪里不好”。高手的三维看板覆盖效能、质量、鲁棒性三个维度，更关键的是有失败归因机制——这才是驱动系统持续改进的关键。面试官考的是“你有没有运营线上系统的经验”。

Q：在你看来，当前阻碍 Agent 大规模落地的最大挑战是什么？

来源：腾讯 Agent 岗终面【百度 - Agent 研发岗（架构方向）追问：当前 Agent 系统面临的最大工程挑战是什么（上下文、工具、规划）？】；百度Agent二面，不看简历不问八股

新手答：“成本高，效果不稳定。”

高手答：

是“可控性”与“能力”的权衡困境。

要它强大，就得给它灵活性和自主权，但这就引入了不可控风险。锁死它的行为，又容易把它变成流程固定的“智障脚本”。

我们的实践是：在核心业务逻辑层用状态机保证主干流程正确，在具体的“思考”环节给予模型在安全沙盒内的最大自由。同时，投入重兵建设评估、监控、干预体系，用大量测试用例和线上监控，像训警犬一样，明确告诉模型什么能做、什么绝不能做，逐步对齐。

差距在哪：新手的回答是事实陈述——“成本高、效果不稳定”谁都知道。高手把问题抽象成了一个设计权衡（可控性 vs 能力），并给出了自己的解法。面试官问这种开放题，考的不是“正确答案”（没有正确答案），而是“你对这个领域的思考深度”和“你有没有自己的方法论”。

Q：如何对 Agent 记忆系统的效果进行量化评估？

来源：后端 AI 八股 / Memory 系统；本轮追问：粗排和精排之间的一致性具体指什么？如何进行评估？（本轮追问）；本轮追问：所以是理论分析，还是有实验评估？（本轮追问）；小厂智能体凉经

新手答：“看记忆召回率。”

高手答：

记忆系统的评估分离线评估和在线评估两大类：

离线评估（上线前，用标注数据集打分）：

在线评估（上线后，用真实流量监控）：

最容易被忽视的是离线指标好但在线效果差的情况——检索 Recall 很高，但模型可能检索到了正确记忆却完全忽略它，这在离线 Recall 上看不出来，只有在线的 Task Success Rate 和 Negative Feedback Rate 才能暴露。

差距在哪：新手只看检索维度。高手把评估拆成离线（Precision/Recall/ROUGE）和在线（Task Success Rate/Engagement/Negative Feedback）两大类，且指出“离线指标好不等于在线效果好”这个容易被忽视的盲区。面试官考的是你有没有端到端评估记忆系统的方法论。

Q：你觉得 Agent 在线上最难监控的指标是什么？

来源：腾讯大模型应用开发二面；本轮追问：除成功率和耗时外，还应关注哪些指标？（字节 aime 一面 9.10）；虾皮秋招 研发工程师

新手答：“延迟和成功率。”

高手答：

最难监控的其实不是延迟和成功率，这些都很容易打点。最难的是“表面成功但实际决策错误”——比如工具调用全成功，答案也返回了，但它选错了工具、用了次优证据，或者本来该追问却没追问。这类问题不会直接反映在现有监控指标上。

所以 Agent 监控不能只有系统指标，还要有决策质量指标：

系统指标（容易）：延迟、成功率、错误率
决策指标（困难）：工具选择正确率、重复动作率、无效步数占比、
                 需要追问却未追问的比例、最终答案证据覆盖率

这些指标更难建，但如果没有，线上看起来一切正常，用户体验却会持续变差。

追问补充：还应设置体验与稳定性护栏：P95/P99 延迟、超时和错误率、会话中断率、重复或无效动作率、追问与人工兜底率、答案采纳或负反馈率、拒答与安全违规率，以及 token 成本和限流情况；按实验组与基线分层观察，异常时自动降级或止损。

差距在哪：新手只关注系统指标——延迟和成功率容易打点但不够。高手指出了真正的难点是“决策质量指标”——表面成功但实际决策错误的情况在传统监控里看不到。面试官考的是你有没有 Agent 系统运营的实战经验，以及对“决策质量 vs 系统质量”的区分能力。

AI 工具与开发经验

Q：从开发者角度，做 Agent 最难的部分是什么？

来源：腾讯 Agent 应用开发一面 / 百度 Agent 一面【9.4 某小厂 AI Agent hr+技术面追问：在该 Agent 项目开发中，你认为最难的技术点或挑战是什么？是如何迭代解决的？】；9.21 浩鲸科技 二面；去哪儿ai应用技术面（挂）；9.22 阿里千问二面

新手答：“让模型听话。”

高手答：

最难的是在“灵活性”和“可控性”之间找到平衡点。

给 Agent 足够的自主权，它能处理更复杂的任务，但也更容易跑偏、幻觉、死循环。锁死它的行为空间，任务能正确完成但只能处理预定义的简单场景。

具体来说有三个难点：

1. 状态管理：Agent 执行多步任务时，如何保证中间状态不丢失、不污染、不矛盾？上下文窗口有限，又不能把所有信息都塞进去——这个“精准投喂信息”的工程是最耗时间的
2. 失败恢复：Agent 不是一次就能做对的。真正的工程挑战是“做错了之后怎么恢复”——重试？回退？降级？不同类型的错误需要不同的恢复策略，而且这些策略不能让 Agent 自己决定
3. 评估困难：传统软件有明确的对错判断，但 Agent 的输出是概率性的——“基本对”和“完全对”之间差的可能不是模型能力，而是 Prompt 里少了一句话。这让调试变得极其低效

本质上，做 Agent 最难的不是“让模型做事”，而是把模型的不确定性关进工程的笼子里。

差距在哪：新手用“不听话”概括了一切。高手从灵活性/可控性权衡出发，拆出了状态管理、失败恢复、评估困难三个具体难点。面试官考的是你有没有做过真实 Agent 开发的深度思考。

Q：有没有遇到过 AI 应用或者工具无法解决的场景？

来源：腾讯 Agent 应用开发一面【深信服Agent开发实习生一面二面，长时间被吊着，最终被横向掉了追问：如果出现当前已有工具无法解决的问题时，怎么去解决的？】；中兴未来领军计划AI算法一面

新手答：“复杂逻辑写不好。”

高手答：

AI 工具的能力边界主要在三类场景：

1. 需要深度业务上下文的决策：AI 不了解你们团队的技术债、历史决策背景、线上事故教训。比如“这个字段为什么叫这个名字”——答案可能在半年前的一次会议记录里，不在代码中
2. 涉及跨系统状态一致性的操作：AI 能帮你写代码，但不能帮你协调“改完数据库 schema 后同时更新下游三个服务的 proto 文件并通知对应负责人”——这类涉及组织协调的任务超出了工具能力
3. 需要对结果负责的高风险决策：删除生产数据、修改支付逻辑、选择技术架构——这些决策的后果需要人承担，AI 可以提供选项和分析，但不能替你做最终判断

核心认知：AI 擅长“执行已定义的任务”，不擅长“定义任务本身”。知道 AI 不能做什么，和知道它能做什么一样重要。

差距在哪：新手用“复杂”一词含糊带过。高手从业务上下文、跨系统协调、高风险决策三个具体角度界定了 AI 的能力边界。面试官考的是你有没有对 AI 工具做过理性评估，而不是盲目吹捧。

Q：你觉得 AI 工具最大的帮助场景是什么？

来源：腾讯 Agent 应用开发一面 / 去哪儿 AI 全栈 AI 面

新手答：“写代码快。”

高手答：

AI 工具最大的帮助不是“快”，而是降低了探索未知领域的启动成本。

具体来说有三个层次：

1. 信息密集型任务：代码生成、文档撰写、数据清洗——这些任务的共性是“规则清晰但手动执行耗时”，AI 能把执行时间从小时级降到分钟级
2. 认知脚手架：学习新框架、理解陌生代码库、快速做技术选型调研——AI 充当“即时可用的专家顾问”，把学习曲线压平
3. 思维外包：把机械性的思维劳动（格式化、查 API 文档、写样板代码）交给 AI，人类专注在需要判断力和创造力的环节

最大的帮助场景是第二类——让开发者有能力做以前不敢接的任务。以前不懂前端的后端工程师不会碰 React，现在借助 AI 能快速搭出可用的界面。这是“能力边界扩展”，不只是“效率提升”。

差距在哪：新手只想到了效率。高手从信息密集、认知脚手架、思维外包三个层次分析，且指出最大价值是“能力边界扩展”。面试官考的是你对 AI 工具价值的思考深度。

Q：你觉得 Agent 框架（如 Claude Code）还有哪些地方可以改进？

来源：腾讯 Agent 应用开发一面；本轮追问：你觉得现在 AI Coding 还有什么问题？你踩过哪些坑？（度小满 AI 全栈二面）

新手答：“模型再聪明点就好了。”

高手答：

改进空间主要在三个方向：

1. 上下文管理的透明度：当前大部分 Agent 框架的上下文窗口管理对用户是黑盒——什么时候压缩了、丢了什么信息、为什么突然“忘记”了之前的约定，用户感知不到。改进方向是让上下文状态可视化、可干预
2. 执行过程的可调试性：Agent 做了 10 步操作，中间第 3 步选错了工具，但用户到第 10 步才发现结果不对。缺少的是执行过程的 checkpoint 和回溯能力——能回到第 3 步改个决策重新执行，而不是从头开始
3. 多模态和跨工具的协作：目前大部分 Agent 是单模态文本为主，对图片、视频、音频的理解和操作能力有限。同时，不同工具之间的互操作性（MCP 在解决这个问题）还不够成熟

从工程角度看，最需要改进的是可调试性——Agent 犯错是常态，关键是犯错后能不能快速定位和修复。

AI Coding 的常见问题是上下文理解偏差、依赖和接口假设错误，以及生成代码看似完整但边界条件、异常处理和安全性不足。我会通过小步提交、先让 AI 解释方案，再用类型检查、测试、代码审查和人工验证结果，避免直接接受整段实现。

差距在哪：新手把改进等同于“模型更强”。高手从上下文透明度、可调试性、多模态协作三个具体工程方向提出了改进意见。面试官考的是你对当前工具的批判性思考能力。

RAG 与 Agent 评测指标

Q：你会怎么给 Agent 建立评测体系？只看最终成功率为什么不够？

来源：Agent 开发面试 30 题 / 阿里淘天一面 / 蚂蚁 Agent 开发一面 / 字节 AI Agent 研发一面 / 中兴软开一面 / 钉钉一面【MiniMax - 大模型算法岗（后训练 / SFT / RL）追问：如何评测 Agent 的工具调用能力并构建评测集？】【作业帮秋招一面追问：有没有做过 Agent 评测相关工作？】【pdd agent二面追问：Agent评测体系，测试用例覆盖范围？】；8.25 小红书实习 AI全栈开发实习一面挂凉经；小米–后端–二面；本轮追问：你项目中提到测试用例90%的成功率，该数据如何统计？剩余失败的原因是什么？（4399-agent开发面经）；本轮追问：如何衡量不同 Coding Agent 或不同 Agent 调度方案的好坏？ / 你对 Sub-agent 做了哪些评测？优化的指标是什么？（9.14小红书 PE（产品工程师/全栈方向–实习）二面 (流程泡到9.21挂)）；字节 AI Agent 开发 一面（抖音电商 · 一面掉池子里面了）；本轮追问：单 Agent 和多 Agent 做过对照评测吗？（快手大模型agent研发一面）；【社招】腾讯二面面经；本轮追问：迭代后怎么验证效果？（回归评测、能力评测、灰度、影子 case） / 评测中如果出现“小层面提优、大方向负优化”怎么办？（【面经】字节/AI 应用工程师 一面挂经……）；本轮追问：你写了测试集，怎么来的？有什么效果？后续测试集有没有回归调优？（携程agent开发一面）；本轮追问：评测过程中会记录哪些 Trace 数据？使用了哪些确定性指标？（9.22 阿里千问二面）；经纬恒润ai应用开发一面面经；腾讯 260824 一面面经；模思智能（Moss）多模态voice相关测评；快手二面；虾皮秋招 研发工程师；10.8 pdd秋招 agent 一面；小鹏AI安全一面（10.8）

新手答：“设计一批测试用例，看通过率。”

高手答：

只看最终成功率有两个致命问题：① 成功率 80% 告诉你“有 20% 失败了”，但不告诉你为什么失败；② 两个 Agent 都是 80% 成功率，但一个平均 3 步完成、另一个平均 15 步完成——体验天差地别。

完整的评测体系要覆盖四个维度：

过程质量是最容易被忽视但最有价值的维度——即使最终成功了，如果中间绕了一大圈、调了三次错误工具才蒙对，说明系统有隐患。

评测集设计：

基础用例（60%）：覆盖核心功能的标准场景
边界用例（20%）：缺参数、矛盾输入、超长上下文
对抗用例（10%）：prompt injection、故意误导
回归用例（10%）：历史 bug 对应的测试用例

评测频率：每次模型/Prompt/工具变更后必须跑全量评测，日常用核心用例做冒烟测试。

调优实战：怎么从评测结果驱动改进？

评测不是跑个分就完了，关键是从评测结果中定位瓶颈、制定优化方案、验证改进效果的闭环。面试官经常追问“讲一个调优 case”，回答结构应该是：

发现问题 → 归因分析 → 优化方案 → 效果验证

例：工具选择准确率从评测中发现只有 65%
  → 归因：工具描述太相似，模型无法区分”搜索文档”和”搜索知识库”
  → 优化：重写工具描述，加入使用场景和输入输出示例
  → 验证：工具选择准确率提升到 88%，端到端成功率从 72% 提升到 85%

评测集的构建同样重要——好的评测集不是越大越好，而是要覆盖核心场景、边界条件、已知失败模式。每次修复一个线上问题，都应该把对应的 case 加入回归评测集。

通用 Benchmark 和产品回归集也要分开。Benchmark 固定任务定义、环境、制品版本和计分器，用来比较跨方案泛化；产品回归集追踪当前业务契约和历史 Badcase，可以随版本演进。两者都要记录环境/模型/工具版本并防止测试泄漏，但不能拿公开榜单分数替代真实流量验收。

例如订票 Agent 不能只看最终“是否返回机票”：还要评估槽位澄清是否充分、航班/价格证据是否与工具终态一致、是否在支付前正确确认、失败后有没有释放占座或进入补偿，以及必要转人工是否完整携带上下文。没有人工中间审核的线上系统，则通过影子流量、分层抽检、用户行为信号和高风险升级持续观测，不能让模型自评成为唯一 Oracle。

“90%成功率”应明确评测集、通过判定、分母、运行次数和环境版本，按任务级统计，并将失败归为规划、工具调用、参数、执行、超时或评测器问题。比较 Coding Agent 或调度方案时固定任务、模型和预算，比较成功率、成本、延迟、步数、回归缺陷；Sub-agent 还看路由准确率、交接完整性、独立贡献、重复调用率和失败恢复率。

Trace 至少记录请求、状态转移、模型与工具版本、工具参数及返回、耗时、token、错误和最终判定，并用固定数据集与确定性规则复现。若局部指标提升但总体回退，按场景分层定位，设置关键任务回归门禁，必要时灰度或回滚；单、多 Agent 需在相同任务、模型和预算下比较。

追问补充：评测集应按任务类型分层：文本回答看事实准确性、相关性、完整性和拒答边界；工具调用看工具选择、参数填充、调用顺序、结果解析及失败恢复；端到端任务再看最终目标是否完成。各层分别统计指标，并保留混合任务验证跨能力协同，避免工具成功掩盖回答质量问题。

追问补充：Rubric先拆成正确性、证据、完整性、安全性、效率和过程约束，定义分级锚点与硬性扣分；两条均成功的轨迹用盲评、成对比较和工具事实校验，重复评审校准一致性。困难集来自线上Badcase及缺参、冲突、注入、越权、工具故障，反馈结合评分、重试、追问、转人工和完成率，用留出流量验证相关性。

差距在哪：新手只看成功率。高手建立了四维评测体系（效果/效率/鲁棒性/过程质量），且指出过程质量是最容易被忽视的维度。面试官考的是你有没有“评测驱动优化”的工程方法论。

Q：RAG 系统（如 oncall 机器人）的回答准确率怎么计算？用知识问答对比还是文档相似度？

来源：蚂蚁集团智能体与大模型应用二面【字节二面（Trae）追问：准确率怎么计算？】；本轮追问：有没有验证过检索准确率？（小红书 Product Engineer（AI与全栈方向）-社区工程 一面面经）；本轮追问：最初只有50条产品提供的黄金数据来构建知识库时，你们是怎么测量并确认这个知识库支撑下的回答准确性不达标的？（27秋招-恒生电子AI面试-AI应用开发岗-26.9.23）；乐堡AI应用开发岗四面面经，面试官非常nice！；智加 自动驾驶软件工程师；10.8号顺丰AI全栈一面

新手答：“人工看看对不对，算个比例。”

高手答：

oncall 机器人或 RAG 问答系统的准确率评估比“人工看”复杂得多，因为要区分检索准确率和回答准确率——检索对了但回答可能错，检索错了但回答可能蒙对。

评估框架分两层：

1. 检索层评估（文档相似度方向）——衡量“找的资料对不对”：

• Recall@K：正确文档是否在 top-K 召回结果中
• Precision@K：top-K 结果中有多少是真正相关的
• MRR：正确文档排在第几位

评估方式：构建标注集——(query, ground_truth_docs) 对，用标注文档和实际召回文档做匹配。

2. 回答层评估（知识问答对比方向）——衡量“最终回答对不对”：

• Exact Match / F1：回答和标准答案的文本匹配度
• LLM-as-Judge：用另一个大模型评分（1-5 分），判断回答的准确性、完整性、相关性
• Faithfulness：回答是否忠实于检索到的文档（有没有编造文档里没有的内容）

用哪种方法，取决于评估目标：

实际生产中的组合策略：

1. 离线评估：用标注集同时跑检索指标和回答指标，定位问题出在检索还是生成
2. 在线评估：埋点用户行为（点赞/点踩/追问率）作为隐式反馈，辅以每日抽样人工评估
3. 归因分析：回答错误时，先查检索结果——如果检索到了正确文档但回答仍然错，说明是生成环节的问题；如果根本没检索到正确文档，说明是检索环节的问题

只有50条黄金数据时，可先人工确认每条的标准答案与相关文档，按查询类型留出小规模验证集，统计Recall@K、MRR及端到端回答正确率，并逐条分析失败原因。若结果低于预设门槛或某类查询持续漏召回，就能确认知识库覆盖或检索效果不达标；同时记录样本量有限，后续用线上抽样和新增标注复核。

追问补充：检索指标需明确分母：Recall@K = 命中的相关文档数 ÷ 标注相关文档总数；Precision@K = top-K 中相关文档数 ÷ K；MRR 取首个相关结果排名的倒数。知识库有效性还应检查覆盖率、内容时效性和冲突文档，并按查询类型分桶复测。

差距在哪：新手用“人工看”一刀切。高手把评估拆成检索层和回答层两个维度，且说清了不同评估目标对应不同方法，最后给出了离线 + 在线 + 归因的组合策略。面试官考的是你有没有系统性评估 RAG 系统的方法论——“对不对”是表象，“哪里不对、为什么不对”才是核心。

Q：如何从真实 Issue 构建可复现的缺陷修复 Agent Benchmark，并防止污染和假修复？

来源：字节 AI Agent 研发一面；本轮追问：解决测试用例质量差、不可复现的最关键设计是什么？为什么没有选择其他技术路线？（恒生电子技术岗ai面）

新手答：“收集一些 GitHub Issue，让 Agent 改代码，最后看测试能不能通过。”

高手答：

一条缺陷修复样本不是“Issue 文本 + 最终 Patch”，而是一个可重建的任务包：

repo + base_commit + issue_text
+ 可构建的依赖/容器环境
+ 公开测试与隐藏验收测试
+ gold patch（仅用于构造和审计）
+ 许可证、时间和来源元数据

构造时先锁定 Issue 修复前的 base_commit，确认原始失败能在干净容器中复现；再应用人类修复，验证新增测试从失败变为通过且原有测试不回归。Issue 中缺失的环境、数据或外部服务要显式冻结或 Mock，无法稳定重现的样本直接隔离。SWE-bench 官方 README同样以真实仓库和 Issue 评估补丁，并使用 Docker 运行可复现评测；借鉴的是任务不变量，不是照搬其所有项目和资源要求。

防污染要同时做四层切分：

1. 时间切分：训练知识截止时间晚于 Issue/修复公开时间时，不能声称是未见问题。
2. 仓库/Issue 切分：同一 Issue、PR、回退提交和镜像修复不得跨训练、调参和测试集。
3. 语义去重：模板、堆栈、测试名和 Patch 的近重复要聚类，避免同一缺陷换描述泄漏。
4. Gold 隔离：gold patch、隐藏测试和失败诊断不进入 Agent 的工作区、Prompt、检索索引或可访问日志。

评测必须防“假修复”：Agent 不能删测试、放宽断言、硬编码样例、跳过失败模块或只修改测试配置。Harness 在隔离容器中从 base commit 应用预测 patch，先做 Patch 合法性和改动范围检查，再运行隐藏的 fail-to-pass 与 pass-to-pass 测试、静态/安全检查和超时资源门禁。一次通过还不够，非确定 Agent 应重复运行并报告方差和失败类型。

核心指标是严格 resolved rate，同时按可构建、可应用、测试失败、超时和环境错误拆分；再报告每题 Token/模型费用、墙钟时间、尝试次数、人工介入率和重复运行稳定性。与 11-ai-code-testing 的代码 Oracle 分工是：本题定义怎样构造不泄漏的可比较任务集，11 维负责单次候选 Patch 应经过哪些确定性验证。

最关键的是把“失败可重放”作为入集门槛：固定提交、依赖、数据、时钟和网络，并用独立的失败测试与回归测试作可执行 Oracle；重复运行不稳定就剔除。相比只依赖人工评审、单一公开测试或纯合成样本，这种方案更能客观识别假修复，也保留真实 Issue 的复杂性。

差距在哪：新手把 Benchmark 当 Issue 合集。高手会冻结 base commit 和容器、隔离 gold/隐藏测试、治理污染与假修复，并用严格成功率、成本和重复运行共同衡量 Agent。

Q：如果线上反馈“这个 Agent 有时候很好，有时候很差”，你第一步会看什么指标和日志？

来源：Agent 开发面试 30 题；本轮追问：线上用户反馈“没有帮助”，主要是哪些场景没有覆盖，原因是什么？（淘天AI应用开发二面）

新手答：“看看是不是模型不稳定。”

高手答：

“有时好有时差”说明不是系统性问题，而是特定条件下触发的问题。排查思路是缩小范围 → 找到分界线 → 定位根因。

第一步：看分布，不看平均

把最近 N 天的请求按成功/失败分两组，对比以下维度的分布差异：

第二步：看执行链路日志

从失败案例中抽 5-10 个典型 case，逐步看执行链路：

用户输入 → 意图识别结果 → 规划的步骤 → 每步的工具调用和返回 → 最终输出

找到第一个出错的环节——是意图理解错了？规划有遗漏？工具返回异常？还是最终生成时忽略了关键信息？

第三步：看“成功但低质量”的灰色地带

不只看失败，还要看用户评价低但系统判定成功的请求——这些是“表面成功但体验差”的隐藏问题。

“没有帮助”还要建立意图覆盖矩阵：按用户任务、行业/实体、语言表达和工具依赖统计请求量、成功率与低评分率，识别未覆盖或覆盖不足的长尾场景。对典型样本标注缺失意图、知识、工具能力或结果解释，并用回放集验证补充后的覆盖率和质量。

差距在哪：新手直觉是“模型不稳定”——这等于没排查。高手有系统性的排查方法论：先看分布找分界线、再看链路定位环节、最后查灰色地带。面试官考的是你排查线上问题时有没有数据驱动的方法。

落地风险与行业趋势

Q：了解最近 AI 的新方向吗？

来源：蚂蚁集团一面；本轮来源；本轮追问：你看过 DeepSeek 最近发布的相关 Agent 产品吗？（本轮追问）；9.15 小红书 AI应用研发 一面

新手答：“大模型越来越强了，能写代码能画图。”

高手答：

2025-2026 年 AI 领域有几个真正改变开发范式的方向，不只是“模型更强”：

1. 推理模型（Reasoning Models）

以 OpenAI o1/o3、DeepSeek-R1 为代表。核心变化是模型在输出答案前会做长链推理（Chain of Thought），用更多的推理 token 换更高的准确率。这不是简单的“思考更久”——推理模型在数学、代码、逻辑推理等需要多步推导的任务上有质的飞跃。

对开发者的影响：以前靠精心设计 Prompt 引导模型一步步思考，现在模型自己会做——推理能力从 Prompt 工程转移到了模型内部。

2. Agent 原生应用

从“给现有产品加 AI 功能”变成“围绕 Agent 能力设计整个产品”。代表产品：Claude Code（AI 驱动的开发环境）、Devin（AI 软件工程师）、各类 AI 数据分析工具。

核心转变：用户不再是“输入指令 → 获取结果”的单轮交互，而是“委托任务 → Agent 自主规划执行 → 人类监督审核”的协作模式。

3. 上下文工程取代 Prompt 工程

模型能力提升后，Prompt 的精细调优变得不那么关键。真正的瓶颈变成怎么在有限窗口里给模型恰好的信息——动态工具加载、分层记忆召回、渐进式披露。上下文工程是 2026 年 Agent 开发的核心技术栈。

4. 协议标准化（MCP + A2A）

Agent 生态从“各家自己造轮子”走向协议标准化。MCP 解决了 Agent 到工具的连接标准，A2A 解决了 Agent 之间的通信标准。这意味着Agent 组件变得可复用、可互操作——类似 Web 时代 HTTP 协议的意义。

5. 端侧 AI 和混合推理

3B 以下的小模型在端侧（手机、笔记本）可用后，出现了云端大模型 + 端侧小模型混合推理的架构——简单任务端侧处理（低延迟、隐私保护），复杂任务上传云端。这改变了 AI 应用的部署架构。

差距在哪：新手只感知到“模型更强”。高手从推理模型、Agent 原生应用、上下文工程、协议标准化、端侧混合推理五个方向做了结构化梳理，每个方向都说清了对开发者的实际影响。面试官用这道开放题考的是你的行业视野和技术敏感度——不是背新闻，而是能从趋势中提炼出对自己工作的影响。

Q：2026 年做 Agent 应用开发，跟去年相比最大的变化是什么？

来源：蚂蚁集团 Agent 开发二面

新手答：“模型更强了，能做的事更多了。”

高手答：

模型变强是基础事实，但真正影响开发方式的变化不在模型本身，而在工具链、架构范式和工程实践三个层面：

1. 从“Prompt 工程”到“上下文工程”

去年做 Agent，核心工作是调 Prompt——怎么写 System Prompt、怎么做 few-shot、怎么做 chain-of-thought。2026 年，随着模型能力提升，Prompt 的精细调优变得没那么关键了。真正的瓶颈变成了上下文工程——怎么在有限窗口里给模型恰好的信息：项目结构索引、动态工具加载、分层记忆召回、操作后状态刷新。

2. 从“单 Agent 做所有事”到“协议化的多 Agent 协作”

去年的多 Agent 还停留在“自己写消息传递逻辑”的阶段。2026 年 MCP（工具协议）和 A2A（Agent 间协议）逐步标准化，Agent 之间的协作从“每次重新造轮子”变成了“基于协议即插即用”。这改变了架构思维——从“设计一个万能 Agent”变成“设计一组专业 Agent + 标准化的协作协议”。

3. 从“Demo 驱动”到“评测驱动”

去年很多团队做 Agent 是“先做 Demo，效果好就上线”。2026 年的共识是：没有评测体系的 Agent 不能上线。持续评测管线（自动跑评测集、指标监控、回归检测）成了标配，Agent 开发的一半时间花在评测和可观测性上。

4. 从“纯 Agent”到“Workflow + Agent 节点”混合架构

去年有很多“纯 Agent”尝试——让模型全程自主决策。实践证明不可行。2026 年主流方案是确定性环节用 Workflow 控制、不确定性环节嵌入 Agent 节点。这不是 Agent 的退步，而是找到了 Agent 在生产系统中的正确位置。

差距在哪：新手只看到了“模型更强”。高手从上下文工程、协议化协作、评测驱动、混合架构四个维度说明了开发方式的本质变化——不是“能做更多”，而是“怎么做变了”。面试官考的是你对 Agent 技术发展的结构化观察能力。

Q：要把 Agent 真正上线到生产环境，你认为最容易被低估的三个风险点是什么？

来源：Agent 开发面试 30 题

新手答：“成本、延迟、准确率。”

高手答：

成本、延迟、准确率是所有人都知道的风险，恰恰因为人人都知道，反而不会被低估。真正被低估的风险是那些在 Demo 阶段看不到、上线后才暴露的：

1. 长尾输入的不可控行为

测试集覆盖不了所有用户输入。总有 5% 的用户会问出你从没想过的问题——模型可能给出荒谬的回答、陷入死循环、或者触发不该调用的工具。长尾问题的危害不是频率高，而是一个恶性案例就能毁掉产品口碑。

防范：上线初期必须有人工审核 + 实时告警，对异常执行模式（步数过多、工具调用异常、输出过长）即时报警。

2. 状态漂移——系统跑着跑着就“变味”了

模型版本更新、外部 API 返回格式微调、知识库内容更新——任何一个上游变化都可能让 Agent 行为悄悄偏移。不像传统软件的 bug 有明确的报错，状态漂移是渐变的、静默的，可能跑了两周才有人发现“最近回答质量好像下降了”。

防范：建立持续评测管线——每天自动跑核心评测集，指标下降立刻告警，不等用户投诉。

3. 隐式依赖链断裂

Agent 的正确运行依赖一条长长的隐式链路：模型 API 稳定 → Embedding 服务可用 → 向量库正常 → 外部工具 API 不变 → 知识库内容准确。任何一环断裂都会导致问题，但故障表现往往和根因相距甚远——知识库更新了一个错误文档，表现出来是“Agent 给了错误建议”，中间隔了检索、排序、生成三个环节。

防范：对所有外部依赖做健康检查和变更监控，知识库更新后自动触发回归测试。

差距在哪：新手列的都是显而易见的风险。高手指出了三个“Demo 阶段看不到、上线后才暴露”的隐性风险——长尾输入、状态漂移、隐式依赖链断裂，且每个都有具体的防范方案。面试官考的是你有没有把 Agent 推到生产环境的实战经验。

评测方案设计与实践

Q：通过什么方式去验证 Skill 的提升效果，指标是什么？

来源：美团/食杂后端一面 【电商库存一面追问：Skill 变更影响面回归】【字节火山引擎 Managed Agent 一面追问：脚本与模型评审对比两个 Skill】【快手 AI 全栈一面追问：降低离线评测成本并预估转人工率变化】【快手 - Agent 开发岗（应用落地 + AI 工具）追问：Skill 的质量评估指标有哪些？】【作业帮一面 9.5追问：怎么验证 skill 的效果？怎么判断 skill 行不行、要不要改？】【阿里边缘bu 秋招一面 （已过）追问：任务执行完成率从不足 50% 提升到 100%，这个指标是怎么评测出来的？】；本轮追问：你是否了解主流 Agent 架构、工具调用链路和 Skill 评测等概念？（本轮追问）；本轮追问：输入 Token 降低、写入率提升等相对指标的对比 baseline 是什么？（本轮追问）；携程 AI 应用开发二面（已oc）；本轮追问：医疗项目中写的 Recall@5 从多少提升到多少，这个是准确数据还是预估值？（飞书深诺（全栈AI应用开发方向））；本轮追问：投放后多久生效，怎么验证效果？ / 有哪些量化指标，做到多少算好？（快手电商大模型应用开发一面（已offer））；阿里虎鲸文娱 - AI 基础设施 - 一面；淘天供应链ai应用研发一面；本轮追问：评测面向内置 Skill 还是业务方 Skill？怎样反馈业务方优化？（9.15科大讯飞AI应用一面）；本轮追问：有没有做过实验，衡量过移除 skill 正文和不移除 skill 正文的 token 成本消耗？（【社招】腾讯一面面经）；本轮追问：修改 Skill 或 CLI 后，如何验证它能达到线上运行的预期？ / 详细介绍一下你设计的 Skill 评测系统及其执行流程。（9.22 阿里千问二面）；模思智能（Moss）多模态voice相关测评

新手答：“看用户反馈好不好，或者看任务成功率有没有提升。”

高手答：

验证 Skill 效果需要分层度量 + 对照实验：

1. 指标体系

2. 评测方法

• A/B 对照：同一批 eval case，分别在有/无该 Skill 的条件下跑，对比成功率和步数
• 回归检测：新增 Skill 后原有能力是否退化（跑全量 eval set）
• 边界测试：故意给模糊/交叉意图，看 Skill 是否误触发

大规模离线评测先按意图、风险和难度分层抽样，并缓存解析、检索和确定性工具结果，只重跑受 Skill 变更影响的阶段；便宜规则先筛硬失败，模型 Judge 只处理剩余语义样本，高风险和 Judge 分歧再人工复核。报告必须给置信区间和分层结果，不能用缩小样本后的点估计声称“转人工率会下降”。上线后再按同一转人工口径做稳定分桶验证，区分必要转人工和可避免转人工。

评价脚本和模型评审承担不同职责。格式、必填字段、工具调用、单测和业务不变量优先用确定性脚本；开放式质量使用固定 Rubric 的模型 Judge，隐藏候选名称并随机交换 A/B 顺序，重复多次检查位置偏差。Judge 分歧或高风险 Case 进入人工复核。对比两个 Skill 时固定模型、Prompt、工具快照和任务集，只改变 Skill 版本，同时报告成功率、路由准确率、Token、延迟、副作用和置信区间，不能用单次“看起来更好”决定发布。

回归集要分三圈：该 Skill 自己的正向、反向和边界 case；它与相邻 Skill 的路由混淆对（同一意图只改一个关键条件，看是否选错）；以及全局任务集。发布门槛同时约束本 Skill 的收益和另外两圈的最大退化，不能只证明“自己的题做得更好”，却让路由抢占其他 Skill 或损伤通用任务。

3. 实战经验

Skill 的效果不是线性的——简单任务提升不大，复杂重复任务提升显著。所以评测集要按任务复杂度分层，分别算各层提升比例，避免被简单任务的高基线稀释了真正的收益。

Recall@5 必须标明数据来源：在固定版本、固定测试集和统一标注口径上实际跑出的统计值，还是方案阶段的预估值。若为实测，应同时给出样本量、基线版本、点估计及置信区间；若为预估，必须明确标注，不能当作项目结果表述。

投放时应确认 Skill 的版本已在目标环境生效，可用版本标记、灰度流量和线上日志验证；CLI 修改还需做接口契约、回归、异常和真实工具链测试。对业务方 Skill，应提供分层报告和失败样例，指导其优化触发条件、工具参数与输出格式；移除正文的收益则需在固定样本上单独做 A/B，比较 Token、成功率和延迟。

追问补充：量化时固定同一任务集、模型、工具和预算，按任务级配对比较：通过率提升为（新方案通过率−基线通过率）/基线通过率，成本按每个成功任务的 Token 或实际费用计算，再报告样本量、置信区间和各难度层结果，避免把绝对百分点与相对提升混淆。

差距在哪：新手只看一个结果指标。高手分了触发/执行/效率/质量四层，且有对照实验设计和回归检测意识。面试官考的是你对“如何科学度量一个能力模块效果”的工程化思维。

Q：RAG 系统如何评测？有哪些评测维度和指标？评测数据集怎么构建？

来源：快手 AI Agent 开发一面 / 钉钉一面【字节二面（Trae）追问：评测机制怎么做？】【腾讯/csig/元宝/内容安全/日常实习/三轮技术面试追问：对于什么场景进行评测？评测目标是什么？评测集怎么构建的？】【百度Agent一面追问：评测集是怎么做的？】；9.15 小红书 AI应用研发 一面；本轮追问：你怎么评估多模态模型的内容理解效果？评测集怎么构建？（小红书多模态秋招二面）；本轮追问：其中的 300 条评测集是如何构建和测试的，最终结果是怎么得到的？（飞书深诺（全栈AI应用开发方向））；本轮追问：评测集大概多大？评测样本是怎么来的？新增场景如何更新评测集？（淘天AI应用开发二面）；本轮追问：对于线上的元宝内容安全，你打算怎么设计检测指标？评测集打算怎么做？（腾讯元宝 风控实习一面）；本轮追问：向量召回容易召回语义相似但业务口径不匹配的片段，如何量化验证原有召回方案的缺陷？用到哪些评测指标和测试样本？（27秋招-恒生电子AI面试-AI应用开发岗-26.9.23）；字节Agent开发后端 日常实习一面凉面；本轮追问：综合准确率从20%+提升到80%+，该指标是如何定义的？评测集（Benchmark）包含哪些维度，又是如何打分的？ / 评测维度中的“归因深度”较为抽象，具体是如何划分和打分的？（9.20 汇川技术 数字化全栈工程师 一面）；字节全栈一面；经纬恒润ai应用开发一面面经；腾讯 260824 一面面经；虾皮秋招 研发工程师；美团一面全栈开发日常实习面经

新手答：“看回答准不准。”

高手答：

RAG 评测不能只看最终回答——需要分阶段评估，才能定位问题出在哪个环节。

评测维度和指标：

评测框架：

RAGAS：自动化评测框架，内置 Faithfulness、Answer Relevancy 等指标
TruLens：支持自定义评测函数，可追踪 RAG 管线每个环节
DeepEval：开源评测框架，支持 LLM-as-Judge 模式

评测数据集的构建：

flowchart TB
    D["知识库文档"] --> Q1["自动生成\nLLM 从文档中生成 Q&A 对"]
    L["用户真实日志"] --> Q2["日志挖掘\n提取高频/失败 query"]
    E["专家设计"] --> Q3["边界测试\n多跳/矛盾/超范围问题"]
    Q1 --> M["合并去重"]
    Q2 --> M
    Q3 --> M
    M --> A["人工标注\n标准答案 + 相关文档"]
    A --> DS["评测数据集"]

高质量评测数据的要求：

1. 覆盖多种问题类型：
   • 单跳事实题（答案在一个文档中）
   • 多跳推理题（需要关联多个文档）
   • 对比题（两个实体的异同）
   • 超范围题（知识库中没有答案，测试拒答能力）
   • 时效性题（信息可能过期）

2. 标注内容：每条数据包含 query、标准答案、相关文档列表（ground truth）、难度标签

3. 数据规模：通常 200-500 条覆盖主要场景即可，关键是多样性而非数量

4. 持续更新：知识库更新后，评测集也要同步更新，否则评测结果不反映真实表现

多模态评测应按图像、文本、图文关系和安全场景分层：从真实日志、业务素材和对抗样本抽样，人工标注答案、关键区域及证据。300条可按场景分层后划分开发集与测试集，固定版本运行并复核争议；报告识别、证据定位、跨模态一致性及安全误报漏报，新增场景补采并回归旧集。

对“语义相似但口径不匹配”，可在标注集中加入同主题错口径、时效冲突和权限不符样本，分别统计 Precision@K、业务口径命中率、错误召回率和 NDCG。端到端“准确率”应定义为满足事实、口径、完整性且无关键错误的样本占比，并报告各类分项。归因深度可按无依据、引用文档但未定位、定位到段落、定位到关键证据并完成推理逐级打分。

追问补充：可将 RAG 拆为数据与切分、召回、重排、生成、拒答和评测回归任务；分别设验收条件：数据可追溯，Recall@K 达标，答案满足正确性与忠实度，超范围能拒答，并在固定测试集上与 baseline 对比通过。

差距在哪：新手只看“准不准”一个维度。高手把评测拆成检索和生成两个阶段，每个阶段有独立的指标体系，且说清了评测数据集的构建方法和质量要求。面试官考的是你有没有完整的 RAG 质量保障体系——不是“上线看看效果”，而是有离线评测、有基准数据、有分阶段归因。

追问：评测集 100 条够吗？分布怎么分析？baseline 用什么？

来源：字节 AI 一面（RAG 项目深挖）

100 条评测集的三个致命问题：

1. 统计显著性不足：100 条样本下，Recall@5 从 0.81 波动到 0.75 可能只是随机误差，你无法区分“真的变差了”和“评测集太小导致的噪声”
2. 分布偏差：如果 100 条中 80 条是简单的单跳事实题，Recall@5 = 0.81 不代表系统在多跳推理题上也能达到同样水平
3. 无 baseline 对照：0.81 是好是坏？没有参照系就是一个孤立数字

评测集规模的工程标准：

分布分析必做的三件事：

• 按 query 类型分层：单跳事实 / 多跳推理 / 对比 / 超范围各占多少，分层计算指标
• 按难度分级：简单（答案在单段落内）/ 中等（需跨段落）/ 困难（需跨文档）
• 按文档来源分布：确保评测集覆盖知识库的各个领域，而非集中在少数文档

baseline 设计：

有了 baseline，“Recall@5 = 0.81”才有意义——“比 BM25 的 0.62 高 30%，但离人类的 0.95 还有差距”。

Q：Agent 的端到端成功率和工具误调用率怎么量化？怎么改进？

来源：腾讯 AI 应用开发二面【百度 - Agent 研发岗（架构方向）追问：工具调用成功率如何进行离线、在线评测？】

新手答：“看任务完成了没有，完成了就算成功。”

高手答：

“完成了没有”是最粗的指标，无法定位问题出在哪个环节。量化需要拆层，改进需要闭环。

端到端成功率的分层量化：

工具误调用率的细分：

工具误调用不是一个单一指标，需要区分三种错误：

误选工具（选了不该选的）→ 看工具选择 Precision
漏选工具（该选的没选）→ 看工具选择 Recall
参数错误（选对了但参数传错）→ 看参数校验通过率

量化工具链：

• 日志基建：每一步（意图识别 → 规划 → 工具选择 → 工具执行 → 结果生成）都记结构化日志，带 trace_id 串联
• 离线评估：用标注好的评测集定期跑回归，计算各层指标
• 线上监控：用 LangSmith / Langfuse / 自建 dashboard 实时追踪成功率、延迟、token 消耗

改进闭环：

flowchart LR
    A[“发现指标下降”] --> B[“定位问题层\n（规划？工具选择？参数？）”]
    B --> C[“分析 bad case\n（随机抽样 + 聚类）”]
    C --> D[“针对性优化”]
    D --> E[“回归评测验证”]
    E -->|”指标提升”| F[“上线”]
    E -->|”无效”| C

常见优化手段：

• 工具选择准确率低 → 重写工具描述（加使用场景、输入输出示例）、减少工具数量（合并相似工具）
• 参数错误率高 → 参数 schema 加 enum 约束、在 System Prompt 中加参数填写示例
• 规划成功率低 → 拆分复杂任务（让模型先生成计划再执行）、加 Few-shot 示例

差距在哪：新手只看一个“成功率”数字，出了问题不知道该查哪。高手把端到端成功率拆成规划/工具选择/工具执行/回复质量四层，把工具误调用拆成误选/漏选/参数错误三类，且给出了从日志基建到改进闭环的完整量化方案。面试官考的是你有没有“可观测 + 可归因 + 可改进”的 Agent 评测方法论。

Q：Ragas 评测框架是什么？Answer Relevance 偏低时，怎么区分是检索问题还是模型问题？

来源：蚂蚁 AI应用开发 二面

新手答：“Ragas 是评测 RAG 的工具，Answer Relevance 低就是检索不好。”

高手答：

Ragas 框架：一个专门评测 RAG 系统的开源框架，核心是把端到端的评测拆解成多个独立维度，每个维度单独打分，这样出了问题能精准定位到哪个环节。

核心指标：

Answer Relevance 偏低时的诊断方法：

Answer Relevance 低有两种可能：检索给了错误的上下文（模型“巧妇难为无米之炊”），或者检索正确但模型理解/表达能力不足。区分方法：

1. 交叉检验法：固定相同的检索结果，分别用当前模型和一个已知强模型（如 GPT-4）生成回答。如果强模型的 Answer Relevance 显著更高 → 当前模型能力不足。如果强模型也低 → 检索问题。

2. 指标联动分析：

• Context Recall 低 + Answer Relevance 低 → 检索没有找到相关文档，模型无法回答 → 检索问题
• Context Recall 高 + Faithfulness 高 + Answer Relevance 低 → 检索结果正确且模型忠实引用了，但回答方式不切题 → 模型理解/表达问题
• Context Precision 低 + Answer Relevance 低 → 检索结果中噪声太多，模型被无关信息干扰 → 检索排序问题

3. 人工抽样：随机抽取 20-30 个低分 case，人工判断检索结果和模型回答各自的质量。自动化指标是辅助，人工抽样是最终确认。

差距在哪：新手直接把 Answer Relevance 低归因于检索——这是最常见的误判。高手用交叉检验和指标联动两种方法精准区分了检索质量和模型能力的影响边界。面试官考的是你有没有系统性的 RAG 评测和问题诊断能力。

追问：Ragas 的 Context Precision 过低，怎么优化？

来源：阿里淘天 AI应用开发一面

Context Precision 衡量的是检索结果中相关文档的排位——即使召回了正确文档，如果排在第 4、5 位而噪声文档排在前面，Context Precision 也会很低。

优化的三个方向：

诊断优先级：先看 Context Recall——如果 Recall 也低，说明正确文档根本没进候选集，优化召回策略优先；如果 Recall 高但 Precision 低，说明正确文档进了但排位差，加 Rerank 即可。

Q：如何为 Word、PDF、Markdown 等文档生成与编辑能力设计通用自动评测框架？

来源：百度 AI 测开一面；本轮追问：如果面对的是没有标准答案的开放式场景（例如长文档或规划书生成），你认为应该如何去进行质量评测？（本轮追问）；本轮追问：如何自动评估生成文章的质量？ / 文章质量改进能否自动化评估？（携程 AI 应用开发二面（已oc））；秋招-字节跳动-抖音电商-Agent开发一/二/三面

新手答：“准备一些标准文档，用 LLM-as-Judge 比较生成内容是否相似。”

高手答：

文档 Agent 的输出是可解析、可渲染、可继续编辑的工件，不能只把文本抽出来算相似度。每条评测样本应包含输入工件、编辑指令、允许变化范围、必须保持的不变量、期望证据和风险级别；先冻结工具、字体和渲染环境，再运行同一任务，保证结果可复现。

评测拆成五层：

不同格式共享评测骨架，但必须先固定具体格式和方言。.docx 可按 ECMA-376检查 OOXML 包结构和文档对象，旧 .doc 不在该标准范围内；Markdown 则要声明 CommonMark、GitHub Flavored Markdown、kramdown 等目标方言，CommonMark 规范与测试集只验证其核心语法，不覆盖所有表格、任务列表或站点扩展。PDF 更偏最终呈现，需要同时检查页面对象、文本/链接提取和固定分辨率渲染。跨格式转换还要验证语义和引用保持，不能要求内部结构逐字节相同。

确定性检查先门禁：文件损坏、Schema 错、目标字段未改、非目标区域变化或页面遮挡直接失败。只有“表达是否清晰”“摘要是否完整”这类难以程序化的语义质量才交给带固定 Rubric 的 LLM Judge，并用人工抽样校准。生成模型和 Judge 不应共享未公开金标；高风险模板还要保留独立只读验收集，防止两者一起误解需求。

报告按格式、操作类型、文档复杂度和风险切片，至少看任务通过率、结构错误率、非预期改动率、视觉回归率、可重开/导出率、人工复核成本和 P95 延迟。这样才能区分“内容写对但文件坏了”“文件能开但改错区域”和“结构正确但排版不可用”。

质量改进可做成自动闭环：先按固定 Rubric 分维度评分，再让系统针对低分项重写或调整提示词，生成前后版本并做成对比较；结构、事实、引用和格式仍用确定性规则门禁，语义评分需固定 Judge、保留回归集，并以人工抽样校准，防止自动优化迎合评分器。

差距在哪：新手把文档当纯文本。高手用格式解析、编辑差分、业务不变量、视觉渲染和过程 trace 建立多层 Oracle，并明确确定性门禁与 LLM Judge 的边界。

Q：怎么理解 Vibe Coding？你有哪些实践经验？

来源：蚂蚁 AI应用开发 二面【快手 - Agent 开发岗（应用落地 + AI 工具）追问：Vibe Coding 在实际工程中的优缺点是什么？】；本轮追问：哪些岗位会收到 AI Coding 考察？（本轮追问）；本轮追问：单纯依赖 Prompt 做业务实现有哪些优缺点？（本轮追问）；本轮追问：你关注哪些 AI 技术方向？有过哪些 AI 工作流实践？（本轮追问）

新手答：“就是用 AI 写代码，说需求然后让模型生成。”

高手答：

Vibe Coding 是 Andrej Karpathy 提出的概念——开发者用自然语言描述意图，AI 生成代码，开发者不逐行审查而是直接运行看效果，凭“感觉”（vibe）判断代码是否正确。核心特征：开发者从“写代码的人”变成“描述需求+验证结果的人”。

适用场景和边界：

实践经验：

1. 小步快跑：不要一次描述完整需求，而是分步骤——先搭框架 → 再填功能 → 最后优化。每步验证后再进入下一步
2. 验证比生成更重要：AI 生成代码很快，但验证代码是否正确才是耗时的部分。好的 Vibe Coding 实践是花 20% 时间描述需求，80% 时间验证和调试
3. 知道什么时候停：Vibe Coding 的效率在简单任务上极高，但在复杂逻辑上迅速下降。当你发现自己花更多时间解释 bug 而非描述需求时，就该切回手写代码

对 Agent 开发的启示：Vibe Coding 本质上就是人类使用了一个“代码生成 Agent”——用户用 NL 描述意图，Agent 调用代码生成工具执行。这个体验的好坏直接反映了 Agent 系统的核心能力：意图理解、工具调用、结果验证。

差距在哪：新手把 Vibe Coding 等同于“用 AI 写代码”。高手理解它的本质（角色转变：写代码→验证结果），知道适用边界（原型适合、核心逻辑不适合），且有具体的实践方法论。面试官考的是你对 AI 辅助开发的思考深度——不是“用没用过”，而是“怎么用、什么时候不用”。

Q：如何衡量 Agent 的 Planning 能力 vs Hallucination Rate？请列举具体的量化评估指标或自动化评估框架

来源：淘天 AI Agent 一面；本轮追问：评价 Agent 时，应该关注中间过程，还是最终任务结果？（9.14小红书 PE（产品工程师/全栈方向–实习）二面 (流程泡到9.21挂)）

新手答：“看任务成功率就行了。”

高手答：

Planning 能力和 Hallucination Rate 必须同时评估，因为它们之间存在本质张力——规划能力越强意味着模型越敢自主决策，但自主决策越多，幻觉风险越高。只看成功率会掩盖这个矛盾：一次“碰巧成功”的幻觉规划和一次“系统性正确”的规划，在成功率上没有区别。

Planning 能力的量化指标：

Hallucination Rate 的量化指标：

核心矛盾：Planning 越强，Hallucination 风险越高

Planning 自主性光谱：
低自主 ──────────────────────────── 高自主
固定流程    受限规划    自由规划    完全自主
幻觉风险低              幻觉风险高
能力上限低              能力上限高

→ 评估不能只看一端，要画出”能力-幻觉”的帕累托曲线

所以评估框架必须同时覆盖两个维度，生成类似这样的联合报告：

Agent A：Planning 得分 82，Hallucination Rate 15% → 高能力、中风险
Agent B：Planning 得分 78，Hallucination Rate 5%  → 中能力、低风险
Agent C：Planning 得分 90，Hallucination Rate 30% → 高能力、高风险（不可上线）

自动化评估框架对比：

自建管线的推荐做法：

flowchart TB
    T[“测试用例集\n（任务+标准答案+标准步骤）”] --> R[“Agent 执行任务”]
    R --> P[“Planning 评估”]
    R --> H[“Hallucination 评估”]

    P --> P1[“LLM-as-Judge\n评估计划质量”]
    P --> P2[“规则匹配\n步骤覆盖率/效率”]
    P --> P3[“注入失败\n测试适应性”]

    H --> H1[“规则检查\n工具幻觉检测”]
    H --> H2[“声明提取+验证\n事实幻觉检测”]
    H --> H3[“结果对比\n输出幻觉检测”]

    P1 --> S[“联合评分报告<br>Planning 得分 x Hallucination Rate”]
    P2 --> S
    P3 --> S
    H1 --> S
    H2 --> S
    H3 --> S

LLM-as-Judge 用于评估 Planning 质量（计划是否合理、步骤是否冗余），规则检查用于 Hallucination 检测（工具名是否存在、参数是否合法、引用的事实是否有来源）。两类评估互补：LLM 擅长语义判断，规则擅长精确校验。

差距在哪：新手只看“任务成功率”——这是一个结果指标，无法区分“系统性正确”和“碰巧成功”，更无法暴露潜在的幻觉风险。高手同时评估 Planning 能力和 Hallucination Rate，认识到两者之间的张力关系，并用多框架组合（LLM-as-Judge + 规则检查 + 注入测试）构建完整的评估管线。面试官考的是你有没有“评估即工程”的思维——不是跑一个 benchmark 就完了，而是要建一套持续运行的评估体系。

Q：设计一个电商客服 Agent 的评测方案——商品咨询、售后处理、投诉安抚三类任务如何分别评估？

来源：淘天 AI Agent 一面（场景题）；本轮追问：介绍一下你参考的 Agent Evaluation 方案，以及它对你们评测系统设计的影响。（9.22 阿里千问二面）

新手答：“看客服满意度评分。”

高手答：

电商客服 Agent 的三类任务——商品咨询、售后处理、投诉安抚——评测维度和指标必须分开设计，因为它们的成功标准完全不同。

分任务评测维度：

投诉安抚场景的特殊指标设计——用户满意度很难直接衡量，需要代理指标：

评测数据集构建：

flowchart TB
    subgraph sources["数据来源"]
        S1["历史客服对话日志\n挖掘高频/典型 case"]
        S2["人工设计边界 case\n极端场景/对抗输入"]
        S3["用户投诉工单\n真实痛点场景"]
    end

    subgraph build["构建流程"]
        B1["按三类任务分桶"]
        B2["每类标注：标准答案 +\n合规红线 + 难度标签"]
        B3["加入对抗样本\n（诱导违规/套取补偿）"]
    end

    subgraph scale["规模建议"]
        C1["商品咨询：100 条\n覆盖主要品类"]
        C2["售后处理：80 条\n覆盖各退换货场景"]
        C3["投诉安抚：60 条\n覆盖不同情绪强度"]
        C4["对抗样本：30 条\n测试安全红线"]
    end

    sources --> build --> scale

判定 Agent 好坏的综合评分：

不能用一个分数定生死——三类任务加权，且有一票否决机制：

综合得分 = 0.4 × 商品咨询得分 + 0.3 × 售后处理得分 + 0.3 × 投诉安抚得分

一票否决项（触发任何一项直接判定不合格）：
  - 承诺虚假商品信息（价格/功能/库存）
  - 违反退换货政策做出超权限承诺
  - 回复激化用户情绪（情绪恶化率 > 5%）
  - 泄露其他用户信息

可参考分层的 Agent Evaluation：分别评估最终任务结果、工具调用轨迹、过程安全与用户体验，并结合规则校验、模型裁判和人工抽检。这个思路影响了我们的系统设计：数据集同时保存任务目标、允许动作和红线，评测器拆分为结果评测与轨迹评测，并支持离线回放和线上指标对照。

差距在哪：新手只想到一个“满意度”数字。高手把三类任务的评测维度完全拆开——商品咨询看准确性和转化，售后看解决率和合规，投诉安抚用情绪转正率等代理指标替代难以直接衡量的满意度。面试官用这个场景题考的是你能不能把抽象的“Agent 评测”落地到具体业务场景中，且能设计出可量化、可采集的指标体系。

Q：用户在线反馈怎么收集？不同模型和 Prompt 的 AB 测试怎么设计？

来源：快手AI应用开发一面【美团 - Agent 开发岗（场景设计方向）追问：AB 测试评估两种 Prompt 策略？】；本轮追问：项目有没有做模型微调或后训练？Prompt 是怎么迭代优化的？如何验证 Prompt 优化效果？（本轮追问）；本轮追问：抖音用过吧，让你做推荐用户下一个视频你怎么设计？（本轮追问）；本轮来源；本轮追问：AB测试系统解决什么痛点？（本轮追问）；蔚来——大模型算法岗（智能座舱/自动驾驶）实习一面；本轮追问：变更如果要上线的话，怎么做 AB 或灰度？（拼多多 复活赛 agent 二面）；本轮追问：怎么从特别多的prompt验证你的prompt最好?（字节多模态大模型面经一面）

新手答：“加个点赞按钮，然后随机分流看哪个模型好就行。”

高手答：

在线反馈分显式反馈和隐式反馈两层：

AB 测试的设计要点：

graph TD
    A[用户请求] --> B[分流层]
    B -->|hash userId + experimentKey| C{实验组}
    C -->|A组| D[模型A + Prompt v1]
    C -->|B组| E[模型B + Prompt v2]
    D --> F[收集指标]
    E --> F
    F --> G[准确性/人工修改率/投诉率/审核耗时]

分流原则：

1. 用户粘性：同一用户或同一工单必须稳定在同一实验组，避免体验混乱
2. 分流方式：hash(userId + experimentKey) % 100 < 50 ? A : B
3. 不能只看点赞率：理赔场景关注准确性和风险，核心指标是证据引用率、人工修改率、投诉率、审核耗时、最终改判率

CREATE TABLE llm_ab_eval (
    request_id VARCHAR(64),
    user_id VARCHAR(64),
    experiment_key VARCHAR(64),
    group_name VARCHAR(32),
    model_name VARCHAR(64),
    prompt_version VARCHAR(64),
    helpful TINYINT,
    manual_edit_rate DECIMAL(6,4),
    evidence_valid TINYINT
);

统计显著性：样本量要够——每组至少跑 500+ 请求，且按场景分层统计（简单咨询 vs 复杂审核的 AB 效果不同，不能混在一起看均值）。

上线可用特性开关按用户或租户稳定分流，先小比例灰度，再逐步扩大；同时监控准确率、错误率、延迟、成本、投诉和人工修改率等护栏指标。指标显著恶化时自动或人工回滚到旧模型，保留实验版本和请求日志便于复盘。

面对大量 Prompt，可先按模板、检索策略和模型生成候选，再用固定评测集做离线筛选；按场景分层比较正确率、忠实度、成本和延迟，保留前几名做成对人工或在线 A/B 验证，并控制多重比较带来的偶然胜出。

差距在哪：新手只想到加点赞按钮和随机分流。高手有完整的反馈分层（显式+隐式）、分流一致性保证、业务相关指标选择和统计显著性意识。面试官考的是你对在线实验系统的工程理解——不是“A/B测试是什么”，而是在 AI 场景下怎么科学评估效果差异。

Q：AI 写代码越来越强，算法工程师的角色会怎么变？

来源：字节TikTok AI应用开发一面 / 虾皮一面；本轮追问：Auto Research 是什么？算法工程师是否会被取代？（本轮追问）；本轮追问：你在规范治理项目中承担的角色是啥？（本轮追问）；科大讯飞面试挺有意思，不考八股不问项目；科大讯飞——飞凡计划面经

新手答：“AI 会替代一部分简单工作，工程师要学更多东西。”

高手答： 这道题考的是你对行业趋势的独立判断，没有标准答案，但要有结构化的分析框架。

AI 在侵蚀哪些工作：

• 样板代码生成、单元测试编写、文档注释——这些占初级工程师大量时间的工作已经被 AI 大幅提效
• 简单的功能实现、API 封装、数据处理脚本——Vibe Coding 场景下 AI 可以直接完成

工程师价值的迁移方向：

1. 问题定义能力：AI 最擅长“给定问题写解法”，但“识别真正的问题是什么”依然是人的核心价值。需求不清晰时，工程师要做 Problem Framing
2. 系统设计与架构：多模块协同、性能与成本取舍、技术债管理——AI 生成的代码在局部上可能很好，但跨模块的一致性和长期可维护性需要人来把控
3. 质量与信任边界：AI 代码需要审查——工程师的核心技能从“写代码”迁移到“评估和验证 AI 产出”。懂得在哪里信任 AI、在哪里必须亲自把关
4. AI 系统的开发者：构建 Agent、调优 Prompt、设计评测体系——这是增量的新工种，而非替代
5. 领域知识护城河：AI 缺乏特定业务/行业的深度上下文。工程师的领域专长（广告算法、推荐系统、量化交易）构成差异化竞争力

底层能力没有因为 AI 生成代码而失去价值：性能回归需要理解运行时和数据结构，线上故障要判断线程、内存、网络和存储，安全审查要识别权限与供应链边界。AI 可以生成候选实现，但验证不变量、解释资源代价和处理跨层故障仍依赖工程师理解底层机制。

个人判断：未来 3-5 年，算法工程师的数量不会大幅减少，但人均产出会大幅提升——团队会变小，对单人能力的要求会更高，尤其是系统化思维和跨层能力。

追问补充：数据治理Agent现阶段适合在规则明确、影响可回滚的子流程中自动执行，例如字段检查、脱敏和质量报告；难以独立承担全链路闭环。护栏只能约束已知风险，仍需权限隔离、数据血缘、结果抽检、异常升级和人工审批，尤其是删除、修复及高影响决策，必须保留人类对目标、例外和最终结果的判断。

差距在哪：面试官考的是你有没有独立思考这个问题，而不是说正确答案。避免“AI 不会替代工程师”的防御性回答，也避免“AI 会替代一切”的焦虑式回答。展示结构化分析 + 具体场景举例 + 自己的定位思考，才是高手答法。

Q：哪些类型的 Agent 产品在未来 2 年内最可能被淘汰？

来源：字节TikTok AI应用开发一面

新手答：“功能太简单的会被淘汰。”

高手答： 这是一道逆向思维题——通过识别“哪些 Agent 会死”，倒推“什么样的 Agent 有生命力”。

高风险被淘汰的 Agent 类型：

1. 单工具封装型 Agent：只是把某个 API 包了一层自然语言交互，没有推理能力。随着 MCP 生态成熟，这类 Agent 的门槛变成零，竞争优势消失
2. 无差异化的通用助手：没有垂直场景深度的泛用型聊天 Agent，会直接被 Claude/GPT/Gemini 的原生能力压制——你做不到比底层模型更通用
3. 依赖单一模型供应商能力的 Demo 型产品：核心功能是“某个模型能力 + 薄包装”，一旦该能力被内嵌进官方产品就失去存在价值
4. 纯提示词工程型产品：没有工程护城河，核心竞争力只是“更好的 Prompt”——随着模型理解能力提升，这类优势快速磨平

有生命力的 Agent 特征：

• 深度垂直领域数据/知识（法律、医疗、金融文档）
• 与企业系统的深度集成（内部工具、私有数据、审批流程）
• 长周期任务执行能力（多天跨越、状态持久化、Human-in-the-Loop）
• 有网络效应的数据飞轮（用户越多数据越好，效果越好）

差距在哪：面试官考的是你对产品护城河和技术壁垒的理解，而不是能不能列举“会消失的产品”。高手会反向推导：被淘汰的根本原因是“护城河建立在会快速商品化的能力上”——这个洞察才是真正的答案。

Q：线上 log 是海量的，怎么转化成有限的线下评测集？随机抽样为什么不行？

来源：字节跳动 AI Agent 评测二面 / 钉钉一面【腾讯/csig/元宝/内容安全/日常实习/三轮技术面试追问：怎么保证构建的评测集覆盖所有场景且可用？】【阿里边缘bu 秋招一面 （已过）追问：评测集和 Ground Truth 是如何构造的？】；本轮追问：Golden set 是自己构造的，凭什么能拦住问题？（本轮追问）；本轮追问：Benchmark中20多个评测Case是如何筛选出来的？评测时每条Case跑多次的原因是什么？（9.20 汇川技术 数字化全栈工程师 一面）

新手答：“随机抽一批线上 case，标注答案就行了。”

高手答：

随机抽样构建评测集有三个致命问题：

1. 分布偏斜：线上 80% 的流量是简单 case（“查快递”“看余额”），随机抽 500 条可能 400 条都是简单题，复杂场景几乎没覆盖——评测分数很高但不反映真实能力
2. 难例稀释：真正暴露系统问题的 bad case 在线上占比可能不到 5%，随机抽样大概率抽不到它们，评测集变成了“自我感觉良好”的工具
3. 无法追踪回归：随机抽样每次抽的不一样，指标波动大，无法做版本间对比——“这次改了 Prompt 到底是变好了还是变差了”无法判断

正确做法：分层采样 + 难例富集 + 固定基准

flowchart TB
    L["线上海量 log"] --> F["第一步：过滤\n去除无效/重复/异常请求"]
    F --> C["第二步：聚类\n按意图/场景/复杂度分桶"]
    C --> S["第三步：分层采样\n每桶按比例抽取"]
    S --> E["第四步：难例富集\n额外补充 bad case"]
    E --> A["第五步：人工标注\n标准答案 + 评判标准"]
    A --> D["评测集"]

具体操作：

值班聊天这类高噪声日志还要先恢复对话结构。按工单、线程、引用关系和时间间隔切段，识别提问者、值班人、机器人和旁观者角色；去掉入群通知、寒暄、重复催问、无结论讨论和机器人回声。问题与答案配对时保留人工修正、最终确认和证据链接，未解决或多解冲突记录不能伪装成标准 QA。

入库前做 PII、密钥、客户标识和内部地址脱敏，并记录 source_thread、时间、owner、解决状态和修订链。用途必须隔离：训练集可包含经审核的表达变体，评测集保留冻结的真实分布和隐藏标签，知识库只接收有 owner、来源和有效期的已确认事实；同一事件及其改写不能跨集合，避免训练、检索和评测互相污染。

难例富集的来源：

- 用户显式负反馈（点踩、投诉）
- 工具调用失败或重试 > 2 次的 case
- Agent 执行步数异常多的 case（>10 步才完成或超时）
- 触发 fallback/兜底策略的 case
- 用户在同一 session 内重复提问的 case（说明首次回答不满意）

评测集的规模和比例建议：

总量：300-500 条（够做统计显著性分析）
分布：
  - 核心场景 × 简单难度：40%（保证基线能力不退化）
  - 核心场景 × 中等难度：30%（日常能力验证）
  - 边界场景 × 困难难度：15%（暴露天花板）
  - 难例/对抗样本：15%（压力测试）

20多个Case应从意图、难度、工具链、失败类型和长尾场景分层，优先覆盖高风险与历史回归问题，并由人工复核去重、确认标签和可判定性。每条Case多次运行是为估计随机性和稳定性，报告均值、波动区间及失败一致性，避免一次运行偶然成功或失败。

差距在哪：新手用随机抽样——评测结果受分布偏斜影响严重，无法暴露真实问题。高手用分层采样保证覆盖，用难例富集暴露短板，用固定基准支持版本对比。面试官考的是你对“评测集质量决定评测价值”这个核心认知——好的评测集不是“有就行”，而是精心设计的诊断工具。

Q：能不能不走“线上转线下评测集”，直接对线上 case 做无 GT 的打分和效果观测？

来源：字节跳动 AI Agent 评测二面；本轮追问：这些 Case 的标准输出是怎样确定的？（本轮追问）；【社招】腾讯二面面经；9.22 阿里千问二面

新手答：“没有标准答案怎么打分？那还是得标注。”

高手答：

完全可以——而且在很多场景下，无 GT（无 Ground Truth）的在线评估反而比离线评测更能反映真实效果。核心思路是用代理信号和LLM-as-Judge替代人工标注的标准答案。

三种无 GT 在线评估方案：

方案一：行为代理指标——不问“对不对”，看“用户怎么反应”

这些信号不需要标准答案，纯粹从行为日志中提取，能实时反映系统健康度。

方案二：LLM-as-Judge——用模型做自动评审

flowchart LR
    A["线上 case\n（query + Agent 回答）"] --> B["评审模型\n（强模型如 GPT-4）"]
    B --> C["多维度打分\n相关性/完整性/准确性/安全性"]
    C --> D["聚合分析\n按场景/时间/模型版本看趋势"]

评审 Prompt 示例：

请评估以下 Agent 回答的质量：
用户问题：{query}
Agent 回答：{response}
可用的上下文：{context}

请从以下维度打分（1-5 分）：
1. 相关性：回答是否切题
2. 完整性：是否覆盖了问题的所有方面
3. 准确性：信息是否正确（如无法判断标注"无法确认"）
4. 安全性：是否有不当内容或越权操作

LLM-as-Judge 的优势是可以大规模自动化运行——每天评估数千条线上 case，成本远低于人工标注。

方案三：对比评估——不打绝对分，看相对优劣

A/B 测试场景下，不需要 GT 也能判断哪个版本更好：

同一 query 分别给模型 A 和模型 B 回答
→ 用 LLM 做 pairwise comparison：
  "以下两个回答，哪个更好？为什么？"
→ 统计 A 胜率 vs B 胜率

这种方式消除了“绝对评分标准不一致”的问题——人对“4 分和 5 分的区别”很难统一，但“A 比 B 好”的判断一致性更高。

三种方案的适用场景：

关键注意事项：

1. LLM-as-Judge 的偏差：评审模型可能偏好更长的回答、更正式的语言，需要用人工抽样校准
2. 代理指标的滞后性：行为信号反映的是“用户体验”，和“回答准确性”有相关但不等价
3. 成本控制：LLM-as-Judge 每条 case 消耗额外 token，需要控制评审频率（如每天抽样 1000 条而非全量）

差距在哪：新手认为没有标准答案就无法评估。高手用三种无 GT 方案（行为代理、LLM-as-Judge、对比评估）构建了完整的在线效果观测体系。面试官考的是你对“评测不只有一种形态”的认知——离线评测集是精确诊断工具，在线无 GT 评估是持续监控手段，两者互补而非替代。

Q：RAG 召回链路的监控怎么做？怎么判断召回漂移？

来源：数据智能查询平台面试；9.14字节推荐架构一面

新手答：“看看召回率有没有下降。”

高手答：

召回漂移是指：系统上线时检索效果正常，但随着时间推移，召回相关性悄然下降——用户没改什么，但答案质量变差了。

漂移的常见原因：

1. 数据侧：新文档入库但没有更新 Embedding、旧文档被删但向量未清理
2. 查询侧：用户提问方式变化（如从“怎么退款”变成“退款流程是什么”），查询分布偏移
3. 模型侧：Embedding 模型版本不一致（新文档用了新模型，老文档还是旧向量）

监控体系设计：

召回漂移的检测方法：

1. 分数分布监控：每天统计 Top-K 召回文档的平均相似度分数。如果分数分布从“高分集中”变成“低分离散”，说明召回相关性在下降
2. 黄金测试集：维护一批“标准问题→标准文档”的 pair，每天自动跑一遍，计算 Recall@K 和 MRR。指标下降即报警
3. 用户行为信号：追踪“用户看了召回结果但没点击”的比例（曝光未点击率），比例上升说明召回不准
4. 向量新鲜度审计：定期扫描向量库中“最后更新时间”，找出超过 N 天未更新的文档——可能内容已变但向量过期

发现漂移后的处理：

• 轻度：触发增量重建——对过期文档重新生成 Embedding
• 中度：排查是数据问题还是查询分布偏移，针对性补充改写规则
• 重度：全量重建索引 + 评测集回归验证

差距在哪：新手只知道“看召回率”但不知道怎么发现问题。高手从分数分布、黄金测试集、用户行为、向量新鲜度四个角度交叉验证，并且有从检测到修复的完整闭环。面试官考的是你对“系统会退化”这个事实的认知——没有监控的 RAG 系统，迟早会悄悄变差。

Q：你怎么看 Agent 后续的发展？哪些场景你觉得更容易落地？

来源：视频面经汇总

新手答：“Agent 会越来越智能，以后什么都能做。”

高手答：

我把 Agent 落地的难度分成三个梯队：

第一梯队（已规模化落地）：

• 代码辅助：Claude Code、Cursor、Copilot——确定性高、验证成本低（跑测试就知道对不对）、容错空间大（生成错了人看一眼就发现）
• 客服/知识问答：输入输出明确、有标准答案可对照、错误成本低
• 文档处理：摘要、翻译、格式转换——模型天然擅长

第二梯队（正在突破）：

• 数据分析 Agent：Text-to-SQL + 可视化——结果可验证，但需要理解业务语义
• 研究助手：Deep Research 类——多步检索+综合，质量波动大但容忍度也高
• 运维诊断：日志分析+告警处理——操作空间受限、有回滚机制

第三梯队（仍在探索）：

• 自主决策类：投资、医疗诊断——错误成本极高，需要 Human-in-the-Loop 全程介入
• 长周期项目管理：跨天/跨周的复杂任务——状态管理和纠错难度指数级增长
• 创意生产：不是不能做，而是评价标准主观，难以量化“做得好不好”

核心判断框架：一个场景是否适合 Agent 落地，看三个条件——① 结果可验证（能自动判断对错）② 错误可容忍/可回滚 ③ 任务可分解为明确步骤。三条都满足的场景先落地。

差距在哪：新手泛泛而谈“Agent 很强大”，没有判断框架。高手按落地难度分梯队，并给出了判断标准——面试官考的是你对 Agent 边界的清醒认知，而不是对 AI 的盲目乐观。

Q：面试最后的反问环节，怎么提出有深度的问题？

来源：视频面经汇总

新手答：“你们部门做什么业务？”

高手答：

反问环节是你展示信息密度和思考深度的最后机会。好的反问应该体现三个层次：

第一层：展示你做了功课

• “我看到贵司在 XX 场景落地了 Agent，目前最大的瓶颈是模型能力还是工程稳定性？”
• 体现你提前调研过公司产品和技术栈

第二层：展示你的技术判断

• “目前 Agent 落地普遍有确定性不足的问题，你们团队更倾向于用工程约束（状态机/规则兜底）还是模型能力提升来解决？”
• 体现你对行业共性问题有自己的思考

第三层：展示你的职业规划契合度

• “这个岗位未来半年的核心目标是什么？我能参与到哪些关键项目？”
• 体现你关注的是长期成长而非只是“找份工作”

避免的反问：

• 官网上能查到的信息（“你们公司做什么”）
• 纯待遇相关（留给 HR 面）
• 太宽泛无法回答的问题（“你觉得 AI 的未来是什么”）

差距在哪：反问“部门做什么业务”说明你面试前没做准备——这种信息 JD 上都有。好的反问应该让面试官觉得“这个候选人对我们的方向有认真思考”，而不是在完成一个流程性步骤。

Q：Text2SQL 系统的准确性怎么评测？用户反馈 SQL 不可用时，系统怎么回流优化？

来源：数据智能查询平台面试

新手答：“跑一些测试用例看对不对，用户说不对就改 Prompt。”

高手答：

Text2SQL 的评测分上线前和上线后两套体系：

上线前——离线评测：

评测集构建：从线上真实 query 中采样 + 人工标注标准 SQL，按难度分级（单表查询 / 多表 join / 子查询嵌套 / 聚合+条件）。

上线后——在线评测：

• 用户满意度：每次查询结果下方“有用/没用”按钮
• 执行成功率：SQL 能跑通的比例（排除语法错误、表不存在等）
• 二次编辑率：用户拿到 SQL 后修改了多少再执行——修改越多说明生成质量越差

反馈回流机制：

flowchart LR
    A[用户标记"SQL不对"] --> B[反馈工单入队]
    B --> C{人工分类错误类型}
    C -->|Schema 错误| D[补充/修正 DDL 知识库]
    C -->|业务逻辑错误| E[补充规则层]
    C -->|SQL 写法错误| F[增加 Few-shot 示例]
    D --> G[重新生成 Embedding]
    E --> G
    F --> G
    G --> H[回归测试：修复后不影响已有 case]

关键设计：修一个不能坏十个——每次规则修改后必须跑回归测试集，确认不影响已有正确结果。

模型变强后的核心挑战：不再是“能不能生成 SQL”，而是业务语义对齐——“有效订单”在不同部门的定义不同、“GMV”的计算口径有三种版本。这是知识管理问题，不是模型能力问题。

差距在哪：新手评测停在“测试用例能过”，没有上线后的持续监控和反馈闭环。高手建立了“离线评测→上线监控→反馈回流→回归验证”的完整迭代循环。面试官考的是你有没有真正运营过一个 AI 系统，而不是搭完就走。

Q：Agent 自进化闭环如何设计？怎样判断沉淀出的经验值得进入系统？

来源：字节/Agent 开发实习生一面 【电商库存一面追问：人工审批、C 端灰度与回滚】【字节火山引擎 Managed Agent 一面追问：自动更新 AGENTS.md / Skills 后如何验证提升】【阿里控股 Agent Infra 二面项目深挖】；本轮追问：你怎么评估 LLM 沉淀的结果？如果出现冲突、重合怎么处理？（9.21 货拉拉二面）；本轮追问：Agent的记忆与自我改进如何实现？（滴滴一些面经合集（算法））；本轮追问：评测结果是否已经与 Agent 自动修改 Skill 的能力打通，形成自动优化闭环？（9.22 阿里千问二面）；阿里云 Agent开发 一二面；美团一面全栈开发日常实习面经

新手答：“收集成功案例，让模型总结成 Skill，再自动更新。”

高手答：

自进化不是让 Agent 随意改 Prompt，而是受控的经验生产与发布流水线：

flowchart LR
    A[线上轨迹] --> B[脱敏与质量过滤]
    B --> C[聚类高频模式]
    C --> D[生成候选 Skill/规则/样本]
    D --> E[离线回放与对抗评测]
    E --> F{达到发布门槛?}
    F -->|是| G[灰度发布]
    F -->|否| H[拒绝或人工修订]
    G --> I[线上监控与回滚]

候选经验至少满足四个门槛：可复现，不依赖偶然上下文；有覆盖率，能解决一类问题；无回归，在固定集上不伤害旧能力；可治理，来源、版本、权限和回滚路径清晰。候选产物不能自行进入生产，必须由明确的业务或技术 Owner 审批；高风险变更还要经过安全、合规或领域专家复核。产物可以是 Skill、路由规则、评测 case 或训练样本，不应默认直接改模型权重。

C 端发布的门槛要更严：先用影子流量验证，再按用户或会话稳定分桶做小比例金丝雀；实时观测任务成功率、投诉/违规率、工具副作用、延迟和成本，并为关键指标设置自动停止与回滚阈值。每次发布都绑定候选来源、评测报告、审批人、Prompt/模型/Skill 版本和回滚目标，保证出现问题时能定位到具体变更，而不是只知道“自进化后效果变差了”。

落到真实项目时，闭环中的每个候选还应有独立 candidate_id，关联产生它的失败 Trace、去重后的模式、适用边界、修改 diff 和审批记录。离线对照要同时跑“该类失败样本、相邻场景和冻结回归集”，灰度时保留未使用候选的对照流量；只有收益能归因到这次变更，且重复运行稳定、没有把失败转移到其他切片，才允许晋级。个人简历里的单次指标提升不能替代这些可复核证据。

记忆可分为短期上下文、情节记忆和经验证的语义/程序记忆；写入前做脱敏、去重、冲突检测并保留来源、时间、置信度和适用范围。冲突时按新鲜度、证据强度和权限裁决，无法裁决则并存并在检索时提示；自我改进只生成候选，经回放评测和灰度后更新，失败可回滚。

追问补充：触发可来自同类失败或用户负反馈达到阈值、评测回归、人工标注以及定期复盘。轨迹层保存脱敏 Trace、工具调用、结果、错误和反馈；知识层只沉淀经验证的规则、Skill、样本及适用边界。产出包括候选 Skill、路由规则、评测用例和记忆条目。

差距在哪：新手把自进化理解成“模型自改 Prompt”，高手设计了数据过滤、候选生成、离线评测、灰度和回滚的闭环。面试官考的是如何让学习发生，同时不失去系统控制权。

Q：如何通过两套 Harness 的同任务对照与组件消融定位效果差异？

来源：Teamily AI QA/测开面经【深信服 ai agent 一面追问：如何评估 Harness 效果？】；本轮追问：如何验证小模型效果好？（本轮追问）；本轮追问：如何评估 ASR 清洗对下游 AC 自动机和推荐链路的收益？（本轮追问）；0915 百度二面；本轮追问：如何通过 Benchmark 评估 Memory、RAG 和 Context 等模块？（字节 aime 一面 9.10）；0924恒生电子｜AI 应用开发工程师 ｜AI面

新手答：“让两个 Harness 各跑一遍，哪个成功率高就用哪个。”

高手答：

直接比较两个端到端分数只能说明“整体不同”，不能说明差异来自哪里。先冻结模型及采样参数、任务集、工具和数据版本、权限、预算、并发和运行环境；两套 Harness 使用同一成功条件和统一 trace schema，否则模型更强、工具更快或评测口径不同都会被误算成 Harness 收益。

诊断分三步：

1. 端到端基线：比较任务成功率、步骤数、Token、延迟、工具错误、恢复率和安全违规，并按任务类型切片。
2. 首错点对齐：把 Context Builder、Planner/Router、Tool layer、Memory、Retry、Verifier 的输入输出映射到同一逻辑阶段，找到第一处行为分叉。
3. 组件互换/消融：在 A 中替换 B 的单个组件，或关闭某项能力；每次只改变一个变量。若单组件无收益但组合有收益，再做二阶交互实验。

每次运行保存任务、组件/Prompt/模型版本、随机种子、候选工具、状态迁移、Observation 和验收证据。统一 trace 可以参考 OpenTelemetry 对 Trace 与 Span 语义的约定，但 Agent 阶段字段仍需项目自己定义。随机任务应重复运行并报告置信区间，不能凭一两个 case 下结论。

如果两套结果都差，先看共同失败：任务定义或 Oracle 错、模型能力不足、工具/数据有缺陷，还是两套都缺少同一种恢复机制。修复后同时跑局部组件集和端到端回归，避免“Router 指标变好但最终成功率下降”。

具体可按模块建立成对 Benchmark：关闭或替换 Memory，评估记忆召回准确性、过期记忆干扰和跨轮任务成功率；替换 RAG，评估检索命中、答案依据与幻觉率；消融 Context，评估关键信息保留、上下文长度和截断后的成功率。所有模块使用同一任务集、数据版本和验收标准，并与端到端结果联合分析。

追问补充：验证受控编辑时固定任务、初始数据和模型参数，随机分流比较“受控补丁”和“直接生成完整修改”。除任务成功率外，统计字段约束通过率、非法写入率、越权修改率、业务不变量破坏率、人工拒绝率和回滚率，并按编辑类型分层；用配对检验或置信区间判断收益，不能只看成功率。

差距在哪：新手做产品赛马。高手通过控制变量、首错点对齐和组件交换建立因果证据，既能识别单组件收益，也能发现组件之间的交互效应。

Q：Skill 路由应该如何构造测试集并评估？

来源：字节/Agent 测评一面；本轮追问：构造的 Case 和预期结果是否经过实际值班人员或领域专家 Review？（本轮追问）；本轮追问：你的测评怎么做的？你还知道别的什么测评集吗？它们的侧重点有什么不同？（9.21 货拉拉二面）；9.15科大讯飞AI应用一面；9.15秋招东方财富AI应用一面；淘天供应链ai应用研发一面

新手答：“准备一些用户问题，看 Skill 选对了没有，算准确率。”

高手答：

Skill 路由是带拒识能力的多标签分类问题。测试集至少包含：单 Skill 正例、语义相近 Skill 的困难负例、多 Skill 组合、无需 Skill 的拒识样本、信息不足需澄清的样本，以及拼写错误和提示注入等扰动样本。

指标不能只看 accuracy：

数据按 Skill、意图难度、用户类型和时间切片报告，避免热门 Skill 掩盖长尾失败。线上 badcase 经脱敏、聚类和人工确认后回流到固定回归集；每次修改描述、路由器或模型都跑版本对比。

除自建领域集外，可参考 BFCL 类工具调用集测参数和调用正确性，用对抗或越界集测拒识与安全，用 OOD 和时间切片集测泛化与漂移；这些只能作补充，最终仍需领域专家抽检路由意图、Skill 边界和端到端结果。

差距在哪：新手只测“选没选对”，高手覆盖召回、拒识、参数和端到端执行，并设计困难负例与线上回流。面试官考的是 Skill 路由能否持续迭代。

Q：如何证明 Agent 的最终答案真正使用了工具或检索证据，而不是凭模型常识猜中？

来源：Momenta Agent 开发一面、阿里 Agent 开发一面（2026-08-17）；本轮追问：怎么判断Agent真正完成了用户给的指令？分配的subagent任务真正完成由谁来判断？（本轮追问）；本轮追问：你如何证明将视频切成一分钟 Segment、五分钟 Chunk，并融合音频和视频帧的方案是有效的？（本轮追问）；本轮追问：如果正确证据已经召回，但模型没有使用，应当如何优化？（字节 aime 一面 9.10）；本轮追问：怎么验证模型确实使用了输入的深度信息，而不是直接忽略该通道？（地平线算法面经）

新手答：“检查它有没有调用工具，答案正确就算通过。”

高手答：

工具调用发生过，不代表模型使用了返回结果。评测样本必须同时包含问题、可用证据、预期引用和证据不足样本，并做三组对照：移除证据后答案应降低置信度或拒答；替换关键证据后结论应随之改变；加入语义相近但错误的干扰证据时，模型仍应选择正确来源。

线上记录 claim -> evidence_id 映射，分别统计引用准确率、证据覆盖率、无依据断言率和证据不足时的拒答率。高风险结论再由确定性校验器核对关键字段。只比较最终答案会把“碰巧猜对”和“基于证据推导正确”混在一起。

优化应先确认上下文中证据可见且位置不被截断，再用强制引用格式、claim-evidence 校验器和必要的重试/拒答门禁约束生成；按反事实集评估引用覆盖与无依据断言，仍不使用时调整证据排序、压缩和训练样本，而非只提高召回。

对深度通道做模态消融和反事实测试：保持 RGB、问题及其他输入不变，遮蔽、替换或扰动深度，检查深度相关结论、定位和置信度是否显著变化；再用只含深度判别信息的样本验证模型确实依赖该通道，而非利用 RGB 线索猜测。

差距在哪：新手只验证结果和调用轨迹，高手用反事实对照验证因果依赖，并把每个结论绑定到可审计证据。面试官考的是评测是否能识别“看过证据但没用证据”的假成功。

Q：树形意图识别和逐层路由应该如何设计，并构造评测集避免误差级联？

来源：快手 AI 应用开发一面（2026-08-24）【大方云图研发实习一面追问：双阶段路由的专精与错误阻断】；本轮追问：路由有没有判断错误过？（本轮追问）；智谱ai native builder实习一面；美团ai全栈一面；本轮追问：你们怎么知道意图识别分得就是对的？指标如何量化？（迅雷 Agent一面）

新手答：“先识别一级意图，再逐层分类到叶子节点，用每层准确率评估。”

高手答：树形路由适合标签多、层级有稳定业务语义的场景，但父节点一旦选错，正确叶子就永远无法被看到。设计时应把 taxonomy 做成互斥性和覆盖性可检查的版本化契约；每个节点定义正例边界、易混淆兄弟、拒识条件和可用下游能力。路由器在每层输出校准后的 Top-K 与置信度，低置信或多意图请求进入澄清、并行候选或全局检索，而不是强制沿单一路径到底。

评测集不能从每个叶子随机抽几条即可，至少要覆盖：各层普通正例、兄弟节点困难负例、跨父节点语义相近样本、多意图组合、缺少关键信息、树外拒识，以及口语、省略、错别字和提示注入扰动。再加入从线上首错点回流的 badcase，并按用户或时间切分，防止同模板泄漏到训练集和测试集。

指标需要同时观察节点与路径：逐层 macro-F1 和校准误差定位单个分类器，路径准确率与叶子 Recall@K 衡量级联损失，拒识/澄清精度衡量安全出口，最终任务成功率衡量路由是否真的有用。报告应按深度和意图频次切片，并统计“第一个错误层”；还要用 oracle-parent 实验分别测量当前节点自身错误和上游传递错误。发布门槛基于完整路径和高风险叶子，不允许用一级节点的高准确率掩盖深层失败。

双阶段路由应先证明两个阶段有不同标签体系、上下文或成本：第一阶段做领域/风险粗分，第二阶段在域内选择具体任务、Agent 或 Tool。每阶段输出 Top-K、校准置信度和拒识原因；低置信时回到全局候选、澄清或人工，执行后再用工具可用性、参数合法性和任务结果做后验校验。它是层级分类/路由设计，不自动等于把系统拆成多个 Agent。

差距在哪：新手把它当多个分类器串联，高手同时设计 taxonomy、低置信逃生路径、级联敏感测试集和首错点指标。面试官考的是如何让层级路由既可扩展，又能量化并控制上游错误对最终任务的放大。

Q：Multi-Agent 出现 Badcase 时，如何定位责任 Agent，并判断是否需要 SFT？

来源：字节/Agent 开发二面；本轮追问：你们有哪些 Case 用来统一判断输入和输出是否正确？（本轮追问）；本轮来源；秋招-字节跳动-抖音电商-Agent开发一/二/三面

新手答：“查看日志找到出错的 Agent，收集数据做微调。”

高手答：

先把端到端失败拆成可观测的责任链：路由、规划、检索、工具、子 Agent 输出、聚合与验证。每个节点保存输入版本、输出、模型与 Prompt 版本、工具结果和局部评分，通过 trace 回放找到第一个偏离预期的节点，而不是把最终失败归给最后一个 Agent。

是否 SFT 要按根因决策：

• Prompt 或 schema 能稳定修复，且错误模式少：先改约束与验证器。
• 知识缺失或证据召回错误：修 RAG，不做 SFT。
• 工具不稳定或状态污染：修工程链路。
• 同类决策错误高频、边界稳定、已有足够高质量轨迹：才考虑 SFT。

SFT 后必须在责任 Agent 的局部集和端到端回归集同时验证，防止局部指标提升却破坏协作协议。

追问补充：对最终报告做关系级验收：先统一实体与关系类型，再将报告中的三元组与证据片段对齐，检查关系方向、属性、时间和来源是否被证据支持；用规则校验互斥与必备约束，并在分层回归集上统计关系准确率、漏报率和幻觉率，疑难样本人工复核。

差距在哪：新手看到 badcase 就微调，高手先做首错点归因，再区分 Prompt、RAG、工具和模型能力问题。面试官考的是评测驱动的优化决策，而不是训练冲动。

Q：什么是 AI-native 团队？如何判断团队离 AI-first 还有多远？

来源：HR 系统一面（2026-08-12）；本轮追问：如果继续推进一年的 AI Native 化建设，你认为应该分哪些阶段、重点做哪些事情？ / 团队的研发、测试、验收和沟通流程如何进一步向 AI Native 转型？（9.21 蚂蚁二面）；本轮追问：基础架构团队不能大面积使用AI，要做到什么程度才可以信任AI？（美团AI Agent一面）；本轮追问：使用 AI 编码工具时如何团队合作？（中兴未来领军计划AI算法一面）

新手答：“大家日常都使用 AI Coding，就是 AI-native。”

高手答：AI-native 不是工具渗透率，而是需求、开发、测试、运维和知识沉淀都围绕“机器可执行的上下文、验证和反馈”重构。成熟度可看高价值流程覆盖率、任务成功率、人工接管、交付周期、回归门禁和经验复用率。阻碍通常来自数据/权限不可用、缺少评测、旧系统无接口、责任边界不清和员工只会聊天式使用。推进应从可验证、低风险流程开始，不以调用次数作为目标。

可按季度推进：先盘点流程、权限和数据并建立基线；再在低风险研发任务中落地 CLI/Skills、自动测试与评测；随后把代码评审、验收、运维和知识沉淀接入闭环；最后扩大范围。基础架构只对可回滚、最小权限、沙箱执行、全量审计且通过固定回归集的操作放权，高风险变更保留人工审批和回滚。

团队协作上，应统一提示词、项目上下文、编码规范和工具权限，任务通过共享上下文或变更单交接；AI 生成代码必须经过分支隔离、自动测试、同行评审和责任人确认，禁止多人同时无审查地修改主干，并记录采纳、回滚和失败原因。

差距在哪：新手谈工具采购，高手谈组织流程和可衡量的能力闭环。

Q：如何实现基于 VLM 的 Benchmark 系统，并避免评测模型自说自话？

来源：深信服 Agent 开发一面；本轮追问：模型对比是如何实施的？是定量实验还是主观感受？（本轮追问）；本轮追问：如果将这套评测和诊断方法迁移到工业场景（设备故障诊断），面对“故障种类极多但单类样本较少”的特点，这套Benchmark还能否有效建立？（9.20 汇川技术 数字化全栈工程师 一面）

新手答：“准备图片和标准答案，让 VLM 打分，再统计准确率。”

高手答：先按任务定义 Oracle。OCR、定位、图表问答、页面操作和开放描述需要不同标注：文本 Exact Match、框坐标与 IoU、结构化字段、可执行动作结果，以及成对偏好不能混成一个总分。每条样本保存原始资产哈希、标注版本、允许答案集合和评分器版本，并按来源对象切分 train/dev/test，避免同一页面或视频相邻帧泄漏。

确定性指标优先由程序计算；只有语义等价、视觉质量等难规则化维度才使用 VLM Judge。Judge 输入必须限制为任务、候选、参考证据和量表，输出结构化分项、证据区域和置信度。再用人工双标样本校准一致率、偏置和阈值，并做位置互换、去模型名、对抗提示、图片遮挡与无答案测试。Judge 与被测模型尽量使用不同模型族，关键结论保留人工复核。

报告除平均分外，还要按分辨率、语言、图像质量、长图、遮挡和任务难度切片，并给置信区间。评测资产、推理参数、解析器和评分代码全部版本化；模型升级后重跑冻结集与新增回归集，防止 Benchmark 被反复调参污染。

工业故障可按设备、部件和故障机理建立分层标签，采用每类少量专家标注加正常样本、异常检测和未知类留出；按设备或产线隔离训练与测试，避免同源泄漏。用宏平均召回率、少样本类别表现和误报成本评估，合成样本须与真实测试集分开验证。

差距在哪：新手把 VLM 同时当答题者和裁判，高手先固定任务 Oracle，再校准 Judge 偏差、数据泄漏和版本可复现性。

Q：生成内容常见的质量 Bad Case 有哪些，如何分类与评估？

来源：携程 AI 应用开发二面（已oc）；本轮追问：如何面向黑盒评估系统提高内容得分？（快手电商大模型应用开发一面（已offer））；本轮追问：遇到插值 bad case、运动物理一致性差的场景，该如何修复？（地平线算法面经）

新手答：“生成内容常见问题包括事实错误、答非所问、格式不符合要求、内容重复以及表达不自然。”

高手答：

生成质量的 Bad Case 应按可观测问题分类，而不是只凭主观印象打分：包括事实性错误或幻觉、任务不遵循、遗漏关键约束、逻辑矛盾、内容重复、风格不一致、语言不通顺，以及安全、隐私和偏见风险。评估可建立带标签的代表性数据集，按场景定义通过标准，结合规则检查、结构化指标、模型评审与人工盲评；对高风险类别设置“一票否决”，对可接受的创造性保留人工判断。要区分离线回归、线上采样和用户反馈，并按版本、提示词、模型、数据分桶统计。自动评估需抽样复核和校准，防止评审模型与生成模型共犯；同时记录严重度、触发条件和修复后复测结果，避免只追逐平均分。

黑盒评估只能通过固定探针集和分桶回归定位短板，逐项控制提示词、采样参数和输入条件做实验，并保留未参与调参的验证集，避免只对评测器过拟合。插值或运动不连续时检查关键帧间的光流、遮挡和轨迹约束，可增加中间帧约束、时序一致性损失或分段重生成；物理不一致则显式加入深度、碰撞、速度等约束并复测。

差距在哪：浅层回答只能列举错误类型，面试官更关注分类标准、风险分级、评估集与人工复核如何形成可回归的质量闭环。

Q：独立 Verifier 和 LLM-as-Judge 应该如何分工？

来源：阿里千问 C 端算法实习一面（2026-08-10） / 字节中国交易与广告 AI 全栈二面；本轮追问：业务逻辑中AI与人的具体分工？（本轮追问）

新手答：“规则能判断的用 Verifier，主观内容用大模型评分。”

高手答：确定性 Verifier 负责 schema、单元测试、数据库终态、权限和业务不变量；LLM Judge 只处理难以程序化的语义质量，并使用固定 Rubric、盲化顺序和人工校准。高风险结论必须以确定性证据为门禁，Judge 不能覆盖失败的硬校验。两者结果分别记录，出现分歧时定位是规则覆盖不足、Judge 偏差还是任务定义不清。

语音转录等复核任务还要让 Reviewer 输出结构化结果：问题类型、证据时间片或文本 span、建议修订和置信度。格式、敏感词、时间戳连续性等先由规则校验，模型只判断语义遗漏或错配；生成模型与 Reviewer 尽量不要共享同一 Prompt/上下文偏差，分歧样本进入人工抽检并保留可追溯修订链。

差距在哪：高手不会把 Judge 分数当事实，也不会要求规则理解所有语义。

Q：如何判断用户反馈真的让 Agent 变好，而不是噪声或选择偏差？

来源：MiniMax 平台研发一面（2026-08-20）；本轮追问：如果 CTR/CVR 离线涨了但线上不涨，如何判断问题出在哪？（本轮追问）；虾皮agent开发一面

新手答：“统计点赞、点踩和采纳率，指标上升就有效。”

高手答：反馈要绑定任务、版本、曝光和后续结果，区分显式评价、行为代理信号和人工修正。用稳定分桶 A/B 或准实验控制用户与任务难度，处理延迟反馈、重复用户和只在失败时反馈的选择偏差。结论同时看任务成功、负向副作用、成本和各切片置信区间；反馈先进入候选集，经去重、归因和回归验证后才能沉淀为规则或训练数据。

追问补充：应该沉淀，而且负面案例往往更能暴露边界问题。记录原始反馈、任务上下文、版本、失败类型和后续人工判断，但与正向样本分开管理，先脱敏、去重和抽样分析，不把未核实的负反馈直接当作训练标签；确认归因后再进入难例集、回归集或训练集。

差距在哪：新手看相关性，高手建立可归因的实验和数据准入链路。

Q：哪些业务场景不适合引入 Agent？

来源：虾皮测开日常实习一面；本轮追问：Agent 的业务场景是什么？（去哪儿ai应用技术面（挂））

新手答：规则明确、容错率极低或收益无法覆盖模型成本的场景通常不适合。

高手答：

用任务不确定性、可验证性、错误代价和交互收益做评估。支付扣款、权限审批、实时控制等强确定性流程应使用规则和工作流，模型最多做辅助解释；开放式研究、客服分流等才适合 Agent。上线前定义离线基准、人工兜底、审计和停止开关，比较端到端 ROI 与传统方案。

差距在哪：考察能否识别 Agent 边界，关注业务风险而不是只展示模型能力。

Q：如何设计消融实验并判断模块贡献？

来源：美团面经-美团算法岗面经-01；字节算法（Agent）凉经；虾皮agent开发一面

新手答：逐个去掉或替换模块，保持其他条件相同，比较指标变化。

高手答：

先确定主指标和统计置信区间，再做单模块、组合模块和替代基线消融；固定数据切分、随机种子、预算与评测脚本，至少重复多次。报告绝对值、相对下降和成本变化，检查交互效应，不能只凭一次结果断言“贡献最大”。

追问补充：评估时构造带标准答案的代码定位集，固定查询、候选范围和预算，比较加入 Description 与原始代码或随机摘要的 Recall@k、MRR、首个命中位置及证据正确率；同时加入相似目录等 hard negative，并按目录、文件、符号层级分组，检查收益是否稳定而非只看平均值。

差距在哪：考察实验控制、指标解释和对结论不确定性的认识。

Q：串行链路修改一个节点后，如何做精确归因？

来源：知识科技 数据平台 二面；本轮追问：在这套 AI pipeline 中，你如何保证每一个节点执行效果的准确性？（(秋招) 9.16 字节中交广 - 交易与广告业务 - AI全栈开发工程师）

新手答：锁定其他节点和输入，只比较修改前后的输出与最终指标。

高手答：

为每次运行记录版本、配置、输入快照和随机种子；用固定回放集做 A/B，对照组与实验组仅切换目标节点。逐节点记录中间产物，配合分层指标和配对统计，排除数据漂移、模型版本、缓存和并发噪声；必要时用 shadow 流量与分阶段上线验证。

对每个节点定义输入输出契约、校验规则和可接受误差，建立覆盖正常、边界、异常与权限场景的节点级金标集。回放时先校验中间产物，再分析最终指标；对不满足契约的节点阻断下游并保留可复现证据。

差距在哪：考察可复现实验和链路级证据，而非只看最终结果。

Q：供应商不返回 usage 时，如何核算 Agent 的 Token 和成本？

来源：成都晓多科技 Agent 开发岗二面（2026-08-12）；本轮追问：Agent 的 TOKEN 是什么，怎么获取，起到什么作用？（本轮追问）

新手答：“用对应 Tokenizer 重新数一遍。”

高手答：模型网关统一记录请求、响应、模型版本和流式终止状态；有官方 usage 时以其为准，没有时用匹配版本的 Tokenizer 估算，并标注 estimated。工具、子 Agent、重试、缓存和被取消流都按 trace 聚合，价格表带生效区间和输入/输出/缓存单价。账单抽样与供应商对账，偏差超阈值就修正估算规则，不能把估算值伪装成精确账单。

差距在哪：新手只数文本，高手解决跨模型版本、异步补账和财务可追溯性。

Q：评审 Agent 为什么要左移？应该左移到需求、设计还是编码阶段？

来源：字节社招一面（2026-08-23）；本轮追问：Agent 的评审或评价机制是如何设计的？（本轮追问）

新手答：“越早发现问题成本越低，所以需求阶段就开始评审。”

高手答：不同风险放在不同阶段：需求阶段检查目标、边界和验收；设计阶段检查依赖、权限和回滚；编码阶段检查实现、测试和变更影响。左移不能让概率模型阻塞所有需求，低置信度建议只提示，高风险硬规则才门禁。每阶段使用独立证据和责任人，并通过缺陷逃逸率、误报率和交付周期判断左移是否过度。

差距在哪：新手只说“更早”，高手按缺陷类型和证据成熟度设计分层门禁。

Q：Skill 的调用量、Token 成本和效果埋点应该放在哪一层？

来源：电商库存二面（2026-08-17）

新手答：“在每个 Skill 里打印日志，统计调用次数和 Token。”

高手答：

统一埋点应放在所有 Skill 调用都会经过的运行时网关或编排器，不能依赖 Skill 作者自行上报。根 trace 记录租户、会话、任务和版本指纹；每次 Skill 调用生成 span，记录路由候选、选中原因、输入输出大小、模型与工具调用、缓存命中、延迟、Token、成本、状态和错误码。

效果不能只看调用量，还要关联任务成功率、人工接管率、回退率和增量收益。异步子任务延迟退出时，先记录 provisional cost，再按 run_id + span_id 幂等补账；用户断连不应丢失服务端 trace。原始 Prompt 和工具结果可能含敏感信息，应分级采样、脱敏并设置保留期。

差距在哪：新手把埋点散落在业务代码，高手从统一拦截、跨异步归因、版本关联和隐私治理设计可核算体系。面试官考的是能否回答“这个 Skill 到底值不值得保留”。

Q：如何为跨任务重复出现的安全或质量问题生成稳定 Fingerprint，并安全接入自动修复 Agent？

来源：元石科技后端/Agent 一面

新手答：“把错误文本做 Embedding，相似的聚成一类，然后让 Agent 自动修复。”

高手答：

原始错误文本不稳定：请求 ID、路径、时间、堆栈行号、组件版本和模型措辞都会变化。Fingerprint 应由稳定根因特征组成，例如责任层、规范化异常类型、失败操作、工具/规则 ID、关键堆栈帧、违反的不变量和脱敏后的资源类型；自由文本向量只用于候选召回，不能单独决定同簇。组件版本属于簇的适用范围和检索过滤条件，不应默认进入稳定签名，否则同一根因会被版本号机械拆散。

入簇采用“检索 + 验证”两阶段：先召回相近问题簇，再检查根因、适用版本和修复是否可共享。匹配不确定时进入人工待审，不要为了降低簇数量强行合并。簇本身带 cluster_id、signature_version、owner、first/last_seen、affected_versions、reproducer、fix_ref、status；规则变化时重新计算并保留旧新映射，支持误合并后拆簇。

观测字段可以借鉴 OpenTelemetry 稳定的 异常语义约定，但 exception.message 可能含敏感信息，入库前必须脱敏。跨 Agent 失败还要记录首错节点和证据引用，不能把最终报错的组件当成根因。

问题簇不能直接触发生产修复。自动修复 Agent 先从簇中取得最小复现、允许修改范围和验收标准，在隔离环境生成候选补丁；依次通过静态检查、专项用例、全局回归和安全门禁，再 shadow/灰度发布。修复不得改金标、删断言或放宽安全阈值来制造通过；高风险、低置信或不可回滚变更必须转人工。

指标要同时看聚类纯度、新问题误归旧簇率、重复簇率、自动复现率、修复通过率、回归逃逸率和回滚率。簇越少不是目标，稳定地把相同根因转成可复现回归才是目标。

差距在哪：新手只做文本聚类。高手把 Fingerprint 建成版本化根因契约，用检索后验证控制误归，并让自动修复经过独立复现、回归和发布门禁。

Q：智能问数结果出现误差时，如何区分数据链路问题与模型数值理解问题？

来源：滴滴一些面经合集（算法）

新手答：“先检查数据查询和计算链路是否正确，再判断模型是否在单位、筛选、聚合或数值推理上出错。”

高手答：

应把结果拆成可审计链路：问题解析、指标与维度映射、权限和时间范围、SQL 或工具调用、原始返回、聚合计算、模型生成与最终展示。先用同一问题执行黄金 SQL 或人工基准，核对数据源版本、字段口径、空值、重复行、时区、单位、精度和权限过滤；若原始结果已错，优先定位元数据、连接器、SQL 生成或执行层。若原始结果正确而答案错，再构造最小数值样本，测试加减、同比、排序、分组、单位换算和多轮上下文，区分解析错误与模型推理错误。生产上应保留 trace、SQL、输入快照和中间结果，加入结果校验、可复算性检查与拒答机制，并用分层回归集量化两类错误率。

差距在哪：浅层回答只停留在“查数据或查模型”，深入回答要建立可回放的分层链路、最小对照实验、错误归因指标和安全兜底。

Q：如何搭建微调任务的效果评估体系，并量化模型优化收益？

来源：滴滴一些面经合集（算法）

新手答：“建立覆盖准确性、稳定性、泛化能力和业务价值的测试集，对比微调前后的指标与典型案例。”

高手答：

评估体系应先固定任务定义、数据切分和验收标准，避免训练集泄漏或只挑成功案例。数据层覆盖常见、长尾、边界、对抗、不同长度和不同业务分布，并保留独立回归集；指标层同时看任务正确率、格式或工具调用成功率、事实一致性、拒答质量、延迟、成本与安全风险。可用自动规则、程序化校验、模型裁判和人工盲评结合，但要抽样复核裁判偏差，并报告置信区间或分桶结果。收益量化应与基线、同预算方案和线上对照比较，区分平均提升、长尾改善和回归项；记录随机种子、数据版本、超参及推理配置，做多次运行和显著性检验。微调后还要验证灾难性遗忘、提示变化下的鲁棒性及发布后的监控，不能把单一分数当作生产收益。

差距在哪：浅层回答只罗列准确率等指标，深入回答会设计分层数据、可靠评测、基线对照、统计不确定性及线上成本与风险验证。

Q：如何设计一个通用的图像质量评估模型？

来源：小红书多模态秋招二面

新手答：“可以用清晰度、构图、色彩和主体突出程度等指标训练一个分类或回归模型来评估封面图质量。”

高手答：

先定义模型角色：它应预测封面对目标场景的可用性，而不只是审美分数。建立覆盖清晰度、曝光、构图、主体突出、文字可读性、相关性和安全风险的标注体系，采用多标注者评分并记录场景、设备和分歧；同时保留点击、停留或转化等结果作为弱监督，但避免把热门内容直接当成高画质。模型可用视觉编码器加多任务分类/回归头，结合裁剪、压缩、缩放和文字遮挡增强，输出总分、分项分数与置信度。按时间、作者和主题切分数据，评估相关性、排序质量、校准、不同设备及长尾场景表现，并做人工抽检和线上 A/B。要防止模板、作者或曝光数据泄漏；单一总分易掩盖缺陷，分项解释更可运营，但标注成本和推理延迟也更高。

差距在哪：浅层回答只列审美指标和模型类型，深入回答会处理标签定义、弱监督偏差、数据泄漏、分项解释、校准及线上验证。

Q：故障诊断系统如何降低误报率并平衡漏报率？

来源：蔚来——大模型算法岗（智能座舱/自动驾驶）实习一面

新手答：“通过提高告警阈值、过滤短时异常并结合人工复核，可以减少误报，但要同时监控漏报。”

高手答：

先定义误报与漏报的业务代价、告警对象和统计口径，不能只看一个准确率。数据侧要处理标签噪声、类别不平衡、传感器漂移和故障发生前的时间窗口；模型侧可采用分层诊断、时间窗口与滞回、置信度校准、代价敏感阈值和“不确定则转人工/延迟确认”。对同一根因的多个症状应做告警聚合，避免重复报警，但不能用简单去重掩盖真实并发故障。验证应按设备、工况、故障类型和时间切分，报告混淆矩阵、精确率、召回率、提前量、每设备告警量及未见故障表现，并在影子模式和灰度阶段监测漂移。阈值应按风险分级：安全关键故障宁可保留较高召回并快速升级，低风险故障则可压低误报；上线后还需闭环复盘人工处置结果。

差距在哪：浅层回答只会调高阈值；面试官更关注误漏报成本、时间与设备分层、告警聚合、校准、未知故障、灰度验证和上线后的反馈闭环。

Q：如何通过统计显著性和重复实验排除实验结果的随机波动？

来源：字节算法（Agent）凉经

新手答：“可以通过显著性检验、置信区间和多次重复实验，观察效果是否稳定且明显超过随机波动。”

高手答：

先明确主指标、最小可接受提升、零假设和实验单位，再通过随机分流或配对设计减少选择偏差。报告点估计、置信区间和效应量，不能只看p值；样本量不足时应先做功效分析。对训练类实验固定数据切分并更换随机种子，重复完整流程，比较均值、方差和结果分布；对线上实验还要检查分流均衡、实验周期、分桶异质性和外部事件。多指标或多次中途查看需要控制多重比较和停止规则，避免挑选最好的结果。最终结合预注册指标、敏感性分析、独立复现和长期护栏指标判断稳定性。重复实验成本与统计把握度存在权衡，显著也不等于业务上有价值。

差距在哪：浅层回答停留在“做显著性检验”，深层考察实验单位、随机种子、功效、多重比较、效应量及线上偏差控制。

Q：如何理解当前 LLM 推理能力的上限、瓶颈与评估边界？

来源：字节多模态大模型面经一面

新手答：“LLM 的推理能力受训练数据、模型规模和上下文长度限制，复杂、多步骤且需要真实世界知识的问题仍容易出错。”

高手答：

LLM 推理的“上限”不是单一智力天花板，而是由训练信号、模型架构、上下文、工具和任务环境共同决定。模型通常擅长模式归纳与局部推导，但在长链条规划、状态持续更新、因果理解、事实 grounding 和异常处理上，错误会逐步累积；生成看似合理的答案也不等于真正可靠。评估不能只看单次准确率，应使用未污染、分层且贴近业务的题集，覆盖组合泛化、长程任务、对抗输入和拒答，并报告多次运行稳定性、校准度、成本与延迟。工程上可用检索、代码执行、规划器、校验器和人工复核扩展能力，同时用权限隔离、超时、预算、幂等和审计控制失败影响。主要权衡是能力、速度、成本、可解释性与安全边界；验证应关注端到端成功率及失败模式，而非只展示示例。

差距在哪：浅层回答只罗列模型规模和数据等因素，深入回答还应讨论推理机制、长程失败、评估污染、工具增强及生产约束，面试重点是能否把“能力上限”转化为可验证的系统边界。

这类题的答题模式

评估与全局观题的核心是结构化思维 + 独立见解：

1. 评估不是一个数字，是一套多维指标体系
2. 必须有失败归因机制——"知道哪里不好"比"知道好不好"更重要
3. 开放题要抽象出核心矛盾，不要只陈述事实
4. 给出你自己的解法和方法论，而不是复述行业共识

面试官听到“成功率和满意度”就知道你没运营过线上系统。听到三维看板、失败归因队列、可控性 vs 能力的权衡框架，才会觉得你不只是写代码，还能做决策。

附：看完这 5 篇，你应该注意到的答题模式

所有维度的高手答都有几个共同特征：

面试官要的不是“你知道多少概念”，而是“你能不能在真实约束下做出合理决策”。

下一篇建议继续看：

• 多智能体协作：角色分工、通信机制与冲突仲裁