Dlaczego Muse Code trzyma swoje agenty przy życiu przez całą sesję
Cicha decyzja architektoniczna, która stoi za szybkością Muse Code: agenty w tle żyją przez całą sesję, zamiast być tworzone do jednego zadania i wyrzucane.
Problem: powołaj i wyrzuć
Większość wieloagentowych narzędzi do kodowania działa według tego samego przepisu: przychodzi zadanie, więc odpalamy agenta-pomocnika, dajemy mu kawałek pracy, odbieramy wynik i go ubijamy. Czysta abstrakcja z brzydkim kosztem. Każdy świeżo uruchomiony agent startuje od zera — musi na nowo przeczytać strukturę repozytorium, na nowo odkryć system budowania, na nowo nauczyć się konwencji twojego kodu. W sesji z dziesięcioma zadaniami ten podatek od zbierania kontekstu płacisz dziesięć razy.
I nie chodzi tylko o tokeny. To także opóźnienie — każdy zimny start odsuwa właściwą pracę — oraz koszt sterowania, bo agent, który zapomniał, czego nauczył się godzinę temu, zada ci te same pytania dwa razy.
Odpowiedź Muse Code: trwałość
Muse Code jest zbudowany jako prosta pętla głównego agenta plus zestaw asynchronicznych agentów w tle — i te agenty w tle pozostają aktywne przez całą sesję. Nie powstają pod pojedyncze zadania. Każdy jest wyspecjalizowany, przez całą sesję akumuluje kontekst i sam decyduje, kiedy coś jest warte zgłoszenia głównemu agentowi.
Ten ostatni szczegół znaczy więcej, niż się wydaje. Agenty w tle nie blokują głównej pętli czekaniem na instrukcje, ale też nie zalewają jej raportami o statusie. Samodzielnie wykonują kolejne kroki i odzywają się wtedy, kiedy to istotne. Meta uzasadnia to dokładnie tymi dwoma kosztami z akapitu wyżej: trwałość zmniejsza opóźnienia i ogranicza potrzebę ludzkiego sterowania przy trudnych, wieloetapowych zadaniach.
Robotnicy równolegle, recenzenci w tle
W praktyce doświadczasz tego jak zespołu ze stałymi rolami, a nie kolejki pracowników tymczasowych. Robotnicy wykonują zmiany równolegle; recenzenci na bieżąco krytykują wyniki w tle, zanim te trafią do ciebie. Hasło z premiery — „multi-agent by default“ — jest precyzyjne: koordynacja to nie tryb, który włączasz, tylko sposób, w jaki działa każde zadanie. Dostarczasz szybciej nie dlatego, że pojedynczy agent jest szybszy, ale dlatego, że kontrola jakości dzieje się równocześnie, a nie po fakcie.
Wytrenowane w modelu, nie doklejone
Jest powód, dla którego ta konstrukcja harnessa działa z Muse Spark 1.2 lepiej, niż działałaby z generycznym wrapperem na model. Model był współtrenowany z harnessem Muse Code — jego przepis treningowy jawnie optymalizował zachowanie subagentów, obok celów i kompaktowania kontekstu. Podział pracy między główną pętlę a trwałych specjalistów nie jest sztuczką prompt engineeringu położoną na wierzchu; model widział go podczas treningu. Stąd biorą się deklaracje „mniej powtórek, lepsze użycie narzędzi“ — szczegółowo opisujemy to w poście o tym, jak trenowano Muse Spark 1.2.
Czego trwałość nie rozwiązuje
Długowieczne agenty edytujące równocześnie to samo repozytorium byłyby przepisem na katastrofę przy merge — gdyby dzieliły kopię roboczą. Nie dzielą. Kiedy praca rozchodzi się fan-outem, każdy agent-dziecko z prawem zapisu dostaje własny, odizolowany git worktree, więc równoległa praca nigdy nie koliduje na plikach. Ten mechanizm izolacji zasługuje na osobne wyjaśnienie: fan-out agentów i git worktrees. A gdy chcesz wiedzieć, co którykolwiek z tych agentów faktycznie robił, kiedy nie patrzyłeś, kompletną odpowiedź ma append-only dziennik zdarzeń.