Глава 4 — ИИ-агенты и вызов инструментов

Четвёртый пост поглавного разбора LLM Primer V: Building Real-World LLM Applications. Глава, относящаяся к агенту как к языковой модели, зациклённой против инструментов, чьи схемы, слои памяти и мультиагентная разводка должны быть инженерно построены, прежде чем циклу можно доверить что-либо реальное.

Почему существует эта глава

Stateless-модель, только принимающая текст и выдающая текст, — это калькулятор. Продакшен-работа требует превратить её в актора, преследующего цели через несколько шагов: вызови этот инструмент, затем тот, затем реши, какой из результатов резюмировать пользователю, и остановись, когда задача решена. На диаграмме этот ход выглядит просто, в реальности — нет. Агенты блуждают, зацикливаются, вызывают не тот инструмент, придумывают аргументы, которые инструмент принять не может, забывают, что уже подтянули, и действуют за пределами своих полномочий. Глава 4 — про инженерию, которая держит цикл читаемым и ограниченным: про схемы, про дисциплину памяти и про мультиагентную структуру, которая превращает правдоподобно выглядящее демо в продакшен-актора.

4.1 Архитектуры агентов как композиция, а не выбор

Базовый цикл — ReAct: рассудить о ситуации, сделать (вызвать инструмент), пронаблюдать результат и повторять, пока цель не достигнута или бюджет шагов не исчерпан. Продакшен-системы затем компонуют три надстройки поверх базы, а не выбирают между ними. Нативный function calling — провайдер ограничивает аргументы инструментов JSON Schema на этапе декодирования — упрочняет I/O-контракт, так что циклу больше не приходится восстанавливаться после невалидных вызовов. Явное планирование в стиле Plan-and-Execute загружает план заранее для долгих горизонтов и перезапускает планировщик, только когда мир меняется. Workflow-оркестрация кодирует известные переходы задачи как граф и оставляет модели только внутрифазовые решения — форма, к которой сходятся большинство enterprise-развёртываний, потому что она отделяет познаваемое от того, что требует суждения. Reflection-циклы, мультимодельная маршрутизация по cost-tiered флоту и специалист-субагенты стоят рядом как дополнительные надстройки.

4.2 Механика вызова инструментов — схема есть контракт

У каждого инструмента есть схема, и схема — это контракт, который цикл обеспечивает для модели. Описания на уровне свойств — документация для модели, а не для человека-читателя; enum-ы закрывают пространство аргументов там, где домен это позволяет; ключи идемпотентности дают циклу ретраить вызов, не удваивая его эффект; структурированные retryable-ошибки дают модели корректно восстановиться, а не гадать. Инструменты должны быть минимальны — одна ясная работа на инструмент, — потому что толстый инструмент с десятью опциональными флагами — это инструмент, который модель ошибётся использовать. Инструмент ask_user заслуживает явного места в каталоге, чтобы у агента был легитимный путь эскалировать двусмысленность, а не выдумывать аргументы. Параллелизм безопасен, только когда инструменты декларируют независимость; цикл трактует декларированно-независимые инструменты как параллелизуемые, а всё остальное — как строго последовательное. Каждый реальный продакшен-инцидент, прослеженный до «агент сделал не то», разрешается в инструмент, чья схема не сказала, что означают её аргументы.

4.3 Три слоя памяти: краткосрочная, долгосрочная, семантическая

Агентам нужна память, потому что задача редко умещается в один ход. Краткосрочная память — это скользящее окно недавнего диалога с закреплёнными сообщениями, переживающими скольжение (системный промпт, текущая цель, текущий план), и периодическая суммаризация тех ходов, которые выпадают из окна. Долгосрочная память — векторный store курированных фактов, записываемых при подтверждении, а не при каждом наблюдении, и извлекаемых в нескольких точках цикла, а не только на старте. Семантическая память — граф знаний из троек для запросов, требующих структурной композиции, а не сходства: «кто кому подчиняется», «какие продукты в какой категории», отношения, которые векторный store сплющивает. Три слоя хранятся по-разному, потому что используются по-разному, и дисциплина — маршрутизировать записи и чтения в правильный слой, а не сваливать всё в один эмбеддинг-индекс.

Что подготавливает глава 4

Агенты и RAG оба производят стохастические трейсы. Пользователь жалуется, лог показывает сотню спанов по трём инструментам и восьми модельным вызовам, и команде надо решить: это регрессия retrieval, дрейф промпта, проблема схемы инструмента или агент корректно выбрал против сломавшейся downstream-системы? На этот вопрос нельзя ответить без дисциплины превращения трейсов в измеримые pass/fail-сигналы. Глава 5 — эта дисциплина: LLM-as-judge, RAG-триада, trajectory-тесты для агентов и непрерывный цикл, где продакшен-трейсы кормят eval-набор, гейтирующий следующий релиз.

Дальше — Глава 5: Оценка LLM-приложений. Дисциплина оценки, превращающая стохастические трейсы в pass/fail-сигналы, против которых команда может выпускать.