Agent Loop: почему одного вызова инструментов уже недостаточно для корпоративного AI-агента

В последние два года разговор об AI-агентах почти везде начинается одинаково. Берётся большая языковая модель, к ней подключаются инструменты — поиск, CRM, почта, база знаний, API — и дальше предполагается, что модель сможет сама выбрать нужный инструмент, вызвать его и на этом решить задачу.

На демо это часто выглядит убедительно. Пользователь задаёт вопрос, модель делает один-два вызова, получает данные и формирует ответ. Кажется, что этого уже достаточно, чтобы говорить об agentic-сценариях. Но как только AI попадает не в лабораторную среду, а в реальный корпоративный контур, довольно быстро выясняется, что одного вызова инструмента по MCP недостаточно.

Проблема в том, что рабочая задача почти никогда не сводится к одному вызову функции. Нужно понять намерение пользователя, решить, каких данных не хватает, выбрать следующий шаг, проверить результат предыдущего шага, при необходимости скорректировать план, не уйти в ложную ветку, не повторяться, не отвечать без источников, соблюсти ограничения безопасности и только потом собрать ответ.

Иными словами, между «модель умеет вызвать инструмент» и «получился надёжный корпоративный агент» лежит отдельный инженерный слой. 

Меня зовут Денис Селезнёв, я генеральный директор «Первой Формы» — российской BPM-платформы для автоматизации бизнес-процессов в крупных компаниях. В этой статье я расскажу, почему tool calling сам по себе не делает ИИ корпоративным агентом, как эту проблему решает наш подход Agent Loop и как этот цикл устроен в реальной enterprise-среде.

Почему обычный вызов инструмента быстро упирается в потолок

Если смотреть на задачу упрощённо, инструмент решает довольно понятную проблему: модель может не только генерировать текст, но и обращаться к внешнему миру. Например, получить карточку задачи, прочитать файл, найти документ в базе знаний или создать комментарий.

Это важный шаг, и мы в «Первой Форме» его тоже прошли, об этом рассказали в этой статье. Но сам по себе он ещё не отвечает на главный вопрос: кто управляет процессом рассуждения и выполнения?

Если модель просто получила список инструментов и право их вызывать, это не означает, что она:

• корректно определит, когда инструмент вообще нужен;

• не начнёт дёргать лишние источники;

• сумеет построить цепочку из нескольких шагов;

• поймёт, что предыдущий результат недостаточен;

• остановится вовремя, если данных не хватает;

• не начнёт «додумывать» ответ там, где нужен факт из системы.

На простых вопросах это может быть незаметно. Но в enterprise-контуре проблемы становятся системными очень быстро.

Например, пользователь спрашивает: «Что у нас с клиентом X?» Формально модель может вызвать один поиск по CRM и что-то ответить. Но реальный качественный ответ требует маршрута: найти карточку клиента, поднять сделки, встречи, звонки, договоры, понять хронологию, отделить факты от интерпретации, не спутать похожие названия, не упустить открытые риски. Это уже управляемый цикл, который при обычных обстоятельствах проходил бы человек, возможно, аналитик.

Именно здесь становится видно главное различие: вызов инструмента — это механизм доступа к возможностям, а Agent Loop — это механизм управления работой агента.

Что такое Agent Loop и чем он отличается от вызова инструмента

Если коротко, Agent Loop — это управляемый цикл, в котором модель не просто умеет вызывать инструменты, а последовательно проходит через шаги понимания задачи, выбора действия, выполнения, проверки результата, следующего шага и остановки. Это и есть тот слой, который превращает набор «LLM + инструменты» в рабочего агента. Он отвечает на вопрос «Как агент принимает решения на протяжении всей сессии».

В простейшем виде цикл выглядит так:

1. Пользователь формулирует запрос.

2. Агент определяет, можно ли ответить сразу или нужны внешние данные.

3. Если данные нужны — выбирает инструмент и делает один следующий шаг.

4. Получив результат, оценивает: этого уже достаточно или нужен ещё один шаг.

5. При необходимости перестраивает план.

6. Повторяет цикл, пока не достигнет условия остановки.

7. Формирует финальный ответ с опорой на найденные данные и с учётом правил среды.

На словах это выглядит почти очевидно. Но именно здесь и начинается основная инженерная работа. Потому что в реальной системе цикл должен отвечать не только за «думать дальше», но и за много других вещей: какие инструменты и как выбирать, какой источник читать, нужно ли честно признаться, что ответа нет, как не совершить ошибки, как сохранить весь путь принятия решения.

То есть Agent Loop — это полноценная оркестрация поведения агента в прикладной среде. Разница с вызовом инструмента примерно такая же, как между наличием системных вызовов у программы и наличием полноценного runtime. Первое даёт доступ к операциям, второе управляет их жизненным циклом, ограничениями, порядком и условиями завершения.

Что именно делает Agent Loop в реальной системе

На практике у агента почти никогда нет одного линейного маршрута. Он работает в среде, где есть несколько источников данных, разные типы задач, роли пользователей, правила маршрутизации и ограничения на действия.

Объясню на примере Анфисы — корпоративного ассистента, который работает внутри процесса «Первой Формы». Пользователь задаёт вопрос в комментарии задачи, а дальше агент уже внутри платформы решает, что делать дальше. Вся логика работает в Jint — JavaScript-движке для .NET, без отдельной внешней среды запуска. Оркестратор — это agent-loop.js, вокруг него архитектура из десятков модулей и набор инструментов для документов, кода, задач, файлов, почты, календаря, конфигурации и действий в системе.

Это важно, потому что Agent Loop здесь — не абстрактный паттерн поиска, а реальный слой исполнения. В таком контуре цикл отвечает как минимум за шесть вещей.

Маршрутизация. Один и тот же вопрос можно вести по-разному. Если пользователь спрашивает о платформенной логике, нельзя отвечать «из головы» — сначала нужен поиск по документации или коду. Если вопрос про клиента в CRM, маршрут будет другой: карточка клиента, сделки, встречи, договоры. И так для каждой процессной зоны.

Дисциплина использования инструментов. В enterprise-системе важно не просто «что-то найти», а сделать это правильным способом. Если есть специализированный инструмент, нужно использовать его, а не собирать ответ из пяти косвенных вызовов. Если нужен полный объект настройки, нельзя ограничиться краткой сводкой. Если пользователь приложил файл, агент должен его реально прочитать, а не сказать, что «файл недоступен».

Многошаговое уточнение. Ответ часто строится не из одного источника. Агент делает шаг, получает частичный результат, видит недостающее звено, делает следующий шаг и так далее. Это особенно важно там, где сама постановка вопроса задаёт только домен, а не конкретную точку фикса. Например, тикет про checkbox может вести не в leaf-компонент, а в контейнер, сервис или API-слой.

Условия остановки. Без этого любой агент быстро деградирует либо в бесконечный поиск, либо в галлюцинации под давлением необходимости ответить. Поэтому в цикле должны быть лимиты на число шагов, правила остановки при повторяющихся ошибках, ограничения на расширение рамок и явное требование не выдумывать факты, если инструмент их не вернул.

Разделение режимов чтения и действия. Одно дело — найти информацию, другое — создать комментарий, перевести задачу, отправить письмо, обновить поле. В корпоративной среде это разные классы операций, и цикл должен различать их не как «ещё один инструмент», а как отдельный тип ответственности с собственными правилами.

Синтез ответа. После всех шагов агенту всё равно нужно сделать последнюю работу: собрать понятный ответ для человека, не потеряв факты, не расширив вывод за пределы найденного и не смешав уверенное знание с догадкой.

Вот этот набор обязанностей и делает Agent Loop ключевым слоем всей системы.

Из чего состоит Agent Loop в enterprise-контуре

Если посмотреть на него не как на идею, а как на инженерную конструкцию, то внутри Agent Loop обычно есть несколько обязательных компонентов.

1. Входной контекст. Агент получает не просто фразу пользователя, а окружение: задачу, категорию, историю комментариев, профиль автора, предметную область, иногда файлы. Это резко меняет качество решений, потому что вопрос «посмотри, что тут сломалось» без контекста и тот же вопрос внутри конкретного тикета — это две разные задачи.

2. Политики. Это слой правил, который заранее задаёт, как агент должен себя вести: что можно отвечать только после вызова инструмента, какие инструменты обязательны для определённых типов запросов, что использовать в первую очередь и так далее.

3. Планнер на каждом шаге. Не обязательно в виде отдельного явного модуля, но по сути цикл постоянно решает один и тот же вопрос: какой следующий шаг самый дешёвый и самый информативный. Это важный момент: хороший Agent Loop не просто «ищет до победы», а экономит шаги и старается сначала сделать дешёвую проверку гипотезы.

4. Слой исполнения. Это набор инструментов и адаптеров к системам. В случае Анфисы это документы, кодовые репозитории, платформа, конфигурация, задачи, файлы, календарь, почта, внешняя сеть и другие специализированные контуры.

5. Оценщик. После каждого шага нужно понять, приблизил ли результат к ответу. Достаточно ли данных? Есть ли противоречие? Нужен ли следующий вызов? Эта микрологика не даёт циклу вырождаться в набор случайных действий.

6. Жёсткие условия остановки. К ним относятся лимит шагов, прекращение после одинаковой ошибки, остановка после нескольких безрезультатных гипотез, запрет на неподтверждённые факты.

7. Пост-процессинг. Финальная сборка ответа, проверка groundedness, оформление ссылок на источники, иногда автодополнение evidence и редактура результата перед публикацией.

Когда эти компоненты собраны вместе, появляется уже не «LLM с функциями», а рабочий агентный runtime.

Почему без Agent Loop корпоративный агент становится ненадёжным

Есть соблазн думать, что всё это — избыточная инженерия, а хорошая модель и так сможет принять правильные решения. На практике это не так.

В корпоративной среде у агента всегда есть три класса риска. Он может пойти не туда, ответить по неполному контексту или выдать за правдоподобный ответ недостоверную информацию, что в случае enterprise-среды разрушает доверие к системе целиком.

Именно поэтому Agent Loop как полноценный процессный слой нужен не как «умный бонус», а для управляемой надёжности. Из этого следует довольно простой, но важный вывод: если в системе есть только модель и инструменты, то центр тяжести остаётся в самой модели. Предполагается, что она сама правильно решит, как себя вести. С Agent Loop часть ответственности переносится из модели в инфраструктуру агента, и это даёт несколько очень практических эффектов.

1. Поведение становится более предсказуемым: для такого типа вопроса — такой порядок действий, для такого источника — такой инструмент, для такого риска — такое состояние остановки.

2. Можно разбирать не только финальный ответ, но и траекторию: какой шаг был выбран, какой инструмент вызван, где было потеряно качество, где цикл пошёл не по той ветке.

3. Систему проще развивать. Новый инструмент становится узлом в маршрутизации, правила влекут изменения в политики, а домены превращаются в новые карты поведения, а не попытки надеяться, что модель сама догадается.

4. Появляется возможность строить гибридную архитектуру, где часть решений принимает модель, а часть — жёстко задана средой. И для enterprise это обычно гораздо реалистичнее, чем мечта о полностью автономном агенте «общего назначения».

Почему Agent Loop стал особенно важен именно сейчас

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

Именно поэтому разговор об Agent Loop сегодня важен не только для AI-исследований, но и для прикладной корпоративной архитектуры. Вопрос уже не в том, может ли модель вызвать инструмент, а в том, можно ли на её базе построить систему, которая будет предсказуемо работать в бизнес-процессе, не ломаться при усложнении контекста и не терять доверие после нескольких неверных ответов.

Для этого tool calling нужен, но его недостаточно. Нужен слой, который превращает доступ к инструментам в управляемую работу. И именно этот слой, скорее всего, и станет одной из главных архитектурных тем ближайших лет в enterprise AI.