Мы с нуля соберём мультиагентную систему для анализа реального open-source репозитория.
Но ценность проекта не в том, чтобы научиться анализировать именно GitHub.
GitHub здесь - полигон, на котором можно безопасно пройти весь путь от первого вызова LLM до системы, которую уже можно проектировать с расчётом на prod.
Без доступа к рабочим данным, без подключения корпоративного GitHub и без риска что-нибудь сломать.
❗️Работать будем со сторонним open-source репозиторием OpenClaw.
Агент сможет получать запрос на обычном человеческом языке:
«На что пользователи жалуются чаще всего?»
И самостоятельно понять, что ему нужно сделать для ответа.
Звучит просто. Но готового SQL-запроса под такой вопрос нет.
Нужно определить намерение пользователя, решить, какие данные понадобятся, получить issues, PR, commits или releases, отобрать полезное, сопоставить результаты, сделать промежуточные выводы и понять, когда информации уже достаточно.
Заранее неизвестно ни количество шагов, ни нужный набор данных.
На этом и будем учиться проектировать агентов - не как обёртку над LLM, а как полноценную систему.
◻️Как она будет собираться
Начнём вообще без магии.
1️⃣LLM и agent loop
Сначала руками пройдём самый нижний уровень: HTTP-вызов модели, system, messages, обычный Python-цикл.
На них соберём ReAct и Plan→Execute и посмотрим, где заканчивается обычный вызов LLM и появляется агентное поведение.
Это важно не ради учебного упражнения. Когда понимаешь механику снизу, намного проще потом отлаживать систему, а не воспринимать фреймворк как чёрный ящик.
2️⃣Подключим данные и инструменты
Дальше агент получает доступ к GitHub API.
Внутри runtime появляются отдельные компоненты: collector собирает данные, orchestrator управляет выполнением, analyzer занимается анализом, а tool layer определяет, через какие действия агент может получать новую информацию.
Сам агент должен решить, что именно ему сейчас нужно запросить, а не получать весь репозиторий одним огромным промптом.
Параллельно разбираемся с context engineering, structured outputs, валидацией и repair loop.
То есть учимся делать так, чтобы на выходе была не «примерно разумная генерация», а данные в форме, на которую может опираться остальная система.
3️⃣Построим слой хранения
Данные из репозитория нужно не только скачать, но и нормально сохранить.
В архитектуре проекта используются PostgreSQL, NATS JetStream, embeddings и Qdrant для long-term memory.
Разбираемся, что хранить как структурированные данные, что нужно агенту в состоянии текущей задачи, а что имеет смысл положить в долгосрочную память и доставать по необходимости.
Это уже тот кусок, который напрямую переносится на рабочие проекты: агент почти никогда не существует отдельно от БД, API, очередей и существующей инфраструктуры.
4️⃣Добавим память и state
Чтобы агент мог работать с длинной задачей, недостаточно просто передавать историю сообщений.
Он должен понимать:
〰️что уже сделал
〰️на каком шаге находится
〰️какие результаты получил
〰️что ещё осталось
〰️что произойдёт после рестарта
Поэтому добавляем memory, state machine, persistence и idempotency keys.
После этого агент уже не должен забывать предыдущие действия или повторно выполнять одну и ту же операцию после retry.
5️⃣Научим систему нормально ошибаться
В демо можно перезапустить скрипт и сказать «ну, LLM опять чудит».
В рабочей системе так не получится.
Поэтому дальше появляются retry/backoff/fallback, guardrails, ограничения на инструменты, бюджеты, circuit breaker и stop conditions.
Если агент зациклился, потерял уверенность, слишком долго выполняет задачу или собирается сделать потенциально опасное действие - система должна уметь его остановить.