Guia per a desenvolupadors de protocols i arquitectures d'agents d'IA

Inici » Pitó » Guia per a desenvolupadors de protocols i arquitectures d'agents d'IA

Els agents d'IA estan traslladant el programari d'assistents passius a col·laboradors autònoms que poden percebre el seu entorn, raonar sobre objectius complexos i prendre mesures en nom nostre. Per als desenvolupadors, aquest canvi ho canvia tot: en lloc de connectar fluxos de treball estàtics al voltant d'un LLM, dissenyeu sistemes on el propi model impulsa el flux de control, orquestra les eines i coopera amb altres agents i serveis.

Si vols construir seriosament, sistemes agentius de grau de producció, entendre els protocols emergents ja no és opcionalLes maneres estandarditzades perquè els agents accedeixin a les eines (MCP), es comuniquin entre ells (A2A) i interactuïn amb la web mitjançant llenguatge natural (NLWeb) s'estan convertint ràpidament en la columna vertebral de l'"ecosistema d'agents". En paral·lel, encara cal dominar els components bàsics dels agents: models, eines, instruccions, patrons d'orquestració i barreres de protecció.

Què és exactament un agent d'IA i en què es diferencia d'un LLM simple?

Un agent d'IA s'entén millor com un sistema complet construït al voltant d'un LLM, no només el model en si.La definició acadèmicament acceptada (per exemple a Stanford CS221) descriu un agent com una entitat computacional situada en un entorn, capaç de percebre'l a través de sensors i actuar-hi a través d'actuadors per maximitzar les possibilitats d'èxit respecte a algun objectiu.

En termes pràctics de programari, els agents d'IA moderns combinen quatre ingredients: La gran model de llengua per al raonament, accés a eines i API externes, alguna forma de memòria per fer un seguiment del context al llarg del temps i un objectiu o rol clarament definit. A diferència d'un simple chatbot que només respon preguntes, un agent pot planificar, cridar eines, reaccionar als seus resultats i impulsar iterativament un flux de treball fins que s'assoleix un objectiu.

Una font habitual de confusió és confondre "model" i "agent".Un model com GPT-4 o Llama 3 és un "cervell" potent però passiu: no fa res fins que li envies una indicació i no pot enviar correus electrònics, accedir a les API ni actualitzar bases de dades per si sol. Un agent, en canvi, envolta el model en un bucle de percepció, raonament i acció. Utilitza les prediccions del model per triar quina eina cridar, quan demanar aclariments a l'usuari i quan aturar-se.

La diferència clau és qui controla el flux de treballEn el programari clàssic, el codi dicta la seqüència: si A aleshores B aleshores C. En un agent, l'LLM decideix quin ha de ser el següent pas en funció de l'estat actual. Pot optar per consultar una comanda, obrir un tiquet de suport o transferir el cas a un altre agent, tot des de la mateixa sol·licitud d'alt nivell.

Els agents també varien en sofisticació, des de sistemes reactius simples fins a arquitectures d'aprenentatge orientades a objectius.La taxonomia clàssica de Russell i Norvig encara és útil per entendre el panorama: s'obtenen agents reactius simples (regles pures de si-llavors), agents reactius basats en models (amb un estat intern mínim), agents basats en objectius (que planifiquen cap a un resultat desitjat), agents basats en la utilitat (que optimitzen una puntuació numèrica sobre molts resultats possibles) i agents d'aprenentatge (que adapten la seva política en funció de la retroalimentació).

Per què importen els protocols a l'era dels agents d'IA

A mesura que els agents es tornen més capaços i generalitzats, apareixen ràpidament tres problemes: el cost d'integració, la interoperabilitat i la seguretat.El codi ad hoc per a cada API o sistema associat no s'escala. Els formats propietaris i únics bloquegen la col·laboració entre eines i agents de diferents proveïdors. I cada nova integració augmenta la vostra superfície de seguretat.

Els protocols centrats en agents tenen com a objectiu resoldre exactament aquests punts problemàtics definint estàndards oberts per a: com els amfitrions exposen eines i context als LLM (Model Context Protocol o MCP), com els agents es comuniquen amb altres agents a través de les fronteres organitzatives i tècniques (Agent-to-Agent o A2A) i com els llocs web exposen el seu contingut i accions d'una manera que prioritza el llenguatge natural tant per a humans com per a agents (Natural Language Web o NLWeb).

Per als desenvolupadors, aquests protocols es comporten com a "adaptadors universals" i "targetes de visita" per a agents i serveis.En comptes de codificar desenes d'integracions, s'integra una vegada amb servidors MCP, equivalents compatibles amb A2A o llocs NLWeb, i es deixa que el protocol gestioni el descobriment, les capacitats i l'autenticació. Això redueix dràsticament la lògica d'integració personalitzada i permet canviar de model o eina sense reescriure tota la fontaneria.

Alhora, la seguretat a nivell de protocol esdevé essencialEl control d'accés, l'autenticació estandarditzada i les descripcions clares de les capacitats a la capa de protocol faciliten molt el raonament sobre qui pot fer què, des d'on i sota quines restriccions, cosa fonamental en entorns empresarials on els agents poden tenir permís per tocar inventari, pagaments o dades sensibles dels clients.

Protocol de context de model (MCP): un adaptador universal per a eines i dades

El Model Context Protocol és un estàndard obert que defineix com les aplicacions poden proporcionar eines i dades contextuals als agents basats en LLM.Conceptualment, MCP s'interposa entre els agents i els sistemes existents (bases de dades, API SaaS, serveis interns) i els converteix en un conjunt unificat de capacitats que es poden descobrir.

MCP segueix una arquitectura client-servidor amb tres rols principals: l'amfitrió (una aplicació LLM com ara un IDE, un client de xat o un temps d'execució d'agent) que inicia les connexions, els components del client dins d'aquest amfitrió que mantenen connexions un a un amb els servidors MCP i els propis servidors, que són programes lleugers que exposen capacitats específiques.

Dins de MCP, els servidors anuncien tres primitives principals que els agents poden utilitzar de manera coherent: eines, recursos i indicacions. Les eines són accions discretes —“get_weather”, “purchase_product”, “search_flights”— amb noms, descripcions i esquemes d'entrada/sortida. Els recursos són elements de dades de només lectura com ara fitxers, files de base de dades o registres, que poden ser de text o binaris. Les indicacions són plantilles predefinides que encapsulen patrons d'enginyeria d'indicacions o fluxos de diversos passos.

El descobriment dinàmic d'eines és un dels grans èxits de MCPEn comptes de codificar que un assistent de viatge té una funció "searchFlights" amb una signatura específica, l'agent es connecta al servidor MCP de la companyia aèria i demana la seva llista de capacitats. El servidor retorna descripcions llegibles per màquina de les eines, els seus arguments i les respostes esperades. Quan la companyia aèria afegeix una eina "upgrade_booking", el vostre agent la descobreix sense canvis de codi, sempre que respecteu el contracte MCP.

MCP també és deliberadament agnòstic del modelCom que el protocol tracta sobre capacitats i context, no sobre l'API de cap proveïdor, el mateix servidor MCP es pot utilitzar des de diferents LLM o frameworks d'agents. Això permet experimentar amb intercanvis de models o estratègies multimodel (per exemple, utilitzant un model petit i econòmic per a fluxos simples i un de potent per a raonaments complexos) sense haver de refer les integracions.

Un altre avantatge és la seguretat estandarditzadaL'MCP pot incloure mecanismes d'autenticació consistents, cosa que és molt més fàcil de mantenir que fer malabars amb un munt de fluxos d'autenticació personalitzats per a cada API de tercers. Per a les empreses, això significa un escalat més net des d'"una integració en fase de proves" fins a "centenars de servidors MCP en producció" sense perdre el control de les claus i els permisos.

Un exemple concret aclareix el paper de MCPImagineu-vos un usuari que demana a un assistent de viatges d'IA que "em trobi un vol de Portland a Honolulu i el reservi". L'assistent, actuant com a client MCP, es connecta al servidor MCP de la companyia aèria, enumera eines com ara "search_flights" i "book_flight", invoca "search_flights" amb els paràmetres correctes, rep els resultats JSON, els presenta a l'usuari i després crida "book_flight" en funció de l'opció escollida. L'assistent mai crida directament les API internes de la companyia aèria; simplement parla MCP.

Agent-to-Agent (A2A): un protocol per a la col·laboració multiagent

Mentre que MCP se centra en connectar agents a eines i dades, el protocol Agent-to-Agent tracta de connectar agents entre si.Tan bon punt deixis de ser un "superagent" monolític i passis a ser un ecosistema d'agents especialitzats (viatges, facturació, logística, suport...), necessiteu una manera clara perquè es descobreixin mútuament, intercanviïn context i col·laborin en tasques compartides.

A2A està dissenyat per donar suport a aquest tipus d'orquestració distribuïda i entre organitzacions.Permet que agents de diferents empreses, piles i entorns d'allotjament treballin junts a petició d'un usuari sense haver de cablejar cada ruta d'interacció per endavant. Un "agent de viatges" compatible amb A2A pot trucar a un "agent de companyia aèria", un "agent d'hotel" i un "agent de lloguer de cotxes" creats per equips completament diferents.

Cada agent A2A exposa una targeta d'agent llegible per màquina que juga un paper similar a la llista de capacitats de MCP, però a nivell d'agent en lloc d'eina. Una targeta d'agent conté el nom de l'agent, una descripció en llenguatge natural del que gestiona, una llista d'habilitats amb explicacions de quan cridar-lo, l'URL del punt final actual, informació de la versió i indicadors com ara si admet respostes en temps real o notificacions push.

Al costat de la persona que truca, un executor d'agents és responsable de transferir el context i gestionar la interacció.Quan un agent local decideix delegar una subtasca, el seu executor empaqueta la conversa actual, l'estat rellevant i qualsevol restricció, i els envia a l'agent remot per A2A. L'agent remot executa les seves pròpies eines internes i el bucle LLM, i després retorna el resultat sense que la persona que truca hagi de conèixer els seus components interns.

El resultat d'una tasca remota completada es retorna com un artefacte.Un artefacte normalment inclou la sortida de la tasca, una breu descripció del que s'ha fet i el context textual que ha fluït a través del protocol. Un cop lliurat l'artefacte, la connexió A2A es pot tancar, mantenint cada interacció amb àmbit limitat i econòmica, alhora que permet una cooperació rica.

Per a tasques de llarga execució o asíncrones, A2A sovint es basa en una cua d'esdevenimentsEn lloc de mantenir les connexions obertes durant minuts mentre un agent remot processa dades o espera en sistemes externs, la cua d'esdeveniments gestiona el pas de missatges i les actualitzacions. Això és especialment important en sistemes multiagent de nivell de producció on la resiliència de la xarxa, els reintents i la contrapressió són importants.

Els beneficis d'A2A reflecteixen els de MCP però a nivell d'ecosistema. S'obté una millor col·laboració entre agents heterogenis, flexibilitat per triar la millor estratègia LLM o d'ajustament fi per agent i autenticació integrada perquè les trucades entre agents siguin segures i auditables. Esdevé realista crear "equips d'agents" que abastin diversos proveïdors en lloc d'intentar abarrotar totes les capacitats en un sol monòlit.

Web en Llenguatge Natural (NLWeb): fent que la web sigui fàcil d'utilitzar per a agents web

El web es va construir al voltant de documents i HTML, no al voltant de converses i agentsEls usuaris han navegat llargament per menús i quadres de cerca per extreure informació dels llocs web, mentre que l'accés automatitzat normalment es basava en un scraping fràgil o API personalitzades. NLWeb proposa un model diferent: llocs web que parlen llenguatge natural de forma nativa, tant per a humans com per a agents d'IA.

Un desplegament NLWeb gira al voltant d'una aplicació NLWeb central—el codi de servei principal que rep preguntes en llenguatge natural, es connecta a l'emmagatzematge i als models i retorna respostes estructurades. Podeu pensar-hi com el "motor lingüístic" del vostre lloc web, que orquestra les incrustacions, la cerca vectorial i el raonament LLM.

El protocol NLWeb defineix les regles bàsiques per a aquesta interacció en llenguatge natural.Estandarditza com s'envien les preguntes i com es retornen les respostes, normalment en format JSON amb vocabularis com Schema.org. De la mateixa manera que l'HTML estandarditza l'intercanvi de documents, NLWeb pretén estandarditzar l'accés basat en llenguatge al contingut i les accions del lloc, preparant el camí per a una "web d'IA".

Cada instància de NLWeb també actua com a servidor MCPAixò vol dir que pot exposar eines (com ara un mètode "ask") i recursos de dades a sistemes d'IA externs a través de MCP. Des de la perspectiva d'un agent, el vostre lloc web esdevé només un altre punt final de MCP: pot cridar "ask" amb una pregunta, rebre una resposta estructurada vinculada a entrades reals del vostre catàleg i evitar al·lucinacions de productes o pàgines inexistents.

Sota el capó, NLWeb es basa en gran mesura en models d'incrustació i bases de dades vectorials.Quan ingereixes contingut del teu lloc web (fitxatges de productes, descripcions d'hotels, entrades de blog), NLWeb els converteix en incrustacions vectorials i els emmagatzema en un magatzem vectorial compatible com ara Qdrant, Milvus, Azure AI Search, Snowflake o Elasticsearch. En el moment de la consulta, recupera els elements més similars i els passa, juntament amb la pregunta de l'usuari, a un LLM per elaborar una resposta basada en contingut real.

Un lloc web de reserves de viatges és un gran exemple de NLWeb en acció.Ingereixes dades estructurades per a vols, hotels i paquets (idealment utilitzant Schema.org o canals RSS), crees incrustacions i les emmagatzemes. Quan un usuari escriu "troba'm un hotel familiar a Honolulu amb piscina la setmana vinent" en un xat, NLWeb consulta el magatzem vectorial per trobar hotels rellevants, permet que l'LLM interpreti "familiar" i altres restriccions suaus, i retorna una resposta en llenguatge natural amb un inventari real. La mateixa instància de NLWeb, a través de la seva interfície MCP, permet que un agent de viatges extern pregunti, per exemple, sobre restaurants vegans a prop d'aquests hotels i obtingui un JSON coherent i utilitzable per màquina.

Quan té sentit construir un agent d'IA

No tots els problemes necessiten un agent; de vegades un servei determinista simple és millor.Els agents destaquen quan el flux de treball no es pot capturar fàcilment com un conjunt rígid de regles, quan hi ha una forta dependència de dades no estructurades o quan el nombre d'excepcions i casos límit fa que el manteniment de les regles sigui dolorós.

Tres famílies de casos d'ús són especialment adequades per als agentspresa de decisions complexes (per exemple, decidir si s'aprova el reemborsament d'un client segons polítiques matisades), conjunts de regles difícils de mantenir (com ara revisions de seguretat de proveïdors complexes o comprovacions de compliment) i fluxos dominats pel llenguatge natural (processament de reclamacions, sol·licituds de clients de format lliure, tasques de recerca).

Una heurística útil és observar sistemes que han crescut mitjançant pegats infinits i regles de casos especials.Si fins i tot els enginyers sèniors tenen dificultats per predir el comportament o codificar nous canvis de polítiques sense trencar res més, és probable que el problema subjacent sigui semàntic, no purament lògic. Aquest és el territori perfecte per a un agent basat en LLM que pugui raonar sobre text, polítiques i exemples.

En canvi, per a tasques altament deterministes amb entrades i sortides clares, el codi clàssic normalment serà més barat, més ràpid i més fiable.Si la vostra tasca és "convertir aquest número a un altre format" o "executar aquesta consulta SQL i retornar files", afegir un bucle d'agent a sobre probablement és una complexitat innecessària.

Els components bàsics d'un agent d'IA

Malgrat tot l'enrenou, l'estructura interna d'un agent ben dissenyat és força senzilla.Gairebé tots els patrons es redueixen a tres pilars: el model que fa el raonament, les eines que es connecten amb el món exterior i les instruccions que restringeixen i guien el comportament.

El model és el motor de decisióDiferents LLM (Learning Learning Models) equilibren la qualitat del raonament, la latència i el cost. Una estratègia comuna i pragmàtica és: començar amb un model altament capaç per establir una línia de base de qualitat i entendre què significa "bo" en el vostre domini, i després provar progressivament models més petits o més econòmics per a subtasques com la classificació o la recuperació on no es requereix el raonament màxim.

Les eines amplien l'agent més enllà del text purSón funcions, API o serveis que l'agent pot cridar: consultar una base de dades, enviar un correu electrònic, cercar a la web, interactuar amb una interfície d'usuari antiga a través d'un model d'ús de l'ordinador, etc. Les eines ben dissenyades estan documentades, reutilitzables entre agents i idealment exposades a través de protocols estàndard com MCP.

Les instruccions són la part més infravalorada d'un agentNecessiteu més que "ser útils". Les instruccions d'alta qualitat descriuen com descompondre les tasques, com comportar-se quan falta informació, quines eines preferir en quines situacions, què compta com a èxit i què evitar. Molts equips reutilitzen amb èxit SOP, documents del centre d'ajuda o manuals interns existents convertint-los en directrius numerades i compatibles amb el LLM que el model pot seguir.

Cada cop és més comú generar o refinar instruccions automàticament utilitzant els propis LLM.Per exemple, podeu introduir un article del centre d'ajuda en un meta-prompt que demani al model que el reescrigui com un conjunt clar i numerat d'instruccions d'agent, incloent-hi la gestió explícita dels casos límit. Això manté el comportament alineat amb la vostra documentació a mesura que evoluciona.

Patrons d'orquestració: sistemes d'un sol agent vs. sistemes multiagent

Sota el capó, els agents s'executen en un bucle: observar l'estat actual, decidir què fer, actuar (sovint mitjançant una eina), actualitzar el context i repetir fins que es compleixi una condició d'aturada (objectiu assolit, error, intervenció de l'usuari o desviació de la barrera de protecció). Aquest "bucle d'agent" és el que converteix una trucada LLM d'una sola vegada en un motor de flux de treball continu.

L'arquitectura més simple és un agent únic amb einesRep els missatges de l'usuari, explica els seus motius, decideix quines eines cridar i retorna respostes. Els frameworks sovint exposen un component runner que continua cridant el model fins que es compleix algun criteri de terminació, com ara "no hi ha més crides a eines útils" o "s'ha produït una sortida estructurada". Aquest patró és ideal per a versions primerenques i per a problemes ben definits.

A mesura que la complexitat creix, els equips sovint passen a topologies multiagentHi ha dos tipus principals. En un patró de gestor, un agent "orquestrador" central delega subtasques a agents especialitzats exposats com a eines, com ara traductors a diferents idiomes, un agent de recerca i un crític. El gestor manté el control global i ho uneix tot.

El segon patró és més descentralitzatAquí, els agents transfereixen la feina als seus companys quan detecten que una sol·licitud cau fora del seu domini. Un agent de triatge podria encaminar els missatges dels clients a agents d'assistència tècnica, vendes o gestió de comandes, cadascun amb les seves pròpies instruccions i eines. El flux de control salta entre agents sense un únic planificador central.

Ambdós patrons es poden combinar naturalment amb A2A a major escala.Dins d'un límit de producte o microservei, podeu utilitzar un model d'orquestrador més especialistes, mentre que a través d'empreses o departaments confieu en A2A per parlar amb agents externs que anuncien les seves capacitats a través de targetes d'agent.

Baranes de seguretat: mantenint els agents autònoms segurs i fiables

Donar autonomia als agents també significa acceptar nous riscos: podrien filtrar dades sensibles, fer canvis no autoritzats o prendre mesures amb impacte financer o de reputació. Les baranes de seguretat són la capa protectora que gestiona aquests riscos sense neutralitzar la utilitat de l'agent.

El disseny defensiu sol incloure múltiples capes de baranes de proteccióAlguns operen sobre entrades (bloquejant o sanejant sol·licituds malicioses o fora de l'abast), alguns sobre decisions intermèdies del model (comprovant si una acció està permesa abans d'executar-la) i alguns sobre sortides (filtrant per seguretat, compliment o fuites de dades abans que les respostes surtin del sistema).

En moltes implementacions, les barreres de seguretat funcionen "en paral·lel" al progrés optimista de l'agent.El bucle de l'agent avança, però passos específics, com ara una crida d'eina que pot editar dades, estan incloses en comprovacions de guardrail. Si el guardrail detecta una violació, pot aturar l'acció, generar una excepció o escalar a un operador humà.

Algunes baranes de protecció estan impulsades per LLM centrats en límits i riscos o fins i tot agentsPer exemple, podeu mantenir un agent dedicat a la detecció de rotacions que avaluï els missatges entrants dels clients i marqui els que indiquen un alt risc de cancel·lació. Una barrera de seguretat de nivell superior utilitza aquest senyal per activar fluxos de treball de retenció o exigir una revisió humana obligatòria abans de tancar la interacció.

Les baranes operatives també inclouen límits estrictes i escotilles d'escapament.El nombre màxim de passos per evitar bucles infinits, els llindars basats en el risc que obliguen a l'aprovació humana per a accions sensibles i les solucions alternatives clares quan la confiança del model és baixa contribueixen a un desplegament segur en entorns reals.

De la teoria a la pràctica: un disseny pas a pas d'un agent de suport a les comandes

Per fonamentar aquestes idees, considereu l'evolució d'un sistema de suport a comandes per a una botiga en línia.La versió inicial sol ser només un punt final reactiu: donat un ID de comanda, s'obté el seu estat de la base de dades i es retorna. No hi ha raonament, ni memòria ni flux de treball; això encara no és un agent.

El primer pas agentiu és deixar que el model controli el flux de treballEn comptes de suposar que l'ID de la comanda és present, introduïu la conversa completa al model i deixeu que decideixi què fer. Si l'usuari pregunta "On és el meu paquet?" sense proporcionar un ID, el model pot triar una acció "ASK_FOR_ORDER_ID" i demanar a l'usuari més informació.

A continuació, emboliqueu aquest raonament en un bucle i introduïu l'estatDesprés de cada missatge d'usuari o crida a una eina, l'agent reavalua la situació. Pot obtenir una ordre, actualitzar el context, comprovar si té prou informació per respondre o fer una pregunta de seguiment. El bucle només s'atura un cop s'ha enviat una resposta clara o s'ha assolit una condició de finalització.

A mesura que l'abast s'amplia més enllà de les comprovacions d'estat, l'agent comença a seleccionar eines dinàmicament en funció de la intenció.Un problema d'enviament pot dirigir-se a "open_incident", una sol·licitud de reemborsament a "initiate_refund" i una simple consulta d'estat a "get_order_status". No codifiqueu un arbre fix de branques if-else; en canvi, el model tria accions d'un menú d'eines definides per vosaltres o descobertes mitjançant MCP.

En aquest punt, introduïu les baranes de seguretat i l'avaluació de riscos al voltant de les eines sensibles.Les operacions de només lectura es poden executar directament, però qualsevol cosa que canviï d'estat (emetre reemborsaments, cancel·lar comandes, modificar adreces) passa per una barrera de seguretat que detecta riscos. Les accions d'alt risc requereixen aprovació humana; les accions de risc mitjà poden activar confirmacions addicionals; les accions de baix risc poden procedir automàticament.

Finalment, establiu els límits operatius i les regles de traspàs humà.Si l'agent aconsegueix un nombre màxim d'intents fallits, troba informació contradictòria o s'enfronta a una decisió d'alt risc fora del seu àmbit d'actuació, passa tot el context acumulat a un agent de suport humà. Aquest enfocament híbrid permet desplegar l'autonomia de manera segura i, alhora, mantenir el control sobre els casos límit.

Marcs de raonament avançats i eines modernes per a agents

A més d'aquests conceptes bàsics de l'arquitectura, els marcs de raonament avançats ajuden els LLM a comportar-se més com a agents deliberats que com a oracles de caixa negra.Dos patrons populars són la Cadena de Pensament (Cadena de Pensament) i la Reacció (Raó + Actuació).

La cadena de pensament simplement demana al model que pensi pas a pas, descomponent preguntes complexes en passos de raonament intermedis abans de produir una resposta final. La recerca demostra que això pot millorar significativament el rendiment en tasques amb un alt contingut de raonament en models més grans, i es correspon de manera natural amb el bucle d'agent: cada crida a l'eina encaixa en una cadena de raonament més àmplia.

ReAct vincula estretament el raonament amb l'ús d'einesL'agent alterna explícitament entre pensaments, accions i observacions: explica què pretén fer, crida una eina, examina la sortida i actualitza el seu pla. Aquest patró sustenta molts dels primers sistemes d'agents autònoms com AutoGPT i BabyAGI, que generen i reprioritzen dinàmicament llistes de tasques pendents cap a un objectiu de l'usuari.

Els frameworks i SDK moderns encapçalen aquestes idees en abstraccions fàcils de fer servir per als desenvolupadors.Biblioteques com LangChain, LangGraph, CrewAI o conjunts d'eines més petits d'estil "smolagents" proporcionen blocs de construcció per a la crida d'eines, fluxos de treball basats en grafs, orquestració multiagent i memòria persistent. Moltes d'aquestes cadenes d'eines també inclouen guia per a agents personalitzats a VS CodeLes plataformes propietàries de proveïdors i actors del núvol com OpenAI afegeixen construccions de nivell superior per a agents, barreres de protecció i avaluacions.

És important destacar que aquests marcs de treball s'integren cada cop més amb protocols com MCP, A2A i NLWeb.En lloc d'integrar connectors puntuals, els agents poden connectar-se a capes de capacitat estandarditzades, comunicar-se amb agents externs mitjançant targetes d'agent i tractar els llocs web habilitats per a NLWeb com a API de llenguatge natural de primera classe. Aquesta convergència entre protocols i eines és el que permet ecosistemes d'agents interoperables a gran escala.

Tot això es troba en un continu que va des de solucions sense codi fins a solucions d'alt codi.Les plataformes visuals en l'espai sense codi permeten als no desenvolupadors compondre fluxos de treball i eines d'agents amb interfícies d'arrossegar i deixar anar i configuracions de llenguatge natural. A l'altre extrem, els entorns d'alt codi donen als enginyers un control precís sobre l'orquestració, l'avaluació i el desplegament, sovint combinant marcs de treball amb infraestructura personalitzada en AWS, Azure o núvols similars.

En tot aquest espectre, les organitzacions que guanyen són les que aprenen a dissenyar agents, no només a consumir-los.Comprendre els protocols, els patrons i les barreres de seguretat us permet anar més enllà dels experiments de "provar un chatbot" i avançar cap a una automatització robusta i escalable: des d'agents d'anàlisi interns i copilots de desenvolupadors, fins a sistemes multiagent que coordinen l'inventari, els pagaments i l'experiència del client en temps real. A mesura que els agents continuen madurant, aquestes habilitats de disseny esdevenen un veritable avantatge competitiu.