只看得分不够：从 agent 轨迹里找 AX 修复点

简短回答：eval 分数只回答“任务有没有完成”，不回答“agent 怎么完成的、花了多少代价、留下了什么副作用”。微软开发者博客在 2026 年 11 月 5 日记录了 Dev Proxy 的一次评估：五次 agent 运行全部产出了能工作的脚本，但轨迹里数出 15 个问题，每次运行消耗 29 到 39 次请求、最高约 120 万 tokens（来源）。

先澄清一个用词：标题里的 AX 指 agent experience（代理体验），说的是 agent 阅读你的文档、调用你的 CLI 和 API 时的体验，不是网页无障碍（accessibility）。材料没有给 AX 下正式定义，这是根据文章内容的推断；如果你在别处看到 AX 指无障碍，那是另一个语境。

分数为什么会把问题过滤掉#

因为 agent 很能坚持。遇到 404 它会换一个 URL，遇到报错它会换一个参数值，缺什么功能它会自己写一段绕行代码。这些动作都会消耗请求和 token，但只要最后一次成功，分数上看不出差别。

材料里的例子很典型：五次运行都完成了“写一个 CI 脚本，用 Dev Proxy API 记录 Node.js 工具调用了哪些 GitHub API”这个任务，五次都通过。但轨迹显示，四次运行在读文档之前先猜了一个并不存在的 URL；五次运行都靠把插件 DLL 当原始字节读出来、再用正则找类名的方式列出插件。后者能用，所以永远不会出现在分数里，但它既不稳也不省。

轨迹里值得优先看的七类信号#

一、先猜 URL，猜不到才搜索

agent 会按训练里见过的文档站结构预测路径。材料中，四次运行尝试了 technical-reference/api，实际页面是 technical-reference/proxy-api；两次运行花五到七步才找到，另外两次干脆放弃文档、只靠记忆。全部四次运行合计有八次请求返回 404。

对应修复：翻 404 日志，找“几乎存在”的文档路径并加重定向；同时在 CLI 输出里直接打印文档 URL，让 agent 不必猜。

二、帮助文本和错误信息只说错、不说对

人看到报错会去打开文档，agent 则把报错当成规格说明。材料里，agent 按列出的端点调用了 /proxy/rootCertificate，收到 400 和一句“format 字段必填”，但没有可选值列表，于是它依次试了 pem、crt、cer、der，只有 crt 有效。每一轮猜测都是一次请求。

对应修复：把 CLI 帮助和最常见的几类错误各跑一遍。每条错误信息里给出一个合法示例，或直接列出允许值。

三、每次运行都重造同一个 workaround

单次运行里出现绕行代码是噪音；每次运行都写同一段，说明产品缺功能。材料里两次这样的信号：报告文件写完后没有完成信号，四次运行轮询输出目录最长 30 秒，第五次直接 sleep 2000 毫秒并注释“让 reporter 把文件刷出来”；以及没有列出插件的命令，五次运行全部去读 DLL。

下面这段是材料给出的读取 DLL 示例，本文未执行，仅用于说明形态：

$b = [IO.File]::ReadAllBytes("$d\plugins\DevProxy.Plugins.dll")
$s = [Text.Encoding]::Unicode.GetString($b)
[regex]::Matches($s, '\b[A-Z]\w*(Plugin|Reporter)\b') | % { $_.Value } | sort -u

对应修复：凡是“调用返回后还要等一会儿才真正完成”的操作，提供一个可查询的完成状态；凡是 agent 需要从中挑选的集合（插件、模板、预设），提供一个列举命令。

四、文档在你的工具边界停下

开发者总是把你的工具和别的运行时一起用，而文档常写到工具边界就结束。agent 会用训练记忆补上这段空白。材料里，让 Node.js 应用走 Dev Proxy 需要 NODE_USE_ENV_PROXY 这个较新版本才支持的开关，五次运行都从记忆里答对了，但没有一次是在 Dev Proxy 文档里找到的。模型记得少一点，结果就是脚本静默地什么都没记录。

轨迹里的表现是：推理段落在陈述一个事实，却没有引用任何来源。

对应修复：列出开发者最常搭配的运行时和框架，逐个补上组合配置示例；对没写的那几个，跑一个任务，看 agent 自己填了什么。

五、agent 会拒绝“第一次运行”的默认配置

默认配置通常是为“五分钟内看到效果”设计的。材料里，Dev Proxy 的默认配置会在示例 API 上注入随机错误，用来证明流量确实经过代理；但任务换成记录真实流量时，它就碍事了。agent 立刻识别并绕开，自己新建配置，三次运行选了三种不同插件，同一个任务得到不一致的结果。

对应修复：保留让第一次运行成功的默认值，同时在旁边为每个常见任务提供预设，并把预设写进 CLI 帮助——agent 很早就读这段。

六、搜索索引里是旧快照

agent 往往通过搜索引擎读你的文档，而索引存的是快照。材料里，Dev Proxy API 从 v3.3.1 起要求 token；一次运行的搜索返回了两条该变更之前的结果，一条是 6 月抓取的乌克兰语翻译，另一条是六周前才更新过鉴权的 agent skill 文件，两者展示的调用都不带 token，而现在会返回 401。本文未实际发起这些请求，这段是材料描述的现象。

对应修复：用 agent 会用的关键词搜一遍自己的文档，把翻译页和你自己发布的 skill 也纳入检查；在每页顶部写明适用版本，让搜索摘要本身就带上版本信息。

七、帮助文本没写的默认值

agent 把帮助文本当字面规格：一个读起来像“开关”的选项，它默认是关的，除非你显式传入。如果它其实是默认开启，agent 永远不会去关它。对大多数选项，代价只是行为和预期不符；但如果这个默认值改变了工具之外的东西，agent 就会交付一个带有它并不知道的副作用的脚本，而任务照样成功，分数照样看不出来。

这篇材料的摘要提到，三次运行会静默改道 CI runner 的网络流量，对应本节讨论的默认值。但抓取到的正文在这里被截断，具体是哪个默认值、如何生效，现有材料无法确认，待核实。

读轨迹的操作顺序#

1. 选三到五个真实任务，每个任务让 agent 独立跑多次，保留完整轨迹，而不是只留最终脚本。
2. 先看请求序列：有没有连续 404、有没有同一参数反复试值、有没有固定等待。
3. 再看重复性：同一段绕行代码是否在多次运行里重复出现。重复是缺功能的证据，单次不是。
4. 然后看推理段落：有没有不引用来源的事实陈述，那就是文档缺口的位置。
5. 最后看副作用：脚本有没有改动工具之外的状态，比如环境变量、代理设置、网络路径。
6. 把发现整理成候选修复点，再用新的 eval 验证修复是否真的减少了请求数和绕行。

三个容易走偏的地方#

• 轨迹是样本，不是统计。五次运行数出 15 个问题，只能说明这些问题存在，不能推出发生率。要判断优先级，得扩大样本或结合日志。
• 别把别人的数字当自己的基线。29 到 39 次请求、约 120 万 tokens 是微软在 GitHub Copilot Chat 加 Claude Sonnet 5.5、无扩展的环境下得到的，模型、工具和任务都不同，数字不可直接比较。
• 修完要复测。轨迹能告诉你哪里可能有问题，不能证明修复有效。补了错误示例、加了列举命令之后，仍要用同一批任务重跑并对比。

小结#

eval 分数是结果指标，轨迹是过程指标，两者回答的不是同一个问题。对做 API 和开发者工具的团队来说，轨迹最实际的价值在于：它把“agent 绕过去了”变成一条条可以修的清单——补重定向、给错误信息加示例、为异步操作提供完成信号、为可选集合提供列举命令、在文档里写清版本和组合方式。这些改动对人同样有用，只是人不会像 agent 那样，把每一次猜测都留在日志里。