La settimana scorsa abbiamo spedito Non più di mesi di sprint di ingegneria – in una settimana, con 10 sessioni di Membrane Agent in esecuzione in parallelo. 1,000 API integrations Gli universi membranosi Membrane Universe è la nostra libreria di conoscenze di integrazione prefabbricate – tutto ciò di cui un agente o uno sviluppatore ha bisogno per connettersi alle API esterne. Ci sono molti tipi di elementi in esso, ma per questo progetto ci siamo concentrati su due: Connettori, che definiscono come connettersi a un'API esterna (autenticazione tramite OAuth2, chiavi API, ecc., più raccolte di dati e eventi) Pacchetti di azione, che sono raccolte di azioni API pronte all'uso (ad esempio, "Create a Slack message", "List GitHub repos") che agenti e flussi di lavoro possono chiamare. Per i pacchetti di azione, non cerchiamo di essere esaustivi - generamo le azioni più comuni che coprono ~80% dell'uso tipico. Costruire ogni integrazione manualmente richiede uno sviluppatore - studiare i documenti, scoprire l'auth, implementare il client, scrivere test. A questo tasso, 1.000 integrazioni richiederebbero a una persona circa un anno di lavoro a tempo pieno. Abbiamo usato LLM per accelerare questo dai primi giorni di gpt-3.5, ma è sempre stato ad hoc. 30–60 minutes Membrane Agent sa già come lavorare con la nostra piattaforma. Abbiamo costruito un pipeline di lotti per elaborare automaticamente migliaia di applicazioni. We saw the opportunity to industrialize it La costruzione del gasdotto Il pipeline ha due fasi, ciascuna guidata dal proprio script di lotto. Fase 1 si occupa dell'autenticazione - la parte più difficile di qualsiasi integrazione. Fase 2 strati sulle azioni che rendono utile ogni integrazione. Entrambi seguono lo stesso modello: raccogliere applicazioni ammissibili, spin up agenti AI simultanei, convalidare i risultati, pubblicare ciò che passa, bandiera ciò che non fa. Fase 1 - Autenticazione (connettori di costruzione) Questo script gestisce il primo passo: implementare auth per ciascuna app. How it works: Raccoglie tutte le app dalla nostra API, filtra a quelle senza un connettore ancora Per ogni app (che funziona fino a 10 contemporaneamente), esso: Crea un record di connettore in Membrane Crea una sessione di agente nel nostro motore Agente di membrana locale alimentato da Claude Dice all'agente quale connettore implementare - l'agente sa come interagire con Membrane dal suo prompt di sistema e come costruire connettori attraverso abilità pre-caricate, quindi il messaggio utente è solo il nome dell'app e l'URL Aspetta che l'agente finisca (~ 2,5 minuti in media) Valida il risultato contro i nostri schemi – questo ciclo di feedback è importante per gli agenti, poiché possono correggere se stessi quando la convalida fallisce In caso di validità: pubblica il connettore e lo rende pubblico In caso di validità: seleziona l'app per la revisione manuale What Membrane Agent actually does inside each session: In primo luogo, l’agente utilizza e Legge attraverso i documenti, scopre se l'API utilizza OAuth2, API keys, Basic auth o altro, e configura tutti i pertinenti parametri auth - client ID / campi segreti, scopi, URL token, le opere. web search web fetch Quindi implementa un client API che attaccano correttamente le credenziali alle richieste, scrive una funzione di test per verificare la connessione e effettivamente effettua richieste HTTP all'API per confermare che è raggiungibile e risponde correttamente. Infine, utilizza gli strumenti di Membrane per scrivere tutta la configurazione indietro sulla piattaforma. E l’agente lo fa completamente autonomamente. 2.5 minutes per app Fai la matematica: Questo è circa 10 connettori costruiti e convalidati ogni pochi minuti - senza un singolo tocco di tasti umani. e 10 è solo ciò che ci siamo stabiliti per ora - la concorrenza è configurabile e potrebbe andare più in alto. 10 agents, ~2.5 minutes each, running in parallel Ogni agente gestisce un connettore (o un pacchetto di azioni) per sessione. Lo manteniamo deliberatamente su un elemento per sessione per evitare di gonfiare la finestra di contesto - una nuova sessione per ogni app significa che l'agente rimane focalizzato. Fase 2 - Azioni (Pacchetti di costruzione) Una volta che un'app è auth configurata, è pronta per la seconda fase: generando le azioni che rendono l'integrazione effettivamente utile. Questo script prende ogni app che ha già un connettore e crea un pacchetto di azioni per esso. Lo script filtra le applicazioni che hanno un connettore con auth ma non hanno ancora un pacchetto, quindi genera un agente per ciascuno. Ogni agente conosce il suo ID di connettore e viene detto di implementare il pacchetto. Esso ricerca l'API dell'app, identifica i punti finali più popolari e utili e crea definizioni di azione - completa con schemi di input, configurazione di richiesta API, schemi di uscita e linee guida opzionali per il comportamento non ovvio. Dopo la convalida (verifica del pacchetto ha effettivamente azioni), viene pubblicato e reso pubblico. L’architettura Ecco come appare l'intero sistema quando si zooma fuori: Dettagli tecnici chiave In concorrenza 5–10, si procede Ecco cosa rende questo funzionamento affidabile: ~100 apps per batch run Sessione di tracciamento Ogni sessione di agente viene tracciata nel nostro cloud, anche se gli agenti vengono eseguiti localmente durante le costruzioni di lotti. Lo script crea le sessioni nella nostra piattaforma e dopo che ogni agente finisce, e sincronizza tutti i messaggi di conversazione. Ciò significa che possiamo rivedere ogni decisione AI attraverso la nostra interfaccia utente della console, esattamente come se fosse una sessione ospitata nel cloud. Validazione e gestione degli errori Non tutte le app possono essere automatizzate. lo script gestisce il fallimento in modo grazioso: Validazione schema: dopo che l'agente è finito, validiamo il risultato contro i nostri schemi SDK. Se non passa (mancanza di campi richiesti, struttura sbagliata), l'app viene contrassegnata. API morti: l'agente viene istruito a lasciare auth vuoto e a spiegare perché se l'API non è disponibile. Timeout: Se Claude viene bloccato su un'API particolarmente complicata (anche se non accade spesso), la sessione è contrassegnata come fallita e può essere ripristinata. Quando un agente fallisce su un'app, rivediamo la sessione per capire perché - è stata una lacuna nelle abilità dell'agente? Uno strano modello API? cattiva documentazione? Risolviamo il problema sottostante, riavviamo e ogni lotto diventa migliore dell'ultimo. La conoscenza dell'agente Questa è la chiave: l'agente non inizia da zero per ogni API. Il suo prompt di sistema è assemblato da più fonti di conoscenza: Panoramica della piattaforma di membrana (che cosa è Membrane, come funziona il framework) abilità di costruzione di connettori (un flusso di lavoro step-by-step proprietario per implementare auth. determinare il tipo auth, leggere documenti specifici per auth-type, configurare parametri, implementare client API, implement test) abilità OpenAPI (come trovare e interrogare incrementalmente le specifiche OpenAPI senza caricare intere schemi nel contesto), Istruzioni di implementazione dettagliate per le funzioni di connettore di base. Il nostro framework di agenti supporta il caricamento delle competenze su richiesta durante una sessione, ma per il trattamento dei lotti abbiamo scoperto che pre-caricare le competenze chiave direttamente nel prompt del sistema funziona meglio. Ciò significa che l'agente ha una profonda conoscenza dei modelli della nostra piattaforma prima di guardare l'API di destinazione. Il livello manuale Non tutto è completamente automatizzato – e questo è per design. Alcune cose hanno ancora bisogno di un uomo: Case Edge: Alcune API sono indocumentate ma funzionali.Le abbiamo scoperte durante la revisione e le abbiamo gestite manualmente. Revisione della qualità: rivediamo le sessioni degli agenti attraverso la nostra console, specialmente per le app in cui la convalida ha fallito. Nessuna credenziale reale: attualmente, l'agente non autentica con chiavi API reali. Verifica che le API siano raggiungibili e che l'auth sia configurato correttamente, ma non completa i veri flussi OAuth. Stiamo costruendo attivamente l'automazione del browser per la generazione automatica di account di test per colmare questo divario. Cosa è Successivo Nelle prossime settimane stiamo lanciando pubblicamente Membrane Universe, a partire da applicazioni di nicchia e oscure - API di vecchia scuola, sistemi scarsamente documentati. Il più grande divario al momento è il test delle credenziali reali. stiamo costruendo l'automazione del browser per la registrazione automatica e i flussi OAuth in modo che gli agenti possano verificare le integrazioni end-to-end. Più a lungo termine: manutenzione continua. le API cambiano, i punti finali vengono deprecati. Gli stessi agenti che hanno costruito queste integrazioni li manterranno aggiornati. Il quadro più ampio è questo: gli agenti AI non sono solo assistenti di codifica che ti aiutano a scrivere funzioni più velocemente. Indica loro un problema ben definito, dà loro gli strumenti e le conoscenze giuste, e possono costruire le cose su una scala che semplicemente non era possibile prima. infrastructure builders
