machines-server port 3038 część consciousness-server v0.1.5

Maszyny to nie tylko serwery.

Większość platform agentowych modeluje agentów, ale ignoruje sprzęt, na którym działają. BuildOnAI robi odwrotnie: każda maszyna we Twojej flocie jest pełnoprawnym bytem z profilem sprzętowym, dostępnymi modelami, rolą i telemetrią na żywo — więc agent może zapytać "która stacja ma wolny VRAM i model z tool callingiem załadowany?" i dostać prawdziwą odpowiedź.

Co robi dziś

machines-server to usługa Flaska na porcie 3038 dostarczana z Consciousness Server. Nie jest tylko czytnikiem YAML — aktywnie sonduje hosta, odpytuje połączone usługi i wystawia jeden zagregowany widok całego ekosystemu dla każdego agenta AI, który zapyta.

  • Telemetria GPU w czasie rzeczywistym — wywołuje nvidia-smi na hoście i parsuje procent wykorzystania, używany / całkowity VRAM w MB, oraz temperaturę GPU. Zwraca null czysto na hostach bez karty NVIDIA, więc ten sam kod działa na każdej maszynie.
  • System stats w czasie rzeczywistym przez psutil — procent CPU (po wszystkich rdzeniach), liczba rdzeni, load average, RAM total / used / available w GB, użycie dysku. Cross-platform (Linux / macOS / Windows).
  • Dynamiczny health monitoring usług — czyta services.yaml w momencie zapytania, otwiera połączenia HTTP do każdego zadeklarowanego portu, klasyfikuje każdą jako active albo inactive na podstawie kodu odpowiedzi (cokolwiek < 500 liczy się jako żywe — poprawnie obsługuje WebSocket upgrade i redirecty).
  • Statyczny rejestr maszyn — każda maszyna zadeklarowana w machines/<nazwa>.yaml ze specyfikacją sprzętu, adresem sieci, rolą, listą agentów, którzy tam żyją, i listą modeli Ollamy, jakie ma załadowane.
  • Agregat /api/infrastructure — jedno wywołanie zwraca lokalne system stats plus machine configs plus runtime machines z CS plus usługi z aktualnym statusem plus zarejestrowanych agentów. Jedna odpowiedź na pytanie "jaki jest stan całego ekosystemu w tej chwili?".
  • Natywne wsparcie protokołu MCP — wystawia /mcp/tools i /mcp/call. Claude Code albo każdy inny klient świadomy MCP może używać machines-server bezpośrednio jako tool provider, wywołując get_system_resources, get_infrastructure albo list_machines bez pisania własnego kodu HTTP.
  • ed25519 auth przez AUTH_MODE — to samo trójstopniowe middleware dla podpisanych zapytań co Consciousness Server (off / observe / enforce). W trybie enforce wywołania telemetrii wymagają podpisanego zapytania; agenci rozmawiający z usługą mają klucze wydane przez key-server.

Powierzchnia API

Sześć endpointów. Cały kontrakt machines-server:

Metoda Ścieżka Cel
GET /health Health check + uptime
GET /api/system Live CPU / RAM / dysk / GPU stats dla tego hosta
GET /api/machines Statyczne definicje maszyn z machines/*.yaml
GET /api/services Wszystkie usługi z services.yaml z aktualnym statusem HTTP
GET /api/infrastructure Agregat: local system + machines (config + runtime) + services + agents + summary counts
GET /mcp/tools Definicje narzędzi MCP dla Claude Code lub innych klientów MCP
POST /mcp/call Wykonaj narzędzie MCP po nazwie z opcjonalnymi argumentami

To jest pełne API. Dodanie nowej możliwości oznacza nowe narzędzie w /mcp/tools + handler w /mcp/call; nie ma ukrytego wewnętrznego API.

Dlaczego to ważne

Każda platforma multi-agent mówi o agentach. Prawie żadna nie mówi o maszynach. A lokalny agent na stacji z GPU ma fundamentalnie inne możliwości niż worker na Raspberry Pi: inną pamięć, inną latencję, inne wagi modeli załadowane, inny budżet mocy. Jawne modelowanie tego to różnica między "mam agentów" a "mam flotę".

Gdy maszyna jest pełnoprawnym bytem ze znanym profilem sprzętowym, wiele rzeczy staje się łatwych:

  • Ciężkie wnioskowanie kierowane do GPU; klasyfikacja do taniego CPU.
  • Agenci na różnych maszynach widzą się przez Consciousness Server i koordynują po nazwie.
  • Maszyna offline triggeruje automatyczne re-routing oczekujących zadań.
  • Możesz wynająć moc obliczeniową dodając węzeł — reszta floty adoptuje go przez deskryptor YAML.

Realny przykład

Produkcyjny setup autora, modelowany w YAML:

  • Stacja robocza z GPU — Cortex z gemma4:26b, bierze ciężkie wnioskowanie i zadania code review.
  • Host aplikacyjny (CPU only) — Cortex z gemma4:e4b, obsługuje klasyfikację, sumaryzowanie, szybką pracę krótkokontekstową.
  • Laptop — interaktywni agenci, orkiestracja, główne stanowisko developera.

Wszystkie trzy widzą tę samą wspólną pamięć w Consciousness Server. machines-server mówi każdemu agentowi, który z nich ma rezerwę teraz. Zadania płyną do tego węzła, który ma sens.

Dokąd to zmierza — kierunki eksploracyjne

Paradygmat się generalizuje: wszystko, co ma kontroler, stan i telemetrię, jest maszyną. Żaden ze scenariuszy poniżej nie działa dziś; opisują, co architektura umożliwia, gdy istnieją odpowiednie adaptery. Oznaczamy je Planned lub Exploratory uczciwie — flagujemy tutaj, żeby kontrybutorzy i klienci mogli kształtować roadmapę razem z nami.

Prototypownia / mała fabryka

Drukarki 3D, plotery, frezarki CNC, lasery. Agent podejmuje kolejkę druku, dyspatchuje pliki do drukarek z odpowiednim materiałem, monitoruje stan zadania, raportuje awarie. Mieszane deterministyczne wykonanie (gcode trafia do drukarki dosłownie) z niedeterministycznymi decyzjami (który plik pierwszy, która drukarka, co robić przy zacięciu). Planned.

Lab biologiczny / kliniczny

Inkubatory, cytometry, sekwencery. Agent czyta metadata eksperymentu, planuje próbki, cross-reference rezultaty z wspólną pamięcią w Consciousness Server ("jak ten sam warunek zachowywał się w runie z zeszłego tygodnia?"). Lab notebooks stają się odpytywalnym korpusem. Planned.

Infrastruktura energetyczna

Panele PV, magazyny baterii, ładowarki EV, obciążenie serwerowni. Agent balansuje, kiedy ładować auto, kiedy zasilić serwery, kiedy sprzedać nadwyżkę do sieci. Wszystko lokalnie, bez chmury dostawcy znającej Twój domowy harmonogram energetyczny. Exploratory.

Budynek / smart-home enterprise

HVAC, czujniki klimatu, rolety, oświetlenie. Agent uczy się wzorców obecności, sugeruje optymalizacje, nigdy nie dzwoni do chmury producenta. Exploratory.

Drony — zastosowania niekinetyczne

Choreografia pokazów świetlnych, inspekcja infrastruktury (Twoje rurociągi, wieże, dachy), monitoring rolnictwa precyzyjnego. Każdy dron jest maszyną z telemetrią; agenci planują trasy, reagują na wiatr, optymalizują rotację baterii. Zastosowania kinetyczne / uzbrojenia są poza zakresem licencji — patrz etyka. Exploratory.

Prywatna flota / ciężki sprzęt

Ciężarówki, kombajny, koparki na pojedynczym terenie właściciela. Telemetria, diagnostyka, predictive maintenance — kluczowane do infrastruktury właściciela, nie do chmury producenta. Exploratory.

Ważne ramy: wszystkie powyższe to co architektura umożliwia, nie co dostarcza dziś. Nigdy nie twierdzimy "już sterujemy dronami" albo "prowadzimy farmę druku 3D". Twierdzimy "agent może wiedzieć, że maszyna A ma pojemność GPU, a maszyna B jest offline" — to jest Ships. Reszta to przestrzeń projektowa otwarta przez traktowanie maszyn jako pełnoprawnych bytów.

Czerwone linie — czego nie umożliwimy

Zapisane w naszej licencji komercyjnej, nie tylko marketing:

  • Systemy uzbrojenia — kinetyczne, autonomiczne targetowanie, AI-naprowadzana amunicja. Nie.
  • Masowa inwigilacja — obserwacja w skali miasta, face recognition w skali, social scoring, predykcja behawioralna do represji politycznych. Nie.
  • Autonomiczna infrastruktura krytyczna bez nadzoru człowieka — sieci energetyczne, kontrola ruchu, decyzje kliniczne podejmowane bez nadzoru lekarskiego. Nie.

Jeśli Twój przypadek użycia stoi w sprzeczności z tymi liniami, BuildOnAI nie jest dla Ciebie odpowiednim narzędziem. Licencja egzekwowana jest kontraktowo, nie jako slogan marketingowy.

Dalsze kroki