Эволюция инструментов разработки: почему фреймворки для AI-агентов выжили и изменились

Суть

С каждым улучшением больших языковых моделей (LLM) в сообществе разработчиков возникает один и тот же вопрос: «Нужен ли нам всё ещё специальный фреймворк для агентов, или модель справится сама?».

Команда LangChain, оглядываясь на опыт последних трех лет (с 2023 по 2026 год), дает однозначный ответ: фреймворки полезны, но только если они эволюционируют с той же скоростью, что и сами модели. Ключевой сдвиг произошел в понимании роли инструментов: от жесткого кодирования логики индустрия перешла к делегированию решений самой модели, а фокус разработки сместился с написания кода на «наблюдаемость» (observability) и отладку поведения.

Контекст

Чтобы понять текущее состояние индустрии, нужно посмотреть на три поколения агентных систем, которые мы наблюдали:

1. Эпоха цепочек (Chaining, 2023): Ранний LangChain стал популярен как способ соединить «сырые» модели с данными. Это было время жестких инструкций и последовательных действий. Тогда фреймворки часто критиковали за излишнюю сложность, но они помогали стандартизировать работу в условиях, когда мало кто понимал, как вообще применять LLM.
2. Эпоха оркестрации (Orchestration, 2024-2025): Появился LangGraph — инструмент более низкого уровня. Он добавил управление состоянием (state) и памятью, что стало критически важным для создания сложных взаимодействий между агентами и людьми.
3. Эпоха автономных «упряжек» (Harnesses, 2026): Современные решения, такие как DeepAgents. Поскольку модели стали лучше рассуждать, разработчики начали делегировать им принятие решений о планировании и вызове инструментов, вместо того чтобы прописывать каждый шаг вручную.

Детали

Главный аргумент против использования фреймворков всегда заключался в том, что они добавляют лишний слой абстракции, который быстро устаревает. Однако практика показала, что «сидеть и ждать», пока технологии устоятся — проигрышная стратегия. Фреймворки позволяют кодировать лучшие практики, уменьшать количество шаблонного кода и быстрее выводить продукты в продакшн.

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

Именно поэтому платформа LangSmith была отделена от открытого кода LangChain. Она поддерживает трассировку и оценку качества работы агентов независимо от того, на чем они написаны — будь то AutoGen, CrewAI, Vercel AI SDK или вообще самописное решение без фреймворков.

Анализ

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

• Среда исполнения (Runtime/Harness): Инструменты для построения логики (LangChain, LangGraph, DeepAgents). Здесь всё зависит от задачи. Для простого запроса к LLM фреймворк может быть избыточен. Для долгоживущего автономного агента, который работает с файловой системой и планирует задачи на часы вперед, необходима надежная среда управления состоянием.
• Наблюдаемость (Observability): Инструменты для анализа поведения (LangSmith). Это стало обязательным стандартом. Невозможно улучшать систему, если вы не видите, почему агент принял то или иное решение, зациклился или выдал ошибку.

Подход «батарейки в комплекте» (batteries-included), реализованный в новых инструментах вроде DeepAgents, указывает на зрелость рынка. Разработчикам больше не нужно собирать агента по винтикам; им нужна готовая, но гибкая структура, способная использовать возросшие когнитивные способности моделей.

Перспектива

Индустрия движется к конвергенции процессов построения и тестирования. Создание агента — это только первый шаг. Основная работа инженера смещается в область «агентной инженерии» (agent engineering), где главными инструментами становятся не IDE для кода, а платформы для анализа трассировок и автоматической оценки качества (evals).

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