Вопрос всплывает с завидной регулярностью: если LLM становятся умнее буквально на глазах, нужен ли вообще фреймворк для агентов? На первый взгляд — спорно. Но если смотреть без иллюзий, агент — это не только модель. Это ещё и слой вокруг неё: инструменты, память, маршрутизация, контроль выполнения, безопасность, трассировка. И вот этот слой никуда не девается. Он просто меняется, иногда довольно резко.
Если коротко, позиция LangChain здесь такая. Во-первых, фреймворки для агентов по-прежнему полезны — но лишь до тех пор, пока они успевают за темпом развития моделей. Во-вторых, наблюдаемость агента не должна зависеть от того, на чём именно вы его собрали: на своём стеке, на open source-библиотеке или вообще «на коленке». Собственно, поэтому LangSmith работает и без обязательной привязки к LangChain или LangGraph.
Об этом и пойдёт речь. Без лишнего лака — по существу.
Почему фреймворки AI-агентов всё ещё актуальны
Подходы к построению агентов менялись не по учебнику, а скорее рывками. Сначала — chaining, затем orchestration workflow, позже — циклы вызова инструментов, файловая система, память, субагенты. И да, всё это не просто разные названия. Это разные способы проектировать поведение системы.
LangChain за это время прошла через три поколения агентных инструментов, и каждое следующее заметно отличалось от предыдущего. Не косметически. По сути.
Chaining
Первый LangChain выстрелил в 2023 году в момент, когда рынок только пытался понять, как вообще применять LLM в реальных задачах. Фреймворк предлагал довольно прямой путь: подключить foundation models к данным, API и внешним сервисам через интеграции и базовые абстракции. Для старта — удобно. Для обучения — тем более.
Но, если честно, ранняя версия была местами слишком жёсткой в своих допущениях. Такой себе «быстрый вход» в prompting и RAG, а не идеальный production-инструмент на все случаи жизни. Когда первая волна генеративного ИИ немного улеглась, критика посыпалась ожидаемо: мол, фреймворки для агентов избыточны, мешают, прячут важные детали.
И всё же в реальных командах картина была другой. Большинству не хотелось каждый раз собирать всё с нуля. Нормальный фреймворк, если он сделан с головой, даёт вполне приземлённые преимущества:
- встраивает рабочие практики прямо в процесс разработки;
- сокращает объём шаблонного кода;
- помогает быстрее выйти на приемлемое качество;
- делает архитектуру понятнее для команды;
- упрощает путь от прототипа к production.
Именно поэтому ставка на фреймворки не исчезла. Она просто сместилась. Немного, а потом сильно.
Оркестрация и runtime
LangGraph появился как более низкоуровневый и гибкий инструмент. Он добавил runtime с поддержкой состояния и долговременного выполнения — а это, как быстро выяснилось, критично для сценариев, где есть взаимодействие человек–агент или агент–агент. Иными словами, когда система живёт дольше одного запроса и должна помнить, где остановилась.
Этот подход закрыл многие претензии к раннему LangChain, особенно там, где разработчикам был нужен контроль, а не магия одной кнопки. Позже, в 2025 году, исходный LangChain тоже переработали, сделав его легче и стройнее. Но сам вывод остался прежним: один инструмент не обязан подходить под все сценарии. Да и не подходит, чего уж.
Harness-подход
Следующий шаг — deepagents, то есть agent harness с готовой инфраструктурой «из коробки». Он ориентирован на более высокую производительность и при этом оставляет пространство для гибкой настройки. Поддерживаются планирование для длинных задач, циклический вызов инструментов, выгрузка контекста в файловую систему и оркестрация субагентов.
Почему такой подход вообще заработал? Потому что сами LLM стали заметно сильнее в рассуждении. Всё больше решений можно не зашивать в код намертво, а делегировать модели. Это меняет саму логику разработки AI-агентов: меньше жёстких сценариев, больше управляемой автономии.
По духу deepagents ближе всего к Claude Agent SDK, но при этом не привязан к одной модели или одному стеку приложений. Для рынка это важный момент. Особенно если вы строите корпоративные решения, где сегодня одна модель, завтра другая, а переписывать всё заново — удовольствие сомнительное.
Сейчас LangChain рекомендует разные инструменты под разные use cases. И LangChain, и deepagents опираются на runtime из LangGraph, когда нужна long-running execution. То есть не «или-или», а скорее набор слоёв, которые комбинируются под задачу.
За три года рынок, по сути, увидел три поколения агентных систем. Всё начиналось с RAG, потом пришли agentic workflow, а затем — более автономные агенты с циклическим вызовом инструментов. Картина меняется быстро. Иногда даже слишком быстро. Но это не аргумент против фреймворков как таковых — скорее аргумент в пользу того, что архитектура AI-агентов должна быть гибкой и пересматриваемой.
Да, есть популярный контраргумент: в AI всё развивается настолько стремительно, что стандарты просто не успевают оформиться. В этом есть правда. Но сидеть в стороне и ждать, пока всё «устаканится», — стратегия, мягко говоря, так себе. Фреймворки помогают быстрее войти в тему, быстрее собирать рабочие решения и не тратить недели на повторение уже известных ошибок.
При этом фреймворк нужен не всегда. Если у вас один простой вызов модели без сложной логики, памяти, инструментов и контроля исполнения, тяжёлый слой абстракций может только мешать. Тут без фанатизма. Иногда молоток — это просто молоток, а не платформа для забивания гвоздей.
Почему LangSmith изначально сделали независимым от open source-фреймворков
Довольно рано в LangChain заметили простую вещь: главное препятствие на пути к production — не сама генерация, а качество. Точнее, способность это качество измерять, отслеживать и улучшать. Поэтому наблюдаемость агентов и evals стали не приятным дополнением, а обязательной частью инженерного стека.
Так появился LangSmith. Название, по сути, отражало идею: компания не рассчитывала, что на рынке будет существовать один-единственный фреймворк, вокруг которого все дружно выстроятся. Даже если бы такой лидер и появился, ему всё равно пришлось бы меняться настолько быстро, что ранние версии быстро потеряли бы сходство с самими собой.
Отсюда и решение: LangSmith должен работать независимо от того, использует ли команда LangChain, другой фреймворк или собственную реализацию. На тот момент это было не самым очевидным ходом, но логика понятна — наблюдаемость не должна быть заложником конкретной библиотеки.
Сегодня LangSmith интегрируется с разными фреймворками из коробки: AutoGen, Claude Agent SDK, CrewAI, Mastra, OpenAI Agents, PydanticAI, Vercel AI SDK и другими. Плюс поддерживается tracing на базе OpenTelemetry, а значит, в систему можно передавать данные из любого стека, который следует спецификации OTEL. Это уже не просто удобство, а серьёзная база для безопасности AI-агентов, аудита и контроля качества в enterprise-среде.
И да, LangSmith работает даже с агентами, собранными вообще без фреймворка. Среди клиентов есть компании, которые не используют open source-инструменты LangChain, но всё равно полагаются на LangSmith для observability и evals. Что, в общем, довольно показательно.
Разработка и тестирование в agent engineering всё сильнее сходятся
Какой бы фреймворк вы ни выбрали — или не выбрали вовсе, — без traces понять поведение агента почти невозможно. Именно трассировки показывают, что произошло на самом деле: какой контекст был передан, почему модель выбрала тот или иной инструмент, где сломалась логика, на каком шаге поплыл результат. Код тут уже не единственный источник правды. Иногда и не главный.
В агентных системах логика приложения всё чаще проявляется именно в traces. Они нужны для отладки, мониторинга, оценки качества, анализа сбоев и последующей оптимизации. Это особенно важно, потому что агенты по своей природе недетерминированы: до запуска в реальной среде вы не всегда можете предсказать, какие входы получите и какие выходы система сочтёт уместными.
Вот почему debugging, testing и monitoring становятся не отдельными этапами после разработки, а частью самой разработки. Практически одним процессом. Чуть сумбурно звучит, но так и есть: сначала вы строите агента, потом наблюдаете за ним, потом снова перестраиваете — и этот цикл не заканчивается на релизе.
Для корпоративных команд это особенно чувствительно. Когда речь идёт о мультиагентных системах, агентной памяти, RAG, требованиях к воспроизводимости и регуляторным ограничениям, без наблюдаемости всё быстро превращается в чёрный ящик. Красивый, дорогой и местами нервирующий.
Поэтому главный вывод здесь довольно приземлённый. Не так важно, используете ли вы OSS-фреймворки LangChain. Важно, понимаете ли вы, как ведёт себя ваш агент, где он ошибается, как это измерить и как исправить. А ещё — как обеспечить AI compliance и соответствие требованиям, если решение работает в реальном бизнес-контуре.
Именно в этом месте разговор о фреймворках и разговор о наблюдаемости сходятся. Не идеально, не по линейке — но очень по делу.