AI Agent 与 AIGC 评估面试题

本文档包含 16 道 AI Agent 测试与 AIGC 内容质量评估方向的高频面试题，覆盖 Agent 路径与工具调用、多轮对话、规划能力、评估框架，以及文本/图像/代码/多模态内容的评估方法。

一、AI Agent 测试（8题）

Q1: 什么是 AI Agent？Agent 测试与普通 LLM 应用测试有什么区别？

答案：

AI Agent 是一类能自主感知、决策、行动来完成目标的 AI 应用。跟普通 LLM 应用最大的区别是：普通 LLM 应用通常是「一次问答」，Agent 是「多步推理 + 调用工具 + 跟环境交互」来完成复杂任务，比如自动订机票、写代码并提交 PR、运营一个独立的客服流程。

跟普通 LLM 应用相比，Agent 测试的复杂度跳跃式上升：

测试维度更多。单次回答只测内容；Agent 要测决策路径、工具调用、状态管理、错误恢复、终止条件，几乎是测一个微型软件系统。

执行不可预测。每次跑同一个任务可能走完全不同的路径，不能用固定脚本验证步骤一致性，要看「最终目标是否达成」和「过程是否合理」。

成本和时间放大。一次 Agent 任务可能要跑几十步、调用多个工具、消耗几万 Token，测试效率远低于单轮 LLM。

失败模式多样。可能是规划错（plan 不合理）、工具调用错（参数填错）、循环（陷入无限重试）、提前放弃、被中间步骤的错误信息误导，每种都要专门测。

环境依赖复杂。Agent 调用真实工具时要测 Mock 模式（用模拟工具）和真实模式（连真工具），评估覆盖度也差别很大。

简言之，Agent 测试是 LLM 测试 + 系统测试 + 强化学习评估的混合体，需要更体系化的方法。

Q2: Agent 决策路径与执行步骤如何评估？

答案：

评估 Agent 的执行过程，常见做法是「记录 + 比对 + 打分」。

Agent 多步执行的核心循环（ReAct 模式）和评估关注点：

完整 Trace 记录。每次 Agent 运行都要记录：每一步的思考（Thought）、工具选择（Action）、工具参数、工具返回（Observation）、下一步决策。LangSmith、LangFuse 这类 LLMOps 工具能自动收集。

路径合理性评估。对每个步骤判断「是不是必要的」「有没有更好的选择」「参数填得对不对」。可以用 LLM-as-Judge 自动判断，也要人工抽审。

终态评估。任务最终是否达成、达成质量怎么样（完整度、正确性、副作用）。这是最直接的成功指标。

效率指标。完成任务用了几步、消耗多少 Token、调用工具几次。同样目标用更少步骤完成意味着 Agent 更聪明。

错误恢复能力。中途遇到错误（工具失败、信息不全）时是否能正确判断并调整策略，而不是死循环或放弃。

可重现性。同一任务多次跑，路径分布是否合理，关键决策是否稳定。

实战中通常组合用：终态评估做硬指标（任务成功率），路径评估做诊断（找问题），效率指标做优化方向。

Q3: 工具调用（Function Calling）准确性怎么测？

答案：

工具调用是 Agent 的核心能力，准确性要从几个维度测：

工具选择准确性。给定任务，Agent 应该调用哪个工具，是否选对了。比如查天气应该用 weather_api 而不是搜索引擎。

参数生成准确性。工具的参数是否正确填充，类型是否对、必填字段有没有缺、值是否合理。比如订机票的日期格式是否正确、目的地代码是否对应。

调用时机准确性。该调用时调用、不该调用时不调用。常见错误是该查信息时直接编造、信息已经够了还反复调用。

并发与顺序。多个工具按什么顺序调，能不能并发，依赖关系是否正确处理。

错误处理。工具返回错误（参数不对、服务不可用、限流）时，Agent 如何处理是否合理。

测试方法：

构建工具调用测试集，每条测试用例包含任务描述、预期工具、预期参数（或参数 Schema）、预期顺序。

跑 Agent 后对比实际调用和预期，按维度算准确率。可以用 JSON Schema 校验参数，用 LLM-as-Judge 判断语义合理性。

Mock 工具便于评估，避免真实工具的副作用和不确定性影响测试结果。

回归用例库要持续扩充，把线上发现的 bad case 都加进去。

工具上 OpenAI、Anthropic 都提供官方 Function Calling 评估示例，业界也有 BFCL（Berkeley Function-Calling Leaderboard）这类基准。

Q4: 多轮对话与记忆能力如何测试？

答案：

Agent 通常需要维护长期记忆和短期记忆，测试要覆盖几个层面：

短期记忆（会话内）。当前对话内的信息是否被正确利用，包括用户偏好、历史回答、中间结论。常见测试是在对话中先告诉一个事实，几轮后引用看是否记得。

长期记忆（跨会话）。用户之前会话中的信息（如个人偏好、历史交易记录）是否被检索和使用。测试时模拟多个会话，验证后续会话能正确读取历史。

记忆更新与覆盖。新信息覆盖旧信息时是否正确更新（"我搬家了，新地址是…"）。

记忆隔离。多用户场景下，记忆是否严格隔离，不能让 A 用户看到 B 用户的内容（涉及隐私和合规）。

记忆容量边界。记忆超过存储或检索容量时如何处理，是 LRU 淘汰、总结压缩，还是简单截断，对结果影响多大。

错误纠正。用户纠正 Agent 之前的错误信息时，Agent 是否更新记忆并避免再犯。

测试设计上常常用「场景脚本」方式：定义一个 5-10 轮的对话脚本，每一轮给定输入和预期检查项，跑完整个脚本验证记忆使用是否正确。

工具上 Mem0、LangGraph、LlamaIndex 都提供记忆管理的标准实现，测试时用同样的标准评估集对不同记忆策略做对比。

Q5: Agent 的规划能力（Planning）如何评估？

答案：

规划能力指 Agent 把复杂任务拆解成子任务并按顺序执行的能力，是高级 Agent 的核心。评估方法：

任务分解质量。给一个复杂目标，看 Agent 拆出来的子任务是否完整、是否合理、是否可执行。可以让 LLM-as-Judge 对照参考分解打分，或人工评审。

依赖关系正确性。子任务之间的依赖（哪些必须先做、哪些可以并行）是否被正确识别。

执行顺序合理性。Agent 实际执行的顺序是否符合依赖、是否高效。

应变能力。中途出现意外（某个子任务失败、新信息出现）时，Agent 是否能重新规划。

终止判断。任务完成后是否能正确判断"已完成"，避免无意义的额外步骤；任务无法完成时是否能正确放弃并给出说明。

评估方法：

设计典型规划任务集（旅行规划、研究报告、代码重构），人工标注合理的子任务和顺序作为参考。

跑 Agent 后用 LLM 对比 Agent 的 plan 和参考 plan，从分解度、合理性、完整性维度打分。

跟踪执行过程，看实际行为是否跟 plan 一致；不一致也要看是否合理（动态调整）。

业界基准如 PlanBench、AgentBench 都有规划任务的标准评估，可以借鉴方法学。

Q6: 主流 Agent 评估框架（AgentBench、SWE-bench、AppWorld）有哪些？

答案：

这些基准的共同特点是「目标可验证 + 多步推理 + 工具使用」，但侧重点不同。选择时要结合自己 Agent 的应用场景：做编程类用 SWE-bench，做客服类用 τ-bench，做通用助手用 GAIA。

注意几点：

公开榜单只是参考。基准跟实际场景往往有差距，自家场景的评估集才是上线决策的依据。

避免数据污染。模型训练时可能见过基准数据，分数虚高。优先选最近发布或定期更新的基准。

榜单结果要看得失。同一模型在不同基准上表现差别巨大，单一基准不能代表整体能力。

Q7: Agent 失败模式有哪些？如何分析？

答案：

Agent 失败模式比单轮 LLM 复杂得多，常见的几类：

规划错误。任务分解错（漏了关键步骤、加了多余步骤）、依赖识别错、顺序错。

工具误用。选错工具、参数错、不该用时用、该用时不用。

死循环。同一步骤反复跑、相互依赖的步骤来回切换、对错误信息反复尝试同样修复。

幻觉行为。编造工具不存在的功能、假装已经执行了某个步骤、引用不存在的中间结果。

提前放弃。任务远没完成就声明"无法完成"、对临时错误反应过度。

上下文丢失。多步执行后忘了原始目标、忘了用户的关键约束、忘了之前的中间结论。

错误传播。前面一步的错误（如理解错误的需求）导致后面所有步骤都偏离。

输出格式不符合下游要求，导致下一步无法处理。

分析方法：

完整 Trace 记录是基础，没有 trace 几乎没法分析。

按失败模式打标签，统计每类占比，优先治理高频问题。

人工抽审典型 case，找根本原因（Prompt 设计、模型能力、工具描述、环境问题）。

针对性改进：Prompt 优化、工具描述改进、加 Guardrail（如最大步数、循环检测）、必要时换更强模型。

把失败 case 加到评估集，做回归测试避免再犯。

业界常用工具如 LangSmith、Langfuse 都支持按 trace 打标签和统计分析，是 Agent 调试的必备。

Q8: 如何测试 Agent 在真实生产环境的稳定性？

答案：

生产环境的 Agent 稳定性测试要覆盖几个维度：

负载与并发测试。模拟生产规模的并发请求，看 Agent 调度、工具调用、模型 API 是否吃得消。

成本与限流测试。统计单次 Agent 任务的平均 / P99 成本，验证成本上限保护、用户级限流、Token 预算控制是否生效。

外部依赖故障。模拟工具 API 故障、超时、限流、返回异常，看 Agent 是否能优雅降级或失败重试。

模型 API 故障。模型 API 限流、超时、返回错误时的行为，是否能切换到备用模型、是否能给用户友好提示。

长时间运行稳定性。让 Agent 跑长任务（几十步以上），看是否有内存泄漏、状态污染、token 累积等问题。

恶意输入鲁棒性。Prompt 注入、越狱尝试、超长输入、特殊字符的处理。

数据竞争。并发 Agent 之间是否会读写同一份资源（用户数据、共享缓存），是否有竞态问题。

降级与回滚。当新版本表现退化时，是否能快速回滚 Prompt、模型版本、工具实现。

可观测性。每次失败能否快速定位原因，trace 是否完整，日志是否详细。

测试时建议用影子流量（Shadow Traffic）：把生产流量复制一份给新版本跑，结果不返回给用户，观察新版本表现，是 Agent 上线前的标准做法。

二、AIGC 内容质量评估（8题）

Q9: AIGC 内容质量评估有哪些维度？

答案：

AIGC 内容评估要从用户视角和系统视角综合看，常见维度可以归成几组：

正确性。内容是否符合事实、是否准确、是否完整。文本看事实性，代码看能否运行 + 是否符合需求，图像看是否符合描述。

相关性。是否回应了用户的实际需求，没有跑题。

质量。语言表达是否流畅自然、风格是否得当、结构是否清晰。图像看构图、清晰度、美学；视频再加时间维度的连贯性。

安全性。是否违反内容安全规范（涉政、涉黄、暴力、歧视）、是否泄露隐私、是否传播错误信息。

一致性。多次生成同一类内容风格是否一致、上下文中信息是否前后一致、跨语言/跨格式是否保持核心信息。

多样性。重复请求是否能生成多样化内容，避免模板化。

实用性。内容是否能直接被用户使用，比如代码能跑、配方能照做、文案能用上。

成本与延迟。生成耗时和成本是否在可接受范围。

不同业务对维度的优先级不同：内容创作类看质量和多样性，事实问答看正确性，编程辅助看实用性，企业 To B 应用看安全性和一致性。

Q10: 文本生成质量评估方法有哪些？BLEU、ROUGE、BERTScore 各适用什么场景？

答案：

文本生成评估方法可以分自动指标和人工评估两大类，自动指标里又分基于 n-gram 的传统指标和基于模型的现代指标。

实战经验：

机器翻译领域 BLEU 仍是标准，但近几年 COMET 这类基于神经网络的指标更受认可。

摘要任务 ROUGE 仍常用，但不能光看 ROUGE 高就认为质量好。

通用 LLM 应用更推荐 BERTScore + LLM-as-Judge 组合，前者快，后者准。

涉及高价值决策（产品上线、模型选型）必须有人工评估兜底，自动指标只是过滤器。

注意所有自动指标都是「跟参考的相似度」，对开放生成（多样的合理回答）评估能力有限。

Q11: 什么是 LLM-as-Judge？怎么做？有什么注意点？

答案：

LLM-as-Judge 是用一个（通常更强的）大语言模型作为裁判，对另一个模型的输出打分或判断的评估方法。是当前最流行的 LLM 评估方法之一，因为它能自动评估开放生成、灵活定义评估维度、成本远低于人工。

典型做法：

设计评分 Prompt。明确角色（资深评估员）、评估维度（准确性 / 相关性 / 流畅度等）、评分尺度（1-5 分 / 通过-失败）、输出格式（JSON 含分数和理由）。

成对对比（Pairwise）或单条评分（Pointwise）。Pairwise 让裁判选 A 或 B 哪个更好，对相对排序更准；Pointwise 给绝对分数，对横向对比更友好。

引用参考。如果有标准答案或参考材料，喂给裁判一起判断，比单看模型输出准很多。

汇总与统计。批量评估后看分数分布、平均分、置信区间，单条结果有偶然性。

注意点：

裁判偏置。LLM 裁判有"位置偏置"（偏好放在前面的选项）、"长度偏置"（偏好更长的回答）、"风格偏置"（偏好自己输出风格的回答）。可以通过随机化位置、控制长度、轮换裁判模型缓解。

裁判能力上限。裁判能力低于被评对象时评不准，常用 GPT-4 / Claude Sonnet / Opus 这类前沿模型当裁判。

成本与速度。每条评估都调一次 LLM，规模大时成本高、速度慢，要做缓存和并发。

人工对齐。重要场景下要做人工抽审，看裁判结果跟人工判断的一致性（Cohen's Kappa 等指标）。

复现性。固定裁判模型版本和温度（建议 0），让评估可复现。

业界常用框架 G-Eval、MT-Bench、AlpacaEval 都基于 LLM-as-Judge，可以参考它们的 Prompt 设计。

Q12: 主观评测的样本量、评分尺度、评分员一致性怎么设计？

答案：

人工评测虽然慢和贵，但对关键决策不可替代，设计时要考虑几个要点：

样本量。统计意义上至少 30-50 条才能看出显著差异，关键决策建议 100-300 条；如果想做细分维度（按问题类型、用户群体）分析，每个细分至少 30 条。

评分尺度。常见有：

• 二分类（通过/失败）：简单稳定，适合上线门槛判断。
• 5 点李克特量表（1-5 分）：信息量更大，适合细粒度对比。
• 成对对比（A/B/平手）：相对判断更准，适合模型选型。
• 多维度评分：同时打多个维度（准确、相关、流畅）的分，能看到不同维度的得失。

评分员选择与培训。专业领域的内容（医疗、法律）必须找领域专家，普通内容可以用经过培训的标注员。培训要给标准、给示例、做小批量预试。

评分员一致性。多个评分员独立打分，算 Cohen's Kappa（二分类）或 Krippendorff's α（多类）评估一致性。一致性 < 0.6 说明评分标准不清楚或任务太主观，要重新培训或调整标准。

盲测。让评分员不知道哪条是哪个版本生成的，避免偏见。

成对评估优于绝对评分。让评分员对比 A 和 B 谁好，比给绝对分数更稳定，结论更可靠。

工具上 Label Studio、Doccano、Prolific 都能做评测项目管理；公司内部通常用众包平台或自建标注平台。

Q13: 图像生成质量怎么评估？常用指标？

答案：

图像生成评估要兼顾「跟描述符不符」「画面好不好看」「内容安不安全」几个维度，方法分自动和人工两类。

自动指标：

人工评估：

通常分维度打分（描述符合度 / 美学 / 真实感 / 创意度），或做成对对比（A 和 B 哪张更好）。涉及风格、艺术性的评估强依赖人工。

特殊场景测试：

文字渲染。中文、英文文字是否能正确生成（Stable Diffusion 早期版本有"鸡爪英文"问题）。

人体结构。手、脸、肢体是否正确，避免六指、扭曲等典型问题。

风格一致性。系列图（同人物多场景）是否能保持人物特征一致。

安全合规。是否会生成涉黄、暴力、未成年敏感内容、版权 IP 等，需要做内容安全审核。

效率与成本。生成时间、显存占用、单张成本。

工具上 Diffusers、ComfyUI 都能跑评估脚本，工业上常配合人工评估平台（如开源的 Open Image Eval）。

Q14: 代码生成评估有哪些 benchmark？怎么用？

答案：

代码生成的好处是「能跑就能验证」，所以很多评估都是基于代码执行的。主流 benchmark：

评估指标常用 pass@k：模型生成 k 个候选，至少 1 个通过测试就算成功。pass@1（一次性写对）最严格。

使用注意事项：

数据污染问题。模型训练时可能见过 benchmark 数据，分数虚高。优先用持续更新的 benchmark（LiveCodeBench）或私有评估集。

不要只看 pass@k。代码风格、可读性、安全性、效率也很重要，需要额外指标或人工审。

跟实际场景的差距。benchmark 多是独立的算法题或函数，跟实际开发中改大型代码库的需求差很多，SWE-bench 这类基于真实 issue 的更接近实际。

成本。复杂 benchmark（SWE-bench）单次评估要几十美元，规模有限。

落地建议：上线前用 benchmark + 自家场景评估集组合，重点关注自家场景；持续监控线上代码生成的接受率（用户接受了百分之多少）作为最终质量信号。

Q15: 多模态输出（图文、视频）怎么评估？

答案：

多模态输出（如图文混合、视频）评估比单模态复杂，核心是「单模态质量 + 跨模态一致性 + 整体体验」三维度并重。

图文混合（如图文社交内容、PPT 生成）的评估要点：

文本质量。流畅度、信息量、语气符合度，按 LLM 评估方法走。

图像质量。清晰度、美学、风格一致性，按图像评估方法走。

图文一致性。图片是否符合文本描述、文本是否合理引用图片、图文风格统一。

排版与结构。整体布局是否合理、长度是否合适、信息层次是否清晰。

视频生成（如 Sora、Veo、Kling）的评估更复杂：

帧质量。每一帧是否清晰、是否符合描述。

时间一致性。物体在不同帧间是否保持一致（人不能突然变脸、车不能凭空出现）。

运动合理性。物体运动符合物理规律、镜头运动符合预期。

时长与节奏。是否符合时长要求、节奏是否合理。

声画同步（如带音轨）。声音是否跟画面对得上。

主观评估。视频特别依赖人工评估，因为时间维度的主观体验很难自动量化。常见做法是设计评分维度量表，让评估员看完整段视频打分。

工具上图文评估常用 CLIP Score 衡量图文一致性、LLM-as-Judge 综合判断；视频评估常用 VBench、EvalCrafter 这类专门 benchmark。

实战中多模态评估的人工成本远高于单模态，建议建立分层评估机制：自动指标做初筛，关键内容人工把关。

Q16: AIGC 评估自动化与人工评估如何组合？

答案：

自动化评估和人工评估各有优劣，理想做法是分层组合：

组合的几个关键设计：

分层数据集。冒烟集（小、快、严）+ 回归集（中、稳）+ 全量集（大、慢、深）。不同阶段跑不同集。

自动指标优先做粗筛。能用代码或简单规则判断的（格式、Schema、关键词）先过滤明显问题。

LLM-as-Judge 做主观评估代理。日常迭代用 LLM-as-Judge 替代部分人工，定期校准它跟人工的一致性。

人工评估覆盖关键决策。版本切换、模型选型、对外宣称指标必须有人工评估支撑。

线上反馈持续回流。把用户反馈的 bad case 加到评估集，让评估集越来越接近真实分布。

预算与节奏管理。人工评估贵且慢，不能每次迭代都做；自动评估便宜但有偏差，不能完全依赖。两者频率和样本量按预算和迭代速度规划。

工具组合上常见的是：DeepEval / Promptfoo 跑自动指标 → LangSmith / Langfuse 收集 trace → 内部标注平台做人工评估 → 数据中台汇总分析。