Dacă îți construiești un agent în cod, framework-ul are deja un mod de a defini un instrument. O funcție, o schemă, un docstring — trei dintre astea și agentul tău poate face ceva.
Atunci de ce să pui un gateway la mijloc? Noi construim unul, deci scade corespunzător. Răspunsul onest este că pentru primele câteva instrumente nu ar trebui.
Ce îți aduce scrierea lor de mână
Lucruri reale, care merită numite înainte de a argumenta împotriva lor.
Scheme exacte. Tu decizi care sunt argumentele, cum se numesc și ce spune descrierea. Modelele citesc descrierile instrumentelor așa cum dezvoltatorii citesc semnături de funcții, iar un instrument croit exact pentru sarcina ta va bate unul generic.
Logică de business în instrument. create_customer poate valida după
regulile tale, îmbogăți din baza ta de date și scrie în două sisteme, iar agentul
vede un singur verb curat în loc de patru pași de secvențiat.
Fără indirecție. Când se strică ceva, ai o urmă de stivă în codul tău, nu un apel către un serviciu care a returnat o eroare pe care trebuie să o interpretezi.
Pentru cele două-trei instrumente care sunt produsul tău, scrie-le. Nimic din ce urmează nu schimbă asta.
Ce costă la al douăzecilea
Problema este că majoritatea instrumentelor dintr-un agent real nu sunt produsul tău. Sunt Gmail, Slack, CRM-ul, tracker-ul — acces de tip marfă la sisteme construite de altcineva. Și fiecare aduce aceeași taxă:
- o aplicație OAuth de înregistrat la furnizorul acela și de reînregistrat când li se schimbă procesul de verificare
- o buclă de reînnoire a token-ului, scrisă din nou, subtil altfel
- un secret de stocat undeva unde o echipă întreagă îl poate folosi în siguranță
- un al doilea cont al aceleiași aplicații, între care trebuie rutat
- limite de rată și paginare, per furnizor, la nesfârșit
- o pistă de audit, dacă vrei una, pe care acum o scrii tu
Nimic din toate astea nu e greu. Toate sunt aceeași muncă per furnizor, nu se compun în nimic și nu sunt ce ți-ai propus să construiești.
Partea pe care framework-urile chiar nu ți-o dau
Două lucruri, și sunt motivul pentru care comparația asta nu e doar despre efort.
Aplicarea regulilor. Un instrument scris de tine poate fi apelat de agentul tău oricând decide modelul. Dacă vrei „citește orice, nu șterge nimic”, trebuie să construiești singur verificarea aceea, într-un loc prin care trec toate apelurile — adică un gateway, doar că unul pe care acum îl întreții tu. Majoritatea configurărilor scrise de mână nu ajung niciodată să îl construiască, iar regula rămâne o propoziție într-un prompt, care concurează cu mesajul utilizatorului și pierde ocazional.
Atribuirea între oameni. Agentul tău rulează cu credențialele serviciului tău. Când îl folosesc cinci oameni, jurnalele furnizorului spun că serviciul a făcut totul. Răspunsul la „cine a cerut asta” înseamnă să construiești propriul strat de audit deasupra.
Un gateway ți le dă pe amândouă prin construcție: reguli citire/scriere/distructiv verificate la fiecare apel înainte ca ceva să ajungă la furnizor, instrumente blocate care nici nu îi sunt oferite modelului, și fiecare apel înregistrat cu instrumentul, argumentele, rezultatul și persoana în numele căreia a acționat.
Una lângă alta
| Instrumente scrise de tine | Prin gateway | |
|---|---|---|
| Control asupra schemei | Total | Forma furnizorului |
| Logică de business în instrument | Da | Nu e treaba gateway-ului |
| Aplicații OAuth per furnizor | Ale tale de înregistrat | Deja făcute |
| Reînnoirea token-ului | A ta de scris | Rezolvată |
| Două conturi ale unei aplicații | Proiectezi tu rutarea | Adresate prin sufix |
| Aplicarea permisiunilor | O construiești | Per aplicație, la fiecare apel |
| Atribuire | O construiești | Per persoană, per apel |
| Funcționează în alți clienți | Doar în agentul tău | În orice client MCP |
| Timp până la al douăzecilea instrument | De douăzeci de ori primul | La fel ca primul |
Cea care decide
Întrebarea nu este care abordare e mai puternică. Este care instrumente sunt de fapt ale tale.
Un instrument care codifică ceva ce știe doar compania ta — regulile tale de preț, modelul tău de date, definiția ta pentru un lead calificat — ar trebui să fie cod scris de tine, cu o schemă aleasă de tine. Nimeni nu ți-o poate da.
Un instrument care citește Gmail nu este al tău. Este același instrument pe care îl construiește toată lumea, iar construirea lui din nou nu îți aduce nimic în afară de întreținere.
Majoritatea agenților au nevoie de trei din primul fel și douăzeci din al doilea. Aranjamentul care reflectă asta: propriul tău server MCP sau instrumente de framework pentru cele trei, un gateway pentru cele douăzeci. Un client MCP poate vorbi cu amândouă deodată, iar agentul tău nu simte diferența.