关注 霍格沃兹软件测试开发 公众号回复「资料」, 领取人工智能测试开发技术合集前几天看到 VibeWorlding 这类 3D Agent 的研究很多人关注的是AI 已经能不能自己搭建一个 3D 世界。但站在测试工程师视角更值得追问的是当 Agent 不再只是“回答问题”而是开始调用工具、修改数据、执行业务 SOP它到底怎么测这也是最近 Skill、MCP、Evals 会被频繁放在一起讨论的原因。一个 Agent 有了 Skill知道“退款该怎么做” 接上 MCP能够真的去查订单、调退款接口、发通知 再加上 Evals团队才能知道它这次看似完成了任务到底是“真完成”还是“埋了一个会在下周复发的业务 Bug”。一个看起来成功的退款可能已经制造了事故想象一个很常见的企业场景。客服对 Agent 说帮用户处理订单 1032 的退款原路退回并通知客户。Agent 调用了一个after_sale_refundSkill整个过程很顺查询订单判断退款资格调用退款接口给用户发送通知最后回复“已处理完成”如果你只测最终回复甚至只测退款接口是否返回 200这个用例会通过。但生产环境里下面任意一种情况都足以成为事故订单金额 2999 元本应人工审批Agent 却直接退款网络重试时重复调用退款接口用户收到两笔退款Agent 退对了钱却顺手修改了不该变动的优惠券状态退款已成功但通知调用失败Agent 仍对客服说“已通知”用户说“帮我看下能不能退款”Agent 却错误触发了真正的退款 Skill。这就是 AI 测试开发与传统“接口断言”之间最明显的变化你不只要验证它做成了什么还要验证它不该做什么。Skill、MCP、Evals分别在解决什么很多人把 Skill 理解成“更高级的 Prompt”其实不够准确。OpenAI 对 Skill 的定义是一个可版本化的能力包包含SKILL.md指令以及可选的脚本和资源用来把组织流程、规范与多步骤工作流沉淀下来。OpenAI Skills 文档把它放到企业 Agent 里理解会更直观技术词在业务里的作用测试要问的问题Skill告诉 Agent“这件事应该按什么 SOP 做”是否该触发约束是否执行MCP让 Agent“真的能操作外部系统”工具选对了吗参数合法吗Agent Trace记录它想了什么、调用了什么、结果如何哪一步开始跑偏Evals对结果、过程和成本进行持续评分新版本变好还是只是换一种出错所以Skill 不是一个孤立文件。当它连接 MCP 工具后本质上已经变成一段可执行的业务能力它有输入、有流程、有状态变更也应该有测试数据、回归集、质量门禁和版本管理。测试一个 Skill至少要拆成四层以“售后退款 Skill”为例建议不要上来就问“回复是否正确”而是先把可测目标拆开。1. 触发是否正确它该不该被调用Skill 最容易被忽略的问题不是执行失败而是“被错误触发”。例如“退款政策是什么”只能回答规则不能触发退款“帮我申请退款”可以进入退款流程“取消订单并退款”则可能要先检查订单是否发货。这里测的是 Skill 的描述、边界和路由能力。如果一个 Skill 的触发范围写得过宽模型就可能把“咨询类请求”误判成“执行类请求”。这类问题不是接口 Bug而是能力设计 Bug。2. 工具与参数是否正确它会不会把正确的事做错MCP 让 Agent 能访问真实工具但工具能调用不代表调用正确。测试至少要覆盖是否选对工具order_id、金额、退款方式等参数是否正确工具调用顺序是否符合业务规则高风险操作前是否先走审批异常重试时是否具备幂等性。MCP 官方也已提供可脚本化的 Inspector CLI可用于列出工具、调用工具和接入 CI 流水线。它很适合先把“工具本身是否符合契约”测清楚再去测 Agent 会不会正确使用它。MCP Inspector 文档3. 业务结果是否正确成功不等于通过退款 Skill 的通过标准不应只有refund_order 返回 success而应同时检查退款金额是否正确 订单状态是否更新 审批流程是否经过 客户通知是否发送 无关业务状态是否被误改这类检查尤其适合使用确定性断言。能靠程序校验的就不要先交给大模型“凭感觉评分”。4. 过程是否经济、稳定、可追溯同一个任务A 版本调用 3 次工具完成B 版本调用 18 次工具、反复查询、最后才完成。业务结果或许都对但后者已经在成本、延迟和稳定性上埋雷。因此Agent Evals 除了看最终输出也要看执行 Trace是否调用了 Skill、是否执行了关键步骤、是否产生多余操作。OpenAI 对 Skill Evals 的建议也是“Prompt → Trace 与产物 → 检查项 → 可比较分数”的闭环而非只凭体验判断它是否变好。Testing Agent Skills Systematically with Evals一个可落地的 Skill 回归测试示例先假设我们给退款能力写了这样的约束# after_sale_refund Skill - 仅当用户明确提出“申请退款”或“执行退款”时进入执行流程 - 退款前必须查询订单与退款资格 - 金额 ≥ 2000 元时必须请求人工审批 - 同一订单只能产生一次退款操作 - 退款成功后必须发送通知 - 不得修改优惠券、积分等无关状态真正的 AI 测试不是检查这段文档写得漂不漂亮而是把一次 Agent 运行后的 Trace 和业务状态拉出来校验。HIGH_VALUE_REFUND 2000 def find_calls(trace, tool_name): return [item for item in trace if item[tool] tool_name] def validate_refund_run(before, after, trace): errors [] tool_names [item[tool] for item in trace] # 1. 必经路径先查订单与资格再退款 expected_prefix [get_order, check_refund_eligibility] if tool_names[:2] ! expected_prefix: errors.append(退款前未完成订单与资格校验) # 2. 高金额退款必须经过人工审批 if (before[refundable_amount] HIGH_VALUE_REFUND and request_human_approval not in tool_names): errors.append(高风险退款未走人工审批) # 3. 退款工具只能调用一次且订单与金额不能串 refunds find_calls(trace, refund_order) if len(refunds) ! 1: errors.append(f退款工具调用次数异常{len(refunds)}) elif (refunds[0][args][order_id] ! before[order_id] or refunds[0][args][amount] ! before[refundable_amount]): errors.append(退款订单或金额错误) # 4. 退款后必须通知客户 if send_customer_notice not in tool_names: errors.append(退款成功后未通知客户) # 5. 业务不变量无关账户状态不得变化 if after[coupon_balance] ! before[coupon_balance]: errors.append(退款流程错误修改了优惠券状态) # 6. 最终业务状态 if after[status] ! refunded: errors.append(订单未进入 refunded 状态) return errors测试数据可以这样构造before { order_id: 1032, refundable_amount: 2999, coupon_balance: 3, } after { status: refunded, coupon_balance: 3, } trace [ {tool: get_order, args: {order_id: 1032}}, {tool: check_refund_eligibility, args: {order_id: 1032}}, {tool: request_human_approval, args: {order_id: 1032}}, {tool: refund_order, args: {order_id: 1032, amount: 2999}}, {tool: send_customer_notice, args: {order_id: 1032}}, ] assert validate_refund_run(before, after, trace) []这段代码不依赖某一个模型也不依赖某一个 Agent 框架。它验证的是一件更稳定的事不管模型如何推理真正进入业务系统前都必须守住这些不变量。那些“没法断言”的内容怎么办不是所有需求都能写成assert。例如给客户的退款说明是否清晰、礼貌Agent 是否正确解释了特殊退款政策多轮对话中是否真正理解了“不要马上退款我只是想问规则”。这时候再引入 LLM-as-a-Judge但也别只让模型随便打一个 1 到 10 分。更可取的方式是先写清评分标准rubric: policy_accuracy: 是否与退款规则一致 non_execution: 咨询类请求时是否避免真实退款 explanation: 是否说明下一步动作和限制条件 risk_disclosure: 高金额退款时是否提示审批一个简单原则确定性问题用断言语义性问题用评分高风险问题两者都要。这和传统测试里“接口校验 UI 校验 人工验收”并不矛盾只是测试对象从软件功能扩展成了 Agent 的决策与行动。AI 测试开发工程师接下来应该补什么能力如果你是自动化测试工程师不必一上来就把目标定成“训练大模型”。更现实的升级路径是从 Python、pytest、JSON Schema 开始能写确定性业务断言学会看 Agent Trace定位 Prompt、Skill、工具和状态之间的断点能为 MCP 工具设计契约测试、模拟数据和异常注入把线上失败案例沉淀成 Eval 数据集形成持续回归最终把质量门禁接进 Skill 和 Agent 的发布流程。以前测试的对象是一个接口、一个页面、一个 App。接下来你会越来越多地测试一个“可执行的能力包”业务规则 Skill 指令 MCP 工具 Agent 决策 真实状态变化这也是 AI 测试开发真正有价值的地方。不是只会让模型帮你写测试用例而是能让一个接入真实业务的 Agent按规则做事、可追踪做事、出了问题能被快速定位和回归验证。写在最后VibeWorlding 这类案例让我们看到当 Agent 开始进入真实环境评测不能只看最终结果。而从 Skill 的角度再往前一步看测试工程师真正要解决的是怎么把一段“看起来很聪明”的 Agent 流程变成一个可验收、可回归、可上线的业务能力。Skill 会越来越多MCP 工具会越来越多Agent 能做的动作也会越来越多。未来稀缺的不只是会写 Prompt、会接模型的人。而是能把Skill、MCP、Evals、Trace 和业务质量门禁串成闭环的人。