知识卡片：用 NVIDIA NeMo 把 Agent 失败转化为测试与 Harness 修复

一句话结论

NVIDIA 提出一条“从生产轨迹到自定义评测再到 Harness 修改”的闭环优化流程：用 NeMo Compass 从已记录的 Agent 轨迹中定位并优先级排序问题，用 NeMo Eval Author 把问题固化为可复现的评测，再修改 Agent Harness（如系统提示、工具定义等），最后在开发集与留出集上对比前后结果以验证改进并检测回归。

事件概述或研究问题

• 来源：NVIDIA Technical Blog，2026 年 11 月 4 日，作者 Patrick Moorhead、Sean Lopp、Moon Chung。
• 核心问题：面向特定领域的 Agent，通用基准分数往往无法解释其失败原因。Agent 可能选错工具、走错工作流分支、遗漏相关上下文、使用不必要昂贵的模型，或完成任务但未满足领域特定要求。
• 文章主张：改进 Agent 不只是模型调优，提示、工具、路由、记忆、技能、控制流和其他代码共同决定生产可靠性；轨迹用于调查失败，评测用于衡量改动是否真正改善行为。
• 文章给出一条完整的优化周期教程，配套 NVIDIA NemoClaw Agent 优化蓝图。

方法/产品要点

• 优化对象是 Agent Harness：一次错误的工具调用就可能让整个任务失败，原因可能是不清晰的工具描述、路由规则或 Harness 中缺失的上下文。
• NeMo Compass：分析已存储的 Agent 轨迹与评测证据，发现重复出现的问题、识别评测空白并排序改进优先级；把大规模轨迹语料压缩为结构化的问题清单、支撑样例和改进建议，并把每条发现关联到具体 trace ID。其判断依据包括异常行为迹象、Agent 使用工具的方式、与预期行为的偏离。
• NeMo Eval Author：提供编码 Agent 技能与工作流，用于按领域要求创建自定义评测，支持 Harbor 评测与 NVIDIA NeMo Gym 评测两种格式；同时生成判定器（verifier）以判断 Agent 是否满足特定标准。它也可在生产数据尚不存在时，依据 ETHOS.md 中的要求和工具定义等代码细节先行创建评测。
• 示例环境：Hermes Agent 运行在 NVIDIA OpenShell 沙箱中，通过 MCP 连接虚构公司的聊天、邮件、文件和工单系统；轨迹以每行一个 JSON 的形式记录。前置条件包括原生运行 Docker 的 Linux 机器（推荐 Ubuntu 24.04、8 vCPU、32 GB 内存）、OpenShell 0.1.2 与 Harbor 0.22.0、NVIDIA API key，以及 NeMo Eval Author 支持的编码 Agent（如 Codex 或 Claude Code）。
• 闭环步骤：NeMo Compass 定位问题 → NeMo Eval Author 生成复现该问题的评测 → 修改 Harness 的一个部分 → 在开发任务与留出任务上重跑评测对比 → 若有回归或结论不明，对新轨迹再跑 NeMo Compass 迭代。

主要结果或产业意义

• 职场助手示例：Agent 被要求“起草一条项目进展消息”，它完成了草稿，但在未经用户确认的情况下调用了 send_message 工具。NeMo Compass 通过对照 ETHOS.md 中的规则识别出该错误，并给出相关 trace ID。修复方式是修改 Hermes 的 SOUL.md（类似系统提示），明确“撰写、起草、编写、准备、建议消息”仅授权准备内容，应在发送前停下；准备工具返回的 token 只是执行动作的技术能力，不构成用户同意。
• 对比结果（表 1）：
  • 开发集（2 任务 × 3 次运行）：通过数从 3/6 提升到 6/6，工具调用从 10 降到 6。
  • 留出集（2 任务 × 3 次运行）：通过数从 4/6 提升到 6/6，工具调用从 28 降到 15。
• 迭代发现新问题：在更新后的 Agent 上重跑 NeMo Compass，原先“未确认即发送”的发现不再出现，转而识别出新问题——某些查询中 Agent 找到了答案，但没有把回答建立在检索到的证据上。
• 工程 Agent 示例（Dassault Systèmes）：使用其工程虚拟助手 LEO 做车门设计，提出设计变更并通过仿真测试。NeMo Compass 发现 Agent 把 QueryModel 参数放在预期 options 字段之外、返回空错误信息导致无法恢复的重复问题；编码 Agent 据此增加校验步骤捕获错位参数与名称。结果：畸形工具调用从 142 降到 0，准确率不变，其余场景未观察到回归。首次优化循环在约 12 小时内无人干预地隔夜运行，报告显示车门设计工作流整体评测分数相对提升 28%，六个测试场景中每次运行的工具调用减少 35%，其他场景未报告回归。
• 内部基准说法：在数千条轨迹的数据集上运行 NeMo Compass 全部信号，识别出的异常多于由编码 Agent 执行同类任务时的发现（原文未给出具体量化细节）。

为什么重要

• 把“生产证据”变成“可排序的问题清单 + 可复现的评测”，使 Agent 改进从依赖直觉转向可测量、可回归检验的工程流程。
• 明确 Harness（提示、工具、路由、记忆、技能、控制流、代码）是主要优化面，而非只调模型。
• 强调留出集必须对提出改动的编码 Agent 隐藏，以避免过拟合；只有在测试用例与留出集同时改善时才接受改动。
• 同时衡量任务质量与执行效率（工具调用次数、token 消耗），并以“无回归”为接受条件。
• 与既有脉络的关系：本卡片补充了 NeMo Compass（轨迹分析、问题排序）与 NeMo Eval Author（评测生成）两个具体工具的角色，以及“轨迹→评测→Harness 修改→回归验证”的完整操作闭环；此前卡片分别覆盖了 NeMo Relay 的可观测记录、NeMo Gym 的评测优化，以及基于 NeMo RL 的自动研究工作流。本条新增的是从失败证据到测试与修复的闭环流程本身及两组量化案例。

局限与不确定性

• 文章中的示例均基于虚构公司或合作方演示，量化结果（如 28% 相对提升、35% 工具调用减少）来自特定场景，不能直接外推到其他 Agent 或领域；待核实实际生产环境中的可复现性。
• 文中提到“生产评测套件常有数百到数千条样例”，但示例只用了很小的评测集（每类 2 任务 × 3 次运行），小样本结论的统计稳健性待核实。
• 作者称 NeMo Compass 在内部基准上优于编码 Agent 的同类分析，但未公开数据集与评测细节，待核实。
• 前置条件（OpenShell/Harbor 版本、API key、编码 Agent 支持范围）可能随版本变化，具体兼容性待核实。
• 文章标注内容由 NVIDIA Nemotron 生成摘要，可能总结不完整，关键信息需回原文核实。

可用于图书/PPT/简报的角度

• “Agent 可靠性工程”闭环图：轨迹采集 → 问题挖掘与排序 → 评测固化 → Harness 单点修改 → 开发集/留出集对比 → 回归检查 → 下一轮。
• 案例对比页：职场助手“未经确认发送消息”与工程助手“工具参数错位”两类失败，展示同一闭环如何适配不同领域。
• “Harness 即优化面”示意图：提示、工具描述、路由、记忆、技能、控制流、中间件与插件各自可能成为失败根因。
• 评测设计原则页：留出集隐藏以防过拟合、同时看质量与效率、无回归才接受改动、评测集需覆盖广泛行为。
• 产业意义页：把通用基准分数与领域特定要求的差距，转化为可执行的工程 backlog。

原始材料

• 标题：Use NVIDIA NeMo to Turn Agent Failures into Tests and Harness Fixes
• 来源：NVIDIA Technical Blog
• 作者：Patrick Moorhead, Sean Lopp, Moon Chung
• 日期：Nov 04, 2026
• URL: https://developer.nvidia.com/blog/use-nvidia-nemo-to-turn-agent-failures-into-tests-and-harness-fixes
• 关键词：Agentic AI, Generative AI, NeMo, Nemotron, NemoClaw, Agent Harness, Evaluation, Traces
• 相关资源（文中提及）：NemoClaw blueprint for agent optimization、workplace assistant example（GitHub 教程）、CAD guide、NVIDIA Brev launchable