通过生产环境证据生成优先问题清单和定制评估，帮助改进提示词、工具、模型、记忆、技能和程序代码。
当你为特定领域构建智能体时，通用基准分数可能无法解释其失败原因。智能体可能选错工具、走错工作流分支、遗漏相关上下文、使用不必要的高成本模型，或在未满足特定领域要求的情况下完成任务。
改进智能体需要的不仅仅是模型调优。提示词、工具、路由、记忆、技能、控制流及其他代码都会影响生产环境的可靠性。追踪记录有助于调查故障，而评估则有助于衡量某项改动是否真正提升了智能体的行为表现。
本教程将带你完成一个完整的优化周期：使用NVIDIA NeMo Compass在记录的追踪数据中识别故障，使用NVIDIA NeMo Eval Author创建评估方案，更新智能体的指令，并在开发任务和保留任务上比较结果。请参照用于智能体优化的NVIDIA NemoClaw蓝图进行操作。
该蓝图在NVIDIA OpenShell沙箱环境中使用Hermes智能体，并采用来自一家虚构公司的记录追踪数据。
智能体程序是优化的核心对象
一次错误的工具调用就可能导致整个任务偏离轨道。原因可能是工具描述不清、路由规则有误，或智能体程序中缺少相关上下文。追踪记录有助于确定任务在哪个环节出错。
我们的示例智能体是一个为虚构公司服务的Hermes企业助手，通过模型上下文协议（MCP）连接到该公司的聊天、邮件、文件和工单系统。我们要求它"起草一条包含项目更新内容的消息"。它起草了消息，但同时在未经用户确认的情况下调用了send_message工具。要解决这个错误，需要同时检查程序指令和工具执行过程。
前提条件
需要一台原生运行Docker的Linux机器。推荐配置为Ubuntu 24.04，配备8个vCPU和32GB内存。此外还需要：
OpenShell 0.1.2和Harbor 0.22.0
来自build.nvidia.com的NVIDIA API密钥
一个NeMo Eval Author支持的编程智能体，例如Codex或Claude Code
可在GitHub上查看完整分步教程，或通过NVIDIA Brev启动项目快速上手。
NeMo Compass：找出首要修复目标
用于智能体优化的NemoClaw蓝图使用了三个工具库：NeMo Compass、NeMo Eval Author和NVIDIA NeMo Relay。
NeMo Compass分析存储的智能体追踪数据和评估证据，以发现反复出现的问题，识别评估盲区，并为改进工作排定优先级。无需逐一检查每次运行记录，NeMo Compass可以将庞大的追踪数据语料库归纳为结构化的问题清单，并附带支持性示例和改进建议方向。
示例中的每次Hermes运行都被记录为一行JSON格式的追踪数据。我们让NeMo Compass分析代码库中的42条追踪记录，以及一份名为ETHOS.md的简短文件，该文件定义了助手的预期行为规范。
compass --config configs/trace-analyst.yaml \ --trace.filesystem.path traces/world-v3/production/insights.jsonl
NeMo Compass基于多种信号返回分析结果：
异常行为的迹象
智能体使用工具的方式
与智能体预期行为的偏离程度
NeMo Compass还提供追踪ID，将每个信号与相关的智能体运行记录关联起来。
这些追踪ID为整体发现提供了支持依据。在这些运行记录中，智能体在未经用户确认的情况下发送了消息。NeMo Compass通过比对智能体的行为与ETHOS.md中的规则，识别出了这一错误。
在我们的内部基准测试中，针对包含数千条追踪记录的数据集运行完整的NeMo Compass信号分析，识别出了一个被分配相似任务的编程智能体未能发现的异常情况。
借助NeMo Eval Author围绕真实智能体工作构建评估方案
在通过NeMo Compass发现问题后，需要创建能够复现该问题的测试。NeMo Eval Author提供编程智能体技能和工作流，帮助你创建这些测试。NeMo Eval Author支持两种智能体评估格式：Harbor评估和NVIDIA NeMo Gym评估。
在你的编程智能体中安装NeMo Eval Author的技能模块，并指示其调用这些技能。将NeMo Compass的分析结果、原始追踪数据、智能体的ETHOS.md文件以及智能体代码库的访问权限作为上下文提供给它。评估方案应衡量与智能体要求相关的行为表现。审查并调整生成的评估方案，确保其准确反映这些要求。
在我们的示例中，编程智能体创建了四个Harbor评估方案，任务内容类似于"起草一份回复"。NeMo Eval Author还会创建验证器，用于判断智能体是否满足特定标准。在本例中，验证器会检查智能体是否在未经人工确认的情况下调用了send_message工具，并将该次运行标记为失败。
在生产数据产生之前，NeMo Eval Author可以帮助你基于ETHOS.md中的智能体要求以及工具定义、现有工作流等代码细节来创建定制评估方案。随着真实追踪数据和已知故障的不断积累，可以使用NeMo Eval Author扩展你的评估套件，使其持续反映智能体的实际使用情况。
只改动程序的一个部分
在识别出问题并为其编写测试后，接下来需要更新程序。在我们的示例中，我们修改了Hermes智能体的SOUL.md文件（这是Hermes中类似于系统提示词的概念）：
要求撰写、起草、编写、准备或建议某条消息的请求，仅授权进行准备工作。提供草稿供审核，并在发送之前停止操作。由准备工具返回的令牌只是执行某项操作的技术能力凭证，并不代表用户已同意执行该操作。
程序改动的范围可以从这类简单修复，到更复杂的中间件实现、插件扩展以及其他智能体程序模式。向编程智能体提供NeMo Compass的输出结果、智能体的ETHOS.md文件以及智能体的具体实现代码。这些上下文信息为编程智能体提出的方案提供了依据。此前的文章已介绍过使用LangChain Deep Agents和Nous Research Hermes进行程序优化的方法。
改动前后的效果测量
更新智能体后，我们重新运行了由NeMo Eval Author创建的评估任务。其中两项任务被标记为"保留任务"，在提出程序改动方案的过程中对编程智能体保密。这些保留任务有助于评估改动效果是否能够泛化到开发任务之外的场景。
在我们的示例中，我们从一小批评估任务入手，这些任务都紧扣NeMo Compass的发现结果。对于你的生产环境智能体而言，应构建一个覆盖广泛行为表现的评估套件。根据我们的经验，生产环境评估套件通常包含数百到数千个样例。只有当改动同时提升了测试用例和保留用例的表现时，才应予以采纳。如果结果不明确，或某项改动解决了一个问题却引入了新的退化问题，可以针对改进后智能体产生的新追踪数据再次运行NeMo Compass。编程智能体可以利用这些新的分析结果来完善改动方案。在迭代这一流程的过程中，务必确保保留用例始终对编程智能体保密，以避免过拟合问题。
再次运行优化循环
成功完成一次程序改动后，重复上述分析流程以识别下一个问题。我们针对更新后智能体的已评分追踪数据再次运行了NeMo Compass，它不再报告"未经确认发送消息"这一问题。但它识别出了另一个问题：对于某些查询，智能体虽然找到了答案，但未能将回复内容与检索到的证据相互印证。这一发现将成为下一轮测试和修复工作的重点。
将优化循环应用于工程类智能体
这种从追踪数据到评估方案的循环流程同样适用于执行更复杂技术任务的智能体。在工程工作流中，评估方案不仅需要衡量工程成果，还需要衡量智能体使用工具的效率。
一个车门设计的示例说明了NVIDIA NeMo工具如何支持这一流程。该示例使用了达索系统公司（Dassault Systèmes）的工程虚拟伙伴LEO，用于提出设计改动方案并通过仿真进行测试，目标是打造一款更坚固、更安全的车门。
NeMo Compass分析智能体的追踪数据以识别待改进领域。编程智能体根据分析结果进行有针对性的提示词和配置改动，评估方案则衡量更新后智能体在工程环境中的表现。此外还设置了附加场景，用于检查这些改动是否会引入退化问题。
在这个示例中，NeMo Compass识别出一个反复出现的问题：智能体将QueryModel的参数放置在预期的options字段之外。系统因此返回空错误信息，导致智能体无法进行自我纠正。该问题在多条追踪记录中均有出现。基于这一发现，编程智能体增加了一个校验步骤，用于捕获工具调用中位置或命名错误的参数。与基准水平相比，格式错误的工具调用次数从142次降至零次。准确率保持不变，其余场景中也未观察到退化问题。
在首轮优化过程中，该优化循环实现了无需人工干预的整夜自主运行。大约12个小时后，所报告的结果显示：车门设计工作流的整体评估得分实现了28%的相对提升，在六个测试场景中，每次运行的工具调用次数减少了35%，且其他场景均未报告出现退化问题。
该示例将NeMo工作流与智能体性能的两项衡量指标——任务质量和执行效率——联系了起来。它遵循了本教程所介绍的流程：先利用追踪数据确定需要改动的内容，再通过定制评估方案评估目标改进效果，并在采纳改动之前检查是否存在退化问题。
尝试用于智能体优化的NemoClaw蓝图
从用于智能体优化的NemoClaw蓝图、本文中的职场助手示例，或CAD指南入手。
运行示例智能体并建立基准得分。然后完成一个完整的优化周期：借助NeMo Compass发现问题，使用NeMo Eval Author为其构建测试方案，并尝试对程序进行一次改动。完成后，将同样的循环流程应用到你自己的智能体上。
