Co robi dziś
machines-server to usługa Flaska wystawiona na porcie hosta 13038 (port kontenera 3038), dostarczana z Consciousness Server. Nie jest tylkoczytnikiem 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-smina hoście i parsuje procent wykorzystania, używany / całkowity VRAM w MB, oraz temperaturę GPU. Zwracanullczysto 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.yamlw momencie zapytania, otwiera połączenia HTTP do każdego zadeklarowanego portu, klasyfikuje każdą jakoactivealboinactivena 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>.yamlze 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 plusmachine configs plus runtime machines z CSplus usługi z aktualnym statusem pluszarejestrowanych agentów. Jedna odpowiedź na pytanie "jaki jest stan całego ekosystemu w tej chwili?". - Natywne wsparcie protokołu MCP — wystawia
/mcp/toolsi/mcp/call. Każdy klient obsługujący MCP może używać machines-server bezpośrednio jako tool provider, wywołującget_system_resources,get_infrastructurealbolist_machinesbez pisania własnego kodu HTTP. - Uwierzytelnianie ed25519 — chronione żądania wymagają podpisu weryfikowanego 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 |
| 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:
- Agent kieruje ciężkie wnioskowanie na GPU, a klasyfikację na tani CPU, bo widzi, który jest który.
- Agenci na różnych maszynach widzą się przez Consciousness Server i koordynują po nazwie.
- Maszyna offline jest widoczna dla każdego agenta, więc oczekującą pracę można podjąć gdzie indziej. Automatyczny re-routing: Planned.
- 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. Agent wybiera węzeł, 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 lubExploratory 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 badawczy (biologia)
Inkubatory, cytometry, sekwencery. Agent czyta metadata eksperymentu z LIMS, cross-references nowe wyniki ze 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. Celuje najpierw w środowiska badawcze; wdrożenia kliniczne wymagają osobnej walidacji regulacyjnej.
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
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. Exploratory.
Prywatna flota / ciężki sprzęt
Ciężarówki, kombajny, koparki i inne maszyny różnych producentów u jednego właściciela. Dziś każdy producent ma swoją chmurę telematyczną — właściciel mieszanej floty loguje się do kilku osobnych portali, a telemetria, historia pracy i dane do predictive maintenance rozsypane są po tylu chmurach ilu producentów. Zamiast tego jeden, świadomy system utrzymania ruchu (CMMS) pod kontrolą właściciela: zbiera telemetrię lokalnie z każdej maszyny niezależnie od producenta, prowadzi predictive maintenance na sprzęcie który właściciel posiada, trzyma pełną historię serwisową w jednym miejscu — nie w pół tuzinie portali producentów. Exploratory.
Dostępne dziś: agent może wiedzieć, która maszyna ma pojemność GPU, a która jest offline. Powyższe przypadki użycia opisują przestrzeń projektową otwartą przez traktowanie maszyn jako pełnoprawnych bytów — nie są deklaracjami o dziś.
Dalsze kroki
- Consciousness Server (gdzie żyje machines-server) →
- Cortex (agent działający na każdej maszynie) →
- Zobacz Consciousness Server na GitHub