Агенты: создание, настройка, оркестрация

Создание, настройка и оркестрация агентов

Вопросы участников:

Оркестрация агентов
как разработать ИИ-агенты
создание агентов, орестрация
Создание, настройка, запуск и организация агентов

Начнём с определения, потому что от него зависит всё остальное. Рабочая формулировка, которую даёт Anthropic: агент — это LLM, которая в цикле сама вызывает инструменты и наблюдает результат, пока не решит задачу. Отсюда выстраивается лестница сложности, и подниматься по ней нужно только тогда, когда проще не получается.

Базовые архитектурные паттерны, на которых стоит почти всё:

Дополненная LLM — модель плюс инструменты, память и поиск. Это атомарный кирпич любого агента.
ReAct — чередование рассуждения и действия в одном цикле: модель думает, делает шаг инструментом, читает наблюдение, корректирует план. Паттерн описан в работе ReAct: Synergizing Reasoning and Acting.
Plan-and-Solve — сначала явный план из подзадач, потом выполнение по плану. Снижает пропуск шагов относительно наивного chain-of-thought, см. Plan-and-Solve Prompting (arXiv).
Оркестратор-воркеры — центральная LLM динамически дробит задачу, раздаёт подзадачи воркерам и собирает их результаты. Это основной паттерн оркестрации для задач, где число и характер подзадач заранее не известны.

Ключевая развилка при проектировании — рабочий процесс или агент. Рабочий процесс — это заранее прописанный вами маршрут из вызовов модели и кода. Агент — это когда модель сама ведёт свой цикл и решает, что делать дальше. Правило простое: предсказуемый маршрут дешевле и надёжнее сделать рабочим процессом, а автономный цикл включать там, где шаги нельзя предугадать.

Чем это собирают на практике:

Claude Code subagents — субагент описывается markdown-файлом с YAML-фронтматтером: name, description, набор tools, model, permissionMode, предзагруженные skills, memory. Тело файла становится системным промптом. Это самый быстрый способ получить настроенного специалиста без кода, см. Create custom subagents.
LangGraph — низкоуровневый движок оркестрации: агент моделируется как граф из узлов и рёбер поверх общего состояния, с контрольными точками и супершагами. Берут, когда нужен явный контроль потока и восстановление.
CrewAI — команды ролевых агентов (последовательный или иерархический процесс с агентом-менеджером) плюс событийные Flows для управления состоянием.
AutoGen от Microsoft — разговорные агенты и runtime, который управляет их жизненным циклом и сообщениями.
MCP — открытый стандарт подключения инструментов и данных к модели, чтобы не писать интеграцию под каждый источник заново.

Что пойдёт не так и как избежать. Первое — переусложнение: оркестрацию тащат туда, где хватило бы одного вызова. Второе — расплывчатая постановка подзадач: без чёткой цели, формата вывода и границ воркеры дублируют работу или оставляют пробелы. Третье — плохие описания инструментов уводят агента не туда; в разборе Anthropic отдельный агент-тестировщик переписал описание сбоящего инструмента, и это сократило время выполнения задач на 40%. Лечится это не новым фреймворком, а дисциплиной: начинать с простого, давать каждому агенту узкую роль и хорошие описания инструментов, наращивать сложность только под доказанную потребность.

Ссылки

Один агент или рой: зачем дробить на 10–20 и как не потерять контроль

Вопросы участников:

пока не понимаю для чего в проекте разделять задачи на 10-20 агентов и не потерять при этом контроль за тем, что происходит.

Это правильное подозрение, и ответ у него две стороны. Сначала зачем вообще дробить. Причина не в моде, а в физике контекста: окно модели конечно, а внимание на длинном окне размывается. Несколько субагентов дают параллельные раздельные контексты — каждый копает свой кусок в своём окне и возвращает наверх сжатую выжимку. По данным Anthropic, на широких исследовательских задачах, где нужно тянуть много независимых направлений сразу, мультиагентная связка (ведущий на более сильной модели, воркеры на модели попроще) обошла одиночного агента на той же топ-модели на 90,2% по их внутреннему замеру. Плата за это большая: агенты тратят примерно вчетверо больше токенов, чем чат, а мультиагентные системы — примерно в 15 раз больше. Поэтому рой оправдан только на дорогих задачах с реальной параллельностью, а не как самоцель.

Теперь про контроль, и здесь важен трезвый контрапункт. Cognition в разборе Don't Build Multi-Agents показывает, где рой разваливается: когда несколько агентов параллельно пишут, каждое действие несёт неявные решения (стиль, обработка краевых случаев, паттерны кода), и эти решения конфликтуют. Итог — хрупкая система, где никто не видит полной картины. Их вывод в продолжении Multi-Agents: What's Actually Working уже тоньше: рой работает, когда запись держится однопоточной, а дополнительные агенты добавляют не действия, а интеллект — читают, ищут, ревьюят. Например, агент-ревьюер с чистым контекстом ловит то, что автор кода уже не видит.

Как не потерять контроль на практике:

Единый источник плана. Оркестратор держит план и todo-список, субагенты работают от него, а не каждый от своей картины мира.
Чёткий контракт на субагента. Цель, формат вывода, границы задачи и подсказка по инструментам — иначе будет дублирование и пробелы.
Масштаб под сложность. Anthropic зашивает это в промпт: простой поиск факта — 1 агент и 3–10 вызовов; прямое сравнение — 2–4 субагента по 10–15 вызовов; сложное исследование — больше 10 субагентов с явным разделением ролей. Ранние версии спавнили по 50 субагентов на простой запрос — это и есть потеря контроля.
Наблюдаемость и однопоточная запись. Трассировка каждого агента плюс правило, что финальные изменения вносит один писатель, а остальные только советуют.

Что пойдёт не так без этого: рой параллельных писателей без общего контекста даёт конфликтующие правки, дубли и систему, которую невозможно отладить. Держите запись однопоточной, а параллельность — на чтении и разведке.

Ссылки

Глобальные и проектные скиллы, узконаправленный агент под разные проекты

Вопросы участников:

Рассказать разницу между глобальными скиллами агента и скиллами внутри проекта. Рассказать как сделать узконапралвенного агента под разные проекты. Например агент solution-architector

Разберём отдельно механику скиллов и отдельно — как из них собрать переносимого узкого специалиста.

Что такое скилл. Это папка с файлом SKILL.md и опциональными ресурсами (скрипты, справочники). Работает по принципу progressive disclosure в три уровня: в контекст всегда загружены только метаданные (имя и описание, порядка 50 токенов); полное тело SKILL.md подгружается, когда скилл сработал; файлы из references/ — только по необходимости. Так агенту можно дать сотни скиллов, не раздувая окно. Подробности — в разборе Equipping agents with Agent Skills и в спецификации Agent Skills.

Глобальный или проектный — это про область видимости. Разница не в содержимом, а в том, где лежит файл и кому он доступен. В Claude Code это прямо задаётся расположением:

.claude/agents/ и .claude/skills/ в репозитории — проектная область: доступно всем на этом проекте, версионируется вместе с кодом.
~/.claude/agents/ и ~/.claude/skills/ — глобальная (пользовательская) область: доступно во всех ваших проектах.
Плагины и managed settings — командный и организационный уровни.

Приоритет разрешения — от организационного к плагинам, так что проектная версия перебивает глобальную. Практический смысл: общий метод (например, как вы делаете архитектурное ревью) держите глобально, а специфику конкретного репозитория — в проектных файлах.

Как собрать агента solution-architect под разные проекты. Соберите его один раз как переносимого специалиста и положите на глобальный уровень:

Системный промпт (тело файла субагента) — роль, рамки, критерии качества архитектурного решения.
Ограничение инструментов через tools — например, только чтение и поиск, без права писать в код.
Предзагруженные skills — ваши методички по ADR, trade-off-анализу, оценке нефункциональных требований.
Модель и memory — сильная модель для рассуждений плюс память для накопления решений между сессиями.
Точное description — именно оно решает, когда агент подхватится, поэтому пишите триггеры конкретно.

Что пойдёт не так. Главная ловушка — описание: слишком широкое description заставит агента срабатывать невпопад, слишком узкое — он не подхватится там, где нужен. Вторая — глобальный скилл, который лезет в каждый проект и мешает; если он нужен не везде, держите его проектным. Полная таблица областей и полей — в Create custom subagents.

Ссылки

Стоит ли писать свои loops или лучше использовать встроенные /goal и /loop в агентах?

Сначала про механику, потому что тут легко перемудрить. Агентный цикл — это и есть сердце любого агента: модель вызывает инструмент, читает результат, решает следующий шаг, повторяет до условия выхода. Это классический ReAct. Встроенные примитивы вроде команд-циклов в вашем харнессе (в разных инструментах это оформлено по-разному, например командой вида /loop) — это готовая обёртка над тем же циклом, чтобы не собирать его руками.

Развилка своё против встроенного сводится к той же паре понятий из Building Effective AI Agents: рабочий процесс против агента.

Берите встроенный цикл, когда задача открытая и маршрут заранее не известен: пусть модель сама ведёт итерации. Писать свой цикл ради самого цикла — лишняя работа и лишние баги.
Пишите свой цикл, когда нужен жёсткий контроль: бюджет на попытки и токены, обязательная верификация на каждом шаге (тесты, линтер), контрольные точки и откат, детерминированная маршрутизация. Тут вы фактически строите рабочий процесс, а не полагаетесь на автономию.

Отдельный полезный слой — цикл саморефлексии. В работе Reflexion (arXiv) агент после неудачи формулирует словесный разбор ошибки, кладёт его в память и в следующей попытке действует лучше. Это надстройка над базовым циклом: не просто повторять, а повторять с выводами.

Что пойдёт не так. Самая частая беда встроенных циклов — отсутствие условия выхода и бюджета: агент крутится, компаундит раннюю ошибку и жжёт токены. Поэтому даже на встроенном цикле ставьте лимит шагов и токенов и точку отката. И наоборот, ручной цикл без нужды превращает гибкую задачу в хрупкий скрипт, который ломается на первом непредусмотренном случае. Практический ответ: по умолчанию встроенный цикл, а свой — только вокруг тех участков, где вам реально нужны бюджеты и проверки.

Ссылки

Сквозной автономный SDLC-пайплайн на большой легаси-базе

Вопросы участников:

Клод как бы умный. Но хотелось бы построить энд ту энд автономный SDLC пайплайн для разработчиков, которые можно было бы внедрить в мою команду. Хотелось бы понять современные классные приемы оптимизации контекста, обучения агентов работе с большой существующей кодовой базой и легаси кодом, уменьшения вероятности ошибок и галлюцинаций

Разложу вопрос на три части: контекст, работа с легаси и снижение ошибок, а в конце — как это собрать в пайплайн.

Оптимизация контекста. Ключевая идея из разбора Effective context engineering (Anthropic): у модели конечный бюджет внимания, и цель — не набить окно, а найти наименьший набор высокосигнальных токенов. Рабочие приёмы под длинные задачи:

Компакция — при подходе к пределу окна свернуть историю в сжатое резюме и продолжить с него.
Структурные заметки — агент ведёт внешний файл вроде NOTES.md и todo-список, куда выносит цель и решения, чтобы не терять их между десятками вызовов.
Субагенты — тяжёлую разведку отдать отдельным контекстам, которые возвращают наверх выжимку на 1000–2000 токенов вместо всего сырья.

Работа с большой и легаси-базой. Здесь принципиальный приём — не грузить репозиторий целиком, а дать агенту навигацию и поиск точно в срок: пусть ищет через grep и glob, читает файлы по путям по мере надобности, а общий контекст проекта берёт из файла-карты (в Claude Code это CLAUDE.md). Так вы обходите и устаревшие индексы, и раздувание окна. То есть агента не столько обучают базе, сколько дают инструменты, чтобы он разбирался в ней инкрементально.

Снижение ошибок и галлюцинаций. Опора — не на рассуждение модели, а на исполнение: тесты, линтер, типы, сборка в CI как обязательные ворота. Диффы держите маленькими и добавляйте агента-ревьюера с чистым контекстом: по данным Cognition, такой ревьюер находит в среднем около 2 багов на PR, из которых порядка 58% серьёзные (логические ошибки, пропущенные краевые случаи, уязвимости), см. Multi-Agents: What's Actually Working.

Как это собрать в пайплайн. Стадии SDLC — планирование, кодирование, ревью, тестирование, мониторинг — оформляются как оркестратор-воркеры с однопоточной записью и интеллектом вокруг. Инструменты и данные подключаются через MCP. Реалистичная планка автономии: даже сильные скаффолды на SWE-bench Verified решают лишь часть реальных задач (минимальный агент в сотню строк — около 65% на отобранном как решаемый наборе). Поэтому сквозной пайплайн строят с человеческими воротами на ключевых стыках, а не как полностью необслуживаемый конвейер.

Что пойдёт не так: ожидание полной автономии end-to-end, попытка засунуть весь репозиторий в окно и доверие вердиктам без прогона. Лечится это тремя вещами — контекст точно в срок, исполнение как источник истины и человек на ответственных переходах.

Ссылки

Реально ли создать агента под любую задачу и какого выбрать

Вопросы участников:

Реально ли создать агента под любую задачу?
какого агента выбрать

Короткий честный ответ: технически агента можно приставить почти к любой задаче, но это не значит, что стоит. Полезнее думать не могу ли, а нужен ли здесь агент и какого типа.

Когда агент оправдан. Из Building Effective AI Agents: агент имеет смысл на открытых задачах, где шаги нельзя предугадать, а результат можно проверить и откатить. Если задача узкая и предсказуемая — дешевле и надёжнее один вызов модели или простой рабочий процесс, без всякой автономии.

Насколько реально под любую задачу. Трезвая планка — SWE-bench Verified: это 500 задач из реальных GitHub-issue, отобранных людьми как заведомо решаемые. Даже на этом облегчённом наборе лучшие системы закрывают лишь часть, а минимальный агент-цикл — порядка 65%. Вывод: агенты уже реально полезны, но полная автономия под произвольную задачу пока недостижима — нужна проверяемость и человек в контуре.

Какого агента выбрать — по форме задачи:

Предсказуемый маршрут → рабочий процесс из вызовов и кода, без агентной автономии.
Нужны инструменты и итерации → один агент в цикле ReAct. Это дефолт, начинать стоит отсюда.
Широкая параллельная задача с высокой ценностью → оркестратор-воркеры. Но помните про цену: мультиагент тратит примерно в 15 раз больше токенов, чем чат, по данным Anthropic.
Модель под роль → сильная на оркестраторе и рассуждении, подешевле и побыстрее на воркерах.

Дополнительный критерий выбора — есть ли дешёвая проверка результата. Там, где есть тесты, компилятор или схема, агенту можно дать больше свободы. Там, где проверка дорогая или субъективная, автономию урезают и добавляют человека.

Что пойдёт не так: тянуться к агенту там, где хватило бы скрипта (лишние стоимость, задержка и непредсказуемость), или строить мультиагента, где справился бы один. Выбор агента — это в первую очередь выбор минимально достаточной сложности под конкретную задачу.