„GitHub“ žengia aiškų žingsnį nuo „DI, kuris padeda spausdinti“ link „DI, kuris gali nuimti jūsų darbą“. Viešoje peržiūros versijoje, paskelbtoje 2026 m. vasario 4 d., „GitHub“ teigia, kad kūrėjai dabar gali tiesiogiai paleisti trečiųjų šalių kodavimo agentus iš „Anthropic“ („Claude“) ir „OpenAI“ („Codex“).Agento būstinėkartu su „GitHub Copilot“.
Jei naudojote „Copilot“, pasiūlymas gali skambėti pažįstamai: greitesnis užbaigimas, mažiau konteksto perjungimų, didesnis pagreitis. Tačiau agentų būstinė bando pakeisti situaciją.kurirkaipdarbas vyksta. Užuot šokinėję tarp pokalbių skirtukų, vietinių įrankių ir įklijuotų fragmentų, šiuos agentus galima priskirtiproblemos ir užklausos dėl ištraukimoir atsakyti tame pačiame bendradarbiavimo paviršiuje, kurį jūsų komanda jau naudoja: „GitHub“.
Tai mažiau svarbu solo kūrėjui, kuriančiam šalutinio projekto prototipą, o daugiau šiuolaikinės programinės įrangos realybei: bilietams, kodo peržiūrai, atitikčiai ir nuolatinėms deryboms tarp „išsiųsti“ ir „išsiųsti saugiai“. Panagrinėkime, ką paskelbė „GitHub“, ką „agentas“ iš tikrųjų reiškia praktiškai ir kaip komandos turėtų galvoti apie kelių agentų darbo eigų diegimą nepaversdamos savo saugyklų dirbtinio intelekto generuojamais „spagečiais“.
Ką „GitHub“ reiškia kaip „agento būstinę“ (ir kuo ji skiriasi nuo pokalbių)
Naujoji integracija yra platesnės „GitHub“ vizijos dalis.Agento būstinė: vieta, kurioje dirbtinio intelekto agentai yra „gimtoji“ dalis kasdieniuose „GitHub“ darbo procesuose. Svarbiausias pokytis yra tas, kad agentas ne tik atsako į klausimus – jis dalyvauja darbo gyvavimo cikle.
„GitHub“ rėmuose galite priskirti agentą užduočiai ir gauti jį:
- Siūlyti kodo pakeitimus (dažnai kaip PR juodraštį)
- Komentuoti užklausas dėl ištraukimo
- Kartoti remiantis atsiliepimais
- Pririškite pokalbį prie saugyklos, problemos ir skirtumo
Pastarasis punktas yra subtilus, bet labai svarbus. Tradiciniai dirbtinio intelekto asistentai yra be būsenos, nebent nuolat iš naujo pildomas kontekstas. „GitHub“ siekia priešingo: „kontekstas“ yra pati saugykla – problemų gija, esama kodo bazė, testai, CI patikrinimai ir peržiūros diskusija.
Agento būstinė taip pat aiškiai nurodytakelių tiekėjų„GitHub“ produktų vadovas Mario Rodriguezas teigė, kad konteksto kaita sukuria trintį ir kad kūrėjai turėtų galėti pereiti „nuo idėjos prie įgyvendinimo“, pasirinkdami skirtingus agentus skirtingiems veiksmams, nepalikdami įrankio.
Kitaip tariant: „GitHub“ nori tapti agentų orkestravimo sluoksniu, o ne tik IDE asistentu.
Claude'as ir Codexas prisijungia prie „Copilot“: kas iš tikrųjų siūloma
„GitHub“ pranešime teigiama, kad „Claude“ ir „Codex“ jau prieinami viešoje peržiūros versijoje:
- „Copilot Pro+“ir„Copilot Enterprise“vartotojai
- VidujeGitHub,GitHub MobileirVisual Studio kodas
- Su„Copilot“ komandinės eilutės palaikymas bus pasiekiamas netrukus
„GitHub“ taip pat pažymi, kad kiekviena agento sąveika sunaudojapriemokos užklausa(svarbi detalė, susijusi su išlaidomis ir valdymu), ir ši prieiga bus išplėsta, kad būtų galima naudotis daugiau prenumeratos tipų.
„The Verge“ išleidimo santraukoje pabrėžiama ta pati tema: „GitHub“ leidžia konkurentų modelius ir agentus tiesiogiai pasiekti „Copilot“ ekosistemoje, tęsdama tendenciją, kai „Copilot“ tampa mažiau orientuota į vieną modelį ir daugiau į platformą, kurioje gali būti talpinami keli metodai.
Kodėl tai svarbu: agentai gyvena ten, kur gyvena atskaitomybė
Jei kada nors bandėte „naudoti dirbtinį intelektą darbui“ komandoje, tikriausiai susidūrėte su tais pačiais sunkumais:
- Dirbtinis intelektas nežino saugyklos.Įklijuojate fragmentus, apibendrinate architektūrą ir vis tiek gaunate pasiūlymus, kurie ignoruoja jūsų konvencijas.
- Darbas nėra peržiūrimas.Pokalbių lange gaunate kodo fragmentą be aiškių skirtumų, testų ar kilmės.
- Pokalbis nuslysta tolyn.Sprendimai priimami tiesioginėse žinutėse arba pokalbių įrankiuose, kurie nėra susieti su problemomis ir PR.
- Valdymas yra košmaras.Apsaugos komandos nerimauja dėl duomenų atskleidimo; inžinerijos vadovai nerimauja dėl kokybės ir atsakomybės.
Agento būstinė sprendžia šias problemas priversdama agento išvestį būti nukreipta į tuos pačius „bėgius“, kurie naudojami žmonių bendradarbiavimui:
- Pakeitimai rodomi kaip commit arba pull request.
- Peržiūra atliekama pažįstamoje kodo peržiūros vartotojo sąsajoje.
- Diskusijos lieka susijusios su problemomis ir PR.
- Komandos gali taikyti esamas politikas (filialo apsauga, privalomos peržiūros, CI vartai).
Tai yra tikrasis pažadas: ne tai, kad agentai yra stebuklingai protingesni, bet tai, kad juos lengviau integruoti į drausmingą programinės įrangos procesą.
Kelių agentų darbo eigos: kodėl jums reikėtų daugiau nei vieno modelio
Dauguma komandų greitai supras, kad „geriausias modelis“ yra iliuzija. Skirtingi modeliai turi skirtingus privalumus:
- Kai kurie yra stiprūs bendros architektūros ir kompromisų srityje.
- Kai kurie yra stiprūs tiksliuose mechaniniuose refaktoriuose.
- Kai kurie gerai rašo testus ar dokumentus.
- Kai kurie geriau samprotauja apie kraštutinius atvejus.
„GitHub“ aiškiai skatinapalyginimaskaip darbo eigos dalis. „Agent HQ“ leidžia jums priskirti kelis agentus ir įvertinti, kaip kiekvienas iš jų sprendžia tą pačią problemą.
„GitHub“ netgi pateikia praktinę skirtingų agentų naudojimo taksonomiją:
- Architektūriniai apsauginiai turėklai:Įvertinkite moduliškumą, susiejimą ir galimą šalutinį poveikį.
- Loginis slėgio bandymas:Ieškokite kraštinių atvejų, asinchroninių pavojų, mastelio keitimo prielaidų.
- Pragmatinis įgyvendinimas:Pasiūlyti mažiausią atgalinio suderinamumo pakeitimą su mažu sprogimo spinduliu.
Naudingas mentalinis modelis yra elgtis su agentais mažiau kaip su „jaunaisiais kūrėjais“ ir labiau kaip suspecializuoti recenzentaigalite akimirksniu suktis:
- Vienas agentas elgiasi kaip architektas.
- Elgiamasi kaip kokybės užtikrinimo inžinierius.
- Elgiamasi kaip palaikytojui, optimizuojančiam minimalius skirtumus.
Net ir tada, kai agentai nesutaria, tas nesutarimas yra vertingas – jis išryškina kompromisus, kurių galite nepastebėti, jei konsultuojatės tik su vienu asistentu.
Kaip naudotis agento būstine nesukeliant netvarkos
Greičiausias būdas išvengti agentų nesėkmės – paprašyti jų „įdiegti X funkciją“ ir tada tvirtinti PR. Antras greičiausias būdas – leisti jiems atlikti pakeitimus nesusijusiose saugyklos dalyse.
Tvaresnis požiūris yra naudoti agentusapriboti, peržiūrimi pjūviai.
1) Pradėkite nuo darbų: testų, dokumentų, nedidelių pakeitimų
Ankstyvos pergalės paprastai būna:
- Trūkstamų vienetinių testų pridėjimas esamam moduliui
- Integracinių testų rašymas siekiant ištaisyti klaidą
- Dokumentų ir pavyzdžių tobulinimas
- Mechaninio pertvarkymo atlikimas (pervadinimas, funkcijos išskyrimas, dublikatų pašalinimas)
Šios užduotys natūraliai yra diferencijuotos ir lengvai patvirtinamos naudojant CI.
2) Pirmiausia klauskite planų, o tik tada kodo
Prieš leisdami agentui paliesti kodą, paprašykite jo:
- Pakartotinai suformuluokite problemą ir apribojimus
- Nustatykite paveiktus modulius
- Pasiūlyti įgyvendinimo planą
- Išvardykite testavimo atvejus ir gedimų režimus
Tada peržiūrėkite planą taip, kaip tai darytumėte projekto peržiūros metu. Tik suderinę planą, turėtumėte nurodyti agentui jį įgyvendinti.
Čia ir sužiba daugiaagentiškumas: vienas agentas pasiūlo planą, kitas jį kritikuoja.
3) Išlaikykite mažą sprogimo spindulį
Aiškiai išdėstykite lūkesčius:
- „Lieskite tik šiuos failus.“
- „Priklausomybė nesikeičia.“
- „Jokių formatavimo redagavimų.“
- „Pridėkite X ir Y elgesio testus.“
Agentai linkę keisti paieškos apimtį, nes jie optimizuoja siekdami „priversti veikti“, o ne „sumažinti skirtumą“. Jūsų užduotis – apriboti paieškos erdvę.
4) Agentų PR traktuokite kaip PR juodraščius
Agentų sugeneruoti PR turėtų pradėti gyvuoti kaipjuodraštis.
Reikalauti:
- CI leidimas
- Bent vienas žmogaus pritarimas
- Saugumo patikros (SAST / priklausomybių nuskaitymas)
- Greitas „skirtumo patikrinimas“ dėl netikėtų redagavimų
Jei agentas gali komentuoti PR, taip pat galite paprašyti jo pagrįsti pakeitimus. Tikslas yra ne pasitikėti agentu, o padaryti jį tokį, kadaudituojamas.
Paslėpta sunki dalis: saugumas, politika ir audituojamumas
Įmonės nenaudoja įrankių todėl, kad jie yra šaunūs – jos naudoja įrankius todėl, kad juos galima valdyti.
„GitHub“ pranešimas į tai remiasi. „Agent HQ“ pristatoma kaip „sukurta komandoms, o ne tik individualiems asmenims“, pabrėžiant centralizuotą kontrolę:
- Agento valdikliai / politika:Administratoriai gali apibrėžti, kurie agentai ir modeliai yra leidžiami.
- Audito žurnalavimas:Agento veiklos ir prieigos matomumas.
- Metrikų ataskaitų skydelis:Stebėti naudojimą ir poveikį.
„GitHub“ taip pat atkreipia dėmesį į „GitHub Code Quality“ (viešą peržiūrą), skirtą priežiūros ir patikimumo poveikiui įvertinti, ir į integruotą „kodo peržiūros“ etapą, kai „Copilot“ sprendžia pradines problemas prieš kūrėjui pamatant kodą.
Tai svarbu, nes agentų pritaikymas neformaliai paprastai nepavyksta. Komandoms reikia atsakymų į tokius klausimus:
- Kuriems saugykloms leidžiama naudoti kuriuos agentus?
- Ar agentai gali pasiekti privatų kodą? Kokiomis sąlygomis?
- Kokie duomenys siunčiami modelio teikėjui?
- Kaip užtikrinti, kad galėtume atkurti, kas ką pakeitė ir kodėl?
Net jei esate maža komanda, jums reikės „mini valdymo“:
- Trumpa politika, kokias užduotis agentams leidžiama atlikti.
- Taisyklė, kad joks agentas PR nesujungia be bandymų.
- Reikalavimas, kad agento išvestis būtų priskirtina (PR aprašymas paaiškina raginimą / ketinimą).
Išlaidos ir kvotos: „premium“ užklausos keičia elgseną
„GitHub“ teigia, kad kiekviena agento sąveika sunaudojapriemokos užklausaTai daugiau nei vien tik sąskaitų faktūrų smulkmenos – tai formuoja darbo eigos dizainą.
Jei užklausų dėl priemokų bus nedaug, komandos:
- Naudoti agentus didesnės įtakos užduotims (dizaino kritikai, testų generavimui, pertvarkymo planavimui)
- Venkite „plepiško“ iteravimo ir vietoj to pateikite geresnius pradinius raginimus.
- Standartizuokite daugkartinio naudojimo užduotis (komandos vadovėlius)
Praktinis patarimas: sukurkite „užduočių šablonus“ pasikartojančioms užduotims, tokioms kaip:
- Šablonas „Rašyti šio modulio vienetinius testus“
- Šablonas „Atlikti pertvarkymą su griežtais apribojimais“
- Šablonas „Peržiūrėti PR dėl saugumo rizikos“
Geri šablonai sumažina iteraciją, o tai sumažina aukščiausios kokybės užklausų apdorojimą.
Ką tai reiškia kūrėjams: naujas darbo pasidalijimas
Agento būstinė skatina kūrėjus rinktis kitokį darbo aprašymą:
- Mažiau laiko praleidžiama rašant standartinius tekstus
- Daugiau laiko apribojimų apibrėžimui ir skirtumų peržiūrai
- Daugiau laiko architektūros ir kraštutinių atvejų svarstymui
- Daugiau laiko testų rašymui ir numatomo elgesio nustatymui
Geriausiu atveju tai yra atnaujinimas: kūrėjai tampa labiau panašūs į prižiūrėtojus ir į produktą orientuotus inžinierius.
Blogiausiu atveju tai sukuria trapią sistemą, kurioje žmonės pritaria pokyčiams, kurių nesupranta.
Taigi svarbiausias „įgūdis“ yra ne greita inžinerija – taiperžiūros inžinerija:
- Ar galite pastebėti įtartinus pokyčius?
- Ar galite patvirtinti, kad testai atitinka ketinimus?
- Ar galite pastebėti subtilų našumo sumažėjimą?
- Gal galėtumėte paaiškinti komandos draugui šį pokytį?
Daugiagentės sistemos čia iš tikrųjų galėtų padėti: vienas agentas gali įdiegti, o kitas – peržiūrėti, tačiau vis tiek reikia žmogaus sprendimo kaip galutinio sprendimo.
Kur toliau: agentai kaip pirmos klasės „GitHub“ piliečiai
„GitHub“ teigia, kad bendradarbiauja su papildomais partneriais – „Google“, „Cognition“ ir „xAI“ – siekdama įtraukti daugiau specializuotų agentų į „GitHub“, „VS Code“ ir „Copilot“ CLI darbo eigas.
Jei taip atsitiks, įdomūs klausimai bus ne „kuris modelis yra protingiausias?“, o veikiau:
- Kuris agentas yra geriausiastaikokios rūšies užduotis?
- Kaip automatiškai nukreipiame užduotis (rūšiavimas, testų generavimas, dokumentų atnaujinimai)?
- Kaip užtikrinti, kad žmonės būtų informuoti apie svarbius įvykius?
- Kaip užtikriname ilgalaikį priežiūrą?
Tikėkitės, kad „agento“ idėja išsiplės nuo kodo generavimo iki saugyklų operacijų:
- Automatiškai parengti išleidimo pastabas
- Apibendrinant incidentus ir pomirtinius tyrimus
- Triaging problemos ir etikečių siūlymas
- Priklausomybės atnaujinimų siūlymas atliekant rizikos analizę
Kadangi tai yra „GitHub“ viduje, visa tai galima susieti su pagrindiniais objektais, kurie jau reprezentuoja darbą: problemomis, PR, commit'ais ir patikromis.
Esmė
„GitHub“ agentų būstinės integracija su „Claude“ ir „Codex“ yra mažiau susijusi su nauju blizgančiu pokalbių valdikliu, o labiau su dirbtinio intelekto kūrimu.dalyvauti faktiniame programinės įrangos kūrimo procese: problemos, užklausos dėl išgavimo, peržiūra ir valdymas.
Jei jūsų komanda agentus traktuoja kaip „PR generatorius su aiškiais apribojimais, gerais testais ir rimta peržiūros disciplina“, kelių agentų darbo eigos gali sumažinti darbo krūvį ir anksčiau priimti geresnius sprendimus. Jei jūsų komanda agentus traktuos kaip autopilotą, trumpalaikį greitį iškeisite į ilgalaikį trapumą.
Lietuvių kalba
English
العربية
Čeština
Dansk
Nederlands
Eesti
Suomi
Français
Deutsch
Ελληνικά
Magyar
Italiano
日本語
한국어
Latviešu valoda
Norsk bokmål
Polski
Português
Română
Русский
Slovenčina
Slovenščina
Español
Svenska
Türkçe