llms.txt v2: co się zmieniło
Opublikowano:
Propozycja llms.txt została zmieniona w sierpniu 2026, prawie dwa lata po wersji pierwotnej. Sam format pliku się nie zmienił — plik zgodny z v1 nadal jest poprawnym plikiem v2. Zmieniło się wszystko wokół pliku: to, jak agenci go znajdują, i jakich narzędzi oczekuje specyfikacja.
Format pozostaje bez zmian
Wymagana struktura jest dokładnie taka jak wcześniej: opcjonalny BOM, nagłówek H1 z nazwą projektu (nadal jedyny obowiązkowy element), podsumowanie w cytacie blokowym, opcjonalny tekst bez nagłówków, a potem zero lub więcej sekcji H2 z listami odnośników w Markdown. Jeśli twój plik dostawał 100 punktów według v1, dostaje je nadal.
1. Relacje odnośników, żeby agenci przestali zgadywać
To istotne uzupełnienie i odpowiedź na najczęstszą prośbę z dwóch lat wdrożeń: mając daną stronę, jak agent ma znaleźć jej wersję Markdown albo plik llms.txt, który ją obejmuje, nie zgadując adresów?
v2 odpowiada dwiema standardowymi relacjami odnośników:
rel="describedby"— wskazuje plik llms.txt obejmujący tę stronę.rel="alternate" type="text/markdown"— wskazuje wersję Markdown tej strony.
Każda z nich może być elementem HTML <link>:
<link rel="describedby" href="/llms.txt"> <link rel="alternate" type="text/markdown" href="/docs/page.html.md">
…albo nagłówkiem odpowiedzi HTTP, co jest jedyną opcją dla zasobów innych niż HTML — na przykład dla samych plików Markdown — i co można ustawić w konfiguracji serwera lub CDN bez zmiany choćby jednej strony:
Link: </docs/page.html.md>; rel="alternate"; type="text/markdown", </docs/llms.txt>; rel="describedby"
Jeśli wcześniej stosowałeś radę, by zgłaszać plik przez rel="alternate" type="text/plain" — także z wcześniejszych wersji naszych własnych poradników — zamień to na rel="describedby". Była to rozsądna konwencja, dopóki specyfikacja nie miała własnej; teraz ma.
2. Obie formy adresów .md są już dozwolone
v1 określała jedną formę adresu dla markdownowego bliźniaka strony: .md dopisane do pełnego adresu, więc page.html stawało się page.html.md. W praktyce część narzędzi publikacyjnych zamieniała rozszerzenie, dając page.md. v2 dopuszcza obie. Dla adresów bez nazwy pliku dopisz index.html.md lub index.md.
Nie ma tu nic do migracji — forma, którą już generujesz, jest teraz poprawna.
3. Pliki w podścieżkach są wreszcie zdefiniowane
v1 zezwalała na llms.txt poza katalogiem głównym, ale nigdy nie mówiła, co to znaczy. v2 to definiuje: plik obejmuje strony pod swoją ścieżką, a gdy zastosowanie ma więcej niż jeden, agenci używają najbardziej szczegółowego. Czyli /docs/llms.txt obejmuje wszystko pod /docs/, a agent czytający stronę dokumentacji przedkłada go nad plik z katalogu głównego.
Ma to znaczenie dla każdego, kto kontroluje ścieżkę, ale nie host — witryna projektu na GitHub Pages, sekcja dokumentacji na wspólnej domenie — i właśnie dlatego specyfikacja pozostaje przy zwyczajowej nazwie pliku, a nie /.well-known/, które istnieje wyłącznie w katalogu głównym origin.
Praktyczny wniosek: jeśli to dokumentacja jest tym, co interesuje agentów, dedykowany /docs/llms.txt jest teraz pełnoprawnym wyborem, a nie szarą strefą.
4. Narzędzia rozwijania kontekstu wypadły (a „Optional” straciła mechanikę)
v1 opisywała llms_txt2ctx — narzędzie rozwijające llms.txt w jeden kontekst dla modelu. v2 z niego rezygnuje i zamiast tego wprost formułuje oczekiwanie: agenci przeglądają lub przeszukują llms.txt, a potem podążają za potrzebnymi im odnośnikami — a więc odnośniki powinny prowadzić do treści przyjaznych modelom, a sam plik pozostaje dość mały, by zmieścić się w kontekście.
Wraz z tym narzędziem znika mechaniczne znaczenie sekcji ## Optional, która istniała po to, by mówić takim narzędziom, co pominąć. Sekcje Optional są nadal dozwolone i nadal są przydatną konwencją dla drugorzędnych odnośników, które agent może pominąć — tylko nie uruchamiają już niczego automatycznie.
Zauważ, że llms-full.txt nigdy nie był częścią specyfikacji, w żadnej z wersji. To szeroko przyjęta praktyka branżowa i dobry pomysł przy dużych zbiorach dokumentacji — tylko nie traktuj go jako wymogu.
Co zrobić w tym tygodniu
- Dodaj
rel="describedby"wskazujące twój llms.txt — jedna linia w szablonie albo jedna reguła nagłówka w CDN. - Jeśli publikujesz markdownowe bliźniaki, zgłoś je przez
rel="alternate" type="text/markdown". - Zamień każdą wskazówkę
rel="alternate" type="text/plain"narel="describedby". - Jeśli dokumentacja to najcenniejsza część, rozważ dedykowany
/docs/llms.txt. - Uruchom ponownie walidator — teraz raportuje, czy twoje strony zgłaszają relacje z v2, i podąża za plikami w podścieżkach tak, jak v2 przewiduje dla agentów.
Dlaczego w ogóle doszło do zmiany
Bo założenie przestało być spekulacją. Gdy llms.txt proponowano we wrześniu 2024, „agenci będą czytać twoją stronę” było przewidywaniem. Dziś platformy dokumentacyjne generują ten plik automatycznie, Lighthouse w Chrome sprawdza jego obecność w ramach kontroli agentic browsing, a laboratoria AI publikują llms.txt dla własnej dokumentacji dla programistów. v2 to obraz propozycji po tym, jak jej założenia sprawdziło prawdziwe wdrożenie.