Современные AI-агенты строятся достаточно разнообразно. Где-то берут готовые приложения, которые выросли в полноценные фреймворки с преднастроенными агентами. Где-то провайдеры предлагают настройку из готовых блоков через UI на веб-портале. Где-то хочется написать своё: дешевле, в своём контуре или просто иначе. Один из популярных фреймворков для этого - LangChain / LangGraph: удобные обёртки, пайплайны, графы, интеграции под типичные куски агента.

В большинстве случаев агенты строятся вокруг базового цикла ReAct (Reasoning + Acting - рассуждение и действие): модель рассуждает, при необходимости вызывает инструмент (tool), смотрит результат и снова думает - пока не отдаст ответ. На короткой задаче этого хватает. На длинной - агент сам накапливает контекст: историю, результаты инструментов, планы, файлы. Вопрос смещается от «как написать промпт» к «как управлять всей этой средой». Этим занимается контекст-инжиниринг (context engineering). Глубокие агенты (Deep Agents) - готовая реализация этой идеи в экосистеме LangChain: не новый тип модели, а заранее собранная рабочая среда вокруг обычного агента (в API - create_deep_agent поверх create_agent).

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

Агенты сейчас обсуждают все подряд. Меняются фреймворки, появляются MCP-серверы, облака обещают «агента из коробки». Но в центре любой такой схемы по-прежнему одна и та же вещь — LLM: она читает контекст и формулирует следующий шаг. А между запросом к агенту и самой моделью — ещё несколько слоёв.

Сама модель всего лишь предсказывает вероятности следующего токена; снаружи нарастает луковица обёрток — о них и речь. Если собирать агента не из готового конструктора, понимание этой логики помогает быстрее найти источник проблемы: поломки могут быть не в модели, а на каком-то уровне рядом. Я пришёл к агентам из ML: для меня каждый новый слой появлялся поверх уже знакомого — поэтому дальше рассказываю от модели наружу. Идея статьи пришла после очередного совместного поиска бага с технической командой: захотелось собрать заметки в один обзор, чтобы в следующий раз было проще объяснять.