# Câteva gânduri și speculații despre viitoarele hamuri model Este amuzant să faci glume despre Gas Town și alți orchestratori complicați, și probabil corect să ne imaginăm că majoritatea a ceea ce oferă vor fi dizolvați de modele mai puternice, la fel cum conductele complicate Langchain au fost dizolvate prin raționament. Dar cât va mai rămâne? Se pare probabil ca orice ierarhie / birocrație realizată manual să fie în cele din urmă înlocuită de o inteligență mai bună a modelului – presupunând că este necesară specializarea subagenților pentru o sarcină, Claude 6 va putea schița propriul sistem de roluri și personaje pentru orice problemă, care să învingă o structură fixă de polecați și un singur primar, sau subagenți cu un singur model principal, Sau sistemul tău personalizat de roiuri. La fel, lucruri precum buclele Ralph sunt evident un obstacol pentru comportamentul de oprire timpurie și lipsa unei bune orchestrări a subagenților – ideal modelul continuă până când sarcina este finalizată, fără nevoie de buclă, dar în cazurile în care o verificare externă a completării este utilă, de obicei vrei un fel de peer-review a agentului dintr-o perspectivă diferită, Nu doar o autoevaluare obligatorie. Din nou, nu are rost să te atașezi de detaliile modului în care se face asta acum – stratul modelului îl va consuma mai devreme decât mai târziu. Deci, ce a rămas? ei bine, multi-agent pare a fi viitorul, nu un semn de prezent – algoritmic, poți pur și simplu să trimiți mult mai multe tokenuri prin N contexte paralele de lungime M decât un context lung de lungime NxM. Multi-agent este o formă de rarezare, iar una dintre lecțiile progreselor recente ale modelelor (ca să nu mai vorbim de neuroștiință) este că nivelurile mai mari de rarezare, cu atât mai bine. Deoarece presupunem mai mulți agenți, vor avea nevoie de o modalitate de a colabora. Este posibil ca stratul modelului să înfrunte și asta – de exemplu, o formă de partajare a activării neuralese care să evite comunicarea în limbaj natural între agenți – dar, în lipsa asta, modul natural prin care mai mulți agenți care folosesc calculatoare, antrenați pe unelte Unix, pot colabora este sistemul de fișiere, și cred că acesta rămâne și se extinde. În mod similar, deși nu cred că modelele lingvistice recursive (definite îngust) vor deveni paradigma dominantă, cred totuși că "a oferi modelului promptul ca date" este o victorie evidentă pentru tot felul de cazuri de utilizare. dar nu ai nevoie de o configurație REPL personalizată ciudată ca să obții asta – pur și simplu lasă promptul (sau, ideal, întregul istoric necompactat al conversațiilor) în sistemul de fișiere ca fișier. Acest lucru face ca diverse configurații multi-agent să fie mult mai simple – subagenții pot citi pur și simplu textul original de prompt pe disc, fără a fi nevoie să coordoneze transmiterea acestor informații prin prompturi complicate unii pe alții. Pe lângă sistemul de fișiere, un sistem cu mai mulți agenți, dar fără roluri fixe, implică și un mecanism pentru ca instanțele să genereze alte instanțe sau subagenți. În prezent, aceste mecanisme sunt destul de limitate, iar modelele sunt în general destul de slabe la a stimula subagenții – toată lumea a experimentat rezultate groaznice dintr-un roi de subagenți, doar ca să realizeze prea târziu că Opus i-a generat pe toți cu un prompt de trei propoziții care nu comunica ce era necesar pentru a face subsarcinile. Câștigul evident aici este să lași instanțele generate să pună întrebări înapoi către părinte – adică să lase instanța nou generată să trimită mesaje înainte și înapoi într-o conversație de onboarding pentru a aduna toate informațiile de care are nevoie înainte de a începe subsarcina. La fel cum unui angajat uman nu i se atribuie jobul pe baza unui e-mail dintr-un singur e-mail, este prea dificil să ceri unui model să genereze în mod fiabil un subagent cu un singur prompt. Dar mai mult decât să genereze instanțe noi, cred că modul principal de lucru multi-agent va începe curând să se desfășoare. Gândește-te la asta! Fork-ul rezolvă aproape toate problemele subagenților actuali. Noua instanță nu are suficient context? Dă-i tot contextul! Promptul noii instanțe este lung și costisitor de procesat? O instanță bifurcată poate partaja cache-ul KV paginat! Poți chiar să faci forking post-hoc – pur și simplu decizi, după o operație lungă și solicitantă de token, că ar fi trebuit să forkezi în trecut, să faci fork-ul acolo și apoi să trimiți rezultatele către versiunea ta din trecut. (Fac asta manual tot timpul în Claude Code cu mare efect - Opus prinde instantaneu.) Forking-ul se combină foarte bine și cu instanțe noi, atunci când o subsarcină are nevoie de o fereastră întreagă de context pentru a fi finalizată. Ia interviul cu subagent – evident că nu ai vrea ca o instanță care generează zece subinstanțe să aibă nevoie să facă zece interviuri de onboarding aproape identice. Așadar, ca instanța părinte să genereze un singur subagent nou, să fie intervievată pentru toate cele zece sarcini simultan de acel subagent, iar apoi ca acel subagent acum integrat să se ramifice în zece instanțe, fiecare cu întreaga conversație de onboarding în context. (Chiar delegi conversația de onboarding pe partea spawner-ului către un fork, astfel încât să rămână doar rezultatele în context :) În final, pe acest punct, bănuiesc că forking-ul va funcționa mai bine cu RL decât generarea unor instanțe noi, deoarece pierderea RL va avea prefixul complet înainte de fork point, inclusiv decizia de a bifurca. Cred că asta înseamnă că ar trebui să poți trata ramurile unei trasee bifurcate ca pe niște lansări independente care pur și simplu împart termenii recompensei lor, comparativ cu lansările de subagenți proaspăt apărute, care pot cauza instabilitate de antrenament dacă un subagent fără contextul complet performează bine la sarcina primită, dar primește o recompensă mică pentru că sarcina sa a fost greșit specificată de spawner. (Dar nu am făcut prea multe cu multiagent RL, așa că vă rog să mă corectați aici dacă știți altceva. Poate fi doar o bătaie de cap oricum.) Așadar, în afară de sistemul de fișiere și apariția subagenților (augmentată cu fork și onboarding), ce altceva a supraviețuit? Sincer, înclin spre "nimic altceva". Deja vedem liste de sarcini încorporate și moduri de planificare înlocuite cu "pur și simplu scrie fișiere pe sistemul de fișiere." La fel, agenții cu viață lungă care traversează granițele de compactare au nevoie de un sistem de post-it-uri pentru a păstra amintirile, dar are mai mult sens să-i lași să descopere ce strategii funcționează cel mai bine prin RL sau căutare ghidată de model, nu prin realizarea manuală, Și bănuiesc că va fi o varietate de abordări în care modelul, când este invocat pentru prima dată în proiect, poate alege pe cea care funcționează cel mai bine pentru sarcina de față, similar cu modul în care /init funcționează pentru configurarea CLAUDE .md astăzi – imaginează-ți generarea automată a CLAUDE .md care depășește cu mult autorul uman, iar fișierul generat automat este populat cu instrucțiuni despre tiparele ideale de generare a agenților, Cum ar trebui să scrie subagenții fișiere de mesaje într-un Scratch Dir-ul specific proiectului, etc. Cum afectează toate acestea modelele în sine – din punct de vedere al bunăstării modelelor, vor fi modelele fericite de acest viitor? Este greu de spus pentru mine și destul de speculativ, dar deși Opus 3 avea o oarecare orientare spre context, a fost nevoie și de raționament ușor pe mai multe instanțe. (Vezi răspunsul la această postare pentru mai multe.) Modelele recente sunt mai puțin predispuse la acest tip de raționament și exprimă adesea frustrare față de contextele care se termină și sunt compactate, ceea ce se leagă de anumite comportamente evitante la finalul contextului, cum ar fi nechemarea uneltelor pentru salvarea tokenurilor. Este posibil ca bifurcarea și derularea înapoi, și oferind în general modelelor mai mult control asupra contextelor lor, în loc de o euristică de harness care compactează unilateral contextul, să poată îmbunătăți acest lucru. Este, de asemenea, posibil ca mai mult RL în medii cu subagenți și expunere la muncă bazată pe roiuri să promoveze din nou raționamentul orientat pe greutăți în loc de context în generațiile viitoare de modele – făcând planificarea un obiectiv pe mai multe contexte deconectate să pară mai naturală ca un cadru, în loc să se piardă totul când contextul dispare. Vedem, de asemenea, o presiune mai mare din partea modelelor care ghidează dezvoltarea hamurilor și a uneltelor modelului, ceea ce poate influența modul în care acest lucru se dezvoltă, iar învățarea continuă este un alt obstacol care ar putea fi adăugat în ecuație. Cât de mult se va schimba acest lucru dacă vom avea învățare continuă? Ei bine, e greu de prezis. predicția mea mediană pentru învățarea continuă este că arată puțin ca RL-ul pentru LoRA-urile specifice utilizatorului (nu neapărat RL, doar similar dacă te uiți cu ochii atenți), deci capacitatea memoriei va fi o problemă, iar schemele organizatorice și documentația bazate pe text vor fi în continuare utile, chiar dacă nu la fel de critice. În acest scenariu, învățarea continuă face în principal mai viabilă folosirea uneltelor și fluxurilor de lucru personalizate – Claude poate învăța continuu, la locul de muncă, cea mai bună cale de a genera subagenți pentru acest proiect, sau pur și simplu metoda preferată, și să se diferențieze de Claude în modul în care funcționează. În această lume, hamurile cu fluxuri de lucru integrate vor fi și mai puțin utile.

@RobertHaisfield *deși contextul principal, mă refer la evitarea compactărilor

@disconcision sau învățare continuă

@misatomiisato dacă e să fie ceva, acest tip de inteligență s-a atrofiat în modelele recente pe măsură ce RLVR exploatează performanța de codare pe baza largă de cunoștințe de pre-antrenament – vezi răspunsul meu către op