Управление агентами

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

Дата составления: 2026-07-22
Статус: 💡 Актуально

Проблема: почему один агент «плывет» на сложной задаче

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

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

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

Харнесс: обвязка, которая делает из модели агента

Харнесс (Harness, «обвязка») — это все, что окружает языковую модель и превращает ее в действующего агента: инструкции, инструменты и MCP-серверы, песочница с доступом к файлам, память, ограничители (guardrails), а также логика оркестрации, которая запускает субагентов и распределяет задачи между моделями.

Таким образом, агент = модель + харнесс

В гайде Google «The New SDLC With Vibe Coding» это описывают метафорой «модель — двигатель, а харнесс — сама машина, дорога и правила движения» и оценивают вклад как «10% модель, 90% харнесс» (оценка выведена из инженерии кодинга, но сам принцип — среда важнее модели — общий). Ключевое следствие: одна и та же модель в разном харнессе дает разный результат, поэтому «сменить модель» и «улучшить агента» — далеко не одно и то же.

Что на практике считают харнессом. Границу можно провести по способу запуска харнесса:

  • Терминальные и IDE-харнессы — работают в командной строке или среде разработки. Выросли из кодинга, но применимы и к документам: Claude Code CLI, Codex, Cursor, z.code (от z.ai), Qwen Code, Kimi Code.

  • Готовые агентные приложения — облачные или десктопные, работают без терминала, как обычная программа: Claude Cowork, ChatGPT Work (документы, таблицы, презентации, отчеты), Perplexity Computer.

  • Самохостинговые ассистенты — запускаются на своем сервере и живут в мессенджерах, файлах и браузере: OpenClaw и Hermes — активно развиваемый преемник OpenClaw.

Выбрать харнесс — значит выбрать среду, в которой вы будете оркестровать агентов; обзор некоторых из них и юридические кейсы — в статье Обзор инструментов.

Оркестрация и субагенты

Оркестрация — не отдельная технология, а тот самый слой харнесса, который отвечает за запуск и координацию субагентов.

Оркестратор (Orchestrator) — агент, который сам работу не делает, а раздает подзадачи другим агентам и собирает результат. Субагент (Sub-agent) — исполнитель, которого оркестратор запускает под конкретную задачу; у субагента свое отдельное контекстное окно, и после сдачи результата он «растворяется», освобождая контекст.

Ключевая механика: каждый субагент работает в чистом контексте и не мешает другим, а оркестратор тратит свое окно только на координацию — «запусти писателя», «запусти рецензентов», «собери оценки». Именно это снимает проблему ограничения контекстного окна и позволяет эффективно решать масштабные задачи.

Есть разные топологии связывания агентов между собой, представленные участниками сообщества Нейросети | ilovedocs на вебинаре «Армия агентов на службе у юриста: как это работает в Claude» (07.05.2026):

  • Субагенты — схема «звезда». Исполнители подчиняются одному оркестратору, отчитываются только ему и между собой не общаются; контексты изолированы. Дешевле и предсказуемее, годится, когда важен только результат каждого исполнителя.

  • Агентские команды (Agent Teams) — схема «граф». Агенты видят работу друг друга, обмениваются сообщениями и спорят до общего решения; есть общий список задач, а человек может вмешаться на любом шаге. Дороже по токенам, но сильнее там, где нужны обсуждение и взаимная критика. В Claude Code это пока экспериментальный режим, выключенный по умолчанию.

Выбор конфигурации зависит от задачи: «разложить массив на части и обработать» — работа для субагентов; «выработать позицию, где аргументы конфликтуют» — для команды со спором.

Преимущества использования субагентов

  • Изоляция контекста. Каждый агент держит в окне только свою часть и работает без накопленного мусора переписки.

  • Специализация. Можно запустить десятки узких агентов-специалистов.

  • Настойчивость. Цикл не заканчивается, пока не выполнен формальный критерий качества, — процесс сам гоняет доработку по кругу.

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

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

Приемы управления

Ниже — приемы, которые уже применяют юристы сообщества Нейросети | ilovedocs.

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

Выделяйте проверку в отдельную роль. Самый часто используемый прием — отделить того, кто пишет, от того, кто проверяет. Формы разные: рецензенты с оценкой от 0 до 100 и порогом (метод Олега Блинова), «адвокат дьявола», обязанный искать дыры (подход Григория Москалева), передача черновика на критику другой модели — Claude пишет и запускает двух рецензентов параллельно, а Codex выступает придирчивым критиком (прием Максима Шедогубова).

Задавайте роли моделям по способностям (мультимодельная оркестрация). Разные модели — на разные роли: более «умная» на архитектуру и ревью, быстрая и дешевая — на рутину, третья — для «второго мнения». В сообществе так собирают многомодельные связки: например, в многомодельном плагине Яна Стригова — форке Superpowers — оркестрацию ведет Sonnet, планирование и ревью выполняет Opus, а реализацию — Codex.

Выносите роли и инструкции в переиспользуемые файлы. Персону-критерий удобно хранить отдельным файлом или скиллом и копировать в новые проекты. Полезно различать: короткие «мягкие» правила — в профиле или системной инструкции, проектные — в файле CLAUDE.md в корне проекта, а длинные инструкции «как что-то сделать» дробить на отдельные скиллы, а не держать одним полотном.

Сохраняйте артефакты процесса. Оркестратор может вести журнал: правку на каждую итерацию, лог оценок, итоговый отчет с баллами и резюме изменений. Это дает воспроизводимость и точку приемки. Как сформулировано в разборе Екатерины Якуненко «Мой месяц в Claude Cowork», «результаты каждого этапа работы агента должны быть задокументированы» — так появляется аудит-трейл, по которому видно, на каком шаге возникла ошибка.

Для каких юридических задач это подходит

Оркестрация оправдывает свою цену там, где задача сложная или объемная:

  • Массовый параллельный анализ. Обработать практику судьи из 200 решений, чтобы найти закономерности, можно не одним агентом за пять часов, а двадцатью за двадцать минут (кейс Максима Шедогубова).

  • Проверка и юридический дизайн массива договоров. Скилл в Claude Cowork переводит массив типовых договоров в формат юридического дизайна и сверяет их условия с требованиями регуляторов. Чтобы агент не выдумывал, цитаты проверяются по совпадению начала и конца пункта, а несовпадения уходят на пересборку; вывод агент выдает по заданной «рамке»: что устанавливает пункт, что говорят регулирующие документы, есть ли расхождение и почему. На реальном проекте точность так довели примерно с 30% до 90%. Этим кейсом Евгений Вихров поделился на вебинаре «Как работать в Claude Design — опыт участников сообщества» (21.05.2026).

  • Меморандумы и заключения с исследованием и критикой. Команда «исследователь → автор → критик» готовит правовую справку с уже встроенной проверкой (демонстрация Григория Москалева на примере ответственности маркетплейса за контрафакт).

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

Отдельная большая область — написание кода с агентами (вайб-кодинг): та же оркестрация субагентов лежит в основе «нового SDLC» (Software Development Life Cycle — жизненного цикла разработки ПО) — см. гайд Google «The New SDLC With Vibe Coding», где команда агентов пишет, проверяет и чинит код. Здесь эти приемы применяются особенно развернуто; подробный разбор скоро появится в обновлении раздела Вайб-кодинг.

Когда оркестрация не нужна: простой документ, одна-две правки, единственное четкое требование — последовательные промпты в обычном чате будут быстрее и дешевле.

Связанные статьи

Дополнительные материалы

Теги: #агентный-ии #оркестрация #актуальное