Środowisko agentów do pracy zespołowej | Dweve Nexus

Choose the audience that matches your question

The page contains three selectable readings of the same subject.

Asystent kodowania i wsparcie operatora. Metryki demonstracyjne mają charakter poglądowy.

Terminal, wyszukiwanie, lint, testy, git i więcej.

Zapamiętuje kontekst Twojej bazy kodu i zespołu.

Wyspecjalizowani agenci współpracują w różnych obszarach.

Każdy krok jest rejestrowany z datą i godziną.

Zasady, kontrole i testy są zawsze uruchamiane.

Przeglądaj diffy, żądaj zmian, finalnie zatwierdzaj.

Odtwórz dowolną sesję bit po bicie, gdy coś wymaga przeglądu.

Przeczytaj retry.ts, wykryto błąd przekroczenia limitu czasu

Wyodrębnij guard + ogranicz liczbę ponowień

Autonomiczne agenty, które piszą kod i zostawiają ślad

do obsługi limitów czasu sieci, odpowiedzi 5xx i warunków bezpiecznych dla idempotencji. Czysta funkcja pomocnicza, w pełni pokryta testami jednostkowymi.

Wejście, polityka, uzasadnienie na jednym artefakcie

Wstrzymuje się przed czymkolwiek nieodwracalnym

Ograniczenia oceniane w czasie rzeczywistym

utworzony wokół jednego zadania i pokazuje, co robi

intencja, zakres, treść, etyka, anomalia, wykonanie

cel obj-281 · zespół 5 specjalistów · cykl 1/1

Środowisko wykonawcze dla organizacji wykonywalnych · jeden cel, jeden zespół, jeden ślad

decyzja o wykonaniu · wstrzymaj płatność do dostawcy v-281

działanie · bramka zatwierdzeń · decyzja #4f9e2c

w kolejce do operacji, oczekuje na zatwierdzającego

podpis · M. Bos, ops-3 · 2026-04-12 09:14 CET

konto · ślad ograniczeń zapieczętowany, odtwarzalny od początku do końca

Robocza, epizodyczna, semantyczna, proceduralna, baza wiedzy

jednego celu, jednej odpowiedzialnej operacji

Przedstaw Nexusowi cel, który obecnie obejmuje ludzi, systemy, zasady i zatwierdzenia. Zobacz, jak praca jest dekomponowana, jak powstaje organizacja, jak przypisywane są uprawnienia, jak ograniczane są awarie i jak każdy wkład wraca do jednego odpowiedzialnego wyniku.

Potok, fan-out, delegacja, tablica, debata

Dweve Nexus, środowisko uruchomieniowe dla Organizacji Wykonywalnych

Nexus to wieloagentowe środowisko uruchomieniowe w Pythonie dla pracy, która wymaga więcej struktury niż pętla promptów. Jego implementacja rozdziela agentów, cykl życia zadań, przepływy pracy, pamięć i routing oparty na możliwościach na odrębne komponenty. Budowniczowie w Pythonie, DweveScript i CLI definiują i uruchamiają tę pracę.

Użyj budowniczych w Pythonie, DweveScript lub CLI, aby zdefiniować agentów, zadania i przepływy pracy dla pracy, którą musisz koordynować.

Komponenty do skoordynowanej pracy agentów

Robocza, epizodyczna, semantyczna, proceduralna i wiedza

Od dedukcyjnego po hybrydowy, dobierany do zadania

Dweve Nexus, każde zadanie dostaje własny zespół

Większość narzędzi AI daje każde zadanie temu samemu asystentowi. Nexus działa inaczej. Za Fabric tworzy zespół wokół tego, o co prosisz, wysyła każdą część do specjalisty, który jej odpowiada, i zwraca jeden wynik w rozmowie, którą już otworzyłeś. Pytasz raz. Nexus organizuje wszystko w tle.

Zapytaj raz. Pozwól Nexus utworzyć zespół, podzielić pracę, połączyć elementy i zwrócić jeden wynik. Organizacja pracuje dla Ciebie. Władza pozostaje przy Tobie.

Typowane przekazania utrzymują spójność środowiska uruchomieniowego. Ktokolwiek podpisuje pracę, czyta coś innego.

Obecna implementacja udostępnia budowniczych Pythona dla agentów oraz kompilator DweveScript do deklaratywnych definicji agentów i przepływów pracy. Jego CLI analizuje, kompiluje i uruchamia pliki DweveScript. To komplementarne interfejsy do tej samej implementacji w Pythonie, a nie deklaracje równoważnych klientów w Rust, TypeScript czy Go. Definicja napisana w jednym z nich jest tą samą definicją czytaną z drugiego, więc zespół może przechodzić między plikiem deklaratywnym a budowniczym bez utrzymywania dwóch opisów tej samej organizacji.

Obok komunikatów punkt-punkt działa typowana magistrala zdarzeń, na której grupa agentów faktycznie się koordynuje: żądania i wyniki zadań, akceptacja i odrzucenie, roszczenia i zwolnienia oraz zdarzenia cyklu życia i zdrowia, a subskrybenci mogą filtrować, przekazywać, odrzucać i przekształcać to, co otrzymują. Dwa rodzaje stanu są celowo trzymane poza pojedynczymi komunikatami. Tablica to zadeklarowana struktura, którą agenci czytają i zapisują, więc wkład jest czytelny dla kogoś innego niż tylko dla autora.

Zdarzenia i stan, który ma być współdzielony

Przekazanie w Nexus to wartość z kształtem, a nie akapit, który jeden agent ma nadzieję, że drugi sparsuje. Warstwa protokołu przenosi typy zgodne z A2A dla komunikatów, zadań, artefaktów, możliwości, umiejętności, ról i statusów, a JSON to jeden ze sposobów umieszczenia ich na przewodzie, a nie sam system typów. Narzędzia i systemy zewnętrzne pojawiają się przez kontrakt, a Model Context Protocol jest obsługiwany jako jedna z tych granic, gdy klient tego chce. Odbierający komponent może zweryfikować ten kształt, zanim zadziała, a ślad utrzymuje przekazanie możliwym do sprawdzenia. JSON to wybór transportu; nie zastępuje kontraktu.

Odtworzenie odpowiada, co się stało. To, co części sobie przekazują, jest równie ściśle typowane.

Nexus ma osobne komponenty do routingu, wykonywania przepływów pracy, komunikacji, rozumowania, pamięci, bezpieczeństwa i odzyskiwania. Ta separacja umożliwia sprawdzenie odpowiedniego komponentu, gdy praca zachowuje się nieoczekiwanie, zamiast traktować każdą awarię jako problem z promptem. Każdy komponent rejestruje to, co zdecydował w momencie podjęcia decyzji, więc pytanie po incydencie brzmi: który komponent się zmienił, a nie które zdanie było źle sformułowane. Ten zapis jest tym, co odtwarza replay.

Przechwycone odtworzenie ponownie wykorzystuje zarejestrowane wyniki każdego wywołania zewnętrznego i odtwarza oryginalne uruchomienie, co testuje decyzje samego środowiska uruchomieniowego przy zatrzymanym świecie zewnętrznym. Odtworzenie na żywo ponownie wywołuje zależności i porównuje, co jest testem, który może się nie udać, a zatem tym, który warto uruchomić. Przechwycone odtworzenie odpowiada, czy środowisko uruchomieniowe podjęło te same decyzje przy zatrzymanym świecie zewnętrznym. Odtworzenie na żywo odpowiada, czy dzisiejsze zależności nadal dają ten sam wynik. Porównanie jest zatem testem środowiska, a nie drugą kopią historii.

Wszystko to można obserwować na żywo. To, co środowisko uruchomieniowe decyduje samo, jest ustalone, zanim uruchomisz.

Ustrukturyzowane zdarzenia są emitowane per encja, a wdrożenie decyduje, który magazyn je odbiera: ograniczona pamięć w środowisku deweloperskim, trwały magazyn w produkcji oraz magazyn tylko do dopisywania lub zabezpieczony przed manipulacją, gdy zapis ma się obronić przed kimś spoza budynku. Każdy z nich jest nazywany tym, czym jest. Środowisko uruchomieniowe nie nazywa zwykłych mutowalnych logów niezmiennymi, co jest różnicą między dowodem, który ktoś akceptuje, a twierdzeniem, które testuje. Zdarzenia zachowują swoją encję i postawę magazynowania.

Różne rodzaje bytów przyjmują różne pytania i ta asymetria jest użyteczną częścią. Pytanie agenta o to, jak bardzo jest zdrowy, ma sens, a zadanie tego samego pytania operacji nie, ponieważ operacja jest albo zablokowana, albo nie, a jej zdrowie to tylko zdrowie tego, kto się w niej znajduje. Jednostka pracy ma termin i liczbę ponownych prób, a grupa nie ma żadnego z nich: to, co ma grupa, to członkostwo i zapis tego, nad czym pracowała. Ponieważ żadne dwa z tych zestawów nie są takie same, jeden płaski strumień wierszy odpowiada na wszystkie cztery pytania źle.

Pytanie produkcyjne rzadko dotyczy tego, co powiedział log. Chodzi o to, która jednostka pracy przekroczyła termin, który agent jest niezdrowy, która część operacji jest zablokowana i przez co. Nexus raportuje stan na tych samych rzeczach, na których wykonuje, więc pytanie trafia do tego, kto posiada odpowiedź, zamiast być składane z wierszy, które przypadkiem o tym wspominają. To sprawia, że pytanie jest adresowalne bez odtwarzania rozmowy. Stan należy do bytu, który posiada pracę, więc przekroczony termin, niezdrowy agent lub zablokowana operacja mogą być zbadane na podstawie jego rekordu i bieżącego stanu.

O odzyskaniu jesteś informowany. Obserwowanie go podczas działania to inne wymaganie.

Dwie konsekwencje, które inżynier może wykorzystać. Ponieważ czas oczekiwania jest deterministycznym punktem stałym obliczanym na podstawie numeru próby, a nie losowaniem ze źródła losowego, harmonogram nieudanego uruchomienia jest częścią tego, co się odtwarza, więc spór o to, ile trwało wczoraj, ma odpowiedź, a nie teorię. A ponieważ obwód należy do agenta, a nie do rodzaju pracy, jedna zawodna zależność zatrzymuje kierowanie do jednego miejsca, podczas gdy ta sama praca pozostaje kierowalna wszędzie indziej. Każde podstawienie jest zapisywane na bieżąco: przekierowanie wymienia zastępczego agenta i stan, który z nim podróżował, więc uratowane uruchomienie czyta się później jako jeden kawałek pracy z odzyskaniem w środku.

Coś zawiedzie, a interesujące pytanie nie brzmi, która odpowiedź zostanie wybrana. Chodzi o to, co powstrzymuje odzyskanie przed staniem się obciążeniem. Każda jego część jest ograniczona, zanim zaczną się problemy: ile prób, jak długi jest każdy czas oczekiwania, ile z limitu może wydać ratunek i ile z zasobów jedna zła zależność zabiera ze sobą. Nic tutaj nie kończy się, ponieważ pętla zdecydowała, że próbowała wystarczająco mocno. Środowisko uruchomieniowe rejestruje numer próby, obliczony czas oczekiwania, stan obwodu, zastępcę i stan przeniesiony. To daje przeglądowi incydentu ograniczoną ścieżkę do zbadania: ponowna próba może być odtworzona, zamknięta trasa może być wyjaśniona, a błąd terminalny może być odróżniony od ratunku, który się zakończył.