Агент ці працэс? Раздзяляем разважанне і выкананне ў карпаратыўным AI

Агентныя AI — гэта тэрмін, які зараз популярны. Дайце LLM калькі засобаў, дадзіце памяць, падключыце яго да корпаратыўных сістэм, дазвольце яму самаму адлучыць, што робіць далей, і такі рэзультат называецца агентам AI. Аднак існуе прынцыпавая проблема: корпаратыўныя сістэмы не можу працаваць выключна на адлучэннях, заснованых на верыятнасцях. Калі AI працуе з дакументамі постаўчыкаў, фінансавымі процэсамі, дадзенымі ERP, затверджэннямі чы іншымі крытычнымі операцыямі, дзеянні агента можу быць гнучкімі, а дзеянні іншых — ні.

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

Чаму агент не павінен робіць усё

Уявіце запіт на адаптаванне постаўчыка: створыць такога постаўчыка, прабавіць яго даныя, пераканацца ў правільнасці політыкі закупкаў і адправіць у SAP. У тэорыі аблеглы агент мог бы расцёніць запіт, шукаць внутрашні дакументы, прабавіць даныя, выявіць, чы робіцца неабходна згода, наладзіць звязак з SAP, стварыць запіс і праказаць спробу зноў у разе невыпання.

Гэта тэхнічна можліва, але з архітэктурной точкі зору не прыемна. LLM ўжоўляе верагатныя рашэнні. Аднойчы той самы вхідны даныя можа прывесты да адносна разных шляхоў расцёнкі, а мадэлі, запросы і кантэкст постаўляюць разныя рашэнні. Такая гнучкасць чудова для расцёнкі таго, што мае на увазе чалавек. Але яна не падходзіць для выканання крытычных бізнес-операцый. Мадэль не должна выявляць, чы трэба праказаць транзакцыю ў базе дадзеных, ствараць сабстычную стратэгію праказаў, выявляць, чы можна прыхіліцца да адпаведных прав, чы выконваць ролю 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

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

Прымэчка чалавека мае больш за адна значэння

У розмовах пра AI ў падпрыемствах часта сказваецца проста: «Проста включыце чалавека ў працэс». Аднак людзі можу втручацца з розных прычын, і прынеймна два відзэныя тыпу затверджэння варта розлучыць.

Затверджэння ад бізнесу

Сам процэс бізнесу выклікае патрэбу ў затверджэнні, незалежна ад таго, участвуе AI чы не:

Supplier
   ↓
Compliance Check
   ↓
Manager Approval
   ↓
Creation

Апраўка інструмента AI

Патрабуецца другая апраўка, таму што агент хочаць выконаць чутлівую дзеянне:

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 не павінен стаць самай архітэктурай. Ён павінен браты удзел у ёй.

Дзе даесяць рэзультатаў аўтаномія

Прыдатны вопыт — не гэта, сколькі аўтаноміі можна даць модэлю, а гэта, дзе аўтаномія стварае ценнась. Аўтаномія падходзіць для тлумачэння нечыста сформульаванага запіту, пошуку ў вялікай колькасці внутраніх дакументаў, аналізу кантэксту і прыметкі наступных дзеянь. Яна не падходзіць для перакрыцча бізнес-правіл, кантролю транзакцый чы выкарыстоўвання пароляў да базы дадзеных.

Мета — кантролюемая аўтаномія, якая ў корпаратывных сістэмах значыць спалучэнне верагатыстычнага аналізу AI з дэтэрміністычным інжынерыям. Наступны вопыт вырашаецца сама сабою: калі агент павінен з’явіцца ў SAP чы базе дадзеных, як жа павінна выглядаць гэтая межа?