docs/context.pl.md
Rama main · réplica de lectura del repositorio original.
---
source_sha: "6ed5be54f7ae"
---
# Pliki kontekstowe { #context-files }
**Plik kontekstowy** to kawałek stałej wiedzy napisany raz i podpięty do wielu
agentów: słownik pojęć, opis tonu marki, macierz eskalacji, lista produktów,
które naprawdę sprzedajesz.
Jeśli pisałeś kiedyś `AGENTS.md` dla agenta kodującego, to jest ta sama idea w
tym samym kształcie — plik w Markdownie mówiący, jak się tu robi rzeczy, trzymany
obok pracy, a nie w środku jednego promptu. Różnica jest w tym, kto go czyta:
`AGENTS.md` w repozytorium czyta cokolwiek akurat je otworzy, a plik kontekstowy
tutaj jest podpięty do agentów, których wybierzesz, wersjonowany razem z nimi i
edytowalny przez osobę, która naprawdę zna odpowiedź.
To odpowiedź na problem, który każda firma napotyka przy swoim trzecim agencie —
te same trzy akapity wklejone do trzech zestawów instrukcji, a potem poprawione
w jednym z nich.
W kreatorze agenta **Context → New context file** tworzy plik bezpośrednio w panelu zdolności, dołącza go do bieżącego szkicu i włącza Context. Następnie możesz wybrać sposób użycia pliku przez tego agenta. Publikacja pozostaje osobnym krokiem. Tworzenie wymaga uprawnień do edycji agenta i plików contextu.
## Gdzie leży, między skillami a wiedzą { #where-it-sits-between-skills-and-knowledge }
Trzy rzeczy podają modelowi tekst, a zły wybór między nimi to zwykła przyczyna
agenta, który albo ignoruje to, co mu powiedziano, albo nie czyta niczego.
| | Co trzyma | Kiedy model to widzi |
| ----------------------------------------- | ------------------------------------------------------------------------------------- | -------------------------------------------------- |
| **Plik kontekstowy** | Stałe fakty, krótkie i niezmienne — słownik, przewodnik po tonie, schemat organizacji | Zawsze albo na żądanie — Ty wybierasz |
| **[Skill](skills.md)** | Procedurę dla jednego rodzaju zadania — jak obsłużyć wniosek o zwrot | Kiedy model uzna, że dzieje się właśnie to zadanie |
| **[Kolekcja wiedzy](file-processing.md)** | Korpus zbyt duży, by go przeczytać — każdy dokument polityki, każde zgłoszenie | Tylko te fragmenty, które zwróci wyszukiwanie |
Zasada praktyczna: **jeśli coś jest krótkie i zawsze istotne, to plik
kontekstowy. Jeśli jest długie, to wiedza. Jeśli to procedura, to skill.**
Strona **Context** pokazuje na karcie początek każdego pliku. `GET
/api/v1/context` zwraca go jako `excerpt`: kilka ograniczonych linii, nigdy całą
treść.
## Dwa tryby, a różnica między nimi to koszt { #two-modes-and-the-difference-is-cost }
Każde przypięcie pliku ma tryb w ustawieniach capability **Context** agenta. Ten sam wspólny plik można wstrzykiwać u jednego agenta, udostępniać na żądanie u drugiego lub wyłączyć u trzeciego.
=== "`inject` — zawsze obecny"
Treść jest wklejana do instrukcji agenta dosłownie. Model zna ją zawsze,
bez decydowania, czy zajrzeć, i bez wywołania narzędzia.
Używaj go do rzeczy, których agent nigdy nie może pomylić: jak nazywają się
Twoje produkty, do kogo eskalować, jak mówić o firmie.
**Jest czytany w każdej turze**, więc jest częścią kosztu każdej wiadomości.
Wstrzykiwane pliki trzymaj krótkie.
=== "`link` — czytany na żądanie"
Treść zostaje poza promptem i jest wystawiona przez narzędzie. Model czyta
ją tylko wtedy, gdy uzna plik za istotny, wybierając po nazwie i po
jednozdaniowym opisie, który piszesz.
Używaj go do materiałów, które liczą się czasami: rzadko potrzebnej
polityki, regionalnego wariantu, długiej listy.
Nie kosztuje nic w turach, które go nie potrzebują, i nie kosztuje nic w
ogóle, jeśli model nigdy nie zajrzy — co jest jednocześnie ryzykiem.
!!! tip "Opis pisz dla modelu, nie dla człowieka"
Linkowany plik jest wybierany wyłącznie po nazwie i opisie. „Polityka
zwrotów” mówi modelowi mniej niż „kiedy klient może zwrócić towar, jakie są
terminy i trzy wyjątki” — a ta różnica decyduje o tym, czy plik zostanie
kiedykolwiek otwarty.
## Podpinanie ich do agenta { #attaching-them-to-an-agent }
Pliki kontekstowe należą do organizacji, nie do agenta. Piszesz jeden, a wiąże
się z nim dowolna liczba agentów.
Włącz na agencie capability **Context**, a potem podepnij pliki, które ma mieć.
Edycja pliku później zmienia to, co wie każdy związany z nim agent **przy jego
następnym runie** — bez ponownej publikacji, żadnego z nich.
O to właśnie chodzi i na to właśnie trzeba uważać: zmiana w pliku wstrzykiwanym
jest zmianą w każdym agencie, który go niesie. Traktuj go jak wspólny, nośny
tekst, którym jest.
W Builderze każdy wybrany plik ma przełącznik **Używaj w tym agencie** i wybór trybu. Te ustawienia należą do szkicu agenta i zaczynają działać po publikacji. Edytor biblioteki zmienia tylko wspólną treść i opis; format wynika z nazwy pliku. Istniejące wersje agentów bez indywidualnych ustawień zachowują poprzedni tryb i dostępność.
Capability pozwala też wyłączyć narzędzie do odczytu. Wyłączenie narzędzia do
czytania oznacza, że do modelu trafiają tylko pliki wstrzykiwane i nic nie jest
czytane na żądanie — rozsądny wybór, gdy chcesz, żeby wejścia agenta były
całkowicie przewidywalne.
Można też zacząć od pliku: **Dodaj do agenta** na jego karcie dodaje go do
szkicu agenta razem z włączoną capability Kontekst, a karta mówi, którzy agenci
już go mają. Baza wiedzy ma tę samą akcję na swojej stronie.
## Zmiany proponowane przez asystenta { #changes-the-assistant-proposes }
**Ulepsz z asystentem**, w edytorze pliku, prosi
[asystenta tworzenia](authoring.md#context-files) o lepszą treść, napisaną na
podstawie runów agentów, którzy czytają plik. To, co proponuje, nie jest
stosowane: czeka nad listą na stronie Context, z uzasadnieniem, runami, na
których się opiera, i agentami, do których plik jest podpięty.
Zastosowanie jej to to samo co ręczna edycja pliku - działa od razu dla każdego
agenta, którego opublikowana wersja czyta plik - więc najpierw jest
**Sprawdź evalami**, na jednym z tych agentów. Obok **Zastosuj** zmiana mówi, co
robi jej zastosowanie: dla jakich agentów i środowisk zacznie działać, które
suity evali ustawi w kolejce i którzy strażnicy sprawdzą ją dopiero przy
następnej promocji agenta. Plik, który ktoś edytował po zaproponowaniu zmiany,
odrzuca ją; ta edycja nigdy nie zostaje nadpisana.
Ponowna prośba do asystenta przepisuje czekającą zmianę, zamiast dodawać drugą.
Decyzja wskazuje wersję zmiany, którą przeczytałeś, więc z dwóch podjętych
naraz liczy się tylko jedna, a strona otwarta przed przepisaniem jest odrzucana
z komunikatem „The proposal changed since you opened it”, dopóki nie przejrzysz
nowej wersji. Zmiana, która mówi to, co plik już mówi, w ogóle nie jest
proponowana.
Każda edycja pliku - zastosowana albo zrobiona ręcznie - i jego usunięcie
ustawiają w kolejce suity evali uruchamiane po zmianie zależności, dla każdego
agenta, który go czyta, a zastosowanie zmiany powiadamia właścicieli tych
agentów.
## Dostęp { #access }
Plik kontekstowy ma właściciela i widoczność, jak każdy inny zasób tutaj, a
`context:view` bramkuje odczyt katalogu. Plik, do którego ktoś nie dostał grantu,
to plik, którego nie może podpiąć, i decydują o tym [te same trzy
warstwy](permissions.md) co wszędzie indziej.
Nic naprawdę tajnego nie trafia do takiego pliku — plik kontekstowy to tekst,
który agent czyta na głos, gdy zadać mu właściwe pytanie. Poświadczenia należą do
[vaultu](secrets.md).
## Podsumowanie { #recap }
- Plik kontekstowy to **stała wiedza napisana raz i związana z wieloma agentami**.
- **`inject`** jest zawsze w prompcie i kosztuje w każdej turze; **`link`** jest
czytany na żądanie i nie kosztuje nic, dopóki nie zostanie przeczytany.
- Linkowany plik jest wybierany po **opisie**, więc pisz go dla modelu.
- Edycja pliku aktualizuje **każdego związanego agenta przy jego następnym
runie**, bez publikowania czegokolwiek.
- Krótkie i zawsze istotne → kontekst. Długie → [wiedza](file-processing.md).
Procedura → [skill](skills.md).