agent 轨迹作为可观测性数据：从执行路径反推可用性修复点

可以，但有条件。eval 分数回答的是“任务有没有完成”，轨迹回答的是“完成得多费劲、路上绕了什么”。把多条轨迹放在一起看，重复出现的绕路才指向产品缺口；单条轨迹里的怪步骤，更可能只是一次噪声。

所谓轨迹（trajectory），指 agent 执行过程中留下的逐步记录：调用了哪个工具、传了什么参数、拿到什么返回、以及它为什么这么选。它和最终输出、eval 分数是两类数据。分数是二值的，过程是有成本的。

分数通过，为什么还要看轨迹#

Microsoft 开发者博客在 2026 年 11 月 5 日的一篇文章里描述了一次评估：使用 GitHub Copilot Chat 与 Claude Sonnet 5.5、不装扩展，让 agent 五次执行同一任务——写一个 CI 脚本，通过 Dev Proxy 的 API 记录某个 Node.js 工具调用了哪些 GitHub API。五个脚本都能工作，分数上看不出异常；但轨迹里记录了 15 个问题，每次运行消耗 29 到 39 次请求，最高到 120 万 token（来源）。

原因不复杂：agent 很“执着”。遇到 404 就换一个 URL，遇到报错就换一个参数值，直到错误消失。失败被它自己消化掉了，于是分数干净，过程很脏。而它反复试错的位置，往往正是人类开发者会停下来查文档、或者干脆放弃的位置。

标题里的 AX，按上下文指 agent 使用产品时的体验，可对照 DX（developer experience）。这是对用词的解读，来源没有给出正式定义。

六类轨迹信号与对应的修复点#

1. 先猜 URL，再搜索

来源描述：五次运行中有四次在读文档之前，先去请求 .../technical-reference/api，返回 404；真实路径是 .../proxy-api。两次运行多花了五到七步才找到，另外两次直接放弃文档，改为凭记忆试错。找到正确页面后，又有运行按导航结构推测 .../plugins/executionsummaryplugin，而该页实际在 .../executionsummaryplugin。四次运行累计八次 404。

对应的修复点：文档 URL 结构对团队来说“合乎逻辑”不够，agent 是按模式预测路径的。可以翻 404 日志里那些“几乎存在”的路径，逐个加重定向；也可以在 CLI 输出里直接打印文档 URL，省掉猜测。

2. 错误信息只说错，不说对

来源描述：一次运行按帮助文本调用 /proxy/rootCertificate，得到 400，响应里只有 format 字段必填，没有列出合法值。agent 依次试了 pem、crt、cer、der，只有 crt 成功。

人类看到这种报错会去翻文档；agent 把帮助文本和错误消息当成规格说明，于是每一轮猜测都对应一次请求。修复方式很直接：让常见错误消息给出有效值列表或一个可用的示例。

3. 每次运行都重写同一个绕过

这是判断“是噪声还是缺口”的关键信号。来源描述了两个例子。其一，Dev Proxy 在停止录制后写报告，但没有“写完”的信号，四次运行轮询输出目录最多 30 秒，第五次干脆 sleep(2000)；在繁忙的 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

以上为来源中给出的 PowerShell 片段，本文未执行，也不对其在当前版本上的可用性作判断。它能工作，所以分数永远不会显示它；但它在每次运行里都出现，这就是轨迹能提供、而分数提供不了的信息。

对应的修复点：凡是“调用返回之后才完成”的操作，需要一个告诉 agent 已完成的信号；凡是 agent 需要从中挑选的东西，比如插件、模板，需要一个列举命令。

4. 缺的集成知识由模型记忆补

来源描述：要让 Node.js 应用走 Dev Proxy，应用的 fetch 需要一个较新 Node 版本才支持的开关。五次运行都“知道” NODE_USE_ENV_PROXY 以及 22.21.0+ / 24.0+ 的版本要求，但没有一次是从 Dev Proxy 文档里读到的。这次模型恰好知道；换一个知道得更少的模型，代码会看起来正确、实际什么都不做，而且不报错。

在轨迹里，这类缺口表现为“陈述了一个事实，但没有引用来源”。对应的修复点：列出开发者常与本产品搭配的运行时和框架，把每个组合的接入步骤写进文档；对没写的组合，跑一次任务，看 agent 自己补了什么。

5. 默认配置被当成障碍

来源描述：Dev Proxy 的默认配置会在示例 API 上注入随机错误，用于首次运行时确认流量确实经过代理。但对“录制真实流量”这个任务，agent 立刻判断要绕开它，自己新建配置；而新建出来的是空配置，五次运行因此选了三种不同插件，同一任务得到不一致的结果。

对应的修复点不是删掉默认值。默认值让首次运行能跑通，这个作用应当保留；缺的是为每类常见任务准备预设，并把预设写进 agent 会早早读到的 CLI 帮助里。

6. 搜索结果里的旧快照

来源描述：从 v3.3.1 起，Dev Proxy 的 API 需要 token。一次运行的搜索结果里出现了两条索引于该变更之前的内容，其中一条是乌克兰语翻译，另一条是产品自带的 agent skill 文件；两者都展示了不带 token 的调用，而这类调用现在返回 401。该运行最终做对，是因为它先读了 CLI 帮助——帮助文本随安装版本发布，不会过期。

对应的修复点：站在 agent 的角度，用它会用的关键词搜一遍，检查结果（包括翻译页和自带的 skill）描述的是不是当前版本。别人的索引没法直接刷新，但可以在每页顶部写明版本要求，让它出现在搜索摘要里。

7. 帮助文本没有声明的默认值

来源在这里被截断，只留下了方向：当某个选项在帮助里写成像“需要打开”的开关，agent 会默认它是关闭的；如果它其实是默认开启，agent 就永远不会传关闭它的值。多数情况下这只是行为与预期不符；但如果这个默认值会改变产品之外的东西，脚本就会带上一个 agent 不知道的副作用，而任务仍然成功，eval 同样抓不到。完整例子待核实。

把轨迹变成修复清单的流程#

1. 固定任务、固定模型与工具配置，重复跑同一任务若干次。来源用的是五次；次数越多，“重复模式”和“偶发噪声”越容易分开。
2. 确保轨迹包含工具调用、参数、返回和推理依据。只有最终输出，无法反推它在哪一步犹豫。
3. 逐条标注四类现象：多余请求（404、重试）、重复绕过、无来源的事实断言、被绕开的默认配置。
4. 只把跨运行重复出现的项排进修复队列。单次出现的怪步骤先记为观察项。
5. 修复后跑同一任务复测，比较请求数、步数和 token 消耗，而不只是看任务是否完成。
6. 轨迹会包含内部 URL、路径甚至凭据，落盘和共享前先脱敏。

这套流程是根据来源案例归纳的建议，不是本文执行的测试；效果需要在各自产品上验证。

边界与待核实#

• 来源是一篇博客，且正文抓取被截断，第七类信号的完整结论可能落在未提供的部分，本文没有替它补全。
• 文中的数字来自单一产品的一次评估，不能外推到其他产品的请求数或 token 成本。
• Dev Proxy 的当前版本、API 是否仍需 token、Node 版本要求，应以官方文档为准，本文未做核验。
• 404 日志分不清访问者是人还是 agent，它只能提供候选路径，不能单独作为结论。

轨迹的价值不在于证明 agent 行不行，而在于把“它在哪里猜错了”翻译成产品该改的地方。分数告诉你任务完成了，轨迹告诉你这次完成得值不值。