当 eval 变成 agent 的训练信号：agent 轨迹审查该看什么

这个问题可以先给一个简短的回答：eval 分数回答“agent 有没有完成”，轨迹回答“它是怎么完成的、在哪里绕了路”。材料里那篇文章的做法，是把轨迹当作产品改进的输入——看 agent 反复在哪里猜、在哪里试、在哪里自己造轮子，然后回头修文档、错误信息和 CLI。需要说明的是，材料讨论的是“信号从哪里来”，不是用 eval 做模型训练的完整流程；如果你关心的是训练侧，本文只覆盖前半段。

以下内容转述自 Microsoft for Developers 博客 2026 年 11 月 5 日的文章 Your best AX fixes are hiding in agent trajectories（标题中的 AX 按上下文指面向 agent 的使用体验，这是推断，材料未给定义）。本次只拿到摘要与截断的正文片段，最后一节不完整，下文会标出。

案例设置：五个能跑的脚本，十五个问题#

文章作者评测的对象是 Dev Proxy，一个拦截应用 HTTP 请求的本地代理。任务设定为：让 GitHub Copilot Chat（使用 Claude Sonnet 5.5、不装扩展）写一个 CI 脚本，调用 Dev Proxy API 记录某个 Node.js 工具访问了哪些 GitHub API，同一个任务跑五次。

结果的分裂很典型：五个脚本都能工作，eval 分数上看不出问题；轨迹里却有 15 个问题，每次运行发出 29 到 39 次请求，最高消耗约 120 万 tokens。文章没有说明 token 的统计口径，这个数字只能作为该次评测的记录，不能外推成基准。

轨迹里该看的七类模式#

下面每一类都按“轨迹里长什么样 → 指向什么修复”来组织。判断依据是跨运行是否重复：只在一次运行里出现的怪步骤可能是噪声，每次都出现的步骤基本可以确定是产品问题。

1. 先猜 URL，猜不中才搜索

agent 往往跳过站内搜索，直接按记忆和文档站的常见结构拼路径。五次运行里有四次在没读任何文档前就请求了 technical-reference/api，返回 404；真实路径是 technical-reference/proxy-api。两次运行多花五到七步才找到，另外两次干脆放弃文档，改凭记忆试错。读文档之后猜测仍在继续：一次运行抓取了 technical-reference/plugins/executionsummaryplugin，而该页实际在 technical-reference/executionsummaryplugin；四次运行合计有八次抓取返回 404。

指向的修复很直接：翻 404 日志里那些“几乎存在”的文档路径，补重定向；在 CLI 输出里直接打印文档 URL，省掉这一步猜测。

2. 接口只差一步：错误说了哪里错，没说什么是对的

Dev Proxy 的端点列表只列方法和用途，不写请求体和必填参数。一次运行照列表调用了 /proxy/rootCertificate，收到 400：{"errors":{"format":["The format field is required."]}}。错误没给合法取值，agent 依次试了 pem、crt、cer、der，只有 crt 成功。

面向人的错误信息可以省略“正确答案”，因为人可以去查文档；agent 把错误信息当规范读，缺了合法值就只能一轮轮试。文章的建议是：跑一遍 CLI help，再手动触发最常见的错误，确认每条信息都给出示例或允许值列表。

3. 每次运行都重造同一个 workaround

这是整篇材料里最有诊断价值的一类。Dev Proxy 在停止录制后不久写报告，但没有“写完了”的信号。四次运行轮询输出目录最多 30 秒，第五次只等两秒：

await api('POST', '/proxy', { recording: false });
await sleep(2000); // let the reporters flush their files

文章判断，这个固定在忙碌的 CI runner 上迟早会失败；轮询更稳，但每次运行都得猜该等哪个文件。

更奇怪的是插件：产品没有列出插件的命令，于是五次运行都把插件 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

这两段代码摘自材料，本次未执行，也不构成对 Dev Proxy 行为的复现。第二段能跑通，所以任何只看结果的评分都发现不了它；轨迹能发现，因为它每次都出现。对应的产品修复是两条：调用返回后才完成的操作需要提供完成信号；agent 需要从中选择的东西（插件、模板）需要一条列举命令。

4. 文档止步于工具边界，agent 用训练记忆补空白

开发者会把工具和其他运行时、框架一起用，而文档常常写到工具边界就停了。例子是让 Node.js 应用走 Dev Proxy：应用侧需要一个近期 Node 版本才支持的开关。某次运行的推理是“undici 默认不认 HTTPS_PROXY，所以需要 NODE_USE_ENV_PROXY，要求 Node 22.21.0+ 或 24.0+”。

注意，这是轨迹中 agent 自己的陈述，本文未对照 Node.js 官方文档核验版本号。文章的关键观察不是它对不对，而是：五次运行都答对了，但没有一次是在 Dev Proxy 文档里找到的。模型知道就成功，不知道就静默写出一个什么都不做的脚本。轨迹里的表现是“陈述了一个事实，却没有引用任何来源”。

5. 默认配置是为第一次运行设计的

默认配置和入门模板服务的是“几分钟内看到东西跑起来”。Dev Proxy 的默认配置会在示例 API 上注入随机错误，用来证明请求确实经过了代理；但要录真实流量，它就是障碍。agent 立刻绕开了：“我应该避免默认配置，它会注入随机错误，所以我要自己建一个配置。”新建的配置是空的，于是每次运行各自搭一套，同一个目标选了三种不同插件。

同一条任务得到不一致的结果，问题不在 agent，在于缺少“面向具体任务的预设”。文章的建议是保留首次运行的默认，同时在旁边为常见任务提供预设，并把预设列进 agent 会早早读到的 CLI help。

6. agent 相信搜索结果，而索引给的是快照

Dev Proxy API 从 v3.3.1 起要求 token。一次运行的搜索返回了两条在此变更之前索引的结果：一份 6 月抓取的乌克兰语 API 参考译文，以及 Dev Proxy 自家 agent skill 里一个在运行前六周已更新认证的文件。两条都展示了不带 token 的调用，而这类调用现在返回 401。该次运行的认证之所以正确，只是因为它先读了 CLI help——help 随安装版本发布，不会过期。

这一类的可控部分有限：你刷新不了别人的索引。能做的是在每页顶部写明版本要求，让它出现在搜索摘要里；并定期用 agent 会用的搜索词，检查搜索结果、译文和自家 skill 描述的是不是当前版本。

7. help text 没写明的默认值（材料此处截断）

材料能确认的部分是：agent 把 help text 当字面规范读，看到像开关的选项就假设默认关闭，如果实际默认开启，它永远不会传入关闭值。对只影响工具内部行为的选项，代价是行为不符预期；对会改变工具之外状态的默认值，agent 会生成一个带未知副作用的脚本——而任务仍然成功，eval 依然抓不到。正文在这一节举 Dev Proxy 的具体例子时被截断，因此这里不补写它默认做了什么，这部分待核实。

把审查落成可重复的流程#

1. 固定任务和模型配置，同一任务至少跑数次，保留完整轨迹而不是只留最终产物。
2. 先按“重复”排序：统计同一类 404、同一段 workaround、同一句无来源断言在几次运行里出现。重复次数是最好的优先级信号。
3. 把轨迹里的失败映射到可修的资产：文档路径 → 重定向；错误信息 → 补合法值与示例；缺失能力 → 完成信号或列举命令；空缺的集成说明 → 在文档里补该运行时的配置；默认值 → 任务预设。
4. 改完再跑同一组任务，比较请求数和轨迹里那类步骤是否消失。材料没有给出这一步的对照数据，属于建议而非已验证做法。

边界与不确定#

• 材料只覆盖一个产品、一个任务、一个模型配置，七类模式的普适性没有跨产品数据支撑。
• 文中所有请求数与 token 数都是该次评测的记录，材料未说明统计口径，不能作为基准或优化目标。
• 最后一节在抓取中被截断，该类的完整案例与结论可能存在于未提供的部分，本文对此不作推断。
• “训练信号”在这里指产品改进的反馈来源；材料没有涉及用轨迹做模型训练的方法与效果。