Сбой обычно происходит на границе
Когда агент вызывает инструмент и вызов идёт не так, инстинктивно хочется винить модель. Промпт был недостаточно ясен, рассуждение было поверхностным, контекст был зашумлён. На практике значительная доля таких сбоев решается ещё до того, как модель вообще начинает рассуждать: на схеме инструмента. Схема — это контракт между моделью и системой. Если этот контракт расплывчат, модель заполняет пробелы правдоподобными догадками, и инструмент их исполняет.
Это эссе утверждает, что проектирование интерфейса следует рассматривать как главный рычаг надёжности для агентных систем, опережающий промпт-инжиниринг. Промпты формируют поведение вероятностно. Схемы обеспечивают его структурно.
Где на самом деле сбоят вызовы инструментов
Три паттерна объясняют непропорционально большую долю плохих вызовов инструментов.
Неоднозначные имена параметров. Поле с именем target, value или options приглашает модель выводить смысл из контекста. Модель порождает аргумент, синтаксически корректный и семантически неверный. Инструмент его принимает. Ошибка всплывает позже, часто как проблема с данными ниже по потоку, а не как неудавшийся вызов. Имена вроде target_user_id и retention_days — не многословные; они устраняют неоднозначность.
Опциональные поля без значения по умолчанию. Если схема помечает поле опциональным, но у инструмента нет значения по умолчанию и нет пути обработки null, модель вынуждена придумать значение, чтобы завершить вызов. Она это сделает. Придуманное значение будет выглядеть разумно и будет неверным так, что это трудно обнаружить. Опциональность — это утверждение о поведении инструмента, а не подсказка модели.
Аргументы в виде свободного текста. Строковый аргумент без структуры сводит намерение к прозе. Инструмент не может валидировать прозу. Модель нельзя исправить прозой. Поле, принимающее "отправь отчёт команде завтра утром", перекладывает логику планирования в голову модели, где её нельзя ни проинспектировать, ни протестировать.
Это не сбои рассуждения. Это сбои спецификации, которые выглядят как сбои рассуждения.
Правила проектирования схемы инструмента
К схеме инструмента следует относиться с той же строгостью, что и к публичному API, потому что это оно и есть.
Каждый аргумент типизирован, ограничен и валидируется на границе. Типы необходимы, но недостаточны. Строка, которая должна быть одним из фиксированного набора, должна быть enum. Число, которое должно попадать в диапазон, должно нести этот диапазон, и граница должна отклонять значения вне его до исполнения. Валидация на границе означает, что инструмент никогда не видит аргумент, который не может обработать, а модель получает детерминированный сигнал, когда она его породила.
Предусловия указаны в описании, а не подразумеваются из контекста. Если инструменту требуется, чтобы ресурс существовал или чтобы предыдущий вызов завершился успешно, это место — в описании. Модель не выводит надёжно предусловия из истории диалога, и не должна этого делать. Описание, говорящее «требуется активный session id, полученный из open_session», — это спецификация. Описание, говорящее «делает то самое», — это надежда.
Ошибки возвращаются как типизированные коды с подсказками по исправлению. Когда вызов не проходит валидацию, ответ должен быть машиночитаемым: код, по которому агент может ветвиться, плюс короткая подсказка о том, что удовлетворило бы контракт. Стек-трейсы и свободнотекстовые сообщения об ошибках перекладывают парсинг обратно на модель — именно ту работу, которую схема должна была убрать.
Конкретный механизм: двухэтапный путь вызова. Модель порождает аргументы по схеме. Валидатор проверяет типы, границы, enum и предусловия и возвращает либо нормализованный объект аргументов, либо типизированный отказ. Только нормализованные объекты доходят до реализации инструмента. Реализация инструмента тогда может предполагать, что её входные данные хорошо сформированы, что убирает защитное ветвление из пути исполнения и делает сбои относимыми к одному из двух мест: аргументу модели или поведению инструмента.
Почему промпты не могут компенсировать
Соблазнительно написать более длинный системный промпт, объясняющий особенности инструмента. Это не масштабируется по трём причинам.
Следование инструкциям ухудшается с ростом длины контекста и числа инструментов. По мере роста числа доступных инструментов внимание модели к любой отдельной инструкции размывается. Правило, изложенное один раз в длинном промпте, конкурирует со всем остальным в окне. Схема же обеспечивается при каждом вызове независимо от того, сколько инструментов присутствует.
Схема обеспечивается; промпт соблюдается. Это ключевая асимметрия. Валидация выполняется детерминированно. Соблюдение промпта — это вероятность, варьирующаяся от формулировки, порядка и контекста. Когда важна надёжность
Изменения схемы — это рецензируемые артефакты. Диф к схеме инструмента — это диф к контракту. Его можно рецензировать, версионировать, тестировать и откатывать. Правка промпта — это изменение инструкции на естественном языке, эффекты которого не локальны и не легко ограничиваемы. Команды, относящиеся к промптам как к слою надёжности, получают надёжность, которую нельзя рецензировать.
Честный компромисс: более строгие схемы стоят гибкости. Жёстко типизированный инструмент не может поглотить слабо специфицированный запрос, и некоторые законные сценарии использования будут отклонены на границе, а не обработаны изящно. Альтернатива — инструмент, который принимает что угодно и сбоит непредсказуемо. Для большинства продакшн-систем типизированный отказ дешевле молчаливого неверного результата. Там, где гибкость действительно необходима, её следует моделировать явно, например как размеченное объединение типизированных вариантов запроса, а не как нетипизированную строку.
Миграция и версионирование
Инструменты — это API. Им нужны окна устаревания, версионированные имена и период, в течение которого разрешаются и старая, и новая схемы. Агент, выучивший форму инструмента через его описание, не адаптируется мгновенно к ломающему изменению, и оценки, построенные вокруг него, тоже.
Две метрики заслуживают места на первоклассном дашборде, рядом с задержкой и стоимостью:
- Доля успешных вызовов по каждому инструменту. В разбивке по инструментам, а не агрегированно. Общесистемная доля успеха скрывает тот единственный инструмент, который сбоит.
- Доля отклонённых аргументов. Пропорция вызовов, отклонённых валидатором до исполнения. Растущая доля отклонений — ранний сигнал о том, что схема неоднозначна, что описание вводит в заблуждение или что у модели запрашивают значение, которого она не может знать.
Эти две метрики отделяют проблемы схемы от проблем рассуждения. Инструмент с высокой долей отклонений и ясным кодом отказа говорит вам, что его контракт неясен. Инструмент с высокой долей успеха на вызовах, которые позже дают неверные результаты, говорит вам, что его валидация слишком снисходительна. Ни один из этих сигналов не виден в промпте.
Что это меняет на практике
Отношение к поверхности инструмента как к проблеме схемы меняет то, куда уходят инженерные усилия. Проектирование схемы становится рецензируемой деятельностью с собственными тестами. Описания становятся спецификациями с предусловиями и постусловиями. Ошибки становятся частью интерфейса, а не запоздалой мыслью. Промпты по-прежнему важны, но они делают то, в чём хороши: формируют тон, стратегию и декомпозицию. Они не несут бремя обеспечения контракта.
Более широкая мысль в том, что надёжность агента — это в основном дисциплина интерфейса. Модель, которая хорошо рассуждает против расплывчатого интерфейса, всё равно будет порождать расплывчатые вызовы. Модель, которая рассуждает адекватно против точного интерфейса, будет порождать вызовы, которые можно проверить, отклонить и исправить. Вторая система — та, которой можно управлять.