Агент или рабочий процесс? Разделение рассуждений и выполнения в корпоративном ИИ

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

Проект по управлению поставщиками, разработанный с использованием технологий RAG, LangGraph, MCP, утверждения человеком и Amazon Bedrock, привёл к одной основной идее: агент должен решать, что необходимо сделать, а приложение — контролировать способ выполнения этих действий. Всё остальное в проектировании вытекает из этого разделения функций.

Почему агент не должен делать всё

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

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

Рабочие процессы против агентов

Эти два термина часто путают, но разница между ними важна. Рабочий процесс ИИ следует в основном заранее определённому пути:

Request
   ↓
Validate
   ↓
Retrieve Policies
   ↓
Evaluate
   ↓
Approval
   ↓
Create Supplier
   ↓
Publish Integration Event

Приложение знает каждое состояние и каждую переходную процедуру. У ИИ-агента больше свободы в выборе следующего шага:

User Request
      ↓
     LLM
      ↓
Reason about intent
      ↓
Choose next capability
   ↙    ↓     ↘
Search Validate Request Approval

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

Расчёты агента сверху, детерминистическое выполнение снизу

На высоком уровне архитектура выглядит следующим образом:

USER
                      │
                      ▼
                 FastAPI API
                      │
                      ▼
                 LangGraph
                Agent Workflow
                      │
          ┌───────────┼───────────┐
          ▼           ▼           ▼
        RAG        Reasoning     Tools
          │
          ▼
   Amazon OpenSearch
          │
          ▼
     AWS Bedrock
                      │
                      ▼
                MCP Boundary
                      │
                      ▼
               Application API
                      │
                      ▼
              Domain / Use Cases
                      │
              ┌───────┴───────┐
              ▼               ▼
          PostgreSQL         AWS SQS
                                │
                                ▼
                               SAP

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

Где агенты находят своё место

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

Понимание намерений

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

{
  "intent": "supplier_onboarding",
  "supplier": "ACME",
  "country": "BR",
  "requires_policy_validation": true
}

Далее берёт на себя управление детерминистическое программное обеспечение.

Получение корпоративных знаний с использованием RAG

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

Question
   ↓
Embedding
   ↓
Amazon OpenSearch
   ↓
Relevant Policy Chunks
   ↓
LLM Context
   ↓
Reasoning

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

Где рабочие процессы работают лучше

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

Validate Supplier
      ↓
Check Duplicate
      ↓
Check Authorization
      ↓
Persist Supplier
      ↓
Publish Integration Event
      ↓
Wait for SAP Result

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

Почему LangGraph

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

START
  │
  ▼
Understand Intent
  │
  ▼
Retrieve Policies
  │
  ▼
Evaluate Request
  │
  ├───────────────┐
  │               │
  ▼               ▼
Approval Needed?  No Approval
  │               │
  ▼               │
Human Approval    │
  │               │
  └───────┬───────┘
          ▼
     Request Action
          │
          ▼
         END

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

Подход с участием человека имеет несколько значений

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

Утверждение руководства

Сам процесс бизнеса требует подтверждения, независимо от того, задействован ИИ или нет:

Supplier
   ↓
Compliance Check
   ↓
Manager Approval
   ↓
Creation

Утверждение инструмента ИИ

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

Agent
  ↓
"Create supplier"
  ↓
Tool requires confirmation
  ↓
Human approves
  ↓
Application executes

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

Почему важен MCP

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

Agent
  ↓
MCP Tool
  ↓
Application API
  ↓
Use Case
  ↓
Domain
  ↓
Infrastructure

и избегает подключения агента к базе данных:

Agent
  ↓
PostgreSQL

или непосредственно в SAP:

Agent
  ↓
SAP

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

SAP не должно зависеть от постоянной работы LLM

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

Agent
  ↓
SAP
  ↓
Wait...
  ↓
Timeout

Поток становится следующим:

Agent
  ↓
Application
  ↓
Persist State
  ↓
AWS SQS
  ↓
Integration Worker
  ↓
SAP

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

Гибридная архитектура

После установления этих границ называть систему просто ИИ-агентом уже некорректно. Это гибридная система:

┌─────────────────────────────┐
│     PROBABILISTIC LAYER     │
│                             │
│ LLM                         │
│ RAG                         │
│ Intent Understanding        │
│ Reasoning                   │
│ Tool Selection              │
└──────────────┬──────────────┘
               │
        Controlled Boundary
               │
┌──────────────▼──────────────┐
│     DETERMINISTIC LAYER     │
│                             │
│ Application Use Cases       │
│ Domain Rules                │
│ Authorization               │
│ Validation                  │
│ Transactions                │
│ Idempotency                 │
│ Messaging                   │
│ Integrations                │
└─────────────────────────────┘

Это различие имеет решающее значение для корпоративных агентных ИИ-систем.

Архитектура программного обеспечения по-прежнему важна

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

Агент или рабочий процесс?

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

AI AGENT
                 │
                 │ decides WHAT
                 ▼
        ┌─────────────────┐
        │ Controlled Tool │
        │    Boundary     │
        └────────┬────────┘
                 │
                 │ requests
                 ▼
          APPLICATION
                 │
                 │ decides HOW
                 ▼
             DOMAIN
                 │
                 ▼
        INFRASTRUCTURE

LLM не должен становиться самой архитектурой. Он должен участвовать в ней.

Где приносит пользу автономия

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

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