Agenty AI w produkcji 2026: moja architektura CAPCOM/MCC
Jak zaprojektować system multi-agentowy, który nie gubi kontekstu i działa stabilnie w środowisku produkcyjnym 4 marek technologicznych.
Architektura CAPCOM/MCC to wzorzec orkiestracji agentów AI oparty na rozdziale ról: dyspozytor centralny zarządza stanem i deleguje zadania do wyspecjalizowanych sub-agentów z bezpośrednim dostępem do baz PostgreSQL i protokołu MCP, co eliminuje halucynacje i zapewnia pełną deterministyczność operacyjną.
Wstęp: Koniec ery prostych promptów
W 2026 roku proste wrappery na API LLM przestały wystarczać. Klienci biznesowi oczekują systemów, które realizują wieloetapowe zadania, weryfikują własne wyniki i nie gubią stanu po restarcie sesji. Robiłem to we wtorek w LabAI — gdy jeden z agentów napotkał błąd parsowania JSON, cały pipeline zablokował się na 40 minut. To zmusiło nas do przebudowy podejścia.
W ramach LabAI rozwijamy system orkiestracji nazwany wewnętrznie CAPCOM / MCC (Mission Control Center).
3 filary architektury produkcyjnej
- Deterministyczna pamięć stanowa: Baza PostgreSQL jako jedno źródło prawdy (Single Source of Truth), a nie ulotny bufor kontekstu LLM.
- Protokół MCP (Model Context Protocol): Standaryzacja komunikacji między agentami a narzędziami systemowymi i bazami danych.
- Specjalizacja agentów zamiast jednego 'omnipotentnego' prompta: Podział zadań na architekta, wykonawcę, testera i audytora bezpieczeństwa.
// Przykładowy kontrakt dyspozytora CAPCOM
export interface AgentTask {
id: string;
role: 'planner' | 'executor' | 'qa' | 'reviewer';
payload: Record<string, unknown>;
contextId: string;
}Dlaczego PostgreSQL i pgvector zamiast niszowych baz?
Wielu vendorów promuje wyspecjalizowane wektorowe bazy no-SQL. W praktyce produkcyjnej w DBAdmin przekonaliśmy się, że trzymanie danych relacyjnych, logów transakcyjnych i wektorów w jednym klastrze PostgreSQL drastycznie upraszcza architekturę i eliminuje problemy ze spójnością transakcji (ACID).
Testowałem to na 3 moich markach: zapytania hybrydowe (SQL + wektory) wykonują się w czasie poniżej 12ms bez konieczności synchronizacji dwóch niezależnych silników bazodanowych.
Podsumowanie i rekomendacja
Jeśli budujesz system agentowy w software house lub startupie, nie zaczynaj od skomplikowanych frameworków full-autonomous. Zacznij od jasnego podziału ról i stabilnej bazy danych.
Powiązane marki technologiczne i laboratoria produkcyjne:
Architekturę opisaną w tym artykule wdrożyłem i przetestowałem bezpośrednio w następujących markach: