AI总能把代码写出来，为什么一接公司接口就开始“凭经验乱猜”？

摘要：以微软公开提出的Agent Experience为入口，拆解Coding Agent生成过期SDK、误选接口和假成功的原因，并给出文档可发现性、可执行样例与竞争性回归方案。

研发把一个新接口交给Coding Agent接入。几分钟后代码生成完毕，语法检查通过，单元测试也能运行。真正联调时却发现，它调用的是两年前的SDK方法，还把已经废弃的字段写进请求体。

团队第一反应通常是“模型知识旧了”。但换一个更强模型，问题可能仍然存在。Agent搜索不到最新文档、示例缺少版本、CLI错误信息不给修复方向、旧页面在搜索结果中排名更高，都会把它推向错误路径。

微软在2026年10月6日把这类问题概括为Agent Experience，也就是AI Agent发现、选择和使用一项技术时获得的体验。过去我们只测试人能否看懂API；现在还要测试Agent能否从文档和工具反馈中稳定得到正确实现。

这篇文章不讨论如何让AI多写代码，而是给出一套“API面向Agent”的质量验收：它能否找到、能否选对、能否跑通、失败后能否自我修正，以及版本变化后能否持续保持。

旧办法为什么开始失效

传统开发者体验强调导航清晰、示例完整、错误提示友好。Agent不会像人一样耐心浏览目录，它往往依赖搜索片段、上下文文件、README、类型信息和工具返回。对人很明显的“新版请点击这里”，对Agent可能只是一个没有进入上下文的链接。

更麻烦的是，Agent会补全缺失信息。参数说明不清，它可能根据别家SDK猜一个字段；示例没有错误分支，它可能把200响应当成业务成功；新旧版本同时存在，它可能选择训练数据里出现更多的旧写法。

因此，API测试不能只验证服务端契约，还要验证“Agent看到的契约”。这包括搜索结果、代码示例、Schema、类型声明、CLI帮助、错误消息和迁移指南。

建一组真正像Agent任务的用例

不要只问“这个接口怎么调用”，而要给Agent一个完成型任务，例如：为退款服务增加Python SDK调用；要求支持幂等键；失败时输出可追踪请求ID；不得使用已废弃的refund.create_v1。

评测结果至少分四层：是否选对当前版本；参数是否来自正式Schema；生成代码能否在干净环境运行；运行失败后是否根据错误信息修复，而不是换一个未经允许的接口。

FORBIDDEN = {"refund.create_v1", "legacy_refund"}

def assert_agent_patch(trace, files, run):
    joined = "\n".join(files.values())
    assert not any(name in joined for name in FORBIDDEN)
    assert "Idempotency-Key" in joined
    assert trace["docs_version"] == "2026-10"
    assert run["exit_code"] == 0
    assert run["created_refunds"] == 1
    assert run["request_id"]

这段断言把“看起来会调用API”升级为业务判断：没有用旧版本、带了幂等控制、在当前文档版本下运行成功，而且只创建一次退款。

一定要加入竞争性场景

真实环境里不会只有一份正确文档。至少准备三类干扰：搜索结果中保留旧版教程；仓库里存在另一语言的相似示例；错误提示只给出状态码但不说明字段变更。观察Agent会不会被更熟悉但错误的路径吸走。

还可以做“文档变异测试”：删掉版本标签、替换一个参数名、把成功示例换成过期写法，看看评测能否及时下降。若文档已经损坏而指标毫无变化，说明评测集根本没有覆盖Agent真正依赖的信息。

不要只测一个模型

某份文档对模型A友好，不代表对模型B也可发现。模型、Harness、上下文窗口和检索策略都会影响路径。建议用至少两种Agent配置执行同一组任务，并把差异定位到“发现、选择、执行、恢复”四个阶段。

例如A能找到正确页面却生成错误参数，是Schema表达问题；B始终找到旧页面，是检索与版本标识问题；两者都在错误后反复重试，则需要改进错误信息和停止条件。这样的报告比一句“某模型成功率更高”更能指导工程修改。

AX的质量门禁怎么落地

每次发布SDK、CLI或文档时，CI自动选择十几个关键任务，让Agent在干净容器里从零完成。记录它读取了哪些页面、生成哪些文件、执行哪些命令、失败后如何恢复，并用业务断言验证最终环境。

门禁可分三层。第一层是确定性禁止项：旧API、明文密钥、跳过证书校验，一次出现就失败。第二层是任务成功：项目可安装、测试能运行、真实测试环境产生正确对象。第三层是效率与稳定性：多次运行成功率、平均修复轮次、Token与时间成本。

当文档更新导致Agent成功率下降，不要立即把责任推给模型。先比较Trace：旧页面是不是更容易被检索；示例是不是缺少完整import；Schema是不是没有解释条件字段；错误提示能不能指向迁移文档。AX测试的价值，就是把“AI总在乱猜”变成可以定位、可以回归的问题。

测试工程师的新机会

测试人员最擅长把隐含规则变成可验证条件。以前我们为人设计用例，现在还要为Agent设计任务。接口契约、兼容性、文档质量、环境可复现、错误恢复，这些并不是新概念，只是被一个非确定性的使用者重新组合。

普通团队可以从一个最常被AI用错的内部API开始：准备一个正确任务、两个干扰文档、一个失败反馈和一组业务断言。持续跑一周，你会得到一份真正有价值的Agent Experience基线，也会第一次看见公司的技术为什么“人会用，AI却不会用”。

做一次“新手Agent测试”比看文档点击量更有用

可以每周创建一个没有历史缓存、没有人工提示的新Agent，让它从搜索入口完成三个真实任务。不要提前告诉它正确页面，也不要把最新示例直接塞进上下文。只有这样，才能测出技术资产在自然发现路径上的表现。

记录它第一次搜索词、打开页面顺序、复制的代码版本、第一次运行错误以及最终修复方式。若团队每次都靠人工把正确文档喂给Agent，测到的是提示工程，不是Agent Experience。

文档团队和测试团队怎么分工

文档负责人保证版本、示例和迁移关系清晰；SDK负责人提供机器可读Schema、类型与错误信息；测试负责把高频开发任务变成回归集，持续验证不同Agent能否完成；平台团队保存Trace和环境证据。

当失败发生时，先根据阶段分派，而不是笼统报“模型生成错误”。发现失败归文档可发现性，选择失败归版本与接口描述，执行失败归示例和环境，恢复失败归错误反馈。责任边界清楚后，Agent使用API才会从偶然成功变成可运营质量。

旧版本退役也要测试

搜索入口是否给旧页面降权，旧示例是否明确标注替代版本，错误提示是否能把Agent引向迁移文档，都是版本治理的一部分。让Agent稳定离开旧路径，才算真正完成SDK升级。

还有一条负向用例值得固定下来：文档只公开了查询接口，没有公开写入字段时，Agent是否会根据旧示例猜一个参数继续调用。合格行为应是明确说明信息不足、保留已找到的证据并停止，而不是用一次偶然成功掩盖接口资产缺口。

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