Как устроена «команда» внутри ИИ-сервиса
- Запрос клиентаНужны дата доставки и следующий шаг
- Передачи между исполнителямиСведения и условия должны сохраниться
- Ответ клиентуПроверяем результат всего запроса
Допустим, компания внедрила помощника поддержки. Один компонент определяет тему обращения, другой разбирает заказ, третий отвечает за доставку, четвёртый формулирует сообщение клиенту.
Субагент здесь означает отдельного ИИ-исполнителя со своими инструкциями и рабочим контекстом. Он получает часть задачи и возвращает результат. При каждой передаче приходится решать, какие сведения сохранить для следующего исполнителя.
В гайде Anthropic рассматривается альтернатива: основной агент ведёт задачу, а необходимые инструкции и инструменты получает по мере необходимости. Так можно уменьшить число передач контекста. Решение зависит от измерений конкретной системы, а не от количества прямоугольников на схеме. Исходный гайд.
Что такое один агент со скиллами
- Основной агентСохраняет задачу и выбирает следующий шаг
- Скиллы и инструментыПодключает инструкции и получает данные
- Проверенный результатСоблюдает ограничения и отвечает пользователю
Представьте сотрудника, у которого есть рабочая инструкция и доступ к нескольким сервисам. Для новой задачи ему не нужно читать все регламенты компании. Он открывает нужный раздел и использует подходящий инструмент.
| Элемент | Простое объяснение | Пример |
|---|---|---|
| Основной агент | Ведёт запрос и выбирает следующий шаг | Уточняет, какой заказ проверить |
| Скилл | Подключаемая инструкция по конкретной работе | Как обработать запрос о возврате |
| Инструмент | Выполняет определённое действие | Получает статус заказа из учётной системы |
| Проверка в коде | Обеспечивает обязательное условие | Отказывает в операции с чужим заказом |
Скилл сам по себе не создаёт второго исполнителя. Единый агент может обращаться к нескольким инструментам, в том числе параллельно.
В миграционном наборе Anthropic описано, как раскладывать инструкции: процедуру переносить в скилл, справочные сведения в материалы или поиск, обязательные ограничения в исполняемые проверки. Шаг переноса функций.
Где потери заметны пользователю
Рассмотрим условный запрос: «Заказ задерживается. Успеет ли он прийти до пятницы, и что делать, если нет?»
Пользователь оценивает один результат. Ему нужны подтверждённая дата и доступные действия. Если один агент проверил оплату, другой прочитал общие условия доставки, а третий составил красивый ответ, задача всё равно может остаться нерешённой.
Для владельца продукта полезны три вопроса:
- Получены ли фактические сведения именно по этому заказу?
- Сохранилось ли ограничение клиента «до пятницы»?
- Понятно ли пользователю, что делать дальше?
Само объединение агентов правильной даты не создаёт. Нужен инструмент, который получает её из соответствующего источника. Иначе сменится архитектура, а пробел в данных останется.
Четыре решения вместо спора «один или много»
Каждую специализированную функцию стоит рассмотреть отдельно.
| Решение | Когда его проверять |
|---|---|
| Перенести в основной агент | Работа состоит из инструкции и инструментов; отдельный контекст не даёт понятной пользы |
| Объединить два субагента | Они постоянно идут друг за другом и используют одни сведения |
| Оставить субагента как инструмент | Нужна отдельная обработка, но она укладывается в ограниченное поручение с результатом |
| Сохранить отдельное ведение диалога | Исполнителю действительно нужно самостоятельно общаться с пользователем |
Такую классификацию предлагает этап аудита набора Anthropic. Для решения нужны основания: код, логи вызовов, объём данных, характер ошибок. Принадлежность функции отдельному отделу сама по себе этих оснований не заменяет.
Если субагент остаётся инструментом, основной агент продолжает разговор. Исполнитель возвращает структурированный результат: вывод, доказательства, выполненные действия и оговорки. Это помогает проверять передачу сведений, хотя сама передача никуда не исчезает. Вариант «агент как инструмент».
Как это применить к контент-заводу
Представим систему, которая превращает голосовую заметку предпринимателя в статью и несколько публикаций. В ней могут быть агенты интервьюера, автора, редактора и выпускающего.
Начать стоит с карты результата. Какие факты должны попасть в материал? Кто подтверждает спорные утверждения? Где хранится согласованная версия? Кто разрешает публикацию?
Возможный вариант для проверки: один агент хранит задачу и подключает инструкции для интервью, структуры и редактирования. Расшифровку и сохранение черновика выполняют инструменты. Публикация проходит отдельную проверку прав и согласования.
Независимого проверяющего можно сохранить. Например, дать ему утверждения и первоисточники для поиска неподтверждённых выводов. Критерий пользы конкретный: ловит ли проверка ошибки, которые основной процесс пропускает, и оправдывает ли результат её стоимость.
Этот пример дополняет наш разбор контент-завода с ИИ. Первым экспериментом может стать только объединение подготовки структуры и первого черновика.
Как проверить миграцию без самообмана
До изменения системы зафиксируйте, что считается выполненной задачей. Для поддержки: подтверждённый срок и понятное следующее действие. Для контент-завода: черновик с проверенными фактами, сохранённый в нужном месте без преждевременной публикации.
Сравнивайте версии на одинаковых заданиях, с одной версией модели и одинаковыми доступными данными. В наборе Anthropic предусмотрены исходный замер, повторные прохождения и проверка цепочек передачи сведений. Важен итог запроса, а не только удачная формулировка ответа. Этап исходной оценки.
Для продуктового обсуждения удобно собрать такую таблицу. Это критерии примера поддержки, а не готовые результаты замера.
| Что измеряем | Что считать результатом |
|---|---|
| Завершение задачи | Дата подтверждена, следующий шаг объяснён |
| Время | Измерено от запроса до полезного ответа |
| Стоимость | Учтены обращения к моделям и платным инструментам |
| Сохранность условий | Срок клиента и ограничения операции не потерялись |
| Поведение при сбое | Система сообщает, каких данных нет, и предлагает доступное действие |
| Соблюдение доступа | Чужие записи недоступны, запрещённые операции отклоняются |
Особенно полезны пограничные случаи: нет данных, доступ запрещён, пользователь изменил условие, сервис не ответил. Если новая версия выигрывает на обычных запросах, но ломает обязательное правило, эксперимент нужно доработать.
Что даёт single-agent-loop-kit
Single agent loop kit сопровождает гайд. В нём есть скилл для Claude Code, этапы аудита и миграции, скрипты сравнения и пример службы поддержки. Это справочная реализация без сопровождения; авторы не принимают доработки. В README перечислены ограничения реальных испытаний. Набор не стоит представлять как готовую систему для эксплуатации.
Для знакомства можно скачать репозиторий и выполнить бесплатную проверку демонстрации:
git clone https://github.com/anthropics/single-agent-loop-kit
cd single-agent-loop-kit/examples/support-desk
KIT_MODEL=fake python3 evals/run_eval.py --variant smoke
При подготовке статьи мы выполнили этот прогон на версии c43796287b83bec847db923f07131d1cc8de750d: 19 сценариев прошли без ошибок тестовой обвязки. Использовалась локальная модель-заглушка. Это подтверждает запуск демонстрации, но не качество ответов Claude, экономию или готовность вашей системы к миграции. Назначение проверки объяснено в инструкции демонстрации.
С чего начать руководителю
Попросите команду выбрать повторяющийся процесс и показать путь запроса до результата. Выделите участок, где исполнители используют одни данные и часто передают работу друг другу.
До эксперимента нужны согласованные критерии, тестовый контур и возможность вернуть предыдущую версию. После него нужен разбор конкретных заданий: какие улучшились, какие ухудшились и почему.
Разговор об архитектуре становится предметным, когда рядом со схемой появляются реальные запросы, результаты и стоимость. Тогда можно решить, где достаточно одного агента со скиллами, а где отдельный исполнитель приносит измеримую пользу.
Если вы только выбираете первый процесс, начните с гайда по автоматизации малого бизнеса. Различия между помощником и бизнес-процессом разобраны в материале об ИИ-ассистенте.
В A+I можно начать с разбора действующей схемы: определить результат для пользователя, найти лишние передачи и выбрать один участок для проверяемого пилота.