NVIDIA 于 2026 年 9 月 30 日介绍 NeMo Relay，一个为 AI agent 提供共同 observability layer 的工具。它捕捉有顺序的 lifecycle events 和结构化 trajectories，让开发者不只知道 agent 最后是否完成任务，也能检查它用了多少模型调用、工具操作、重试、错误、时间和 tokens。
文章以 Hermes Agent 作示范。Hermes 内置 NeMo Relay 集成后，可以产生 ATOF event streams、ATIF 逐步 trajectories，以及带有 OpenInference 标签的 OpenTelemetry spans，再在 Arize Phoenix 等工具中查看。ATOF 主要用来重建单次执行的事件、时间和父子关系；ATIF 则把互动整理成逐步的 agent 路径；OpenTelemetry 适合检视模型和工具 spans、延迟、token 使用量及错误。
这个分层很重要，因为 model 的 tool request 并不代表工具真的成功。NVIDIA 明确提醒，要确认结果，需要对照相同 uuid 的 tool start、tool end 和 error events，并查看 parent relationship。只保存 agent 的最终答案，会把中间的失败搜索、重复读文件或错误恢复全部隐藏，令团队难以判断 harness 改动到底改善了什么。
NVIDIA 分享的 Hermes ToolPerf case study 比较固定 baseline 和修正版，在两个模型上合共 108 次执行。文中一个 Qwen Coder 30B 例子由 baseline 的 19/27 任务成功上升到修正版的 22/27，但平均 LLM calls 由 3.8 增加到 4.9、tool calls 由 2.8 增加到 3.9、tool-result data 由 16 KB 增加到 33 KB，平均时间由 27 秒增加到 42 秒。这说明较高成功率可能伴随更多恢复步骤，不应只看单一成功率数字。
NeMo Relay 的另一个实际限制是 trace 本身可能包含 prompt、模型回复、tool arguments、结果、文件路径及其他应用数据。这些资料在传送到 Phoenix 或其他 OTLP backend 前需要审查和适当遮蔽。Observability 可以成为治理的证据层，但也会成为新的敏感数据面，不能因为是 debug log 就自动视为没有风险。
对于 agent 团队来说，较完整的评估方法是把 deterministic verifier 与 trace 放在一起：先用固定任务及成功检查确认结果，再用轨迹解释模型调用、工具重试、错误及成本如何变化。这比把「少用了几次工具」直接当作效率改善更可靠，也能帮助团队识别某个修正只对特定模型、任务或环境有效。
