案例研究
合作伙伴
调校框架而非模型：Nemotron 3 Ultra实践指南
2026年7月8日
返回博客
创建智能体
关键要点
- 以极低成本实现接近前沿的智能体质量。仅通过调校框架，Nemotron 3 Ultra在Deep Agents套件上的最佳运行得分达到0.86，几乎与Opus 4.8的最佳0.87分持平，而每次运行成本约为后者的十分之一（完整套件约4.48美元对43.48美元），延迟基本持平。
- 评估是框架工作的训练数据。每次更改都通过追踪驱动循环，先进行低成本筛选，只有当结果在多次试验中重复出现且未导致其他指标退化时，才被保留。
- 匹配度决定了模型能发挥多少能力。匹配的框架让模型将能力集中于任务本身；不匹配的框架则使其花费精力应对脚手架，两者之间的差异会在分数上体现出来，而无需触及模型权重。
- 框架调优存在上限。它能修复由脚手架引发的失败，但无法增加权重中不存在的知识。因此，如果某项结果在所有框架更改后仍保持不变，则表明需要后训练而非继续调整框架。
智能体由模型和框架组成。模型负责思考，而框架（包括系统提示、工具描述、中间件）是模型工作的脚手架。我们之前已经调校过前沿模型的框架，但这次我们想探索开源模型能达到何种程度。
开源模型的价值在于：它们已经足够优秀，可用于实际的智能体工作，且成本仅为前沿API的一小部分。你可以获得权重，自行托管和微调模型，或使用多家云服务商的端点而无需绑定。但问题在于，一个能力强大的模型若置于不匹配的框架中，仍可能表现不佳——这正是我们要解决的问题。
作为Nemotron Coalition成员，我们认为Nemotron 3 Ultra是在Deep Agents中调校的正确选择。NVIDIA构建Nemotron的目的就是让其适配智能体框架，我们想看看它能走多远。
框架是可以控制的部分
开箱即用的通用框架并未针对特定模型进行调校。使用未调校的框架是合理的默认选择，但并非最佳选择。
框架是模型周围的全部环境，模型则是其中的引擎。当两者匹配时，模型的能力能完全用于任务；不匹配时，模型会花费能力应对脚手架，例如重复请求已有信息、提前停止或陷入循环。
匹配度的重要性超出大多数人预期，我们之前已经证明过。在Terminal-Bench 2.0上，我们仅通过调整框架，将gpt-5.2-codex的得分从52.8提升至66.5，大约从排名30提升至前5。当我们发布针对不同模型的框架配置文件时，通过遵循提示指南，我们将tau2-bench的一个精选子集提升了10到20分。相同的权重，不同的脚手架，得分截然不同。
我们采用数据驱动的方法进行框架端工作，挖掘追踪记录中的失败模式。本案例研究聚焦于Nemotron 3 Ultra，这是一个开源模型，它本身就表现出色——因为NVIDIA专门对其进行了后训练，使其在多种智能体框架中表现一致，而不仅仅是单轮对话，这得益于其在大规模长时间、工具使用任务上的训练（NVIDIA的发布文章涵盖了智能体后训练及其背后的架构）。
我们保持模型固定，仅更改框架：系统提示、工具描述以及模型和工具调用之间的中间件。生成设置保持供应商推荐默认值，因此以下所有改进均不涉及温度、top-p或思考预算的改变。
从评估开始
调校框架始终始于评估。没有学习信号，你只能猜测；而基于猜测调校的框架会过度拟合你最后看到的内容。我们将评估视为框架工程的训练数据：每个案例都提供关于智能体是否采取正确行动或产生正确结果的信号，该信号指导下一步更改。
智能体开发与常规软件不同。常规软件通常知道输入、输出和预期行为，而智能体的输入空间广阔，许多输出是可接受的，提示、工具或编排的微小更改可能修复一个案例却破坏另一个。因此，工作是迭代的，以LangSmith追踪记录为真相源，循环进行：
- 评估：在行为套件上运行模型。
- 观察：读取每个失败运行的追踪记录，了解失败位置和方式。
- 诊断：将失败轨迹聚类为行为模式。
- 工程：对框架的某一部分进行针对性更改。
- 重新评估：将更改在成本阶梯上逐步推广，仅当改进稳定时保留。
下图是我们智能体开发生命周期循环的一个变体，专门针对使用评估环境进行框架调校进行了修改：
两项原则确保循环诚实。第一，单次良好运行不足为凭，因为运行会因随机性略有变化。因此，更改只有在其效果在多次试验中重复且未导致其他指标退化时才能保留。第二，我们在不损失信号的前提下控制测试成本。不是每次更改都运行完整套件，而是先在一个小型、低成本的筛选集上测试候选更改，只有通过后才进行更广泛、更昂贵的运行。
在子集上筛选的风险是遗漏某些任务上的退化。我们通过确保筛选集具有代表性来防范这一点：一个在涵盖不同行为的样本上表现稳定的更改，通常在完整运行中也成立。通过选取代表性样本，我们的筛选在昂贵的全面测试前提供了真实信心。
两个层级
提示
在提示方面，我们的第一直觉是重写系统提示。这是最容易更改的部分，因此也是每个人的起点。但根据我们的经验，它最被高估。大范围重写和泛泛的“成为更好的智能体”指令往往效果平平，因为能力强大的模型的实际失败通常不是措辞问题。
真正有效的是与重写相反的做法：简短、单一目的的代码块，针对你在追踪记录中看到的具体失败行为。例如，如果模型完成任务但从不报告结果，你只需写一条指令：“工具调用成功后，最终答案必须报告具体结果，而不仅仅是任务已完成。包括回答用户请求的关键实体、动作、标识符、标题、接收者、服务、状态或值。如果用户问了多个问题，请分别根据对应的工具输出回答每个问题。”
不过要小心，这些代码块会相互影响。一条单独无效的指令，可能在与框架其他更改搭配后开始发挥作用，因此我们也要测试组合。
中间件
当行为必须“每次”而非“大多数时候”发生时，提示无法达到目的。中间件——在模型和工具调用周围运行的钩子——承担两个不同的工作，值得区分。
第一个是代码层面的强制执行。例如，限制模型和工具调用次数，在循环超时前终止运行；一次性重试吸收瞬态工具故障。这些都不需要模型参与，而是改变循环的行为。
第二个工作，也是Nemotron案例中发挥主要作用的，是上下文工程：在相关时刻将正确的信号放在模型面前。我们不是将所有规则都塞进系统提示并希望模型记住，而是观察追踪记录中的轨迹，在模型出错的位置注入指导。
最明显的例子是一个我们想实现的规则：当文件读取返回一整页时，假定还有更多内容并继续读取。将它写入read_file工具的描述中，它毫无效果。模型读取第一页后假设已获取整个文件，然后回答。我们将相同的文字（未做任何修改）移到工具返回的内容中，它开始生效，因为现在它直接出现在模型正在读取的数据旁边。相同的文字，不同的位置，截然相反的结果。此后，我们不再只问规则应该说什么，而是开始问它应该出现在哪里才能被读取。
同样的模式也体现在信号出现在哪条消息中，而不仅仅是它位于提示还是工具结果。Nemotron对在需要时刻作为对话消息传递的指导响应最可靠，而不是系统提示中的固定规则。因此，我们添加了中间件，先告诉智能体在执行前进行规划，然后在规划写出后注入第二条消息，要求它在执行前审查规划。在追踪记录中，模型接收了这些注入的消息并执行了操作——先规划，然后回去检查自己的工作——而同样的指令放在系统提示中则容易被忽视。
哪些没有效果
我们尝试的大部分更改都没有存活下来，这一点值得明说：一个只报告成功的调优循环通常是在过度拟合。许多看似合理的更改毫无效果，少数甚至使情况恶化，而且不止一个杠杆只有在与其他更改结合时才有效，单独使用则不行。
我们坚持的原则是：保留针对具体行为类别的修复，而非针对基准测试的技巧。一个好的杠杆能在真实条件下触发（例如，任何返回整页的文件读取），就像精心设计的工具一样，无需了解面前的具体测试。我们剔除了一项对单个评估中的某个短语有依赖的更改，因为它会虚增分数，但对下一个智能体毫无教益。
调校带来的成果
单一分数只能告诉你智能体变好或变坏，但无法指出具体方面。因此，在信任任何框架更改前，我们在LangChain的Deep Agents套件上运行Nemotron，该套件分别对智能体在各项任务上的表现进行评分：文件操作、工具调用、信息检索、多轮对话、长上下文总结。按这种方式评分，结果指向特定能力，这有助于区分框架问题与模型问题。
调校将Nemotron 3 Ultra从无配置基线的约0.80分提升至典型运行下的约0.84分，最佳运行达到0.86分，几乎与Opus 4.8的最佳0.87分持平（Opus典型运行约0.86分）。从约0.80分的无配置起点开始，这本身就是一个强劲的开箱即用结果，是NVIDIA智能体后训练的直接回报：模型在工具使用和多步骤工作方面已经非常熟练，为框架提供了一个高起点。
总结能力在调校前提升空间最大，调校后完全消除短板。无配置时，框架未提供压缩指导，因此模型在转向新的大型任务时要么跳过压缩，要么从总结的对话中回答而非读取卸载的历史文件。配置文件添加了明确的压缩指导，引导模型采取正确的压缩行为。工具使用也显著改善。检索和文件操作原本就很出色，这是模型经过后训练适合实际智能体工作的另一个迹象，调校后两者进一步提升。将这些改进加起来，就得到一个在实际智能体依赖的任务上表现出色的模型。
对话是例外，其平稳的分数本身提供了信息。这些不是框架能够修复的低级错误。它们是长期行为，例如在跨多轮任务中保持后端状态，这属于模型后训练而非脚手架能解决的问题。在配置文件中针对它们进行调整，意味着迎合基准测试的特定形状，而非构建通用配置文件。一项结果在框架可触及的所有层面都保持不变，表明问题超出了框架的能力范围。
（正文因成本控制而截断）