OpenClaw vs LangChain: почему мы не используем фреймворки
OpenClaw — это тонкий движок выполнения. LangChain — это толстый фреймворк. Вот почему это различие имеет значение и почему мы выбрали первый вариант.
Первый вопрос, который люди задают, увидев Claw-Stack: почему бы не использовать LangChain? Это доминирующий Python-фреймворк для AI-агентов, у него огромная экосистема, и он обрабатывает много работы, которую вам иначе пришлось бы писать самостоятельно. Ответ связан с тем, что означает слово “фреймворк” и что нам на самом деле было нужно.
Что такое OpenClaw (и что это не такое)
OpenClaw — это npm-пакет. Вы его устанавливаете, конфигурируете, и он работает как локальный процесс, который дает Claude доступ к инструментам — файловой системе, шеллу, MCP-серверам, памяти. Это runtime, а не фреймворк. Он не диктует вам, как организовать логику вашего агента. Он просто выполняет вызовы инструментов и управляет сессиями.
Это важное различие. OpenClaw имеет мнение о том, как вызываются инструменты, но он не имеет никакого мнения о том, что делает ваш агент. Нет базового класса для расширения, нет цепочки для композиции, нет графа для определения. Вы пишете файл CLAUDE.md, который описывает, как должен вести себя ваш агент, и OpenClaw запускает сессию Claude с этим контекстом и зарегистрированными инструментами.
LangChain — это противоположность. Он имеет сильные мнения о том, как вы должны структурировать логику агента: цепочки, runnable-объекты, агенты, инструменты, память, retriever-ы. Это фреймворк в классическом смысле — он предоставляет каркас, вы заполняете детали. Это полезно, когда каркас соответствует вашему случаю. Это проблема, когда он не соответствует.
Проблема абстракции
Абстракции LangChain разработаны вокруг идеи, что вы будете комбинировать вызовы LLM в конвейер: вход → получение информации → LLM → выход → следующий вызов LLM. Это хорошо работает для RAG-систем и простых агентов ответов на вопросы. Это начинает конфликтовать, когда вам нужно что-то, что не подходит под модель конвейера.
Наш многоагентный протокол встреч, например, запускает несколько экземпляров Claude в качестве “участников” структурированного обсуждения. Каждый участник читает историю беседы, формирует ответ и опционально сигнализирует о консенсусе или запрашивает новый раунд. Координатор затем решает, продолжать ли. Ничто из этого не подходит аккуратно под модель agent/tool в LangChain. Вы бы либо втискивали протокол в агента с пользовательскими инструментами, либо обходили большую часть абстракций LangChain.
С OpenClaw мы просто пишем логику координации сами. Агент-координатор — это сессия OpenClaw, которая читает текущее состояние из общего файла, вызывает агентов-участников как подпроцессы, собирает их ответы и решает, что делать дальше. Это написано на JavaScript (Node.js ES modules), разбросано по шести исходным файлам — координатор, менеджер сессий, summarizer, детектор консенсуса, обработчик timeout-а и писатель протокола — и каждая строка делает то, что мы понимаем.
Опыт отладки
Когда что-то идет не так с LangChain-агентом, ошибка часто находится глубоко в стеке абстракций. Вы отлаживаете runnable, который вызывает цепочку, которая вызывает LLM, который возвращает выход, который парсируется output parser-ом, который… где-то там что-то не сработало. Получение полезного stack trace требует понимания того, какой слой абстракции ответствен за какое поведение.
С OpenClaw, по сути, есть два места для поиска: реализация вашего инструмента и журнал сессии Claude. Если агент вызвал неправильный инструмент, вы проверяете историю сессии. Если инструмент выдал неправильный результат, вы проверяете инструмент. Нет промежуточного слоя, пытающегося быть полезным.
Это имеет большее значение, чем кажется. Мы запускали сессии, которые длились часами, включали десятки вызовов инструментов и накапливали несколько сотен килобайт контекста. Когда что-то идет не так во второй час, вы хотите иметь возможность прочитать журнал сессии и точно понять, что произошло. С тонким runtime-ом журнал сессии является полной записью того, что произошло. С толстым фреймворком внутреннее состояние фреймворка — это параллельный источник истины, который вам также нужно проверить.
Привязка и зависимости экосистемы
LangChain имеет более 500 интеграционных пакетов. Многие поддерживаются сообществом и ломаются при обновлении библиотек. Если вы строите логику агента вокруг абстракций LangChain, вы неявно принимаете зависимость от того, что все они поддерживаются и совместимы.
Модель интеграции OpenClaw отличается: интеграции происходят через MCP (Model Context Protocol). MCP-сервер — это просто процесс, который предоставляет инструменты. Написание MCP-сервера для нового источника данных — это около 50 строк кода. Интерфейс стандартный, протокол простой, и когда сломается интеграция третьей стороны, исправление ограничено этим сервером — оно не каскадирует через логику вашего агента.
Вот почему мы могли построить наш слой веб-автоматизации (26 инструментов Chrome DevTools Protocol), наш агрегатор контента об AI и технологиях и нашу интеграцию резервного копирования без какого-либо кода фреймворка. Каждый — это автономный MCP-сервер, который регистрирует свои инструменты в OpenClaw при запуске.
Когда LangChain имеет смысл
Это не общий аргумент против LangChain. Если вы строите RAG-систему, где основной поток управления — это: получить релевантные документы, передать их в LLM, вернуть ответ — абстракции LangChain хорошо соответствуют этому паттерну. LCEL (LangChain Expression Language) действительно чистый для композиции retrieval-конвейеров.
У него также есть сильные интеграции с векторными базами данных, document loaders и моделями эмбеддингов, которые потребовали бы времени на построение с нуля. Для команд, быстро прототипирующих или встраивающих обычные AI-функции в существующие Python-приложения, накладные расходы фреймворка стоят ярлыков интеграции.
Наш случай использования отличается. Мы строим систему AI-агентов, которая работает автономно, накапливает состояние в течение дней и недель, координирует несколько агентов на сложных задачах и нуждается в отладке, когда что-то идет не так. Для этого нам нужен был максимально прозрачный и минимальный runtime, который мы могли найти.
Принцип: тонкий runtime, богатые навыки
Наша архитектура следует принципу, который мы начали называть “тонкий runtime, богатые навыки”. OpenClaw — это runtime: он обрабатывает dispatch инструментов, управление сессиями и интерфейс с Claude. Все остальное — память, безопасность, координация многоагентов, веб-автоматизация — живет в отдельных, независимо развертываемых модулях.
Это означает, что каждый навык может быть протестирован в изоляции, заменен без касания других, и рассмотрен без понимания целой системы. Минус в том, что нужно написать больше вспомогательного кода. Плюс в том, что когда что-то ломается, это почти всегда в вспомогательном коде — который написали вы и понимаете.
Мы не пропагандируем этот подход как универсально правильный. Это правильный компромисс для исследовательского проекта, который нужно отлаживать, расширять и понимать на каждом уровне. Если вы отправляете функцию продукта на дедлайне, накладные расходы фреймворка LangChain могут того стоить. Для нас — нет.