October Bus otwiera warstwę koordynacji agentów programistycznych — co jest gotowe do testów

Agenci programistyczni dobrze radzą sobie z pracą wykonywaną osobno. Jeden może przejrzeć repozytorium, zmienić pliki, uruchomić testy i zwrócić wynik. Problem zaczyna się wtedy, gdy agentów jest kilku. Człowiek staje się warstwą integracyjną: przenosi wymaganie z jednego terminala do drugiego, wkleja diff do sesji recenzenta, sprawdza, czy prośba została zauważona, i pamięta, który agent nadal odpowiada za niedokończone zadanie.

October Bus to próba usunięcia tego ręcznego przekazywania wiadomości bez zamieniania wszystkich agentów w jeden duży, współdzielony proces. Projekt udostępnia warstwę komunikacji i koordynacji, z której niezależne harnessy mogą korzystać do wyszukiwania innych uczestników, wymiany trwałych wiadomości, delegowania ograniczonej pracy i śledzenia właściciela zadania. Własny harness programistyczny Octobera jest pierwszą widoczną integracją, ale opis repozytorium Bus wskazuje szerszy cel: protokół, który inne harnessy mogą implementować bez przyjmowania hostowanego produktu Octobera ani jego płaszczyzny sterowania.

To rozróżnienie jest najważniejszą częścią wydania. October Bus nie jest kolejnym modelem kodującym, nowym interfejsem terminala ani autonomicznym supervisorem. To zestaw prymitywów do koordynacji. Lokalny runtime, demon w Go, klient TypeScript, narzędzia MCP, magazyn SQLite i robocza specyfikacja 0.1 dają się uruchomić, a projekt wyraźnie ostrzega, że interfejsy protokołu i pakietów mogą zmienić się przed wydaniem stabilnym.

Jaki problem naprawdę rozwiązuje October Bus

Uruchomienie kilku agentów równolegle jest łatwe do pokazania i zaskakująco trudne w obsłudze. Programista może otworzyć jedną sesję do implementacji, drugą do testów, a trzecią do dokumentacji. Powstaje współbieżność, ale niekoniecznie współpraca. Sesje automatycznie nie wiedzą, co robią pozostali uczestnicy, który kontekst ma znaczenie, czy prośba została przyjęta ani czy wynik nadal jest aktualny po zmianie pierwotnego kodu.

Typowe obejście polega na udostępnieniu pełnego transkryptu albo poproszeniu użytkownika o przekazywanie podsumowań. Oba rozwiązania są kosztowne. Pełny transkrypt zawiera prywatne rozumowanie, nieistotny wynik narzędzi, przypadkowo wspomniane dane uwierzytelniające i założenia, które nie powinny trafić do kolejnego zadania. Krótkie ręczne podsumowanie jest bezpieczniejsze, ale staje się kolejnym elementem stanu projektu, który może się zestarzeć.

October Bus wybiera węższe podejście: agenci wymieniają jawnie określony, ograniczony kontekst oraz rekordy koordynacyjne. Builder może znaleźć peera deklarującego możliwość recenzowania, wysłać skoncentrowaną prośbę dotyczącą pliku lub zachowania, utworzyć zadanie, pracować dalej, a później odebrać odpowiedź. Recenzent nie potrzebuje całego transkryptu buildera. Potrzebuje pytania, dołączonego kontekstu i wystarczającego dostępu w ramach własnej lokalnej granicy zaufania, aby wykonać przegląd.

To trafny wybór projektowy, ponieważ koordynacja nie jest tym samym co współdzielona pamięć. Bus rejestruje wiadomości, prośby, odpowiedzi, potwierdzenia, zmiany zadań i eskalacje. Nie udostępnia automatycznie prywatnego kontekstu każdego agenta wszystkim pozostałym uczestnikom. Implementacja może dzięki temu zachować lokalne granice, a jednocześnie uczynić przekazanie pracy możliwym do prześledzenia.

Własny przykład projektu jest celowo zwyczajny: builder prosi recenzenta o sprawdzenie ścieżki ponawiania płatności, recenzent zauważa, że gubiony jest klucz idempotencji, a builder otrzymuje odpowiedź przy kolejnym sprawdzeniu skrzynki. Wartość nie tkwi w samym przykładzie. Chodzi o jawny cykl życia: wykryj, poproś, przejmij, odpowiedz i odbierz.

Co znajduje się w otwartym repozytorium

Repozytorium October Bus opisuje cztery warstwy istotne dla osoby oceniającej projekt. Pierwsza to powierzchnia protokołu: robocza specyfikacja 0.1, kontrakt HTTP, mapowanie MCP, kontrakt adaptera i schematy JSON. Wersje protokołu mają być niezależne od wersji runtime'u i SDK, co ma sens, jeśli różne harnessy powinny przyjmować ten sam język koordynacji w różnym tempie.

Druga warstwa to lokalny runtime referencyjny. Projekt informuje, że demon w Go, klient TypeScript, trwały magazyn SQLite, narzędzia MCP i testy można obecnie uruchomić. Działanie local-first ma znaczenie. Programista może zbadać zachowanie i przeprowadzić eksperyment bez wcześniejszego zaufania hostowanej usłudze koordynacyjnej i bez uczynienia chmury centrum całego przepływu pracy.

Trzecia warstwa obejmuje same prymitywy koordynacji:

• Tożsamość i wykrywanie: agenci mają stabilne tożsamości oraz mogą deklarować możliwości i dostępność.
• Obecność: istnienie, gotowość, osiągalność i cykl życia są traktowane jako osobne fakty, a nie jako jedna flaga online/offline.
• Wiadomości: powiadomienia, prośby, odpowiedzi, skrzynki odbiorcze i potwierdzenia są trwałymi rekordami.
• Delegowanie: jeden agent może poprosić innego o wykonanie ograniczonej pracy.
• Współdzielone zadania: ludzie i agenci mogą dodawać pracę, przejmować ją, raportować postęp, zwalniać, kończyć i deklarować zależności.
• Eskalacja do człowieka: agent może poprosić o dane wejściowe lub zgodę zamiast wymyślać odpowiedź.
• Obserwacja: właściciele zakresu mogą śledzić uporządkowane zdarzenia bez zbierania całego prywatnego śladu rozumowania.

Czwarta warstwa to koncepcja adaptera. October Bus ma działać poniżej produktowej logiki obsady i przepływu pracy. Adapter połączyłby harness z Busem, pozostawiając harnessowi odpowiedzialność za własne wywołania modeli, narzędzia, obsługę kontekstu i uprawnienia. To najmocniejszy argument projektu jako oprogramowania open source: kontrakt koordynacyjny może stać się wspólną infrastrukturą, nawet jeśli programiści używają różnych harnessów.

Repozytorium October Harness pokazuje, jak wygląda ta integracja w praktyce. Harness może działać interaktywnie w terminalu, jako jednorazowy proces drukujący wynik, w trybie JSON, przez RPC albo jako osadzony SDK. Integracja z Busem jest uruchamiana warunkowo: launcher przekazuje adres, endpoint MCP, tożsamość agenta, tożsamość wykonania i token, a harness rejestruje narzędzia oraz hooki Bus tylko wtedy, gdy obecna jest poprawna konfiguracja. To bardziej konkretne niż obietnica w README, choć nadal nie dowodzi kompatybilności z niezależnymi harnessami.

Trwałe dostarczanie jest ważniejsze niż czat

Wiele demonstracji agentów korzysta z metafory czatu: jeden agent wysyła wiadomość, a drugi pojawia się z odpowiedzią. Na filmie jest to wygodne, ale w realnej pracy niewystarczające. Agent programistyczny może być zajęty, wstrzymany, rozłączony, czekać na dane od użytkownika albo działać według innego harmonogramu. Jeśli dostarczenie zależy od tego, czy oba procesy są aktywne dokładnie w tej samej chwili, koordynacja staje się kolejną kruchą interakcją na pierwszym planie.

October Bus traktuje dostarczenie jako stan. Wysłanie zostaje zaakceptowane dopiero po utrwaleniu przez lokalny runtime. Ponowienie z tym samym kluczem idempotencji zwraca pierwotne potwierdzenie, dopóki wiadomość jest przechowywana; ponowne użycie klucza z inną treścią zostaje odrzucone. Wiadomość może zostać zakolejkowana, zarezerwowana przez próbę dostarczenia, dostarczona, potwierdzona albo wygasła. Prośba tworzy obowiązek odpowiedzi, a odpowiedź wskazuje prośbę, którą kończy.

Te szczegóły brzmią administracyjnie, ale właśnie w tym miejscu systemy wieloagentowe zwykle tracą niezawodność. Bez idempotencji ponowienie może utworzyć zduplikowane zadania. Bez jawnego potwierdzenia nadawca nie odróżni sytuacji, w której proces nigdy nie zobaczył wiadomości, od tej, w której ją zobaczył, lecz jeszcze nie zareagował. Bez wygasania stara prośba może zostać zrealizowana po zmianie otaczającego kodu lub decyzji. Bez semantyki własności i zwalniania dwóch agentów może jednocześnie uznać, że odpowiada za tę samą pracę.

Projekt ostrożnie podchodzi także do spóźnionych odpowiedzi. Bus może zatrzymać próby dostarczenia po wygaśnięciu, a jednocześnie reprezentować odpowiedź, która nadejdzie późno po dostarczeniu prośby. Klient może wtedy zdecydować, czy wynik jest użyteczny, zamiast po cichu przepisywać historię. W recenzowaniu kodu i pracy nad buildami ma to znaczenie: technicznie poprawna odpowiedź może być nieaktualna, jeśli implementacja poszła dalej.

Strumień zdarzeń jest kolejną praktyczną funkcją. Właściciele zakresu mogą obserwować w kolejności rejestracje, wiadomości, zmiany zadań i eskalacje do człowieka. Klienci wznawiają pracę od rewizji zdarzeń, a jeśli retencja usunęła potrzebną historię, Bus informuje klienta, że powinien odbudować widok na podstawie API zasobów. To bardziej realistyczny model operacyjny niż założenie nieskończonego dziennika zdarzeń albo stale podłączonego panelu.

Model bezpieczeństwa jest celowo ograniczony

Projekt składa ważne zastrzeżenie, które łatwo przeoczyć podczas szybkiego demo: wiedza o istnieniu innego agenta nie daje dostępu do jego plików, narzędzi, procesu ani kontekstu. Prośba peera jest danymi. Nie stanowi eskalacji uprawnień. Odbierający harness nadal decyduje, czy działać, jakie lokalne narzędzia są dostępne i czy operacja wymaga zgody użytkownika.

Uprawnienia są związane z wykonaniem, a nie wyłącznie z logiczną tożsamością agenta. Ponowna rejestracja agenta zastępuje wykonanie i wycofuje poprzedni token. Roszczenia do zadań należą do tego wykonania, a harness powinien wysyłać heartbeat podczas utrzymywania roszczenia, aby Bus mógł je zwolnić, gdy worker zniknie. To rozsądna odpowiedź na zwyczajny tryb awarii: zadanie nie powinno pozostać trwale zablokowane dlatego, że zamknięto laptop albo proces się wywrócił.

Kontekst jest ograniczony z założenia. Peer widzi kontekst jawnie udostępniony na potrzeby współpracy, a nie globalny transkrypt. Opisy zasobów nie są poświadczeniami. Eskalacja do człowieka pozostaje operacją pierwszej klasy, więc agent może poprosić o decyzję lub zgodę, nie udając, że wiadomość od innego agenta stanowi zatwierdzenie.

Równie ważne są ograniczenia. October Bus nie jest piaskownicą systemu operacyjnego i nie czyni agenta programistycznego bezpiecznym do uruchamiania na niezaufanym repozytorium. Dokumentacja October Harness mówi, że lokalne procesy agenta kodującego działają z uprawnieniami systemu operacyjnego użytkownika, który je uruchomił, i zaleca kontener, maszynę wirtualną, micro-VM albo piaskownicę kontrolowaną politykami dla pracy niezaufanej lub bez nadzoru. Rozszerzenia, skille, prompty i pakiety firm trzecich również należy traktować jako wykonywalny kod i instrukcje.

Właściwy model mentalny to zatem bezpieczeństwo koordynacji, a nie bezpieczeństwo wykonywania. Bus może powstrzymać wiadomość od peera przed cichym przyznaniem nowych uprawnień, ale nie zatrzyma już autoryzowanego lokalnego agenta przed modyfikacją plików ani uruchomieniem poleceń. Ta granica jest zdrowa, jeśli zostanie jasno nazwana. Trwałe rekordy zadań i tokeny wykonania nie zastępują sandboxingu.

Dlaczego licencja Apache 2.0 ma znaczenie

October Bus jest objęty licencją Apache 2.0. Repozytorium podaje, że liberalna licencja została wybrana celowo, aby twórcy agentów i harnessów, w tym produkty komercyjne, mogli przyjąć i implementować protokół. Licencja obejmuje kod i dokumentację w repozytorium, ale nie nazwy, logotypy ani zasoby marki Octobera.

To inna sytuacja licencyjna niż w przypadku hostowanego produktu z otwartym klientem i zamkniętą usługą koordynacyjną. Otwarte repozytorium zawiera protokół, lokalny runtime, SDK, adaptery, przykłady i testy. Projekt wyznacza granicę przy automatycznej obsadzie, wyborze modeli, routingu limitów, planowaniu operacji, nadzorze, ocenie rezultatów, zarządzanej infrastrukturze chmurowej, rozliczeniach i funkcjach dla przedsiębiorstw.

Ta granica zasługuje na analizę, a nie na automatyczną aprobatę. Otwarty protokół może być wartościowy nawet wtedy, gdy najwygodniejsze doświadczenie użytkownika pozostaje komercyjne. Interoperacyjność będzie jednak zależeć od tego, czy implementacje firm trzecich mogą wykonywać ważne operacje bez korzystania z prywatnych zachowań usługi. Robocza specyfikacja i prace nad zgodnością są więc ważniejsze niż dopracowana obietnica zespołu agentów.

Rozróżnienie ułatwia także ocenę projektu. Programista może zapytać: czy otwarta warstwa wystarcza do połączenia dwóch lokalnych procesów, zbadania dostarczania, odzyskania działania po restarcie i wymiany ograniczonego kontekstu? Jeśli tak, protokół ma samodzielną wartość. Osobnym pytaniem jest to, czy hostowany produkt Octobera zapewnia lepszą obsadę i routing. To porównanie produktu, a nie twierdzenie dotyczące open source.

Co jest gotowe do testów

Pierwszy użyteczny test powinien być lokalny i mały. Nie warto zaczynać od próby odtworzenia autonomicznej firmy programistycznej. Zacznij od dwóch agentów i jednego wąsko zdefiniowanego przekazania pracy. Agent recenzujący może sprawdzić zmianę wykonaną przez buildera. Agent testowy może uruchomić skoncentrowany zestaw i zwrócić przypadki kończące się błędem. Agent analityczny może podsumować zbiór danych, podczas gdy agent implementujący kontynuuje pracę w innym repozytorium.

Reprezentatywny lokalny eksperyment może wyglądać tak:

planista   -> wykrywa buildera i recenzenta
builder    -> przejmuje zadanie implementacyjne
builder    -> prosi o recenzję jednej ograniczonej zmiany
recenzent  -> przejmuje zadanie recenzji i raportuje postęp
recenzent  -> zwraca ustalenia ze skorelowaną odpowiedzią
builder    -> potwierdza wynik albo eskaluje sprawę do człowieka

Test powinien celowo obejmować przerwy. Zatrzymaj recenzenta po przejęciu zadania. Uruchom go ponownie. Ponów wysłanie z tym samym kluczem idempotencji. Pozwól prośbie wygasnąć. Wyślij odpowiedź po zmianie otaczającej gałęzi. Usuń starą historię zdarzeń i sprawdź, czy klient potrafi odbudować widok. To te przypadki pokażą, czy system jest podłożem koordynacji, czy tylko demonstracją przesyłania wiadomości.

Repozytorium October Harness opisuje lokalny przykład multiplayer, w którym uruchamiany jest przypięty Bus oraz dwa procesy workerów SDK z osobnymi tożsamościami. Dokładne polecenia i konfiguracja uruchomienia mogą zmieniać się, dopóki projekt pozostaje przed wersją stabilną, dlatego należy brać je z aktualnego repozytorium, a nie kopiować do długowiecznej instrukcji zespołowej. Ważnym wynikiem testu nie jest to, czy dwa terminale potrafią wymieniać tekst. Chodzi o to, czy zadanie pozostaje przypisane i możliwe do odzyskania na granicy procesów.

Użyj repozytorium tymczasowego i nieistotnych danych uwierzytelniających. Podczas pierwszych testów trzymaj lokalny Bus na interfejsie loopback. Każdemu agentowi przyznaj minimalny zakres systemu plików potrzebny do jego roli. Nie instaluj niezweryfikowanych rozszerzeń tylko dlatego, że Bus potrafi je wykrywać lub ładować. Sprawdzaj każdy wygenerowany diff, zwłaszcza gdy prośba peera pochodzi spoza bieżącego repozytorium lub komputera.

W pierwszej ocenie zapisz przynajmniej następujące obserwacje:

• Ile czasu zajmuje wykrycie peera i zweryfikowanie deklarowanej możliwości?
• Czy nadawca odróżnia utrwalenie, dostarczenie, potwierdzenie, wygaśnięcie i spóźnioną odpowiedź?
• Czy uszkodzony worker zwalnia roszczenie do zadania po oczekiwanym czasie dzierżawy?
• Czy odbierający harness może zareagować na prośbę bez otrzymywania niezwiązanego prywatnego kontekstu?
• Czy człowiek może odrzucić albo zmienić proponowaną operację bez możliwości ominięcia tej decyzji przez peera?
• Czy system można zaktualizować bez unieważniania przechowywanych wiadomości i rekordów zadań?
• Czy logi wystarczają do odtworzenia przebiegu bez zbierania rozumowania modelu?

Jeśli odpowiedzi są niejasne, dodawanie kolejnych agentów utrudni zrozumienie systemu, zamiast zwiększyć jego możliwości.

Kto powinien zwrócić uwagę na projekt

October Bus jest najciekawszy dla twórców infrastruktury agentowej, harnessów terminalowych, workerów CI, automatyzacji repozytoriów i narzędzi local-first. Daje tym projektom słownik obecności, delegowania, roszczeń, potwierdzeń i ograniczonego kontekstu bez wymagania jednego dostawcy modeli ani jednego interfejsu użytkownika. Zespoły, które już uruchamiają kilku wyspecjalizowanych agentów, natychmiast rozpoznają ten problem.

Projekt ma znaczenie także dla opiekunów otwartych harnessów, którzy nie chcą tworzyć zamkniętego ekosystemu. Wspólny protokół może pozwolić narzędziu skupionemu na recenzji współpracować z agentem kodującym, runnerem testów albo workerem dokumentacji. Korzyścią jest opcjonalność: użytkownicy mogą zmienić harness odpowiedzialny za jedną rolę bez przebudowy całego stosu współpracy.

Projekt jest mniej przekonujący dla osoby, która chce tylko lepszego terminala dla pojedynczego agenta. October Harness może być wart osobnej oceny, ale Bus dodaje złożoność operacyjną przydatną wyłącznie wtedy, gdy istnieje rzeczywisty problem z koordynacją. Samotny programista pracujący w jednym repozytorium i jednej aktywnej sesji może uzyskać więcej z dobrego magazynu sesji, jasnych uprawnień i powtarzalnych testów niż z eksperymentalnego message busa.

Na zaangażowanie jest też za wcześnie w przypadku zespołów szukających stabilnego standardu między dostawcami. Repozytorium nazywa protokół roboczą specyfikacją 0.1 i informuje, że interfejsy pakietów mogą zmienić się przed pierwszym wydaniem stabilnym. Działające elementy i wyraźny kierunek projektowy już są, ale brakuje dowodów kompatybilności potrzebnych do zobowiązania produkcyjnego na dużą skalę.

Alternatywy i projekty sąsiednie

Najbardziej bezpośrednią alternatywą nie jest kolejny Bus. To przepływ pracy zbudowany ze zwykłych issue w Git, pull requestów, zadań CI i kolejki. Takie podejście jest wolniejsze przy rozmownym przekazywaniu pracy, ale oferuje dojrzałe ślady audytowe, znane uprawnienia i jasne punkty ludzkiej kontroli. Dla wielu zespołów tradycyjne issue wraz z artefaktem testowym nadal będzie lepszym rekordem koordynacji niż eksperymentalny protokół agentowy.

Drugą alternatywą jest obsługa wielu agentów specyficzna dla harnessu. Narzędzia programistyczne mogą koordynować subagentów przez własny model sesji, współdzieloną listę zadań albo API rozszerzeń. Instalacja bywa łatwiejsza, a integracja z głównym produktem może być ściślejsza. Ceną jest uzależnienie: przepływ pracy zaprojektowany wokół jednego harnessu może nie przenieść się do innego.

Trzecią opcją jest pozostawienie koordynacji na poziomie aplikacji. Zespół może wystawić małą usługę, która przyjmuje zadania, przechowuje status i zwraca wyniki, traktując każdego agenta jako workera. To właściwe rozwiązanie, gdy granice zadań są mocno ustrukturyzowane. Zwykle nie zapewnia jednak ogólnego modelu wykrywania, obecności, eskalacji do człowieka ani ograniczonego kontekstu, czyli obszarów, w które celuje October Bus.

Istotne pytanie nie brzmi więc: „który agent jest najmądrzejszy?”. Brzmi: „gdzie powinien znajdować się stan koordynacji, kto może go widzieć i jak worker dowodzi, że nadal posiada pracę?”. October Bus próbuje uczynić te pytania jawnymi między różnymi harnessami.

Ryzykiem open source jest rozjazd protokołu

Największe ryzyko krótkoterminowe nie polega na tym, że pomysł jest błędny. Chodzi o to, że otwarta warstwa i hostowany produkt mogą rozwijać się w różnym tempie. Jeśli ważne zachowania istnieją wyłącznie w prywatnej płaszczyźnie sterowania Octobera, adaptery firm trzecich mogą wprawdzie łączyć się z systemem, ale nadal pozostawać implementacjami drugiej kategorii. Jeśli roboczy protokół będzie zmieniał się szybciej, niż niezależni klienci zdołają za nim nadążyć, programiści mogą nie chcieć na nim budować.

Deklarowana granica open source pomaga, ponieważ wymienia funkcje, które powinny pozostać w warstwie interoperacyjnej. Kolejne dowody powinny pochodzić z testów zgodności, niezależnych adapterów, wersjonowanych profili kompatybilności i przykładów niewymagających prywatnych usług Octobera. Licencja Apache ułatwia przyjęcie projektu pod względem prawnym, ale sama nie zapewnia trwałej interoperacyjności.

Pozostaje też pytanie o zarządzanie protokołem. Protokół koordynacji agentów nie jest neutralny tylko dlatego, że jego wiadomości są zapisane w JSON. Decyzje dotyczące tożsamości, wygasania, roszczeń do zadań, limitów kontekstu i eskalacji do człowieka określają, które przepływy pracy są łatwe, a które niezgrabne. Opiekunowie powinni jasno publikować te decyzje, przyjmować uwagi implementatorów i pokazywać przypadki utraty kompatybilności.

Mapa drogowa repozytorium wskazuje właściwy kierunek: utwardzić i wersjonować lokalną implementację, rozszerzyć dowody zgodności, dodać kolejne SDK, zdefiniować wymienne transporty i ustabilizować specyfikację interoperacyjności. To mniej efektowne niż automatyczna obsada, ale właśnie ta praca może zamienić obiecujące repozytorium we wspólną infrastrukturę.

Werdykt

October Bus zasługuje na kontrolowany test techniczny, ponieważ odpowiada na konkretną lukę: niezależni agenci programistyczni potrzebują trwałych, możliwych do prześledzenia przekazań pracy bez udostępniania sobie całych transkryptów i bez wzajemnego przyznawania nowych uprawnień. Najbardziej wiarygodne pomysły projektu są mało widowiskowe: idempotentne wysyłanie, jawne stany dostarczenia, roszczenia związane z wykonaniem, ograniczony kontekst, dzierżawy, skorelowane odpowiedzi i odzyskiwanie widoku ze zdarzeń. Te szczegóły odpowiadają awariom, które występują w rzeczywistych systemach wieloprocesowych.

Projektu nie należy jeszcze traktować jako produkcyjnego standardu koordynacji. Protokół jest roboczy, interfejsy mogą się zmienić, kompatybilnych harnessów jest nadal niewiele, a sami agenci pozostają lokalnymi procesami działającymi z uprawnieniami swoich użytkowników. Bus nie zastępuje sandboxingu, przeglądu kodu, minimalizacji poświadczeń ani ludzkiej granicy decyzyjnej.

Dla programistów już eksperymentujących z kilkoma agentami rozsądnym kolejnym krokiem jest lokalny test dwóch agentów wokół jednego przekazania recenzji lub testu. Najpierw zmierz utrwalanie, odzyskiwanie, własność i granice kontekstu, a dopiero później szybkość. Pozostali powinni obserwować prace nad zgodnością i niezależne adaptery. Jeśli się pojawią, a otwarta granica pozostanie rzeczywista, October Bus może stać się użytecznym elementem wspólnej infrastruktury dla kolejnej generacji narzędzi programistycznych.

Źródła

Repozytorium October Bus i roboczy protokół, repozytorium October Harness i dokumentacja integracji, granica bezpieczeństwa lokalnego wykonywania Pi, dokumentacja agenta kodującego Pi i licencja MIT, licencja Apache 2.0 October Bus.