Инструменты агентных рабочих процессов: паттерны и подводные камни

На прошлой неделе я считала часы. За пятидневный спринт по написанию агентного пайплайна — семь инструментов, три внешних API, песочница для кода, слой автоматизации браузера — я потратила примерно 14 часов на отладку. Одиннадцать из них — на «проводку». Не модель. Не промпты. Пространство между тем, как модель решает вызвать инструмент, и тем, как этот инструмент действительно делает правильную вещь.

Кто-то в нашем командном Slack спросил меня: «Дора, разве сложной частью не должен был быть промпт-инжиниринг?» Восемь месяцев назад — да. Сейчас промпты занимают один день. Заставить диспетчеризацию инструментов, ограничение прав доступа и восстановление после сбоев правильно работать под реальной нагрузкой занимает остаток недели.

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

Почему «проводка» инструментов — это самое сложное

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

Что на самом деле означает «проводка» в агентных системах. «Проводка» инструментов — это не просто «подключить API». Это полная поверхность: как инструменты обнаруживаются, как они описываются модели, как разграничиваются права доступа для каждого инструмента, как ответы проверяются перед подачей обратно в контекстное окно, и как сбои в любой из этих точек обрабатываются без сбоя сессии. Спецификация Model Context Protocol была разработана специально для стандартизации этого слоя — обнаружение инструментов, вызов и форматирование результатов — потому что каждая команда изобретала его заново.

Распространённые заблуждения при переходе от демо к продакшену. В демо вы подключаете три инструмента, модель вызывает их правильно, и это кажется магией. В продакшене вы обнаруживаете, что описания инструментов конкурируют за внимание, когда их пятнадцать. Что схемы параметров должны быть до абсурда точными, иначе модель будет галлюцинировать аргументы. Что «счастливый путь», продемонстрированный в вашем прототипе, покрывает, возможно, 40% реальных вызовов. В недавней публикации Anthropic о написании эффективных инструментов для агентов обнаружилось, что даже незначительные изменения в описаниях инструментов — например, добавлял ли Claude «2025» к поисковым запросам — могут существенно снизить производительность. Дизайн интерфейса имеет такое же значение, как и модель.

Основные паттерны в производственной оркестрации инструментов

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

Последовательная и параллельная диспетчеризация инструментов. Последовательная диспетчеризация проста — вызвать инструмент A, разобрать результат, вызвать инструмент B. Большинство ранних агентных систем работают именно так. Параллельная диспетчеризация, при которой модель одновременно запрашивает несколько вызовов инструментов, сокращает задержку, но вводит сложность координации. Фреймворк оркестрации LangGraph поддерживает оба паттерна через своё графовое управление состоянием, и разница в реальной задержке значительна — я измерила ускорение в 3-4 раза на пакетных операциях. Но параллельная диспетчеризация также означает, что нужно обрабатывать частичные сбои: что происходит, когда инструмент A успешно выполняется, а инструмент B зависает?

Ограничение прав доступа по типу инструмента. Не все инструменты несут одинаковый риск. Запрос к базе данных только для чтения фундаментально отличается от инструмента, который может удалять файлы или отправлять письма. Я разграничиваю инструменты на три уровня: только чтение (автоматически одобряется), запись с откатом (логируется, автоматически одобряется с аудитом) и деструктивные/внешние (требуют явного подтверждения). Команда NVIDIA AI Red Team опубликовала практическое руководство по изолированию, которое хорошо формулирует это: обязательные меры контроля — ограничения исходящего трафика и блокировка записи файлов за пределами рабочего пространства. Всё остальное вторично.

Стратегии изолирования. Если ваш агент выполняет код, ему нужна песочница. Не контейнер Docker — контейнеры совместно используют ядро хоста и недостаточно изолированы для ненадёжного LLM-генерируемого кода. Производственные варианты: микровиртуальные машины (Firecracker, Kata Containers), gVisor для перехвата системных вызовов или защищённые контейнеры строго для доверенного кода. Я запускаю gVisor для большинства выполнений инструментов. Накладные расходы приемлемы. Альтернатива — обнаружить, что LLM-сгенерированная команда bash выполнила rm -rf на подключённом томе — нет.

Режимы отказов, которые следует ожидать

Циклы вызовов инструментов и бесконечное делегирование. Самый дорогостоящий режим отказа. Модель вызывает инструмент, получает ошибку, повторяет тот же вызов с идентичными параметрами, получает ту же ошибку, повторяет снова. Без ограниченного бюджета повторных попыток это продолжается до исчерпания лимита токенов или порога выставления счетов API. Я особенно часто наблюдала это при ошибках авторизации — модель продолжает повторять то, что никогда не удастся. Минимальный порог — ограниченное количество повторных попыток (2-3) с классификацией ошибок на повторяемые и неповторяемые.

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

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

Деструктивные команды без ограничений. Модель с доступом к выполнению оболочки или инструментам файловой системы время от времени будет генерировать деструктивные команды. Не злонамеренно — просто некорректно. Руководство AWS по оркестрации агентов рабочих процессов рекомендует отслеживать состояние выполнения для каждого рабочего агента и внедрять шлюзы подтверждения для всего, что влияет на производственные системы. Согласна. Любой инструмент, который может записывать, удалять или отправлять, должен иметь явный шаг подтверждения.

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

Паттерны восстановления и отказоустойчивости

Логика повторных попыток с экспоненциальной задержкой. Начните с 1 секунды, удваивайте каждую попытку, ограничьтесь 60 секундами, добавьте случайный джиттер. Это не опционально. Без джиттера параллельные сессии повторяют попытки одновременно и создают эффект «стада громов». Сначала классифицируйте ошибки: ограничения запросов и ошибки 5xx повторяются. Ошибки авторизации и валидации — нет, никакое количество повторных попыток не исправит неправильный ключ API. Две-три попытки для транзиентных ошибок. Ноль для неповторяемых.

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

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

Оценка агентной инфраструктуры

Строить или покупать: когда создавать собственную обвязку. Если ваш рабочий процесс — линейная цепочка из 3-4 инструментов с предсказуемыми входными данными, пользовательская обвязка строится за день и проще в обслуживании, чем фреймворк. Если вам нужна динамическая маршрутизация, параллельная диспетчеризация, сохранение состояния между сессиями и контрольные точки с участием человека, построение с нуля займёт месяцы. Именно тогда фреймворки вроде LangGraph или управляемые платформы зарабатывают своё место. Я начала с пользовательского решения. Мигрировала после третьего раза, когда перереализовывала контрольные точки состояния.

Ключевые сигналы производственной готовности. Можете ли вы ответить на эти вопросы: Что происходит, когда вызов инструмента зависает? Где хранятся журналы вызовов инструментов, и можно ли их запрашивать? Как система обрабатывает ответ инструмента, который является валидным JSON, но семантически неверным? Можно ли воспроизвести сбойную сессию с контрольной точки? Если любой из этих вопросов заставляет вас задуматься, система не готова к продакшену.

Что нужно оценить перед масштабированием. Задержка на вызов инструмента под нагрузкой. Частота ошибок по типу инструмента. Потребление токенов за сессию (ответы инструментов — основной драйвер). Резерв по ограничениям запросов при 2x текущего трафика. Я игнорировала метрику потребления токенов несколько недель и была потрясена, когда действительно измерила — ответы инструментов составили 60% моих общих расходов на токены.

Часто задаваемые вопросы

Что такое «проводка» инструментов в агентных AI-системах?

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

Как предотвратить деструктивные команды в агентных рабочих процессах?

Разделите инструменты по уровням риска. Операции только для чтения могут автоматически одобряться. Операции записи должны логироваться с возможностью отката. Деструктивные операции — всё, что удаляет данные, отправляет внешние сообщения или изменяет производственное состояние — должны требовать явного подтверждения человека. Сочетайте это с изолированием (gVisor или микровиртуальные машины для выполнения кода) и элементами управления исходящим трафиком, которые по умолчанию блокируют произвольные исходящие соединения.

Каков лучший способ обработки сбоев вызовов инструментов в продакшене?

Классифицируйте ошибки на повторяемые (ограничения запросов, таймауты, 5xx) и неповторяемые (ошибки авторизации, ошибки валидации, отказ в доступе). Применяйте экспоненциальную задержку с джиттером для повторяемых ошибок, ограничив 2-3 попытками. Для неповторяемых ошибок возвращайте чёткое сообщение об ошибке модели, чтобы она могла скорректировать свой подход — или передать задачу пользователю. Дополните это размыкателями цепи, которые обнаруживают, когда инструмент последовательно даёт сбой, и обходят его.

Как работает управление разрешениями в многоинструментальных агентах?

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

Когда следует использовать управляемый агентный слой, а не строить собственный?

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

Я ещё настраиваю модель ограничения прав доступа. Трёх уровней может быть недостаточно — некоторые операции записи кажутся такими, которые следует автоматически одобрять (добавление в лог-файл), тогда как другие явно нет (обновление записи клиента). Эта граница продолжает смещаться по мере усложнения рабочих процессов. Продолжение следует.

Предыдущие публикации：

• Claude Code Agent Harness Architecture
• Claude Mythos vs Claude Opus 4.6
• Claude Mythos API Pricing
• What is Claude Mythos?
• Claude Code: Architecture & Leaked Source Deep Dive