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

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

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

Архитектурный подход: агент как объект 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. Такой подход упрощает отладку, рефакторинг и тестирование поведения ^[3] агентов с использованием привычных инструментов контроля версий и CI/CD.

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

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

Получить грант → ^[4]

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

Разработчики утверждают, что архитектура обвязки (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 (оценка общего логического мышления ^[5]): средний показатель RHAE составил 50,2%.

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

Безопасность и ограничения решения

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

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

Заключение

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

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

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

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