SavePearlHarbor

DeerFlow 2.0 от ByteDance: развернул super-agent harness через Docker, прогнал на реальной задаче

—

от автора

admin

61 тысяча звёзд на GitHub за один релиз — это много или мало? Что под капотом, чем отличается от Claude Code и OpenHands, и где честные ограничения

В конце февраля 2026 ByteDance выложила вторую версию DeerFlow — open-source агентного фреймворка, который команда позиционирует как «super agent harness». Релиз залетел в топ-1 GitHub Trending, набрал 61 тысячу звёзд за пару недель, попал во все технические телеграм-каналы. Версия 2.0 — это полностью переписанный с нуля код, новая архитектура, отсылки на сравнение с Manus, Claude Code и другими «настоящими» агентами.

Я развернул DeerFlow 2.0 через Docker на своём VPS, погонял на пары реальных задач и провёл вечер с конфигом и логами. Расскажу, что внутри, как разворачивать, на чём он реально хорош, где спорно, и почему телеграм-маркетинг расходится с честным README в нескольких важных местах.

Сразу оговорка по жанру. Это не «руководство по запуску», для этого есть Install.md в репозитории — он довольно подробный. Это технический разбор архитектурных решений и личный опыт развёртывания. Цель — дать читателю Хабра достаточно информации, чтобы он сам решил, стоит ли разворачивать у себя.

Что такое DeerFlow и кому это вообще нужно

В мире AI-агентов сейчас стандартная путаница терминологии. У нас есть фреймворки (LangChain, LangGraph), агентные runtimes (AutoGPT, Claude Code, OpenHands), оркестраторы (CrewAI, AutoGen) — и все они претендуют называться «агентами». DeerFlow — это harness, инфраструктурный слой между LLM и реальными задачами. То есть не сама модель, не интерфейс к ней, а среда, в которой модель получает инструменты, память, песочницу, файловую систему, и может выполнять долгие многошаговые задачи.

Концептуально ближе всего DeerFlow стоит к Claude Code и OpenHands. Только Claude Code заточен под кодинг и Anthropic, OpenHands ориентирован на full-stack разработку с упором на изоляцию через Docker, а DeerFlow позиционируется как универсальный harness для «больших и долгих» задач: ресёрч с генерацией отчёта, создание презентаций, веб-страниц, изображений и видео, плюс что угодно через сабагентов.

Базовый кейс из README — research-task. Пользователь даёт задачу типа «исследуй рынок X и сделай отчёт». DeerFlow:

  1. Планирует подзадачи через lead-agent

  2. Параллельно запускает суб-агентов (поиск, скрапинг, анализ, верификация фактов)

  3. Накапливает результаты в файловую систему через sandbox

  4. Использует skills (структурированные навыки) для конкретных типов работы

  5. Собирает финальный отчёт через специализированный writer-агент То есть это не «один промпт — один ответ», а полноценная многошаговая работа, которая может идти от минут до часов. Поверх этого — long-term memory между сессиями, поддержка любых LLM провайдеров (через LangChain-совместимые адаптеры), интеграция с messaging-системами.

Под капотом — LangGraph для оркестрации, LangChain для абстракции LLM-провайдеров, отдельный sandbox-слой (локально, Docker или Kubernetes). Это серьёзная архитектура с production-ready амбициями, не игрушка.

Установка: реально один час, не «одной командой»

В рекламном описании я часто встречаю фразу «one-line setup». Чтобы было честно: одна команда там действительно есть, но она прокидывает агенту инструкции по настройке. Реальная развёртка состоит из нескольких шагов.

Я разворачивал через Docker. У меня был VPS с Ubuntu 22.04, 8 vCPU, 16 GB RAM, 60 GB SSD. По README этого хватает для одиночного режима использования.

Шаг 1: клонирование и setup-wizard.

git clone https://github.com/bytedance/deer-flow.gitcd deer-flowmake setup

Wizard — это интерактивный bash-скрипт, который спрашивает основные параметры: какой LLM-провайдер использовать, нужен ли web search, какой sandbox-режим выбрать. На выходе генерирует config.yaml и .env. Занимает реально 2-3 минуты.

Я выбрал OpenAI как провайдер, Tavily как поисковик и Docker-sandbox для безопасности. Все ключи API нужны заранее.

Шаг 2: doctor-проверка.

make doctor

Полезная команда — проверяет, что все зависимости установлены, ключи API валидны, sandbox доступен. У меня сразу нашлась проблема: на VPS не был установлен nginx, и make doctor про это аккуратно сказал. После установки повторный запуск прошёл чисто.

Шаг 3: запуск Docker-стека.

make docker-init   # подтянуть sandbox-образ (один раз)make docker-start  # запустить все сервисы

В режиме разработки запускается 4 контейнера: frontend (Next.js), gateway API, LangGraph server, nginx-reverse-proxy. Плюс отдельно поднимаются sandbox-контейнеры по требованию. Стандартный порт — http://localhost:2026.

У меня первый запуск занял около 12 минут — сборка образов, скачивание зависимостей, поднятие сервисов. Повторный запуск секунд 30-40.

В сумме развёртывание заняло около часа с учётом разбора ошибок и настройки. Это не катастрофа, но не «one-line».

Конфигурация и Gateway-режим

Самое неочевидное в DeerFlow — это деление на два режима исполнения: Standard и Gateway. Об этом стоит сказать отдельно, потому что в маркетинговых описаниях этого нет, а на практике от выбора зависит ресурсопотребление.

Standard Mode. Используется по умолчанию. Agent runtime крутится на отдельном LangGraph-сервере (это решение от LangChain Inc). 4 процесса, 2 Python-runtime. Лицензия LangGraph Platform для production требуется.

Gateway Mode. Экспериментальный. Agent runtime встроен прямо в Gateway API. 3 процесса, 1 Python-runtime. Лицензия LangGraph не нужна. Cold-start быстрее, ресурсов меньше.

Я выбрал Gateway Mode — он легче по ресурсам, и для индивидуального использования логичнее. Запускается так:

make docker-start-pro

В моём кейсе разница в потреблении RAM получилась ощутимая: в Standard примерно 4.5 GB суммарно по контейнерам, в Gateway — около 3 GB. Это особенно важно, если ты крутишь это на small VPS.

В конфиге моделей всё стандартно для LangChain-совместимых провайдеров:

models:  - name: gpt-4o-mini    display_name: GPT-4o Mini    use: langchain_openai:ChatOpenAI    model: gpt-4o-mini    api_key: $OPENAI_API_KEY    - name: claude-sonnet-4-6    display_name: Claude Sonnet 4.6 (Claude Code OAuth)    use: deerflow.models.claude_provider:ClaudeChatModel    model: claude-sonnet-4-6    max_tokens: 4096    supports_thinking: true

Интересная деталь — DeerFlow поддерживает «CLI-backed providers», то есть может использовать Claude Code OAuth или Codex CLI как backend для своих агентов. Если у тебя уже есть подписка Claude Pro, можно не подключать отдельный API-ключ Anthropic, а использовать локальный OAuth-токен из ~/.claude/.credentials.json. Это уменьшает затраты, если ты уже платишь Anthropic.

Это, кстати, прямой ответ на маркетинговый тезис «интегрируется с Claude Code». В реальности направление обратное: DeerFlow использует Claude Code как провайдер, а не «отправляет задачи в DeerFlow из IDE». Это технически разные вещи, и важно понимать.

Реальный кейс: исследование рынка кофейных машин

Чтобы протестировать harness по-настоящему, я взял конкретную задачу. У меня дома сломалась эспрессо-машина, нужна замена в диапазоне 80-120 тысяч рублей. Я хотел понять: какие модели в этом диапазоне сейчас актуальны, какие у них болячки, что предпочитают на форумах.

Промпт DeerFlow:

Исследуй рынок домашних эспрессо-машин в России в диапазоне 80-120 тысяч рублей. Найди 5-7 актуальных моделей. Для каждой собери:- технические характеристики- частые проблемы из отзывов- альтернативы в этом же бюджете- сравнительный плюс/минус Финал — отчёт в формате markdown с таблицей.

DeerFlow в Gateway-режиме отработал так:

Минута 1. Lead-agent разбил задачу на подзадачи, выбрал инструменты — Tavily для веб-поиска, web-fetch для глубокого парсинга страниц, file-system для накопления промежуточных результатов.

Минуты 2-15. Параллельно запустилось несколько суб-агентов. Один искал общие списки «топ эспрессо-машин 2026», другой собирал отзывы с форумов (4pda, форумы любителей кофе), третий читал спецификации производителей. В sandbox создавались промежуточные .md файлы по каждой модели.

Минуты 15-20. Writer-агент собирал финальный отчёт. На этом этапе он несколько раз возвращался в файлы для уточнения деталей и делал дополнительные веб-поиски для подтверждения цифр.

Минуты 20-25. Финальный отчёт. Получилось около 4 страниц с таблицей сравнения 6 моделей, описанием каждой, частыми проблемами из отзывов и итоговой рекомендацией.

Что мне понравилось в результате:

  • Структура отчёта действительно осмысленная: не «дамп найденного», а аналитика с приоритизацией.

  • Указаны источники для каждого утверждения с URL.

  • Конкретика по проблемам — не «бывают вопросы к надёжности», а «у модели X из 50 отзывов на Wildberries у 7 пользователей течёт парогенератор через 6-9 месяцев». Что не понравилось:

  • Стоимость прогона. По логам — около 180 тысяч токенов в общей сумме (input + output). На GPT-4o это около $1.50 за один такой ресёрч. Для серьёзного использования нужно считать бюджет.

  • Время. 25 минут на ресёрч — это много. Понятно, что это лучше часа моего ручного гугления, но не «секундная магия».

  • Иногда галлюцинирует цифры. В отчёте была фраза про «среднюю цену модели Y — 95 тысяч рублей». Я проверил — на актуальных площадках она 110-115 тысяч. Это типичная LLM-проблема при работе с быстро меняющимися данными.

Skills и Sub-Agents: на чём всё держится

Архитектурно ядро DeerFlow — это два слоя: skills и sub-agents.

Skills — это структурированные капабилити-модули, каждый — Markdown-файл с описанием воркфлоу, лучших практик и ссылок на ресурсы. Это та же концепция, что в Anthropic Agent Skills, что в book-to-skill, что в claude-skills репозиториях. DeerFlow ставится с встроенным набором: research, report generation, slide creation, web pages, image и video generation.

Ключевое — skills грузятся прогрессивно. То есть когда стартует ресёрч-задача, в контекст подгружается только research.md, а если потом понадобится сгенерировать презентацию, дополнительно подтянется slides.md. Никакого «всё разом в контекст» — это сильно экономит токены и позволяет работать с моделями вроде GPT-4o-mini, у которых ограничения по context window.

В моём docker-разворачивании skills лежат в skills/public/ — там 7-8 директорий со скиллами от ByteDance. Можно создавать свои в .agent/skills/ — это документировано в Install.md.

Sub-agents — это полноценные дочерние агенты, которые lead-agent может спавнить параллельно. Каждый получает свою задачу, свой контекст, свой набор инструментов. Это решает проблему context bloat: вместо того, чтобы один агент пытался удерживать в памяти всё (поиск + анализ + написание), задача распараллеливается.

В коде это реализовано через LangGraph state graph с динамическим спавном узлов. Подсмотрев пару скиллов, я видел, как lead-agent вызывает spawn_subagent() с конкретным promptm-шаблоном и набором инструментов. После завершения суб-агент возвращает структурированный результат, который lead подхватывает.

Это, наверное, главное архитектурное отличие DeerFlow от более простых runtime’ов: настоящая многоагентная топология, не просто «один LLM плюс tools».

Безопасность: то, о чём в телеграм-постах не пишут

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

DeerFlow по дефолту имеет доступ к shell, file system, web fetch, MCP servers. Это полноценный агент с правами на исполнение команд. README содержит большой раздел Security Notice, где автор прямо предупреждает:

«Improper deployment may introduce security risks»

Возможные риски, которые описаны в самом README:

  • Агент может скачивать и исполнять произвольный код в sandbox

  • Через MCP-серверы возможен доступ к внешним системам

  • При неправильной настройке прав может быть compromise файловой системы хоста

  • Web search и web fetch потенциально могут попадать на вредоносные ресурсы Авторы рекомендуют:

  • Использовать Docker-sandbox (не локальное исполнение) для любого, что не на dev-машине

  • Запускать в изолированной сети без доступа к чувствительным сервисам

  • Ограничивать набор MCP-серверов только проверенными

  • Не запускать на машинах с production-данными

  • Регулярно ротировать API-ключи Я лично разворачивал на отдельном VPS, не на рабочем ноутбуке. Это правильный подход. Когда вы видите в телеграм-посте «без ограничений, без лимитов», стоит помнить: это означает не «безопасно», а «у вас полная свобода настройки в том числе и неправильно».

Где DeerFlow проигрывает аналогам

Чтобы не выглядеть как реклама, перечислю минусы.

Сложность установки выше, чем у Claude Code. Claude Code ставится одной командой npm install -g. DeerFlow требует Docker, конфигов, базы, sandbox-настройки. Для индивидуального разработчика это барьер.

Документация местами противоречивая. README на английском, README_ru.md есть, но я нашёл расхождения с актуальной конфигурацией (упоминаются конфиги, которые в последних коммитах переименованы). Issue №422 на эту тему открытых — много.

Frontend-UX уступает Claude Code и Cursor. Это субъективно, но Next.js-фронтенд DeerFlow визуально и эргономически проще, чем у конкурентов. Видимо, фокус разработчиков пока на backend и архитектуре.

Стоимость прогона задач высокая, если использовать топовые модели. $1.50-2 за ресёрч-задачу на GPT-4o складывается в серьёзные суммы при ежедневном использовании. Это можно резать, используя локальные модели (DeerFlow поддерживает vLLM), но тогда теряется качество.

Ещё не зрелый продукт. Версия 2.0 вышла в феврале 2026, по сути в продакшене 1.5 месяца. Issue tracker и PR-очередь говорят, что много ещё допиливается. Для серьёзных рабочих задач я бы подождал ещё пару минорных релизов.

Заявления «убил всех ИИ-агентов» сильно преувеличены. DeerFlow — это альтернатива, причём со своими нишами (multi-channel IM-интеграции, скиллы для презентаций и видео, китайские LLM из коробки), но не «убийца» Claude Code или OpenHands. У всех этих систем разная архитектурная философия, и сравнение их «кто круче» примерно как «BMW или Tesla».

Кому это реально нужно

После двух недель я для себя сформулировал так:

Стоит развернуть, если:

  • Вы строите команду или продукт вокруг автономных AI-задач, не привязанных к одному IDE

  • Вам нужна интеграция с Telegram/Slack/Feishu для приёма задач — это уникальная фича DeerFlow

  • У вас есть мощности для запуска (хотя бы 8 vCPU / 16 GB RAM)

  • Вы готовы вкладывать время в настройку и обновления

  • Вам интересно изучить устройство многоагентных систем через работающий пример Не стоит, если:

  • Вам нужен «AI-агент в IDE» — для этого есть Claude Code, Cursor, Windsurf

  • У вас нет времени на DevOps-сторону вопроса (Docker, конфиги, мониторинг)

  • Вы хотите «решить задачу за пять минут» — DeerFlow не про скорость одной задачи, а про автоматизацию долгих воркфлоу

  • Ваша задача укладывается в один LLM-вызов с парой инструментов — overengineering Я лично продолжаю использовать DeerFlow для конкретных кейсов (ресёрч с генерацией отчёта, реакция на задачи через Telegram-бота), но Claude Code остаётся моим основным инструментом для разработки. Это разные классы инструментов под разные задачи.

Главные технические уроки

Несмотря на критику, я считаю DeerFlow 2.0 крутым проектом — и не как «убийцу» чего-то, а как архитектурный пример многоагентной системы, который можно изучить и многое позаимствовать.

Несколько уроков, которые я для себя вынес:

Прогрессивная загрузка skills — правильный паттерн. Когда у вас есть набор разнородных возможностей агента, не нужно держать их все в системном промпте. Структурируйте через файлы и подгружайте по требованию. Это работает не только в DeerFlow — это применимо к любой системе с большим набором tool/skill-определений.

Two-tier deployment (Standard / Gateway) — это правильное решение архитектурной дилеммы. Дать пользователю выбор между «правильно по архитектуре, но дорого по ресурсам» и «компромиссно, но легко» — лучше, чем навязывать одно решение. Многие open-source проекты этого не делают и теряют либо пользователей с слабыми машинами, либо production-кейсы.

Sub-agents через LangGraph state graph — рабочий паттерн. Я уже видел этот подход в нескольких проектах (включая claude-skills и Anthropic-овский Multi-Agent Research System). В DeerFlow он реализован чисто, и можно посмотреть, как это масштабируется на сложные топологии.

Honest README spares pain. Раздел Security Notice — отличный пример того, как должна выглядеть production-готовая документация. Не «всё работает идеально», а «вот риски, вот рекомендации». Это уважение к пользователю.

Главное

DeerFlow 2.0 — это серьёзный open-source super-agent harness от ByteDance, который заслужил свои 61 тысячу звёзд технической глубиной, не маркетингом. Он решает реальные задачи — долгие многошаговые воркфлоу с многоагентной топологией, что отличает его от более простых tool-using LLM.

Развернуть у себя — реалистичный план: час времени, минимум 8 vCPU, конкретный кейс применения. Это не серебряная пуля, не «убийца ChatGPT», и не «one-click solution». Это инструмент с своим характером и своей нишей.

Если вы строите вокруг автономных AI-воркфлоу и готовы вкладываться в DevOps-настройку — берите. Если ищете «улучшение существующей IDE» — это не сюда, идите к Claude Code, Cursor или Windsurf.

И в любом случае стоит хотя бы заглянуть в код. LangGraph-based многоагентная система с прогрессивной загрузкой skills — это материал, на котором можно изучать архитектуру современных агентных систем, даже если в продакшен ставить его не планируете.

Полезные ссылки:

ссылка на оригинал статьи https://habr.com/ru/articles/1034900/