AI-агент – это не промпт: 5 слоёв рабочего агента для руководителей

«Большинство людей до сих пор думают, что AI-агент – это просто ChatGPT с хорошим промптом». С этой фразы начинается статья Sunil Ramlochan «The AI Agent Stack Is Not a Prompt. It’s a Production System», и дальше автор называет это убеждение «утешительным мифом». Полезная правда, по его словам, в другом: настоящий агент ближе к маленькой операционной системе для работы. У него есть мозг, руки, память, правила, логи, планы восстановления и кто-то, кто отвечает, когда агент делает не то.

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

Сразу уберём главную путаницу, ту самую, с которой спорит автор. «Агент» работает принципиально иначе, чем чат-интерфейс: промпт даёт один вопрос и один ответ. Агент получает цель и работает в цикле: понимает задачу, решает, что делать дальше, выбирает инструмент, использует его, смотрит на результат, осмысляет, что произошло, и продолжает, останавливается или зовёт человека. Статья честно отсылает к гайду OpenAI по построению агентов, где агент определяется как система из моделей, инструментов, инструкций и ограничений. Этот цикл и отличает агента от привычной автоматизации: агент не отвечает одной репликой, он доводит дело до конца.

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

Слой 1: модель – мозг, но не всё тело

Модель – это часть, которая рассуждает, планирует и пишет. Ей достаётся всё внимание, потому что она выглядит магией: сильнее модель – лучше рассуждения, меньше явных ошибок. Но автор формулирует жёстко: в продакшене модель часто не самая сложная часть.

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

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

Слой 2: инструменты – руки агента и его главный риск

Инструменты – это то, чем агент действует во внешнем мире: поиск, API, базы данных, почта, календари, выполнение кода, файлы, платёжные системы, внутренние бизнес-приложения. Именно здесь, пишет автор, агент перестаёт быть генератором текста и становится исполнителем. И именно здесь резко растёт «радиус поражения». Это ровно тот переход, который три года назад привёл к тренду BYOA – Bring Your Own Agent: как только инструмент получает доступ к реальным системам, организационные вопросы начинают опережать технические.

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

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

Любопытно, что всё это – про инструменты, права, схемы подтверждения – звучит как разговор об архитектуре. Но под архитектурой лежит кое-что попроще: умение внятно сформулировать, что агент должен делать, в каком контексте и при каких ограничениях. Без этой формулировки даже хорошо написанный агент начинает «додумывать» – и именно тогда инструменты становятся опасными.

Слой 3: память – блокнот, который становится обузой

«Память звучит просто. Пусть агент запоминает полезное. Легко, да? Не совсем», – пишет автор. Память бывает четырёх видов: краткосрочная (что происходит в текущей задаче), сессионная (что было в текущем разговоре), долгосрочная смысловая (знания, которые переиспользуются во времени) и транзакционная (состояние, которое обязано быть точным: заказы, статусы, права, согласования).

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

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

Слой 4: рантайм – где «мышление» превращается в цикл

В центре стека – рантайм агента, тот самый цикл: понять цель, решить, что делать дальше, выбрать инструмент, использовать его, оценить результат, осмыслить и продолжить, остановиться или попросить помощи. Автор связывает этот паттерн с подходом ReAct (reasoning and acting) и подчёркивает простую вещь: агент не просто отвечает, он работает.

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

Вот это переворачивает рамку. «Описать процесс с состоянием и контрольными точками» – это ровно та работа, которую менеджер делает, когда строит регламент или ставит задачу команде. Цикл агента подозрительно похож на то, как работает живой сотрудник: получил задачу, прикинул шаги, что-то сделал, посмотрел на результат, скорректировался. Разница в том, что у сотрудника есть здравый смысл и страх ошибиться, а у агента – только те ограничения, которые вы заранее в него заложили.

Слой 5: наблюдаемость, безопасность и управление – разница между демо и системой, которой можно доверять

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

Но дальше идёт самое важное различие, и оно сугубо управленческое. «Наблюдаемость говорит вам, что произошло. Управление решает, чему вообще позволено произойти». Дашборд покажет, что агент собирается сделать что-то рискованное. Управление определяет, кто может его остановить, при каком условии и кто владеет этим решением. Автор прямо ссылается на классификацию рисков из OWASP Top 10 для LLM (где prompt injection назван крупной угрозой) и на NIST AI Risk Management Framework как на ориентиры.

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

Самое слабое место: швы между слоями

Здесь статья делает поворот, который легко пропустить, а зря. Автор пишет, что самое трудное в стеке агента – это, возможно, соединительная ткань между слоями, а вовсе не какой-то один отдельный слой. Рантайм выбирает инструмент, инструмент меняет бизнес-состояние, слой памяти сохраняет результат, модель интерпретирует его, слой наблюдаемости логирует решение, слой безопасности решает, разрешить ли следующий шаг. Если хоть одна из этих передач описана нечётко, вся система становится хрупкой.

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

Для менеджера эта картина с передачами между слоями подозрительно знакома. Размывается ответственность, теряется контекст при передаче, растут накладные расходы на координацию – это проблемы любой живой команды, где задача идёт по рукам. Поэтому решение «один агент или несколько» автор и гайд OpenAI советуют принимать так же, как вы решаете, нанимать ли ещё людей: начинать с одного, выжимать из него максимум и усложнять структуру, только когда один перестаёт справляться. Та же логика стоит за отчётом Google Cloud о новой роли менеджера как супервайзера команды агентов – только вендор рисует пять автономных агентов уже сегодня, а инженеры честно советуют начинать с одного и хорошо описанных швов между ними.

Что со всем этим делать менеджеру на практике

Автор завершает статью лозунгом «Агенты – это не магия. Это управляемая автономия» и предлагает чек-лист: перед запуском агента ставить вопрос глубже, чем «работает ли это». Спрашивать стоит другое: «можно ли доверять этому агенту, когда у него реальные пользователи, реальные данные, реальные инструменты, реальные затраты и реальные последствия». Демо выживает с удачным промптом. Продакшен требует архитектуры, тестов, прав, дисциплины памяти, наблюдаемости, защиты и ясного владельца.

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

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

Дальше опишите процесс именно как рабочий процесс со множеством шагов – ровно к этому призывает статья. Один длинный промпт здесь не работает. Разбейте задачу на шаги, к каждому привяжите конкретное действие и нужный инструмент, опишите нестандартные случаи и обязательно отметьте, на каких шагах решение должен принимать человек. Если вы не можете внятно описать процесс словами, никакой агент его не выполнит. Это и есть проверка готовности, и сделать её можно прямо сейчас, в обычном чате.

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

Когда черновик готов, отдайте его на проверку второй модели – пусть найдёт дыры до того, как вы понесёте задачу в разработку. Ниже для примера разбирается уже немного «причёсанный» черновик того же процесса поддержки; вставьте сюда свой:

Заметьте: оба шага вы делаете в обычном чате, ещё до того, как зайдёт речь о разработке настоящего агента. Самая дорогая ошибка – заказать сложного агента под процесс, который вы сами не смогли внятно описать.

Что в итоге

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

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

И базовый навык под всем этим один и тот же – что для одиночного промпта, что для агента. Это умение точно сформулировать, чего вы хотите, на каких данных и с какими ограничениями – по сути, те же 5 элементов хорошего промпта, только применённые к целому процессу. Без этого навыка не работает ни промпт, ни агент. С него и стоит начинать.

Читайте также

AI для входящих запросов клиентов: −50% времени ответа

Автоматизация отчётов и статусов с ИИ: рабочий цикл

Анализ конкурентов с ИИ: где модель выдумывает факты

Как ставить задачи разработчикам с помощью ИИ