NVIDIA の新エージェントフレームワーク NOOA を DGX Spark のローカル LLM で試してみた

はじめに

こんにちは、クラスメソッド製造ビジネステクノロジー部の森茂です。

2026 年 7 月 27 日に NVIDIA が公開した「Six Agent Harness Capabilities for Higher Model Performance」という記事、気になっている方も多いのではないでしょうか。エージェントを取り巻く実行系（ハーネス）の設計を変えるだけで、同じモデルのベンチマークスコアが大きく動くという内容です。

https://developer.nvidia.com/blog/six-agent-harness-capabilities-for-higher-model-performance/

記事と同時に、NVIDIA-labs OO Agents（略称 NOOA）というフレームワークが GitHub で公開されました。アプリケーションに組み込んで使うエージェント構築 SDK で、エージェントを Python のクラスとして書き、メソッドの本体を ... にすると実行時に LLM が埋めてくれるという、かなり思い切った設計です。現在は PyPI にも v0.0.8 が公開されていて、uv add nooa の 1 行で導入できます。

https://github.com/NVIDIA-NeMo/labs-OO-Agents

ただ、論文もブログもホスト型 API のモデルで測った数字しか載っていません。DGX Spark でローカル LLM を回している身としては、「うちの手元のモデルで動くのか」が一番知りたいところです。

この記事では、NOOA がどんなフレームワークかの整理と、v0.0.8 を DGX Spark 上のローカル LLM で動かして公開されている capability test の一部を追試した結果を紹介します。ローカルでエージェントフレームワークを動かしたい人に刺さるといいなと思っています。

NOOA とは何者か

検証に入る前に、NOOA がどんな道具なのかを整理しておきます。NOOA は vLLM や Ollama のような推論サーバーではなく、その客です。Claude Code のような「起動して使う」エージェント製品でもありません。アプリケーションに import して使うエージェント構築 SDK で、層としては LangChain、LangGraph、Mastra、Pydantic AI と同じ場所に座ります。

アプリケーションとモデル API の間に座るエージェント構築 SDK 層。NOOA は LangChain / LangGraph / Mastra / Pydantic AI と同じ層に属し、下層の litellm 経由で推論サーバーに接続する。

同じ層の中での違いは、抽象の方向です。LangChain 系のフレームワークでは、ツールを 1 つ足すたびにスキーマを定義して登録し、プロンプトはテンプレートに分け、処理の流れは Chain、Graph、Node といったフレームワーク固有の部品で組み立てます。書きたいのはエージェントのロジックなのに、先にフレームワークの語彙を覚える時間のほうが長くなりがちです。NOOA が解決しようとしているのはまさにここで、フレームワークの語彙を消して素の Python に還元することに全振りしています。エージェント定義は自分のクラス、ツール登録は不要でメソッドを書くだけ、プロンプトは docstring、制御フローはただの if と for です。

この設計には近い親戚がいくつかあります。モデルにコードを書かせて、その実行でツール操作を済ませる CodeAct 路線の smolagents、型契約路線の Pydantic AI、そして関数本体を LLM に埋めさせる Marvin です。NOOA はこの 3 系統の要素を 1 つのオブジェクトモデルに束ねた、と見るのが正確だと思います。論文が「6 つの capability はどれも新発明ではないが、一枚の面に統合したのは自分たちが初めて」と自己評価しているのは、まさにこの位置取りの宣言ですね。

もう 1 つの差別化軸は、既存のソフトウェア工学の道具がそのまま効くことです。エージェントが「ただのクラス」なら、pytest で単体テストが書けて、トレースもリファクタリングも普段のワークフローに乗ります。Chain や Graph という独自構造を持ち込まないことの実利は、実はここが一番大きいのかなと個人的には思っています。

もう一つ、出自にも触れておきます。NOOA は製品というより、「ハーネスの設計次第で同じモデルの成績が大きく動く」という研究上の主張を実証するために作られたフレームワークです。何を証明しようとしているのかは、コードを見たあとで数字と一緒に整理します。

最後に、成熟度も押さえておきます。ライセンスは Apache 2.0、対応 Python は 3.12〜3.13 で、PyPI 上の開発ステータスは Alpha です。NVIDIA 自身も research preview と位置づけているので、プロダクションの部品というより、ハーネス設計の考え方ごと試せる実験場と捉えるのがいまは正確ですね。

エージェントを Python のオブジェクトとして書く

位置づけがわかったところで、コードを見てみます。NOOA の中心にあるのは「エージェントは Python のオブジェクトである」という一点です。README の冒頭に置かれているコードがそのまま設計思想になっています。

from nooa import Agent

class SupportAgent(Agent):
    """You are a support agent."""

    # State lives on the object. Fields are typed.
    order_db: OrderDB

    # Ordinary method. Just Python.
    def is_refund_eligible(self, order: Order) -> bool:
        return order.delivered and order.days_since_delivery <= 30

    # Agentic method: the runtime hands this to an LLM.
    async def triage(self, message: str, order: Order) -> Ticket:
        """Create a typed support ticket."""
        ...

クラスがエージェント、フィールドが状態、docstring がプロンプト、型アノテーションが契約です。そして本体が ... のメソッドは、実行時に LLM が埋めます。埋めるといっても一発の文章生成ではなく、モデルがコードを書いては実行し、結果を見て次の一手を決める反復、いわゆる agentic loop が回ります。本体が書いてあるメソッドは、ただの決定論的な Python として動きます。

面白いのは、ツールという概念が存在しないことです。self に生えているものはすべてモデルから見えるので、ツールを足すことはメソッドを書くこと、ツールを消すことはメソッドを消すことと同じになります。スキーマ定義もデコレータも登録処理もありません。前の章に書いた「素の Python への還元」が、そのまま実装になっている格好です。

メソッド名がプロンプトの一部になる、というのも特徴です。analyze_feedback を analyze_feedback_briefly にリネームすると出力が変わる、と examples に書かれています。この挙動は後半で実際に確かめてみました。

何を証明するために作られたのか

NOOA の面白さは、機能より動機にあります。出発点は冒頭のブログと同じ主張、つまり「モデルを替えなくても、ハーネスの設計を変えれば成績は大きく動く」というハーネス仮説です。NOOA はこの仮説を実証するために NVIDIA が用意した実験場で、リポジトリに capability test と評価ハーネスが同梱されているのもそのためです。

https://arxiv.org/abs/2607.20709

では、どんな設計ならモデルの力を引き出せるのか。技術レポートはその条件を 6 つの capability として整理しています。型付き入出力、参照渡し、コードとしての行動、Python によるループ制御、オブジェクト上の明示的な状態、そしてモデルから呼べるハーネス API の 6 つです。前の章で見た「素の Python への還元」は、この 6 つを 1 つのオブジェクトモデルでまとめて満たすための技術的アプローチ、ということになります。

なぜ素の Python だと力を引き出せるのか。論文の説明は明快で、モデルは学習で大量の Python を読んでいるから、です。オブジェクトのドキュメントを読み、型付きの引数でメソッドを呼び、戻り値を使い、状態を書き換える。この一連の動きを現行世代のモデルは追加の学習なしにこなせるので、フレームワーク固有の語彙を間に挟むこと自体がインターフェイスの摩擦になる、という理屈です。なお、14 のフレームワークとの比較表では NOOA だけが 6 項目すべてに丸が付いていますが、そこは NVIDIA 自身による評価として読む必要があります。論文自身も「コミュニティは既にいくつかの項目に収束しつつある」と認めています。

仮説の証拠として説得力があるのは ARC-AGI-3 の数字です。ARC Prize による素の GPT-5.6-sol の評価が同じ 25 ゲームで平均 13.3% なのに対し、同じモデルを NOOA のハーネスに入れると 85.1% に届いたと報告されています。論文はこれを 6.4 倍のハーネス改善と表現しています。ハーネス設計で二桁変わる、という主張の直接の根拠がここです。

そしてこの記事の出発点になったのが、技術レポートの Table 2 です。capability test のうち「実際のエージェント仕事に近い」6 つを抜き出した stress test で、モデルの規模別に集計されています。

小型モデルは 70.8% まで落ちる、という劣化曲線を NVIDIA 自身が公開しているわけです。

ここで気になるのが、この「小型」の中身です。Claude Haiku 4.5、Gemini 3.5 Flash、Nemotron 3 Nano 30B、GPT-5.4 Mini の 4 つで、いずれもホスト型 API のモデルです。Qwen 系は 1 つも入っていません。量子化による劣化も、ローカル推論サーバーの挙動も測られていません。

つまり、DGX Spark で動かす量子化モデルがこの曲線のどこに乗るのか、ハーネス仮説がローカルでも成り立つのかは書かれていない。しかも stress test のコードはリポジトリに同梱されているので、そのまま回せます。これは試してみるしかないですね。

DGX Spark で動かすまで

検証には手元の DGX Spark を使いました。GB10 で統合メモリ 121GB、aarch64 の Linux です。

ライブラリとして使うだけなら、インストールは PyPI から 1 行です。CLI やメモリなどの周辺機能はサブパッケージに分かれていて、extras でまとめて入ります。

uv add nooa                   # コアのみ
uv add "nooa[cli]"            # + nooa コマンド（トレースビューア・eval runner）
uv add "nooa[cli,memory]"     # + 長期記憶サブシステム

ただし examples と capability test は wheel に入っていないので、追試するならリポジトリを clone します。バージョンは uv-dynamic-versioning で git タグから決まるため、タグを checkout しておくと PyPI 版と同じ時点を固定できます。

git clone https://github.com/NVIDIA-NeMo/labs-OO-Agents.git nooa
cd nooa && git checkout v0.0.8
uv sync --group dev

依存は pydantic と litellm が中心の純 Python なので、aarch64 でも wheel の問題は起きませんでした。requires-python が >=3.12,<3.14 なので、uv が自動的に Python 3.13 を取ってきて仮想環境を作ります。

フレームワーク自体のテストも走らせてみました。

uv run pytest tests/ -q --ignore=tests/test_mcp

6348 passed, 5 skipped, 282 deselected, 21 warnings in 161.83s (0:02:41)

6348 件が aarch64 で通ります。DGX Spark 上で NOOA 自体が動くことは、これで確認できました。

次はローカル LLM への接続です。README には Ollama も vLLM も接続例が載っていて、get_llm_client に api_base を渡すだけで済みます。フレームワーク本体はローカル対応済みということですね。

from nooa.unifiedllm.registry import get_llm_client

llm = get_llm_client("ollama_chat/qwen3.6:35b", api_base="http://localhost:11434")
llm = get_llm_client("hosted_vllm/qwen36-35b", api_base="http://localhost:8000/v1")

ここで一つ引っかかった点があります。examples/quickstart/ のサンプルは nooa.util.quickstart というヘルパーから LLM クライアントを受け取るのですが、その中身が環境変数を見て NVIDIA か OpenAI の API キーを選ぶ分岐になっていて、ローカルの api_base を差し込む口がありません。examples をそのままローカルで動かすことはできない、という状態です。仕方がないので llm だけ差し替えるシムを書きました。

import os

from nooa.util.quickstart import *  # noqa: F401,F403
from nooa.unifiedllm.registry import get_llm_client

MODEL = os.environ.get("NOOA_LOCAL_MODEL", "ollama_chat/qwen3.6:35b")
API_BASE = os.environ.get("OLLAMA_API_BASE", "http://localhost:11434")

llm = get_llm_client(MODEL, api_base=API_BASE)

import * で全部引き継いでから llm を再代入するだけです。examples 側の from nooa.util.quickstart import * をこのモジュールに向け替えれば、そのまま動きます。

なお、この不便は upstream でも解消済みです。main では環境変数 NEMO_OO_MODEL と NEMO_OO_API_BASE を設定するだけで examples がローカルのサーバーへ向くようになっていて、次のリリースからはシム自体が不要になるはずです。v0.0.8 の PyPI 版で追試する場合の暫定処置と捉えてください。

なお、より行儀のよい方法として、レジストリに YAML でエイリアスを登録する経路も用意されています。.nooa/llm_config.yaml に置くか NEMO_OO_LLM_CONFIG で指しておくと、モデル名だけで呼べるようになります。

models:
  qwen3.6-35b-local:
    model_name: ollama_chat/qwen3.6:35b
    api_base: http://localhost:11434
    context_window: 262144
    drop_params: true

quickstart の 10 本は 35B でも全部動いた

まずは examples/quickstart/ の 10 本を、Ollama 上の qwen3.6:35b で順に流してみました。1 本あたりの時間予算は 600 秒に設定しています。

10 本すべて動きました。ただし表の注記のとおり、agentic なループが長い 3 本（04・09・10）は 600 秒の予算に収まらず、上限を 1800 秒に伸ばした再実行で完走しています。エージェントがどれだけ長いループを選ぶかは run ごとに変わるので、ローカルの遅い推論でタイムアウトを切り詰めすぎると、動くはずのサンプルが落ちて見える点は覚えておいて損がないですね。

プロセスが正常終了したというだけでは意味がないので、答えが決まっているものを検算しています。

03_codeact_tools.py は在庫チェックのエージェントです。りんごが 50 個で 0.75 ドル、バナナが 30 個で 0.50 ドル、オレンジは在庫ゼロ。この 3 品を予算 5 ドルで注文できるかを聞きます。

Can fulfill: False
Total cost: 1.25
Unavailable items: ['orange']

0.75 + 0.50 = 1.25 で、オレンジは在庫切れなので充足不可。全項目正解です。モデルは CodeAct の中で self.get_stock() と self.get_price() を呼んで計算しています。

もっと感心したのは 05_progressive_disclosure.py のほうです。progressive disclosure は、最初からすべての情報をプロンプトへ詰め込まず、必要になった時点でモデル自身に調べさせる設計のことです。このサンプルでは 4 つの異なるクラスがそれぞれ違う評価メソッドを持っていて、システムプロンプトには型の説明がありません。モデルは doc(obj) を実行時に叩いて調べる必要があります。

  ART-001 (Artwork): $15,000.00
  STK-001 (StockHolding): $87,550.00
  JWL-001 (Jewelry): $20,000.00
  COL-001 (Collectible): $4,250.00

4 件とも正解でした。株式は 100 株 × 875.50 ドル、宝石は 2.5 カラット × 8,000 ドル、収集品は基準額 5,000 ドルに状態係数 0.85 をかけた額です。型ごとに違うアクセサを実行時に発見して呼び分けています。35B のローカルモデルでこれが動くのは、素直に面白いですね。

stress test の数字は出たが、効果の測定はまだ揺れる

サンプルが動くのは確認できたので、次は論文の Table 2 と同じテストをローカルのモデルで回します。バックエンドは vLLM 上の Qwen3.6-35B-A3B-FP8、テストごとに 5 回実行です。対象は judge が不要な 4 つに絞りました。残り 2 つは採点に LLM judge を使う設定で、その judge が NVIDIA 内部のモデルエイリアスを指しているため、外部からは解決できません。temperature は、再現性を優先した 0 とモデル既定の 2 条件です。論文側は同じ 4 テストだけを抜き出して再計算した値で、本文の 70.8% と 93.9% とはそのまま比べられない点にご注意ください。

まず、確かめられたことが 2 つあります。1 つ目は数字そのもので、集計はどちらの temperature でも論文の小型 API モデル群を上回りました。量子化したローカル 35B が、この土俵では小型ホスト型モデルより上に乗る。ハーネス仮説の土台がローカルでも崩れないことの、最初の手がかりです。

2 つ目は、エージェントの並列実行とバックエンドの相性です。50 件のバッチ分類 sentiment_batch では、モデルが 1 件ずつ分類するメソッドを書き、50 件へ asyncio.gather で一斉に発射しました。NOOA が標準で吐く OpenTelemetry のトレースで数えると LLM 呼び出しは 51 回。この fan-out を既定設定の Ollama は捌けず 600 秒でタイムアウトし、--max-num-seqs 64 で立てた vLLM は継続バッチングで吸収して 35.7〜129.0 秒で完走しました。ここは条件を変えて何度回しても機構として安定に再現します。Ollama 側は GGUF、vLLM 側は FP8 と量子化が揃っていないのでバックエンドの優劣の話ではなく、「NOOA の fan-out は、バッチサイズに見合う同時実行数を持つサーバーを前提にしている」というのが実測から言えることです。バッチ 50 件なら --max-num-seqs を 50 以上に取っておくのが確実ですね。

classify が 602.56s で Result は None。左のイベント欄に generation スパンが 51 本並んでいるのが飽和の正体。

同じ 51 本の generation スパンでも classify は 35.74s で完走し、Result に 50 件の分類結果が返っている。

一方で、それ以外の効果は、この規模の実測では確かめられませんでした。temperature は 4 テスト中 3 つで差が出ず、唯一動いた refinement も temperature 0 の 60% に対して既定が 20% と、素直な解釈を許さない向きです。そもそも temperature 0 でも結果は毎回同じにならず、refinement は同一条件の 5 回で 3 勝 2 敗でした。vLLM の continuous batching は他のリクエストとの同居状況で数値計算の順序が変わりうるため、greedy デコードでも出力が揺れます。惜しい失敗例を 1 つ挙げると、生成コードのこの 1 行が実行時エラーで run を落としました。どの run で踏むかは temperature 0 でも制御できません。

qty = await self.check_availability({alt: 110}).get(alt, 0)

メソッド名を analyze_feedback_briefly に変えると出力が短くなる件も、Ollama の並列数を上げるとエージェントが fan-out をやめて一括回答に切り替わった（速いが不正解だった）件も、同じ構図です。効いているように見える回はあるものの、5 回程度の実行で見える差は誤差帯と隣り合わせで、効果の有無を断定できる材料がありません。論文が 1 テストあたり複数 run の平均を取っているのも、この揺れが前提にあるからだと理解しました。ローカルでの NOOA は、いまのところ「動くことは確か、効かせ方の効果は未知数」と読むのが正確です。

ローカルで動かすときに詰まりやすいポイント

検証中に踏んだものをまとめておきます。同じところで止まる方の時間が少しでも減れば幸いです。

vLLM で NOOA を動かすとき、素の vllm serve に接続すると即座に弾かれます。

BadRequestError: "auto" tool choice requires --enable-auto-tool-choice
and --tool-call-parser to be set

NOOA が tool_choice="auto" を送るためで、サーバー側で tool calling を明示的に有効にします。Qwen3 系なら hermes パーサーで動きました。

--enable-auto-tool-choice \
--tool-call-parser hermes

api_base の書き方は Ollama と vLLM で違います。Ollama は http://localhost:11434 で末尾に /v1 を付けず、vLLM は http://localhost:8000/v1 と付けます。間違えると 404 page not found としか出ないので、原因にたどり着きにくいですね。

統合メモリの機体で Ollama と vLLM を同居させる場合は、起動の順番に罠があります。vLLM は起動時に空きメモリを測ってから確保するのですが、その最中に Ollama 側のモデルが keep_alive 失効でアンロードされると、空きが増えたことを「他プロセスの干渉」と判定して起動に失敗します。

AssertionError: Error in memory profiling. Initial free memory 73.16 GiB,
current free memory 77.31 GiB. This happens when other processes sharing
the same container release GPU memory while vLLM is profiling

GB10 は CPU と GPU がメモリを共有しているぶん、Ollama のロードとアンロードがそのまま vLLM の観測に映ります。vLLM を立てる前に ollama stop <model> で明示的にアンロードしておくと安定しました。並列数を変えた Ollama を 2 台目として試すときは、OLLAMA_HOST で別ポートに立てられます。

pytest まわりでは、ripgrep が入っていない環境だと shell ツール系の 150 件が「needs rg and grep on PATH」で skip されます。テスト数が妙に減っていたら rg の有無を疑ってください。また testpaths に tests/test_mcp が含まれる一方で mcp extra は dev グループに入らないため、そのまま流すなら --ignore=tests/test_mcp を付けるか uv sync --extra mcp しておきます。

トレースビューアは uv run nooa start-dev で 5001 番に立ち上がり、実行済みのトレースは nooa import-traces <dir> --batch-id <id> で後から流し込めます。実験単位でまとめて比較できるので、今回のように条件を変えて何度も回すときは重宝しました。1 点だけ、個別トレースの URL は /traces/view?session_id=<id> の形式です。また v0.0.8 のビューアはトークン未設定だと loopback 以外のアクセスを 403 で弾くため、リモートの機体で立てたビューアを手元のブラウザで見るなら SSH のポートフォワード経由が手早いです。

記事の本筋からは外れますが、長期記憶のサブシステムだけは LLM なしで試せます。examples/quickstart/12_memory.py は FakeLLMClient とオフラインの埋め込みで動くので、API キーもローカルモデルも要りません。中身は SQLite で、テーブルは memories、memory_edges、maintenance_log の 3 つだけ。内容は平文で保存されるので sqlite3 で普通に読めます。1 点補足すると、メンテナンスレポートの edges_added が 0 でも memory_edges テーブルには行が入ることがあります。記憶の投入時に張られる refines エッジは reflect 工程のカウンタに乗らない、という計上範囲の違いで、不具合ではありません。

最後に、README が自ら書いている注意も引いておきます。NOOA は LLM が生成したコードを実行するフレームワークで、AST 検査とモジュールの拒否リストは持っていますが、README はそれを「防御の一層であって封じ込めの境界ではない」と明言しています。open() で任意のファイルに触れるし、importlib でパスから直接ロードもできるので、Python の静的検査では封じ込めを保証できないという説明です。封じ込めの境界は OS レベルの隔離だと書かれていて、コンテナや VM、あるいは NVIDIA OpenShell の中で動かすことが推奨されています。

https://github.com/NVIDIA/OpenShell

upstream はいま何を積んでいるか

v0.0.8 のリリース後も main の開発は活発で、2026-08-18 時点で 60 件を超えるコミットが積み上がっています。記事の手順に影響しそうなものを挙げておきます。

一番大きいのは、途中でシムを書いて回避した examples のローカル対応が、本体側に入ったことです。加えてトレースまわりでは、ファイルベースの journal 形式が入りました。main の 06_tracing.py は journal exporter でローカルにトレースを書き出し、nooa import-traces で後からビューアに流し込む 4 ステップの手順に書き換わっています。ビューアのリモート公開も整備が進んでいて、トークンとセッション cookie による認証、共有用 URL の発行が main では動くようになっています。v0.0.8 で 403 に阻まれた部分は、次のリリースで解消されそうです。

examples には CyberGym というセキュリティ評価エージェントの実装が追加されました。8 月中旬にはポートフォリオ型のエージェントと、モデル別のコスト内訳つき評価レポートまで公開されていて、単独で遊べるボリュームがあります。機能面では、skills をエージェント単位でロード・リロードできるようにする修正、複数エージェントでセッションを共有する基盤、長期記憶の SQLite をスレッドセーフにする修正が続いています。ほかにも CHANGELOG にはセキュリティ変更として、MCP サーバー設定が環境変数の ${VAR} プレースホルダを展開しなくなった件が記録されています。リリース手順自体もスクリプト化されたので、PyPI への定期的なリリースが続く体制に見えますね。

まとめ

NOOA v0.0.8 を DGX Spark のローカル LLM で動かしてみました。確かなことから書くと、quickstart の 10 本は 35B ですべて動き、型ごとに違うアクセサを実行時に発見して呼び分けるところまで確認できました。「エージェントを素の Python に還元する」という設計は、ローカルの量子化モデルが相手でも看板どおりに機能します。judge 不要の stress test 4 本は集計 85.0% で、NVIDIA が公開している小型 API モデル群の 63.8% を上回り、大型モデル群の 91.7% には届かない位置です。fan-out とバックエンド同時実行数の相性も機構として安定に再現したので、50 件のバッチに 50 並列を投げてくるフレームワークだと知ったうえで、vLLM なら --max-num-seqs をバッチサイズ以上に取っておくのが実測では確実です。

一方で、temperature・戦略選択・メソッド名といった「効かせ方」の効果は、5 回規模の実測では符号すら安定せず、未知数のまま残りました。temperature を 0 にしても continuous batching の非決定性で結果は変わります。ハーネス仮説そのものを肯定する材料も否定する材料もまだ足りない、というのが正直なところで、エージェントの実測値は揺れる前提で読む必要がありますね。

できなかったことも書いておきます。judge が要る 2 テストは NVIDIA 内部のモデルエイリアスに依存していて回せていません。サンプル数も 1 テストあたり 5 回と少なく、論文の 10 モデル × 5 回とは母数が違います。並列数を変えるとエージェントの戦略が変わって見えた件も、原因の特定には至っていません。

次は main で整備が進んでいる journal トレースと CyberGym example、それと OpenShell のサンドボックスに入れた状態での挙動を試してみたいところです。ARC-AGI-3 のワールドモデルソルバーもリポジトリに同梱されているので、そちらも改めて触ってみたいと考えています。

参考リンク

• Six Agent Harness Capabilities for Higher Model Performance — 本記事の出発点になった NVIDIA Technical Blog の記事
• NVIDIA-labs OO Agents: Native Python Object-Oriented Agents — 設計原則と評価結果をまとめた技術レポート
• NVIDIA-NeMo/labs-OO-Agents — フレームワーク本体。capability test も同梱
• nooa - PyPI — v0.0.8。extras で nooa-cli / nooa-memory / nooa-bench を追加できる
• NVIDIA OpenShell — README が推奨しているサンドボックス実行環境
• LiteLLM Documentation — モデル指定の書式はこちらに準拠