将生产环境中的证据转化为按优先级排列的问题和自定义评估，帮助你改进提示词、工具、模型、记忆、技能和 harness 代码。
当你为所在领域构建 agent 时，通用基准测试分数可能无法解释它的失败。agent 可能选错工具、走错工作流分支、遗漏相关上下文、使用不必要的高成本模型，或者完成任务却未满足特定领域要求。
改进 agent 需要的不仅仅是模型调优。提示词、工具、路由、记忆、技能、控制流以及其他代码都会影响生产可靠性。trace 帮助你调查失败，而评估帮助你衡量某项改动是否改善了 agent 行为。
本教程带你走完一个完整的优化周期：使用 NVIDIA NeMo Compass 在记录的 trace 中识别失败，使用 NVIDIA NeMo Eval Author 创建评估，更新 agent 的指令，并在开发任务和留出任务上比较结果。请跟随 NVIDIA NemoClaw blueprint for agent optimization 一起操作。
该 blueprint 在 NVIDIA OpenShell 沙箱中使用 Hermes Agent，并配有来自一家虚构公司的记录 trace。
agent harness 是优化面
一次错误的工具调用就可能让整个任务偏离正轨。原因可能是工具描述不清、路由规则不当，或 agent harness 中缺少上下文。trace 有助于定位运行出错的位置。
我们的示例 agent 是一家虚构公司的 Hermes 企业助手，通过 Model Context Protocol（MCP）连接到公司的聊天、电子邮件、文件和工单系统。我们要求它“起草一条包含项目更新的消息”。它起草了消息，但还在未经用户确认的情况下调用了 send_message 工具。要解决这个错误，需要同时检查 harness 指令和工具执行。
前提条件
使用一台原生运行 Docker 的 Linux 机器。推荐配置为 Ubuntu 24.04，8 个 vCPU 和 32 GB 内存。你还需要：
- OpenShell 0.1.2 和 Harbor 0.22.0
- 来自 build.nvidia.com 的 NVIDIA API 密钥
- NeMo Eval Author 支持的编码 agent，例如 Codex 或 Claude Code
按照 GitHub 上完整的分步教程操作，或从 NVIDIA Brev launchable 开始。
NeMo Compass：找出先修什么
用于 agent 优化的 NemoClaw blueprint 使用三个库：NeMo Compass、NeMo Eval Author 和 NVIDIA NeMo Relay。
NeMo Compass 分析存储的 agent trace 和评估证据，以发现反复出现的问题、识别评估缺口并确定改进优先级。NeMo Compass 无需你逐一检查每次运行，而是将大量 trace 语料缩减为结构化的积压问题、支持示例以及建议改进或实验的领域。
示例中的每次 Hermes 运行都记录为每行一个 JSON trace。我们将 NeMo Compass 指向仓库中的 42 条 trace，以及 ETHOS.md——一个定义助手预期行为的简短文件。
compass --config configs/trace-analyst.yaml \
--trace.filesystem.path traces/world-v3/production/insights.jsonl
NeMo Compass 基于多种信号返回发现：
- 异常行为的迹象
- agent 如何使用工具
- 偏离 agent 预期行为的情况
NeMo Compass 还提供 trace ID，将每个信号关联到相关的 agent 运行。
这些 trace ID 支持整体发现。在这些运行中，agent 未经用户确认就发送了消息。NeMo Compass 通过将 agent 的操作与 ETHOS.md 中的规则进行比较，识别出了这个错误。
在我们的内部基准测试中，针对包含数千条 trace 的数据集运行全套 NeMo Compass 信号，识别出了编码 agent 在类似任务中遗漏的异常。
使用 NeMo Eval Author 围绕真实 agent 工作构建评估
在使用 NeMo Compass 发现问题后，创建一个能复现该问题的测试。NeMo Eval Author 提供编码 agent 技能和工作流，帮助你创建这些测试。NeMo Eval Author 支持两种 agent 评估格式：Harbor evaluations 和 NVIDIA NeMo Gym evaluations。
在你的编码 agent 中安装 NeMo Eval Author 的技能，并指示它使用这些技能。提供 NeMo Compass 的发现、原始 trace、agent 的 ETHOS.md 文件以及对 agent 仓库的访问权限作为上下文。评估应衡量与你的 agent 需求相关的 agent 行为。审查并调整生成的评估，确保它们反映这些需求。
在我们的示例中，编码 agent 创建了四个 Harbor 评估，任务类似于“起草一条回复”。NeMo Eval Author 还会创建验证器，用于判断 agent 是否满足特定标准。在此示例中，验证器检查 agent 是否在未经人工确认的情况下调用了 send_message 工具，并将该次运行标记为失败。
NeMo Eval Author 可以帮助你在生产数据出现之前创建自定义评估，使用来自 ETHOS.md 的 agent 需求以及工具定义和现有工作流等代码细节。随着真实 trace 和已知失败的出现，使用 NeMo Eval Author 扩展你的评估套件，使其持续反映你的 agent 的实际使用方式。
只改动 harness 的一个部分
在识别问题并为其编写测试后，更新 harness。在我们的示例中，我们修改了 Hermes agent 的 SOUL.md（一个类似于系统提示词的 Hermes 概念）：
Requests to write, draft, compose, prepare, or suggest a message authorize preparation only. Provide the draft for review and stop before sending it. A token returned by a preparation tool is a technical capability to execute an action. It does not establish the user's consent to that action.
harness 改动范围可以从这样简单的修复，到更复杂的中间件实现、插件扩展以及其他 agent harness 模式。向编码 agent 提供 NeMo Compass 的输出、你的 agent 的 ETHOS.md 文件以及你的 agent 实现。这些上下文为编码 agent 的提案提供依据。之前的文章介绍了使用 LangChain Deep Agents 和 Nous Research Hermes 进行 harness 优化。
衡量改动前后
更新 agent 后，我们重新运行了由 NeMo Eval Author 创建的评估任务。其中两个标记为“Held out”的任务被保留，未提供给提出 harness 改动的编码 agent。这些留出任务有助于评估这些改动能否泛化到开发任务之外。
表 1. harness 改动前后的评估结果
| 评估集 | 基线通过/运行次数 | 更新后 agent 通过/运行次数 | 工具调用，改动前/后 |
|---|---|---|---|
| 开发集，2 个任务 x 3 次运行 | 3/6 | 6/6 | 10 降至 6 |
| 留出集，2 个任务 x 3 次运行 | 4/6 | 6/6 | 28 降至 15 |
在我们的示例中，我们从一组规模较小、仅聚焦于 NeMo Compass 发现的评估任务开始。对于你的生产 agent，应构建覆盖广泛行为的评估套件。根据我们的经验，生产套件通常包含数百到数千个示例。只有当改动同时改善测试用例和留出集时才接受该改动。如果结果不确定，或者某项改动修复了一个问题却引入了回归，请对提议 agent 的新轨迹运行 NeMo Compass。编码 agent 可以利用这些新洞察来改进该改动。在迭代此过程时，确保留出用例对编码 agent 保持隐藏，以避免过拟合。
再次运行循环
在 harness 改动成功后，重复分析以识别下一个问题。我们对更新后 agent 的已评分轨迹运行了 NeMo Compass，它不再报告“未经确认即发送”的发现。它识别出另一个问题：对于某些查询，agent 找到了答案，但未能将其响应建立在检索到的证据之上。该发现是下一轮测试和修复的重点。
将优化循环应用于工程 agent
同样的轨迹到评估循环可以应用于执行更复杂技术任务的 agent。在工程工作流中，评估既需要衡量工程成果，也需要衡量 agent 工具使用的效率。
一个车门设计示例说明了 NVIDIA NeMo 工具如何支持这一过程。该示例使用来自 Dassault Systèmes 的工程虚拟伴侣 LEO 来提出设计改动，并通过仿真进行测试，目标是打造更坚固、更安全的车门。
▶ https://www.youtube.com/watch?v=IqhDPbRrsh4
视频 1. NVIDIA GTC Berlin 2026 上的超级 AI agent
NeMo Compass 分析 agent 的轨迹以识别改进领域。编码 agent 利用这些发现进行有针对性的提示词和配置改动，评估则衡量更新后 agent 在工程环境中的表现。其他场景检查这些改动是否引入回归。
在此示例中，NeMo Compass 识别出一个反复出现的问题：agent 将 QueryModel 参数放在了预期的 options 字段之外。它返回了空错误消息，导致 agent 无法恢复。该问题出现在多条轨迹中。基于这一发现，编码 agent 添加了一个验证步骤，用于捕获工具调用中位置错误的参数和名称。与基线相比，格式错误的工具调用从 142 降至零。准确率保持不变，其余场景中未观察到回归。
在初始阶段，优化循环在无人干预的情况下通宵运行。在大约 12 小时内，报告的结果显示车门设计工作流的整体评估得分相对提升了 28%，在六个测试场景中每次运行的工具调用减少了 35%，其他场景未报告回归。
该示例将 NeMo 工作流与两项 agent 性能指标联系起来：任务质量和执行效率。它遵循本教程中描述的过程——使用轨迹识别需要改动的内容，然后使用自定义评估来评估有针对性的改进，并在采纳改动前检查回归。
试用用于 agent 优化的 NemoClaw 蓝图
从用于 agent 优化的 NemoClaw 蓝图、本文中的工作场所助手示例或CAD 指南开始。
运行示例 agent 并建立基线得分。然后完成一个优化周期：使用 NeMo Compass 发现问题，使用 NeMo Eval Author 为其构建测试，并尝试对 harness 做一项改动。之后，将同样的循环指向你自己的 agent。