Arhitektura AI agentov za podjetja: Zgradite kontrolno ploskev pred agentom

AI agenti za podjetja ne propadejo v produkciji zato, ker ekipe izberejo napačno ogrodje, temveč zato, ker gradijo agente kot samostojne aplikacije namesto kot upravljane digitalne delavce, ki delujejo na skupni kontrolni ploskvi, ki upravlja identitete, omejena orodja, odobritve in revizijo še pred prvim agentom. Ogrodja so v redu. Vzorci orkestracij so v redu. Kar uniči uvedbo, je to, da vsaka aplikacija izmisli svoj lastni login, svoje lastne ključe, svoj lastni spomin in svojo lastno revizijsko sled — nato pa nekdo iz varnosti zastavlja vprašanje, na katerega nihče ne more odgovoriti.

Agent brez dovolilnega motorja, prehoda za orodja in večstopenjskega modela odobritev je incident eskalacije privilegijev, ki čaka na post-mortem analizo. Podjetja, ki uspešno uvajajo agente v produkcijo, niso tista z najpametnejšim načrtovalcem. To so tista, ki so najprej zgradila identitete, omejitve, prehod za orodja in revizijo, šele nato pa dovolila agentu, da se dotakne orodja.

Prava arhitektura ni agent — je kontrolna ploskev pod njim

Vsak vodnik za podjetniške agente se začne z istim seznamom komponent: model za razmišljanje, orodja za zunanje funkcije, navodila, ki opredelijo vedenje ^[1]. Pravilno in nevarno nepopolno, ker opisuje enega agenta v izolaciji. Podjetniška enota oblikovanja ni agent. Je plast pod vsakim agentom.

Recimo ji Agent Control Plane. Upravlja najemnike, človeške identitete, agentske identitete storitev, katalog omejitev, register orodij z njegovimi poverilnicami, dovolilni motor, avtomatski stroj odobrovalnega procesa, omejen spomin in revizijski dnevnik. Vsaka aplikacija — računovodstvo, knjiga, marža, marketing, napovedovanje energije — se vključi v isto kontrolno ploskev. Vsak agent deluje na njej. Salesforce opredeli agentsko podjetje kot večletno transformacijo IT arhitekture ravno zato, ker tradicionalna podjetniška arhitektura podpira le pod-obsežne uvedbe agentov, ne pa razširjene agente, ki razmišljajo in delujejo po sistemih ^[3].

Če danes ne morete narisati tega diagrama za vaš sklad, ne gradite podjetniških agentov. Gradite demonstracije, ki se bodo zaletele, ko bo druga ekipa izdala svojo.

Nehajte dajati agentom lastne logine

Agenti niso ljudje. Nikoli ne bi smeli imeti človeškega stila loginov, trajnih glavnih API ključev ali avtonomnih upravičencev, ki preživijo zahtevo. Agenti tečejo kot omejene identitete storitev znotraj aktivne seje človeškega uporabnika, efektivno dovoljenje za katero koli dejanje pa se izračuna kot presek: človekovo dovoljenje ∩ agentovo dovoljenje ∩ politika najemnika ∩ obseg orodja ali podatkov. Če kateri od teh štirih reče ne, se dejanje ne zgodi. To je pravilo, ki preprečuje tržniku, da bi preko preveč navdušenega računovodskega agenta izvlekel plačne podatke.

Vzorci avtentifikacije se jasno ločijo. Ljudje uporabljajo OIDC, SSO in žetone sej. Notranji agenti in storitve uporabljajo kratkotrajne žetone storitev, omejene API ključe in podpisane notranje zahteve, z mTLS, kjer to zahteva mejna doverljivost. Integracije tretjih oseb uporabljajo OAuth, kjer je na voljo, in poverilnice konektorjev z obsegom najemnika, shranjene v trezorju — nikoli trajne glavne ključe, vgrajene v konfiguracijski datoteko. Kontrolna ploskev vse izdaja, rotira in prekliče.

Eksplicitni avtomati stanja in človeški kontrolni punkti so tisto, kar naredi vedenje agenta revidirajočo, ko se agenti dotaknejo stroškov, produkcijskih podatkov ali komunikacije s strankami ^[4]. Ta predvidljivost se začne z identiteto. Če ne morete odgovoriti, kateri človek, kateri agent, kateri najemnik in kateri obseg je dovolil klic orodja — v tem vrstnem redu — nimate upravljanja. Imate upanje.

Prehod za orodja je mesto, kjer se upravljanje dejansko dogaja

Neposredne povezave agent-baza podatkov so način napake v produkciji, o katerem se področje noče pogovarjati. Agenti ne kličejo Stripe neposredno. Agenti ne poizvedujejo po knjigi neposredno. Agenti se ne lotevajo Gmail, tržne platforme ali računovodskega sistema neposredno. Vsak klic orodja se usmeri skozi prehod, ki uveljavi preverjanja dovoljenj, izolacijo najemnikov, validacijo vnosov, filtriranje iznosov, omejitve hitrosti, izolacijo skrivnosti, preverjanja odobritev in strukturirano beleženje — pred vsemi stranskimi učinki.

Spomin tudi ni globalna klada. To je spomin najemnika, spomin uporabnika, spomin agenta, spomin poteka dela in spomin dokumenta, vsak omejen in ozaveščen upravičenj. Če uporabnik ne more brati plačnih list, mora plast pridobivanja preprečiti, da bi se v sejo agenta, ki deluje v sejo tega uporabnika, vključile vložitve, povezane s plačnimi listami. To uveljavlja prehod, ker alternativa — zaupanje vsakemu agentu, da se samonadzorovaje — ni nadzor. To je želja.

Zgraditi to enkrat, centralno, je tisto, kar omogoča podjetju dodati tretji, peti in deseti agent, ne da bi vsakič znova pregovarjali varnost. Zgraditi to za vsako aplikacijo je način, kako organizacije končajo s tremi računovodskimi agenti, štirimi shrambitvenimi prostori skrivnosti in oddelkom za skladnost, ki je nehal vračati klice.

Razvrstite vsako dejanje po stopnji tveganja, preden napišete poziv

Branje javnih tržnih podatkov in prenos sredstev ne moreta deliti odobritvene politike. Dodelite vsakemu dejanju v vašem katalogu orodij stopnjo tveganja od 0 do 5. Stopnja 0 je branje javnih podatkov. Stopnja 1 je branje notranjih podatkov. Stopnja 2 je osnutek ali izračunavanje. Stopnja 3 je pisanje notranjih zapisov. Stopnja 4 je objavljanje, pošiljanje e-poštnih sporočil, oddajanje ali obveščanje zunanjih strank. Stopnja 5 je premikanje denarja, spreminjanje pravnih zapisov, brisanje podatkov ali izvajanje trgov.

Povežite vsako stopnjo s specifičnim pravilom človeškega nadzora. Stopnji 0 in 1 tečeta z beleženjem. Stopnja 2 teče z beleženjem plus metapodatki o zaupanju. Stopnja 3 je omejena na specifične vloge in specifične agente. Stopnja 4 zahteva eksplicitno človekovo odobritev pred izvršitvijo. Stopnja 5 zahteva dvojni nadzor ali je za agente popolnoma blokirana. Agenti, ki odobrujejo stroške, spreminjajo produkcijske podatke ali komunicirajo s strankami, potrebujejo človekovo revizijo pred kritičnimi dejanji, eksplicitni avtomati stanja pa so način, kako to narediti revidirajoče ^[4].

Stanje odobritve samo mora biti prvorazredni objekt: osnutek, zahtevana_revizija, odobreno, zavrnjeno, izvršeno, preklicano. Tržni agent naredi osnutek kampanje in človek odobri, preden platforma objavi. Agent za maržo predlaga spremembe cen in finance odobrijo pred posodobitvami cen. Energijski agent označi priložnost za arbitražo baterije in človek odobri pred izvršitvijo. Agent pripravi. Človek dovoli. Platforma izvrši. Revizijski dnevnik zabeleži vse tri.

Uporabite deterministične storitve za matematiko, agente za razmišljanje

LLM ni vir resnice za stanja knjig, izračune marž, napovedi ali karkoli drugega, kjer ima napaka pripeto številko. Formule marž živijo v deterministični storitvi. Pravila knjiženja v knjigi živijo v deterministični storitvi z validacijami. Usposabljanje modela napovedi živi v statistični ali ML storitvi z različicami vnosov in zabeleženih predpostavkah. Agent koordinira ta orodja, razloži rezultat, klasificira izjeme in naredi osnutek naslednjega koraka.

Pravilna delitev dela v procesu marže je konkretna. Agent prejme zahtevo in kontrolna ploskev preveri dovoljenja. Agent kliče branja knjige, branja računov in branja stroškov izdelkov skozi prehod orodij. Deterministična storitev marže opravi izračun. Agent razloži gonilne sile in predlaga spremembe cen. Predlagane spremembe vstopijo v odobritveni proces. Revizijski dnevnik zabeleži vsak klic orodja, vsako dovolilno odločitev in vsak prehod stanja odobritve. V nobeni točki model ne proizvede številke, ki jo bo CFO podpisal.

Ta delitev tudi ubije skušnjavo za preveč arhitektoriranja. Najprej maksimizirajte zmogljivosti enega agenta; dodatni agenti ustvarijo kompleksnost in režijske stroške, en agent z orodji pa je pogosto dovolj, dokler procesi ne postanejo res preveč zapleteni ali izbira orodij ne odpove ^[1]. Večino tega, za kar ekipe sežejo po multi-agentskih sistemih, dejansko reši dodajanje deterministične storitve za dobro omejenim orodjem.

Začnite z enim agentom in odličnim upravljanjem, ne z multi-agentskim ozvezdjem

Pragmatično zaporedje gradnje ni bleščeče in to je poanta. Najprej skupna identiteta najemnika in uporabnika. Nato register agentov. Nato dovolilni motor, ki temelji na obsegu. Nato prehod orodij. Nato revizijski dnevnik. Nato zgodovina izvajanja agentov. Nato odobritveni proces. Nato register konektorjev. Nato storitev spomin. Nato evalvacija in nadzor. Šele potem izdajte prva enega ali dva agenta visoke vrednosti — agent za maržo in računovodski agent sta dobra kandidata, ker je vrednost merljiva in deterministične storitve že obstajajo.

Vrstni red je pomemben. Ekipe, ki ga obrnejo — izberejo ogrodje, zgradijo agenta, nato pa retroaktivno dodajo upravljanje — so ekipe, katerih pilotni projekti nikoli ne dosežejo produkcije ^[2].

Razdelite v multi-agentske sisteme šele, ko izbira orodij enega agenta resnično odpove: ko poziv opravi preveč dela, ko se opisi orodij trčijo, ko je kontekstno okno enega agenta izčrpano z zmogljivostmi, ki jih redko uporablja. Do takrat en agent z desetimi dobro omejenimi orodji premaga pet agentov z lastnim spominom, lastnimi ključi in lastnimi mnenji o tem, kako klicati Stripe.

Suverenost je arhitekturna izbira, ne označna škatlica skladnosti

Ko kontrolna ploskev upravlja identiteto, skrivnosti, spomin in revizijo za vsako avtonomno pisanje, vprašanje, kje model teče, preneha biti infrastrukturna preferenca in postane vprašanje upravljanja. Vsak poziv, poslan v oblačni LLM API, vsebuje vnose, ki jih je kontrolna ploskev pravkar dovolila — izvlečke knjig, vsebine računov, zapise strank, energijske pogodbe, notranje politične dokumente — plus pogosto sheme orodij, ki opisujejo, kaj sme agent početi. Pošiljanje teh pisanj skozi API tretje osebe spremeni ponudnika modela v največji neupravljan obseg eksplozije v vašem skladu.

Standardi interoperabilnosti kot Model Context Protocol in Agent2Agent so pomembni ^[3], vendar interoperabilnost brez suverenosti pomeni le več končnih točk, ki delijo vaše podatke. Za regulirane delovne obremenitve — finance, energijo, zdravstvo, karkoli pod GDPR — je odgovor lokalna GPU inferenca na odprto-težinskih modelih, ki tečejo na infrastrukturi, ki jo nadzoruje stranka, z isto kontrolno ploskvijo, ki upravlja tako agenta kot model.

To gradi Wavenetic. WaveNode strojna oprema, izvajalno okolje, odprto-težinski modeli, aplikacijska plast, RAG s sledenjem citatov in evropska podpora kot en lokalni, zračno ločen sklad. Revizijske sledi in GDPR-skladno uvajanje niso funkcije, privijačene za skladnost — to je ista kontrolna ploskev, ki jo je arhitektura zahtevala že na prvem mestu. Izberite ogrodje nazadnje. Podjetja, ki uspešno uvajajo agente v produkcijo, so tista, ki so najprej zgradila kontrolno ploskev. Tista, ki so še vedno obtičala v pilotu, so tista, ki so pustila vsaki aplikaciji, da izmisli svoj login, svoje ključe in svojo revizijsko sled.

Rezervirajte tehnično revizijo vaše agentske kontrolne ploskve z našo ekipo — https://wavenetic.com