← Университет

Фреймворки и системы: что выбрать ядром для завода Лучиана

Сравнение восьми систем из mas-research/systems/*.md (LangGraph, CrewAI, AutoGen/AG2, OpenAI Agents SDK, OpenClaw, OpenHands/MetaGPT, Claude Agent SDK, PAUL Framework) + транскрипты про агентную инженерию. Задача — не пересказать досье, а дать предварительную архитектурную рекомендацию ядра для его системы, с аргументами именно под его завод, деньги и токеномику.

1. Зачем вообще выбирать «ядро» — и что это значит

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

  1. «Мозг» (какая LLM думает) — у Лучиана это уже решено: подписка Claude (claude -p, мульти-аккаунт failover), НЕ API-ключи. Это зафиксировано в 04-server и 02-factory-overview HERMES_HANDOFF: «мозг завода = подписка Claude... частый источник багов». Это значение уже вложено и работает.
  2. «Оркестратор» (кто управляет циклом агент→инструмент→агент, кто хранит состояние, кто спавнит субагентов) — вот это и есть настоящий вопрос ядра. Именно тут фреймворки различаются принципиально.

Важное наблюдение из транскрипта Building Effective Agents with LangGraph (Anthropic + LangChain): следует различать workflows (жёстко заданный путь, предопределённое число шагов) и agents (LLM сама решает, сколько шагов сделать). У Лучиана де-факто уже работает workflow — конвейер ⓪→⑨ в channel-hq — с двумя человеческими гейтами (EDIT_PENDING, APPROVAL_PENDING). Оркестратор channel-hq/core/orchestrator.mjs существует, но выключен. Это значит: завод построен как классический DAG-конвейер (близко к философии LangGraph: State/Node/Edge), а не как «свободный» агент. Переход к ночной автономии — это не смена фреймворка, а включение оркестратора и замена части человеческих гейтов на агентов-критиков — при сохранении workflow-скелета там, где предсказуемость важнее гибкости (аплоад, деньги), и добавление agent-loop там, где нужна импровизация (ресёрч ниш, MVP-веер для консультаций).

2. Матрица восьми систем — принципы, а не фичи

2.1 LangGraph — «граф, а не абстракция»

Ключевая цитата из досье: «LLMs generate text. LangGraph governs behavior». Три примитива — State (TypedDict), Nodes (чистые функции), Edges (направленные и условные) — дают детерминированный контроль потока. Checkpointing после каждого шага решает ровно ту проблему, которую сам Лучиан фиксирует как больную: раздувание контекста и потерю прогресса при сбое (его правило «упал прогон — резюмируй, не удаляй» — это ручная реализация того, что LangGraph делает автоматически через PostgresSaver). Klarna сэкономила $60M, заменив 853 сотрудника ботом на LangGraph — но кривая обучения 2-3 дня даже для опытных разработчиков, и фреймворк Python-first (JS SDK отстаёт).

Для Лучиана LangGraph — это не сам оркестратор, а язык описания графа. У него уже есть Python/Node инфраструктура сервисов (16+ докер-контейнеров) — можно взять LangGraph как библиотеку внутри одного сервиса (например, следующая версия content-planner или opportunity-scout), но не как «единую операционную систему» для всего завода: это была бы избыточная миграция уже работающей инфраструктуры на чужие абстракции состояния.

2.2 CrewAI — «роли вместо графа»

Философия: «Ваш AI не работает в одиночку». Простая ролевая модель (Agent/Task/Crew/Process) быстрее осваивается, чем граф. Но досье честно фиксирует критический недостаток: иерархический режим не умеет условно пропускать агентов — менеджер выполняет всё последовательно, даже когда часть работы не нужна, что дало пример 15 759 токенов на простой запрос вместо ожидаемых 200. Это прямая иллюстрация той самой «токеномической» боли, которую Лучиан уже испытал (раздувание контекста до ~1М токенов на 12-шаговых задачах). CrewAI решает это через Flows (явная маршрутизация) — но тогда теряется «простота», ради которой CrewAI и выбирают.

2.3 AutoGen/AG2 — «диалог вместо графа»

Парадигма другая: агенты общаются как в чате, GroupChatManager выбирает следующего говорящего через LLM. Плюс — эмерджентность и «дебаты» (полезно для судейских панелей — прямое попадание в паттерн Лучиана «параллельные MVP + турнир критиков»). Минус — незрелость (AG2 всё ещё beta v0.7.x в 2026, оригинальный AutoGen — maintenance mode) и склонность к бесконечным циклам без явного max_round. AG2 хорошо подходит именно для режима консультанта («веер 3-10 MVP, агенты спорят и ранжируют») как локальный паттерн внутри одного модуля, а не как каркас всей системы.

2.4 OpenAI Agents SDK — не подходит по определению

Полностью привязан к моделям OpenAI (нет мультипровайдерности), а у Лучиана «мозг» — подписка Claude. Единственный сценарий использования — если завод когда-нибудь начнёт параллельно дергать GPT для конкретной узкой задачи (например, сравнение качества генерации между моделями). Как ядро — отклоняется сразу.

2.5 OpenClaw — ближе всего по духу, но не по масштабу

OpenClaw уже знаком Лучиану (в профиле указано «пробовал OpenClaw/Hermes»). Архитектурно он ближе всего к его текущей интуиции: Local-First Gateway, каналы (Telegram и др.), MEMORY.md + memory/YYYY-MM-DD.md + .learnings/ — это практически калька структуры памяти, которую он уже частично воспроизвёл в memory-bank (3 банка: global/per-channel/per-generator). Двухуровневая иерархия субагентов (максимум 5 на родителя, depth 0/1/2) — тот самый guardrail против «взрывного разрастания», который нужен и его системе. Но: реальный пример стоимости из досье — «Steinberger: 100+ параллельных агентов = $1.3 млн/месяц на 603 млрд токенов» — это ровно тот кошмар, которого боится Лучиан («монстр, кушающий $1000 в минуту»). Плюс критические уязвимости 2026 (CVE-2026-25253 RCE через WebSocket, 30 000+ незащищённых инстансов, 15% skills в ClawHub с malware) требуют серьёзной изоляции, если ставить OpenClaw как публичный Gateway.

2.6 OpenHands / MetaGPT — узкоспециализированные, не ядро

OpenHands — «control center для coding agents» (переключение между backend'ами: локальный/облачный/Claude Code). MetaGPT — симуляция software-компании (PM→Architect→PM→Engineer, Code = SOP(Team)) для одноразовой генерации целого репозитория из одной строки требования. Оба идеально подходят как строительный блок «Строителя приложений» (приоритет №1 Лучиана: по одной команде построить сайт/тулзу ночью), но не как оркестратор всего завода — у них нет общей памяти между запусками уровня всего бизнеса, только per-workspace persistence.

2.7 Claude Agent SDK — единственный кандидат, совместимый по всем осям

Ключевое отличие от остальных: это не альтернативный «фреймворк со своей философией», а официальная библиотека поверх той же Claude CLI-модели, которую завод уже использует (claude -p). Из досье: «SDK — это инфраструктурный слой Claude Code, выставленный как библиотека». Архитектура subprocess (один процесс claude = одна сессия, JSONL-трансценд на диске) — прямое расширение того, что уже происходит в channel-hq и генераторах. Субагенты получают изолированный контекст (наследуют только system prompt + CLAUDE.md + prompt делегирования; НЕ наследуют историю родителя) — это архитектурное решение именно той токеномической проблемы, которую Лучиан сформулировал как отдельное критическое требование. Цитата из досье: «большие объёмы работы... не загромождают главный контекст» — это буквально формулировка его правила «оркестратор передаёт выжимки, не сырьё».

Ограничение по глубине (5 уровней) и параллелизм («время завершения = время самого медленного субагента, а не сумма») тоже совпадают с уже усвоенными паттернами OpenClaw, которые Лучиан видел на практике. Hooks (PreToolUse/PostToolUse/Stop/SessionStart) дают детерминированные guardrails без LLM — прямое попадание в его правило №3 «скрипт вместо ИИ где можно».

2.8 PAUL Framework — не платформа, а дисциплина

PAUL — не оркестратор, а методология поверх Claude Code (Plan→Apply→Unify Loop) с обязательным закрытием цикла (/paul:unify), критериями приёмки Given/When/Then до старта работ и статусами DONE_WITH_CONCERNS/NEEDS_CONTEXT вместо бинарного «готово». Это прямое лекарство от проблемы, описанной в web/case-studies-failures.md: «Loop of Death — агенты застревают в циклах исправления ошибок» и «10-шаговая задача при 95% точности на шаг имеет только 60% шанс полного успеха». PAUL не заменяет ядро — он накладывается на Claude Agent SDK / Claude Code как слой дисциплины для этапа «Строитель приложений» (план→код→критика→тест→визуальная проверка→доработка — этот пайплайн из профиля Лучиана почти дословно совпадает с PLAN→APPLY(Execute/Qualify)→UNIFY).

3. n8n — отдельный вопрос: клей, а не мозг

n8n (досье web + отдельный систем-файл) заслуживает отдельного комментария, потому что Лучиан уже пользуется low-code инструментами и явно ненавидит роль «человека-клея» между сервисами (боль №1 в профиле). AI Agent Tool node в n8n решает именно проблему оркестрации нескольких визуальных агентов на одном canvas, но исследование прямо предупреждает: «контекст между агентами передаётся неявно, требует careful prompt engineering» и «memory limitations: по умолчанию max 100MB execution data». Для завода с 16+ докер-сервисами и уже написанной логикой на Node/Python n8n — это инструмент для быстрых интеграционных мостиков (например, триггер по webhook → цепочка HTTP-вызовов между сервисами завода), а не замена оркестратора. Использовать точечно, не архитектурно.

4. Итоговая рекомендация: гибридное ядро, не единый фреймворк

Предварительный вывод, вытекающий из сопоставления досье с профилем Лучиана:

Ядро — Claude Agent SDK поверх уже существующей подписки Claude, с тремя надстройками:

  1. PAUL-подобная дисциплина (Plan/Apply-Execute-Qualify/Unify с критериями приёмки) — для режима «Строитель приложений» и «Консультант-фабрика MVP», где нужен формальный критерий, что MVP готов к демо, а не просто «агент сказал done».
  2. LangGraph-паттерн (state + checkpoint) как модель мышления, не обязательно как библиотека — потому что оркестратор channel-hq уже неявно реализует граф стадий ⓪→⑨ с гейтами; включение orchestrator.mjs и добавление персистентного state — это именно закрытие той дыры, которую и решает LangGraph концептуально (у Лучиана уже есть свой JSON-based checkpoint в state.json каждого проекта — не обязательно тащить Postgres/LangGraph, если своя реализация работает).
  3. AutoGen-подобный debate/consensus паттерн локально — для конкретного модуля «judge panel»: параллельные MVP-варианты, которые критикуют и ранжируют друг друга. Это узкий, изолированный сценарий (не вся система), поэтому AG2 или просто несколько параллельных субагентов Claude SDK с разными системными промптами закрывают задачу без внедрения нового фреймворка целиком.

Почему не OpenClaw как ядро, при том что он ближе всего по духу: OpenClaw даёт готовый Gateway/каналы/skills-экосистему, но ценой (а) архитектурного дублирования того, что Лучиан уже построил вручную и понимает лучше (память, гейты, оркестрация), и (б) реального риска стоимости и безопасности при full autonomy (открытый WebSocket-Gateway, 15% вредоносных skills в публичном каталоге). Разумный компромисс — заимствовать идеи OpenClaw (Telegram/веб-канал поверх Gateway-подобного слоя, .learnings/ файлы, депth-ограничение субагентов), но реализовывать это на Claude Agent SDK, а не ставить сам OpenClaw как внешнюю зависимость с чужим кодом skills.

Почему не n8n/CrewAI/OpenAI SDK как ядро: n8n — интеграционный слой, не мозг долгоживущих агентов; CrewAI даёт красивую ролевую модель, но доказанно неэффективна при условной маршрутизации (токены); OpenAI SDK несовместим с текущим «мозгом» (Claude-подписка).

5. Типичные ошибки, которые фреймворки не решают сами по себе

Из всех досье и транскриптов повторяется один и тот же набор ловушек — важно проговорить их отдельно от выбора фреймворка, потому что ядро НЕ спасает от них автоматически:

6. Практические выводы для дорожной карты Лучиана

  1. Не менять «мозг» — подписка Claude остаётся, это уже правильное и рабочее решение, независимое от выбора оркестратора.
  2. Ядро оркестрации — Claude Agent SDK, потому что это прямое расширение уже работающей subprocess-модели завода (channel-hq уже использует claude -p и OAuth), без миграции на чужую систему состояния.
  3. Включить orchestrator.mjs не «вслепую», а по методологии PAUL: явные критерии приёмки (Given/When/Then) вместо простого «прошло/не прошло», с обязательным этапом UNIFY (сравнение плана с реальностью) — это прямая защита от ситуации «агент сказал done, а на самом деле нет».
  4. Модуль «Строитель приложений» — MetaGPT-подобный SOP-паттерн (PM→Architect→Engineer→QA) реализовать как набор субагентов Claude SDK с изолированным контекстом, а не тащить сам MetaGPT как зависимость (Python-lib с собственным конфигом и меньшей гибкостью, чем нативные субагенты Claude).
  5. Модуль «Консультант-фабрика MVP» (веер 3-10 вариантов + судейская панель) — паттерн parallel fan-out + role panels из Claude Agent SDK досье (уже описан как штатный паттерн: «Role Panels: Разные специализированные агенты рецензируют один артефакт с разных углов одновременно») — это буквально готовый рецепт под запрошенный Лучианом сценарий.
  6. n8n — оставить как точечный инструмент интеграции с внешними API/webhook-триггерами, не как архитектурный уровень.
  7. OpenClaw — не разворачивать как отдельный Gateway; при желании можно позаимствовать формат MEMORY.md/.learnings/, но без publичного WebSocket и без skills из чужого каталога (риск CVE и malware).

Документ носит предварительный характер: финальное решение по ядру должно быть подтверждено на этапе roadmap с учётом бюджета ($500–2000/мес), хостинга (VPS vs домашний ПК vs гибрид) и результатов пилота на одном сервисе завода (кандидат — content-planner или новый opportunity-scout).