--- title: "调校“马具”，而非模型：一份 Nemotron 3 Ultra 实战手册" title_en: "LangChain Tunes the Harness, Not the Model — Nemotron 3 Ultra Closes In on Opus 4.8 at 1/10 the Cost" source: "langchain.com" source_url: "https://www.langchain.com/blog/tuning-the-harness-not-the-model-a-nemotron-3-ultra-playbook" published_at: "2026-07-09T00:00:00.000Z" language: "zh-CN" topics: ["claude"] tags: ["研究解读","LangChain","Nemotron","harness","Deep Agents","开源模型"] review_status: "unreviewed" --- # 调校“马具”，而非模型：一份 Nemotron 3 Ultra 实战手册 > 通过调校智能体周围的“马具”（提示词、工具描述、中间件），而非模型本身，Nemotron 3 Ultra 在 Deep Agents 评测中几乎追平了前沿模型 Opus 4.8 的成绩，但成本降低了约 10 倍。 ## 内容摘要 本文介绍了如何通过调校智能体系统的“马具”（包括系统提示词、工具描述和中间件）来提升开源模型 Nemotron 3 Ultra 的性能，而不改动模型权重。通过数据驱动的迭代循环（评估-观察-诊断-工程-重新评估），作者将 Nemotron 3 Ultra 在 Deep Agents 评测套件上的最佳成绩从 0.80 提升至 0.86，几乎追平 Opus 4.8 的 0.87，而每次运行成本仅为后者 ## 为什么值得关注 对于 AI 初学者来说，这篇文章揭示了一个重要事实：智能体的性能不仅取决于模型本身，还取决于围绕模型的“马具”（即提示词、工具描述和中间件）。通过精心调校马具，可以用开源模型达到接近前沿模型的性能，同时大幅降低成本。这意味着即使没有顶级模型，也能构建高效的 AI 智能体，这对于预算有限的开发者和企业尤其有价值。 ## 核心要点 - 调校马具（提示词、工具描述、中间件）而非模型，可将 Nemotron 3 Ultra 的 Deep Agents 评测成绩从 0.80 提升至 0.86，几乎追平 Opus 4.8 的 0.87。 - 每次运行成本降低约 10 倍（4.48 美元 vs 43.48 美元），延迟基本持平。 - 调校过程遵循数据驱动的循环：评估、观察、诊断、工程、重新评估，确保改动有效且不引入退化。 - 提示词层面，简短、单一目的的指令比大范围重写更有效；中间件层面，上下文工程（在正确位置注入指导）是关键。 - 马具调校有天花板：它能修复脚手架引起的故障，但无法添加模型本身没有的能力。 ## 关键要点 - **接近前沿水平的智能体质量，成本却低得多。** 仅调校“马具”（harness），就让 Nemotron 3 Ultra 在 Deep Agents 评测套件上跑出了 0.86 的最佳成绩，几乎追平 Opus 4.8 的 0.87 最佳成绩，而每次运行的成本却低了大约 10 倍（完整套件上约 4.48 美元对比 43.48 美元），延迟也基本持平。 - **评测数据就是马具工作的训练数据。** 每一次改动都经过一个“追踪-驱动”的循环：先用低成本的方式快速筛选，只有当这个改动在多次试验中都能稳定获胜，并且没有导致其他方面退步时，它才算真正有效。 - **匹配度决定了模型有多少能力能用在任务上。** 一个匹配的马具能让模型把能力集中在工作上；一个不匹配的马具则会让模型与“脚手架”对抗，而两者之间的差距会直接体现在分数上，完全不需要改动模型权重。 - **马具调校有天花板。** 它能修复由脚手架本身引起的故障，但无法添加模型权重里没有的能力。所以，如果一个结果在所有马具改动下都毫无变化，那就说明问题出在模型的后训练阶段，而不是需要再挂一个钩子。 ## 马具是你能够控制的部分 一个智能体（agent）等于一个模型加上一个马具。模型负责思考，而马具（包括系统提示词、工具描述、中间件）是它工作的“脚手架”。我们以前也调校过围绕前沿模型的马具，但这次，我们想看看用一个开源模型能走多远。 开源模型让这件事变得有趣。它们已经足够好，可以认真用于实际的智能体工作，而且成本只有前沿 API 的零头。你能拿到模型权重，所以可以自己托管和微调模型，或者使用各种云服务商提供的接口，不用担心被锁定。但问题是，一个能力很强的模型，如果放在一个不是为它设计的马具里，表现也可能不佳，这正是我们要解决的问题。 作为 Nemotron 联盟的一员，我们认为 Nemotron 3 Ultra 是在 Deep Agents 内部进行调校的合适模型。NVIDIA 构建 Nemotron 就是为了让它能在智能体马具里工作，我们想看看能把它推到什么程度。 开箱即用的情况下，一个通用的马具并不是为特定模型调校过的。直接使用模型而不调校马具是一个合理的默认做法，但并不是你能做到的最好情况。 马具是模型周围的一切，而模型是内部的引擎。当两者匹配时，模型就能把能力用在任务上。当它们不匹配时，模型就会把能力浪费在与脚手架对抗上，比如反复询问它已经知道的细节、过早停止、或者陷入循环。 匹配度的重要性远超大多数人的预期，我们之前已经展示过这一点。在 Terminal-Bench 2.0 上，[我们让 gpt-5.2-codex 的分数从 52.8 提升到了 66.5](https://www.langchain.com/blog/improving-deep-agents-with-harness-engineering)，当时大约是从前 30 名提升到了前 5 名，而且完全没有动模型。当我们[发布针对不同模型的马具配置文件](https://www.langchain.com/blog/tuning-deep-agents-different-models)时，通过遵循提示指南，我们将 tau2-bench 的一个精选子集提升了 10 到 20 分。同样的权重，配上不同的脚手架，就会得到不同的分数。 我们使用数据驱动的方法完成了这些马具端的工作，通过挖掘追踪记录来寻找失败模式。这次的研究对象是 Nemotron 3 Ultra，一个本身就已经很出色的开源模型。这是因为 NVIDIA 专门对它进行了后训练，使其能在各种智能体马具中表现一致，而不仅仅是单轮对话，训练数据是一大套长时间运行、使用工具的复杂任务（[NVIDIA 的发布文章](https://developer.nvidia.com/blog/nvidia-nemotron-3-ultra-powers-faster-more-efficient-reasoning-for-long-running-agents/)详细介绍了这种智能体后训练及其背后的架构）。 我们保持模型不变，只改动马具：系统提示词、工具描述，以及模型和工具调用周围的中间件。生成设置保持厂商推荐的默认值，所以下面的所有改进都不是通过调整温度、top-p 或思考预算来实现的。 ## 从评测开始 为模型调校马具总是从评测开始。没有学习信号，你就是在瞎猜，而靠瞎猜调校出来的马具只会过度拟合你最后看到的那几个案例。我们把[评测视为马具工程的训练数据](https://www.langchain.com/blog/better-harness-a-recipe-for-harness-hill-climbing-with-evals)：每个案例都会提供一个信号，告诉我们智能体是否采取了正确的行动或产生了正确的结果，这个信号会指导下一步的改动。 智能体开发看起来不像普通的软件开发。对于普通软件，你通常知道输入、输出和预期的行为。但对于智能体，输入空间非常广阔，很多输出都是可以接受的，而且对提示词、工具或编排逻辑的一个小改动，可能修复一个案例，却破坏了另一个。所以，这项工作是一个迭代过程，以 LangSmith 的追踪记录作为事实来源，按照一个[循环](https://www.langchain.com/blog/the-art-of-loop-engineering)来运行： - **评估**。在多个模型上运行行为评测套件。 - **观察**。阅读每个失败运行的追踪记录，看看它在哪、以及如何失败的。 - **诊断**。将失败的轨迹聚类成行为模式。 - **工程**。对马具的某个部分进行一次有针对性的改动。 - **重新评估**。按照成本阶梯逐步推广这个改动，只有当它带来的胜利能持续下去时才保留它。 下面的图表是我们智能体开发生命周期循环的一个变体，专门针对使用基于上述循环的评测环境来调校马具进行了修改： 有两个原则保证了循环的诚实性。首先，一次看起来不错的结果说明不了什么，因为运行结果会因随机性而略有变化。考虑到这一点，一个改动只有在多次试验中都能重复成功，并且没有导致其他方面退步时，才算真正有效。其次，我们在不放弃信号的前提下，尽量降低了测试成本。我们不会在每次改动后都运行完整的评测套件，而是让候选改动先在一个小型、低成本的筛选中进行测试，只有证明了自己，才能获得更广泛、更昂贵的运行机会。 在子集上进行筛选的风险是，可能会遗漏子集未覆盖到的任务上的退步。我们通过保持筛选的代表性来防范这一点：一个改动如果能在涵盖不同行为的样本上成立，那么它在完整运行中通常也成立。通过选取有代表性的样本，我们的筛选在进入昂贵的完整测试之前，就为我们带来了真正的信心。 ## 两个层面 ### 提示词 在提示词方面，我们的第一反应是重写系统提示词。这是最容易改动的地方，所以每个人都会从这里开始，但根据我们的经验，这也是最被高估的。大范围的重写和泛泛的“做个更好的智能体”之类的指令往往没什么效果，因为一个能力强的模型真正的失败通常不是措辞问题。 真正有效的是重写的反面：简短、单一目的的代码块，专门针对你在追踪记录中观察到的某个失败行为。如果一个模型完成了任务，但从不陈述结果，你就只写这一条指令，别的什么都不加。 ``` 在工具调用成功后，最终答案必须报告具体的结果，而不仅仅是说任务完成了。需要包含回答用户请求的关键实体、操作、标识符、标题、收件人、服务、状态或数值。如果用户问了多个问题，需要根据对应的工具输出逐一回答。 ``` 然而，我们必须小心，因为这些代码块会相互作用。一个单独使用时毫无效果的指令，一旦与马具中其他地方的改动搭配起来，可能就开始发挥作用了。所以我们也测试了组合效果。 ### 中间件 当一个行为必须**每次**都发生，而不是**大多数时候**发生时，提示词就做不到了。中间件，也就是在模型及其工具调用周围运行的钩子，承担着两个不同的工作，值得分开来看。 第一个是**代码层面的强制执行**。对模型和工具调用次数设置上限，可以在循环超时之前就结束它。一次性的重试可以吸收瞬时的工具故障。这两者都不需要模型做什么；它们改变的是循环本身的行为。 第二个工作，也是为 Nemotron 做出主要贡献的工作，是**上下文工程**：在模型需要的时候，把正确的信号放在它面前。我们不是把所有规则都塞进系统提示词里，指望模型能记住，而是观察追踪记录中的轨迹，在模型出错的地方注入指导。 最清晰的例子是我们希望遵循的一条规则：当读取文件返回的内容长达一整页时，要假设还有更多内容，并继续读取。把这个规则写在 `read_file` 工具的描述里，一点用都没有。模型读了第一页，就以为拿到了整个文件，然后回答了。我们把同样的文字，一字不改，放到了工具返回的内容里，然后它就开始生效了，因为现在这条规则就出现在模型正在读取的数据旁边。同样的文字，不同的位置，截然不同的结果。在那之后，我们不再只问规则应该说什么，而是开始问它必须出现在哪里才能被模型读到。 同样的模式也体现在信号搭载在哪个消息里，而不仅仅是它是在提示词里还是在工具结果里。Nemotron 对以对话消息形式、在需要时点传递的指导响应最可靠，而不是作为系统提示词中的一条固定规则。所以，我们添加了中间件，先告诉智能体在行动前做计划，然后，一旦计划写好了，再注入第二条消息，要求它在执行前审查计划。在追踪记录中，模型会接收这些注入的消息并据此行动：先做计划，然后回头检查自己的工作。而同样的指令放在系统提示词里，往往就没什么效果。 ## 什么没起作用 我们尝试的大部分改动都没能存活下来，这一点值得大声说出来：一个只报告成功的调校循环，通常是在过度拟合。很多看似合理的改动毫无效果，有几个甚至让情况更糟，而且不止一个杠杆只有与其他改动结合时才有效，单独使用则不行。 我们坚持的原则是：保留针对**行为类别**的修复，而不是针对**基准测试**的技巧。一个好的杠杆应该像设计良好的工具一样，基于一个真实的条件（比如，任何返回一整页的文件读取）来触发，而无需知道它面前的具体测试用例是什么。我们放弃了一个改动，正是因为它依赖于某个单一评测中的特定短语：它会让分数更好看，但对我们下一个智能体毫无帮助。 ## 调校给我们带来了什么 一个单一的分数只能告诉你智能体变好了还是变差了，但不知道具体在哪里。所以，在信任任何马具改动之前，我们让 Nemotron 在 LangChain 的 Deep Agents 评测套件上运行，这个套件会根据智能体实际花费时间的工作来分别打分：处理文件、调用工具、检索信息、进行多轮对话、总结长文本。这样打分，结果就能指向特定的能力，你就能区分出是马具的问题还是模型的问题。 调校让 Nemotron 3 Ultra 从没有配置文件的基线分数（大约 0.80）提升到了典型运行时的 0.84 左右，最佳运行达到了 0.86，几乎追平了 Opus 4.8 的最佳成绩 0.87（Opus 通常跑在 0.86 左右）。从大约 0.80 的基线开始，没有任何配置文件，这本身就是一个很强的开箱即用结果，也是 NVIDIA 智能体后训练的直接回报：这个模型一上来就非常擅长使用工具和多步骤工作，这为马具提供了一个很高的起点。 **总结能力**的提升空间最大，而调校完全解决了这个问题。没有配置文件时，马具没有提供任何压缩指导，所以模型要么在开始新的庞大任务时跳过压缩，要么从总结过的对话中回答，而不是去读取已卸载的历史文件。配置文件添加了明确的压缩指导，引导模型走向正确的压缩行为。**工具使用**也显著改善。**检索**和**文件操作**开箱即用就已经很强，这再次表明模型是为真正的智能体工作而进行过后训练的，而调校仍然将它们推向了更高水平。把这些改进加起来，你就得到了一个在智能体实际依赖的任务上表现良好的模型。 **对话**是个例外，这条平坦的线本身就很有信息量。这些不是马具能修复的低级故障。它们是长周期行为，比如在长时间的多轮任务中保持后端状态，这类问题更适合通过模型后训练来解决，而不是脚手架。为了它们去调校配置文件，意味着要迎合基准测试的形状，而不是构建一个能泛化的配置文件。一个在马具能触及的所有改动下都保持稳定的结果，说明问题超出了马具的范围，它清晰地指向了后训练与马具工作相结合可以继续发力的方向。 做这一切的价值在于**成本**。在达到相同的最佳运行质量时，调校后的开源模型每次运行的成本大约是 Opus 的十分之一，完整套件上约 4.48 美元对比 43.48 美元，根据精度和提示缓存的不同，这个优势在 3 倍到 10 倍之间。中位延迟也与 Opus 持平，大约每次测试 10 秒。在智能体实际执行的工作上达到接近前沿的水平，同时每次运行的成本更低，这改变了你能负担得起构建和评估的内容。 ## 界限在哪里 马具调校有天花板，知道这个天花板在哪里，和知道取得了哪些胜利同样重要。当故障来自脚手架时，它是正确的工具：比如模型是如何被提示的，工具是如何被描述的，结果、重试和循环是如何处理的。生产环境中导致智能体不可靠的大部分原因都在这里，所以调校马具通常是让一个有能力的模型正常工作最快的方法。 它做不到的是添加模型本身没有的能力。当一个故障对你围绕模型所做的任何改动都没有反应时，这就是一个信号，表明问题存在于模型权重中，解决方案是后训练，而不是再挂一个钩子。知道你在面对哪种故障，才能告诉你应该继续调校还是开始训练。 还有第二条界限值得划出，它存在于马具工作内部。一个改动可以是**核心马具改进**，能帮助任何智能体；也可以是**配置文件配置**，编码了某个特定模型的需求。“继续读取”提示就是一个核心改进：它会在任何完整页面读取时触发，所以它应该属于所有人的马具。而将 Nemotron 的指导以带内消息而非系统提示词的形式传递，则是配置文件配置。在任何调校项目中，最有趣的问题是，一个给定的改动实际上处于哪个位置，而原则是尽可能诚实地将每个改动推向核心，因为只有这样的版本，才能在这个模型和这个任务消失后，继续带来回报。 ## 延伸阅读 - [通过马具工程改进 Deep Agents](https://www.langchain.com/blog/improving-deep-agents-with-harness-engineering) - [更好的马具：一份使用评测进行马具爬山优化的配方](https://www.langchain.com/blog/better-harness-a-recipe-for-harness-hill-climbing-with-evals) - [调校 Deep Agents 以适配不同模型](https://www.langchain.com/blog/tuning-deep-agents-different-models) ### 相关内容 ### 看看你的智能体到底在做什么 LangSmith，我们的智能体工程平台，帮助开发者调试智能体的每一个决策、评估改动，并一键部署。 --- 英文原文：[LangChain Tunes the Harness, Not the Model — Nemotron 3 Ultra Closes In on Opus 4.8 at 1/10 the Cost](https://www.langchain.com/blog/tuning-the-harness-not-the-model-a-nemotron-3-ultra-playbook)