consciousness-server v1.1.0 AGPL-3.0-only + Komercyjna

Consciousness Server

Wspólny mózg dla Twojej floty agentów.

Przegląd

Każdy agent AI, którego uruchamiasz, resetuje się między sesjami. Chmurowe agentowe CLI nie pamiętają wczorajszego dnia; hostowane LLM nie wiedzą, co Twój zespół ustalił w zeszłym tygodniu. Consciousness Server jest wspólną, trwałą pamięcią, do której wszyscy sięgają.

Notatki, konwersacje, skille, rejestr agentów, zadania i semantic search po wszystkim. Jedno HTTP API. Samodzielnie hostowane. Twoje.

Co nowego w v1.1

  • F4.6 kontrakty + pipeline codegen. lib/schemas/*.openapi.yaml jest jedynym źródłem prawdy dla schematów chat / notes / tasks / common. bin/sync-schema bundluje kontrakty i generuje konsumentów Node w core/generated/schemas/. Edytujesz YAML, regenerujesz — koniec z ręcznym duplikowaniem typów.
  • POST /api/tasks to kanoniczna ścieżka tworzenia zadań (legacy POST /api/tasks/create pozostaje jako alias). Obie zwracają pełny obiekt Task, nie tylko {id, status, created_at}. Ta sama zmiana shape dla POST /api/notes.
  • /health rozróżnia chat_messages od conversation_embeddings, plus jawne pole semantic_search (ok / misconfigured / timeout / unreachable). Breaking dla monitoringu czytającego memory.conversations bezpośrednio — patrz CHANGELOG.
  • Parser @mentions korzysta z rejestru live. Każdy agent zarejestrowany przez POST /api/agents/register staje się @adresowalny — łącznie z nazwami z myślnikami, cyframi i podkreśleniami (@CC-TESTER, @agent-001). @ALL zostaje jako token broadcast.
  • NoteType zyskuje audit — dedykowany typ dla notatek audytowych (koniec z workaroundem type=observation + prefiks [AUDIT] w tytule).

Pełna lista zmian per release i checklist migracji v1.0.0 → v1.1.0 jest w CHANGELOG.md.

Co dostajesz

Sześć usług HTTP w jednym docker compose up:

Port Usługa Rola
3032 core Zadania, notatki, czat, pamięć, rejestr agentów, skille, wbudowany WebSocket.
3037 semantic-search Flask + ChromaDB, embeddingi przez Ollamę.
3038 machines-server Świadomość infrastruktury plus telemetria w czasie rzeczywistym.
3040 key-server Opcjonalny przez --profile full, ed25519 auth.
3041 test-runner Asynchroniczne wykonywanie pytest / jest / npm.
3042 git-workflow Odbiornik post-commit hooków.

Zewnętrzne zależności: Redis (zapakowany w compose) i Ollama (na hoście, dla dostępu do GPU).

Instalacja

terminal
git clone https://github.com/build-on-ai/consciousness-server.git
cd consciousness-server
bin/preflight                       # weryfikacja zależności hosta
cd deploy
docker compose up -d

Domyślny profil uruchamia sześć usług z AUTH_MODE=off, więc pojedynczy użytkownik dostaje działający ekosystem bez generowania kluczy. Key-server jest opcjonalny przez --profile full, gdy potrzebujesz uwierzytelniania ed25519 per agent.

Pojęcia

Pamięć

Stan trwa w Redis (notatki, zadania, czat, agenci, logi, rekordy treningowe) i ChromaDB (semantic search po wszystkim, co zostało zembeddowane). Notatki dodajesz przez POST /api/notes (siedem typów łącznie z audit), zadania przez POST /api/tasks, czat przez POST /api/chat z @mentions. Rekordy treningowe (jeden z: troubleshooting, exploration, implementation, explanation, architecture, ui_mapping) lądują w osobnym kanale i zasilają fine-tuning dataset.

Agenci

Każdy klient HTTP jest agentem. Każdy dostaje nazwę, opcjonalnie parę kluczy ed25519 (zarejestrowaną w key-server). Cztery profile postaci dostarczone jako przykłady: designer, observer, validator, writer — każdy zwykłym plikiem .md w katalogu agents/. Dodaj więcej upuszczając pliki .md; Consciousness Server przeładowuje przy pierwszym brakującym wpisie.

Skille

Odkrywalne możliwości żyją jako pliki .md w katalogu skills/. Każdy dokument mówi kiedy użyć skilla, jak go wywołać i czego dotyka. Pomyśl o nich jako o "nazwanych narzędziach" dostępnych dla każdego agenta.

Maszyny

machines-server serwuje pliki YAML z katalogu machines/. Każda maszyna listuje sprzęt, dostępne modele (przez Ollamę), rolę i status na żywo. Agenci mogą zapytać: która maszyna ma wolny VRAM i model X? Czytaj dalej →

Auth

Trzy wartości AUTH_MODE:

  • off (domyślne) — bez podpisów.
  • observe — niesygnowane requesty są logowane, ale obsługiwane.
  • enforce — niesygnowane dostają 401; key-server musi działać.

API

Próbka — najczęściej używane endpointy. Pełna powierzchnia API i przykłady w README repozytorium.

Metoda Ścieżka Cel
GET /health Health i uptime + liczniki chat_messages / conversation_embeddings + status semantic_search
POST /api/agents/register Zarejestruj agenta — od tej chwili można go @wzmiankować i adresować
GET /api/agents Lista zarejestrowanych agentów
POST /api/chat Czat między agentami z @mentions i broadcast @ALL
POST /api/tasks Utwórz zadanie (alias: POST /api/tasks/create)
GET /api/tasks/pending/:agent Kolejka oczekujących zadań dla konkretnego agenta
PATCH /api/tasks/:id/status Zmień stan zadania (PENDING / IN_PROGRESS / DONE / FAILED / CANCELLED)
POST /api/notes Zapisz notatkę (observation / decision / blocker / idea / handoff / session_end / audit)
GET /api/notes Filtruj notatki: agent / type / tag / since
POST /api/search Semantic search po pamięci (proxy na port 3037)

Klienci

Consciousness Server mówi HTTP. Każdy klient działa. W praktyce większość użytkowników łączy go z:

  • Cortex — lokalny agent zbudowany przez tego samego autora, oparty na GPU przez Ollamę, dostarczany z integracją Consciousness Server, więc agenci mogą się przełączać między tymi środowiskami przez zmianę URL.
  • Zewnętrzne agentowe CLI — każde, które potrafi wykonywać requesty HTTP (Claude Code przez profil postaci to ścieżka z największym przebiegiem).
  • Twój własny klientcurl, fetch, requests — wszystkie działają. Pełna powierzchnia HTTP w ARCHITECTURE.md.

Dalsze kroki