Comments 27
Проблема субагентов через cli в том, что теряется UI курсора для ревью изменений.
CLI просто меняет файлы, оно никак не отражается непосредственно в IDE и это неудобно.
Частично этот вопрос решается через git.
Именно, но тут Cursor ведет себя аналогично другим CLI-агентам. Можно либо проверять все изменения через git в конце, либо просить после завершения каждой задачи делать коммит, чтобы видеть этапность изменений и иметь возможность откатиться на несколько шагов назад.
Я предпочитаю первый вариант: ревьюить сразу финальный код.
Курсором не пользуюсь, но при использовании Claude Code в терминале обычного vscode есть официальная интеграция, которая позволяет как раз все изменения ревьюить в ide.
Спасибо за статью, очень помогли. Я пользовался похожим методом, но в ручном режиме - создавая отдельных агентов для отдельных задач кратких, создаю им локальные .md, почти никогда не загружаю весь контекст. Но ваш процесс автоматизирует эту суету)
Чего-то я не понимаю, наверно
Открываешь окошко в режиме "Агент", добавляешь нужные Cursor Rules (у меня их пара десятков на проект) и Commands (ваши "субагенты"?) - и вперед с чистым контекстом
Закончил работу - закрыл.
Что за "главный агент"?
Ваш промпт:
аналитик, архитектор, планировщик — opus-4.5
ревьюеры ТЗ, архитектуры, плана, кода и разработчик — composer-1
Cursor никак не может понять и разнести по разным LLM. Покажите доказательства скриншотами.
Тоже смотрю в сторону автоматизации переключения контекстов с помощью Cursor Rules
А в чем может возникнуть проблема у Cursor на этой задаче? В целом здесь только краткий промпт приведен, если смотреть полный файл с инструкциями оркестратора в репозитории - сомнения должны отпасть.
Добавил скриншот, где видно, как Cursor запускает субагента. Видно, что от вызывает CLI утилиту cursor-agent с передачей содержимого файла с промптом с ссылкой на файл с задачей.
В приведённом в статье шаблоне промпта есть ссылки на файлы с описанием общей схемы работы оркестратора и промптами для отдельных ролей. Пример файлов есть на github. Каталог с этими файлами нужно расположить либо в самом проекте (это имеет смысл, если там есть специфичные для данного проекта инструкции), либо где-то рядом, но в доступном для Cursor месте. И в промте указать актуальное расположение файла с инструкциями для оркестратора и файлов с промптами.
Тогда всё заработает.
Про каркас аля как было принято в Паскале +1. Я с курсором попробовал в процелурное программирование сверху вниз с вкраплениями функционально. Получается отлично. Про автозапуск субагентов звучит прекрасно. Попробую. Сейчас запускаю руками.
Рекомендую попробовать KiloCode с тем же клодом. Режим оркестрации там есть и в него можно воткнуть любую нужную модель. Большой бонус - работает в idea based IDE, если не нравится vs code.
Все эти мульти агенты очень интересны. Но даже один в режиме эдитор иногда делает чушь, приходится каждый шаг немного корректировать. Не могу представить как можно модель оставить на несколько часов работы. Даже один чат за 5-10 мин может отработать 2-3 промта и каждые надо бежать проверять. Наверно от проекта зависит
Если изменение не тривиальное, то чтобы агент-разработчик мог сделать что-то правильно, как раз и требуется предварительная цепочка анализа и декомпозиции задачи.
Также важно помочь агентам разобраться в том, что уже есть в проекте. Я не стал делать на это фокус в статье, но в промте, возможно, обратили внимание на путь к файлу с описанием проекта. Это важно, т.к. для более-менее большого проекта никакого контекста не хватит переварить весь код - нужна выжимка, чтобы аналитик и архитектор знали, куда смотреть в первую очередь.
Вероятность получить приемлемый результат также повышается за счёт этапов ревью. Да, на ревью требуются дополнительные токены, но практически всегда ревьюеры находят замечания, по которым выполняются исправления.
И конечно самое важное для получения хорошего результата - это обратная связь, т.е. результаты тестов. Можно рассматривать процесс решения задачи как своеобразный RL (reinforcement learning*): делаем → получаем обратную связь → дорабатываем. Чем тесты будут более приближенными к реальным сценариям использования системы, тем качественнее будет результат. Модели часто любят тривиальные юнит-тесты типа проверки наличия полей в классе. А вот более вдумчивые тесты они ленятся делать. В своих промтах я делаю акцент именно на как можно более реалистичные тесты, чтобы они действительно показывали, насколько доработки соответствуют требованиям. Плюс обязательные регрессионные тесты.
Конечно, результат невозможно гарантировать, бывают неудачные решения, которые приходится откатывать или рефакторить. Но всё равно стабильность разработки по описанной схеме намного выше, чем без каких-либо специальных приёмов.
Я ему говорю "сначала разработай автотесты, перепроверь их логику, потом напиши код, протестируй результаты..."
Не хватает хорошего README на github.
Согласен.
Сейчас в качестве описания общей схемы можно использовать файл https://github.com/rdudov/agents/blob/master/00_agent_development.md.
Дополню:
Claude code не особенно привязана к моделям антропиков - туда легко встраиваются другие модели.
Нативно - киты (минимакс м2, зайка glm, deepseek), через Claude-code-router любые OpenAI-совместимые, а через cliproxyapi модно встроить даже другие cli агенты по подпискам (как просто модели, не субагенты).
и все функции СС сохраняются даже с другими моделями!
СС довольно удобная упряжка.
Делаете костыли, когда уже есть готовые решения по типу Roo Code и Kilo Code который тут уже упоминали, причём в них можно добавить конфигурацию MCP серверов, которые как раз и решают проблемы summary.
Добавьте пожалуйста лицензию в репозиторий.
Спасибо за статью и за репозиторий с промптами, особенно 00_agent_development.md и линейку ролей оркестратор → аналитик → ревьюеры → девелопер. Очень аккуратная схема.
Вопрос по эксплуатации такой мультиагентной системы на длинной дистанции.
Как она живёт, когда проект не “игрушечный на вечер”, а тянется месяц и больше в одном репо: ТЗ плавает, архитектура дорабатывается, накапливается серия задач и правок?
Не превращается ли в таком режиме оркестратор по факту в “мега-агента”, которому всё равно приходится руками выравнивать состояние: помнить актуальную архитектуру, прошлые решения, контекст задач и т.п.?
Или вам хватает текущего набора файлов (00_agent_development.md + промпты ролей, git-история, notes), и дополнительной “памяти проекта” (отдельных state-файлов / базы задач) пока не требуется?
Очень интересно, где, по вашему опыту, проходит естественная граница этой схемы:
до какого масштаба/длительности проекта она остаётся комфортной “из коробки”, а в какой момент приходится городить более тяжёлый контур — отдельный storage состояния, таск-трекер для агентов, память оркестратора и т.д.?
Я сделал эту схему для серьёзных доработок существующего проекта. Для проектов "на вечер" я бы не стал её использовать - это overkill, очень накладно по токенам. Также небольшие доработки, где нет зависимостей из разных модулей, я запускаю обычным способом одним промптом по той же причине.
На практике я всегда самостоятельно проверяю написанные агентами ТЗ и архитектуру. Это позволяет не уйти в разработку не по тому пути.
Также есть важные нюансы, которые учтены в промптах, но я не стал делать акцент на них в статье:
"Память проекта", которую вы упомянули, критически важна для того, чтобы агенты могли вносить адекватные изменения в большие проекты. Когда кода много, он не помещается в контекст, и агенты просто не в состоянии увидеть все зависимости. Поэтому в каждом каталоге очень желательно иметь файл .AGENTS.md, в котором содержится описание структуры каталога и назначение файлов, классов и методов. Также важно иметь актуальный README.md, а ещё лучше заточенный под агентов .AGENTS.md для всего проекта, по которому агенты смогут быстро понять, про что проект и как он устроен. Но стоит упомянть, что агенты не всегда строго следуют правилам ведения .AGENTS.md.
Оркестратор не становится мега-агентом, но всё равно достаточно быстро набирает контекст. Мой вариант промпта рабочий, но не идеальный. Тут ещё есть простор для оптимизации, чтобы оркестратор не читал лишние документы.
На примере моего проекта, который очень часто дорабатывается, ТЗ очень быстро теряют актуальность. Лучше не запускать параллельные доработки, касающиеся одного и того же кода. В отличие от человека, который может сопоставить имеющийся документ и новые изменения в коде, для агентов это достаточно ресурсоёмкая задача, и они скорее всего что-то упустят. Если такая ситуация возникает, то лучше перезапустить весь процесс заново, с этапа проектирования. Поэтому я стараюсь все доработки доводить до конца как можно быстрее.
Вообще, всю эту историю я затеял с целью иметь возможность стартовать разработку через мессенджер, даже не заходя в Cursor. И через него же проводить ревью ТЗ, архитектуры и т.п. Скажем так: это схема рабочая, доработки будут сделаны и функционал будет работать. Но рано или поздно технический долг накопится, и надо будет проводить рефакторинг с ручным вмешательством. Всё-таки агенты пока не настолько умные, чтобы полностью избежать дублирования кода и создания разных сущностей, которые делают похожие вещи.
Спасибо за статью! Хорошая работа!
В целом, для меня субъективно есть только один минус - слишком долго работают агенты. Если делать всё напрямую через чат Cursor, то скорость работы выше в 2-3 раза. Не знаю, с чем это связано...
Мультиагентная разработка в Cursor: как заставить субагентов работать на большие проекты