Создание эффективных agents

Примечание: Значительная часть ландшафта инструментов, описанного в этой статье, изменилась с декабря 2024 года. О нашем текущем подходе читайте в статьях  «Как мы создали Claude Managed Agents» и в  документации по Managed Agents.

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

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

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

«Агент» можно определить по-разному. Некоторые клиенты определяют агентов как полностью автономные системы, которые функционируют независимо в течение длительного времени, используя различные инструменты для решения сложных задач. Другие используют этот термин для описания более регламентированных реализаций, следующих предопределенным рабочим процессам. В Anthropic мы относим все эти варианты к  агентным системам (agentic systems), но проводим важное архитектурное различие между  рабочими процессами (workflows) и  агентами:

•  Рабочие процессы (Workflows) — это системы, в которых LLM и инструменты оркеструются с помощью предопределенных путей кода.
•  Агенты (Agents), с другой стороны, — это системы, в которых LLM динамически управляют собственными процессами и использованием инструментов, сохраняя контроль над тем, как они выполняют задачи.

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

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

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

Когда требуется большая сложность, рабочие процессы обеспечивают предсказуемость и согласованность для четко определенных задач, в то время как агенты являются лучшим выбором, когда гибкость и принятие решений на основе моделей необходимы в больших масштабах. Однако для многих приложений оптимизации одиночных вызовов LLM с помощью извлечения данных (retrieval) и примеров в контексте (in-context examples) обычно оказывается достаточно.

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

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

• Claude Agent SDK; 
• Strands Agents SDK by AWS;
• Rivet — конструктор рабочих процессов LLM с графическим интерфейсом и функцией перетаскивания (drag and drop); а также 
• Vellum — еще один инструмент с графическим интерфейсом для создания и тестирования сложных рабочих процессов.

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

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

Примеры реализации вы можете найти в нашей поваренной книге (cookbook).

Строительные блоки, рабочие процессы и агенты

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

Строительный блок: Дополненная LLM (The augmented LLM)

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

Дополненная LLM

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

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

Рабочий процесс: Цепочки промптов (Prompt chaining)

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

Рабочий процесс цепочки промптов

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

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

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

Рабочий процесс: Маршрутизация (Routing)

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

Рабочий процесс маршрутизации

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

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

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

Рабочий процесс: Параллелизация (Parallelization)

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

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

Рабочий процесс параллелизации

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

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

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

Рабочий процесс: Оркестратор-воркеры (Orchestrator-workers)

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

Рабочий процесс «оркестратор-воркеры»

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

 Примеры полезного применения архитектуры «оркестратор-воркеры»:

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

Рабочий процесс: Оценщик-оптимизатор (Evaluator-optimizer)

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

Рабочий процесс «оценщик-оптимизатор»

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

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

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

Агенты (Agents)

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

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

Автономный агент

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

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

 Примеры полезного применения агентов:

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

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

Высокоуровневый поток работы агента по написанию кода

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

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

Резюме

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

При реализации агентов мы стараемся следовать трем основным принципам:

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

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

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

Авторы: Эрик С. (Erik S.) и Барри Чжан (Barry Zhang). Эта работа опирается на наш опыт создания агентов в Anthropic и ценные идеи, которыми поделились наши клиенты, и мы им за это глубоко признательны.

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

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

А. Служба поддержки клиентов

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

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

Несколько компаний продемонстрировали жизнеспособность этого подхода с помощью моделей ценообразования на основе использования (usage-based pricing), которые взимают плату только за успешно разрешенные проблемы, демонстрируя уверенность в эффективности своих агентов.

Б. Агенты для написания кода

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

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

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

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

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

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

Наши рекомендации по выбору форматов инструментов заключаются в следующем:

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

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

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

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