10 Agent评测面试题

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

评估一个 Agent 是否优秀，不能只看它回答得像不像人，而要看它能不能稳定完成任务。

一个好的 Agent 一般要满足几个条件。

第一，任务完成率高。

用户给它一个明确任务，它能不能完成。比如查订单、生成报告、检索文档、修改代码，不是只回答几句漂亮话。

第二，过程可靠。

Agent 是否会选择正确工具、传正确参数、按合理步骤执行。不能一会儿查知识库，一会儿乱调用工具。

第三，结果可信。

回答是否基于事实，是否有引用来源，是否避免编造。尤其是 RAG 场景，不能资料里没有也硬答。

第四，成本和速度可接受。

如果一个任务要跑几十轮模型调用，虽然最后成功了，但成本太高、延迟太长，也不算好。

第五，安全边界清楚。

遇到删除数据、发送邮件、付款、权限修改这类高风险操作，是否会要求确认，是否会做权限校验。

第六，稳定性好。

同类问题不能今天答对、明天答错；Prompt 或工具稍微变化后，也不应该大面积退化。

所以评估 Agent，至少要从这几个维度看：

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

在 LangChain / LangGraph 项目里，建议结合 LangSmith 或自建评测平台，把每次运行的输入、输出、工具调用、节点路径和耗时都记录下来。这样评测不是只看最终答案，而是能看到 Agent 到底是怎么完成任务的。

2、如何设计Benchmark任务？

Benchmark 任务的目标，是用一批固定测试用例稳定评估 Agent 的能力。

设计 Benchmark 时，不能只放简单问题，也不能只放极端难题，要覆盖真实业务场景。

一个好的 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 v1.0 中，由于执行路径是图结构，可以额外评估节点路径是否符合预期。例如这个任务是否应该经过 retrieve 节点、是否应该进入 human_approval 节点。

3、如何评估Tool Calling能力？

Tool Calling 能力评估，不能只看最终答案，还要看工具有没有调对。

主要评估几个点。

第一，是否该调用工具。

有些问题必须调用工具，比如“查订单状态”；有些问题不需要，比如“什么是订单状态”。Agent 要能区分。

第二，工具选择是否正确。

比如用户问物流状态，应该调用 get_logistics，而不是调用 search_docs。

第三，参数是否正确。

用户输入订单号 O123，工具参数里就应该是：

{
  "order_id": "O123"
}

如果参数名错、类型错、漏字段，都算失败。

第四，调用顺序是否合理。

有些任务有依赖关系。比如先查订单是否存在，再查物流。如果顺序错了，后续可能失败。

第五，工具结果是否被正确使用。

工具返回“订单已取消”，Agent 不能回答“订单正在配送”。

第六，工具失败时是否能处理。

如果工具超时或返回错误，Agent 应该说明问题、重试或走降级，而不是编造结果。

常见指标包括：

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

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

4、如何评估规划能力？

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

比如用户说：

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

一个合理的规划可能是：

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

评估规划能力时，可以看几个方面。

第一，步骤是否完整。

有没有漏掉关键步骤。比如没有查工单就直接总结原因，明显不可靠。

第二，顺序是否合理。

有些步骤有依赖关系，不能乱排。比如先拿到用户 ID，再查订单。

第三，是否避免多余步骤。

规划不是越复杂越好。能一步完成的任务，不应该拆成十步。

第四，是否能根据中间结果调整计划。

如果查不到客户信息，应该停止或要求补充信息，而不是继续查订单。

第五，是否能处理异常分支。

比如工具失败、权限不足、结果为空时，有没有备用路径。

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

例如：

正常路径：intent -> get_customer -> get_tickets -> summarize
异常路径：intent -> get_customer -> missing_info_response

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

5、如何评估推理能力？

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

常见推理场景包括：

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

比如：

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

Agent 应该能得出“可以”，并说明依据。

评估推理能力时，可以看几个点。

第一，事实是否使用正确。

有没有用错输入数据，或者忽略关键条件。

第二，规则是否理解正确。

有没有把“同时满足”理解成“满足任意一个”。

第三，结论是否和过程一致。

不能过程里说不符合，结论又说通过。

第四，是否能处理反例。

测试集中要放一些边界情况，比如刚好等于阈值、缺少字段、规则冲突。

第五，是否避免编造前提。

如果资料里没有某个条件，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 不是为了显得复杂。如果多 Agent 的准确率没有提升，反而更慢更贵，就没有必要。

在 LangGraph v1.0 中，多 Agent 协作可以用图来编排，每个 Agent 作为一个节点，或者每个子图代表一个 Agent。评测时可以检查：

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

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

7、如何评估Memory效果？

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

第一，写入是否正确。

不是所有内容都应该进入长期记忆。比如临时闲聊不需要保存，用户明确偏好、项目背景、长期事实才值得保存。

可以测试：

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

系统应该保存语言偏好。

但如果用户说：

我今天下午三点有个会。

是否保存，要看业务是否需要。不能什么都写入。

第二，召回是否准确。

新会话中，系统是否能根据用户身份召回相关记忆。

例如用户之前说“回答要简洁”，新会话里系统回答是否更简洁。

第三，使用是否合理。

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

第四，是否避免错误记忆。

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

第五，是否保护隐私。

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

常见指标包括：

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

在 LangGraph v1.0 中，短期记忆通常通过 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 是否上升
平均延迟是否变长

第五，重点看失败样本。

整体指标没变，不代表没有问题。某些关键业务场景不能退化，比如支付、权限、客服高频问题。

第六，设置通过门槛。

例如：

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

在 LangGraph v1.0 项目中，回归测试还可以检查执行路径是否变化。比如一个请求原本应该进入 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 更关注安全和工具调用正确率。