Архитектура ИИ-агента: модель, инструменты и управление
Архитектура ИИ-агента — организация модели, инструкций, инструментов, состояния и контроллера, которая превращает запрос в последовательность действий. Она определяет, как наблюдения влияют на следующее решение, где проверяются права, как фиксируются ошибки и при каких условиях работа заканчивается либо приостанавливается.
Этот урок пригодится, если схема агента кажется понятной, но вы не можете объяснить, кто действительно запускает инструмент. Проследим поиск урока от запроса пользователя до проверенного ответа и выделим решения, которые должны принимать компоненты программы.
Главные идеи
- Отделяйте предложение действия от его выполнения.
- Сохраняйте наблюдения вместе с источником и статусом.
- Проверяйте входные данные там, где операция действительно исполняется.
- Различайте завершение, ошибку и прерывание.
Пять компонентов с разными обязанностями
Инструкции задают желаемую работу и границы. Модель предлагает следующее действие. Инструменты выполняют определённые операции. Состояние хранит произошедшее. Контроллер соединяет компоненты и решает, продолжать ли работу. Разделение помогает при отладке: проблема возникла из-за неясной цели, неправильного предложения, недоступного инструмента или проверки, принявшей неподтверждённый ответ? Изменение промпта не исправляет все эти причины. Сначала определите место сбоя, затем меняйте соответствующую часть системы.
Проследите один запрос к каталогу
Учащийся просит вводный урок об ИИ. Приложение создаёт состояние с целью и пустым списком наблюдений. Планировщик предлагает поиск по ключу 'ai'. Контроллер проверяет название инструмента и форму аргументов, затем выполняет поиск. Он сохраняет запись и статус обращения. Следующее предложение использует наблюдение для завершения. Финальная проверка подтверждает, что ответ ссылается на полученную запись, а не на сгенерированное название курса. Каждый переход должен оставлять понятное свидетельство произошедшего.
- 1Цель
- 2Предложенное действие
- 3Проверка
- 4Вызов инструмента
- 5Наблюдение
- 6Следующее решение
Состояние шире истории разговора
Журнал сообщений помогает восстановить сказанное, но рабочему состоянию также нужны оставшийся бюджет, завершённые операции и ожидающие решения. Сохраняйте идентификатор найденной записи вместо копирования всей базы в каждый запрос модели. Состояние должно быть достаточно небольшим для проверки и достаточно явным для продолжения. Если запуск остановлен перед человеческой проверкой, статус остаётся ожидающим. После перезапуска процесса он не должен незаметно превращаться в успешное завершение.
Размещайте проверки на границе исполнения
Промпт 'используй только поиск по каталогу' описывает правило. Исполняющая функция, отклоняющая остальные инструменты, обеспечивает его выполнение. Аналогично проверяйте типы аргументов, область доступа и повторные действия. Возвращённая ошибка должна оставаться ошибкой в состоянии. Для операций, меняющих внешнюю систему, определите, как распознать уже выполненное действие перед повтором. Иначе восстановление после обрыва соединения способно повторить изменение, которое успело успешно завершиться.
Спроектируйте наблюдаемый цикл
Выберите явные переходы: готовность, запрос инструмента, сохранение наблюдения, ожидание проверки, завершение и остановка. Добавляйте состояния, используемые упражнением, и объясняйте выход из каждого. Сохраняйте сведения об операциях и результатах без лишних персональных данных. В более крупной системе среда оркестрации помогает хранить состояние и управлять прерываниями. Сначала разберитесь в самом цикле: фреймворк может его организовать, но критерий приемлемого результата для вашей задачи задаёте вы.
Простыми словами
Представьте небольшую мастерскую. Модель предлагает следующую работу, инструменты выполняют операции, блокнот хранит результаты, а руководитель проверяет разрешения и продвижение. Архитектура — устройство, в котором каждая часть выполняет свою обязанность.
Попробуйте сами
Нарисуйте запрос, проходящий пять блоков: цель, предложение, проверка, поиск и наблюдение. Добавьте точку, где отсутствие записи запрещает выдумывать урок. Отметьте блоки, способные изменять данные.
Ожидаемый результат
Схема с исполнением и проверками вне модели, сохранением статуса поиска и явным исходом: работа завершена либо остановлена.
Проверьте себя: Где нужно отклонять запрос запрещённого инструмента?
На границе исполнения до запуска инструмента. Одни инструкции не обеспечивают эту границу.
Вопросы и ответы
Модель и есть контроллер?
Модель может выбирать предложенное действие, но программа получает предложение, проверяет его и вызывает настоящий инструмент. Разделение делает права и ограничения проверяемыми. В конкретном продукте компоненты могут быть объединены, поэтому изучайте путь выполнения операции, а не только подписи на схеме.
Сначала нужен фреймворк оркестрации?
Небольшой цикл можно изучить на обычном коде. Фреймворк полезен, когда требуются хранение состояния, продолжение после остановки или явные переходы графа. Сопоставьте эти потребности с документацией и проверьте сценарий ошибки до использования решения в более крупном проекте.
Проследите один запрос через всю систему. До добавления функций явно обозначьте исполнение, наблюдение и финальную проверку.
Источники и дальнейшее чтение
- Anthropic — Building effective agents ↗Источники проверены:
- LangChain — LangGraph overview ↗Источники проверены:
- Yao et al. — ReAct: Synergizing Reasoning and Acting in Language Models ↗Источники проверены: