Рекомендации по открытым AI Agent Framework 2026

Последнее обновление: 17 августа 2026 года. Данные сверены с официальными репозиториями и документацией проектов на эту дату.

23 июня 2026 года Pydantic AI объявил стабильный выпуск версии 2.0, поэтому даже известные проекты продолжают заметно менять API и архитектурные подходы. (политика версий Pydantic AI) Отсюда следует практический вывод: рекомендации по открытым AI Agent Framework 2026 нельзя строить по звёздам на GitHub или по одному удачному демо. На этой неделе выберите две-три кандидатуры, запустите одну и ту же задачу с одной моделью и в одной среде, а затем принимайте решение по восстановлению, наблюдаемости, ограничениям инструментов и сопровождению.

Эта статья предназначена для вас, если вы:

• создаёте с нуля инструментального, кодирующего или knowledge-ориентированного Agent;
• переносите прототип в постоянно работающий сервис;
• выбираете стек для команды Python, TypeScript, .NET или смешанного состава;
• хотите заранее оценить стоимость миграции, права инструментов и зависимость от конкретного поставщика.

Что считать открытым AI Agent Framework, а что лучше не смешивать

В список включены проекты, у которых одновременно выполняются четыре условия:

1. Основной код опубликован в открытом репозитории.
2. Есть понятная лицензия для использования и изменения.
3. Проект можно запустить независимо от закрытой панели управления.
4. В репозитории или официальной документации описана разработка AI Agent: инструменты, маршрутизация, состояние, рабочие процессы или взаимодействие нескольких агентов.

В итоговый список входят:

• LangGraph;
• OpenAI Agents SDK;
• Google ADK;
• Microsoft Agent Framework;
• CrewAI;
• Pydantic AI;
• Mastra;
• smolagents;
• Strands Agents;
• LlamaIndex.

Это не рейтинг от первого до десятого места. У проектов разные уровни абстракции.

Тонкий SDK подходит, когда вы хотите самостоятельно управлять циклом, состоянием и инфраструктурой. Графовый или workflow-фреймворк полезен для длинных задач, ветвлений, повторов, пауз и восстановления. Многоагентный фреймворк оправдан, когда роли действительно различаются и между ними есть формальный обмен результатами. Фреймворк для работы со знаниями нужен, если основная сложность находится в загрузке документов, поиске, индексации и проверяемом использовании данных.

Из этого следует главный вывод: простой чат-агент и автономная система обработки документов не должны оцениваться одним и тем же критерием «сколько строк кода нужно для первого запуска».

Как выглядит единый срез десяти кандидатов

В таблице ниже собраны не рекламные формулировки, а рабочие границы, которые следует проверить в POC. Лицензии и заявленные языки сверены по официальным репозиториям проектов. (репозиторий LangGraph)

У Mastra особенно важно разделять открытое ядро и код в каталогах ee/: официальный репозиторий прямо указывает на отдельную лицензию для enterprise-компонентов. (репозиторий Mastra) Это не делает проект непригодным, но меняет юридическую проверку перед коммерческим запуском.

Рекомендации по открытым AI Agent Framework 2026 по стоимости абстракций

Первый запуск часто обманчив. SDK, который позволяет за несколько минут вызвать инструмент, может оставить вам всю сложность состояния, идемпотентности и повторного запуска. Фреймворк с более строгой структурой потребует больше начальной настройки, но уменьшит количество неявных решений в команде.

Проверяйте один минимальный сценарий:

1. Agent получает запрос пользователя.
2. Вызывает функцию поиска.
3. Получает структурированный результат.
4. При ошибке инструмента делает ограниченный повтор.
5. Возвращает ответ с указанием использованных данных.

Для такого теста логика сравнения выглядит так:

• OpenAI Agents SDK, Pydantic AI, Strands Agents и smolagents обычно ближе к лёгкому SDK-подходу. Вы быстро видите цикл вызова и можете оставить управление приложению. OpenAI Agents SDK отдельно документирует инструменты-функции, handoff, guardrails, сессии и встроенную трассировку. (официальная документация OpenAI Agents SDK)
• LangGraph требует принять графовую модель. Это дополнительный концептуальный слой, но он полезен, если задача уже содержит состояния, переходы и точки остановки.
• CrewAI снижает порог для сценариев с ролями «исследователь — редактор — проверяющий», однако такая модель может оказаться лишней для одного Agent с двумя функциями.
• Mastra логично рассматривать TypeScript-команде, которой важно держать Agent рядом с существующим Node-приложением.
• LlamaIndex оправдан, когда трудность лежит не только в вызове модели, а в подготовке и извлечении данных из документов. Сам проект описывает коннекторы, индексы, retrieval и workflows как ключевые части экосистемы. (репозиторий LlamaIndex)
• Google ADK и Microsoft Agent Framework подходят командам, которым важны официальные интеграционные направления, многоагентная оркестрация и путь к развёртыванию. Google позиционирует ADK как code-first и model-agnostic toolkit. (репозиторий Google ADK)

Не приравнивайте маленький пример к низкой стоимости владения. В production вам всё равно понадобятся схема конфигурации, тестовые фикстуры, журналирование, тайм-ауты и изоляция выполнения.

LangGraph и лёгкие SDK: разные задачи, а не спор за первое место

LangGraph стоит выбирать, когда вы заранее видите:

• несколько состояний, между которыми Agent переходит по правилам;
• циклы проверки и исправления;
• паузу до подтверждения человека;
• восстановление после остановки процесса;
• необходимость показать путь выполнения в виде графа.

Если задача похожа на «получить запрос — вызвать инструмент — вернуть результат», граф может увеличить кодовую базу без заметной пользы. В этом случае смотрите на OpenAI Agents SDK, Pydantic AI, Strands Agents или smolagents. LangGraph при этом можно использовать независимо от LangChain; официальный репозиторий описывает его как framework для устойчивых Agent и указывает MIT-лицензию. (официальный репозиторий LangGraph)

Опытная граница: если вы уже добавили в обычный SDK собственный объект State, очередь событий, таблицу checkpoint и набор ручных переходов, пора проверить графовый подход. Иначе вы будете самостоятельно поддерживать часть фреймворка.

Инструменты, схемы и права: важнее количества интеграций

Функция, объявленная как tool, получает возможность воздействовать на внешнюю систему. Поэтому проверяйте не только наличие MCP или готовых коннекторов, но и четыре операции вокруг вызова:

1. Можно ли проверить аргументы до исполнения.
2. Можно ли запретить вызов без подтверждения человека.
3. Можно ли ограничить время и число повторов.
4. Можно ли записать вход, результат и ошибку без утечки секретов.

Разделите инструменты на три уровня риска:

• Низкий риск: чтение публичного API, поиск по заранее подготовленному индексу, арифметика.
• Средний риск: чтение внутренних документов, запросы к базе данных, создание черновика.
• Высокий риск: запись файлов, выполнение команд, отправка писем, изменение инфраструктуры.

Для низкого риска подойдут тонкие SDK. Для среднего уровня вам нужны структурированные аргументы, schema validation и аудит. Для высокого — отдельный sandbox, белый список команд, ограниченный пользователь и ручное подтверждение.

OpenAI Agents SDK документирует guardrails и human-in-the-loop, Strands Agents заявляет встроенную поддержку MCP, а Google ADK описывает инструменты и оркестрацию в собственном code-first подходе. Но наличие интерфейса ещё не означает, что политика безопасности настроена за вас. (репозиторий Strands Agents)

Python или TypeScript: выбирайте не язык примера, а границу системы

Для Python-команды практический короткий список обычно выглядит так:

• Pydantic AI — если ответы должны проходить строгую типовую проверку;
• LangGraph — если основная проблема находится в состоянии и переходах;
• LlamaIndex — если Agent работает с документами и поиском;
• CrewAI — если роли и задачи важнее низкоуровневого контроля;
• smolagents — если нужен небольшой экспериментальный слой;
• Google ADK, OpenAI Agents SDK или Strands Agents — если важны готовые primitives, tools и мультимодельность.

Для TypeScript-команды отдельно смотрите на Mastra и TypeScript-реализацию LangGraph. Mastra ориентирован на современный TypeScript-стек и может встраиваться в Node, React и Next.js-приложения. (документация Mastra) Strands Agents также публикует отдельный TypeScript SDK, поэтому его нельзя оценивать только по Python-примеру.

Смешанной команде Python и .NET стоит проверить Microsoft Agent Framework, но не ограничиваться заявлением о поддержке языков. В POC нужно убедиться, что одинаково реализуются отмена задачи, сериализация состояния, трассировка и обработка исключений в обоих стеках.

Многоагентная система не всегда лучше одного Agent

Много Agent оправдан, если выполняются все три условия:

• у ролей разные инструкции и критерии качества;
• результат одной роли нужен следующей;
• вы можете отдельно измерять вклад каждой роли.

Например, исследователь собирает источники, аналитик проверяет противоречия, а редактор формирует итог. Если же три Agent просто по очереди пересказывают один и тот же запрос, вы получите дополнительные задержки, стоимость вызовов и сложность отладки.

CrewAI явно строится вокруг ролевой координации, CrewAI и Flow-подходов, тогда как OpenAI Agents SDK предлагает более тонкие primitives — Agent, tools, handoffs и guardrails. Microsoft Agent Framework и Google ADK ориентированы на оркестрацию более сложных систем. (официальный репозиторий CrewAI)

Практическое правило:

• один Agent и несколько независимых инструментов — начинайте с SDK;
• последовательность с проверками и возвратами — смотрите на workflow или граф;
• разные роли с формальными артефактами — рассматривайте CrewAI или многоагентные primitives;
• документы, поиск и извлечение — добавляйте LlamaIndex или отдельный слой данных;
• не вводите многоагентность только ради презентационного эффекта.

Что проверять перед production, а не после первой ошибки

Первый шаг: зафиксируйте одинаковый сценарий

Опишите задачу в файле, который не меняется между тестами:

• входной запрос;
• набор документов;
• список доступных tools;
• ожидаемый JSON-результат;
• допустимое число обращений к модели;
• допустимые причины отказа.

Модель, параметры генерации и лимиты должны быть одинаковыми. Иначе сравнение фреймворков будет сравнением разных экспериментов.

Второй шаг: запретите скрытые права

Для каждого инструмента укажите:

• разрешённые аргументы;
• максимальное время выполнения;
• максимальный размер ответа;
• требование подтверждения;
• действие при тайм-ауте;
• место хранения журнала.

Особенно внимательно проверьте чтение файлов и выполнение команд. Agent должен работать не с правами владельца всей машины, а с отдельной рабочей областью.

Третий шаг: проведите три аварийных теста

Запустите сценарий, в котором:

1. tool возвращает ошибку;
2. модель не отвечает вовремя;
3. процесс принудительно завершается между двумя шагами.

Положительный результат — не просто сообщение об ошибке. Вы должны понять, где остановилась задача, можно ли безопасно повторить шаг и не был ли инструмент выполнен дважды.

LangGraph полезен в подобных сценариях за счёт явного состояния и checkpoint-ориентированного подхода. OpenAI Agents SDK предоставляет сессии и трассировку, но остальную политику восстановления приложение должно определить самостоятельно. Для LlamaIndex и workflow-подходов также нужно отдельно проверить сохранение событий и повторное выполнение.

Четвёртый шаг: разделите открытое ядро и внешние функции

В таблице зависимостей отметьте:

• код самого фреймворка;
• официальные расширения;
• сторонние адаптеры;
• облачную наблюдаемость;
• коммерческие функции;
• хранилище состояния;
• провайдеров моделей.

Это особенно важно для Mastra, где официальный репозиторий разделяет Apache 2.0-код и enterprise-лицензию. У Pydantic AI также есть отдельный проект Logfire и дополнительные first-party-компоненты, поэтому не смешивайте возможности основного пакета и внешнего сервиса.

Пятый шаг: проверьте миграцию

Перед фиксацией версии найдите:

• журнал выпусков;
• upgrade guide;
• предупреждения о deprecated API;
• пример обновления с предыдущей major-версии;
• правила поддержки стабильной ветки.

У Pydantic AI переход к стабильной версии 2.0 сопровождался отдельной политикой совместимости и периодом поддержки первой ветки. Это хороший пример того, почему «проект активен» и «проект безопасен для немедленной фиксации» — разные утверждения.

Шестой шаг: измерьте не только ответ, но и эксплуатацию

В чек-листе POC поставьте отметки:

• [ ] установлен фиксированный commit или версия;
• [ ] минимальная задача запускается в чистом окружении;
• [ ] tool-вызовы видны в журнале;
• [ ] аргументы проходят проверку;
• [ ] опасный tool требует подтверждения;
• [ ] тайм-аут не оставляет неконтролируемую фоновую операцию;
• [ ] повтор не дублирует запись;
• [ ] процесс можно перезапустить без потери критического состояния;
• [ ] секреты не попадают в трассировку;
• [ ] команда понимает, как заменить фреймворк или провайдера модели.

Финальная матрица выбора для короткого списка

Используйте условную рекомендацию, а не общий рейтинг:

• Быстрый одиночный прототип: OpenAI Agents SDK, Pydantic AI, Strands Agents или smolagents.
• Длинная задача с ветвлениями и восстановлением: LangGraph.
• Ролевое взаимодействие нескольких Agent: CrewAI, Microsoft Agent Framework или Google ADK.
• TypeScript-приложение: Mastra или LangGraph для TypeScript; дополнительно проверьте Strands Agents.
• Документы, поиск и knowledge Agent: LlamaIndex.
• Строгие схемы данных в Python: Pydantic AI.
• Python/.NET-команда с корпоративной интеграцией: Microsoft Agent Framework.
• MCP-центричная мультимодельная система: Strands Agents или OpenAI Agents SDK, если остальные требования закрываются.

Оставьте в финальном POC не более трёх кандидатов. Например, для документного Agent это могут быть LlamaIndex, LangGraph и Pydantic AI. Для TypeScript-продукта — Mastra, LangGraph и один тонкий SDK. Для ролевой системы — CrewAI, Google ADK и Microsoft Agent Framework.

Если вы параллельно оцениваете архитектуры AI Agent для разработки, не смешивайте выбор фреймворка с выбором модели. Сначала зафиксируйте интерфейс задачи, затем сравните модели и только после этого проверяйте инфраструктуру. Для кодирующих сценариев полезно отдельно изучить рабочие процессы AI Coding, поскольку требования к файловым правам и восстановлению там строже, чем у чат-бота.

Локальный ноутбук удобен для первого запуска, но плохо подходит для параллельного прогона нескольких кандидатов: возникают конкуренция за память, разные версии зависимостей, ручной доступ к процессам и отсутствие отдельного журнала для каждого теста. Общий сервер добавляет риск смешивания секретов, фоновых задач и рабочих каталогов. Поэтому для короткого POC разумно сначала создать изолированную среду, закрепить версии и выполнить одинаковые тесты в каждом окружении. Если локальных ресурсов недостаточно для параллельных запусков или длительных задач, можно рассмотреть облачную Mac-среду для AI-разработки и проверить выбранный Agent Framework до решения о постоянной эксплуатации.

Аренда Mac у Hashvps имеет смысл именно для временного тестового контура, изолированной демонстрации или проверки длительного запуска, когда покупать отдельное устройство ещё рано. Для постоянной тяжёлой нагрузки, физической периферии и многолетнего фиксированного проекта собственный сервер может оказаться рациональнее. Но если текущий ноутбук ограничивает параллельные POC, не даёт стабильно держать фоновые процессы и вынуждает смешивать зависимости, аренда Mac позволяет сначала проверить архитектуру на воспроизводимой среде, а уже затем принимать дорогое решение о production-инфраструктуре.