Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 33
Закреплённые комментарии
Второй день не могу подключиться к серверам Cursor из России напрямую. Статус-страница Cursor показывает что у них всё в порядке — значит проблема на нашей стороне. Если кто-то из России может проверить подключение — напишите, интересно понять масштаб. Прошу сразу писать в каком вы городе тестируете подключение.
Ирония в том, что статья писалась именно про этот риск.
Вам надо сделать бесплатную пробную версию для всех желающих :-)
типа Shareware или Freemium
Помню в молодости подрабатывал в конторе, которая делала двери. И был там один из учредителей, который делал универсальный станок, который должен был получить на входе полотно, а на выходе готовую дверь.
Я там проработал не долго, но как говорили, через пару лет, ничего путного не получилось.
Я это к тому, что универсальный инструмент создает эффект "вау" по началу, но когда капнешь глубже, то всплывает куча проблем.
В любом случае удачи вам в вашем начинании.
Спасибо за пожелание! Но тут важное отличие. Универсальный станок — это одна железка, которая пытается и пилить, и сверлить, и красить. Конечно не получится.
А мой агент — это не станок. Это скорее универсальный работник, у которого в мастерской лежат конкретные, специализированные инструменты: npm для кода, Playwright для браузера, Docker для изоляции. Он не пытается одним сверлом делать всё — он берёт нужный инструмент под конкретную задачу. А если инструмента нет — сам идёт и скачивает.
Разница между плохим универсальным станком и хорошим мастером — в том, что мастер знает когда какой инструмент достать.
А где ссылка то?) где смотреть эту магию?
Раз просите — vibepilot.ru :) В статье специально не давал ссылку, чтобы не превращать технический рассказ в рекламу.
Это Вы не Cursor сделали, а Lovable или Replit :)
Похоже на Lovable/Replit снаружи — согласен! Но внутри принципиально отличается. У Lovable нет Docker-изоляции — код выполняется в их песочнице с ограничениями. У Replit нет мультиагентной архитектуры и браузерных "рук". И главное — оба недоступны в России без VPN и не принимают рубли. А так да, задача похожая — дать неразработчикам возможность создавать приложения :)
Просто слил все токены
Второй день не могу подключиться к серверам Cursor из России напрямую. Статус-страница Cursor показывает что у них всё в порядке — значит проблема на нашей стороне. Если кто-то из России может проверить подключение — напишите, интересно понять масштаб. Прошу сразу писать в каком вы городе тестируете подключение.
Ирония в том, что статья писалась именно про этот риск.
Мой опыта работы с вашим инструментом:
1) Скопировал промт из одного из моих недавних проектов:
hottyburger.com
Hotty Burger Malta is a restaurant located opposite Gzira harbor, offering uniquely irresistible, hot, loaded, and mess-free UFO burgers. They also serve breakfast and coffee daily, providing both a relaxed dine-in experience with a sea view and delivery through Bolt Food and Wolt. Their menu features classic and innovative compact burgers with homemade sauces for all burger lovers.read less
Tagline
Simply, juicy, glorious signature Hotty UFO burgers.
Design Language
Colors
Primary - #E03C31
Secondary - #FFF7F0
Supportive - #8F2424, #222222, #FFC837
Fonts
Aa Bb Cc
Bebas Neue
Aa Bb Cc
Roboto
Tone
Appetizing
Playful
Vibrant
Casual
Bold
Aesthetic
This brand's aesthetic blends a vibrant, appetizing warmth with modern casualness. It pairs a playful script font for headlines with a clean sans-serif for body text, set against a palette of hot red, deep maroon, and cream. The visual language is distinctive for its food-centric layouts and inviting photography, evoking a contemporary diner feel.read less
Attached is a logo and the textured background picture that can be used as a background for selected sections / pages.
The website requires the following pages: Home page (contains all the core information about the business and other pages), About page (Labeled "Our Passion"), Menu page, Gallery page, Contact page Агент в первой сесси смог лишь создать список задач потратив с десяток минут. Несколько раз уменьшал свой контекст, потом закончил, добавив минимальную информацию в память пректа
2) Второму агенту было указано закончить имеющиеся задачи. Он написал основной код сайта, добавил несколько новых задач, потом зашел в круг выполнения каких-то комманд и уменьшения контекста. Было показано предупреждение о 30 циклах, я агента остановил. Агент не смог обновить память проекта и записать структуру проекта или принятые решения
3) Третьему агенту было указано прочитать имеющиеся файлы, обновить прогресс по задачам, и обновить память проекта. Пока агент читал файлы у него закончился контекст и он его опять уменьшил. Задачи он пометил как выполненные, память проекта он не обновил
4) Я попытался запустить превью. Сайт не работал, подсказка скалаза залезай в консоль и запускай сам. Я залез в консоль, прогнал npm i а потом npm run dev. Сайт заработал.
К сожалению качество сайта и скорость агента оставляют желать лучшего. К примеру, я пробовал создать сайт использую промт выше с помощью бесплатной версии base44. Прилагаю фотки обоих резултатов. Base44 справился быстре и лучше с минимальной помощью. После поставленной задачи я лишь попросил увеличить лого и поменять фон в шапке.
Меня больше всего напрягает как часто у вашего агента заканчивается контекст. Я работал с разными AI системи и почти всегда лучший результат получался тогда, когда система не давала агенту привысить контекст за 1 задачу. Большистно инструментов сейчас используют архитектуру sub agents, где главный агент создает новых агентво для задач и не забивает себе контекс пытаясь выполнить все в одиночку. При использовании в курсоре opus 4.6 это происходит постоянно и не только для имплементации фич, но и для просто анализа существующих файлов.
Мне очень понравился ваш UI, у вас много хороших идей, но проект все еще сильно отстает от существующих интсрументов
Спасибо за детальнейший разбор — это именно тот фидбек, который мне нужен.
По контексту — вы попали в баг, который я как раз вчера весь день фиксил. Агент зацикливался на compaction: сжимал контекст, потом снова раздувал, и так по кругу. Фикс уже в проде, но чуть позже будет ещё один фикс.
По архитектуре — у нас уже реализована мультиагентная система: Orchestrator координирует Designer → Planner → Coder → Reviewer → Tester, каждый со своим контекстом. Проблема, с которой вы столкнулись — это баг в модуле сжатия контекста внутри отдельного агента, а не архитектурное ограничение. На длинных промптах с подробной дизайн-системой (как ваш) сжатие зацикливалось. Фикс уже в работе.
Кстати, то что вы смогли продолжить работу во второй и третьей сессии — это фича параллельных чатов, которую я запустил буквально два дня назад. Каждый чат работает со своим контекстом, но с общей памятью проекта. Без неё ваш сценарий вообще не был бы возможен.
По превью — оно должно работать автоматически(есть отдельная вкладка), сервер поднимается в Docker-контейнере. Возможно, не дождались загрузки — иногда npm install занимает время, особенно на проекте с множеством зависимостей. Если что-то пошло не так, в интерфейсе есть возможность перезапустить или отправить ошибку в чат агенту — он починит сам. Напишите мне в личку, разберём ваш конкретный случай.
По сравнению с base44 — честно, их результат выглядит лучше, и главная причина — фотографии. Сгенерированные изображения бургеров и интерьера делают 80% впечатления. Это направление, над которым я сейчас думаю.
Проект молодой и действительно отстаёт от зрелых инструментов. Но неделю назад этого бага с контекстом ещё не существовало — он появился вместе с новой фичей. Двигаемся быстро. Попробуйте ещё раз через неделю — будет заметно лучше.
В любом случае еще раз огромное спасибо за обратную связь.
Да, хочу добавить что сейчас жизненный цикл агента в workspace привязан к websocket соединению. Фича над которой мы сейчас работает - это полностью автономный агент. Это будет выглядеть примерно так: написал задачу, и закрыл браузер, агент будет работать пока задача не будет завершена. Это другой уровень работы и этот подход позволит решить текущие проблемы с контекстом.
От мультиагентной системы:
Orchestrator, Designer → Planner → Coder → Reviewer → Tester.
Лучше отказаться, так как крупные игроки всей этой шаболды уже протестировали все возможные варианты.
И в итоге пришли к выводу, что эффективнее оставить только Планировщик и Выполнение.
И вот почему..
https://chat.deepseek.com/share/jo152mzk6080ei7y06
Спасибо за мнение! Но у меня вопрос: кто именно эти "крупные игроки" которые "протестировали все варианты"? Можно конкретные примеры?
Потому что из того что я вижу — Anthropic только что выпустили Claude с multi-agent orchestration. OpenAI в Codex используют несколько специализированных агентов. Cursor под капотом разделяет планирование и выполнение и ревью. Devin — целая команда агентов.
У нас архитектура гибкая: для простых задач IntentDetector направляет запрос напрямую в Coder, минуя всю цепочку. Для сложных — включается полный пайплайн. Не каждый запрос проходит через все 6 агентов — это было бы расточительно.
А ссылка на чат с DeepSeek как аргумент — это примерно как ссылаться на Wikipedia в научной статье. Интересно почитать, но не источник истины :)
В агенте Клауда, хотя там выбор из 5 по сути это только два про планирование и выполнение
Кажется мы друг друга не понимаем)
Агент Claude с multi-agent orchestration - конкретно для пользователя состоит из двух кнопок планирования и выполнения. Поставьте программы или в виде расширений, там всё и увидите.
Под капотом это всё также выполняется многоагентно, но несколько иначе, чем прежде. Убрав лишнее и привнесли оптимизацию, дабы не тратились лишние токены на симуляцию работы.
Советую прогу zed.dev там можно поставить все возможных агентов: агент Claude встроен из коробки, остальных можно поставить
> А ссылка на чат с DeepSeek как аргумент — это примерно как ссылаться на Wikipedia в научной статье. Интересно почитать, но не источник истины :)
может стоило пройтись по ссылке и посмотреть какие страницы дипсик узучил для ответа и внезапно рассмотреть там что он взял информацию с сайта клауда)
А какие страницы "изучил" Deepseek? Там только одна ссылка, эта https://github.com/RooCodeInc/Roo-Code/issues/264 Это баг связанный с Sonnet 3.5, который запостили в начале прошлого года? Где там ссылка на "сайт Клода"?
Кстати, вот рассуждения самого дипсик: "Смотрю на поисковый результат — это issue на GitHub о технической проблеме зависания. Информация нерелевантная, не содержит объяснений архитектурных решений. Значит, ответ придется строить на основе общих знаний о разработке AI-агентов." Вам понятно? Но эти знания отстают на год примерно, а Claude Code взлетел осенью прошлого года - Deepseek ничего про это не знает если не попросить его найти конкретную информацию.
Дальше поцитирую:
>Синтез функций: Современные LLM (вроде Claude 3.5 Sonnet, который часто используется в Cline/Roo Code) достаточно умны, чтобы в рамках одного контекста сначала спланировать архитектуру, а потом сразу приступить к написанию кода, попутно проверяя себя.
1. Какая же это "современная LLM"? Многие провайдеры уже убрали её. На сайте claude.ai модель недоступна - устарела.
2. Год назад я активно начал работать с Sonnet как раз 3.5(далее работал с каждой версией, до 4.5) - и скажу прямо, зависит от постановки задачи и промпта. Почему сделали разделение в мультиагентной архитектуре? А потому что каждая модель в один момент делала какую-то узкую функцию. И Sonnet, Opus грешат тем что могут уйти в другое русло, "забыть" запланировать - особенно если задача размытая. Да, запрос отдельный делается каждый раз - но здесь есть и плюс - контекст диалога не разрастается! Таким образом мультагентная архитектура даже с более слабыми моделями может показывать выдающиеся результаты.
Мы всё о разном вокруг да около)
Вот что говорит сам claude opus 4.6
источники
https://www.anthropic.com/engineering/multi-agent-research-system
https://docs.cline.bot/core-workflows/plan-and-act
https://cline.bot/blog/plan-smarter-code-faster-clines-plan-act-is-the-paradigm-for-agentic-coding
# Почему Claude Code и Cline отказались от мульти-агентной архитектуры
## Короткий ответ
Они **не то чтобы "отказались"** — они пришли к выводу, что для их задач **один сильный агент с разными режимами** работает лучше, чем оркестрация нескольких специализированных агентов.
---
## Ключевые причины
### 1. Проблема потери контекста при передаче между агентами
Когда Designer передаёт Planner'у, тот Coder'у, тот Reviewer'у — на каждом переходе **теряется информация**. Каждый агент видит только то, что ему передали, а не полную картину.
Из опыта Anthropic (их исследовательский блог, май 2025):
> «Мы обнаружили, что мультиагентные системы часто создают больше проблем координации, чем решают. Единый агент с расширенным контекстом и инструментами справляется лучше.»
Anthropic в своих рекомендациях по построению агентов прямо пишет: **начинайте с простейшей архитектуры и усложняйте только когда это доказуемо необходимо**.
---
### 2. Стоимость и латентность
```
Мульти-агентная система:
User → Planner (вызов LLM) → Coder (вызов LLM) → Reviewer (вызов LLM) → Tester (вызов LLM)
= 4+ вызова LLM на одну итерацию
Единый агент:
User → Agent (думает + планирует + кодит + проверяет в одном потоке)
= 1-2 вызова на одну итерацию
```
Каждый дополнительный вызов — это:
- **Деньги** (токены)
- **Время** (секунды ожидания)
- **Точки отказа** (агент может галлюцинировать, зависнуть)
---
### 3. Проблема "испорченного телефона"
Это самая критичная проблема. Реальный пример:
```
Пользователь: "Сделай форму авторизации с OAuth"
Planner: "1. Создать компонент формы 2. Добавить OAuth 3. Стилизовать"
Coder (получил план, но не полный контекст):
→ Делает OAuth через устаревшую библиотеку
→ Потому что Planner не уточнил стек
Reviewer: "Библиотека устаревшая, переделать"
Coder: Переделывает, но ломает стили
Tester: "Стили сломаны"
→ Цикл повторяется
```
Единый агент **сам помнит**, почему он выбрал конкретную библиотеку, и не создаёт такие петли.
---
### 4. Результаты исследований Anthropic ("Building effective agents", май 2025)
Anthropic опубликовали свои рекомендации по архитектуре агентов. Ключевые тезисы:
**Workflows vs Agents** — они разделяют:
- **Workflows** — предопределённые пути с LLM на отдельных шагах
- **Agents** — LLM динамически решает, что делать дальше
И рекомендуют:
> «Используйте простейшее решение. Не стройте многоагентный фреймворк, когда достаточно одного цикла prompt → tool use → observe.»
Их рекомендуемый паттерн для coding-агентов:
```
while task_not_done:
think() # планирование
act() # написание кода
observe() # проверка результата
```
Это **один агент**, который сам переключается между ролями.
---
### 5. Опыт Cline
Cline (ранее Claude Dev) развивался итеративно. Из обсуждений в их GitHub и Discord:
- Ранние версии пробовали разделение на plan/execute
- Обнаружили, что **единый агент с tool use** (чтение файлов, запуск команд, запись файлов) работает стабильнее
- Agentный цикл: `read → think → edit → run → observe → repeat`
Причём Cline **сохраняет** элементы мульти-ролевого подхода, но **внутри одного агента**:
- Сначала думает (plan mode) — это ваш "Planner"
- Потом пишет код — это ваш "Coder"
- Потом запускает и проверяет — это ваш "Tester"
- Если что-то не так — сам исправляет — это ваш "Reviewer"
---
### 6. Claude Code (Anthropic) — архитектура
Claude Code использует **один агент в agentic loop**:
```
┌─────────────────────────────┐
│ Claude Code │
│ │
│ ┌──────┐ │
│ │ PLAN │ ← think mode │
│ └──┬───┘ │
│ ▼ │
│ ┌──────┐ │
│ │ CODE │ ← tool use │
│ └──┬───┘ │
│ ▼ │
│ ┌──────┐ │
│ │ TEST │ ← bash tool │
│ └──┬───┘ │
│ ▼ │
│ ┌────────┐ │
│ │OBSERVE │ ← читает вывод │
│ └──┬─────┘ │
│ ▼ │
│ Готово? ──нет──→ наверх │
│ │ │
│ да │
│ ▼ │
│ Результат │
└─────────────────────────────┘
```
По сути все ваши пять ролей **существуют**, но как **фазы одного агента**, а не как отдельные сущности.
---
## Когда мульти-агентная архитектура ВСЁ-ТАКИ оправдана
Anthropic признают, что мульти-агенты нужны в конкретных случаях:
| Случай | Почему |
|--------|--------|
| **Разные модели для разных задач** | Дешёвая модель для рутины, дорогая для сложного |
| **Параллельные независимые задачи** | Фронтенд и бэкенд одновременно |
| **Разные инструменты/доступы** | Один агент имеет доступ к продакшену, другой нет |
| **Очень длинные задачи** | Контекст одного агента не вмещает всё |
Именно поэтому **Claude Code** всё же поддерживает **субагенты** (подчинённые агенты для подзадач) — но это не то же самое, что жёсткая конвейерная цепочка Designer→Planner→Coder→Reviewer→Tester.
---
## Главный вывод
```
Мульти-агент (цепочка): Плохо для coding — слишком много координации
Мульти-агент (параллельно): Хорошо для масштаба — независимые подзадачи
Один агент с фазами: Оптимально для coding — полный контекст, гибкость
```
Философия Claude Code и Cline:
> **Не разделяй на агентов то, что можно разделить на шаги одного агента.**
Разделение на роли (Planner, Coder, Reviewer) сохраняется **концептуально** — через системные промпты, through thinking, через tool use — но **физически** это один агент с полным контекстом задачи.
Спасибо за развёрнутый анализ! Но мне кажется, вы сами ответили на свой вопрос — в конце вашего же текста:
"Когда мульти-агентная архитектура оправдана:"
Разные модели для разных задач ✅ — у нас DeepSeek для рутины, Qwen-max для сложного, QVQ для vision
Параллельные независимые задачи ✅ — фронтенд и бэкенд одновременно, мы это поддерживаем
Очень длинные задачи ✅ — сайт на 5 страниц с дизайн-системой не влезает в один контекст
У нас работают оба подхода одновременно. IntentDetector анализирует запрос: простая задача ("добавь кнопку") → один агент в agentic loop, ровно как вы описали. Сложная задача ("создай сайт с бэкендом и базой") → оркестратор раздаёт подзадачи, каждая выполняется в своём контексте.
Это не "конвейер ради конвейера". Это роутинг: простое — просто, сложное — декомпозируется.
И ещё важный момент: Claude Code и Cline — инструменты для разработчиков, которые сидят в терминале и могут сами поправить если что-то пошло не так. Моя аудитория — люди, которые не знают что такое терминал. Для них агент должен сам спланировать, сам выполнить, сам проверить и сам починить. Без участия человека. Это принципиально другие требования к архитектуре.
Ерунда, полная и ненужная.
Я правильно понимаю, что тем, кто делал проект в Курсоре, лучше к вам не соваться, потому что вы убрали среду для программирования? То есть это решение исключительно для одноразовых проектов. А почему не сделать модульную структуру с добавлением ide, когда это необходимо? Пусть не на этапе установки, так хоть внутри самого приложения
Хороший вопрос! Но тут два заблуждения сразу:
1. "Убрали среду для программирования" — мы её не убирали, её никогда и не было в этом смысле. VibePilot — это не IDE и не замена Cursor. Это инструмент для людей, которым IDE не нужна. Маркетолог, владелец бизнеса, продакт — им нужен результат, а не среда разработки.
2. "Одноразовые проекты" — вовсе нет. Проект живёт в вашем workspace, к нему можно возвращаться, дорабатывать, просить агента что-то изменить. "Добавь на лендинг секцию с отзывами" — агент откроет существующий проект и допишет. Это не одноразовый генератор, это рабочее пространство с ИИ-сотрудником.
Но если вы именно разработчик из Cursor — да, вам к нам пока рано. Мы не конкурируем с IDE. Мы конкурируем с фрилансером на бирже, которому платят 80К за лендинг.
А идея с модульным подключением IDE — интересная, записал. В роадмапе есть интеграция с Git (уже работает) — вы можете сгенерировать проект у нас, push в GitHub, и дальше дорабатывать в любой IDE. Лучшее из двух миров.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как мы делали «Cursor для неразработчиков», а сделали полноценного ИИ-агента «с руками»