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 放在一起：先用固定任務及成功檢查確認結果，再用軌跡解釋模型呼叫、工具重試、錯誤及成本如何變化。這比把「少用了幾次工具」直接當作效率改善更可靠，也能幫助團隊識別某個修正只對特定模型、任務或環境有效。
