В Anthropic поработали с десятками команд, которые строили агентов, и сделали вывод, который стоит повесить над столом: лучше всего работали не сложные фреймворки, а простые схемы, собранные из кубиков.
Они различают два типа систем:
- Рабочий процесс (workflow) — шаги заранее прописаны в коде, модель выполняет каждый шаг.
- Агент — модель сама решает, что делать дальше и какие инструменты брать.
Совет оттуда же: начинайте с самого простого. Иногда хватает одного хорошего запроса к модели с примерами. Агент дороже, медленнее и менее предсказуем — берите его, когда без гибкости правда не обойтись.
Вот пять базовых схем. Примеры к каждой — из обычной работы.
1. Цепочка
Задача разбивается на шаги, и каждый шаг получает результат предыдущего. Между шагами можно поставить проверку кодом.
Пример: поддержка получает письмо. Шаг 1 — модель достаёт из письма номер заказа и суть проблемы в JSON. Проверка кодом: номер заказа существует в базе? Шаг 2 — модель пишет черновик ответа по данным заказа.
Когда брать: шаги известны заранее. Каждому шагу проще работать, чем одному большому запросу «разберись с письмом».
2. Маршрутизация
Сначала вход классифицируется, потом отправляется в отдельную ветку со своими инструкциями и инструментами.
Пример: входящие обращения делятся на «вопрос», «возврат» и «баг». Для возврата — доступ к платёжной системе и строгие правила. Для бага — доступ к трекеру. Простые вопросы отдаются дешёвой модели, сложные — дорогой.
Когда брать: входы заметно разные, и одна инструкция на всех портит результат для части из них.
3. Параллельная работа
Два варианта:
- Нарезка — независимые куски задачи выполняются одновременно. Например, одна модель отвечает пользователю, а другая параллельно проверяет, нет ли в запросе попытки обойти правила.
- Голосование — одну задачу решают несколько раз и сравнивают ответы. Например, три независимые проверки кода на уязвимости: если хоть одна нашла проблему, смотрит человек.
Когда брать: куски действительно независимы, или вам нужна уверенность выше, чем даёт один прогон.
4. Оркестратор и исполнители
Главная модель смотрит на задачу, сама решает, на какие части её разбить, раздаёт части исполнителям и собирает результат.
Пример: «переименуй поле во всём проекте». Сколько файлов затронуто и какие — заранее неизвестно. Оркестратор находит их и отдаёт каждый исполнителю.
Когда брать: подзадачи нельзя прописать заранее, они зависят от входа. Это уже ближе к агенту.
5. Автор и проверяющий
Одна модель делает, вторая оценивает по критериям и возвращает замечания. Круг повторяется, пока проверяющий не будет доволен.
Пример: перевод технической документации. Переводчик переводит, редактор сверяет термины с глоссарием и отмечает неточности, переводчик правит.
Когда брать: есть понятные критерии качества, и правки действительно улучшают результат.
Как этим пользоваться
- Опишите задачу словами как последовательность шагов. Если получилось — это цепочка, агент не нужен.
- Если входы бывают разного типа — добавьте маршрутизацию на входе.
- Если важна точность — поставьте проверяющего. Лучше, если это модель другого семейства: она не повторит ошибки автора.
- К агенту с полной свободой переходите, только когда предыдущие схемы упёрлись в потолок.
Большинство «умных агентов» из демо на поверку оказываются цепочкой из трёх шагов с проверкой посередине. И это не недостаток — это то, что делает их надёжными.