Building Effective AI Agents

За прошедший год мы работали с десятками команд, создающих агентов на основе больших языковых моделей (LLM) в самых разных отраслях. Раз за разом самые успешные реализации обходились без сложных фреймворков или специализированных библиотек. Вместо этого они строились на простых, компонуемых паттернах.

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

Что такое агенты?

Понятие «агент» можно определить по-разному. Одни клиенты называют агентами полностью автономные системы, которые работают независимо в течение продолжительного времени, используя различные инструменты для решения сложных задач. Другие используют этот термин для более жёстко заданных реализаций, следующих заранее определённым процессам. В Anthropic мы относим все эти варианты к агентным системам, но проводим важное архитектурное различие между workflow и агентами:

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

Ниже мы подробно рассмотрим оба типа агентных систем. В Приложении 1 («Агенты на практике») мы описываем две области, где клиенты нашли особую пользу в применении таких систем.

Когда (и когда не) стоит использовать агентов

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

Когда дополнительная сложность оправдана, workflow обеспечивают предсказуемость и согласованность для чётко определённых задач, тогда как агенты предпочтительнее, когда нужны гибкость и принятие решений самой моделью в масштабе. Однако для многих приложений обычно достаточно оптимизировать одиночные вызовы LLM с помощью retrieval и примеров в контексте.

Когда и как использовать фреймворки

Существует множество фреймворков, упрощающих реализацию агентных систем, среди них:

Claude Agent SDK; Strands Agents SDK от AWS;Rivet — графический конструктор workflow для LLM с интерфейсом drag-and-drop; и Vellum — ещё один графический инструмент для создания и тестирования сложных workflow.

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

Мы советуем разработчикам начинать с прямого использования API LLM: многие паттерны реализуются буквально в несколько строк кода. Если же вы используете фреймворк, убедитесь, что понимаете лежащий в его основе код. Неверные предположения о том, что происходит «под капотом», — частый источник ошибок у клиентов.

Несколько примеров реализаций смотрите в нашем cookbook.

Строительные блоки, workflow и агенты

В этом разделе мы разберём распространённые паттерны агентных систем, которые мы видели в продакшене. Начнём с нашего базового строительного блока — расширенного LLM — и будем постепенно наращивать сложность: от простых композиционных workflow до автономных агентов.

Строительный блок: расширенный LLM

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

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

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

Workflow: цепочка промптов (prompt chaining)

Цепочка промптов разбивает задачу на последовательность шагов, где каждый вызов LLM обрабатывает результат предыдущего. На любом промежуточном шаге можно добавить программные проверки (см. «gate» на схеме ниже), чтобы убедиться, что процесс идёт как надо.

Когда использовать этот workflow: Этот workflow идеален для ситуаций, когда задачу можно легко и чисто разложить на фиксированные подзадачи. Главная цель — обменять задержку на более высокую точность, делая каждый вызов LLM более простой задачей.

Примеры, где полезна цепочка промптов:

Создание маркетингового текста с последующим переводом его на другой язык.Написание плана документа, проверка того, что план соответствует определённым критериям, и затем написание документа на основе этого плана.

Workflow: маршрутизация (routing)

Маршрутизация классифицирует входные данные и направляет их в специализированную последующую задачу. Этот workflow позволяет разделить ответственность и строить более узкоспециализированные промпты. Без него оптимизация под один тип входных данных может ухудшить качество работы на других.

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

Примеры, где полезна маршрутизация:

Направление разных типов обращений в службу поддержки (общие вопросы, запросы на возврат средств, техническая поддержка) в разные последующие процессы, промпты и инструменты.Направление простых/частых вопросов к меньшим, экономичным моделям вроде Claude Haiku 4.5, а сложных/нетипичных — к более мощным, вроде Claude Sonnet 4.5, чтобы добиться наилучшего качества.

Workflow: параллелизация (parallelization)

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

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

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

Примеры, где полезна параллелизация:

Секционирование:Реализация защитных ограничений (guardrails), когда один экземпляр модели обрабатывает запросы пользователя, а другой проверяет их на неприемлемый контент или запросы. Это обычно работает лучше, чем когда один и тот же вызов LLM отвечает и за защитные ограничения, и за основной ответ.Автоматизация оценок (evals) для измерения качества работы LLM, когда каждый вызов LLM оценивает отдельный аспект работы модели на заданном промпте.Голосование:Проверка фрагмента кода на уязвимости, когда несколько разных промптов просматривают код и помечают его, если находят проблему.Оценка того, является ли некий контент неприемлемым, когда несколько промптов оценивают разные аспекты или требуют разных порогов голосования, чтобы сбалансировать ложноположительные и ложноотрицательные срабатывания.

Workflow: оркестратор-исполнители (orchestrator-workers)

В workflow «оркестратор-исполнители» центральный LLM динамически разбивает задачи, делегирует их LLM-исполнителям и синтезирует их результаты.

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

Пример, где полезен оркестратор-исполнители:

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

Workflow: оценщик-оптимизатор (evaluator-optimizer)

В workflow «оценщик-оптимизатор» один вызов LLM генерирует ответ, а другой в цикле даёт оценку и обратную связь.

Когда использовать этот workflow: Этот workflow особенно эффективен, когда у нас есть чёткие критерии оценки и когда итеративная доработка приносит измеримую пользу. Два признака хорошей применимости таковы: во-первых, ответы LLM заметно улучшаются, когда человек формулирует свою обратную связь; во-вторых, LLM способен сам давать такую обратную связь. Это похоже на итеративный процесс письма, через который проходит человек-автор, доводя документ до готового вида.

Примеры, где полезен оценщик-оптимизатор:

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

Агенты

Агенты появляются в продакшене по мере того, как LLM взрослеют в ключевых способностях — понимании сложных входных данных, рассуждении и планировании, надёжном использовании инструментов и восстановлении после ошибок. Агенты начинают работу либо с команды от пользователя, либо с интерактивного обсуждения с ним. Как только задача ясна, агенты планируют и действуют самостоятельно, при необходимости возвращаясь к человеку за дополнительной информацией или решением. В ходе выполнения агентам крайне важно на каждом шаге получать «ground truth» из среды (например, результаты вызова инструментов или выполнения кода), чтобы оценивать свой прогресс. Затем агенты могут приостанавливаться для обратной связи от человека на контрольных точках или при столкновении с препятствиями. Задача часто завершается по её выполнении, но также принято включать условия остановки (например, максимальное число итераций), чтобы сохранять контроль.

Агенты способны решать сложные задачи, но их реализация зачастую проста. Как правило, это всего лишь LLM, использующие инструменты в цикле на основе обратной связи от среды. Поэтому крайне важно продуманно и ясно проектировать наборы инструментов и их документацию. Подробнее о лучших практиках разработки инструментов мы пишем в Приложении 2 («Prompt-инжиниринг ваших инструментов»).

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

Автономный характер агентов означает более высокие затраты и потенциальное накопление ошибок. Мы рекомендуем тщательное тестирование в изолированных (sandbox) средах вместе с соответствующими защитными ограничениями.

Примеры, где полезны агенты:

Следующие примеры взяты из наших собственных реализаций:

Кодинг-агент для решения задач SWE-bench, которые требуют правок во множестве файлов на основе описания задачи;Наша эталонная реализация «computer use», где Claude использует компьютер для выполнения задач.

Комбинирование и настройка этих паттернов

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

Итоги

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

Реализуя агентов, мы стараемся следовать трём базовым принципам:

Сохраняйте простоту в дизайне вашего агента.Отдавайте приоритет прозрачности, явно показывая шаги планирования агента.Тщательно прорабатывайте интерфейс «агент-компьютер» (ACI) через подробную документацию и тестирование инструментов.

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

Благодарности

Авторы — Erik S. и Barry Zhang. Эта работа опирается на наш опыт создания агентов в Anthropic и на ценные наблюдения, которыми поделились наши клиенты, за что мы им глубоко признательны.

Приложение 1: агенты на практике

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

A. Поддержка клиентов

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

Взаимодействия в поддержке естественным образом следуют ходу беседы, при этом требуя доступа к внешней информации и действиям;Можно интегрировать инструменты для получения данных о клиенте, истории заказов и статей из базы знаний;Действия вроде оформления возвратов или обновления тикетов можно выполнять программно; иУспех можно чётко измерить через определённые пользователем критерии решения проблемы.

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

B. Кодинг-агенты

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

Решения в коде проверяемы с помощью автоматических тестов;Агенты могут дорабатывать решения, используя результаты тестов как обратную связь;Пространство задачи чётко определено и структурировано; иКачество результата можно измерить объективно.

В нашей собственной реализации агенты теперь могут решать реальные GitHub-issue из бенчмарка SWE-bench Verified, опираясь только на описание pull request. Однако, хотя автоматическое тестирование помогает проверить функциональность, человеческая проверка остаётся критически важной для того, чтобы решения соответствовали более широким требованиям системы.

Приложение 2: prompt-инжиниринг ваших инструментов

Какую бы агентную систему вы ни строили, инструменты, скорее всего, станут важной частью вашего агента. Инструменты позволяют Claude взаимодействовать с внешними сервисами и API, задавая их точную структуру и определение в нашем API. Когда Claude отвечает, он включает в ответ API блок использования инструмента (tool use block), если планирует вызвать инструмент. Определениям и спецификациям инструментов следует уделять не меньше внимания при prompt-инжиниринге, чем вашим основным промптам. В этом коротком приложении мы описываем, как заниматься prompt-инжинирингом ваших инструментов.

Зачастую одно и то же действие можно задать несколькими способами. Например, правку файла можно описать, написав diff или переписав файл целиком. Для структурированного вывода можно вернуть код внутри markdown или внутри JSON. В разработке ПО подобные различия косметичны и без потерь конвертируются одно в другое. Однако некоторые форматы модели гораздо труднее писать, чем другие. Написание diff требует знания того, сколько строк меняется в блоке, ещё до того, как написан новый код (в заголовке чанка). Написание кода внутри JSON (по сравнению с markdown) требует дополнительного экранирования переносов строк и кавычек.

Наши рекомендации по выбору форматов инструментов таковы:

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

Одно эмпирическое правило — подумать о том, сколько усилий вкладывается в интерфейсы «человек-компьютер» (HCI), и запланировать столько же усилий на создание хороших интерфейсов «агент»-компьютер (ACI). Вот несколько мыслей о том, как это сделать:

Поставьте себя на место модели. Очевидно ли, как пользоваться этим инструментом, исходя из описания и параметров, или над этим пришлось бы серьёзно подумать? Если да, то, вероятно, это верно и для модели. Хорошее определение инструмента часто включает пример использования, граничные случаи, требования к формату входных данных и чёткие границы по отношению к другим инструментам.Как можно изменить имена или описания параметров, чтобы сделать вещи более очевидными? Думайте об этом как о написании отличного docstring для младшего разработчика в вашей команде. Это особенно важно при использовании множества похожих инструментов.Тестируйте, как модель использует ваши инструменты: прогоните множество примеров входных данных в нашем workbench, чтобы увидеть, какие ошибки делает модель, и дорабатывайте.Применяйте к инструментам принцип poka-yoke (защита от ошибок). Меняйте аргументы так, чтобы ошибиться было труднее.

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