一个智能体可以完成任务，但走的路径却并不高效。一次失败的搜索可能触发另一次搜索。一次被截断的文件读取可能导致命令再次获取相同内容。正确的最终答案往往掩盖了这些额外步骤，尽管它们增加了延迟并消耗了更多Token。低效操作也会增加失败的风险。
为了改进智能体的行为，开发者必须理解任务是否成功，以及智能体是如何完成任务的。仅凭成功检查无法解释智能体为何从工具错误中恢复、为何提前停止，或为何需要额外的模型调用。
在本教程中，你将使用NVIDIA NeMo Relay运行两个Hermes Agent示例。你将利用生成的追踪记录来检查模型与工具调用、错误、重试、耗时和Token使用情况，再将这些证据与每个任务的验证结果进行对比。一个Hermes ToolPerf案例研究展示了如何用同样的方法，在多次重复运行中评估智能体执行框架（harness）的变化。
本教程及配套视频将介绍如何：
搭建一个带有原生NeMo Relay集成的隔离Hermes Agent运行环境。
运行一个简单的终端工具任务，检查其事件流和执行轨迹。
运行一个文件与网页研究任务，在Arize Phoenix中查看其OpenTelemetry追踪记录。
结合任务验证与追踪证据，评估智能体执行框架的一处改动。
前提条件
开始之前，请确保你具备：
macOS或Linux系统
Git和curl
已安装并运行Docker Desktop或Docker Engine
一个用于NVIDIA Nemotron 3.5 Lightning的NVIDIA Build API密钥。打开模型页面并选择生成API密钥。
接下来是本教程所用技术的概述，以及它们如何协同工作。
NeMo Relay与Hermes Agent执行框架如何协同工作
NeMo Relay为智能体开发者提供了一种观察和控制模型及工具执行的通用方式。广受欢迎的智能体执行框架Hermes Agent原生集成了NeMo Relay，并在NeMo Relay的作用域层级结构中表示其会话、轮次、模型调用和工具调用。NeMo Relay在工作开始和结束时记录生命周期事件，保留其时序关系和父子关系。
理解追踪输出
NeMo Relay用于智能体可观测性。你将接触到智能体执行的三种表现形式：
一条ATIF工具请求显示了模型要求运行的内容，但并不能确认结果。要验证实际发生的情况，需检查ATOF中匹配的工具开始与结束事件，以及记录的任何错误。它们共享的uuid将事件配对，而parent_uuid将工具调用与其父级关联起来。
分享追踪记录前请先审查。根据你的配置不同，这些记录可能包含提示词、模型回复、工具参数与结果、文件路径以及其他应用数据。
在智能体安全与安全治理方面，NeMo Relay提供了证据层：结构化的追踪记录和执行轨迹，企业、评估人员和安全系统可以用它们来调查智能体行为、评估策略、改进控制措施，或创建扩展Relay功能的专用安全插件。
接下来开始第一个智能体任务运行。
实验一：用Hermes Agent运行一个简单的工具使用任务
第一个示例刻意设计得比较小，这样你可以在加入网页搜索和Phoenix之前，先验证完整的环境搭建是否正常。Hermes使用其终端工具，在一个隔离的Docker容器内运行所附带的Python脚本。该脚本会打印：VALUE=42。
这个固定的输出为运行器提供了精确的成功检查标准。一次通过的运行同时也确认了Hermes成功连接到模型、在沙箱中调用了终端工具，并生成了两份Relay追踪文件。
该容器无法访问网络、代码仓库检出内容或NVIDIA API密钥。Hermes也无法回退到在主机上运行终端命令。
按顺序运行以下命令。复制keys.env之后，继续之前请先在该文件中添加你的NVIDIA API密钥。
（命令部分：克隆教程仓库、进入目录、创建隔离运行环境、复制密钥模板、验证Docker运行状态、构建Docker镜像、运行任务并生成ATOF与ATIF追踪记录）
Hermes Agent和NeMo Relay进程运行在本仓库的本地环境中。Docker单独用于终端工具沙箱和本地Phoenix服务。
仓库中的搭建脚本会在.tutorial-runtime/目录下创建一个自包含环境，包含所有必要的依赖项，例如Python 3.11、Hermes 0.21.1以及NeMo Relay 0.8.3。它不会修改你现有的Python或Hermes安装。
任务完成后，运行器会检查响应内容及两份追踪文件。一次通过的运行会打印验证结果，随后输出ATOF和ATIF摘要。
查看追踪摘要
Hermes完成任务后，运行器会验证预期结果及生成的追踪记录。它会检查终端命令是否成功，ATOF追踪中是否包含完整的LLM活动记录（带Token使用情况且无工具错误），以及是否生成了非空的ATIF执行轨迹。以下输出来自一次已验证的运行。Token数量、标识符和文件路径在不同运行中可能有所不同。
ATOF摘要显示：事件数74，已完成的LLM作用域2个，带使用数据的LLM作用域2个，提示词Token 7239，补全Token 96，总Token 7335，工具调用1次，工具错误0次，相关事件74个。
ATIF摘要显示：智能体为Hermes Agent，模型为nvidia/nemotron-3.5-lightning-30b-a3b，步骤数3，LLM调用2次，请求的工具调用1次。任务已验证：VALUE=42。产物路径：.../artifacts/runs/<run-id>
请关注“Task verified: VALUE=42”这一行，它确认了预期结果。ATOF摘要报告了已完成的模型作用域、Token使用情况、工具调用及工具错误。ATIF摘要将同样的执行过程呈现为一个三步的执行轨迹。
Artifacts:后的路径指明了包含完整ATOF事件流和ATIF执行轨迹的运行目录。配套仓库中说明了如何再次检查或汇总这两份文件。
实验二：运行多工具研究任务并探索其追踪记录
在验证完基础环境搭建之后，第二个示例使用相同的Hermes和NeMo Relay环境，执行一个需要多种工具的任务。Hermes会收到一份旅行记录，其中包含关于一个未具名机器学习会议的线索。它必须读取该记录，找到与主题、日期和地点匹配的会议，在官方网站上确认答案，将已验证的信息保存到一份报告中，并返回会议名称。
使用NeMo Relay的OpenInference导出器，通过OTLP（OpenTelemetry协议）将OpenTelemetry跨度发送到Arize Phoenix。Phoenix将运行过程以交互式追踪记录的形式展示，你可以查看模型与工具调用、时序、Token使用、错误以及可用的输入输出内容。
你可以通过更改端点和认证设置，将同样的OpenTelemetry追踪记录发送到其他兼容OTLP的后端，例如LangSmith。NeMo Relay可观测性指南中介绍了其他可用的导出器及配置选项。
该示例复用了第一个示例中的NVIDIA Nemotron模型和NVIDIA API密钥。Hermes使用其内置的无密钥网页搜索功能，运行器会在固定版本的本地容器中启动Phoenix。运行会议搜索示例脚本即可开始。
运行过程中，NeMo Relay会在本地保存ATOF事件流和ATIF执行轨迹。
在报告成功之前，运行器会检查Hermes是否：
识别出了COLT 2026这一会议名称
保存了一份包含预期会议详情及官方来源的报告
成功完成了read_file、web_search、web_extract和write_file调用
生成了非空的ATIF执行轨迹
向Phoenix发送了带有正Token使用量的模型和工具跨度
检查通过后，终端输出会包含Phoenix项目链接以及本地运行目录。在Phoenix中打开该项目，即可跟踪智能体从最初的文件读取，到网页搜索、来源验证、报告撰写，再到最终回复的整个运行过程。
用另一个模型尝试该任务
要查看另一个模型如何处理同样的会议查询，可按照配套仓库中的模型配置文件说明操作。保持查询内容、可用工具、执行限制和验证器不变，这样你就可以观察执行路径的差异。
由于该任务使用的是实时网页搜索，建议用这些运行来探索行为差异，而非对模型进行排名。要进行可控的比较，需要固定的搜索响应和重复运行。
用追踪记录评估智能体执行框架的改动
这两个示例展示了如何验证结果并检查单次运行。而评估一处执行框架改动，则需要在受控、重复的条件下进行同样的检查。
智能体执行框架评估步骤
选择一个有精确、自动化成功检查标准的固定任务。
定义一个基线版本，以及对提示词、工具、配置或执行框架所做的一处聚焦改动。
除该项改动外，保持其他一切不变，包括模型版本、提供商、任务输入、执行预算和超时设置。
在启用NeMo Relay的情况下，对基线版本和候选版本运行相同次数的重复测试。
首先比较已验证的任务结果，然后利用追踪记录检查模型调用、工具调用、重试、错误、耗时、Token使用量和成本。
在将结果推广之前，针对该改动预期支持的模型或工作负载重复进行评估。
只有当候选版本在任务完成率上产生可重复的提升，或者在保持完成率的同时改善了你所关注的可靠性、延迟或成本指标时，才能称其为一种改进。一次更快的运行或更少的调用次数可以帮助解释结果，但二者都不能单独证明这是一种优化。
结果不变同样具有意义，它可以说明某个看似的改进其实依赖于特定的模型、环境或样本。
评估Hermes工具层改动的基准案例研究
Hermes ToolPerf基准测试由Nous Research开发，其方法是分析生产环境中的会话、审查工具模式，并从生产会话日志中挖掘失败类别。随后，他们使用NeMo Relay的ATOF追踪记录作为轮次统计的真实依据。通过检查九种失败模式，他们将结果转化为确定性的基准测试案例，并用其评估了一批Hermes工具层修复方案。
8月6日的重跑测试比较了Hermes的固定基线版本与修复版本在九项任务上的表现。每个任务每个模型每个版本组运行三次，总计108次运行，全程使用相同的提示词、工具、执行限制和成功检查标准。任务验证器衡量完成情况，NeMo Relay的ATOF追踪记录捕获了模型调用、工具调用、错误、重试、工具结果数据和时序信息。
在此次运行中，Sonnet没有出现实质性变化。它在基线版本中完成了27次运行中的24次，在修复版本中完成了27次中的23次，相差仅一次运行。其轮次、工具调用和结果数据在两个版本组中均相同。
Qwen Coder则是修复方案真正起作用的地方，但效果是双向的。它成功完成的任务多了三个，从27次中的19次提升到22次。但它也付出了更多努力：平均LLM调用次数从3.8次升至4.9次，工具调用次数从2.8次升至3.9次，工具结果数据量从16KB增至33KB，耗时从27秒增至42秒。修复方案让基线版本放弃的任务转为成功，代价是智能体变得更慢、调用也更频繁。
任务级别的审查揭示了这些权衡的来源。
在被阻止命令的任务中，基线版本的Qwen在解析器阻断处失败，得分仅为33%，而修复版本的恢复机制将其提升至100%。这种恢复正是轮次数增加的原因：恢复需要消耗额外轮次，而放弃则不会产生这种消耗。
大小写不敏感搜索任务的情况则相反。零匹配探测的输出结果在三次重复中的两次里，将Qwen推向了额外的探索性搜索，使其轮次从3.3次增加到9.3次，这一退化值得单独关注。
隐藏文件搜索任务在两个版本组及两个模型上均保持在0%到33%之间，与最初运行发现的差距相同，在当前这些版本上仍未解决。
仅凭任务的成功或失败本身无法得出这一结论。NeMo Relay的追踪记录记录了全部108次运行中每一次模型调用、工具调用、错误、重试、结果负载和时序信息。Qwen额外增加的轮次是恢复性操作而非盲目尝试，而那一项任务的退化可以追溯到一个具体的探测输出。这些追踪记录已归档进结果目录，任何人都可以解包并据此重新生成这些表格。
开始评估智能体追踪记录
NeMo Relay为你提供了一种一致的方式来捕获证据，以评估优化智能体执行框架的各项改动。ATOF保留了有序的生命周期事件，而ATIF则将同样的工作呈现为可读的执行轨迹。将这些追踪记录与确定性验证器配合使用，能让你在比较执行框架改动时，不会将“更少的调用次数”误当作“更好的结果”。
配套仓库提供了示例产物，包括本文中使用的可运行任务、验证器、NeMo Relay配置和Phoenix设置。
Q&A
Q1：NeMo Relay是什么？它有什么作用？
A：NeMo Relay是NVIDIA推出的一种智能体可观测性工具，能为开发者提供观察和控制模型及工具执行的通用方式，帮助记录会话、轮次、模型调用和工具调用的生命周期事件及其父子关系。
Q2：ATOF和ATIF有什么区别？
A：ATOF记录的是有序的生命周期事件流，包含工具开始、结束及错误信息；ATIF则将同样的执行过程呈现为一个可读的任务执行轨迹，两者结合可以帮助开发者全面理解智能体的行为过程。
Q3：Hermes ToolPerf基准测试发现了什么？
A：该测试对比了Hermes基线版本与修复版本在九项任务上的表现，发现修复后Qwen Coder完成任务更多，但调用次数、耗时和数据量也相应增加；而Sonnet模型基本没有变化，说明修复效果因模型而异。
