За состояние задачи между независимыми вызовами, доступ к CRM и базам данных, безопасный повтор API-вызовов и проверку результата отвечает приложение.
Программный слой, который связывает модель с данными и инструментами и контролирует выполнение задачи, называют agent harness. Он собирает контекст, хранит состояние, применяет ограничения и фиксирует ход запуска. Модель выполняет содержательную часть задачи: интерпретирует запрос, анализирует данные, формирует результат и определяет необходимые действия. Harness обеспечивает их управляемое выполнение внутри корпоративной системы.
Процесс не заканчивается вызовом модели
Допустим, агент готовит договор с новым контрагентом. Модель анализирует задачу, выбирает шаблон и определяет, каких реквизитов не хватает. Приложение предоставляет доступ к документам, вызывает корпоративные сервисы и сохраняет полученные данные.
Каждый вызов LLM работает только с теми данными, которые передало приложение. Ожидание внешнего события, сохранение состояния задачи и запуск следующего вызова остаются на стороне приложения.
Агент проверил реквизиты и отправил договор юристу. Ответ пришёл на следующий день, а сервис агента за это время перезапустился. Чтобы продолжить процесс, системе нужно знать, какой договор обрабатывается, какие проверки уже выполнены, кому отправлен документ и какого события она ждёт.
Восстанавливать всё это из длинной истории сообщений ненадёжно. Состояние хранят отдельно — например, в базе данных или workflow-движке. Следующий вызов модели получает только сведения, необходимые для текущего решения.
Здесь легко смешать три сущности:
-
Контекст — данные, переданные в текущий вызов модели.
-
Состояние — положение конкретной задачи в процессе.
-
Память — сведения из прошлых взаимодействий, которые могут понадобиться в следующих задачах.
Если помещать всю историю в контекст, актуальные данные начинают конкурировать со старыми сообщениями. Растёт стоимость обращения к модели, а уже неактуальные сведения продолжают влиять на новые решения.
Сохранять всё подряд тоже не нужно. Harness фиксирует состояние процесса и собирает контекст для следующего шага. Долговременная память остаётся отдельным контуром со своими правилами записи, обновления и доступа.
API нужно адаптировать для модели
Следующий шаг часто требует обращения к документам, CRM, базе данных или внутреннему сервису. Агент взаимодействует с ними через инструменты — описанные операции с заданным набором параметров. За этим интерфейсом приложение передаёт учётные данные, проверяет аргументы, обрабатывает тайм-ауты и приводит ответ API к понятной структуре.
Качество интерфейса влияет на поведение агента. Похожие названия затрудняют выбор инструмента, а длинный неструктурированный ответ занимает контекст и заставляет модель самостоятельно искать значимые данные. В материале Writing effective tools for AI agents Anthropic рекомендует проектировать инструменты вокруг понятных сценариев, возвращать модели только полезный контекст и тестировать их на реальных задачах.
Повторять вызов тоже можно не всегда. Поиск обычно безопасно выполнить ещё раз, а повторная отправка письма или создание заявки могут привести к дублю. Для операций с побочными эффектами используют ключи идемпотентности, проверку текущего состояния или журнал выполненных действий.
Право на действие проверяется отдельно
MCP стандартизирует подключение ИИ-приложений к инструментам и источникам данных. Но MCP-подключение само по себе не заменяет корпоративную авторизацию и контроль исполнения. Приложение и целевая система по-прежнему определяют, кому доступна конкретная операция и как обрабатывать её результат.
Промпт может повлиять на решение модели, но не запрещает действие технически. Поэтому право на вызов инструмента проверяют независимо от ответа LLM. Целевая система также не должна полагаться на то, что модель правильно поняла и выполнила инструкцию.
Способ контроля зависит от риска операции:
-
Агенту предоставляют только необходимые функции и данные.
-
Код выполняют в изолированной среде с ограничениями на сеть, файлы, ресурсы и время.
-
Для запуска задают предел количества шагов и повторов.
-
Платёж, публикацию или удаление данных приостанавливают до подтверждения человеком.
Human-in-the-loop не сводится к кнопке «подтвердить». Сотруднику показывают операцию, её параметры и ожидаемый эффект. После решения продолжается тот же запуск с сохранённым состоянием. Такой механизм паузы и возобновления описан в руководстве OpenAI Guardrails and human review.
Выполненное действие ещё не означает решённую задачу
Успешный ответ API подтверждает только техническое выполнение запроса. Агент при этом мог выбрать неправильный фильтр, взять устаревший документ или сформировать файл не по шаблону. Поэтому результат нельзя принимать только на основании ответа инструмента или решения той же LLM, которая выполняла задачу.
Там, где результат можно формализовать, его проверяют кодом. Для заявки контролируют обязательные поля, для файла — формат и структуру, для изменения записи — фактическое состояние после операции, для программного кода — прохождение тестов.
Модель-оценщик пригодится, если точное правило написать трудно: например, для проверки полноты объяснения или противоречий между текстом и источниками. Такая оценка остаётся вероятностной и дополняет детерминированные проверки, а не заменяет их.
По результатам проверки harness завершает задачу, возвращает модели описание ошибки, повторяет отдельный шаг или передаёт случай человеку. Условия остановки задают заранее, иначе агент может принять неверный результат или попасть в цикл.
Агента оценивают по выполненной задаче
Качество финального ответа — только один из показателей работы агента. Для владельца продукта также важны доля успешно завершённых задач, частота нежелательных повторных операций и вмешательств человека, стоимость успешного выполнения.
Для анализа этих показателей нужна трассировка: история обращений к модели, вызовов инструментов, проверок и ошибок. Она позволяет понять, где произошел сбой — модель выбрала неподходящий инструмент, внешний сервис вернул неполные данные или harness собрал неверный контекст. Такой подход к наблюдаемости описан в руководстве OpenAI Integrations and observability.
Несколько агентов меняют архитектуру
Первого агента обычно собирают под один сценарий, а состояние, инструменты, авторизацию и обработку ошибок реализуют внутри его приложения. Выделять для этого отдельную платформу необязательно.
С каждым новым агентом команде снова нужны доступ к моделям, сервисные учётные записи, инструменты, журналирование и правила авторизации. Постепенно появляются несколько способов подключения к одной CRM, разные форматы логов и разная обработка одинаковых ошибок.
Компания начинает поддерживать несколько реализаций одного служебного слоя. Изменение политики доступа приходится переносить в каждый сервис, а новый инструмент — подключать к нескольким агентам отдельно.
Часть harness в таком случае имеет смысл вынести в общую инфраструктуру. Сценарии сохраняют собственные инструкции, структуру состояния и бизнес-правила, а инструменты, учётные данные и базовые ограничения переиспользуются.
Общий слой можно собрать из open-source-компонентов и собственных сервисов или использовать готовую платформу. Самостоятельная сборка сохраняет контроль над архитектурой, но оставляет команде ответственность за обновления, совместимость, безопасность и эксплуатацию. Готовая платформа сокращает объём этой работы, хотя задаёт свои рамки интеграции и развёртывания: в PWS к такому слою относятся управление правами и сервисными учётными записями, ведение логов и каталог MCP-инструментов. Состояние конкретной задачи, проверка результата, обработка повторов и бизнес-логика остаются в приложении или workflow-движке.
Решение об общем слое зависит не от количества агентов само по себе. Он оправдан, когда поддержка повторяющихся интеграций и правил обходится компании дороже, чем эксплуатация общей инфраструктуры.
