用 NVIDIA NeMo Relay 和 Phoenix 追踪评估 Hermes 智能体

当一个 AI 智能体给出答案时，你看到的往往只是故事的结尾。它到底调用了哪些工具？这些工具返回了什么？它把大部分时间花在了哪里？这些问题在传统的「问答式」交互中几乎被完全隐藏。NVIDIA 技术营销工程师 Patrick Moorhead 在一段演示中展示了如何用 NeMo Relay 对 Hermes 智能体进行链路追踪，并在 Phoenix 中可视化整个执行过程——真正把智能体的「黑箱」打开来看。

为什么要追踪智能体，而不只是看答案

一个智能体最终输出的文本，掩盖了它背后复杂的决策链条。它可能读取了本地文件、发起了多次网络搜索、调用了内容提取工具，甚至写入了中间报告。如果只看最后一行结论，你无法判断答案是否可靠，更无从知道该从哪里着手改进。

Moorhead 的核心观点很直接：验证一个智能体能工作只是起点，真正有价值的是用 trace（追踪记录）去理解「它实际做了什么」，再基于证据评估下一步的改动。这其实是把软件工程中成熟的可观测性（Observability）理念，迁移到了 AI Agent 的开发流程中。对于构建生产级智能体的团队来说，这种「证据驱动」的迭代方式比凭直觉调 prompt 要靠谱得多。

**可观测性（Observability）**源自控制论与分布式系统工程，核心思想是：通过系统对外暴露的输出（日志、指标、追踪）来推断其内部状态，而无需修改系统本身。在微服务领域，OpenTelemetry 等标准已将「Traces / Metrics / Logs」三支柱确立为可观测性的基础。将这一理念迁移到 AI Agent 时，面临独特挑战：智能体的执行路径是动态决策的，工具调用顺序、次数甚至类型都可能随输入变化，无法像传统服务那样预先画出固定的调用图。因此，AI Agent 的可观测性更强调对「运行时轨迹」的完整记录，即每一次 LLM 推理和工具调用都要有可查的输入输出快照，而不仅仅是聚合统计指标。

环境准备：Hermes 与 NeMo Relay 的原生集成

演示从克隆仓库、打开 Hermes Relay 示例开始。值得关注的一个设计细节是：NeMo Relay 会随 Hermes 安装被原生集成，无需额外单独部署。Moorhead 从 main 分支拉取代码时，终端底部已经能看到 NeMo Relay 的标识。

他在这里特意拉取了第二份 Hermes 副本，用来和日常开发环境隔离，避免互相干扰——这是一个实用的工程习惯。接下来是配置密钥：把 NVIDIA build key 填入配置文件即可，这个 key 可以在 build.NVIDIA.com 免费获取。

最后一步是构建沙箱镜像（sandbox image），Hermes 会在这个沙箱里执行命令。在教程场景下，这个沙箱被设置为无网络、无密钥，相当于一个受控的隔离执行环境。这种沙箱机制对于让智能体安全地运行任意脚本至关重要。

Hermes 是 NVIDIA 推出的 AI Agent 框架，设计目标是让智能体能够安全地在沙箱环境中执行代码与工具调用。NeMo Relay 则是 NVIDIA NeMo 生态中的可观测性组件，负责在智能体运行时拦截并结构化记录每一次 LLM 调用与工具调用的输入输出、耗时等元数据，再以 OpenTelemetry 兼容格式将这些追踪数据导出到外部分析平台。Phoenix 是由 Arize AI 开源的 LLM 可观测性平台，专为 LLM 应用与 AI Agent 设计，能够接收 OpenTelemetry 格式的 trace 数据并提供交互式的 span 级可视化、延迟分析和输入输出检查界面。三者的分工清晰：Hermes 执行任务，NeMo Relay 采集数据，Phoenix 呈现与分析——构成一条完整的「执行→记录→洞察」链路。

从最简单任务开始验证

Moorhead 没有一上来就跑复杂流程，而是先给 Hermes 一个「最小可验证」任务：运行一个脚本，告诉我它打印了什么。预期答案是 42。

这一步看似琐碎，实则是方法论的体现——先确认整条链路（智能体执行、Relay 记录、结果回传）能跑通，再逐步加码。运行后，结果正确返回 42，同时 Relay 完整记录下了这次执行。这种「先验证最小闭环再扩展」的思路，正是可观测性工具区别于普通日志打印的地方。

真实任务：一次完整的多工具编排

验证通过后，Moorhead 给出了一个贴近真实场景的任务：一份 6 月 29 日到 7 月 3 日的圣地亚哥旅行计划。Hermes 需要读取计划、执行网络搜索、在网站上进行核实，然后撰写报告并给出答案。

这次运行时，Relay 会把追踪数据实时导出到 Phoenix。执行顺序是 Phoenix 先启动，然后 Hermes 开始工作，搜索实时进行。这个任务串联了文件读取、网络搜索、内容提取、文件写入、结果核实等多个工具调用，是检验追踪能力的理想样本。

在 Phoenix 中逐步拆解执行链路

打开 Phoenix 给出的 URL，就能看到刚刚运行的 Hermes session。点进去，整个 trace 以「turn by turn」（逐轮）的方式呈现，清晰地展示了智能体每一步做了什么。

具体来看，trace 中可以观察到：智能体先读取了文件（能看到文件路径和返回内容），接着执行网络搜索（能看到它写的查询语句和搜索结果），然后额外调用了网页内容提取，再调用写文件工具生成报告，最后由验证器（verifier）读取报告，并输出最终结论。

这种可视化带来的价值是直接的：你不再需要猜测智能体「大概做了什么」，而是能逐步看到每个工具的输入输出。当某次运行结果不理想时，trace 能帮你快速定位是搜索查询写得不好、提取内容有偏差，还是验证环节出了问题。

Phoenix 中展示的追踪结构本质上是一棵 Span 树。每个 Span 代表一次离散操作（如一次 LLM 推理或一次工具调用），记录了开始时间、结束时间、输入参数与返回值。「Turn by turn」的展示方式对应智能体的每一轮「思考-行动」循环（ReAct 模式下即一次推理加一次工具调用）。通过查看 Span 的时间轴，开发者可以直观发现哪个工具调用耗时最长，是否存在冗余的重复搜索，或者某次工具返回了空结果却没有触发重试逻辑。这种粒度的可见性是单纯打印最终答案或查看文本日志所无法提供的，也是调试多步骤智能体时缩短排查时间的关键。

可观测性是智能体工程化的起点

这段演示的真正意义，不在于展示某个单一功能，而在于传递一套智能体开发的工作流：验证它能工作 → 用 trace 理解它实际做了什么 → 基于证据评估下一次改动。

NeMo Relay 负责采集和导出追踪数据，Phoenix 负责可视化与分析，两者配合构成了智能体的「飞行记录仪」。随着智能体承担越来越复杂的多步骤任务，这类可观测性工具会从「锦上添花」变成「不可或缺」。对于正在从 demo 走向生产的 AI Agent 团队，Moorhead 展示的这套链路追踪方法，提供了一个值得参考的落地范式。相关的可运行示例和更详细的说明可以在对应的 GitHub 仓库与博客链接中找到。