智能体完成了任务，并不代表路径合理。一次失败的搜索可能触发第二次搜索，一次被截断的文件读取可能让命令重复抓取同一份内容；正确的最终答案会掩盖这些额外步骤，而它们正在抬高延迟、消耗 token，并增加出错概率。只检查任务是否成功，无法解释智能体为何从工具错误中恢复、为何提前停止，或为何多调用了几次模型。
NVIDIA NeMo Relay 提供的是一层通用观测能力：它记录智能体运行过程中的有序生命周期事件，并以结构化轨迹保存，用 scope 层级表达会话、轮次、模型调用和工具调用之间的父子关系。Hermes Agent 已原生集成 NeMo Relay，可直接产出三类数据。
三类表示各有用途。ATOF 事件流记录工具开始与结束、耗时和错误，通过共享的 uuid 配对同一次调用的起止，用 parent_uuid 关联父级；ATIF 提供逐步轨迹，说明模型请求执行了什么；OpenTelemetry span 带 OpenInference 标签，可在 Arize Phoenix 等工具中查看完整链路。需要注意的是，ATIF 中的工具请求只代表模型"想运行什么"，要确认结果必须回到 ATOF 查看对应的开始、结束事件与错误记录。
官方教程给出两个可复现的例子。第一个是在隔离 Docker 容器中运行终端任务的 Hermes 智能体：脚本固定输出 VALUE=42，runner 以此做精确成功校验，同时确认模型作用域完成、token 用量和零工具错误；容器无法访问网络、仓库代码和 NVIDIA API key，智能体也不能回退到宿主机执行命令。第二个是多工具研究任务：读取旅行记录、搜索网页、在会议官网核验信息、撰写报告，最终返回会议名称 COLT 2026，全部模型与工具 span 送入 Phoenix。
仅有追踪还不够，关键是把轨迹证据与任务验证结果结合。NVIDIA 引用 Hermes ToolPerf 的案例研究：在 108 次运行中对比基线版本与修复版本，结果显示 Qwen Coder 30B 恢复了更多任务，但调用次数、传输数据量和延迟同时上升——成功率提高并不自动等于 harness 更优，必须结合执行证据判断。
教程代码位于 NVIDIA 的 nemoclaw-community 仓库 examples/tools/hermes-relay-tracing，需要 NVIDIA Build API key（示例使用 Nemotron 3.5 Lightning）。NVIDIA 同时提醒，trace 可能包含提示词、模型响应、工具参数与结果、文件路径等应用数据，分享前应先行审查；在安全治理场景中，这类结构化轨迹可作为调查智能体行为、评估策略与构建安全插件的证据层。
WeChat
Profile