Агент чи робочий процес? Розділення міркувань та виконання в корпоративному ШІ

Агентський ШІ — це тренд сьогодні. Дайте ЛЛМ певні інструменти, додайте пам’ять, підключіть його до корпоративних систем, дозвольте йому вирішувати, що робити далі, і результат називається агентом ШІ. Однак є одна проблема: корпоративні системи не можуть функціонувати виключно на основі ймовірнісних рішень. Коли ШІ працює з даними постачальників, фінансовими процесами, даними 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

LLM не повинен імпровізувати в цьому. Робочий процес має визначати гарантії виконання: перевірку, авторизацію, ідемпотентність, запобігання дублікаціям, повторні спроби, журнали аудиту, межі транзакцій та обробку помилок. Це питання інженерії програмного забезпечення, і інжиніринг запитів не має до них жодного відношення.

Чому 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. Спеціаліст керує процесами повторних спроб, затримок, черг для некоректних повідомлень, забезпечує можливість спостереження та ідемпотентну обробку даних, причому ці гарантії походять від детермінованого програмного забезпечення, а не від певної моделі.

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

Після встановлення цих меж називати систему просто AI-агентом більше не доречно. Це гібридна система:

┌─────────────────────────────┐
│     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 чи бази даних, яким має бути цей кордон?