Anatomia zespołu biznesowego opartego na sztucznej inteligencji: koordynacja agentów za pomocą LangGraph i FastAPI
Przewodnik po platformie open-source opartej na wielu agentach: jak kozałożyciele, menedżerowie oraz specjaliści są koordynowani, dzielą się informacjami, wstrzymują pracę w oczekiwaniu na zatwierdzenie i składają raporty.
Większość systemów automatyzacji opartych na sztucznej inteligencji nadal funkcjonuje w modelu jednego agenta: jeden model otrzymuje zapytanie i zwraca odpowiedź. To wystarcza do odpowiadania na pytania, ale rzeczywista praca biznesowa jest rozproszona między różne role, niektóre kroki są wykonywane równolegle, a inne wymagają zatwierdzenia przez osobę. Niniejszy przewodnik analizuje platformę open-source Multi Agent for Business Automation, która modeluje mały zespół startupu jako skoordynowanych agentów. Pod koniec powinieneś zrozumieć, jak ze sobą łączą się jej mechanizmy orkiestracji, pamięć, procedury zatwierdzania oraz interfejs API, a także jakie rozwiązania projektowe możesz wykorzystać w swoich własnych systemach agentów.
Rozważmy, w jaki sposób planuje się nowy projekt. Założyciel formułuje wizję. Menedżer przekształca ją w konkretne zadania. Dział finansowy sprawdza założenia dotyczące przychodów i kosztów, marketing ustala pozycjonowanie rynkowe, dział prawny analizuje ryzyka, a sprzedaż przygotowuje działania marketingowe. Część z tych działań odbywa się sekwencyjnie, część jednocześnie, a niektóre są wstrzymywane do czasu zatwierdzenia kolejnego kroku przez człowieka.
Zgodnie z plikiem README, projekt stanowi platformę do automatyzacji pracy biznesowej i wspierania decyzji, w której agenci o różnych rolach, osobowościach i narzędziach są koordynowani za pomocą procesów LangGraph, wspólnej pamięci oraz mechanizmów zatwierdzania z udziałem człowieka (HITL), przy jednoczesnym generowaniu raportów i integracjach z zewnętrznymi systemami. Celem nie jest stworzenie kolejnego chatbota, lecz wirtualne biuro, w którym agenci mogliby współpracować tak jak zespół startupu.
Pięć warstw architektonicznych
System jest klarownie podzielony na pięć warstw:
- Frontend: panel sterowania w React do onboardingu opartego na czacie, wizualizacji procesów pracy, zatwierdzania i analiz.
- Backend API: punkty końcowe REST w FastAPI, strumienie WebSocket, autoryzacja, raporty oraz API pamięci.
- Warstwa agentów: agenci Cofounder, Manager, Finance, Marketing, Legal, Money i Sales.
- Warstwa orkiestracji: procesy pracy LangGraph w połączeniu z dostosowanym orkiestratorem, delegowaniem zadań i kontrolą postępów.
- Pamięć i infrastruktura: Neo4j, Qdrant, Redis lub Upstash, Supabase oraz przechowywanie raportów.
Zgodnie z dokumentacją README, stos składa się z React 18 w połączeniu z Vite, FastAPI, LangGraph oraz LangChain i CrewAI do zarządzania pracami agentów, Neo4j, Qdrant i Redis do przechowywania danych w pamięci i kolejkach, a także Supabase jako opcjonalne rozwiązanie do autoryzacji i przechowywania danych.
Ogólny proces odbywa się od góry do dołu: od koncepcji użytkownika, przez agenty kierownicze, po specjalistów, a na końcu dane trafiają do wspólnej pamięci, są sprawdzane pod kątem zatwierdzeń i przekazywane dalej.
User Vision
↓
Cofounder Agent
↓
Manager Agent
↓
Specialist Agents
├── Finance
├── Marketing
├── Legal
├── Money
└── Sales
↓
Shared Memory + Approval Gates
↓
Reports + Dashboard + Integrations
Ważne jest zrozumienie, że to rozwiązanie stanowi system procesów pracy, a nie łańcuch poleceń. Stan, pamięć, zatwierdzenia, próby ponowne, możliwość obserwacji oraz przechowywane wyniki to wszystko elementy pierwszorzędnej wagi.
Pięciostopniowy proces pracy
Etap 1: przekształcenie niejasnej idei w ustrukturyzowany kontekst
Wszystko zaczyna się w momencie, gdy użytkownik wyjaśnia, czego chce: koncepcję produktu, pomysł biznesowy lub jakiś cel operacyjny. Agent współzałożyciela otrzymuje te informacje, które mogą być tak ogólne jak pojedyncze zdanie:
Input:
"I want to build an AI tool for small businesses."
Jego zadaniem jest przekształcenie tych informacji w ustrukturyzowany kontekst, z którego może korzystać reszta zespołu:
Cofounder Output:
- Vision statement
- Target users
- Problem definition
- Market opportunity
- Strategic assumptions
- Initial business direction
W dokumencie README ten krok jest określony jako „Vision intake”. W tle może zostać uruchomiony poprzez kilka punktów wejścia, w zależności od tego, czy klient chce projekt jednorazowy, rozmowę czy rozszerzoną sesję:
POST /api/start-project
POST /api/conversation/start
POST /api/enhanced/start-session
Niezależnie od wybranej ścieżki, tło tworzy projekt lub sesję, zapisuje początkowy stan i przekazuje wiadomość odpowiedniemu agentowi.
Etap 2: planowanie i delegowanie przez menedżera
Gdy wizja jest już ustrukturyzowana, agent menedżera przejmuje kontrolę i dzieli strategię na konkretne zadania, które można faktycznie wykonać:
Manager Responsibilities:
- Convert vision into roadmap
- Break work into functional domains
- Create agent assignments
- Define task dependencies
- Decide which agents should execute in parallel
W tym niestandardowym orkiestratorze jest to zaimplementowane w funkcji AgentOrchestrator.start_project(), znajdującej się w pliku backend/flows/orchestrator.py. Funkcja ta generuje identyfikator projektu, najpierw uruchamia Cofoundera, przekazuje jego wynik menedżerowi, a następnie uruchamia specjalistów zgodnie z zadaniami przydzielonymi przez menedżera. W pseudokodzie:
cofounder_result = await Cofounder.execute(vision_task)
manager_result = await Manager.execute(manager_task)
specialist_results = await execute_specialists(manager_result)
generate_outputs(all_results)
Menedżer stanowi warstwę kontrolną. Bez niego każdy specjalista pracowałby samodzielnie na podstawie surowej koncepcji, dostarczając wyniki, które nie odnoszą się do siebie nawzajem. Centralizacja procesu dekompozycji w jednym agencie sprawia, że wyniki specjalistów tworzą spójny plan.
Etap 3: równoległe uruchamianie specjalistów
Gdy zadania zostaną przydzielone, przejmują je agenci domeny. Standardowy skład zespołu i ich obowiązki to:
- Współzałożyciel: wizja, strategia i możliwości rynkowe.
- Menedżer: plan działania, podział zadań i delegowanie obowiązków.
- Finanse: model przychodów, model kosztów, zwrot z inwestycji i prognozy.
- Marketing: pozycjonowanie, kampanie i strategia treści.
- Prawo: zgodność z przepisami, zarządzanie ryzykiem, umowy i weryfikacja polityk.
- Pieniądze: ustalanie cen, monetyzacja i operacje związane z przychodami.
- Sprzedaż: proces sprzedaży, pozyskiwanie klientów i strategia sprzedaży.
Każdy agent jest zdefiniowany w pliku backend/agents/personalities.py, a każda definicja obejmuje cechy charakteru, styl komunikacji, obszary specjalizacji oraz narzędzia specyficzne dla danej roli. To ma znaczenie: agenci są modelowani jako wykonawcy specyficzni dla danej roli, posiadający własne zachowanie, progi pewności siebie oraz kontekst zadań, a nie tylko jako różne instrukcje systemowe.
Egzekucję zajmuje się funkcja _execute_specialists(), która przygotowuje jedno zadanie na każdego specjalistę (Finanse, Marketing, Prawo i Finanse, a także Sprzedaż w przypadku jej aktywacji). Każda próba wywołania agenta jest objęta czasem oczekiwania wynoszącym 60 sekund:
parallel_executions = [
asyncio.wait_for(agent.execute(task), timeout=60.0)
for agent_name, task in specialist_tasks
]
Wszystkie te objęte czasem oczekiwania wywołania są następnie oczekiwane jednocześnie:
specialist_results = await asyncio.gather(
*parallel_executions,
return_exceptions=True
)
Ponieważ asyncio.gather() przyjmuje parametr return_exceptions=True, czas wykonywania lub awaria w jednym agencie są zwracane jako obiekty wyjątków w liście wyników, zamiast anulować całą serię operacji. Konsekwencją jest to, że kod wywołujący musi sprawdzić każdy wynik i zdecydować, czy agencja, która zawiodła, powinna zostać ponownie uruchomiona, pominęta czy przekazana do wyższego poziomu zarządzania. Ogólne rozwiązanie jest słuszne: gdy analiza finansowa nigdy nie potrzebuje wyników z działu marketingu, lub odwrotnie, nie ma powodu, by wykonywać je po kolei.
Etap 4: wspólna pamięć i propagacja kontekstu
System wielu agentów szybko traci wydajność, gdy każdy z nich ma dostęp tylko do swojego własnego kontekstu. Platforma radzi sobie z tym za pomocą zintegrowanej warstwy pamięci, w której każda baza danych pełni określoną funkcję:
Neo4j → graph memory and relationships
Qdrant → vector memory and semantic retrieval
Redis → task queue, cache, runtime coordination
Local data → fallback storage and exported outputs
README podsumowuje to jako pamięć grafową Neo4j, wyszukiwanie wektorowe Qdrant, kolejki Redis lub Upstash oraz lokalne cache z uprzejmym fallbackiem. Każdy z tych rozwiązań służy do zaspokojenia innych potrzeb.
Pamięć grafowa rejestruje relacje pomiędzy agentami, zadaniami, projektami i wynikami:
Agent → executed → Task
Task → belongs_to → Project
Agent → produced → Output
Output → depends_on → PriorContext
Taka struktura umożliwia wizualizację współpracy oraz dokładne śledzenie tego, który agent stworzył dany wynik i w jakim wcześniejszym kontekście.
Pamięć wektorowa w Qdrant umożliwia semantyczne odzyskiwanie informacji, dzięki czemu agent może wyszukać wcześniejsze prace na podstawie znaczenia, a nie ID:
"Find previous market assumptions."
"Retrieve prior financial analysis."
"Use the earlier legal risk summary."
Pamięć kolejek oparta na Redis służy do koordynacji w trakcie wykonywania zadań:
- Event streaming
- Task queues
- Cache
- Agent activity updates
- WebSocket event propagation
Projekt również funkcjonuje prawidłowo, gdy brakuje niektórych usług. Podczas rozwoju lokalnego Redis może zostać zastąpiony adapterem pamięciowym, a wywołania LLM mogą być kierowane do symulowanego dostawcy. Dzięki temu łatwiej jest uruchomić cały system na laptopie bez konieczności przygotowywania wszystkich zależności produkcyjnych, choć oznacza to również, że testy lokalne nie ujawnią problemów, które pojawiają się tylko przy użyciu rzeczywistych usług.
Etap 5: zatwierdzenie przez człowieka
Działania o dużym wpływie nie powinny być wykonywane bezrefleksyjnie, dlatego tutaj zatwierdzenie przez człowieka stanowi integralną część głównego procesu pracy, a nie dodatek. Zasady te odnoszą się do decyzji, które mogą wpłynąć na:
- Customer-facing campaigns
- Pricing recommendations
- Legal-sensitive outputs
- CRM updates
- Social media publishing
- Financial projections
- Business-critical recommendations
W dokumencie README podkreślone są mechanizmy powiadamiania w Slacku oraz konfigurowalne limity czasowe dla tych procesów zatwierdzania. Z perspektywy API, możliwości zatwierdzania są dostępne poprzez takie punkty końcowe jak:
GET /api/approvals/pending
POST /api/approvals/{approval_id}/respond
GET /api/approvals/advanced/pending
GET /api/approvals/stats
Podstawowy cykl życia procesu zatwierdzania wygląda w następujący sposób:
Agent generates action
↓
System evaluates confidence/risk
↓
Approval request is created
↓
Frontend or Slack notifies human
↓
Human approves/rejects/provides feedback
↓
Workflow continues or stops
Wynikiem jest model autonomii warstwowej: prace o niskim ryzyku są realizowane automatycznie, natomiast wszystko, co dotyczy klienta, finansów lub jest wrażliwe pod względem prawnym, wymaga decyzji człowieka. Jeśli projektujesz podobne mechanizmy, powiązany przewodnik dotyczący schematów routingu, rozprzestrzeniania i zatwierdzania w LangGraph szczegółowo omawia mechanizmy na poziomie grafu.
Wewnątrz backendu FastAPI
Główny punkt wejścia backendu, backend/main.py, tworzy instancje zestawu usług globalnych po uruchomieniu aplikacji:
AgentOrchestrator
Enhanced Orchestrator
ReportGenerator
SimplePredictor
AgentCollaborator
AdvancedApprovalManager
AgentService
ReportService
LangGraphOrchestrator
Queue Manager
Zgodnie z README, każda trasa jest montowana przez backend/main.py; backend/api/main.py to lżejszy punkt wejścia, który montuje tylko podzbiór tras. Kod jest zorganizowany według zasad odpowiedzialności:
backend/
├── main.py # Primary FastAPI app
├── api/ # Route controllers
├── agents/ # Agent implementations and personalities
├── workflows/ # LangGraph and HITL orchestrators
├── flows/ # PRD DAG orchestrator
├── memory/ # Graph, vector, cache managers
├── task_queue/ # Redis/Upstash queue with fallback
├── integrations/ # HubSpot, Slack, Instagram clients
├── approvals/ # Approval managers
├── collaboration/ # Cross-agent communication
├── outputs/ # Report generation
├── analytics/ # Predictions and metrics
├── auth/ # Supabase auth
├── services/ # LLM, agent, report services
└── tools/ # Search and tool registry
Warto zwrócić uwagę na rozdzielenie katalogów workflows/ (orchestratory LangGraph i HITL) od katalogu flows/ (orchestrator DAG oparty na PRD): projekt wykorzystuje obie metody orkiestrowania równocześnie, co jest elastyczne, ale wymaga sprawdzania, który ścieżka jest używana przez dany punkt końcowy.
Interfejs API, grupa po grupie
Autoryzacja
POST /api/auth/signup
POST /api/auth/signin
GET /api/auth/user
W trybie przypominającym produkcję te punkty końcowe polegają na autoryzacji Supabase. W trybie lokalnym lub demonstracyjnym aplikacja może całkowicie pominąć Supabase i użyć lżejszej logiki rozwojowej. Opcje konfiguracyjne wymienione w README to DEMO_MODE, zmienne Supabase oraz zmienne dostawcy LLM. Odpowiednie obsługi:
signup() → creates user account
signin() → authenticates user
get_current_user()→ verifies token and returns user profile
Życiowy cykl projektu
GET /api/projects
POST /api/projects
POST /api/start-project
POST /api/auto-execute
GET /api/auto-execute/status
Te odpowiadają następującym funkcjom:
get_user_projects() → fetch projects for authenticated user
create_project() → create new project record
start_project() → execute Cofounder → Manager → Specialists workflow
auto_execute_project() → start automated coordination from raw vision
get_auto_execution_status() → return execution progress and logs
start_project() jest sercem tej grupy. Jej wewnętrzna sekwencja wygląda następująco:
1. Generate project_id
2. Execute Cofounder Agent
3. Log Cofounder result
4. Execute Manager Agent with Cofounder context
5. Log Manager result
6. Execute specialist agents in parallel
7. Export and persist final outputs
8. Return project status and timeline
Ta sekwencja odpowiada bezpośrednio AgentOrchestrator.start_project() oraz _execute_specialists() w module orkiestratora.
Zaostrzone sesje
POST /api/enhanced/start-session
POST /api/enhanced/continue-session
POST /api/enhanced/approve-and-execute
GET /api/enhanced/session-status
GET /api/enhanced/live-logs
GET /api/enhanced/session-results
GET /api/enhanced/system-metrics
POST /api/enhanced/cancel-session
POST /api/enhanced/cleanup-sessions
Każdy punkt końcowy ma wąski cel:
start-session → create enhanced automation session
continue-session → continue existing multi-turn planning session
approve-and-execute → approve captured vision and run workflow
session-status → inspect session state
live-logs → stream logs for UI monitoring
session-results → return final session output
system-metrics → expose high-level runtime metrics
cancel-session → stop active session
cleanup-sessions → remove old sessions
To jest bardziej zorientowany na produkcję sposób, ponieważ dzieli rozmowę, zatwierdzenie, wykonywanie, monitorowanie oraz pobieranie wyników na oddzielne żądania. Klient może sprawdzać status lub przesyłać logi w strumieniu bez utrzymywania otwartego długiego żądania, a sesję można wyraźnie anulować lub usunąć.
Zarządzanie agentami
GET /api/agents/status
GET /api/agents/list
GET /api/agents/personalities
GET /api/agents/configs
POST /api/agents/configs
POST /api/agents/execute
GET /api/agents/logs/live
Co robi każda trasa:
agents/status → current status of all agents
agents/list → available agent inventory
agents/personalities→ UI-visible personality metadata
agents/configs → current agent runtime settings
update configs → update temperature, approval mode, priority, enabled flag
agents/execute → execute a single agent manually
logs/live → recent agent execution logs
Gdy wywołuje się /api/agents/list, lista agentów jest zwracana uporządkowana w cztery kategorie (strategiczne, biznesowe, operacyjne, specjalistyczne), a punkty konfiguracji w czasie wykonywania umożliwiają operatorowi zmianę temperatury, trybu zatwierdzania, priorytetu oraz ustawienia aktywności agenta.
Rozmowy
POST /api/conversation/start
POST /api/conversation/{conversation_id}/message
POST /api/conversation/{conversation_id}/approve
Procedury obsługujące je:
start_conversation() → starts a Cofounder-led discovery conversation
continue_conversation() → continues the existing conversation with stored context
approve_conversation() → approves the captured vision and starts task distribution
Taki schemat istnieje po to, aby system mógł zebrać wystarczająco dużo informacji przed poświęceniem wysiłku na specjalistycznych agentów. Wewnętrznie przebiega to w następujący sposób:
1. User sends initial idea
2. Cofounder Agent asks clarifying questions or structures the vision
3. Conversation state is persisted
4. System detects whether vision is ready for approval
5. User approves
6. System starts agent coordination
W orkiestratorze funkcja start_conversation() przydziela nowy identyfikator rozmowy, zapisuje to, co napisał użytkownik, wywołuje agenta Cofounder, przechowuje odpowiedź i zwraca flagę ready_for_approval, która informuje klienta, czy wizja jest wystarczająco kompletna do zatwierdzenia.
Przepływy LangGraph
POST /api/workflow/execute
POST /api/workflow/resume/{thread_id}
Odpowiednie funkcje:
execute_langgraph_workflow() → runs a LangGraph-based workflow
resume_workflow() → resumes workflow from checkpoint
Te punkty końcowe udostępniają warstwę LangGraph bezpośrednio. W dokumencie README opisuje się je jako maszyny stanowe LangGraph, które zapisują swoje postępy, mogą same się korygować oraz zawierają węzły przerwy, w których interweniuje człowiek. Kluczową właściwością jest możliwość kontynuacji: gdy długo trwający proces zostanie wstrzymany w oczekiwaniu na zatwierdzenie lub zawiedzie w połowie, powinien kontynuować od ostatniego punktu kontrolnego, zamiast zaczynać od nowa i ponownie płacić za każde wezwanie LLM. Nasze omówienie sposobu, w jaki LangGraph's InMemorySaver przechowuje punkty kontrolne wyjaśnia, co faktycznie jest zapisywane na każdym kroku.
Raporty
GET /api/reports/comprehensive
GET /api/reports/{report_type}
POST /api/reports/generate-pdf
GET /api/reports/download/{filename}
GET /api/reports/domains
GET /api/reports/domains/{domain}
Co generuje każda ścieżka raportu:
comprehensive report → generate full business report
specific report → generate executive, marketing, financial, etc.
generate PDF → convert report data into downloadable PDF
download report → serve generated PDF/HTML
domain reports → return modular reports by business domain
Generowanie raportów to kluczowa funkcjonalność: raporty dla kierownictwa, marketingu, finansów oraz kompleksowe raporty w formacie JSON, przy czym pliki PDF są generowane za pomocą WeasyPrint. To właśnie odróżnia ten system od chatbotów, ponieważ końcowym rezultatem jest artefakt biznesowy, a nie wiadomość z czatu.
Pamięć
GET /api/memory/graph
GET /api/memory/stats
POST /api/memory/export
DELETE /api/memory/clear
A to, co zwracają:
memory/graph → return graph nodes and edges for visualization
memory/stats → return vector/graph memory statistics
memory/export → export stored memory and outputs
memory/clear → clear memory stores
README grupuje je pod adresem /api/memory/* w celu eksportu grafów i statystyk. Dzięki nim można sprawdzić zgromadzoną wiedzę agentów, prześledzić ich wyniki oraz zobaczyć, ile pamięci zużywa każdy backend. Należy pamiętać, że endpoint do usunięcia danych ma charakter destruktywny i wymaga takich samych kontroli dostępu jak każda inna akcja administracyjna.
Analityka
GET /api/analytics/predictions
GET /api/enhanced/system-metrics
GET /api/communication/stats
Ich przeznaczenie:
predictions → analyze generated outputs and estimate success/revenue/market timing
system metrics → return enhanced orchestrator metrics
communication stats → return inter-agent communication analytics
Za nimi kryją się proste funkcje pomocnicze:
_analyze_project_success()
_analyze_revenue_trend()
_analyze_market_timing()
To narzędzia analizujące wyniki generowanych przez agenty i wyciągające informacje przydatne dla biznesu, takie jak prawdopodobieństwo sukcesu, kierunek wzrostu przychodów oraz zalecony moment działania. Są to heurystyki oparte na tekście generowanym, dlatego ich wyniki należy traktować jako wskazówki, a nie prognozy.
Integracje
/api/integrations/*
W repozytorium wymieniono HubSpot, Slack oraz Instagram Business API, z których każdy pełni określoną rolę:
HubSpot → CRM workflows
Slack → HITL approval notifications
Instagram → marketing automation with compliance checks
Podstawową zasadą jest to, że agenci powinni przesyłać wyniki do rzeczywistych systemów biznesowych, a nie tylko tworzyć treści, przy czym mechanizmy zatwierdzania chronią wszystko, co wrażliwe.
WebSockets i transmisja strumieniowa
WS /ws/agent-updates
WS /ws/agent-events
GET /api/stream/logs
Co przenosi każdy strumień:
/ws/agent-updates → periodically sends agent status updates
/ws/agent-events → streams queue/Redis events to frontend
/api/stream/logs → streams recent logs via server-sent response
Dla interfejsu wieloagentowego ta widoczność jest niezbędna. Operatorzy muszą widzieć, który agent jest w działaniu, jaka zadanie jest aktywne, czy czeka na zatwierdzenie oraz gdzie doszło do awarii w przepływie pracy.
Frontend React
Klient jest zbudowany na następującej bazie:
React 18
Vite
React Router
Tailwind CSS
React Flow
Recharts
Zgodnie z README, panel sterowania łączy w sobie przepływ onboardingu oparty na czacie, aktualny stan agentów, wizualną mapę przepływu zadań oraz widoki służące do sprawdzania zgodności z PRD. Jego zadania to:
1. Capture the user’s project vision
2. Display agent execution status
3. Visualize task flow
4. Show pending approval requests
5. Display reports and analytics
6. Show memory/monitoring data
7. Connect to WebSocket streams
8. Communicate with FastAPI through api.js
Oryginalna struktura jest kompaktowa:
frontend/
└── src/
├── App.jsx
├── pages/
├── components/
└── services/api.js
App.jsx pełni rolę zalogowanej szkieletowej struktury, pages/ zawiera widoki związane z przepływem pracy, analizą i monitorowaniem, natomiast components/ dostarcza elementy budulcowe: panele do panelu sterowania, ekrany zatwierdzania, widoki sprawdzające zgodność z PRD oraz ustawienia integracji. Każda prośba HTTP przechodzi przez services/api.js, który w jednym miejscu zarządza ponawianiami prób i cache’owaniem, chroniąc tym samym komponenty przed problemami sieciowymi.
Całkowity przepływ
W skrócie główna ścieżka w systemie wygląda następująco:
1. User submits business vision from React UI
2. Frontend sends request to FastAPI
3. FastAPI creates project/session
4. Cofounder Agent structures vision
5. Manager Agent converts vision into roadmap and assignments
6. Specialist agents execute assigned tasks
7. Results are stored in memory
8. HITL approval is requested where required
9. Reports are generated
10. Frontend displays logs, status, graph, reports, and outputs
Gdy przypisze się to do konkretnych modułów i metod, ten sam przepływ wygląda w ten sposób:
React UI
↓ HTTP/WebSocket
FastAPI main.py
↓
AgentOrchestrator / EnhancedOrchestrator
↓
CofounderAgent.execute()
↓
ManagerAgent.execute()
↓
_execute_specialists()
↓
FinanceAgent / MarketingAgent / LegalAgent / MoneyAgent / SalesAgent
↓
MemoryManager + GraphMemory + VectorMemory
↓
ReportGenerator
↓
Dashboard + PDF/HTML/JSON Output
Każda warstwa ma jedno zadanie: interfejs użytkownika zajmuje się interakcją, orkiestratorzy koordynują działania, agenci je wykonywają, menedżerowie pamięci przechowują kontekst, a generator raportów kształtuje wynik końcowy.
Dlaczego orkiestrator grafu zamiast łańcucha
Prace z udziałem wielu agentów wymagają czegoś więcej niż serii wywołań funkcji. Potrzebują:
- State transitions
- Conditional routing
- Checkpointing
- Retry behavior
- Human approval interruptions
- Recovery after failure
- Resume from previous state
W dokumencie README maszyny stanowe LangGraph określone są jako warstwa orkiestracji właśnie ze względu na te możliwości. Zwykły łańcuch poleceń jest liniowy:
A → B → C → Done
Praca biznesowa rozgałęzia się w zależności od pośrednich wyników:
A → B
├── if finance confidence low → retry Finance
├── if legal risk high → ask human approval
├── if marketing ready → generate campaign
└── if all complete → generate report
Niska pewność finansowa powoduje ponowną próbę, wysokie ryzyko prawne wymagają przeglądu przez człowieka, a ostateczny raport czeka, aż wszystkie gałęzie zostaną zakończone. Przekształcenie tego w sztywno skonfigurowane sekwencyjne wywołania szybko prowadzi do plątaniny warunków; graf z wyraźnymi węzłami, krawędziami i punktami kontrolnymi utrzymuje porządek i umożliwia kontynuację pracy.
Co w tym projekcie jest dobrze zaprojektowane
- Jasne granice agentów: każdy agent odpowiada za jeden obszar biznesowy, co zapewnia spójność wyników i ułatwia dodawanie nowych ról.
- Orkiestracja oparta na procesach pracy: wykonywanie zadań jest modelowane jako proces pracy, a nie jako seria odpowiedzi na prośby.
- Specjaliści działający równolegle: działy finansów, marketingu, prawa, zarządzania pieniędzmi i sprzedaży pracują jednocześnie tam, gdzie to możliwe ze względu na zależności, co skraca czas realizacji zadań.
- Wspólna pamięć: Neo4j, Qdrant, Redis oraz lokalne magazyny danych razem obsługują relacje między elementami, funkcje odzyskiwania informacji semantycznych, kolejki zadań, cache oraz mechanizmy awaryjne.
- Bезpieczeństwo dzięki udziałowi człowieka: mechanizmy zatwierdzania sprawiają, że system nadaje się do podejmowania decyzji o rzeczywistych konsekwencjach.
- Obserwowalność w czasie rzeczywistym: WebSockets, logi, wykresy czasowe, panele kontrolne oraz narzędzia analityczne umożliwiają śledzenie działań agentów.
Zabezpieczanie systemu przed użyciem w produkcji
Fundamenty są solidne: modułowy backend, dedykowani agenci, abstrakcja pamięci, proces zatwierdzania oraz frontend poddawany obserwacji. Oczywistymi kolejnymi krokami są działania związane z niezawodnością, bezpieczeństwem, monitorowaniem, oceną oraz kontrolą kosztów:
1. Add distributed tracing with OpenTelemetry
2. Add LangSmith or custom LLM evaluation dashboards
3. Add cost tracking per agent and per workflow
4. Add stronger RBAC for users, agents, and approvals
5. Add persistent workflow checkpoints in Postgres or Redis
6. Add retry policies per agent type
7. Add queue-based background execution with Celery/RQ/Arq
8. Add structured output validation with Pydantic schemas
9. Add agent-level unit tests and golden-output evaluation
10. Add Docker production profiles and deployment manifests
Dwa z tych punktów wymagają szczególnej uwagi. Śledzenie kosztów dla każdego agenta oraz dla poszczególnych procesów jest istotne, ponieważ specjaliści pracujący równolegle zwiększają liczbę wywołań modeli LLM, a koszty pozostają niewidoczne dopóki nie zostaną zmierzone. Walidacja struktury wyjściowej za pomocą schematów Pydantic jest kluczowa, gdyż każdy kolejny krok – od zapisu danych do raportów i aktualizacji w CRM – jest tak niezawodny, jak kształt danych zwracanych przez agenta.
Główne wnioski
- Traktuj warstwę orkiestracji jako produkt; model LLM jest jedynie jednym z jej komponentów.
- Wyznacz agenta o charakterze menedżera do zarządzania procesem dekompozycji, aby wyniki pracy specjalistów były spójne.
- Zapewnij równoczesną pracę niezależnych agentów z ustalonymi czasami timeout dla każdego z nich oraz wyraźnie radź sobie z częściowymi awariami.
- Pozycjonuj każdy magazyn pamięci do jednego zadania: grafy do śledzenia pochodzenia danych, wektory do ich odzyskiwania oraz kolejki do koordynacji działań.