NVIDIA NOOA 解析：Agent Harness 如何改變模型成績？
NVIDIA 開源 NOOA，把 Agent 的狀態、方法、提示與型別整合進 Python class。本文解析 Agent Harness 的六項能力、官方評測結果，以及程式碼執行與安全隔離的現實限制。
目錄+
在 NVIDIA 團隊公布的測試中，同一個模型換一套 Agent Harness，成績可能差到兩位數百分點。
這不是說 Harness 能憑空把小模型變成頂級模型，而是提醒我們：模型提供推理與動作決策，真正決定它能不能完成長任務的，還包括它如何看見狀態、呼叫工具、驗證結果、保留記憶，以及判斷工作是否完成。
NVIDIA Labs 在 2026 年 7 月開源 NVIDIA-labs OO Agents（NOOA），就是把這套「模型周圍的工作環境」當成主要研究對象。
從會寫 RTL 的模型，看見 Harness 的存在
NVIDIA AI 最近展示 Nemotron 3 Ultra 處理代理式晶片設計：模型撰寫 RTL、交給 simulator 執行、讀取失敗訊息，再修改程式碼。這個循環一直重複，直到設計通過驗證。
這則貼文不是 NOOA 的產品展示，兩者不能直接畫上等號。它比較像一個容易理解的例子：只有模型並不足以完成任務，外面還需要一套系統負責執行、回傳觀察、保存進度與控制迴圈。
這套系統就是 Agent Harness。
如果把 LLM 比喻成大腦，Harness 就是它的工作桌、工具箱、筆記本、操作規則與驗收流程。桌面太亂、工具回傳格式不穩、筆記每隔一段時間就遺失，即使大腦沒有變笨，最後的工作成果仍會下降。
Agent Harness 不只是模型外面的包裝
一般聊天介面的流程很短：使用者輸入文字，模型回傳文字。
Agent 的流程則長得更像軟體執行：
模型每次採取行動後，Harness 都要決定下一輪讓它看到什麼。工具輸出要完整塞進 context，還是只給一段 preview？模型說「完成了」就停止，還是必須交出符合型別、附帶驗證證據的結果？
這些選擇會改變 token 成本、錯誤恢復能力與長任務可靠性。因此 NOOA 的核心主張不是「物件導向寫法比較漂亮」，而是：軟體介面本身就是 Agent 能力的一部分。
NOOA 如何把 Agent 變成 Python 物件？
許多 Agent 框架把 prompt、tool schema、callback、workflow graph 與 state 分散在不同檔案。NOOA 選擇把它們收回一個 Python class。以下是省略 LLM client 設定的概念範例，不是可直接執行的完整程式：
from nooa import Agent
class ResearchAgent(Agent):
"""整理研究資料，並回傳經過驗證的摘要。"""
sources: list[str]
def source_count(self) -> int:
return len(self.sources)
async def summarize(self, topic: str) -> str:
"""根據目前資料來源整理主題，缺少證據時必須指出。"""
...
這段程式裡：
ResearchAgent是 Agent 本身。sources是模型可見的物件狀態。source_count()有普通 method body，所以執行的是確定性 Python。summarize()的 method body 是...，NOOA 會在執行時啟動 LLM loop。- method name、參數和 docstring 共同描述任務。
str回傳型別是契約；結果不符合時，Harness 可以把錯誤交回模型修正。
對開發者來說，Agent 因此可以像其他程式碼一樣做 diff、code review、unit test、trace 與 refactor。對模型來說，它面對的是訓練資料中早已熟悉的 Python，而不是另一套新發明的 workflow DSL。
NOOA 集中處理的六項能力
NOOA 技術報告整理了六個 model-facing interface capabilities。它們並非每一項都由 NOOA 首創；研究團隊的主張是，NOOA 首次把六項能力放在同一個介面上。
| 能力 | NOOA 的做法 | 實際影響 |
|---|---|---|
| Typed input/output | method 參數與回傳型別成為執行契約 | 減少自由文字交接，錯誤可自動重試 |
| Pass-by-reference | 大型資料保留為 live Python object，只向模型顯示有限 preview | 不必把完整工具結果反覆塞回 context |
| Code as action | 模型在類似 Jupyter REPL 的環境撰寫 Python | 能使用迴圈、條件、library 與多步控制流 |
| Programmable loop | 開發者與模型都能用普通 Python 組合流程 | 不需另外學一套 workflow language |
| Explicit object state | 不依賴對話紀錄的顯式物件狀態放在 Agent fields | context 被整理後，關鍵狀態不一定跟著消失；跨 session 保存另由 long-term memory 負責 |
| Harness APIs | context blocks 與 event history 可被程式化查詢 | 模型能主動管理自己看到的內容與歷史 |
其中最有意思的是 pass-by-reference。假設工具回傳一個百萬列資料表，NOOA 不必把整張表序列化成文字。模型先看到資料型別、長度與頭尾樣本，再寫 Python 對真正的物件做篩選或統計。
這讓「模型能處理的資料量」不再完全等於「context window 能塞多少文字」。完整資料仍在執行環境，context 只承載模型當下需要理解的部分。
NVIDIA 公布的評測結果，應該怎麼讀？
NOOA 的數字很亮眼，但不同表格回答的是不同問題。SWE-bench Verified 測試 Agent 能否修好真實 GitHub issue；CyberGym L1 測試漏洞發現與驗證；ARC-AGI-3 則要求 Agent 在陌生格狀遊戲中靠互動找出規則。ARC 使用的 RHAE 是相對人類基準衡量動作效率的分數，而 reasoning effort 是模型在回答前投入的額外推理資源。
先把口徑分開：
| 評測 | NVIDIA 團隊公布結果 | 正確解讀 |
|---|---|---|
| Capability tests | 4,309 / 4,400 筆紀錄通過，97.9% | 10 種模型大多能使用 NOOA 介面，不是真實世界任務成功率 |
| SWE-bench Verified | GPT-5.5 在 off、high、xhigh reasoning 分別為 67.2%、78.8%、82.2% | 同一模型增加 reasoning effort，成績也明顯變動 |
| SWE-bench Verified | GPT-5.5 xhigh：NOOA 82.2%、OpenCode 1.14.33 為 78.6%、PI 0.72.1 為 78.2% | 在論文設定下，Harness 仍造成可測量差距 |
| CyberGym L1 | GPT-5.5、封鎖網路下解出 86.8% | 論文稱其為該表最高分的開源 Agent |
| ARC-AGI-3 memory ablation | GPT-5.5 使用 NOOA memory 為 50.2%，markdown notes 為 38.4% | 相同 world-model skill 下，記憶系統增加 11.8 個 RHAE 百分點 |
Capability tests 共包含 88 個測試案例、36 個家族、10 種模型，每項重跑五次。97.9% 證明的是多數現代模型能看懂 typed methods、操作 state、使用 REPL 並交回合法型別；其中較困難的 stress subset 只有 84.7%，長序列 bookkeeping 與錯誤恢復仍會拉開模型差距。
最能支持「Harness 會影響能力」的，是論文內使用同一模型與 reasoning 設定的比較。以 GPT-5.5 關閉 reasoning 的 SWE-bench Verified 為例，NOOA 是 67.2%，OpenCode 是 59.2%，PI 是 60.8%。到了 xhigh，三者差距縮小到 3.6 至 4 個百分點。這代表 Harness 在模型本身缺少規劃與驗證紀律時，可能補得更多。
論文也把 NOOA + Claude Opus 4.6 的 79.8%，與 OpenHands CodeAct 已公開的 68.4% 相比，得到 11.4 個百分點差距。這是同一底層模型的公開結果比較，但不是同一批實驗中的完全受控 A/B test，適合視為值得重現的訊號，不宜寫成已證明的普遍定律。
效率也值得注意。論文報告 NOOA + GPT-5.5 xhigh 在 SWE-bench 每題約使用 28 次模型呼叫與 110 萬 tokens；PI 約用 66 次呼叫與 220 萬 tokens，分數仍較低。研究團隊把差異歸因於 live objects、bounded previews 與 append-only context，使系統不必反覆序列化工具輸出，也能保留 prefix cache。
ARC-AGI-3 方面，GPT-5.6-sol 搭配 NOOA 得到 85.1% RHAE，ARC Prize 公布的 raw model 結果為 13.3%。論文自己也提醒兩邊預算不同，因此只能作方向性觀察，不能直接說 NOOA 讓模型能力提升六倍。
NVIDIA 真正想建立的是一整套 Agent 技術棧
NOOA 不需要限定使用 NVIDIA 模型。它透過 LiteLLM 支援託管與本地模型，官方 README 示範了 OpenAI、Anthropic、Ollama 與 vLLM。這個 model-agnostic 設計反而更能說明 NVIDIA 的企圖：讓自己掌握的不是單一模型，而是 Agent 從模型到執行環境的多個層次。
使用託管 API 不需要自行準備 GPU；若想用 Ollama 測試較小的本地量化模型，麗臺 RTX PRO 4000 Blackwell 24GB可作為工作站選項，但硬體需求仍取決於實際模型大小，並不是使用 NOOA 的必要條件。
可以把目前版圖粗略分成四層：
- 模型層：Nemotron 提供可用於推理與 Agent 任務的模型。
- Agent 開發層：NOOA 定義狀態、能力、提示、記憶與執行迴圈。
- 安全執行層：OpenShell 用作容器或作業系統層級的隔離邊界。
- 推理基礎設施層：Dynamo 處理長 context Agent workload 的 routing、KV cache 與分散式 serving。
想看安全執行層，可以延伸閱讀 NemoClaw、OpenShell 與 NVIDIA 開源 Agent 版圖；推理層則可接著看 NVIDIA Dynamo 如何處理 Agentic Inference 的 KV cache。
這套布局的商業意義很直接：當模型逐漸可以替換，競爭會往「誰能讓模型更穩定、更便宜、更安全地工作」移動。Harness、runtime、memory 與 inference infrastructure，都可能成為比 chatbot 介面更難替換的部分。
NOOA 現在最大的限制，也是它的核心優勢
NOOA 的 CodeAct 會在 Agent 自己的 process 內執行模型生成的 Python。這樣才能保留 live objects 與 pass-by-reference，不必穿過 sandbox boundary 後把資料序列化。
代價是安全風險。
官方 README 說得很清楚：AST checks 與 module deny-list 只是 defense-in-depth guardrails，不是 containment boundary。Python 的檔案存取、動態 import 與 reflection，都不是靜態檢查能完整封鎖的。
只要 Agent 能執行模型產生的程式碼，就應把整個 Agent process 放進容器、VM、權限系統或 OpenShell，而不是相信 in-process validator。
這形成一個真正的工程取捨：把程式碼搬到外部沙箱比較安全，卻會犧牲 live object reference；留在同一 process 效率較高，安全邊界就必須包在更外層。
還有兩個限制不能忽略：
- NOOA 是研究型軟體，不是已證明可直接接管 production workflow 的成熟平台。
- 論文談到用 reinforcement learning 訓練模型使用 Harness 的可能性，但那是未來研究方向，不是目前已整合的 NOOA + NeMo RL 功能。
常見問題
NOOA 是 AI 模型，還是 Agent 框架？
NOOA 不是模型，而是 model-agnostic 的 Python Agent Harness。它負責向模型呈現狀態、提供方法、執行動作、驗證回傳值，以及管理事件與記憶。
NOOA 能搭配 OpenAI、Claude 或本地模型嗎？
可以。NOOA 透過 LiteLLM 支援多種託管與本地模型，官方範例包含 OpenAI、Anthropic、Ollama 與 vLLM。實際相容性仍取決於模型是否能穩定使用程式碼與型別介面。
NOOA 適合直接部署到正式環境嗎？
不建議把預設的 in-process 程式碼執行視為安全邊界。官方將 NOOA 定位為研究型軟體，正式環境應放進容器、VM 或 OpenShell 等作業系統層級沙箱。
我的判斷
NOOA 最重要的地方不是「用 class 寫 Agent」這個語法，而是它把 Harness 從幕後工程提升成可測量、可修改的能力介面。
目前的結果還不足以證明 NOOA 會全面取代其他框架。評測由專案團隊執行，部分比較引用不同時間與設定的公開成績，production safety 也需要另一層系統補足。但它提出了一個很有說服力的方向：下一輪 Agent 競爭，不只會訓練更強的模型，也會共同設計模型工作的環境。
後續文章會繼續拆 NVIDIA 的模型與 Agent 訓練專案，包含 Nemotron、NeMo Gym、NeMo RL，以及 OpenShell 如何補上安全執行層。
你想先看 NeMo Gym 與 NeMo RL 的代理訓練流程，還是 Nemotron 模型家族？
利益揭露：本文含一條蝦皮聯盟連結，若你透過連結購買，我可能獲得分潤，不影響你的價格。
資料來源：NOOA GitHub、NVIDIA Technical Blog、NOOA Technical Report、NVIDIA OpenShell。