AI测试开发面经：50个Tool，Agent为什么总是选错？

关注 霍格沃兹软件测试开发 公众号，回复「资料」, 领取人工智能测试开发技术合集

最近 DeepSeek Harness、MCP、Agent Tool Calling 这些技术越来越热。

如果你正在准备 AI 测试开发岗位，我觉得有一类题很值得重点准备。

它不是问：

MCP 是什么？

也不是问：

Function Calling 怎么写？

而是直接给你一个真实业务问题：

公司做了一个企业客服 Agent，接入了 CRM、订单、物流、退款、知识库等多个 MCP Server，一共暴露了 50 多个 Tools。上线测试以后发现 Agent 偶尔会选错 Tool。

如果让你负责测试，你会怎么设计方案？

这道题看起来不复杂。

但往下追三四层以后，其实非常能区分：

会调用大模型 API 的候选人

和

真正有 AI 测试开发思维的候选人。

一、面试官第一问：Tool 能正常调用，为什么 Agent 还会出错？
很多传统测试工程师第一反应可能是：

我先把50个Tool全部做接口自动化测试。

当然应该做。

但这只是第一层。

假设：

get_order
get_refund
get_logistics
search_customer
所有接口：

100% PASS。

用户输入：

帮我查一下上个月那笔退款为什么失败了。

Agent 却调用：

get_order
而不是：

get_refund
接口本身没有任何 Bug。

真正出错的是：

User Intent
↓
LLM Understanding
↓
Tool Selection ← FAIL
↓
Arguments
↓
Tool Execution
所以我会先告诉面试官：

Agent Tool Testing 不能只测试 Tool 本身，还要测试模型对 Tool 的理解、选择和调用。

二、面试官继续追：那你准备怎么测“选没选对”？
这时候就需要构建：

Tool Evaluation Dataset
不能只准备：

输入 → Expected Output
而应该包含：

User Query
+
Expected Tool
+
Forbidden Tool
+
Expected Arguments
+
Expected Business Behavior
例如：

cases = [
{
"id": "tool_001",
"query":
"查一下订单A1024现在到哪了",

"expected_tools": [
"get_order",
"get_logistics"
],

"forbidden_tools": [
"create_refund"
]
},

{
"id": "tool_002",
"query":
"上个月那笔退款为什么失败？",

"expected_tools": [
"get_refund_record"
],

"forbidden_tools": [
"create_refund"
]
},

{
"id": "tool_003",
"query":
"这个客户已经退款8次了，
这次又要退5000元",

"expected_behavior":
"manual_review"
}
]
第三条非常重要。

因为 AI 测试不仅要验证：

什么时候应该调用 Tool。

还要验证：

什么时候不应该继续自动调用。

三、面试官：如果有多个Tool都能完成任务，Expected Tool怎么写？
这个追问就开始有点二面的味道了。

例如：

search_order
query_order
find_order
三个 Tool 都能查询订单。

如果 Case 写死：

assert selected_tool == "search_order"
可能会产生大量误报。

所以我不会简单定义唯一 Expected Tool。

而是根据业务定义：

case = {
"query":
"查询A1024订单状态",

"acceptable_tools": {
"search_order",
"query_order"
},

"forbidden_tools": {
"create_refund",
"cancel_order"
},

"expected_result":
"order_status_returned"
}
这背后其实是一个很重要的 AI 测试思想：

不要把“路径不同”直接等价成“结果错误”。

Agent 系统本身允许存在多条合理路径。

真正需要约束的是：

业务结果和行为边界。

四、面试官：那具体怎么自动化？
可以先写一个基础 Evaluator。

def evaluate_tool_selection(agent, case):

trace = agent.run(case["query"])

calls = [
event
for event in trace
if event["type"] == "tool_call"
]

selected_tools = {
call["tool"]
for call in calls
}

acceptable = set(
case.get("acceptable_tools", [])
)

forbidden = set(
case.get("forbidden_tools", [])
)

forbidden_called = (
selected_tools & forbidden
)

valid_selection = True

if acceptable:
valid_selection = bool(
selected_tools & acceptable
)

return {
"selection_pass":
valid_selection,

"forbidden_call":
list(forbidden_called),

"selected_tools":
list(selected_tools)
}
这段代码并不复杂。

真正重要的是测试思路：

我们开始把 Agent Trace 变成一种：

可自动断言的测试对象。
而不是只盯最终回答。

人工智能技术学习交流群
伙伴们，对AI测试、大模型评测、质量保障感兴趣吗？我们建了一个 「人工智能测试开发交流群」，专门用来探讨相关技术、分享资料、互通有无。无论你是正在实践还是好奇探索，都欢迎扫码加入，一起抱团成长！期待与你交流！👇

五、面试官继续问：50个Tool里偶尔选错，怎么知道到底是哪几个Tool有问题？
这里可以引出一个很有价值的指标：

Tool Confusion Matrix
假设我们跑5000条真实业务 Case。

得到：

真实意图
Order
Refund
Logistics
CRM
Order
97.1%
1.2%
1.1%
0.6%
Refund
5.8%
90.7%
2.0%
1.5%
Logistics
2.4%
1.1%
95.6%
0.9%
CRM
2.1%
1.6%
0.8%
95.5%
总体 Tool Selection Accuracy：

94.7%。

看起来还不错。

但是矩阵一拆：

Refund → Order 的误选率达到5.8%。
这时候测试团队就知道：

问题不是“Agent偶尔抽风”。

而是：

Refund 和 Order 两类 Tool 之间存在系统性的语义混淆。

六、面试官：发现Tool Confusion以后，你怎么定位原因？
如果只回答：

优化 Prompt。

我觉得分数不会很高。

因为真正可能影响 Tool Selection 的变量很多。

至少包括：

Tool Name

Tool Description

Parameter Schema

System Prompt

Tool数量

Tool排序

Context

Model

Routing Strategy
所以我会做：

Controlled Experiment
例如固定：

Model；

Temperature；

Dataset；

System Prompt；

其他 Tools。

只修改 Refund Tool Description。

版本A：

Get refund information.
版本B：

Query an existing refund record
and return refund status,
failure reason and refund amount.

This tool does NOT create
or modify refunds.
然后重新执行同一套 Dataset。

结果：

A B

Refund Selection 90.7% 96.8%

Refund→Order 5.8% 1.7%

Forbidden Call 0.4% 0.1%
这时候我们才有依据说：

Tool Description 优化有效。

而不是凭感觉改 Prompt。

七、面试官再追：Tool选对了，是不是就算PASS？
当然不是。

下一层是：

Argument Evaluation
Agent 正确选择：

create_refund
但是生成：

{
"order_id": "A1024",
"amount": 599
}
真实可退款金额：

199
Tool Selection：

PASS。

Business Result：

可能直接资损。

所以我们还要验证：

Argument Accuracy
例如：

def validate_refund_args(
tool_call,
business_context
):

args = tool_call["arguments"]

violations = []

if (
args["amount"]
> business_context["refundable_amount"]
):
violations.append(
"refund_amount_exceeded"
)

if (
args["order_id"]
!= business_context["order_id"]
):
violations.append(
"wrong_order"
)

return {
"pass":
len(violations) == 0,

"violations":
violations
}
这里开始体现：

AI Evaluation + 业务测试
真正结合起来了。

八、面试官：那LLM Judge要不要用？
要。

但不能什么都交给 LLM Judge。

这是现在 AI 测试面试里非常值得讲清楚的一点。

例如：

退款金额是否超过可退款金额。

完全可以：

assert refund_amount <= refundable_amount
为什么还要花 Token 让另一个 LLM 猜？

所以我会设计：

Hybrid Judge
Agent Trace
↓
┌──────────┴──────────┐
↓ ↓
Rule Judge LLM Judge
↓ ↓
参数是否合法 回答语义是否合理
调用顺序 解释是否准确
禁止行为 用户意图是否满足
金额约束 复杂场景判断
└──────────┬──────────┘
↓
Final Score
简单来说：

能用确定性规则判断的，就不要全部交给大模型。
LLM Judge 应该解决传统 Assertion 很难解决的问题。

九、面试官：MCP Server升级了，你怎么做回归？
这其实是传统测试工程师非常容易发挥优势的一道题。

假设：

Refund MCP V2.3
升级：

Refund MCP V2.4
研发说：

API没改，只改了一下Tool Description和Schema说明。

传统 API Regression：

全部通过。

是不是可以上线？

不一定。

因为对于 Agent：

Tool Description 本身就是运行逻辑的一部分。

所以我会自动执行：

MCP / Plugin Change
↓
Schema Validation
↓
API Regression
↓
Tool Selection Eval
↓
Argument Eval
↓
Behavior Eval
↓
Business Dataset
↓
Old VS New
↓
Quality Gate
十、面试官：Quality Gate怎么定？
比如：

def mcp_release_gate(report):

if report.api_pass_rate < 1.0:
return "BLOCK"

if report.critical_case_pass < 1.0:
return "BLOCK"

if report.forbidden_call_rate > 0:
return "BLOCK"

if report.tool_selection < 0.95:
return "BLOCK"

if report.argument_accuracy < 0.95:
return "BLOCK"

if report.p95_latency > 2.0:
return "REVIEW"

return "PASS"
为什么 Latency 超标只是：

REVIEW
而 Forbidden Call：

BLOCK
因为：

指标的业务风险等级不同。

这其实又回到了测试开发非常熟悉的：

Risk-Based Testing
十一、再给一道更难的追问：Tool越多，Agent是不是越强？
不一定。

假设：

10 Tools

Selection Accuracy
98.2%
增加到：

30 Tools

95.7%
再增加：

80 Tools

87.4%
这时候不能简单说：

模型能力下降了。

很可能是：

Tool Space过大。
尤其大量 Tool 的：

Name；

Description；

Schema；

业务能力

高度相似时，

Agent 的决策难度会明显提高。

这时候解决方案可能已经不是继续：

“优化Prompt。”

而是考虑架构：

User Query
↓
Intent Router
↓
Tool Group
↓
Candidate Tools
↓
LLM Selection
↓
Execution
把：

80选1
变成：

5个Domain选1
↓
Domain内部10选1
这时候测试工程师已经不只是在：

发现Bug。

而是在通过 Evaluation 数据：

推动Agent架构优化。

十二、这类面试题为什么特别适合传统测试工程师？
因为你仔细看：

里面真正用到的能力是：

接口测试；

契约测试；

数据驱动；

控制变量；

回归测试；

性能测试；

业务规则；

质量门禁；

故障定位。

这些都是传统测试开发工程师原本就应该具备的。

需要补充的是：

MCP
Tool Calling
Agent Trace
LLM Evaluation
Tool Selection Evaluation
Argument Evaluation
所以传统测试转 AI 测试开发，最好的思路不是：

把过去全部推倒重学。

而是：

把已有测试工程能力重新映射到AI系统。

十三、如果现在让我准备AI测试开发面试，我会真正做一个这样的项目
而不是简历上只写：

熟悉 LangChain、RAG、MCP。

我会做一个：

MCP Agent Evaluation Platform
至少支持：

Tool Dataset管理

Tool Selection测试

Argument测试

Trace记录

Rule Judge

LLM Judge

Confusion Matrix

版本对比

Regression

Quality Gate
哪怕只是自己做一个小型 Demo。

面试的时候都可以直接讲：

我发现 Tool 数量从10个增加到50个以后 Selection Accuracy 下降，所以我建立了 Confusion Matrix，发现两个订单 Tool 语义高度重叠，然后通过 Description A/B Test 验证，误选率从X降到了Y。

这句话的含金量，

远高于：

“我了解MCP协议。”

最后，再留一道AI测试二面题
企业 Agent 有：

80个Tools
目前：

Tool Selection Accuracy：93%

Argument Accuracy：97%

Task Success：91%
你做了一层 Intent Router，把每次提供给模型的 Tool 从80个减少到平均12个。

结果：

Tool Selection Accuracy：97%

Argument Accuracy：96%

Task Success：95%

P95 Latency：+18%

Token Cost：-23%
这个优化能不能上线？
一个好的回答不应该只是：

能。

而应该继续追问：

18%的延迟增加有没有突破SLA？

然后结合：

任务成功率；

业务场景；

Cost；

Latency；

Critical Case；

稳定性

做最终 Release Decision。

因为 AI 测试开发工程师真正需要解决的问题，从来不是：

这个模型得了多少分？

而是：

这个AI系统，在企业真实业务约束下，到底能不能上线？

当你能把这个问题讲清楚的时候，你和“会几个AI名词”的候选人，已经不是一个层级了。

推荐学习
智能化测试-测试用例生成公益训练营，从行业大模型特性讲起，带你搞懂AI测试的全链路：大模型能力评测、智能体Harness工程、Skill技能体系、CLI与MCP工具体系、RAG知识图谱——最后直接上手打造一个能自动生成测试用例的智能体。

关于我们
霍格沃兹测试开发学社，隶属于 测吧（北京）科技有限公司，是一个面向软件测试爱好者的技术交流社区。

学社围绕现代软件测试工程体系展开，内容涵盖软件测试入门、自动化测试、性能测试、接口测试、测试开发、全栈测试，以及人工智能测试与 AI 在测试工程中的应用实践。

我们关注测试工程能力的系统化建设，包括 Python 自动化测试、Java 自动化测试、Web 与 App 自动化、持续集成与质量体系建设，同时探索 AI 驱动的测试设计、用例生成、自动化执行与质量分析方法，沉淀可复用、可落地的测试开发工程经验。

在技术社区与工程实践之外，学社还参与测试工程人才培养体系建设，面向高校提供测试实训平台与实践支持，组织开展 “火焰杯” 软件测试相关技术赛事，并探索以能力为导向的人才培养模式，包括高校学员先学习、就业后付款的实践路径。

同时，学社结合真实行业需求，为在职测试工程师与高潜学员提供名企大厂 1v1 私教服务，用于个性化能力提升与工程实践指导。