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

ИИ-агент — это программа, которая получает цель, сама выбирает последовательность шагов, выполняет их во внешней среде и проверяет результат. Ключевых слов здесь два: «сама выбирает» и «во внешней среде». Если шаги жёстко заданы разработчиком, это не агент, а обычный сценарий автоматизации — пусть даже внутри вызывается языковая модель.

Почему это стало возможно именно сейчас

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

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

Из чего состоит агент

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

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

Модель

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

Инструменты

Инструмент — обычная функция с описанием: «получить список документов за период», «найти контрагента по ИНН», «сформировать отчёт». Чем уже и понятнее инструмент, тем предсказуемее поведение агента. Универсальный «выполни любой SQL» — худший из возможных инструментов: он даёт модели слишком много свободы и слишком мало гарантий.

Память

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

Права и правила

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

Цикл работы: пять шагов, которые повторяются

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

1. Задача. Формулируется цель и критерий готовности: не «посмотри документы», а «найди расхождения между актами и учётной системой и перечисли их».
2. План. Модель разбивает цель на шаги и решает, какие инструменты понадобятся.
3. Действие. Вызывается инструмент с конкретными аргументами: запрос, файл, команда.
4. Наблюдение. Результат возвращается в контекст — и модель оценивает, приблизился ли он к цели.
5. Коррекция. Если результат не тот, план меняется: другой запрос, другой инструмент, уточнение у человека.

Именно пятый шаг отличает агента от скрипта. Скрипт выполняет инструкцию и падает с ошибкой; агент — замечает, что ошибся, и пробует иначе. Но у этой гибкости есть цена: каждый цикл — это токены, время и новый шанс уйти не туда.

Пример: сверка актов в бухгалтерии

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

Цель. «Сверь акты за сентябрь с учётной системой. Верни список расхождений: номер, контрагент, сумма в акте, сумма в учёте, характер расхождения. Ничего не меняй».

Инструменты. Чтение папки с актами, доступ к учётной системе только на чтение, сопоставление по номеру и сумме, запись результата в таблицу. Ни одного инструмента, который что-то изменяет, — это принципиально.

Цикл. Агент получает список файлов, выгружает записи из учёта, сопоставляет, находит несовпадения и формирует таблицу. Если документ не распознан — не угадывает, а помечает как «требует проверки». Если расхождений больше заданного порога — останавливается и спрашивает человека.

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

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

Виды агентов — и важное различие

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

Отдельно стоит сказать про workflow. Многие системы, которые называют агентными, на самом деле — жёстко заданные сценарии с вызовом модели на отдельных шагах. Это не плохо: для регламентированных процессов workflow надёжнее и дешевле. Агент нужен там, где заранее неизвестно, сколько шагов потребуется и какие инструменты понадобятся. Если ответ известен заранее — не усложняйте.

Где это уже работает в финансах и учёте

Агенты дают выигрыш не там, где «нужен интеллект», а там, где много однотипной работы с проверяемым результатом.

• Сверки. Акты, накладные, платежи, остатки — сопоставление по правилам и список расхождений.
• Разбор первички. Извлечение реквизитов из PDF и сканов, проверка на полноту, раскладка по папкам.
• Подготовка ответов. Сборка пакета документов по требованию, черновик пояснения, проверка комплектности.
• Мониторинг изменений. Отслеживание публикаций, сроков, статусов — с уведомлением человека.
• Черновики отчётов. Сбор цифр и формулировок; финальную проверку и подпись оставляет специалист.

Общий признак: результат можно проверить — сравнить с эталоном, правилом или другим источником. Там, где проверки нет, агент приносит не пользу, а уверенность в непроверенном.

Где агенты ломаются

Поломки у агентов однотипные. Если знать их заранее, половину можно предотвратить на этапе проектирования.

Как сделать агента надёжным

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

• Минимальные права по умолчанию. Чтение — да, запись — только через подтверждение. Опасные операции запрещены на уровне инструмента.
• Лимиты. Максимум шагов, времени и стоимости на одну задачу. Исчерпал — остановился и доложил.
• Логи и трассировка. Каждый вызов инструмента, аргументы и результат сохраняются. Без этого инциденты не разбираются.
• Тесты на реальных кейсах. Набор задач с известными ответами; после каждого изменения проверяем, что агент не стал хуже.
• Человек в контуре. Необратимые действия — только после подтверждения. Это не недоверие, а разумная осторожность.
• Идемпотентность. Повторный запуск не должен создавать дубли: операции проектируются так, чтобы их можно было безопасно повторить.

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

Локально или в облаке

Для агента это не столько вопрос вкуса, сколько вопрос данных и стоимости. Облачные модели сильнее в сложных рассуждениях и проще в запуске; локальные — предсказуемы по цене и не отправляют документы наружу.

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

Про локальный запуск у меня есть практические разборы: OpenCode и бесплатные модели, DeepSeek Harness, платформа GAIA на Ryzen AI и сборка агента на NPU AMD XDNA2. Там же — про то, что реально работает на домашнем железе, а что остаётся обещанием.

Частые вопросы

Материал носит методический характер и описывает общие принципы. Конкретные настройки доступов и обработки данных зависят от вашей учётной системы и требований безопасности.