Agent 面试通关 / 05

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

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

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

来源：腾讯 Agent 岗终面

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

高手答：

我们有一个三维看板：

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

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

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

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

来源：腾讯 Agent 岗终面

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

高手答：

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

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

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

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

Q：你觉得 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：你觉得 AI 工具最大的帮助场景是什么？

来源：腾讯 Agent 应用开发一面

新手答：“写代码快。”

高手答：

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

具体来说有三个层次：

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

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

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

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

来源：腾讯 Agent 应用开发一面

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

高手答：

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

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

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

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

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

来源：腾讯 Agent 应用开发一面

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

高手答：

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

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

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

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

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

来源：腾讯 Agent 应用开发一面

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

高手答：

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

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

具体来说有三个难点：

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

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

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

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

来源：蚂蚁集团智能体与大模型应用二面

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

高手答：

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. 归因分析：回答错误时，先查检索结果——如果检索到了正确文档但回答仍然错，说明是生成环节的问题；如果根本没检索到正确文档，说明是检索环节的问题

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

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

来源：Agent 开发面试 30 题

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

高手答：

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

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

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

评测集设计：

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

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

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

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

来源：Agent 开发面试 30 题

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

高手答：

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

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

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

第二步：看执行链路日志

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

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

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

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

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

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

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

来源：Agent 开发面试 30 题

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

高手答：

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

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

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

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

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

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

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

3. 隐式依赖链断裂

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

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

差距在哪：新手列的都是显而易见的风险。高手指出了三个“Demo 阶段看不到、上线后才暴露”的隐性风险——长尾输入、状态漂移、隐式依赖链断裂，且每个都有具体的防范方案。面试官考的是你有没有把 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：了解最近 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 原生应用、上下文工程、协议标准化、端侧混合推理五个方向做了结构化梳理，每个方向都说清了对开发者的实际影响。面试官用这道开放题考的是你的行业视野和技术敏感度——不是背新闻，而是能从趋势中提炼出对自己工作的影响。

这类题的答题模式

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

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

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

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

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

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

下一篇建议继续看：

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