Production AI Agents: определение, архитектура и контроли

Прямой ответ

Production AI agent - это система, которая выполняет multi-step работу внутри бизнес-tools под scoped permissions, с human approval gates на рискованных действиях, evals, ловящими регрессии, наблюдаемым исполнением и именованным владельцем после handoff. Модель - один компонент; определение живёт в архитектуре, обёрнутой вокруг неё. Chat-окно, которое только разговаривает, каким бы впечатляющим оно ни было, - это demo.

Под капотом agent обычно ходит по циклу: воспринимает контекст, планирует следующий шаг, действует через tools, наблюдает результат и повторяет, пока цель не достигнута или не сработало условие остановки. Этот цикл и есть agent. Production - это wrapper, который делает цикл безопасным при реальных данных, реальных permissions и реальных последствиях.

Эта статья - технический и информационный pillar: архитектура, контроли и примеры, которые делают agent production-ready. Если вопрос организационный или коммерческий - куда такие системы встраиваются, на какой стадии зрелости покупать и как задать scope первого pilot - читайте production AI agents для бизнеса. Слово «production» зарабатывается тем, что происходит, когда вход искажён, API падает по timeout или клиент зол, а не тем, что происходит на штатном сценарии.

Пять свойств, определяющих «production»

1. Действует через tools, под permissions. Agent читает и пишет в вашем CRM, inbox, таблицах или тикетах через scoped credentials, с принудительным least privilege. Он работает внутри ваших tools, а не рядом с ними.
2. Закрыт gates там, где это важно. Необратимые действия - отправка, оплата, изменение записей, закрытие тикетов - идут через human approval, пока доказательства не оправдают ослабление. Gates проектируются, а не прикручиваются потом.
3. Оценивается непрерывно. Eval-сет кодирует, как выглядит хороший выход; regression-проверки прогоняются перед любым изменением prompt или модели. Без этого качество дрейфует незаметно.
4. Наблюдаем. Logs и traces показывают, что agent видел, решил и сделал, - и читаются вашей командой без вендора на звонке. Инциденты диагностируются за минуты, а не восстанавливаются по памяти.
5. Имеет владельца. Именованный человек ведёт review queue, смотрит метрики и может нажать stop switch. Софт без владельца деградирует в источник рисков.

Уберите любое из пяти - и у вас нечто слабее production: многообещающий прототип, рискованная автоматизация или ничейная обуза.

Gates ложатся на спектр autonomy простым языком: assisted (человек ведёт; agent готовит драфт или предлагает), semi-autonomous (agent действует на низкорисковых шагах; человек утверждает высокорисковые) и supervised (agent идёт по пути с непрерывным мониторингом, sampling и stop switch). Полная unattended autonomy - не цель по умолчанию для production business workflows. Как approval queues и escalation работают на практике, см. human-in-the-loop AI agents.

Как работает agent (цикл)

Полезная ментальная модель - замкнутый цикл, а не один prompt. Исследования generic agents описывают plan-and-act cycling; production-shaped цикл добавляет grounded context и permission gate перед side effects tool:

1. Бизнес-вход - запрос, событие или элемент очереди, который запускает run.
2. Grounded context (обоснованный контекст) - retrieval политик и источников, чтобы следующий шаг опирался на реальные данные.
3. Plan and validate (план и проверка) - выбрать следующее безопасное действие или tool call.
4. Permission gate (шлюз разрешений) - human approval, когда действие рискованное; низкорисковые шаги могут проходить по policy.
5. Tool execution (выполнение tool) - scoped, по возможности idempotent read или write под credentials.
6. Observe and improve (наблюдение и улучшение) - прочитать результаты, trace, evaluate, retry или stop, затем цикл при необходимости.

Исследования interleaved reasoning and acting (ReAct) формализуют ядро plan-and-act: модель думает, делает действие, наблюдает и продолжает, а не только выдаёт финальный ответ (ReAct paper). Определения платформ описывают ту же форму: agents преследуют цели, используют tools и сочетают planning с action (AWS on AI agents, Google Cloud on AI agents). Tool use / function calling - примитив, который превращает текст в side effects в реальных системах (Anthropic tool use).

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

Demo agent vs production agent

Колонка demo не является неправильной для demo. Она становится неправильной в момент, когда через систему текут реальные данные клиентов или реальные деньги. Операционные страшилки, которые появляются, когда команды пропускают этот разрыв, - в demo vs production.

Production AI agent vs chatbot

Chatbot может сидеть на том же семействе моделей, что и agent. Граница - действие, permissions и control, а не branding. Если система только разговаривает, относитесь к ней как к surface, а не как к production agent.

Анатомия wrapper

Внимание достаётся модели; работу делает wrapper. Production build включает:

• Tool contracts. Явные определения того, что может делать каждый tool call, с валидацией входов и выходов. Предпочитайте немного tools, строго типизированные schemas и idempotent writes, где возможно.
• Permission scoping. Service accounts на каждую integration, минимальные scopes, план ротации, secrets в менеджере, а не в коде.
• Session and memory. Short-term session state для текущего run; long-term memory или retrieval только когда workflow это требует, с правилами retention и доступа.
• Approval gates и review queue. Определённый список gated-действий, queue, с которой люди реально работают, и критерии ослабления gates со временем.
• Обработка исключений. Timeouts, retries с idempotency и dead-letter путь, чтобы упавшая работа была видимой, а не потерянной.
• Eval-сет. Репрезентативные кейсы, включая граничные и отказные, с порогами прохождения, привязанными к acceptance tests.
• Tracing и monitoring. Каждый запуск реконструируем от начала до конца; алерты на error rate, latency и cost. Agent-платформы считают tracing model calls, tools, handoffs и guardrails first-class operational signal (OpenAI agents guide, agents observability).
• Cost и token signals. Мониторьте spend и token use как operational alerts, а не только как месячную строку бюджета post factum. Ставьте thresholds под ваш workflow; не выдумывайте универсальные числа.
• Versioning и rollout. Prompts и конфиги версионируются как код; shadow mode и canary перед полным трафиком.
• Stop switch и runbook. Одно задокументированное действие ставит agent на паузу; runbook говорит, кто что делает, когда срабатывают алерты.
• Handoff-пакет. Документация, план по credentials, обучение и условия выхода, чтобы знание пережило отношения с вендором.

Протоколы interoperability вроде Model Context Protocol (MCP) могут стандартизировать, как apps подключают tools и данные. Это полезная обвязка. Они не заменяют gates, evals, ownership или stop switch.

Типичные failure modes

Эти отказы - причина, по которой существуют пять свойств. Каталог здесь короткий; глубина - в гайде по failure modes.

• Бесконечные циклы / нет iteration caps - agent перепланирует бесконечно без timeout или step budget.
• Unscoped credentials - общий admin key превращает одно плохое действие в широкий радиус поражения.
• Silent quality drift - prompts или модели меняются без eval suite, и неверные выходы выглядят нормально, пока не заметят клиенты.
• Runaway tool spend - рекурсивные tool calls сжигают tokens или платные APIs без cost alert.
• Missing или broken tools - agent выдумывает шаги или плохо fails closed, когда integration лежит.
• Multi-agent cascade - лишние agents усиливают ошибки там, где хватило бы одного gated path.

Паттерны защиты от этих modes - в production agent failure modes.

Evaluation, observability и security

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

Evaluation. Держите offline acceptance suite и гоняйте regression перед каждым изменением prompt, tool или модели. Добавляйте trajectory review, когда важен путь: смотрите, что agent сделал шаг за шагом, а не только финальный текст. Сэмплируйте live traffic на drift после go-live (online evaluation) и оставляйте human review в loop для high-stakes суждений (Microsoft lesson on agents in production, AWS on evaluating agentic systems). Исследовательские программы также изучают evaluation probes и machine-readable audit trails для agentic systems (NIST evaluation probes for agentic AI); это research direction, а не compliance badge. Полный go-live метод: как оценивать AI agents перед go-live.

Observability. Нужны logs и traces, которые реконструируют, что agent видел, какие tools вызывал, что они вернули и что решил человек. Если отладить run может только вендор, системой вы не владеете. Глубина: agent observability: logs and traces.

Security. Принудительный least privilege на каждый tool credential. Sandbox или review tools и skills, прежде чем они могут работать на production paths. Аудит tool results, а не только model text. Держите stop switch, который именованный владелец может нажать без звонка вендору.

Примеры production AI agent

Иллюстративные паттерны workflow, не case studies:

Это production-примеры только когда controls и evidence реальны. Тот же workflow без scoped tools, failure handling и ownership - всё ещё прототип.

Surfaces - это не система

Chat, email, тикеты, voice, WhatsApp, background jobs - это точки входа, а не архитектура. Одно и то же production-ядро может обслуживать несколько surfaces, а красивый chat UI может сидеть поверх пустоты. Когда вендор показывает surface, спросите, что под ним: карта gates, eval-сет, хранилище traces. Surface - последние 10 процентов; покупатели, оценивающие surfaces, покупают demos.

Как строится production agent

Путь, который надёжно производит свойства выше:

1. Сначала discovery и карта workflow, включая exceptions.
2. Acceptance tests, письменно согласованные до build.
3. Pilot, построенный с включёнными gates с первого дня.
4. Evals, прогнанные против acceptance tests.
5. Shadow mode на реальном трафике без действий.
6. Canary на маленьком срезе с gates.
7. Масштаб, где решения об ослаблении gates принимаются на доказательствах.

Команды, прыгающие из build сразу в полный трафик, - источник большинства agent-страшилок. Разница разобрана в demo vs production.

Что это значит для вашей организации

Production agent меняет работу людей, а не только tooling. Кто-то на вашей стороне владеет качеством после ухода вендора: ведёт review queue, читает недельные метрики, решает, когда ослаблять gates, и оплачивает строку LLM usage, которая теперь сидит в вашем бюджете. Если до старта build внутри компании нельзя назвать никого на эту роль, вы не готовы покупать production agent - вы готовы купить demo, а разочароваться можно и дешевле.

В проектах Northstar большая часть инженерии - это не вызов модели: основное усилие уходит на approval gates, интеграции, evals и мониторинг.

Как помогает Northstar

Northstar строит production-путь с самого начала: discovery, gates, evals, observability и handoff внутри scope pilot, поверх chat-, email- и background-job-поверхностей. Если у вас есть один scoped workflow и владелец review queue, начинайте с production-shaped pilot, а не с demo. Смотрите solutions о том, как устроен pilot, и production AI agents для бизнеса про org fit и scope первого pilot.