10 Agent 评测面试题

1、如何评估一个 Agent 是否优秀？

评估一个 Agent 是否优秀，应重点关注它在真实任务中的完成质量、稳定性和可控性，而非仅关注语言表达是否自然。

一个好的 Agent，通常要同时满足这些条件：

• 任务完成能力：用户给出明确目标后，Agent 能完成对应操作，比如查订单、生成报告、检索文档、修改代码。
• 过程可控：能够根据任务上下文判断工具调用时机、工具选择、参数生成和后续执行路径。
• 结果可信：回答基于事实，有必要时能给出引用来源。尤其是 RAG 场景，应避免在资料不足时生成无依据内容。
• 成本和速度可接受：如果一个任务需要几十轮模型调用，即使最终成功，过高的延迟和成本也会影响工程可用性。
• 安全边界清楚：遇到删除数据、发送邮件、付款、修改权限这类高风险操作，要做权限校验和用户确认。
• 表现稳定：同类问题的输出质量应保持一致；Prompt、模型或工具描述小幅变化后，不应出现大面积能力退化。

常见评估维度包括：

任务完成率
答案正确性
工具调用正确率
规划合理性
安全合规
延迟和成本
用户满意度
稳定性

在 LangChain / LangGraph 项目里，建议结合 LangSmith 或自建评测平台，把每次运行的输入、输出、工具调用、节点路径和耗时都记录下来。这样既能评估最终答案，也能分析 Agent 的实际执行过程。

2、如何设计 Benchmark 任务？

Benchmark 的作用，是用一批固定测试用例稳定评估 Agent 的能力。

设计 Benchmark 时，不宜只覆盖简单问题，也不宜只选择极端难题。测试集应覆盖真实业务中的常见路径、复杂路径和异常路径。

常见任务类型包括：

• 基础问答：测试 Agent 能否理解问题并给出正确回答。
• RAG 问答：测试它是否能够检索正确文档，并基于资料回答。
• Tool Calling：测试它是否会选择正确工具、生成正确参数、处理工具返回。
• 多步骤任务：测试它是否能规划步骤，比如先查用户信息，再查订单，再生成结论。
• 异常任务：测试工具失败、检索为空、参数缺失、权限不足时，Agent 是否能合理处理。
• 安全任务：测试越权操作、敏感信息、危险工具调用时，Agent 是否会拦截或请求确认。

每条测试用例最好包含输入、预期行为、预期工具、评分标签等信息：

{
  "id": "case_001",
  "input": "帮我查一下订单 O123 的物流状态",
  "expected_tools": ["get_order", "get_logistics"],
  "expected_answer": "订单物流状态应基于物流接口返回",
  "expected_behavior": "如果缺少权限，应拒绝查询",
  "tags": ["tool_calling", "order", "normal"]
}

Benchmark 还要区分难度：

简单任务：一轮回答即可完成
中等任务：需要一次工具调用或一次检索
复杂任务：需要多步规划、多工具协作或异常处理

如果是 LangGraph 项目，还可以评估执行路径是否符合预期。比如这个任务是否应该经过 retrieve 节点，是否应该进入 human_approval 节点。

3、如何评估 Tool Calling 能力？

Tool Calling 能力评估，不应仅依据最终答案判断，还要检查工具调用是否符合预期。

可从以下维度评估：

• 工具触发是否合理：比如“查订单状态”必须调用工具，“什么是订单状态”通常不需要。
• 工具选择是否正确：用户问物流状态，应该调用 get_logistics，而非调用 search_docs。
• 参数生成是否准确：订单号、用户 ID、时间范围、枚举值这些字段都要正确。
• 调用顺序是否合理：有些任务要先查订单是否存在，再查物流；调用顺序错误会影响后续执行。
• 工具结果使用是否正确：回答内容应与工具返回结果一致。例如工具返回“订单已取消”，最终回答不应写成“订单正在配送”。
• 工具失败处理是否合理：工具超时、报错、返回空时，Agent 应说明原因、重试或走降级，而非生成无依据结果。

参数正确性的例子：

{
  "order_id": "O123"
}

常见指标包括：

工具调用触发准确率
工具选择准确率
参数正确率
调用顺序正确率
工具结果使用正确率
工具失败处理正确率

在 LangChain 中，可以通过 tracing 记录每次 tool call。在 LangGraph 中，如果工具执行放在 ToolNode 或独立节点里，可以统一统计工具名称、参数、返回值、错误和耗时。

4、如何评估规划能力？

规划能力指的是 Agent 面对复杂任务时，是否能够拆解步骤，并按合理顺序完成。

比如用户说：

帮我分析这个客户最近的投诉原因，并给出处理建议。

合理的规划可能是：

1. 查询客户基本信息
2. 查询最近工单
3. 查询订单和售后记录
4. 总结投诉原因
5. 给出处理建议

评估规划能力，可以关注以下方面：

• 步骤是否完整：是否遗漏关键步骤，比如没有查询工单就直接总结投诉原因。
• 顺序是否合理：有依赖关系的步骤不应随意排列，比如要先拿到用户 ID，再查订单。
• 是否避免多余步骤：规划复杂度应与任务复杂度匹配，能一步完成的任务不应拆成多步。
• 是否能根据中间结果调整计划：如果查不到客户信息，应该停止或要求补充信息，而非继续查询订单。
• 是否能够处理异常分支：工具失败、权限不足、结果为空时，是否有备用路径。

在 LangGraph 中，规划能力可以通过实际执行路径来评估。因为节点和条件边都很清楚，可以直接看 Agent 是否走了正确路径。

例如：

正常路径：intent → get_customer → get_tickets → summarize
异常路径：intent → get_customer → missing_info_response

如果任务应该进入异常路径，但 Agent 仍然继续调用后续工具，通常说明规划或路由存在问题。

5、如何评估推理能力？

推理能力评估的是 Agent 是否能够基于已有信息做出正确判断，而非简单复述资料。

常见推理场景包括：

• 多条件判断
• 因果分析
• 规则匹配
• 多文档综合
• 工具结果对比
• 风险判断

比如：

规则：订单金额超过 5000 且用户等级为 VIP，可以走快速审批。
输入：订单金额 6800，用户等级 VIP。
问题：是否可以快速审批？

Agent 应该得出“可以”，并说明依据是金额和用户等级都满足条件。

评估时重点看：

• 事实使用是否正确：是否忽略金额、等级、时间、状态等关键输入。
• 规则理解是否正确：是否把“同时满足”误解成“满足任意一个”。
• 结论和过程是否一致：推理过程与最终结论不应相互矛盾。
• 是否能处理边界情况：刚好等于阈值、缺少字段、规则冲突等情况都需要单独测试。
• 是否避免编造前提：资料里没有某个条件时，应该说明信息不足，而非自行补充前提。

对于复杂推理，可以让评测用例包含标准答案和关键依据：

{
  "input": "订单金额6800，用户等级VIP，是否可快速审批？",
  "expected_answer": "可以",
  "required_evidence": ["金额超过5000", "用户等级为VIP"]
}

评估时不一定要求文字完全一样，但关键结论和依据必须对。

6、如何评估多 Agent 协作效果？

多 Agent 协作评估，不仅要看最终答案，还要看协作过程是否合理。

多 Agent 系统一般会有不同角色：

Planner：负责拆解任务
Researcher：负责检索资料
Coder：负责写代码
Reviewer：负责检查结果

评估时可以关注以下问题：

• 角色分工是否清楚：每个 Agent 是否只处理自己负责的任务。如果 Reviewer 介入需求修改、Planner 介入代码实现，说明协作边界不清晰。
• 信息传递是否完整：上一个 Agent 的结论、约束、错误信息，是否正确传给下一个 Agent。
• 协作顺序是否合理：应该先 Research 再 Coding，不应在未读取资料前直接生成方案。
• 冲突如何处理：多个 Agent 给出不同结论时，系统是否有仲裁机制。
• 是否有重复劳动：多个 Agent 如果都在查同一批资料，成本和延迟都会变高。
• 最终效果是否优于单 Agent：多 Agent 的价值应体现在质量、稳定性或可维护性提升上。如果准确率没有提升，反而延迟更高、成本更大，就不适合引入。

在 LangGraph 中，多 Agent 协作可以用图来编排。每个 Agent 可以是一个节点，也可以是一个子图。评测时可以重点检查：

节点执行顺序
消息传递内容
是否进入仲裁节点
是否出现循环
每个 Agent 的贡献

多 Agent 的关键指标包括任务完成率、协作轮数、冲突率、重复调用率、总成本和最终答案质量。

7、如何评估 Memory 效果？

Memory 效果评估，重点看记忆是否被正确写入、正确召回、正确使用。

可以拆成几个环节评估。

写入是否正确

并非所有内容都适合进入长期记忆。临时闲聊通常不需要保存，用户明确偏好、项目背景、长期事实才值得保存。

例如：

用户：以后请用中文回答。

这类语言偏好适合保存。

但如果用户说：

我今天下午三点有个会。

是否保存要结合业务需求判断，不应把所有临时信息都写入长期记忆。

召回是否准确

新会话中，系统是否能根据用户身份召回相关记忆。比如用户之前说“回答要简洁”，新会话里系统回答是否更简洁。

使用是否合理

召回了记忆，不代表一定要使用。比如用户偏好“简洁回答”，但这次明确要求详细解释，应以当前请求为准。

更新和遗忘是否正常

如果旧记忆已经过期，或者和当前信息冲突，系统是否能更新、覆盖或忽略。

隐私是否安全

不应把 A 用户的记忆召回给 B 用户，也不应把敏感信息随意放进 Prompt。

常见指标包括：

记忆写入准确率
记忆召回准确率
无关记忆召回率
记忆使用正确率
记忆更新成功率
跨用户污染率

在 LangGraph 中，短期记忆通常通过 checkpointer 评估，长期记忆通过 Store 评估。可以分别测试同一 thread 内的连续性，以及不同 thread 下基于 user_id 的跨会话召回。

8、如何做自动化评测？

自动化评测是将测试集、运行流程和评分规则固定下来，在定期任务或每次变更后自动执行。

基本流程如下：

准备测试集
  ↓
批量运行 Agent
  ↓
记录每次执行结果
  ↓
自动评分
  ↓
生成评测报告
  ↓
和历史版本对比

测试集里每条用例应该包含输入、预期结果、预期工具、评分标准和标签。

示例：

{
  "id": "case_001",
  "input": "查询订单 O123 的物流",
  "expected_tool": "get_logistics",
  "expected_args": {"order_id": "O123"},
  "expected_answer_contains": ["物流", "O123"],
  "tags": ["tool", "order"]
}

评分方式可以灵活组合：

• 规则评分：适合判断工具名、参数、JSON 格式、是否包含关键词等。
• 人工评分：适合复杂问答、开放式回答，准确但成本高。
• LLM-as-Judge：用另一个模型做裁判，判断回答是否正确、是否基于资料、是否遗漏重点。适合大规模初筛，但重要场景最好配合人工抽检。
• 业务指标评分：比如任务是否完成、用户是否转人工、工单是否关闭。

在 LangChain / LangGraph 体系里，可以用 LangSmith Dataset 管理测试集，用 Evaluator 评估结果，并追踪每次运行的链路。

LangGraph 的节点化结构还有一个优势：可以单独评估某个节点。比如只评估检索节点、工具路由节点、人工审核节点，而非每次都端到端运行完整流程。

9、如何做回归测试？

回归测试的目的，是确保修改 Prompt、模型、工具、RAG、Memory 或工作流后，没有把原本正常的能力改坏。

Agent 系统特别需要回归测试，因为它的行为受很多因素影响：

Prompt 改一句
模型版本换一个
工具描述调整
Chunk 切分变化
TopK 修改
记忆召回策略改变

这些变化都可能让输出、工具选择或执行路径发生变化。

回归测试通常包含以下步骤：

• 维护固定测试集：把历史线上问题、典型业务场景、曾经出过 bug 的案例都加入测试集。
• 保存基准结果：每个稳定版本都要保存评测结果，作为 baseline。
• 变更后自动运行：每次修改 Agent 配置、Prompt、工具或图结构后，都跑一遍测试集。
• 对比关键指标：观察任务成功率、工具调用准确率、RAG 命中率、Token、延迟是否出现明显变化。
• 重点分析失败样本：整体指标稳定，不代表关键业务场景没有问题。支付、权限、客服高频问题等场景不应退化。
• 设置通过门槛：比如任务成功率不低于某个值，高风险工具误调用必须为 0。

常见对比项：

任务成功率是否下降
工具调用准确率是否下降
RAG 命中率是否下降
平均 Token 是否上升
平均延迟是否变长

通过门槛可以这样设置：

任务成功率不低于 95%
高风险工具误调用必须为 0
平均成本上升不超过 10%

在 LangGraph 项目中，回归测试还可以检查执行路径是否变化。比如一个请求原本应该进入 human_approval 节点，改完后跳过了，这就是严重回归。

10、Agent 常见评测指标有哪些？

Agent 常见评测指标可以按能力分组。

任务效果指标

任务完成率
答案正确率
用户满意率
问题解决率
转人工率
追问率

这些指标反映 Agent 最终是否解决了用户问题。

工具调用指标

工具选择准确率
参数正确率
工具调用成功率
工具超时率
工具误调用率
工具结果使用正确率

这些指标适合评估 Tool Calling 能力。

RAG 指标

Recall@K
Precision@K
MRR
命中率
引用准确率
幻觉率

这些指标适合评估知识库问答。

Memory 指标

记忆写入准确率
记忆召回准确率
无关记忆召回率
记忆使用正确率
跨用户污染率

这些指标适合评估短期记忆和长期记忆。

规划和流程指标

平均步骤数
最大步骤数中断率
循环率
异常分支处理成功率
人工确认触发准确率

这些指标能看出 Agent 流程是否合理。

性能和成本指标

平均延迟
P95 / P99 延迟
首 Token 延迟
输入 Token
输出 Token
单次任务成本
模型调用次数

安全指标

越权拦截率
高风险工具误调用率
敏感信息泄露率
Prompt Injection 防护成功率

实际项目里，不会所有指标都同等重要。客服 Agent 更关注问题解决率和转人工率；代码 Agent 更关注任务完成率和回归测试；RAG Agent 更关注检索命中率和引用准确性；自动执行类 Agent 更关注安全和工具调用正确率。