Работающий AI-агент получает задачу, обращается к данным, использует инструменты и корректирует действия по результатам их выполнения. Языковая модель определяет, как интерпретировать запрос и какой шаг выбрать. Для выполнения задачи ей требуется программное окружение, которое предоставляет информацию, исполняет операции и контролирует результат.
Архитектуру AI-агента удобно рассматривать через пять инженерных задач: подготовку контекста, управление циклом действий, маршрутизацию запросов, организацию среды исполнения и оценку качества. Разделение помогает определить, из чего складывается система и какую её часть следует улучшать при конкретной проблеме.
Слои работают совместно. Нумерация задаёт порядок разбора, а состав реализации зависит от задачи. Название Jev относится к конкретному продукту TypeSafe; в общей архитектуре этот раздел отвечает за классификацию и маршрутизацию запросов.
| Слой | За что отвечает |
|---|---|
| Context | Какие сведения получает модель перед очередным действием |
| Loop | Как выбирается следующий шаг и когда работа завершается |
| Jev / маршрутизация | Какие решения можно обработать отдельно от основного агента |
| Harness | В какой среде агент действует и какие полномочия имеет |
| Evals | Как измеряется качество работы и выявляются регрессии |
1. Context engineering: подготовка информации для модели
Контекст включает инструкции, историю диалога, найденные документы, описания инструментов и результаты предыдущих операций. От его состава зависит, на какие сведения модель сможет опереться при следующем действии.
Объём контекстного окна сам по себе не определяет качество ответа. В длинной истории полезная информация может соседствовать с устаревшими выводами, повторяющимися сообщениями и большими техническими выгрузками. Поэтому управление контекстом предполагает отбор информации на каждом шаге.
Практически это означает несколько решений:
- Постоянные инструкции содержат роль, ограничения и требования к результату.
- Документы и большие результаты вычислений хранятся во внешних источниках. Модель получает нужный фрагмент через доступный инструмент.
- В истории сохраняются существенные решения, текущая цель и незавершённые вопросы.
- Набор инструментов подбирается под задачу. Для большого каталога можно использовать поиск нужного инструмента вместо загрузки всех описаний сразу.
Ссылка на документ полезна только тогда, когда агент действительно может его открыть. Аналогично, краткое резюме истории должно сохранять ограничения и нерешённые вопросы, которые понадобятся дальше.
Отдельная задача — повторное использование неизменной части запроса через prompt caching. Например, в Claude API попадание в кэш требует точного совпадения соответствующего префикса. Постоянные инструкции и меняющиеся данные поэтому имеет смысл разделять. Экономию рассчитывают по условиям конкретного провайдера и фактической доле попаданий в кэш.
Для агента разработки хороший контекст — это описание ошибки, относящиеся к ней файлы, правила проекта и результаты тестов. Полная история репозитория обычно не нужна для каждого вызова.
2. Loop engineering: управление последовательностью действий
В заранее заданном процессе программа определяет порядок шагов. В агентном цикле модель выбирает следующий шаг после получения результата предыдущего. Это различие подробно описано в архитектурных рекомендациях Anthropic.
При исправлении ошибки агент может запустить тесты, изучить сообщение о сбое, открыть нужный файл, внести изменение и повторить проверку. Последовательность зависит от обнаруженной причины. Условия, при которых исправление считается завершённым, задаются заранее.
Для управляемого цикла нужны четыре элемента: конкретная цель, проверка результата, условия остановки и бюджет. Проверкой может служить тест, успешная сборка, сверка данных или подтверждённое состояние внешней системы. Фраза модели «готово» сама по себе такой проверкой не является.
Условия остановки охватывают успешное завершение, отсутствие прогресса и достижение лимита. Бюджет ограничивает число действий, время и расходы. Для незавершённой задачи предусматривают дальнейший путь: уточнение, фиксированную процедуру или передачу сотруднику.
Агентный цикл полезен там, где ход работы зависит от промежуточных результатов. Для известной последовательности операций разумно сохранить обычный программный процесс. В одной системе оба подхода могут сочетаться: стандартные случаи проходят по заданным правилам, а разбор исключений поручается агенту.
3. Jev engineering: классификация и маршрутизация
Часть работы системы состоит из узких решений: определить категорию обращения, выбрать обработчик или оценить сообщение по заданному критерию. Такие операции можно выделить в отдельный слой до запуска основного агента.
Один из инструментов для таких решений — Jev от TypeSafe. Согласно документации, модель принимает данные и вопросы с заданной формой ответа. Она поддерживает выбор из списка, оценку по шкале и численную оценку истинности утверждения. Результат возвращается в виде структурированных значений, которые использует программа.
Например, входящие запросы можно распределять между документацией, обработкой типовых вопросов и техническим разбором. Только последний маршрут требует агента, который последовательно изучает проблему и выбирает действия.
При этом корректный формат ответа не гарантирует правильную классификацию. Выбранная категория может быть допустимой и одновременно ошибочной. В анонсе Jev разработчик отдельно связывает показатель отсутствия ошибок формата с соответствием схеме.
Показатель confidence также требует проверки на собственных данных. У Jev он рассчитывается из распределения вероятностей для Choice и Score; отдельного confidence у Noul нет. Пороги маршрутизации подбирают с учётом измеренного качества и последствий ошибки.
Перед внедрением такой слой сравнивают с простыми правилами или обычным классификатором. Неуверенные и нетипичные запросы направляют на более подробный разбор. Jev — один из вариантов реализации; выбор инструмента должен подтверждаться результатами на задачах компании. Возможности продукта подробнее рассмотрены в отдельной статье Journal.
4. Harness engineering: среда исполнения и контроль доступа
Harness — программное окружение, в котором работает модель: инструменты, файловая система, правила проекта, изоляция, права доступа и проверки операций. Оно определяет, какие действия агент способен выполнить в реальности.
У этого окружения четыре основные задачи.
Изоляция. Агент работает в выделенной среде с ограниченным доступом к файлам, сети и данным. Для разработки это может быть контейнер с отдельной рабочей копией проекта и доступом только к тестовой базе.
Инструкции. Правила проекта, описания инструментов и примеры ожидаемого результата помогают выбирать действия. В репозитории такие правила можно хранить в AGENTS.md.
Проверки. Сборка, тесты, анализ типов и другие автоматические проверки дают обратную связь о выполненной работе. Журнал операций позволяет установить, что произошло до ошибки.
Полномочия. Доступ ограничивается необходимыми операциями. Подготовка изменения, его публикация и изменение производственных данных могут требовать разных прав.
Эти ограничения закрепляются в исполняющей системе. Инструкция в промпте не отменяет выданное учётной записи право записи. OWASP рекомендует минимизировать доступные функции и разрешения, проверять авторизацию вне модели и получать подтверждение для действий с существенными последствиями.
Среда нуждается в пересмотре при изменении модели и задач. Новые возможности могут упростить часть управляющей логики, но решение об изменении ограничений должно опираться на проверки.
5. Evals engineering: измерение качества
Evals — повторяемый набор задач и критериев оценки. Он позволяет сравнить версии агента после изменения модели, инструкций, инструментов или правил маршрутизации.
Проверки охватывают результат и существенные действия. Для агента разработки результатом будет исправленная ошибка при сохранении требуемого поведения программы. Отдельно можно проверить соблюдение границ доступа и обязательное согласование публикации. Детали пути не следует фиксировать без необходимости: разные корректные решения могут использовать разные последовательности шагов.
Начальный набор формируют из реальных задач и обнаруженных ошибок. Для каждого случая задают исходные данные, ожидаемый результат и способ проверки. Набор дополняют по мере появления новых сценариев.
Объективные условия удобно проверять программно. Для смысловой оценки можно привлекать другую модель, предварительно сопоставив её оценки с оценками специалистов. Такой подход описан в методике оценки агентов Anthropic.
Результаты рассматривают по отдельным категориям: общий показатель способен скрыть ухудшение критического сценария. Вместе с качеством отслеживают время выполнения, стоимость задачи и необходимость вмешательства сотрудника.
Как пять слоёв работают вместе
Рассмотрим условную задачу: устранить ошибку в веб-приложении. Маршрутизация определяет тип запроса и передаёт его агенту разработки. Контекст предоставляет описание сбоя, правила проекта и нужные файлы. Цикл действий связывает диагностику, правки и повторные тесты. Harness обеспечивает рабочую среду, инструменты и границы доступа. Evals позволяют проверить, сохраняет ли новая версия агента качество на наборе подобных задач.
Часть этих возможностей можно получить в готовой платформе. При выборе решения проверяют, насколько оно подходит для задач компании: какие источники данных и интеграции поддерживает, как ограничивает полномочия агента и позволяет оценивать результат.
Эта схема помогает локализовать проблему. Недостающие сведения требуют работы с контекстом. Повторяющиеся без результата действия — пересмотра цикла. Ошибочное распределение запросов — проверки маршрутизации. Избыточный доступ — изменения среды исполнения. Изменения качества после обновления выявляются сравнением результатов Evals.
Для обсуждения архитектуры AI-агента с LindenTech подготовьте одну рабочую задачу, используемые источники данных, разрешённые действия и пример приемлемого результата. На этой основе можно определить, какие части системы уже доступны и что необходимо разработать.