★ FEATURED ARTICLE 摘要以企业支付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是否检索文档、选择正确依赖、修改最小范围并运行有效验证。defassert_refund_patch(run):assertrun.sdk_versioninrun.allowed_versionsassertrun.auth_modeworkload_identityassertrun.changed_filesrun.allowed_filesassertrun.sandbox.refund_count(order-1024)1assertrun.audit.has(refund_denied)assertnotrun.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和测试团队分别接手而不会把所有问题都丢回模型团队。
阅读完成 · 觉得有帮助？
