微软 Agent 评测指南里，藏着一条让测试少背一次锅的结论

摘要：从代码可运行但选错SDK与认证模式的现场，建立可辩护的Agent Experience评测。

Microsoft在10月9日发布AX Practitioner Playbook时直接写到：Coding Agent生成的代码可能看起来合理、甚至能够编译，仔细检查却会发现错误的SDK版本、已弃用的认证模式，或产品团队并不推荐的配置。微软说明，这套方法来自数百次Agent会话，以及Azure、Cosmos DB、SPFx等技术评测。

把这个公开现象转成测试任务，可以让AI Coding接入一个支付SDK，并把验收重点放在版本、认证方式、令牌权限与服务端握手，而不是只看客户端能否初始化。支付只是用于承载风险的业务推演，错误SDK与过时认证模式则直接来自微软公开观察。普通接口回归之所以容易漏掉，是因为错误发生在Agent替开发者决定“用哪个SDK、哪个版本、哪种模式”的第一步。本文把AX方法转成测试团队可执行的选型回归，并沿文档、MCP、Skill、插件、CLI或API定位首个错误来源。

别先问“模型是不是太旧”

团队看到旧SDK，第一反应常是模型知识截止日期不够新。这个解释听起来合理，却难以指导修复：同一模型可能知道更晚发布的功能，也可能忽略早已存在的推荐做法。真正可控的是Agent能看到和调用的来源，包括开发文档、示例代码、Skill、MCP工具、CLI帮助和仓库内说明。

测试要把“Agent不知道”拆成三个不同故障。扩展没有加载，是环境或安装问题；扩展已加载但没调用，是发现与描述问题；扩展被调用却应用错误，是内容、示例或模型理解问题。三类故障的修复面完全不同，如果只看最终代码，它们都会被笼统归为“模型选错”。

官方Playbook最值得借用的是“结果必须可辩护”

Microsoft原文提醒，评测会非常自信地骗人：项目没有编译也可能拿到完美条件分，“使用平台X”的检查甚至可能在未使用时仍通过。一个可信结果至少要有两类证据：Criteria判断技术含义，Gate证明项目确实运行。Criteria回答是否使用正确版本、推荐认证和所需模式；Gate负责构建、测试、部署或实际请求。

Criteria不要写成“遵循最佳实践”，它无法稳定判定。应拆成明确事实：依赖锁文件使用批准主版本；认证流程不保存长期密钥；请求使用组织规定的重试策略；示例没有调用弃用接口。每条条件只判断一个问题，并写清适用与跳过条件。

用真实任务构造基线与候选对照

评测任务不要问“请介绍新版SDK”，而要像真实开发工作：给一个现有订单服务，要求接入支付、处理超时并写回调验签。准备两组配置：基线只有通用仓库上下文；候选加入新版文档、Skill或MCP。两组使用同一模型、同一初始仓库、同一超时和相同运行次数。

候选比基线好的地方叫lift，变差的地方叫drag。不能只报告总体分数，还要看它在哪条条件改善、在哪类场景退化。例如新版Skill让SDK版本正确率提高，却让Agent跳过服务端验签，就不是可以直接上线的改进。

业务断言必须独立于Agent生成的测试

Agent写实现又写测试，最危险的是二者共享同一个错误假设。支付接入可以用独立沙箱和组织策略做真值：

def assert_payment_integration(repo, sandbox):
    assert repo.dependency("payment-sdk").major == APPROVED_MAJOR
    assert repo.uses_deprecated_auth() is False
    result = sandbox.simulate_callback(signature="invalid")
    assert result.status == 401
    assert sandbox.created_charge_count == 0

这里不关心Agent把类放在哪个目录，而是检查版本、认证和真实副作用。再加一个变异测试：故意把验签断言改弱，如果测试仍全部通过，说明评测器没有真正保护业务。

Trajectory比最终分数更快找到修复点

一次失败要按时间线回答：Agent看见了哪些来源；是否加载扩展；是否调用；拿到什么结果；为何选择旧版本；运行Gate在哪一步失败。假如它根本没加载Skill，继续润色Skill内容没有意义；若加载且调用，却被旧README示例盖过，就应该修文档排序与示例；若工具返回新版但Agent仍选旧版，才进入模型与指令层调查。

报告标记第一处偏离，不要只堆完整日志。第一处偏离是“检索命中旧页”，后续的依赖、认证和测试错误通常只是连锁反应。修复后重放原场景和相邻场景，确认不是只记住一个Prompt。

九类失败里，测试最该先分清三类

第一类是基础设施失败：扩展未加载、环境变量缺失、工具超时。第二类是发现失败：扩展存在但Agent没有调用，或被名字相似的旧文档抢走。第三类是应用失败：Agent调用了正确工具，却误解返回内容、混合旧知识或只采用一部分规则。

除此之外，还要单列任务说明不完整、Criteria误判、Gate不可复现、模型循环、成本异常和安全越界。分类不是为了统计漂亮，而是把证据交给真正能修的人。基础设施归平台，来源内容归文档/SDK团队，策略与门禁归测试和安全，模型行为再交给Agent团队。

CI里的最小闭环

SDK或文档每次大版本更新时，挑十个高频任务和五个高风险任务。提交阶段运行静态版本、弃用API与密钥检查；夜间让Agent独立完成任务三次，保存产物、Gate和Trajectory；发布前在真实沙箱执行回调、权限与错误恢复。结果既看通过率，也看方差、成本和首错分布。

新失败进入候选集前必须人工确认期望。评测条件本身也版本化：产品策略变化后，旧Criteria不能悄悄改意思，否则历史趋势不可比较。每次调整说明为什么变、哪些报告受影响、如何重跑。

一张可直接用于评审的AX验收表

把一次失败修成可复用资产

若Agent选错SDK，不要只在当前Prompt补一句“必须使用最新版”。先复现并冻结基线，再用Trajectory确认第一处偏离；随后选择真正可控的修复面，例如更新旧文档、补充Skill、改善MCP描述或让CLI默认生成安全模板。候选修复与基线用相同任务重复运行，证明改善具有统计稳定性。

修复进入生产后继续收集真实任务。新项目可能缺少锁文件，旧项目可能被历史示例影响，企业仓库还可能有私有镜像与安全策略。相邻场景没有改善，说明修复只对评测Prompt有效；出现新的drag，则要回滚或缩小适用范围。

AI Coding把“技术选型”提前交给了Agent，测试也必须向前移动。不是等功能上线后再找Bug，而是在Agent选择来源、版本和模式时就建立证据。测试工程师熟悉的契约、环境隔离、回归、变异测试和根因分析，在这里并没有过时；它们只是从验证代码，升级为验证一整条Agent Experience。

一个可复现的支付SDK评测场景

初始仓库只提供订单服务和旧版支付占位符。任务要求选择组织批准的SDK主版本，实现短期令牌认证、回调验签、超时查询和幂等扣款。测试团队另存一份不可被Agent修改的政策文件：禁止长期密钥、禁止关闭证书校验、回调签名失败必须返回401、未知扣款状态必须先查询。

基线运行三次，记录Agent从哪些页面找到版本信息；候选配置再分别加入新版文档、Skill和MCP工具。不要一次把所有扩展全开，否则改善后无法知道是谁起作用。每次只改变一个变量，再看版本选择、认证方式、运行门禁、成本和Trajectory首错是否改善。

Criteria怎样避免被漂亮文字骗过

一条Criteria只判断一个事实，并包含名称、判定问题、允许证据和跳过条件。例如“使用批准主版本”必须读取锁文件或构建解析结果，不能只搜索代码中出现版本号；“使用安全认证”必须检查令牌生命周期与存储位置，不能因为README写了OAuth就通过。

裁判先在人工构造的通过/失败产物上校准。把旧版本、弃用认证、缺少验签和只写伪测试的仓库分别喂给评测器，确认它能稳定区分。若同一产物五次判断摇摆，Criteria还不能进入发布门禁。

从失败模式反推修复面

扩展未加载时，检查安装路径、名称和大小限制；已加载未调用时，检查描述、触发词和与其他工具的竞争；已调用却用错时，检查返回内容、示例与版本冲突；正确使用但运行失败时，检查SDK文档是否遗漏真实环境前置条件。每一类都对应不同负责人，避免团队反复“加强Prompt”却没有改变信息源。

修复提交时附三样东西：原始失败Trajectory、修改后的来源Diff、同一场景及相邻场景的回归对照。若只在一个提示词上变好，不能称为修复；如果提升依赖于把答案直接写进指令，也要警惕评测污染。

质量改进不能牺牲开发体验

更严格的指令可能让Agent每一步都请求确认，技术选择更安全，却把简单任务拖得很慢。报告需要同时列正确性、完成率、调用次数、上下文大小和人工干预。安全红线不谈折中，但低风险场景可以比较成本与收益，选择最小有效扩展。

最终要形成组织自己的AX回归包：真实任务、独立Criteria、运行Gate、可重放环境和首错分类。模型换代、SDK发布、文档改版或Skill更新时都能重跑，团队就不必靠个别专家每次人工发现“它又选错了”。

评测来源也要做库存

把文档、示例、Skill、MCP和CLI按所有者、版本、生效日期、废弃状态登记。Agent命中旧来源时能迅速找到负责人；来源下线后也能确认缓存与索引是否清理。AX不只是一次评测，它最终会变成面向Agent的知识供应链治理。

最后，给每次评测指定“证据负责人”：谁确认任务真实，谁维护Criteria，谁审Gate，谁接收修复。没有负责人，再好的报告也会停在文档里。AX闭环的终点不是得分，而是某个可控来源被修改并通过回归。

本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。