摘要：从代码可运行但选错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验收表
| 层级 | 关键问题 | 证据 |
|---|---|---|
| 加载 | Skill/MCP/文档是否进入上下文 | 启动日志、扩展清单 |
| 调用 | Agent是否在正确时机使用 | Tool Call、检索记录 |
| 应用 | 版本、认证、模式是否正确 | 代码Diff、Criteria判定 |
| 运行 | 项目是否真正构建与执行 | Build、沙箱请求、回调 |
| 回归 | 修复是否改善相邻任务 | 基线/候选多次对照 |
| 治理 | 成本、安全与来源是否可追 | Trajectory、版本、负责人 |
把一次失败修成可复用资产
若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 测试等内容，侧重测试实践、工具应用与工程经验整理。
