Wiki iliyopita, tulikuwa tunatumia Hakuna zaidi ya miezi ya uhandisi wa sprints - katika wiki moja, na mikutano ya 10 ya Membrane Agent inayoendeshwa kwa pamoja. 1,000 API integrations Ulimwengu wa Membrane Ulimwengu wa Membrane ni maktaba yetu ya ujuzi wa ushirikiano uliopangwa - kila kitu ambacho mfanyabiashara au mtengenezaji anahitaji kuungana na API za nje. Kuna aina nyingi za vipengele ndani yake, lakini kwa mradi huu tumejenga juu ya mbili: Connectors, ambazo zinafafanua jinsi ya kuungana na API ya nje (kuidhinisha kupitia OAuth2, API keys, nk, pamoja na ukusanyaji wa data na matukio) Pakiti za vitendo, ambazo ni mkusanyiko wa vitendo vya API tayari kwa matumizi (kwa mfano, "Tengeneza ujumbe wa Slack", "Orodha ya GitHub repos") ambazo wafanyabiashara na mtiririko wa kazi wanaweza kuita. Kwa pakiti za vitendo, hatujaribu kuwa kamili - tunajenga vitendo vya kawaida vinavyofunika ~80% ya matumizi ya kawaida. Kujenga kila ushirikiano kwa manually inachukua developer — utafiti wa doses, kujua auth, kutekeleza mteja, kuandika majaribio. Kwa kiwango hicho, ushirikiano wa 1,000 utakuwa unachukua mtu mmoja karibu mwaka wa kazi ya muda wote. Tumeitumia LLMs kuharakisha hili tangu siku za mwanzo za gpt-3.5, lakini daima ilikuwa ad-hoc. 30–60 minutes Membrane Agent tayari anajua jinsi ya kufanya kazi na jukwaa letu. Tumeunda pipeline ya mfululizo ili kusindika maelfu ya programu moja kwa moja. We saw the opportunity to industrialize it Ujenzi wa Pipeline Pipeline ina hatua mbili, kila moja iliyoendeshwa na script yake mwenyewe ya mfululizo. Hatua ya 1 inashughulikia utambulisho - sehemu ngumu zaidi ya ushirikiano wowote. Hatua ya 2 inajumuisha hatua ambazo zinafanya kila ushirikiano kuwa na manufaa. Wote wawili hufuata mfano huo: kupata programu zinazohitajika, kuunganisha washirika wa AI, kuthibitisha matokeo, kuchapisha kile kinachotokea, kuonyesha kile ambacho hakifanyi. Hatua ya 1 - Utambulisho (kuunda connectors) Script hii inashughulikia hatua ya kwanza: kutekeleza auth kwa kila programu. How it works: Inapata programu zote kutoka kwa API yetu, filters kwa wale ambao hawana connector bado Kwa kila programu (kuendesha hadi 10 kwa wakati mmoja), ni: Kuunda rekodi ya connector katika Membrane Kujenga Mkutano wa Agent katika injini yetu Inashughulikia Agent ya Membrane ya Mitaa inayotumiwa na Claude Inakuambia mfanyabiashara ambayo connector kutekeleza - mfanyabiashara anajua jinsi ya kuingiliana na Membrane kutoka kwa mwongozo wake wa mfumo na jinsi ya kujenga connectors kupitia ujuzi uliopangwa, hivyo ujumbe wa mtumiaji ni tu jina la programu na URL Kusubiri kwa mfanyabiashara kuishia (~2.5 dakika kwa wastani) Inathibitisha matokeo dhidi ya mipango yetu - mzunguko huu wa maoni ni muhimu kwa wafanyabiashara, kwa sababu wanaweza kurekebisha wenyewe wakati utekelezaji hauwezi Ikiwa ni halali: huchapisha connector na hufanya kwa umma Ikiwa ni halali: huchapisha programu kwa ajili ya uchunguzi wa manual What Membrane Agent actually does inside each session: Kwanza, mfanyakazi anaweza kutumia na ya Ili kupata nyaraka za API za programu. Inasoma kupitia dosari, inafahamu kama API inatumia OAuth2, API keys, Basic auth, au kitu kingine, na inafanya mipangilio ya vigezo vyote vya auth vinavyohusiana - ID ya mteja / majengo ya siri, vipengele, URLs za token, kazi. web search web fetch Kisha inafanya utekelezaji wa mteja wa API ambaye anashikilia uhakiki sahihi kwa maombi, anaandika kazi ya mtihani ili kuthibitisha uhusiano, na kwa kweli hufanya maombi ya HTTP kwa API ili kuthibitisha kuwa inapatikana na kujibu kwa usahihi. Hatimaye, hutumia zana za Membrane kuandika muundo wote tena kwenye jukwaa. na mwakilishi kufanya hivyo kwa kujitegemea kabisa. 2.5 minutes per app Jinsi ya kufanya Math: Hiyo ni karibu 10 connectors kujengwa na kuthibitishwa kila dakika chache - bila kushinikiza mtu mmoja. na 10 ni kitu ambacho tumejitegemea kwa sasa - concurrency ni configurable na inaweza kwenda juu. 10 agents, ~2.5 minutes each, running in parallel Kila mfanyabiashara anashughulikia kiungo kimoja (au mfanyabiashara mmoja) kwa kila mzunguko. Tunahifadhi kwa makusudi kwa kipengele kimoja kwa kila mzunguko ili kuepuka kufunika dirisha la mazingira - mzunguko mpya kwa kila programu inamaanisha mfanyabiashara anaendelea kuzingatia. Hatua ya 2 - Hatua (mipango ya kujenga) Mara baada ya programu imeboreshwa, ni tayari kwa hatua ya pili: kuzalisha vitendo ambavyo hufanya ushirikiano wa kweli muhimu. Mchoro unaonyesha awamu ya 1. Mchoro hufunika programu ambazo zina kiungo na auth lakini bado hawana pakiti, kisha huzaa mfanyabiashara kwa kila mmoja. Kila mfanyabiashara anajua ID ya kiungo yake na anapaswa kutekeleza mfanyabiashara. Inatafuta API ya programu, inatambua viungo vya mwisho maarufu na muhimu, na huunda ufafanuzi wa vitendo - kamili na mipangilio ya kuingia, usanidi wa maombi ya API, mipangilio ya output, na maagizo ya chaguo kwa tabia isiyo ya wazi. Baada ya kuthibitisha (kuangalia mfanyabiashara ina vitendo vya kweli), huchapishwa na kutolewa kwa umma. ya usanifu Hapa ni jinsi mfumo kamili inaonekana wakati wewe zoom nje: Maelezo muhimu ya kiufundi Katika mashindano ya 5-10, tunashughulikia Hapa ni nini hufanya kazi hiyo ya kuaminika: ~100 apps per batch run Mkutano wa kufuatilia Kila kikao cha mfanyabiashara kinafuatiliwa katika wingu letu, hata ingawa wafanyabiashara huendesha ndani wakati wa ujenzi wa mfululizo. script huunda kikao kwenye jukwaa letu na baada ya kila mfanyabiashara kuishia, na kuunganisha ujumbe wote wa mazungumzo. Hii inamaanisha tunaweza kutafakari kila uamuzi wa AI kupitia UI yetu ya console, hasa kama ilikuwa mkutano unaohudhuria wingu. Utekelezaji na Utaratibu wa Makosa Si kila programu inaweza kuwa automated. script inashughulikia kushindwa kwa heshima: Utekelezaji wa mpango: Baada ya mfanyabiashara kuishia, tunathibitisha matokeo dhidi ya mipangilio yetu ya SDK. Ikiwa haina kupitishwa (kupoteza mashamba yanayohitajika, muundo usio sahihi), programu inachukuliwa. API ya kufa: Mwandishi anaamuru kuondoka auth tupu na kueleza kwa nini ikiwa API haipatikani. Timeouts: Ikiwa Claude anashikiliwa kwenye API ya ajabu sana (isipokuwa haina kutokea mara nyingi), mstari unashikiliwa kama kushindwa na inaweza kubadilishwa tena. Hapa ni mahali ambapo inakuwa ya kuvutia: kushindwa hupata nyuma katika kuboresha. Wakati mfanyabiashara hupata kushindwa kwenye programu, tunashughulikia kikao ili kuelewa kwa nini - ilikuwa upungufu katika ujuzi wa mfanyabiashara? Mipango ya API ya ajabu? Takwimu mbaya? Tutayarisha tatizo la msingi, kuendesha tena, na kila seti inakuwa bora kuliko ya mwisho. Ujuzi wa Agent Hii ni muhimu: mfanyabiashara haina kuanza kutoka mwanzo kwa kila API. mwongozo wake wa mfumo unakusanywa kutoka vyanzo vingi vya ujuzi: Ufafanuzi wa jukwaa la membrane (nini ni membrane, jinsi mfumo unafanya kazi) Ujuzi wa kujenga connector (mchakato wa kazi wa hatua kwa hatua kwa utekelezaji wa auth . kuamua aina ya auth, kusoma dosi maalum za auth-type, configure vigezo, kutekeleza API client, kutekeleza mtihani) ujuzi wa OpenAPI (kama unavyoweza kutafuta na kutafuta ufafanuzi wa OpenAPI bila kupakia mipangilio yote katika mazingira), Maelekezo ya kina ya utekelezaji kwa kazi za connector ya msingi. Mfumo wetu wa mfanyabiashara unasaidia ujuzi wa upakiaji wakati wa mahojiano, lakini kwa usindikaji wa seti tuligundua kuwa ujuzi wa msingi unaofuata moja kwa moja kwenye mwongozo wa mfumo unafanya kazi vizuri zaidi. LLMs bado hawana ujuzi wa ujuzi wa ujasiri katika asilimia 100 ya kesi, na katika kiwango hiki unataka ufuatiliaji juu ya urahisi. Hii inamaanisha kwamba mfanyabiashara ana ujuzi wa kina wa mifano ya jukwaa letu kabla hata ya kuangalia API ya lengo. Maelezo ya Manual Layer Si kila kitu ni kikamilifu automatiska - na hiyo ni kwa ajili ya kubuni. Vifaa vya Edge: Vifaa vingine vya API ni vya kutojulikana lakini vya kazi. Tulijifunza wakati wa uchunguzi na kusindika kwa manually. Utafiti wa ubora: Tunaangalia mikutano ya mfanyabiashara kupitia console yetu, hasa kwa programu ambazo kuthibitishwa hazikufanikiwa. Hakuna uthibitisho halisi: Kwa sasa, mfanyabiashara haina kuthibitisha kwa kifungo halisi cha API. Inathibitisha API ni inapatikana na kwamba auth imewekwa kwa usahihi, lakini haina kukamilisha mtiririko halisi wa OAuth. Sisi ni kikamilifu kujenga automatisering ya kivinjari kwa uundaji wa moja kwa moja wa akaunti ya mtihani ili kukamilisha upungufu huu. Nini ni ya baadaye Tutaanzisha umma Ulimwengu wa Membrane katika wiki zijazo, kuanzia na maombi ya niche na ya ajabu - API ya shule ya zamani, mifumo yenye nyaraka mbaya. Upungufu mkubwa sasa ni mtihani wa ujuzi wa kweli. Tunajenga automatisering ya kivinjari kwa usajili wa moja kwa moja na mtiririko wa OAuth ili wafanyakazi waweze kuthibitisha ushirikiano wa mwisho hadi mwisho. Muda mrefu: utunzaji unaoendelea. API inabadilika, pointi za mwisho zinachukuliwa. Washirika wenyewe ambao walijenga mchanganyiko huu wataendelea kuwa na sasa. Picha kubwa ni hii: wafanyakazi wa AI sio tu msaidizi wa coding ambao husaidia kuandika kazi kwa haraka. Tazama matatizo yaliyoelezwa vizuri, kuwapa zana na ujuzi sahihi, na wanaweza kujenga mambo kwa kiwango ambacho hakikuwa rahisi hapo awali. infrastructure builders
