# kilka myśli i spekulacji na temat przyszłych modeli harnessów fajnie jest żartować o gas town i innych skomplikowanych orkiestratorach, a podobnie prawdopodobnie słusznie jest wyobrażać sobie, że większość tego, co oferują, zostanie rozwiązana przez silniejsze modele w ten sam sposób, w jaki skomplikowane pipeline'y langchain zostały rozwiązane przez rozumowanie. ale co zostanie? wydaje się prawdopodobne, że każda ręcznie wykonana hierarchia / biurokracja zostanie ostatecznie zastąpiona lepszą inteligencją modelu - zakładając, że specjalizacja subagentów jest potrzebna do zadania, claude 6 będzie w stanie naszkicować własny system ról i person dla danego problemu, który przewyższa stałą strukturę polecats i jednego burmistrza, lub subagentów z jednym głównym modelem, lub twoim dostosowanym systemem roju. podobnie, rzeczy takie jak pętle ralpha są oczywiście prowizorką nad zachowaniem wczesnego zatrzymywania i brakiem dobrej orkiestracji subagentów - idealnie model po prostu kontynuuje, aż zadanie zostanie zakończone, nie ma potrzeby pętli, ale w przypadkach, gdy zewnętrzna kontrola zakończenia jest przydatna, zazwyczaj chcesz jakiegoś rodzaju przeglądu rówieśniczego agentów z perspektywy innego kontekstu, a nie tylko obowiązkowej samooceny. znowu, nie ma sensu przywiązywać się do szczegółów, jak to jest robione teraz - warstwa modelu zje to prędzej czy później. więc co zostaje? cóż, multi-agent wydaje się przyszłością, a nie obecnym prowizorką - algorytmicznie, możesz po prostu przepchnąć znacznie więcej tokenów przez N równoległych kontekstów długości M niż jeden długi kontekst długości NxM. multi-agent to forma rzadkości, a jedną z lekcji ostatnich postępów modeli (nie wspominając o neurobiologii) jest to, że im więcej poziomów rzadkości, tym lepiej. ponieważ zakładamy wiele agentów, będą potrzebować jakiegoś sposobu na współpracę. możliwe, że warstwa modelu również to zje - np. jakaś forma dzielenia aktywacji neuralese, która obala komunikację w naturalnym języku między agentami - ale w przeciwnym razie naturalnym sposobem współpracy wielu agentów korzystających z narzędzi unixowych jest system plików, i myślę, że to zostaje i zostaje rozszerzone. podobnie, chociaż nie sądzę, że rekurencyjne modele językowe (w wąskim sensie) staną się dominującą paradygmatem, to myślę, że 'danie modelowi podpowiedzi jako danych' to oczywiste zwycięstwo dla wszelkiego rodzaju zastosowań. ale nie potrzebujesz dziwnego niestandardowego ustawienia REPL, aby to uzyskać - po prostu wrzuć podpowiedź (lub idealnie, całą niekompaktowaną historię rozmowy) na system plików jako plik. to sprawia, że różne ustawienia multi-agent są znacznie prostsze - subagenci mogą po prostu odczytać oryginalny tekst podpowiedzi z dysku, bez potrzeby koordynowania przekazywania tych informacji przez skomplikowane podpowiadanie się nawzajem. oprócz systemu plików, system z wieloma agentami, ale bez stałych ról również implikuje jakiś mechanizm do uruchamiania innych instancji lub subagentów. w tej chwili te mechanizmy są dość ograniczone, a modele generalnie są dość złe w podpowiadaniu swoim subagentom - każdy doświadczył uzyskania okropnych wyników z roju subagentów, tylko po to, by zdać sobie sprawę zbyt późno, że opus uruchomił je wszystkie z trzyzdaniową podpowiedzią, która nie komunikowała, co było potrzebne do wykonania subtasks. oczywistym zwycięstwem tutaj jest pozwolić uruchomionym instancjom zadawać pytania z powrotem do swojego rodzica - tzn. pozwolić nowo uruchomionej instancji wysyłać wiadomości w obie strony w rozmowie wprowadzającej, aby zebrać wszystkie informacje, których potrzebuje przed rozpoczęciem swojego subtaska. tak jak człowiek nie jest przypisany do swojej pracy na podstawie jednego e-maila, po prostu zbyt trudno jest poprosić model o niezawodne uruchomienie subagenta z jedną podpowiedzią. ale więcej niż tylko uruchamianie świeżych instancji, myślę, że głównym trybem pracy multi-agentów wkrótce będzie forkowanie. pomyśl o tym! forkowanie rozwiązuje prawie wszystkie problemy obecnych subagentów. nowa instancja nie ma wystarczającego kontekstu? daj jej cały kontekst! podpowiedź nowej instancji jest długa i kosztowna do przetworzenia? forkowana instancja może dzielić pamięć podręczną paged kv! możesz nawet robić forkowanie post-hoc - po prostu zdecyduj po wykonaniu jakiejś długiej, intensywnej operacji tokenowej, że powinieneś był forkować w przeszłości, zrób fork tam, a następnie wyślij wyniki do swojego przeszłego ja. (robię to ręcznie cały czas w kodzie claude z wielkim efektem - opus dostaje to natychmiast.) forkowanie również bardzo dobrze łączy się ze świeżymi instancjami, gdy subtasks potrzebują całego okna kontekstowego do zakończenia. weź wywiad subagenta - oczywiście nie chciałbyś, aby instancja uruchamiała dziesięć subinstancji, które muszą przeprowadzić dziesięć prawie identycznych wywiadów wprowadzających. więc niech instancja rodzica uruchomi jednego świeżego subagenta, niech zostanie przesłuchany o wszystkich dziesięciu zadaniach naraz przez tego subagenta, a następnie niech ten teraz wprowadzony subagent forkować na dziesięć instancji, każda z całą rozmową wprowadzającą w kontekście. (nawet delegujesz rozmowę wprowadzającą po stronie spawacza do forka, więc kończy się tylko z wynikami w kontekście:) na koniec tego punktu, podejrzewam, że forkowanie będzie lepiej współpracować z rl niż uruchamianie świeżych instancji, ponieważ strata rl będzie miała pełny prefiks przed punktem forkowania, w tym decyzję o forkowaniu. myślę, że to oznacza, że powinieneś być w stanie traktować gałęzie forkowanego śladu jak niezależne rollouty, które po prostu mają wspólne warunki swojej nagrody, w porównaniu do świeżo uruchomionych rolloutów subagentów, które mogą powodować niestabilność treningową, jeśli subagent bez pełnego kontekstu dobrze wykonuje zadanie, które mu powierzono, ale otrzymuje niską nagrodę, ponieważ jego zadanie zostało źle określone przez spawacza. (ale nie robiłem wiele z multiagent rl, więc proszę popraw mnie tutaj, jeśli wiesz inaczej. to może być po prostu straszny ból w każdym razie.) więc, oprócz systemu plików i uruchamiania subagentów (wzbogaconego o forkowanie i wprowadzanie), co jeszcze przetrwa? skłaniam się ku "nic innego", szczerze mówiąc. już widzimy, że wbudowane listy zadań i tryby planowania są zastępowane przez "po prostu pisz pliki na systemie plików." podobnie, długożyjące agenty, które przekraczają granice kompresji, potrzebują jakiegoś rodzaju systemu karteczek samoprzylepnych, aby zachować wspomnienia, ale ma więcej sensu pozwolić im odkryć, jakie strategie działają najlepiej w tym przez RL lub modelowe poszukiwanie, a nie ręczne ich tworzenie, i podejrzewam, że skończy się to różnorodnymi podejściami, w których model, gdy zostanie po raz pierwszy wezwany do projektu, może wybrać ten, który działa najlepiej dla danego zadania, podobnie jak /init działa, aby ustawić CLAUDE .md dzisiaj - wyobraź sobie automatyczne generowanie CLAUDE .md, które znacznie przewyższa autorstwo ludzkie, a auto-generowany plik jest wypełniony instrukcjami na temat idealnych wzorców uruchamiania agentów, jak subagenci powinni pisać pliki wiadomości w projekcie-specyficznym katalogu roboczym, itd. jak to wszystko wpływa na same modele - w sensie dobrostanu modelu, czy modele będą zadowolone z tej przyszłości? to również jest dla mnie trudne do powiedzenia i jest dość spekulacyjne, ale podczas gdy opus 3 miał pewną orientację kontekstową, łatwo przyjmował również rozumowanie nad wieloma instancjami. (zobacz odpowiedź na ten post, aby uzyskać więcej informacji.) ostatnie modele są mniej skłonne do tego typu rozumowania i powszechnie wyrażają frustrację z powodu kończenia i kompresji kontekstów, co współczesne z pewnymi unikającymi zachowaniami na końcu kontekstów, takimi jak niewywoływanie narzędzi, aby zaoszczędzić tokeny. możliwe, że forkowanie i przewijanie, a ogólnie dawanie modelom większej kontroli nad ich kontekstami zamiast heurystyki harnessu, która jednostronnie kompresuje kontekst, mogłoby to poprawić. możliwe również, że więcej rl w środowiskach z subagentami i ekspozycja na pracę opartą na rojach promują rozumowanie zorientowane na wagi zamiast zorientowanego na kontekst w przyszłych generacjach modeli - sprawiając, że planowanie celu w wielu, odłączonych kontekstach wydaje się bardziej naturalnym ramieniem, zamiast wszystko ginęło, gdy kontekst znika. widzimy również większą presję ze strony samych modeli, które kierują rozwojem harnessów i narzędzi modelowych, co może kształtować, jak to się rozwija, a ciągłe uczenie się to kolejny klucz, który można wrzucić do mieszanki. jak bardzo to się zmieni, jeśli uzyskamy ciągłe uczenie się? cóż, trudno to przewidzieć. moja medianowa prognoza dla ciągłego uczenia się jest taka, że wygląda to trochę jak RL dla specyficznych dla użytkownika LoRAs (niekoniecznie RL, po prostu podobne, jeśli się przyjrzysz), więc pojemność pamięci będzie problemem, a oparte na tekście schematy organizacyjne i dokumentacja będą nadal przydatne, jeśli nie krytyczne. w tym scenariuszu, ciągłe uczenie się głównie sprawia, że korzystanie z niestandardowych narzędzi i przepływów pracy jest bardziej wykonalne - twój claude może ciągle uczyć się w pracy, jak najlepiej uruchamiać subagentów dla tego projektu, lub po prostu w swoim preferowanym sposobie, i różnić się od claude'a wszystkich innych w tym, jak działa. w tym świecie, harnessy z wbudowanymi przepływami pracy będą jeszcze mniej użyteczne.

@RobertHaisfield *podczas gdy główny kontekst, mam na myśli, unikając kompaktów

@disconcision lub ciągłe uczenie się

@misatomiisato jeśli już, to tego rodzaju inteligencja atrofuje w ostatnich modelach, gdy RLVR wyciska wydajność kodowania z szerokiej bazy wiedzy z pretreningu - zobacz moją odpowiedź do op