案例研究
合作伙伴
調校框架而非模型：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智能體後訓練的直接回報：模型在工具使用和多步驟工作方面已經非常熟練，為框架提供了一個高起點。
總結能力在調校前提升空間最大，調校後完全消除短板。無配置時，框架未提供壓縮指導，因此模型在轉向新的大型任務時要麼跳過壓縮，要麼從總結的對話中回答而非讀取卸載的歷史文件。配置文件添加了明確的壓縮指導，引導模型採取正確的壓縮行為。工具使用也顯著改善。檢索和文件操作原本就很出色，這是模型經過後訓練適合實際智能體工作的另一個跡象，調校後兩者進一步提升。將這些改進加起來，就得到一個在實際智能體依賴的任務上表現出色的模型。
對話是例外，其平穩的分數本身提供了信息。這些不是框架能夠修復的低級錯誤。它們是長期行為，例如在跨多輪任務中保持後端狀態，這屬於模型後訓練而非腳手架能解決的問題。在配置文件中針對它們進行調整，意味着迎合基準測試的特定形狀，而非構建通用配置文件。一項結果在框架可觸及的所有層面都保持不變，表明問題超出了框架的能力範圍。
（正文因成本控制而截斷）