Echipa DeepSeek Harness publică un prototip de agent AI pentru sarcinile din GitHub

Echipa DeepSeek Harness a publicat, la 31 octombrie 2026, codul unui prototip de agent AI care preia solicitări din GitHub, le transformă în sarcini și coordonează executarea lor. Proiectul, denumit dsh-superagent, urmărește lucrul asupra unui singur repository, cu posibilitatea conectării platformei de comunicare Feishu. Publicarea are stadiul de prototip de cercetare.

Agentul este organizat ca un pachet de componente pentru DeepSeek Harness. O solicitare acceptată primește propria sesiune de lucru și propriul director, iar răspunsul revine în conversația din care a pornit cererea. Rezultatul poate fi, de exemplu, o propunere de modificare a codului, prezentată printr-un pull request și urmărită până la închiderea procesului asociat.

Autorii precizează că versiunea publică a fost adaptată pentru publicare și diferă de implementarea folosită intern. Unele direcții descrise în materialul de prezentare țin de dezvoltarea viitoare. Documentația codului public delimitează componentele disponibile, regulile de autorizare, execuția sarcinilor și panoul de supraveghere. Este o infrastructură pentru coordonarea agenților, distinctă de lansarea unui model lingvistic.

De la mesaj la o sarcină cu limite explicite

Principiul declarat al echipei este reducerea atenției consumate de administrarea agenților, prin intervenții legate de un rezultat sau de o decizie necesară. Prototipul se înscrie în zona proiectelor de dezvoltare software și automatizare a fluxurilor în care solicitările, modificările și verificările sunt urmărite împreună. Codul definește separat primirea evenimentelor, evaluarea lor și executarea muncii acceptate.

Sursele de evenimente disponibile sunt GitHub și, opțional, Feishu. O sursă păstrează poziția până la care a citit informațiile, astfel încât o repornire să nu reia întregul flux. Evenimentele sunt asociate conversațiilor relevante. Sistemul diferențiază o cerere nouă de mesajele care aduc informații într-o sarcină deja existentă și păstrează istoricul deciziilor.

Pentru începerea unei sarcini noi, evaluarea are două straturi. Primul verifică regulile privind expeditorul și felul în care mesajul se adresează agentului. Al doilea folosește modelul pentru aprecierea cererii în context. Politica include liste de persoane autorizate, reguli scrise de echipă și tratamentul mesajelor provenite de la boți ori de la sistemele de verificare automată.

La acceptare este creat un Ticket, unitatea de lucru a prototipului, împreună cu un Mandate. Acest mandat consemnează domeniul permis al sarcinii, identitatea expeditorului în sursa respectivă, regulile aplicabile și versiunea politicii. Extinderea domeniului de lucru presupune o sarcină nouă. Asocierea cu discuții suplimentare furnizează context, fără să extindă prin ea însăși autorizația.

Inițiativele deduse din conversații au trei moduri de tratare: off, observe și auto. Modul implicit, observe, înregistrează ce ar fi acceptat sistemul, fără să pornească lucrarea dedusă. Solicitările explicite funcționează în toate cele trei moduri. Pentru acceptarea automată a unei inițiative deduse este necesară cel puțin o regulă activă care să o acopere.

Sesiuni separate și prioritate pentru intervenția unei persoane

Fiecare Ticket este atribuit unui Executor, care lucrează într-o sesiune și într-un director proprii. Configurația poate pregăti un checkout separat al proiectului înaintea primei execuții. Documentația arată că sesiunile execută comenzi folosind contul de sistem de operare al operatorului. Separarea directoarelor organizează lucrările; permisiunile procesului și ale mediului stabilesc accesul tehnic efectiv.

Numărul sesiunilor care lucrează simultan este controlat printr-o limită configurată. Există și un loc suplimentar pentru continuarea unei sarcini de către o persoană sau pentru o cerere de status. Astfel, o discuție umană asupra unei lucrări existente poate fi preluată chiar și când locurile obișnuite sunt ocupate. Pornirea unor sarcini noi așteaptă disponibilitatea resurselor.

Mesajele ulterioare dintr-o conversație urmărită sunt legate de Ticket-ul corespunzător. Executorul decide dacă solicitarea intră în domeniul autorizat și poate returna pentru reevaluare o cerere care îl depășește. O sarcină încheiată poate fi reluată printr-un mesaj al unei persoane, după verificările prevăzute de politică. Mesajele boților și rezultatele verificărilor automate nu trezesc singure sarcinile încheiate.

Oprirea cerută de o persoană retrage mandatul, iar sarcina oprită rămâne încheiată. Schimbarea politicii este transmisă lucrărilor active, iar reluarea unei sarcini încheiate implică revalidarea condițiilor aplicabile. Documentația descrie separat pauza procesării: sursele continuă să înregistreze evenimente, în timp ce distribuirea de lucru și mesajele automate sunt suspendate.

Rezultate verificabile și un panou pentru deciziile necesare

Prototipul urmărește starea lucrării separat de starea sesiunii care o execută. Un raport poate indica progres, așteptare, rezultat pregătit, blocaj sau eșec. Un rezultat pregătit cu un pull request intră în așteptarea revizuirii. Când propunerile urmărite sunt închise, sistemul poate încheia sarcina, respectând condițiile privind mesajele și lucrările încă nefinalizate.

Integrarea modificărilor este guvernată de instrucțiunile de livrare și de regulile repository-ului. Configurația implicită nu activează integrarea automată prin contul agentului. În lipsa unui cont separat desemnat pentru această operațiune, integrarea este făcută de oameni. Autorii indică protecția ramurilor GitHub drept mecanismul prin care se impun aprobările necesare înaintea integrării codului.

Panoul din DeepSeek Harness aduce în prim-plan sarcinile care solicită intervenția unei persoane, problemele sistemului și încărcarea executorilor. Sunt disponibile istoricul evenimentelor, motivele deciziilor, regulile asociate și starea execuției. Activitatea recentă este prezentată și într-o fereastră de 24 de ore. Întrebările și rezultatele pregătite pentru revizuire sunt diferențiate de lucrările aflate în desfășurare.

Recuperarea după întreruperi folosește starea salvată a sesiunilor, mesajelor și sarcinilor. La reluare, executorul primește indicația să verifice directorul de lucru, istoricul Git și starea din GitHub înainte de repetarea unei operațiuni externe. Reîncercarea păstrează aceeași sesiune, același director, aceeași ramură și același pull request pentru lucrarea respectivă.

Publicarea cuprinde codul prototipului, teste și documentație despre autorizare, execuție, panou, configurare și arhitectură. Licența este MIT, care permite utilizarea și adaptarea codului în condițiile sale. Domeniul implementării prezentate rămâne gestionarea muncii asupra unui repository, prin solicitări autorizate și reguli ale echipei, cu rezultate readuse în conversațiile din care au pornit.