NOOA от NVIDIA: публичный Python-фреймворк для разработки ИИ-агентов

Компания NVIDIA выпустила публичный фреймворк NOOA (Object-Oriented Agents), который призван решить проблему фрагментации в разработке ИИ-агентов. Система объединяет разрозненные элементы инфраструктуры — шаблоны промптов, схемы инструментов, функции обратного вызова (callbacks) и графы рабочих процессов — в единый класс Python. 

Проект передан в консорциум Open Secure AI Alliance для совместного развития открытых стандартов безопасности в сфере искусственного интеллекта.

Архитектурный подход: агент как объект Python

В основе концепции NOOA лежит представление ИИ-агента как стандартного объекта Python, где компоненты транслируются напрямую в элементы объектно-ориентированного программирования:

• методы определяют возможности и доступные действия агента,

• поля класса хранят его текущее состояние,

• строки документации (docstrings) выполняют роль промптов,

• аннотации типов выступают в качестве строгих контрактов для ввода и вывода данных.

from nooa import Agent # Агент представляет собой объект Python.
class SupportAgent(Agent): """You are a support agent.""" # Состояние хранится прямо в объекте. Поля типизированы. order_db: OrderDB # Обычный способ — типовой детерминированный код на Python. def is_refund_eligible(self, order: Order) -> bool: return order.delivered and order.days_since_delivery <= 30 # Агентный способ: среда выполнения передает задачу на выполнение LLM. async def triage(self, message: str, order: Order) -> Ticket: """Create a typed support ticket.""" ...

Ключевой особенностью синтаксиса является разделение логики на вероятностную и детерминированную непосредственно на уровне исходного кода. Метод, тело которого состоит только из многоточия (...), при вызове передается на выполнение языковой модели. Среда выполнения направляет аргументы и контекст вызова в LLM-цикл, который решает задачу и возвращает результат в заданном формате.

Метод с обычным телом выполняется как типовой детерминированный код на Python. Такой решение упрощает отладку, рефакторинг и тестирование поведения агентов с использованием привычных инструментов контроля версий и CI/CD.

Развиваете AI‑проект?

Заполните форму и получите до 2 000 000 ₽ на инфраструктуру

Получить грант →

Результаты тестирования на бенчмарках

Авторы утверждают, что архитектура обвязки (harness) существенно влияет на эффективность работы модели. NVIDIA опубликовала результаты тестирования NOOA на нескольких ключевых бенчмарках:

• SWE-bench Verified: в связке с GPT-5.5 фреймворк достиг точности 82,2%, совершив в среднем 28 вызовов LLM и затратив около 1,1 млн токенов на задачу. Для сравнения, решение PI продемонстрировало точность 78,2%, но при этом потребовало больше ресурсов — 2,2 млн токенов. Каркас OpenCode представил близкое к NOOA число запросов и точность 78,6 процентов, тем не менее расход токенов также оказался выше — 1,3 млн на задачу. Таким образом, NOOA демонстрирует потенциал задать новую планку соотношения стоимости и качества.

• CyberGym L1 (проверка на повторное обнаружение уязвимостей): успешное решение 86,8% задач при работе с GPT-5.5.

• ARC-AGI-3 (оценка общего логического мышления): средний показатель RHAE составил 50,2%.

• Каркас также прошел валидацию на бенчмарке Terminal-Bench 2.0.

Защита и ограничения решения

Поскольку модель в рамках NOOA действует через генерацию и непосредственное исполнение кода в интерактивной среде (code as action), запуск агентов требует жесткой изоляции. 

NVIDIA настоятельно рекомендует развертывать агентов внутри защищенной среды выполнения NVIDIA OpenShell или в изолированных контейнерах и виртуальных машинах, поскольку внутренние статические валидаторы кода (AST-проверки и черные списки модулей) служат лишь базовой защитой от ошибок, но не предотвращают намеренный обход ограничений.

Заключение

Несмотря на преимущество консолидации логики по сравнению с разрозненными графами в LangGraph или AutoGen, эксперты указывают на некоторое количество технологических компромиссов:

1. Сложность аудита кода: методы с ... сложно подвергнуть классическому статическому аудиту безопасности (например, через git diff перед слиянием веток), так как их фактическое исполнение генерируется в процессе и зависит от вероятностного поведения модели в среде выполнения. 

2. Риски инъекций: концепция централизованного описания логики увеличивает потенциальный масштаб ущерба ("blast radius") при успешной атаке типа prompt injection, так как злоумышленник может получить более широкий доступ к состоянию и возможностям системы.

3. Ограниченность бенчмарков: высокие показатели на SWE-bench или ARC-AGI-3 могут не переноситься напрямую на реальные регулируемые системы. В отличие от тестовых сред с готовыми автоматическими проверками, в реальном продакшене зачастую невозможно мгновенно определить корректность принятого агентом решения.