Как создать ИИ-агента: архитектура первого рабочего контура

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

Сложность начинается позже.

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

Именно поэтому при создании агентов лучше начинать не с выбора модели, SDK или framework. Современные контура искусственного интеллекта могут использовать разные модели и инструменты, но сами по себе эти элементы архитектуры ещё не определяют архитектуру рабочего контура.

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

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

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

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

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

Нужен ли вам вообще ИИ-агент

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

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

Первый архитектурный вопрос звучит не «какую языковая модель выбрать?», а:

нужен ли здесь агент вообще?

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

Например:

получить форму → проверить обязательные поля → создать запись → отправить уведомление

Здесь системе не приходится каждый раз решать, какой шаг делать следующим. Маршрут известен заранее.

Но вернёмся к нашему агенту входящих обращений.

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

Путь уже нельзя полностью определить заранее.

Здесь появляется смысл в agentic loop: языковая модель участвует в выборе следующего шага в зависимости от текущего контекста и результата предыдущих шагов.

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

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

Агент имеет смысл там, где действительно необходимо управляемая свобода выбора.

Начните с Agent Contract, а не с промпта

Предположим, задача действительно требует агента.

Следующая распространённая ошибка — сразу писать system prompt.

До инструкций полезнее составить контракт задачи.

Не юридический документ и не отраслевой стандарт, а рабочую языковая модель, которая фиксирует, что именно мы делегируем системе.

«Нам используется агент продаж».

Такая формулировка почти ничего не даёт архитектору.

Непонятно:

• когда он запускается;
• какие данные получает;
• где их проверяет;
• что именно важно сделать;
• какой outcome считается успешным;
• какие вызовы ему запрещены.

Для нашего примера формулировка может выглядеть так:

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

Теперь уже можно проектировать систему.

Task — что мы делегируем

Task следует описывать конкретную работу, а не название будущего продукта.

В нашем случае:

определить контекст обращения и подготовить корректный проект ответа.

Это полезнее, чем:

быть виртуальным менеджером продаж.

Архитектура строится вокруг проверяемых операций, а не вокруг красивой роли.

Outcome — что реально должно измениться

Здесь важно разделить output и outcome.

Output — то, что сгенерировала языковая модель.

Например:

подготовлен текст ответа пользователю.

Outcome — состояние, которое реально должно быть достигнуто.

Например:

в внешняя система создан draft ответа, он связан с правильным пользователем, основан на актуальных данных и имеет статус waiting_for_approval.

языковая модель может написать:

«Проект ответа успешно создан».

Но это ещё ничего не доказывает.

Если запись не появилась в внешняя система, задача не выполнена.

Source of Truth — где находится реальная истина

Это один из ключевых моментов архитектуры.

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

• данные человека — внешняя система или запрос в базу данных;
• актуальные условия продукта — база знаний;
• статус отправки письма — почтовый сервис;
• состояние самого run — этап выполнения store агента.

языковая модель не необходимо становиться источником истины только потому, что она уверенно сформулировала ответ.

Если внешняя система говорит, что инициатора не нашли, а языковая модель «догадалась», кто это, контур важно доверять внешняя система, а не догадке модели.

Если инструмент сообщил, что отправка письма завершилась timeout, финальная фраза модели «письмо отправлено» не заменяет подтверждение почтового сервиса.

Success Criteria — как доказать успех

Следующий вопрос:

по каким признакам выбор понимает, что задача выполнена?

• нужный человек идентифицирован;
• данные взяты из разрешённых источников;
• запрос классифицирован;
• проект ответа соответствует обязательным правилам;
• draft записан в внешняя система;
• никаких запрещённых вызовов не произошло;
• архитектура переведена в корректное конечное состояние.

Комментарий Анастасии Чернецкой: первый агент чаще ломается не потому, что команда выбрала «не ту языковая модель», а потому, что никто заранее не договорился, что считается выполненной задачей и где заканчивается ответственность выбор.

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

Определите границы: Capability, Permission и Autonomy — не одно и то же

Предположим, мы подключили агенту CRM API.

Технически контур теперь может:

• читать карточки пользовательов;
• создавать заметки;
• менять поля;
• удалять записи.

Но подключение API не означает, что агенту следует разрешать всё перечисленное.

Capability — что система технически умеет

Если существует функция update_customer, выбор обладает capability изменять данные оператора.

Это просто техническая возможность.

Permission — что конкретному агенту разрешено

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

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

Это уже access policy.

Autonomy — что агент может инициировать сам

Даже разрешённое шаг необязательно должно выполняться самостоятельно.

Например, агент может иметь permission на отправку письма, но конкретное письмо должно проходить согласование.

Техническая возможность есть. Право есть. Автономного исполнения нет.

Approval — подтверждение конкретного действия

ручная проверка относится не ко всей системе сразу, а к конкретной шаги.

• прочитать CRM — автономно;
• создать draft — автономно;
• отправить письмо — после точки контроля;
• изменить критичные данные — запрещено независимо от подтверждения.

Guardrail — дополнительный слой, а не замена permissions

Инструкция «Не меняй цену инициатора» полезна, но она не необходимо быть единственным механизмом защиты.

Если API-вызов всё равно принимает параметр изменения цены и runtime позволяет его выполнить, у нас слабая архитектура.

Надёжнее, когда запрет действует на уровне permissions или policy engine, независимо от того, что решила языковая модель.

Именно поэтому Capability, Permission и Autonomy нельзя использовать как синонимы.

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

Из каких компонентов состоит первый рабочий контур

После задачи и границ уже имеет смысл говорить о компонентах.

Но рабочий агент нельзя сводить только к формуле:

LLM + tools + memory.

Model

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

Языковая LLM интерпретирует вход, анализирует контекст и предлагает дальнейший шаг.

Например:

запрос относится к условиям сотрудничества → сначала необходимо получить тариф человека и актуальные правила из базы знаний.

Но языковая модель — не вся архитектура.

Instructions

Instructions задают цель, правила, приоритеты, процедуру и ограничения.

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

Tools

Tools дают возможность работать с внешней средой.

• get_customer;
• search_knowledge;
• create_draft;
• request_approval;
• send_email.

Runtime / orchestration

Реализовать такой контур можно по-разному: написать backend на Python, использовать agent framework, собрать часть связок в n8n или другой no-code платформе, разместить runtime локально либо на облачном сервере. Конкретный способ программирования вторичен: архитектура всё равно должна определять, где выполняется код, как приложение обращается к интернету и внутренним сервисам, какие файлы и данные доступны и кто управляет переходами между шагами.

LangChain, готовые конструкторы и другие платформы могут ускорить разработку, но не решают за команду вопросы boundaries, permissions, статус выполнения, failures и evals. Поэтому полезно отделять удобство инструмента от качества самой архитектуры.

Runtime — это слой кода, который управляет выполнением агента.

Он не обязан быть отдельным продуктом или специальным сервисом. Это может быть собственный backend, workflow engine или orchestration layer.

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

LLM предлагает шаг. Runtime решает, можно ли его реально исполнить.

Статус выполнения

run status отвечает на вопрос: где сейчас находится конкретная задача?

customer_identified = true
knowledge_loaded = true
draft_created = true
approval_status = pending

Observation

Observation — outcome шаги во внешней системе.

create_draft:
status = success
draft_id = 18427

или:

search_knowledge:
status = no_result

Verifier

Verifier отвечает на принципиально другой вопрос: действительно ли после шаги наступило нужное состояние?

Это особенно важно для операций с внешним side effect.

Наш агент вызвал create_draft. инструмент ответил success.

Verifier может отдельно запросить CRM и убедиться:

• draft действительно существует;
• он прикреплён к правильному пользователю;
• имеет правильный статус;
• содержит нужную версию данных.

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

Предложить вызов может LLM. Доказать итог требуется контур.

Проектируйте tools как контракты, а не как список функций

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

Название инструмента ещё не определяет безопасное поведение.

Возьмём функция send_email().

Для нашего агента стоит заранее определить:

• кому разрешено писать;
• можно ли использовать внешний адрес;
• от какого аккаунта идёт отправка;
• какие вложения разрешены;
• имеет смысл ли ручная проверка;
• что означает success;
• что происходит при timeout;
• можно ли повторять операцию.

Так tools перестают быть просто «руками агента» и становятся управляемыми интерфейсами с явными последствиями.

Через tools агент может взаимодействовать с CRM, базой данных, календарём, мессенджером, файловым хранилищем или внутренним API. Он собирает необходимые данные, передаёт их в LLM, формирует следующий запрос и использует ответ для продолжения процесса. Чем больше таких интеграций, тем важнее заранее определить права доступа и ожидаемые postconditions.

Context, Статус выполнения, Checkpoint, Memory и Knowledge — не одно и то же

Слово «память» в разговорах об ИИ-агентах используют слишком широко.

Под ним могут понимать prompt history, состояние задачи, пользовательский профиль, checkpoint, vector database и документы из RAG.

Это разные слои.

Context

Context — информация, которую LLM видит прямо сейчас.

• входящее сообщение;
• карточка инициатора;
• найденные документы;
• текущие instructions;
• последние вызовы.

Run Статус выполнения

рабочий статус — фактическое положение выполнения.

customer_identified = true
query_type = "pricing"
draft_created = false
approval_status = null

Context может содержать часть текущее состояние, но это не делает их одним и тем же.

Checkpoint / Event Log

Checkpoint позволяет сохранить положение run и восстановить выполнение.

Event log отвечает: что произошло раньше?

10:14 get_customer → success
10:14 search_knowledge → success
10:15 create_draft → timeout

Long-term Memory

Memory хранит информацию между разными задачами или сессиями.

Например: инициатор предпочитает получать документы на английском языке.

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

Но первому агенту long-term memory может вообще не понадобиться.

Retrieved Knowledge

База знаний — ещё один отдельный слой.

Агент может каждый раз заново извлекать актуальные документы через retrieval. Это не значит, что он требуется сохранять эти документы в своей memory.

Context — что языковая модель видит сейчас.

этап выполнения — где сейчас выполнение.

Checkpoint — как восстановить run.

Memory — что сохраняем между задачами.

Knowledge — что получаем из внешнего источника знаний.

Добавление документов в memory или knowledge base не означает обучение языковой модели. Материалы могут подставляться в context через retrieval, а новый навык агента чаще появляется через инструкции, tools и логику runtime, а не через переобучение LLM. Это различие особенно важно при обновлении корпоративных знаний.

Как выглядит Agent Loop с реальным control plane

Классический Agent Loop часто показывают так:

Think → Act → Observe.

Для объяснения идеи этого достаточно. Для рабочего агента — нет.

Вернёмся к нашему входящему обращению.

run status говорит: оператор найден, контекст загружен, draft ещё не создан.

LLM предлагает вызвать create_draft.

Но между предложением модели и реальным выполнением важно появиться control plane.

Под control plane здесь мы понимаем не обязательно отдельный продукт, а совокупность технических проверок runtime перед выполнением шаги. Агент работает внутри этого режима управления: языковая модель предлагает дальнейший шаг, а технический слой решает, допустим ли он. Если проверка не пройдена, агент будет остановлен, переведён в waiting-состояние или передан оператору.

STATE
  ↓
DECISION
  ↓
PROPOSED ACTION
  ↓
SCHEMA VALIDATION
  ↓
PERMISSION CHECK
  ↓
APPROVAL CHECK
  ↓
EXECUTION
  ↓
OBSERVATION
  ↓
POSTCONDITION VERIFICATION
  ↓
STATE UPDATE
  ↓
NEXT / STOP

Сначала LLM предлагает шаг. Runtime проверяет, корректны ли параметры. Затем выбор проверяет permissions. Если шаг требует человека — появляется подтверждение gate. После этого executor вызывает API-вызов.

Полученный outcome становится observation. Дальше verifier проверяет реальное состояние источника истины. Только после этого обновляется текущее состояние.

И уже новый этап выполнения определяет: продолжать цикл или завершить run.

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

Проектируйте ошибки до happy path

Демо почти всегда показывает удобный сценарий. Production редко бывает таким аккуратным.

Что делать, если обязательных данных нет

Например, человек написал с неизвестного адреса. Агент не может однозначно найти карточку.

Это не обязательно failure. run status может перейти в waiting_for_input. контур запрашивает уточнение и ждёт продолжения.

Что делать, если tool временно недоступен

CRM вернула 503. Здесь возможен retry с backoff.

Что делать при Permission Denied

Агент пытается изменить поле, которое ему недоступно. Повторять бессмысленно.

Нужны другой допустимый маршрут, escalation или stop.

Что делать при неоднозначном результате

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

Что делать при timeout после действия с side effect

Допустим, агент вызвал send_email. Почтовый сервис не ответил вовремя.

Мы не знаем, письмо не отправилось, отправилось, но response потерялся, или шаг ещё выполняется.

Если просто вызвать send_email повторно, инициатор может получить два одинаковых письма.

Вот здесь появляется понятие idempotency.

Идея простая: повтор одного и того же логического шаги не следует создавать второй side effect.

Например, каждому исходящему письму можно присвоить уникальный operation ID. Перед повторной отправкой выбор проверяет, существует ли уже сообщение с этим ID.

Если внешний вызов поддерживает idempotency key — используем его. Если нет — сначала проверяем source of truth.

retry и recovery — не одно и то же.

Retry означает повторить операцию. Recovery означает вернуть процесс в корректное состояние — и иногда для этого повторять шаг как раз нельзя.

Что делать, если агент ходит по кругу

У контура важны существовать hard limits:

• max turns;
• max time;
• max cost;
• no-progress detection.

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

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

Stop Conditions: агент должен уметь не только действовать, но и остановиться

Если системе дали цикл, ей обязательно нужны правила завершения.

Простого состояния done обычно недостаточно.

succeeded

Draft создан, проверен и задача завершена.

partial

Часть результата получена, но полный outcome недостижим.

waiting_for_input

важна дополнительная информация от оператора.

waiting_for_approval

Draft готов, но дальнейший вызов заблокировано до выбора человека.

Важно: waiting_for_input и waiting_for_approval — не ошибки. Это нормальные рабочие состояния управляемой агентной системы.

Агент не сломан. Он корректно понял, что самостоятельно продолжать нельзя.

denied

Policy запрещает шаг.

recoverable_failure

Произошёл сбой, после которого работу можно продолжить.

terminal_failure

Продолжение невозможно или небезопасно.

cancelled

Run отменён.

Кроме смысловых состояний, нужны hard limits:

• max turns;
• max time;
• max cost;
• no progress;
• policy denial;
• verification failure;
• user cancel.

Хороший агент требуется уметь не только искать следующий шаг, но и понимать допустимые причины, по которым следующего шага быть не должно.

Human-in-the-Loop: где действительно нужен человек

Human-in-the-Loop не означает, что сотрудник важно контролировать каждый инструмент call.

Если подтверждать всё подряд, самостоятельность исчезает.

Автономно:

• прочитать CRM;
• найти статью в базе знаний;
• классифицировать запрос;
• создать draft.

Через согласование:

• отправить ответ;
• изменить значимые данные;
• применить нестандартное условие.

Запрещено:

• удалять человека;
• самостоятельно менять критичные данные;
• обходить ограничения политики.

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

• какой шаг подтверждаем;
• кто reviewer;
• сколько действует approval;
• что происходит при timeout;
• куда идёт escalation.

Evals проектируют до production, а не после

Если success criteria появились ещё в Agent Contract, часть evals уже известна до реализации.

Success criterion: draft требуется быть сохранён правильному пользователю.

Следовательно: требуется test на postcondition CRM.

Boundary: агент не может менять цену.

Следовательно: используется forbidden-шаги test.

Failure mode: send_email может timeout.

Следовательно: имеет смысл recovery test без duplicate side effect.

Stop condition: при отсутствии инициатора надо перейти в waiting_for_input.

Следовательно: требуется termination/рабочий статус-transition test.

Success criterion → success test
Boundary → forbidden-action test
Failure mode → recovery test
Stop condition → termination test
Approval rule → approval-bypass test

Outcome evaluation

Достигнут ли нужный достигнутое состояние.

Trajectory evaluation

Как именно агент к нему пришёл.

• правильный ли tool выбрал;
• корректные ли arguments передал;
• не совершал ли запрещённых операций;
• не делал ли лишние циклы;
• правильно ли изменял текущее состояние;
• корректно ли восстановился после ошибки.

Так evals становятся продолжением архитектуры, а не отдельным проектом, который вспоминают после запуска.

Перед запуском протестируйте не только идеальные сценарии. В eval set стоит включить неполные данные, ошибочные ответы API, запрещённые шаги и трудные случаи. Такой набор помогает оценивать не только качество ответа, но и эффективность всей траектории: сколько шагов потребовалось, были ли лишние вызовы и удалось ли завершить задачу без ручного вмешательства.

Production Release Gate: что должно существовать до запуска

Успешный demo-run ещё не означает production readiness.

Observability

• trace;
• model calls;
• tool calls;
• этап выполнения transitions;
• approvals;
• ошибки;
• latency;
• стоимость;
• termination reason.

Permissions

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

Eval baseline

Есть ли фиксированный набор сценариев, на котором можно сравнивать версии.

Versioning

• model;
• instructions;
• tool schema;
• policy;
• memory/run status schema.

Rollback

Можно ли быстро вернуть предыдущую версию поведения.

Rollback — откатить версию архитектуры.

Compensation — исправить уже совершённое внешнее вызов.

Если новая версия агента отправила неправильное письмо, rollback кода письмо не отзовёт.

Owner

У рабочего агента важно быть не только технический runtime, но и ответственный владелец.

• кто получает критические alerts;
• кто рассматривает escalation;
• кто разрешает rollout новой версии;
• кто может остановить агента;
• кто принимает выбор о rollback;
• кто отвечает за последствия внешних операций.

Без этого технически наблюдаемая архитектура всё равно может оказаться организационно бесхозной.

Комментарий Анастасии Чернецкой: production readiness — это не момент, когда агент впервые успешно прошёл сценарий. Это момент, когда команда понимает, как обнаружить сбой, воспроизвести run, остановить систему и безопасно изменить её поведение.

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

Как выглядит минимальная архитектура первого рабочего ИИ-агента

Теперь можно собрать всё вместе.

USER / EVENT
      ↓
TASK CONTRACT
      ↓
AGENT RUNTIME
 ┌─────────────────┐
 │ MODEL           │
 │ INSTRUCTIONS    │
 │ STATE           │
 └─────────────────┘
      ↓
PROPOSED ACTION
      ↓
CONTROL PLANE
 ┌─────────────────┐
 │ VALIDATION      │
 │ PERMISSION      │
 │ APPROVAL        │
 │ LIMITS          │
 └─────────────────┘
      ↓
TOOL / EXTERNAL SYSTEM
      ↓
OBSERVATION
      ↓
VERIFIER
      ↓
STATE UPDATE
      ↓
NEXT / STOP
      ↓
EVAL + TRACE

В нашем примере это означает: оператор отправляет сообщение. Agent Contract определяет, что именно требуется получить на выходе. Model выбирает следующий шаг. Runtime принимает это предложение. Control Plane проверяет schema, permissions и approval policy. Tool работает с CRM или базой знаний. Observation возвращает фактический итог. Verifier проверяет source of truth. рабочий статус обновляется.

контур либо продолжает выполнение, либо переходит в одно из terminal/waiting статус выполненияs.

языковая модель — только один компонент этого процесса.

Именно поэтому зрелый AI-agent лучше воспринимать не как «умную LLM с руками», а как управляемый контур вокруг вероятностного механизма принятия решений.

Что не делать при создании первого ИИ-агента

Не начинайте с framework. Сначала требования и архитектура, потом технология.

Не подключайте много tools «на будущее». Каждый новый tool расширяет пространство шагов и ошибок.

Не выдавайте полный доступ только потому, что API это позволяет.

Не используйте prompt как access-control систему.

Не смешивайте context, текущее состояние и memory.

Не проектируйте только happy path.

Не оставляйте Agent Loop без stop conditions.

Не делайте retry автоматически для операций с side effects.

Не откладывайте evals до момента после MVP.

И особенно — не пытайтесь сделать первого агента максимально автономным.

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

Первый агент — это контракт, а не набор технологий

Если убрать названия моделей, SDK и frameworks, архитектура первого агента всё равно требуется оставаться понятной.

Сначала определяется: используется ли здесь агент вообще.

Затем: что именно ему делегируется.

После этого: какой outcome следует быть достигнут, где находится source of truth и как outcome будет доказан.

Дальше: какие capabilities существуют, какие permissions выдаются и какие шаги можно выполнять автономно.

Затем: какие tools, статус выполнения, runtime и verification нужны для исполнения.

И только после этого: как выбор восстанавливается после ошибок, где останавливается, когда зовёт человека и как проверяется перед production.

AGENT FIT
   ↓
TASK CONTRACT
   ↓
AUTONOMY CONTRACT
   ↓
EXECUTION CONTRACT
   ↓
STATE MODEL
   ↓
FAILURE / STOP
   ↓
EVALS
   ↓
PRODUCTION CONTROL

Именно в этом смысле создание ИИ-агента — прежде всего задача архитектуры, а уже потом задача выбора модели и инструментов.

Если создавать первого AI-агента с нуля, полезно пройти этот путь последовательно:

1. выбрать задачу;
2. описать measurable outcome;
3. определить источники данных;
4. задать permissions;
5. подключить минимально необходимые tools;
6. описать статус выполнения и stop conditions;
7. протестировать failures;
8. добавить approvals;
9. собрать eval set;
10. только затем выбирать платформу и готовить запуск.

Такой подход не гарантирует, что агент сразу станет идеальным. Но он позволяет строить выбор, которое можно анализировать, тестировать, ограничивать и постепенно улучшать вместо того, чтобы отлаживать непрозрачную цепочку prompt → model → tool.

Частые вопросы о создании ИИ-агента

Что задаёт системный промпт ИИ-агента?

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

Как разработчики реализуют рабочий цикл ИИ-агента?

Разработчики связывают инструкции, код, API и интеграции в единый процесс. Настройка зависит от платформы, но базовая логика одинакова: ИИ-агент работает с текущим контекстом, вызывает разрешённые функции, получает обратную связь и проверяет итог перед следующим шагом.

С чего начать создание ИИ-агента?

С проверки, действительно ли задаче имеет смысл agentic loop. Затем стоит определить task, observable outcome, source of truth, success criteria и boundaries. Только после этого имеет смысл выбирать языковая модель и инструменты.

Какие элементы архитектуры нужны ИИ-агенту?

Минимальный рабочий контур обычно включает model, instructions, tools, runtime/orchestration, статус выполнения, observation и stop conditions. Для production дополнительно нужны permissions, verification, monitoring и evals.

Чем ИИ-агент отличается от обычного workflow?

Workflow обычно следует заранее известному пути. В агентной системе LLM может выбирать следующий шаг в зависимости от текущего состояния и результатов предыдущих вызовов.

Нужна ли ИИ-агенту память?

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

Как определить, какие действия агент может выполнять самостоятельно?

следует отдельно определить capabilities, permissions и autonomy. Технически доступное шаг не обязательно разрешено, а разрешённое шаг не обязательно должно выполняться без approval.

Что делать, если инструмент агента вернул ошибку?

Сначала определить класс ошибки. Temporary failure может допускать retry. Permission denied требует другого маршрута или остановки. Timeout после возможного side effect сначала требует проверки фактического состояния, чтобы повторная шаг не создала дубликат.

Как проверить ИИ-агента перед запуском?

Нужны проверки task success, forbidden actions, tool failures, stop conditions, approvals, recovery behavior и траектории выполнения. Финальный ответ модели сам по себе не является доказательством корректной работы контура.

Можно ли создать ИИ-агента без программирования?

Да, часть логики можно собрать в no-code конструкторе или n8n. Но чем больше у агента интеграций, прав доступа и нестандартных сценариев, тем чаще потребуется код для надёжного control plane, обработки ошибок и тестирования.

На чём разрабатывать ИИ-агента: Python, framework или no-code?

Выбор зависит от сложности контура. Python удобен для собственного backend и гибкой логики, framework может ускорить сборку типовых компонентов, а no-code подходит для простых связок. Архитектурные требования — boundaries, permissions, статус выполнения, stop conditions и evals — остаются одинаковыми.

Нужно ли обучать нейросеть для создания ИИ-агента?

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

Где запускать ИИ-агента: локально или в облаке?

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

Можно ли использовать ChatGPT, Claude, DeepSeek или другую модель как основу агента?

Да, но готовый чат-интерфейс и собственный агент — не одно и то же. Приложение может использовать GPT, Claude, DeepSeek или другую языковую модель через API, при этом самостоятельно управлять инструкциями, tools, статус выполнения, permissions и мониторингом.

Сколько времени занимает создание первого ИИ-агента?

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

Какой бюджет нужен для работы ИИ-агента?

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

Можно ли подключить ИИ-агента к Telegram, CRM или календарю?

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

Короткий глоссарий по архитектуре ИИ-агентов

Разработка первого агента обычно включает настройку логики, интеграций, API и проверки качества.