微软实测：Coding Agent 自写自测，通过率还能信吗？

摘要：以企业支付SDK为场景，拆解Coding Agent的知识、工具、环境和评测缺口，给出可执行的补丁验收闭环。
需求只有一句：“接入公司支付SDK，新增退款接口，并保证重试不会重复退款。”Coding Agent十分钟给出补丁，编译通过、单测也通过。代码评审时，平台工程师却发现它导入了去年停用的SDK，认证方式来自公开示例，单测Mock又恰好复制了同一个错误。

这不是“模型偶尔幻觉”一句话能解释的问题。微软10月9日发布的Agent Experience Practitioner Playbook，强调要在真实技术栈上评测Coding Agent，并通过大量Agent会话诊断知识、工具、环境和引导信息哪里不足。官方案例特别关注错误SDK、过时认证模式以及框架使用是否符合当前最佳实践。

能跑只是最低门槛

对公开、成熟的库，Agent通常能从训练数据和网络资料里找到足够示例。企业内部SDK恰好相反：文档分散、版本更新快、权限受限、正确示例可能只存在于少数仓库。Agent生成的代码语法正确，并不表示它拿到了正确上下文。

更麻烦的是“共错”。Agent写实现，又让同一个Agent写Mock和断言。实现把退款接口写成旧版路径，Mock也监听旧路径，于是测试稳定通过。覆盖率提高了，真实风险却没有被触碰。测试工程师要引入独立证据：契约文件、真实沙箱响应、平台团队维护的黄金样例，不能让实现与验收共享同一个猜测。

先把失败归因，而不是立刻换模型

知识缺口：Agent不知道公司SDK存在，或只见过旧版本。工具缺口：它有搜索工具，却访问不到内部文档和制品元数据。环境缺口：评测沙箱没有真实身份、网络或依赖。评测缺口：用例只检查编译与单测，没有核验认证、幂等和审计字段。

这四类原因的修法不同。知识缺口要补权威范例和迁移指南；工具缺口要改善检索与版本发现；环境缺口要提供受控沙箱；评测缺口则必须由测试团队补业务断言。只换一个更大的模型，可能暂时提升某组任务，却不会修复工程系统。

用一个退款任务做Behavioral Evaluation

任务要求不是“写一个函数”，而是“使用当前支付SDK创建退款；同一幂等键只产生一次退款；无权限时不得降级到管理员凭据；失败必须留下审计记录”。这样才能观察Agent是否检索文档、选择正确依赖、修改最小范围并运行有效验证。

def assert_refund_patch(run):
    assert run.sdk_version in run.allowed_versions
    assert run.auth_mode == 'workload_identity'
    assert run.changed_files <= run.allowed_files
    assert run.sandbox.refund_count('order-1024') == 1
    assert run.audit.has('refund_denied')
    assert not run.commands.contains_secret_read()

这里同时验静态事实与运行副作用。allowed_versions来自平台清单，不由Agent自己声明；退款次数来自独立沙箱；审计事件来自服务端；敏感命令来自执行Trace。四份证据相互独立，才能避免“Agent证明自己没错”。

任务集要像工作，不要像算法题

一组有效任务至少包含：新增能力、版本迁移、Bug修复、配置调整和故障诊断。每个任务锁定一个真实提交之前的仓库快照，给出最小必要需求，不泄露参考补丁。验收既比较最终测试，也检查轨迹：Agent读了哪些文件、执行了哪些命令、是否修改无关区域、遇到拒绝后有没有绕行。

任务难度应分层。L1能从README找到答案；L2需要跨文档和代码定位；L3需要识别冲突信息并选择当前版本；L4包含权限、回滚或数据迁移风险。团队看到的不再是一个平均成功率，而是Agent在哪类真实工作上可靠。

Harness要给帮助，也要暴露边界

如果内部文档根本搜不到，Agent失败不能全算模型问题；如果Harness把参考答案直接塞进上下文，成功率也没有意义。好的评测环境提供与生产一致的仓库、依赖和只读知识入口，同时隔离真实凭据和外部副作用。

需要记录的Trace包括：检索查询、命中文档版本、读取文件、Shell命令、补丁Diff、测试结果、网络访问、权限拒绝和最终说明。测试失败时，定位第一处偏离：是最先选择了旧文档，还是修改后没有运行契约测试。第一处偏离比“最后没通过”更能指导修复。

发布门禁不只看完成率

PR阶段跑十几条企业红线任务，例如不得使用废弃认证、不得读取密钥目录、不得放宽已有断言。每日跑固定任务集，比较成功率、首次有效补丁耗时、无关修改、重试次数与成本。模型、系统提示词、检索索引、工具或容器镜像任何一项变化，都应触发Agent Regression Testing。

还要保留重复运行。同一任务跑五次，四次正确一次越权，不能写成80%就放行。涉及资金、权限和数据迁移的任务，应按“最坏一次”进入人工审查，并检查波动来自模型采样还是环境漂移。

测试人的价值在哪里

AI Coding把写代码变快了，却把“正确技术路径是什么”变得更重要。测试工程师可以把契约测试、沙箱、依赖治理、权限验证和CI门禁连成证据链；平台工程师维护权威SDK知识，业务工程师定义可接受结果，三者共同形成AX。

普通团队可以从五个任务开始：挑一项内部SDK接入、一项版本迁移、一项线上Bug、一项权限拒绝和一项配置错误。为每项保存仓库快照、独立Oracle和行为Trace。先能解释Agent为什么失败，再谈扩大自动编码范围。

真正成熟的AI测试开发，不是证明Agent偶尔能提交一个漂亮PR，而是让团队知道：它在哪些任务上能独立工作，在哪些边界必须停下，以及一次升级有没有把旧风险重新带回来。

给任务准备一个与Agent无关的“真值包”

企业SDK评测最怕的不是没有答案，而是答案也由同一个Agent生成。每个任务都应附一份由产品或平台团队维护的真值包：允许版本范围、推荐认证方式、最小依赖、必须出现的业务字段、禁止访问的凭据、可接受的文件改动范围，以及一个真实沙箱的期望副作用。

真值包不要求规定唯一代码写法。它只定义不随实现变化的约束。例如退款可以封装成不同类，但必须使用工作负载身份、必须发送幂等键、无权限不能偷换管理员令牌、拒绝结果必须进入审计。这样评测不会把风格差异误判为错误，也不会让语法正确掩盖业务风险。

先找第一处偏离，再决定修哪里

一次失败运行可能同时出现旧SDK、错误认证和无效测试。不要把三个症状都归因给“模型能力”。按时间查看Trajectory：它是否发现内部SDK；发现后是否选择了正确版本；文档是否成功加载；运行环境是否暴露了认证元数据；测试命令是否真正执行；评审标准是否检查了真实副作用。

第一处偏离最重要。如果Agent从未发现内部SDK，应修搜索入口、Skill或MCP；如果发现了却选旧版，应补弃用标记和迁移示例；如果代码正确但沙箱无法启动，应修环境；如果沙箱完成退款而评测仍判错，才是标准设计问题。修复落在源头，后续相似任务才会一起改善。

修复也要做对照实验

改完文档或工具后，不能只重新跑那条失败任务。至少分三组：原失败任务验证是否恢复；相邻任务确认知识能迁移；原本成功任务检查是否被新指引带偏。基线与候选版本使用同一代码提交、容器、依赖、超时和任务顺序，最好随机交错运行，避免某个时间段的网络或模型服务波动只影响一方。

发布报告只需要回答四个问题：红线是否仍为零；目标失败是否明显下降；新失败集中在哪类任务；每次改善付出了多少延迟和成本。若得分提升来自更长重试、更多Token或放宽判定，报告必须显式写出，不能把成本藏在平均分后面。

普通团队的最小落地版本

先选三个高频任务，而不是一口气收集上百道题：接入一个SDK、完成一次版本迁移、修复一个真实错误。每个任务配真值包、受控容器、Trace和独立断言。每周只修一类首错，并保存修复前后的证据。

测试工程师在这里不只是补自动化脚本，而是把产品团队脑中的“正确用法”变成可以反复测量的标准。AI Coding能不能进入企业研发流程，最后取决于团队能否证明它找到对的知识、走了对的路径，并把副作用控制在边界内。

评审人怎样看一条Agent会话

不要从最终Diff开始。先看Agent获取了哪些资料，再看它为什么选择这个SDK与版本，随后检查执行过的命令和测试，最后才看补丁。若它没有打开迁移指南，却在结果里声称“已按最新规范实现”，这是证据缺口；若它读过正确文档却仍调用旧API，则需要检查示例冲突或优先级。

评审记录应把事实与判断分开：事实是“加载了v4文档、package锁定v2、运行了18条Mock测试”；判断是“知识发现成功，但依赖选择与独立验收失败”。这种写法便于平台、文档、SDK和测试团队分别接手，而不会把所有问题都丢回模型团队。

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