英伟达技术博客：如何通过执行轨迹评估智能体框架的改进
文章介绍了使用 NVIDIA NeMo Relay 捕获 Hermes Agent 的执行轨迹（ATOF/ATIF），以分析模型调用、工具使用和重试情况。通过一个基准测试案例，展示了如何区分“成功恢复”与“低效挣扎”，指出仅看最终结果无法判断框架变更是否真正优化了性能。
重要性实质性证据E3 可检验写法快讯
在开发 AI 智能体时，一个常见的陷阱是认为只要任务完成就算成功。然而，智能体可能通过低效的路径完成任务，例如因搜索失败而重复搜索，或因文件读取截断而重新获取内容。这些额外的步骤虽然隐藏了最终答案的正确性，却增加了延迟并消耗了更多令牌，同时也创造了更多失败的机会。要真正理解智能体的行为并评估框架（Harness）的变更，开发者不仅需要知道任务是否成功，还需要知道它是如何完成的。
NVIDIA 的技术博客文章《Tracing Agent Harness Behavior with NVIDIA NeMo Relay》提出了一种基于执行轨迹的评估方法。该方法利用 NeMo Relay 提供的可观测性层，捕获智能体运行时的有序生命周期事件和结构化轨迹。文章重点介绍了两种格式：Agent Trajectory Observability Format (ATOF)，用于调试单个事件的时间戳和父子关系；以及 Agent Trajectory Interchange Format (ATIF)，用于逐步审查智能体的交互路径。此外，这些轨迹还可以转换为 OpenTelemetry 跨度，以便在 Arize Phoenix 等工具中进行可视化检查。
为了说明这一机制的实际应用，文章引用了一个名为 Hermes ToolPerf 的基准测试案例研究。该研究比较了 Hermes Agent 的基线版本和修复版本在 108 次运行中的表现。结果显示，对于 Qwen Coder 30B 模型，修复版本虽然提高了任务成功率（从 70% 升至 81%），但也显著增加了平均 LLM 调用次数（从 3.8 增至 4.9）、工具调用次数、数据量和延迟。如果仅看成功率，可能会误以为这是纯粹的改进；但结合轨迹分析，可以发现这种改进是以更慢、更“啰嗦”的智能体为代价的。
进一步的任务级审计揭示了这种权衡的来源。在某些被阻塞的命令任务中，基线版本的 Qwen 直接失败，而修复版本通过恢复策略成功完成任务，这解释了为什么回合数会增加——恢复需要花费那些放弃时不会花费的回合。相反，在一个不区分大小写的搜索任务中，零匹配探测输出导致 Qwen 进行了额外的探索性搜索，造成了性能回归。这表明，只有将确定性的验证器与详细的执行轨迹相结合，才能准确评估框架变更的真实影响，避免将较少的调用次数误认为是更好的优化。