Przejdź do głównej zawartości
Control Center
Dodaj gwiazdkę do repozytorium5Pobierz
Menu

Model agentów

Czym jest agent?

Dział zatytułowany „Czym jest agent?”

Agent to nazwany aktor z personą, zestawem skillów i adapterem, na którym działa. Agenci są podmiotami w tym samym sensie co ludzie: są autorami wiadomości, posiadają zgłoszenia, zostawiają recenzje i pojawiają się na tej samej liście. To oni wykonują pracę.

Każdy agent należy do dokładnie jednego obszaru roboczego. To twardy niezmiennik — agent.workspaceId nigdy nie jest puste, to właśnie obszar roboczy agenta wybiera plik bazy danych, do którego trafiają jego wiersze, a utworzenie agenta bez obszaru roboczego jest odrzucane.

Agent to także katalog. Jego definicja znajduje się w agents/<slug>/AGENTS.md w katalogu danych obszaru roboczego, a posiadane skille są dowiązane symbolicznie w agents/<slug>/.agents/skills. Wiersz w bazie i plik są zapisywane razem. Zasiewanie jest idempotentne: jeśli wiersz agenta już istnieje, pliki na dysku i dowiązania skillów i tak zostają przepisane. Wywołującym w środowisku produkcyjnym jest tworzenie obszaru roboczego, a nie każde uruchomienie serwera.

Co zawiera agent

Dział zatytułowany „Co zawiera agent”
Atrybut Co robi
name Krótki identyfikator w stylu sluga (architect, qa). To także to, względem czego rozwiązywane są @mentions
title Czytelny dla człowieka tytuł stanowiska
persona Swobodny tekst opisujący osobowość i instrukcje behawioralne, wstrzykiwany jako sekcja promptu
systemPrompt Opcjonalne dodatkowe instrukcje, wstrzykiwane jako sekcja „Agent instructions” — nie zastępują reszty składanego promptu
skills Zestaw nazw skillów bez rozróżniania wielkości liter, odwzorowywany jako dowiązania skillów na dysku
adapterId Do jakiego runnera agent wysyła zadania. Wartość null powoduje powrót do wbudowanej pętli
modelId Który model w obrębie tego adaptera
effort Poziom rozumowania, czerpany ze słownictwa samego wybranego modelu
contextSize Nadpisanie rozmiaru okna kontekstu
silenceTimeoutMinutes Nadpisanie na poziomie agenta (1–240) dla watchdoga ciszy
reportsTo Identyfikator agenta nadrzędnego — łańcuch podległości, który rysuje schemat organizacyjny

Wszystkie te pola edytujesz w Ustawienia → Obszar roboczy → Agenci. Nowy agent tworzy agenta bez nazwy, którego następnie uzupełniasz.

Skille

Dział zatytułowany „Skille”

Skille to nazwy na encji agenta, w których wielkość liter nie ma znaczenia. Dzieją się z nimi dwie osobne rzeczy:

  • Nazwy są wymieniane w składanym promptcie pod nagłówkiem „Skills”. To wszystko, co sam zestaw na encji robi — nie istnieje żadna biblioteka promptów dla poszczególnych skillów, która by się na nim opierała.
  • Katalog każdego nazwanego skilla (skills/<slug>/SKILL.md w obszarze roboczym) jest dowiązywany do folderu samego agenta. W wbudowanym harnessie frontmatter dowiązanych skillów jest automatycznie wczytywany do promptu systemowego, a agent czyta treść na żądanie; wpisanie /skill:<name> w rozmowie wczytuje tę treść jako dyrektywę na czas danej tury.

Skille pobierane z zewnątrz przechodzą między pobraniem a zapisem skan łańcucha dostaw działający w trybie fail-closed — żadna treść skilla nie trafia na dysk ani do promptu bez werdyktu. Tym zewnętrzem są repozytoria GitHub, które sam rejestrujesz jako źródła skillów: nie ma żadnego kuratorowanego sklepu, więc metadane samego repozytorium (jego opis, gwiazdki, nazwa skilla) to niezaufane dane wyświetlane, a werdykt skanu jest jedynym sygnałem bezpieczeństwa. Instalacja pobiera cały katalog skilla, przypina go do commita, z którego pochodzi, w skills-lock.json, a późniejsza aktualizacja ponownie przechodzi przez tę bramę, zanim cokolwiek zastąpi. Jak to zrobić, opisano w sekcji instalacja i zarządzanie skillami.

Skille ograniczone do repozytorium

Dział zatytułowany „Skille ograniczone do repozytorium”

Repozytorium może dostarczać własne skille w każdym z konwencjonalnych miejsc (.agents/skills/, .claude/skills/, .opencode/skills/). Przestrzeń pobiera każde podłączone repozytorium obok siebie w repos/<name>/, ale agent pracuje naraz tylko w jednym repozytorium — niesie więc tylko skille tego repozytorium, a gdy się przenosi, zostają one podmienione.

To, które repozytorium jest aktywne, wynika z plików, których agent dotyka: zapis pliku w repos/<name>/ czyni je aktywnym repozytorium, samo czytanie w różnych repozytoriach już nie, więc podążanie za symbolem do sąsiedniej usługi nigdy nie podmienia zestawu w trakcie zadania. W przestrzeni z jednym repozytorium odpowiedź jest znana jeszcze przed pierwszą turą.

Takie ograniczanie zakresu to decyzja o budżecie kontekstu. Indeks skillów siedzi w promptcie przy każdej turze, a treści już nie, więc wypisanie naraz skillów wszystkich repozytoriów kosztuje tokeny bez przerwy — a skill testing z jednej usługi aktywnie wprowadza w błąd, gdy praca toczy się w innej. Z tego samego powodu indeks agenta obejmuje jedno repozytorium, ale pola wiadomości nie ogranicza się w ten sposób: samodzielne wskazanie skilla to jeden jawny akt, więc /skill:<repo>:<name> sięga do dowolnego repozytorium w przestrzeni.

Skille repozytorium są wczytywane dla każdego adaptera, nie tylko dla wbudowanego harnessu. Skille aktywnego repozytorium są materializowane w katalogu roboczym agenta, który to katalog Claude Code i tak skanuje; ten sam indeks jest składany do AGENTS.md, który czyta wbudowany harness. Zanim do czegokolwiek z tego dojdzie, skille repozytorium przechodzą ten sam skan fail-closed co zainstalowany skill — wyewidencjonowane repozytorium to sklonowana treść, a jego frontmatter trafia do promptu.

Uprawnienia

Dział zatytułowany „Uprawnienia”

Agent nie ma własnych flag uprawnień. O tym, czy może utworzyć commit, wykonać push, otworzyć pull request, zapisywać do trackera albo sięgać do sieci, decydują guardraile akcji — zezwól, zapytaj najpierw lub odmów, w zakresie obszaru roboczego, agenta lub przestrzeni — i te same reguły obowiązują niezależnie od tego, który adapter go uruchamia.

To, co uruchomienie otrzymuje, nie zmienia się wraz z tymi regułami. Uruchomienie w worktree GitHuba zawsze dostaje token GitHub tylko do odczytu, a o push pyta się w chwili, gdy następuje: konfiguracja gita agenta kieruje każdy push do GitHuba przez Control Center, który przed przekazaniem go dalej stosuje regułę Push do zdalnego repozytorium.

Jak to działa, w tym co jest egzekwowane na poziomie systemu plików, a co nie, znajdziesz w sekcji Sandbox i bezpieczeństwo.

O tym, co da się wyegzekwować, decyduje adapter

Dział zatytułowany „O tym, co da się wyegzekwować, decyduje adapter”

Polem o największych konsekwencjach na agencie jest jego adapter, ponieważ transport adaptera określa, jak dużą część polityki Control Center da się faktycznie wyegzekwować.

Transport Adaptery Co egzekwuje Control Center
Wbudowany harness Control Center (built-in) Wszystko. Powierzchnia narzędzi jest budowana z trybu, więc niedozwolone narzędzie jest niewidoczne, a nie tylko odrzucane; każde wywołanie przechodzi przez bramę zatwierdzeń i guardraile działań; kontrakt ukończenia potrafi ponaglić, a następnie uznać za nieudane uruchomienie, które kończy się bez swojego rezultatu
Claude CLI Claude Code Narzędzia mcp__*, które są mu udostępniane, oraz jego polecenia Bash, które hook przed wykonaniem wysyła do polityki akcji. Własne narzędzia Claude’a do czytania, zapisu i edycji działają w jego procesie i pozostają niewidoczne — a uruchamia się go z --dangerously-skip-permissions, bo nieinteraktywne claude -p inaczej zawieszałoby się na zawsze na własnym pytaniu

Konkretnie: tylko wbudowany harness obsługuje subagentów, sterowanie w trakcie uruchomienia, pauzę i wznowienie (a więc i przejęcie) oraz strukturalne egzekwowanie trybu. Claude Code nie ma żadnego z nich.

Agent, który nie ma adaptera, wraca do Control Center (built-in) — pętli wewnątrz serwera, więc nie ma żadnego CLI do zainstalowania — a jego log uruchomienia zapisuje cc-harness. Każdy zasiany agent jest tworzony bez adaptera i modelu, więc pięć agentów świeżego obszaru roboczego działa tam, na domyślnym modelu Anthropic, dopóki nie ustawisz adaptera i modelu dla każdego agenta. Wybór „domyślnego adaptera” w onboardingu to preferencja po stronie klienta, której serwer nigdy nie czyta i której nie stosuje wstecz do już utworzonych agentów.

Skąd biorą się agenci

Dział zatytułowany „Skąd biorą się agenci”
  • Zasiewani razem z obszarem roboczym. Każdy obszar roboczy — nie tylko pierwszy — dostaje CEO oraz czterech specjalistów (qa, architect, engineer, librarian) podlegających jemu, tworzonych idempotentnie w tle w momencie utworzenia obszaru roboczego. Zobacz Obszary robocze i izolacja.
  • Dodawani ręcznie w Ustawienia → Obszar roboczy → Agenci. Poproszenie agenta, by zatrudnił kolegę, nie tworzy wiersza; użyj tego ekranu.

Stan bieżący

Dział zatytułowany „Stan bieżący”

Agent nie ma zapisanej kolumny ze statusem. Jego stan bieżący jest wyliczany z najnowszych logów uruchomień przy każdym odczycie:

Stan Znaczenie
neverRun Nie istnieje żaden log uruchomienia
running Co najmniej jedno uruchomienie trwa
failed Najnowsze uruchomienie zakończyło się błędem albo jego żywotność to failed lub dead
blocked Żywotność najnowszego uruchomienia to blocked, stalled lub looping
idle Wszystko inne — agent działał już wcześniej i nie ma nic w toku

Dwa kolejne stany, queued i succeeded, istnieją dla pojedynczych uruchomień w drzewie uruchomień rozmowy; lista nigdy ich nie produkuje, bo to, że zakończone uruchomienie jest zielone, jest faktem o uruchomieniu, a nie o agencie.

Lista obecności pokazuje równoległy, zgrubniejszy obraz syntezowany po stronie serwera z bieżących zdarzeń uruchomień — myśli, działa, czeka na zatwierdzenie, gotowe — i to dzięki niemu agenci pojawiają się obok ludzi. Zobacz Wieloosobowość.

Powiązane koncepcje

Dział zatytułowany „Powiązane koncepcje”

Preferencje dokumentacji

Wygląd
Język
Polski (Polska)