Back to blog

Zbudowaliśmy system wieloagentowy. Oto dlaczego przechodzimy na jednego Okou.

Zbudowaliśmy system wieloagentowy. Oto dlaczego przechodzimy na jednego Okou.

Wiele osób, myśląc o współpracownikach AI, intuicyjnie zakłada, że powinni działać jak zespół, z jednym agentem na każdą rolę. Jeden od inżynierii, jeden od marketingu, jeden, który pisze wyłącznie posty na bloga.

My też tak to zbudowaliśmy. Okou pozwalał tworzyć w workspace wielu agentów, każdego z własną nazwą, awatarem, Instrukcjami i Workflowami. W sierpniu opublikowaliśmy nawet wpis o tym, jak kilku agentów dzieli się pracą i przekazuje ją sobie nawzajem. W naszym własnym workspace było ich sporo. Lucas pisał nasze posty na bloga, Lisa prowadziła księgowość, Iris zajmowała się relacjami z inwestorami, a Emily, mój własny agent, segregowała moją pocztę.

Ale intuicja użytkowników to tylko punkt odniesienia. Zanim pojawił się Notion, ludzie intuicyjnie zakładali, że narzędzie do dokumentów potrzebuje nagłówków i stopek.

Wieloagentowość nie jest też podstawową funkcją. Podstawowe funkcje to te, których prędzej czy później będzie potrzebował każdy produkt AI: czat, tworzenie prezentacji i stron internetowych, obsługa komputera. Wielu agentów nie ma na tej liście.

Weźmy Lucasa, naszego byłego agenta od bloga. Mniej więcej jedna trzecia jego Instrukcji to ten sam ogólny szablon, którego używa domyślny Okou. Reszta to trzy konkretne procedury: jak opublikować post na blogu w Strapi, jak pisać strony z przypadkami użycia na naszą witrynę i jak przygotować codzienny raport konwersji rejestracji. Wszystkie 13 Workflowów przypisanych do Lucasa jest publicznych w workspace. Żaden z nich nie należy wyłącznie do Lucasa.

Czyli różnica między Lucasem a domyślnym Okou sprowadza się do nazwy, awatara i trzech procedur, które powinny były być Workflowami. Te procedury są zamknięte w Lucasie. Poproś domyślnego Okou o opublikowanie posta na blogu, a nie będzie miał dostępu do żadnej z tych zasad.

Wraz ze wzrostem liczby agentów rosła też liczba kombinacji. Wielu agentów, wiele Workflowów i wiele rozmów wchodzi ze sobą w interakcje, a każda kombinacja to logika, którą my musimy utrzymywać, a użytkownicy muszą się jej nauczyć. Natrafialiśmy na pytania, na które z punktu widzenia użytkownika nie umieliśmy dobrze odpowiedzieć:

  • Dlaczego dwóch agentów nie może korzystać z tego samego Workflowu?
  • Dlaczego z Okou mogę rozmawiać w Slacku, ale z moim prywatnym agentem już nie? Jeśli Lucas jest osobą, powinien być osiągalny wszędzie.
  • Dlaczego pamięć jest wspólna dla wszystkich agentów? Jeśli każdy agent jest osobą, każdy powinien mieć własną pamięć.

Każdy z tych problemów da się rozwiązać, ale każdy wymaga solidnej pracy inżynierskiej. Jeśli zostawi się je nierozwiązane, wieloagentowość pozostaje doświadczeniem niedokończonym. Trudno nam też było znaleźć problem, który mogłoby rozwiązać tylko wielu agentów. Częściej słyszeliśmy skargę, że agentów jest za dużo, by nad nimi zapanować.

Dlatego zdecydowaliśmy, że każda osoba ma jednego Okou. Model jest prostszy:

  • Każda osoba ma jednego domyślnego Okou.
  • Twój Okou należy do ciebie i jest prywatny.
  • Twój Okou i Okou współpracownika to nie ten sam agent.
  • Twój Okou może korzystać z każdego Workflowu, który ktoś w twojej organizacji oznaczył jako Public.

To, co wcześniej było przypięte do agenta, trafiło tam, gdzie lepiej pasuje:

  • Instrukcje należą do ciebie. Piszesz jeden zestaw, a Okou stosuje go w wersji webowej, w Slacku i w automatyzacjach.
  • Workflowy należą do workspace. Każdy może korzystać z Workflowu Public opublikowanego przez współpracownika, a ty możesz go skopiować i dostosować do siebie.
  • Połączone konta należą do ciebie, więc nie musisz już wybierać, który agent dostaje dostęp.
  • Rozmowy są grupowane w Projektach, według klienta, projektu lub tematu.

W tym modelu agent to niewiele więcej niż zestaw Instrukcji. Trzy procedury zamknięte w Lucasie powinny stać się Workflowami, z których każdy może korzystać.

Wieloagentowość to tak naprawdę praktyka zarządcza w organizacji, sposób zarządzania tym, co może robić AI. Każda organizacja ma własne metody zarządzania i nie ma jednego zestawu, który pasowałby wszystkim. Pojedynczy agent jest bliższy narzędziu, a narzędzia łatwiej zrozumieć i wdrożyć. Użytkownicy najbardziej potrzebują tego, żeby zadanie zostało wykonane. Potem narzędzia, które to umożliwi. Najmniej potrzebują metody, jak to zrobić.

Zespół Applied AI w Anthropic zauważył coś podobnego w niedawnym artykule o wdrożeniach agentów w firmach. W porównaniach kilku wdrożeń pojedynczy agent ze Skills często przewyższał jakością architekturę podzieloną na wyspecjalizowane subagenty, i to nierzadko przy niższym koszcie i opóźnieniu na zadanie. Piszą też, że „zbyt często widzimy, jak firmy dają każdemu zespołowi lub typowi problemu osobnego subagenta, a architektura agentów staje się kopią ich schematu organizacyjnego”. Ich artykuł dotyczy architektury agentów, a nie projektowania produktu, ale to rozumowanie da się przenieść.

Patrząc na dzisiejsze produkty AI, widzimy cztery modele:

  1. Wielu agentów, wiele rozmów. Tak działał Okou.
  2. Jeden agent, wiele rozmów. Tak działają ChatGPT, Codex i Claude Cowork.
  3. Jeden agent, jedna rozmowa. Tak działa Instinct.
  4. Wielu agentów, każdy z jedną rozmową. Tak działa Grok bot.

Mieliśmy najbardziej złożoną kombinację, a nie rozwiązywała ona więcej problemów.

Wiemy, że to zmiana, która łamie dotychczasowy sposób działania. Dwie rzeczy powstrzymywały nas przed nią wcześniej: musieliśmy poprosić cię o naukę nowego sposobu pracy, z jednym Okou i Workflowami, a do tego brakowało jasnej ścieżki dla tego, co masz już zbudowane. Oto ta ścieżka:

  • Twoje rozmowy wciąż tam są. Znajdziesz je w Projektach, przez wyszukiwarkę i pod ich oryginalnymi linkami.
  • Jeśli różni agenci służyli ci do porządkowania rozmów, korzystaj teraz z Projektów. Grupowanie rozmów według kategorii było głównym powodem, dla którego wiele osób tworzyło dodatkowych agentów. Claude i ChatGPT odpowiadają na tę samą potrzebę za pomocą Projektów.
  • Jeśli różni agenci mieli u ciebie różne Instrukcje, to, co wspólne, przenieś do swoich osobistych Instrukcji, a konkretne procedury zamień w Workflowy.

Im szybciej przestaniemy budować abstrakcje nad wieloma agentami, tym lepiej. Gdy otworzysz Okou, nie musisz już decydować, którego agenta zapytać. Powiedz Okou, co trzeba zrobić, a Okou zajmie się resztą.

Stay in the loop

// Get the latest insights on AI teammates and collaboration.