Agent-first design: po co powstało Zero i co za to płaci

Pytanie, które zadaje Zero

Założenie Zero jest proste: gdy kod czyta, pisze i naprawia agent AI, a nie tylko człowiek, jak powinien wyglądać sam język?

Istniejące języki zaprojektowano na długo przed tym, zanim agenci zaczęli pisać kod. Ich priorytety (zwięzła składnia, ekspresyjne idiomy, pomysłowe biblioteki) mają sens dla ludzi piszących w edytorach. Tolerują niejednoznaczność i niejawne konwersje, bo ludzie dobrze uzupełniają luki. Agenci nie. Generują dokładny tekst z rozkładów prawdopodobieństwa i za każdą niejasną krawędź języka płacą złym tokenem gdzieś dalej.

Zero zaczyna od nowa z odwróconym ograniczeniem: projektuj najpierw dla agentów, pogódź się z tym, że ludzie wciąż będą czytać kod, i zobacz, co z tego wyniknie.

Zasada 1: mała, regularna powierzchnia

Większość języków programowania z czasem się rozrasta. Każde nowe wydanie dodaje drobną wygodę: nowy operator, nową formę składniową, nowy sposób wyrażenia czegoś, co język już obsługiwał. Każdy taki dodatek zwraca się w ergonomii dla ludzi. Każdy kosztuje agenta: kolejny wariant do nauczenia, kolejny sposób na pomyłkę.

Zero celowo utrzymuje malutką powierzchnię:

• Jedna forma wiązania (let).
• Jedna forma funkcji (fun, opcjonalnie pub).
• Jedna pętla na dziś (while).
• Jeden sposób modelowania typów produktowych (shape).
• Jeden sposób modelowania typów sumowych z danymi (choice).
• Jeden sposób modelowania sum z etykietami (enum).
• Jedna konstrukcja dopasowania wzorców (match).

Brak przeciążania operatorów, dekoratorów, makr, niejawnych konwersji, rzutowania na prawdziwość i operatora trójargumentowego. Każdy brak jest zaletą: usuwa miejsce, w którym agent mógłby wybrać zły wariant.

Koszt jest oczywisty: mniej udogodnień. Korzyść jest taka, że agent uczący się Zero w trakcie sesji może trafić we właściwą składnię bez rozważania siedmiu niemal równoważnych opcji.

Zasada 2: jawne efekty

Większość języków pozwala dowolnej funkcji w dowolnym miejscu wykonywać I/O. console.log w JavaScripcie, printf w C, print w Pythonie. Sygnatura funkcji nie daje żadnej wskazówki, czy może ona zapisać plik albo połączyć się z siecią. Jedynym sposobem, żeby to wiedzieć, jest przeczytanie ciała, rekurencyjnie.

Zero zajmuje przeciwne stanowisko: każdy efekt funkcji jest widoczny w jej sygnaturze.

• I/O jest strzeżone przez capability World. Funkcja, która nie przyjmuje World, nie może wykonywać I/O. Wymusza to system typów.
• Błędy są strzeżone przez raises i check. Funkcja, która może się nie powieść, mówi o tym w sygnaturze. Każdy wywołujący potwierdza to przez check lub inną jawną konstrukcję.

Z samej sygnatury funkcji możesz odpowiedzieć na dwa pytania, na których bardzo zależy agentowi (albo analizatorowi statycznemu, albo recenzentowi kodu):

• "Czy to może dotknąć świata zewnętrznego?" Tak wtedy i tylko wtedy, gdy pojawia się World.
• "Czy to może się nie powieść?" Tak wtedy i tylko wtedy, gdy pojawia się raises.

Ta właściwość nie istnieje w popularnych językach, a jej posiadanie to niemała rzecz.

Kosztem jest przekazywanie parametrów. Wartość World trzeba przekazywać wszędzie tam, gdzie potrzebne jest I/O; klauzula raises powtarza się wszędzie, gdzie przepływają błędy. Zero akceptuje to jako cenę tej właściwości.

Zasada 3: deterministyczne narzędzia

Trzecia zasada najbardziej bezpośrednio celuje w agentów: każde wyjście kompilatora to ustrukturyzowane dane.

Sztandarowym przykładem jest diagnostyka w JSON:

{
    "code": "NAM003",
    "message": "unknown identifier",
    "line": 3,
    "repair": { "id": "declare-missing-symbol" }
}

Trzy właściwości odróżniają to od zwykłego błędu kompilatora:

1. Stabilne kody. NAM003 znaczy to samo dziś i jutro, niezależnie od treści komunikatu dla ludzi.
2. Ustrukturyzowane plany naprawy. Gdy kompilator uważa, że wie, jak naprawić problem, zwraca plan jako dane: listę edycji, a nie sugestię po angielsku.
3. Wiele ustrukturyzowanych kanałów. Diagnostyka, grafy zależności, raporty rozmiaru i wyjaśnienia są dostępne w trybach --json.

Chodzi o to, żeby narzędzie, agent czy cokolwiek innego, nigdy nie musiało parsować angielskiego tekstu, aby działać na podstawie wyjścia kompilatora. Wyszukanie stabilnego kodu jest dokładne; parsowanie prozy jest niepewne. Zero traktuje to pierwsze jako umowę, a to drugie jako udogodnienie dla ludzi.

Zasada 4: biblioteka, która żyje w języku

Agenci dobrze piszą kod zgodny z istniejącymi wzorcami. Gorzej radzą sobie z wyborem właściwej zewnętrznej zależności spośród morza opcji, jej poprawną integracją i śledzeniem, kiedy jej API się zmienia. Każda zewnętrzna zależność to tarcie.

Projekt Zero przenosi możliwości do biblioteki standardowej: jawnie udokumentowanej, spójnej i stabilnej w miarę stabilizowania się języka. Celem jest, aby program w Zero rzadko musiał sięgać poza standardową dystrybucję przy rutynowej pracy. Dzięki temu powierzchnia, o której agent musi rozumować, pozostaje ograniczona.

Na dziś to raczej aspiracja niż gotowy stan. Biblioteka standardowa przed wersją 1.0 jest prawdziwa, ale wciąż rośnie. Zasada wyznacza kierunek, a nie cel podróży.

Co Zero oddaje w zamian

Każda decyzja projektowa ma swoją cenę. Uczciwe kompromisy, na które idzie Zero:

• Rozwlekłość zamiast zwięzłości. Czyste funkcje nie potrzebują World. Funkcje z I/O go potrzebują. Błędy pojawiają się w sygnaturach. Efekt to więcej adnotacji niż w odpowiedniku w JavaScripcie czy Pythonie.
• Jawność zamiast magii. Bez refleksyjnego metaprogramowania, bez dekoratorów po cichu opakowujących zachowanie, bez niejawnych zmiennych globalnych. Rzeczy, które w językach dynamicznych "po prostu działają", trzeba połączyć ręcznie.
• Statyczność zamiast dynamiki. Typy są wymagane dla parametrów, wartości zwracanych i pól shape. Kompilator wykonuje dużo pracy; kosztem jest to, że każdą sygnaturę autor (lub generator) musi napisać.
• Stabilność zamiast tempa zmian. Język jest przed wersją 1.0 i szybko się zmienia, ale zamiarem projektowym jest zamrożenie powierzchni, gdy już się ustabilizuje. Kosztem jest to, że dodanie później sprytnego nowego udogodnienia staje się trudniejsze, bo poprzeczka dla dodatków brzmi: "czy to pomaga agentowi bardziej, niż go kosztuje?"

To, czy te kompromisy się opłacają, zależy od tego, co optymalizujesz. Jeśli jako człowiek piszesz jednorazowy skrypt, tarcie jest realne, a korzyści dla agentów abstrakcyjne. Jeśli obsługujesz agenta, który produkuje tysiące małych programów dziennie, tarcie zwraca się wielokrotnie.

Czym Zero nie próbuje być

Kilka zaprzeczeń, które warto powiedzieć wprost:

• Nie "przyszłością całego programowania". Zero to hipoteza, a nie manifest. Hipoteza brzmi: ograniczenia agent-first dają użyteczny język. To, czy popularne języki powinny przyjąć te ograniczenia, to osobna, dłuższa rozmowa.
• Nie funkcją platformy wdrożeniowej Vercela. Choć pochodzi z Vercel Labs, Zero nie jest powiązane z Next.js ani z hostingiem Vercela. To samodzielny język systemowy.
• Nie zamiennikiem Rusta, Go czy Ziga na produkcji. Wersja przed 1.0. Eksperymentalna. Używaj go do nauki i przekazywania opinii; nie wdrażaj jeszcze z nim oprogramowania dla klientów.
• Nie gotowym produktem. Części biblioteki standardowej, składnia mutowalności, formy obsługi błędów i ograniczenia generyków mogą się zmienić przed wersją 1.0.

Co jest ciekawe, nawet jeśli go nie używasz

Nawet jeśli nigdy nie napiszesz linii w Zero, ten eksperyment wiele uczy:

• To najwyraźniejszy przykład prawdziwego, działającego systemu efektów opartego na capabilities w małym języku systemowym. Model myślowy (przekaż pozwolenie, zobacz efekt w sygnaturze) da się przenieść gdzie indziej.
• Podejście do diagnostyki to coś, co każdy kompilator powinien robić od dekady. Ustrukturyzowane wyjście zawsze wygrywa z prozą, a przywiązanie Zero do stabilnych kodów inne narzędzia mogłyby przejąć bez żadnych zmian w języku.
• Zasada "jeden sposób na każdą rzecz, celowo mała powierzchnia" idzie pod prąd tego, jak zwykle projektuje się języki. Obserwowanie, gdzie ta zasada pomaga, a gdzie uwiera, jest przydatne niezależnie od tego, w jakim języku będziesz pisać jutro.

Co czytać dalej

Jeśli masz już za sobą resztę tej dokumentacji, najbardziej przydatne będą źródła zewnętrzne:

• Repozytorium Zero pod github.com/vercel-labs/zero: przykłady, kod źródłowy i AGENTS.md z opisem zamierzeń samych opiekunów projektu.
• Oficjalna strona zerolang.ai: instrukcje na start i kanoniczne wprowadzenie.

Oba źródła się rozwijają. To, co tam znajdziesz, będzie bardziej aktualne niż jakikolwiek zewnętrzny tutorial. Zasady z tego artykułu zmieniają się powoli; składnia wokół nich będzie się zmieniać, dopóki język się nie ustabilizuje.