Архитектура агента: как модель начинает действовать

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

Модель — Brain. Инструменты — Hands. Между ними — слой, который позволяет модели выбирать и вызывать нужное действие. Модель решает, что сделать, инструмент выполняет действие. Разберём этот слой: tool use, function calling, MCP и memory.

Tool Use: модель решает, что вызвать

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

Зачем в продукте. Чтобы агент отвечал на основе реальных данных и мог инициировать действие. Вопрос «какой статус у заказа №1234» требует запроса к базе. Команда «отмени заказ №1234» требует вызова инструмента, который выполнит отмену.

Как устроен. Модель получает описание доступных инструментов. При запросе решает: отвечать напрямую или вызвать инструмент.

Частая путаница. Tool use путают с function calling. Tool use — концепция («модель может использовать инструменты»), function calling — механизм реализации.

Ограничение. Модель может ошибочно решить, что инструмент не нужен, или выбрать не тот. Точность зависит от качества описания инструментов.

Function Calling: механизм вызова

Что это. Механизм, с помощью которого модель возвращает структурированный вызов инструмента вместо свободного текста.

Зачем в продукте. Чтобы система надёжно распознала решение модели и выполнило его — без хрупкого парсинга свободного текста.

Как устроен. Разработчик описывает функции (имя, параметры). Модель возвращает JSON с вызовом. Система выполняет функцию и возвращает результат модели для финального ответа.

Частая путаница. Function calling — только формат вызова. Выполнение делает код вокруг модели. Модель формирует вызов и получает результат обратно.

Ограничение. Модель может сгенерировать невалидные аргументы. На стороне системы нужна валидация.

MCP: как стандартизировать подключение инструментов

Что это. Model Context Protocol — открытый стандарт, анонсированный Anthropic в ноябре 2024 года. Он определяет, как AI-приложение подключает инструменты и источники данных.

Зачем в продукте. MCP позволяет стандартизировать подключение инструментов и источников контекста, чтобы разные AI-приложения использовали их через единый интерфейс — без переписывания интеграции с нуля для каждой пары «инструмент — приложение».

Как устроен. MCP-сервер предоставляет tools (инструменты для вызова), resources (источники данных) и prompts (шаблоны запросов). AI-приложение подключается к серверу через единый протокол.

Частая путаница. Function calling задаёт, как модель вызывает функцию. MCP задаёт, как инструменты стандартно подключаются к приложению.

Ограничение. Стандарт относительно новый. Поддержка на стороне инструментов и приложений ещё формируется.

Memory: как сохранять состояние между шагами

Что это. Способность системы сохранять и использовать информацию между шагами или сессиями.

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

Как устроен. Два типа. Краткосрочная — контекст текущей сессии, передаётся в промпте. Долгосрочная — сохраняется между сессиями в базе данных или векторном хранилище.

Частая путаница. Memory путают с контекстным окном модели. Окно — лимит на объём текста за запрос. Memory — архитектурное решение о том, что из истории сохранять и передавать в это окно.

Ограничение. Долгосрочная память требует отдельной инфраструктуры. Чем больше история, тем важнее выбирать, что релевантно — это пересекается с retrieval из Блока 2.

Ловушки блока

Главная ошибка — путать tool use и function calling. Tool use означает, что модель понимает: ей нужен внешний инструмент. Function calling — конкретный механизм, которым модель сообщает об этом решении системе.

Tool use — это понимание необходимости внешнего инструмента. Function calling — способ передать это решение системе.

Метрики блока

Как понять, что архитектура агента работает:

• Success rate — доля задач, которые агент довёл до правильного результата.

• Tool call accuracy — насколько точно агент выбирает нужный инструмент и передаёт корректные параметры.

Замеряем на наборе тестовых задач: 50–100 реалистичных запросов, считаем долю успешных вызовов и долю задач, доведённых до конца без ошибок. На success rate влияют точность выбора инструмента, исполнение самого инструмента, бизнес-логика, данные, права доступа и ошибки API.

Как координировать несколько агентов

Один агент с доступом к инструментам и памяти решает конкретные задачи. Но сложные процессы редко укладываются в одного агента — обработка заявки может требовать проверки данных, согласования и уведомления клиента как отдельных шагов, возможно, разными агентами. В следующем посте разберём, как координировать нескольких агентов: workflow, multi-agent, supervisor и human-in-the-loop.