NVIDIA 開源 Agent 全景圖：15 個專案怎麼選

到 2026 年 8 月，要把 NVIDIA 的 Agent 專案列成一張表，已經會碰到模型、合成資料、強化學習、Agent Harness、沙盒與分散式推論等完全不同的工程層。

把它們全叫做「Agent framework」，是理解這套生態的第一個錯誤。

NVIDIA 開源 Agent 生態是一組涵蓋模型生命週期的元件，不是一個必須整套安裝的平台。 本文盤點 15 個核心專案，逐一說明它們的架構、授權、成熟度與替代方案，最後再把它們放進同一個企業研究 Agent 案例。

NVIDIA 開源 Agent 專案有哪些？先看七層全景圖

這 15 個專案可以放進七層。箭頭代表資料或工作成果往下一階段移動；旁支則表示有些元件只在特定需求下才需要。

先用一句話定位每個名字：

這張表不是採購清單。個人開發者可能只用其中一個；訓練團隊可能集中在資料、Gym 與 RL；真正經營大規模自架模型服務的團隊，才會走到 Dynamo。

先釐清：開源、開放權重與可免費試用不是同一件事

NVIDIA 的「開放」至少包含四種不同東西：

1. 開源程式碼：多數 NeMo libraries、OpenShell、NemoClaw、TensorRT-LLM 與 Dynamo 採 Apache 2.0。
2. 開放權重：Nemotron 權重採 NVIDIA Nemotron Open Model License，不能直接當成 Apache 2.0 軟體。
3. 公開資料與 recipes：每個資料集可能採 CC-BY、ODC-BY、NVIDIA Data Agreement 或其他條款，必須逐項確認。
4. 商業封裝：NIM 提供預先封裝的推論微服務，但正式使用通常落在 NVIDIA AI Enterprise 的授權與支援範圍。

所以「GitHub 看得到」只回答了程式碼在哪裡，沒有回答模型權重能怎麼散布、資料能不能商用，也沒有回答這個專案是否適合 production。

開放程度要逐層查，成熟度要逐版本看。

模型層：Nemotron 3 是入口，不是整套 Agent

1. Nemotron 3

Nemotron 3 是面向 Agentic AI 的模型家族，包含 Nano、Super、Ultra 與 Nano Omni。Nano 處理資源受限、低延遲或本地原型；Super 面向正式的推理與工具工作；Ultra 則瞄準長時間、高難度的研究與 coding Agent。Omni 把影像、影音與音訊納入輸入。

架構：模型採 Hybrid Mamba-Transformer MoE 路線。對開發團隊而言，比模型層數更重要的是它能接 NeMo Gym 的環境、NeMo RL 的後訓練，以及 TensorRT-LLM 或其他 runtime 的部署路徑。

開放與成熟度：權重使用 Nemotron Open Model License；Nemotron asset hub 的程式碼採 Apache 2.0，資料集另有各自授權。模型與 recipes 已公開，但官方也提醒，純 open-data recipes 不會逐項重現使用額外 proprietary data 的技術報告結果。完整授權與家族差異可看前一篇 Nemotron 3 開放模型策略。

替代方案：Qwen、DeepSeek、Llama 與 Mistral 等開放權重家族。選擇標準不該只看榜單，而要看工具呼叫成功率、部署後端、context 成本與授權。

資料層：一個負責生資料，一個負責整理資料

2. NeMo Data Designer

NeMo Data Designer 用來從零或根據 seed data 產生合成資料。它不只是把 prompt 丟給模型，而是讓你定義欄位依賴、統計分布、LLM-generated columns，再用 Python、SQL、自訂 validator 或 LLM judge 檢查輸出。

架構：schema 決定資料欄位與相依順序；sampler 或 LLM 逐欄生成；validator 擋掉不合格資料；preview 先小量檢查，再擴大 production run。這種設計適合製作工具呼叫樣本、結構化輸出、角色資料與 Agent 任務。

開放與成熟度：Apache 2.0，已有持續的 0.x releases。核心流程可用，但 0.x 仍代表介面可能變動。使用 NVIDIA Build 或第三方模型端點時，還要另外遵守該服務的資料與使用條款，機密資料不該因 library 開源就直接送出去。

替代方案：Distilabel、Argilla 或自建 batch generation pipeline。Data Designer 的優勢是欄位級依賴與驗證；如果只是生成幾百筆簡單問答，普通腳本可能更省事。

3. NeMo Curator

NeMo Curator 做的是另一件事：把既有的大量文字、圖片、影音與音訊資料清乾淨。它提供分類、品質過濾、語言偵測、去重、embedding 與多模態處理流程，可從 laptop 延伸到 Ray-based 多節點工作。

架構：資料進入模組化 pipeline，依序經過下載或讀取、分類與過濾、exact 或 semantic deduplication，再輸出訓練可用的資料。它和 Data Designer 可以串接，但不能互相取代：Designer 創造缺少的樣本，Curator 移除既有資料的雜訊與重複。

開放與成熟度：Apache 2.0，已持續發行多個版本，成熟度高於剛起步的研究 repo。不過大規模 GPU 加速與多節點操作仍需要資料工程能力。

替代方案：DataTrove、Ray Data 或 Spark-based pipeline。資料量不大時，DuckDB、Polars 加上一組明確規則也可能已經足夠。

訓練與評測層：Framework、Gym、RL、Evaluator 各管一段

4. NeMo Framework

NeMo Framework 是 NVIDIA-NeMo 生態的通用訓練底座，範圍不只 LLM，也包含多模態與語音。它提供模型、distributed training、mixed precision 與 NVIDIA GPU 最佳化的整合。

架構：上層 recipe 與 model definition 接到底層 PyTorch、Megatron Core 等分散式訓練能力，再由 NeMo Run 或叢集工具管理實驗。它負責「如何把模型有效率地訓練起來」，不是 Agent 的工作流程編排器。

開放與成熟度：Apache 2.0，歷史長、功能面廣。代價是依賴與操作面也較重；如果你只微調一個小模型，完整 Framework 可能超過需求。

替代方案：Hugging Face Transformers 搭配 Accelerate、DeepSpeed，或以 Axolotl、LLaMA-Factory 處理較標準的 fine-tuning。真正需要大規模並行與 NVIDIA 最佳化時，NeMo 的價值才會變明顯。

5. NeMo Gym

NeMo Gym 是評估與改善模型、Agent 的 environment library。一個 environment 由 dataset、Agent Harness、verifier 與 per-task state 組成；它讓 coding、搜尋、工具呼叫或多輪任務可以被重複執行與打分。

架構：task 提供目標，Harness 決定模型怎麼和世界互動，state 保存每個任務的執行脈絡，verifier 判斷結果。Gym 能收集 verified rollouts，交給 NeMo RL 或其他 RL framework 使用。

開放與成熟度：Apache 2.0，但 repository 明確標示 early development，API、文件與行為仍會變動。它適合研究、建立內部 benchmark 與訓練環境；正式導入要鎖版本並保留回歸測試。完整拆解可讀 NeMo Gym 為何是 Agent 的練習場。

替代方案：Harbor、OpenEnv、Prime Intellect Verifiers，以及針對特定任務自建 harness。若評測只是把單一輸出和答案比對，一支 script 比環境框架更合理。

6. NeMo RL

NeMo RL 是多模態模型的 post-training library，支援 SFT、DPO、GRPO、reward model 等路徑，並用 Ray 管理 actor 與資源。它同時提供原生 PyTorch DTensor 路徑，以及面向大模型、多節點的 Megatron Core 路徑。

架構：policy 產生 rollout，environment 或 reward function 給分，trainer 根據演算法更新 weights；inference 與 training workers 可各自擴展。Gym 解決「題目、互動與評分」，RL 解決「如何用這些分數更新模型」。

開放與成熟度：Apache 2.0，已有多次 0.x release，功能與 recipes 積極增加。它比一次性的研究程式完整，但版本尚未進入 1.0；演算法支援、模型 support matrix 與 cluster recipe 都要按版本確認。更細的選型分析見 NeMo RL 適合誰、又不適合誰。

替代方案：TRL 適合 Hugging Face 路徑與較小規模實驗；veRL 和 OpenRLHF 也面向可擴展 RL。選擇重點是模型後端、rollout engine、叢集環境與團隊能否除錯，而不是演算法名稱最多。

7. NeMo Evaluator

NeMo Evaluator 把不同 benchmark、container 與執行資源包成可重現的評測工作。它適合需要同一套設定比較多個模型、保存結果並在叢集上重跑的團隊。

架構：launcher 或統一 CLI 選擇 evaluation harness、model endpoint、dataset 與 execution target，再把結果收回一致格式。它測的是模型或 benchmark；NeMo Gym 更著重 stateful environment 與 rollout；NeMo Agent Toolkit 則觀察整個 Agent workflow 的品質、延遲與工具呼叫。

開放與成熟度：Apache 2.0。現行版本持續發行，同時官方也預告 0.3.0 是 ground-up rewrite，表示介面仍在整併期。正式流程應鎖定 container、dataset revision 與 evaluator version。

替代方案：EleutherAI lm-evaluation-harness、HELM 或任務專用 benchmark runner。當團隊只維護少量固定測試時，自建簡單 harness 反而更透明。

Agent 與 Harness 層：不要把 Toolkit、NOOA、ACE-RTL 混在一起

8. NeMo Agent Toolkit

NeMo Agent Toolkit 是跨 framework 的 Agent 工程工具。它可以和 LangChain、CrewAI、Google ADK、Semantic Kernel 或自訂 Python Agent 並用，補上 instrumentation、tracing、profiling、offline evaluation、prompt optimization 與 workflow components。

架構：Toolkit 把 model、function、tool、agent 與 workflow 組成可設定元件，並在 LLM call、tool call 和整體 workflow 上加觀測與評估。它可以建 Agent，但更突出的角色是替既有 Agent 加上可見性和最佳化。

開放與成熟度：Apache 2.0，已進入 1.x release 線。核心 profiling、evaluation 與多框架整合可正式評估；Dynamo runtime intelligence、自動 RL 等新功能仍有 experimental 或 roadmap 標記。它過去叫 Agent Intelligence Toolkit 或 AgentIQ，現在套件應使用 nvidia-nat。

替代方案：LangSmith、Arize Phoenix、W&B Weave 與 OpenTelemetry 組合。這些不是完全相同的產品：有些強在 tracing，有些強在 dataset/eval，有些是 vendor-neutral telemetry。先確認問題是「建 Agent」還是「看懂 Agent 為何失敗」。

9. NOOA

NVIDIA-labs OO Agents，簡稱 NOOA，把 Agent 表達成 Python object：fields 是 state，methods 是 capabilities，docstrings 是 prompts，type annotations 是 contracts。方法本體留成 ... 時，可由 LLM-driven strategy 在 runtime 執行。

架構：Agent 不必另外維護一套工具 schema；模型可以在 Jupyter-style REPL 中寫 Python，透過 self 操作 live objects。這讓 tracing、testing、refactoring 與一般 Python 工程靠得更近，也讓 code execution 風險變得直接。

開放與成熟度：Apache 2.0，官方明確稱為 research software；CLI、memory 與 evaluation pipeline 也各有 beta 或研究性質。AST checks 與 module deny-list 只是 defense in depth，不是 containment boundary。系列第一篇另有完整的 NOOA Agent Harness 分析。

替代方案：LangGraph、AutoGen、PydanticAI 或 OpenHands。NOOA 的辨識度在 Python object model 與 code-as-action，不是 connectors 最多；若團隊偏 declarative graph 或 event workflow，其他框架可能更直覺。

10. ACE-RTL

ACE-RTL 是領域型 Agent，不是通用 Agent 平台。它讓 Generator 產生 RTL，Reflector 讀 simulator 或 testbench 的失敗，Coordinator 保存有用的 context，再安排下一輪修正。

架構：核心是 Generator、Reflector、Coordinator 加上確定性工具回饋。模型不能自己宣布 Verilog 正確，必須接受 simulator、testbench 或 EDA tool 的否決。這種 pattern 也能延伸到其他具有 compiler、solver 或 verifier 的工程領域。

開放與成熟度：repository 公開了 Agent skills、角色元件與 CVDP integration，程式碼採 Apache 2.0；bundled benchmark 或資料仍要看各自條款。它是 2026 年研究成果與早期工程範例，不是完整 EDA 平台，也不能把 benchmark pass rate 當成 tape-out 成功率。系列第五篇另有 Nemotron 3 Ultra 與 ACE-RTL 的完整拆解。

替代方案：OpenHands 或自訂 coding harness 接 Icarus Verilog、Verilator、Yosys，也可以把商業 EDA copilot 放進既有 sign-off 流程。差異在 verifier、IP 資安與工程責任，不只是換一個 LLM。

安全層：應用規則、作業系統隔離、參考堆疊是三件事

11. NeMo Guardrails

NeMo Guardrails 在應用程式與 LLM 之間加入 programmable rails。它可處理 input、dialog、retrieval、execution 與 output：遮蔽敏感資料、限制話題、控制對話流程、檢查工具輸入輸出，或擋下不合格回答。

架構：設定檔指定模型與 rails，Colang 或 Python actions 描述允許的對話和動作。它處理「這個 Agent 應該怎麼回、能不能呼叫這個工具」，但無法阻止已被突破的 process 讀取整個硬碟。

開放與成熟度：Apache 2.0，已累積多個版本與正式文件，成熟度高於新推出的 OpenShell。安全規則本身仍需要 threat model、測試與監控，裝了 library 不代表系統自動安全。

替代方案：Guardrails AI、Llama Guard、ShieldGemma，以及自建 policy engine。內容 classifier、structured-output validator 與 dialog policy 解的是不同問題，不能只看「guardrail」這個名字。

12. OpenShell

OpenShell 是 autonomous Agent 的 sandbox runtime。它用 declarative YAML policies 限制 filesystem、network、process 與 inference，並由 gateway 管 sandbox lifecycle、credentials 與 routing。

架構：Agent 在 sandbox 內運行，所有 outbound connection 經 policy engine；允許的流量通過，需要模型推論的請求可交給 privacy router，其他流量則拒絕並記錄。filesystem 和 process policy 在 sandbox 建立時鎖定，network 與 inference policy 可動態更新。

開放與成熟度：Apache 2.0，但 README 直接寫著「Alpha software — single-player mode」。Docker、Podman 與 MicroVM 路徑可試；Kubernetes、GPU passthrough 與多租戶企業能力仍在演進。它比 in-process deny-list 更接近真正 containment boundary，卻不能被描述成已完成的企業安全產品。

替代方案：E2B、Modal Sandbox，或 Docker 搭配 gVisor、Firecracker、自建 egress proxy 與 secrets broker。OpenShell 的差異是 agent-first policy 和 inference routing；替代方案可能在託管體驗、隔離強度或雲端整合上更成熟。

13. NemoClaw

NemoClaw 是把 OpenClaw、Hermes 或 LangChain Deep Agents Code 放進 OpenShell 的 reference stack。它增加 guided onboarding、hardened blueprint、routed inference、network policy 與 lifecycle management。

架構：Agent 是工作主體，OpenShell 是隔離與政策執行層，NemoClaw CLI 和 blueprint 負責把兩者裝好、設定好並管理生命週期。NemoClaw 不是 OpenShell 的新名字，也不是另一個 foundation model。

開放與成熟度：Apache 2.0，官方仍標示 alpha，社群支援採 best effort。它適合驗證「長時間運行 Agent 加安全預設」的模式，不適合在沒有額外 security review、版本鎖定和事故處理流程下直接接公司機密。

替代方案：原生 OpenClaw 或 Hermes 加上自建 sandbox，也可以直接把 coding Agent 放進 OpenShell、E2B 或內部容器平台。已經有成熟平台工程的企業，未必需要 NemoClaw 的整套 blueprint。

推論部署層：TensorRT-LLM 執行模型，Dynamo 管整個車隊

14. TensorRT-LLM

TensorRT-LLM 提供 Python API、C++ runtime 與 NVIDIA GPU 上的大模型推論最佳化。它關心 quantization、kernel、batching、parallelism、KV cache 與模型執行效率。

架構：model definition 或 checkpoint 經轉換與最佳化後，由 runtime 在單張或多張 GPU 上執行；scheduler、attention kernel、quantization 與 communication paths 一起影響 latency 和 throughput。它是推論 engine，不負責決定哪個 Agent 下一步要呼叫什麼工具。

開放與成熟度：repository 採 Apache 2.0 並持續發行，已是 NVIDIA 推論堆疊的主要元件。不過 TensorRT、CUDA、模型權重與 bundled dependencies 可能有各自條款；「TensorRT-LLM repo 開源」不代表整個執行環境只受一份 Apache 授權管轄。

替代方案：vLLM、SGLang、llama.cpp。前兩者也能成為 Dynamo 的 backend，所以在架構上不一定要二選一。

15. NVIDIA Dynamo

NVIDIA Dynamo 位於 inference engine 之上，處理分散式 serving。它把 prefill 與 decode 拆到合適的 workers，做 KV-aware routing、cache offload、dynamic scheduling 與跨節點資料移動。

架構：frontend 接收請求，router 根據負載與 KV overlap 選 worker，planner 安排資源，KV manager 在 GPU、host memory、local storage 與 remote storage 間管理 cache；底層 runtime 可以是 TensorRT-LLM、vLLM 或 SGLang。

Agent 工作負載特別吃這套能力。每一輪工具呼叫後，Agent 常帶著大段相同 system prompt、tool definitions 與 conversation history 回到模型。一般 round-robin routing 可能把下一輪送到沒有 cache 的 worker，重新計算整段 prefix；Dynamo 試著讓 orchestration layer 看見 session、priority 與 cache locality。

開放與成熟度：Apache 2.0。NVIDIA 在 2026 年 3 月將 Dynamo 1.0 定位為 production-grade multi-node framework，但 agent hints、snapshot 或特定 backend integration 仍可能處於 preview。成熟度應按使用的 feature 判斷，不能只看整體版本號。

替代方案：Ray Serve、KServe、自建 Kubernetes control plane，或直接使用 vLLM、SGLang 的 distributed serving。只有單機或少量 GPU 時，Dynamo 的部署複雜度可能大於收益。

NIM 為什麼不列入 15 個開源專案

NVIDIA NIM 是預先封裝、最佳化並提供標準 API 的 inference microservices。它可能包進開放權重模型和開源 runtime，但 NIM container 本身受 NVIDIA 軟體與產品條款管理；官方 FAQ 也把開發測試和需要 NVIDIA AI Enterprise license 的正式使用分開。

這不代表 NIM 不值得用。企業付費購買的是可支援的封裝、相容性、更新與服務生命週期。它只是不能被拿來證明「NVIDIA Agent stack 從頭到尾全部開源」。

開源元件可以導向商業產品，這正是 NVIDIA 策略的一部分。

用一個企業研究 Agent 串起 15 個專案

假設公司要做一個研究 Agent：它會讀內部文件、搜尋公開資料、呼叫 GitHub 與郵件工具，再輸出附來源的競品報告。真正的工程路徑可以這樣安排：

1. Curator 清理、去重並分類既有文件。
2. Data Designer 生成工具使用、拒答、引用格式與失敗案例。
3. Gym 把研究任務、工具、狀態與 verifier 做成可重跑環境。
4. NeMo RL 用 verified rollouts 調整 Nemotron 或其他支援模型。
5. NeMo Agent Toolkit 追蹤每個 LLM call、工具延遲、token 與任務結果。
6. Guardrails 檢查輸入、檢索內容、工具參數與最終回答。
7. OpenShell 隔離檔案、網路、process 和 credentials。
8. TensorRT-LLM 執行自架模型；流量跨多節點後，再讓 Dynamo 管 routing 與 cache。

這條路徑沒有強制使用 NOOA、ACE-RTL 或 NemoClaw。NOOA 是一種 Harness 選擇；ACE-RTL 是晶片領域案例；NemoClaw 是已選定相容 Agent 與 OpenShell 時的整合捷徑。NeMo Framework、Evaluator 與 NIM 也只在訓練規模、評測治理或商業支援需求出現時加入。

好的平台不是元件最多，而是能刪掉不需要的層。

NVIDIA 開源 Agent 與替代方案怎麼選

下表不是宣稱每個工具一對一等價，而是提供同一工程問題的其他入口。

NVIDIA 的強項是垂直整合：資料和訓練能接到模型，模型能接到 runtime，runtime 又對自家 GPU 最佳化。風險也在同一個地方：每多採用一層官方最佳路徑，日後替換的工程成本就可能增加。

三套實際採用路線

個人開發者：只選眼前最痛的一層

已經用 LangGraph、Claude Code 或其他 Agent 的人，不必先換 Nemotron。要知道 workflow 為何失敗，可以試 NeMo Agent Toolkit；要建立可驗證的工具任務，可以試 Gym；Agent 會執行程式和連網，則先研究 OpenShell。

本地硬體適合小模型、量化版本和開發環境，不適合被包裝成整套 NVIDIA stack 的最低門檻。像 RTX PRO 4000 Blackwell 24GB 可作為本地推論與小型實驗的工作站規格參考，但不能單卡承載 Nemotron Super、Ultra 或大型 RL pipeline。先量測模型、context 與 VRAM，再決定買卡或使用 API。

聯盟揭露：上方連結為蝦皮聯盟連結，若透過連結購買，我可能取得少量分潤，不影響你的價格與本文判斷。

Agent 訓練團隊：先把 verifier 做對

比較合理的核心是 Data Designer 或 Curator、Gym、RL，再視模型規模加入 NeMo Framework。Evaluator 用來守住跨版本 benchmark，Agent Toolkit 則觀察完整 workflow。

不要從 GRPO 名稱開始。先確認任務能重跑、環境不洩漏答案、verifier 不會被 reward hacking，失敗軌跡也真的能保存。沒有可靠環境，更多 GPU 只會更快放大錯誤。

企業部署團隊：先畫信任邊界，再談模型速度

企業可保留既有 Harness，加入 Agent Toolkit、Guardrails 與 OpenShell。這三者分別處理可觀測性、應用政策與執行隔離。模型服務只有在流量、延遲與自架需求明確後，才需要 TensorRT-LLM、Dynamo 或 NIM。

安全審查也不能因「Apache 2.0」省略。開源授權說明你能怎麼使用程式碼，不會替你完成 secrets 管理、tenant isolation、事故回應、供應鏈掃描與資料治理。

15 個專案成熟度速查

以下是截至 2026 年 8 月的實務分類，不是 NVIDIA 官方支援等級。成熟度會隨版本改變，導入前仍應回到各 repository 的 release notes、security policy 與已知限制。

常見問題

NVIDIA Agent Toolkit 和 NeMo Agent Toolkit 是同一個東西嗎？

現在談開源 Python 工具時，正式名稱是 NVIDIA NeMo Agent Toolkit。它過去叫 Agent Intelligence Toolkit 或 AgentIQ，套件也從 aiqtoolkit 遷移到 nvidia-nat；舊文章裡的名稱通常不是另一套產品。

NeMo Gym 與 NeMo RL 有什麼差別？

Gym 管任務、Agent Harness、state 與 verifier，產生可評分的互動軌跡；RL 使用 rollout 和 reward 更新模型。簡單說，Gym 是練習場與裁判，RL 是教練和訓練引擎。

OpenShell、NemoClaw 與 NeMo Guardrails 能互相取代嗎？

不能。Guardrails 控制應用層輸入、對話、檢索、工具與輸出；OpenShell 在作業系統與網路層隔離 Agent；NemoClaw 把相容 Agent、OpenShell、推論路由與安全預設組成參考堆疊。

使用 NVIDIA 這些開源專案一定需要 NVIDIA GPU 嗎？

不是每一個都需要。Data Designer、Gym、Agent Toolkit、NOOA、Guardrails 與 OpenShell 可以連外部模型或在沒有 GPU 的環境執行。大規模 NeMo 訓練、TensorRT-LLM 與 NVIDIA 最佳化部署，才高度依賴 NVIDIA GPU。

個人開發者最值得先試哪三個 NVIDIA Agent 專案？

從 Agent Toolkit、Gym 與 OpenShell 挑一個最符合當前問題的工具。要追蹤和評測 workflow 選 Toolkit，要建立有 verifier 的任務選 Gym，要隔離會寫檔、執行程式或連網的 Agent 選 OpenShell。不要一次裝全套。

結論：NVIDIA 建的不是另一個 LangChain

NVIDIA 的 Agent 版圖不是以聊天流程框架為中心，而是一路往上游碰資料、環境與 RL，往下游碰 sandbox、inference engine 與多節點 routing。Nemotron 提供模型入口；NeMo libraries 把資料、訓練與評估接起來；OpenShell 管行動邊界；TensorRT-LLM 和 Dynamo 把工作負載帶回 GPU 基礎設施。

這套垂直整合有真實價值，也帶來真實依賴。正確用法不是問「NVIDIA 全套能不能取代其他生態」，而是找出團隊現在缺的那一層，再用明確介面保留替換空間。

如果今天只能選一個專案，你最該選的通常不是功能最多的，而是能讓目前失敗變得可觀察、可驗證或可隔離的那一個。

下一步該問的是：你的 Agent 現在真正缺的是更大的模型，還是一個不會讓它自己宣布成功的系統？

資料來源

• NVIDIA-NeMo GitHub organization
• NVIDIA Nemotron developer asset hub
• NeMo Data Designer
• NeMo Curator
• NeMo Framework
• NeMo Gym
• NeMo RL
• NeMo Evaluator
• NVIDIA NeMo Agent Toolkit
• NVIDIA-labs OO Agents
• NVlabs ACE-RTL
• NeMo Guardrails
• NVIDIA OpenShell
• NVIDIA NemoClaw
• NVIDIA TensorRT-LLM
• NVIDIA Dynamo
• NVIDIA Technical Blog：OpenShell 與 NemoClaw
• NVIDIA Technical Blog：Dynamo 1.0
• NVIDIA NIM FAQ