Search nie powinien być przyciskiem. Powinien być programowalnym narzędziem dla agentów

Artykuł Perplexity „Rethinking Search as Code Generation“ opisuje Search as Code: architekturę, w której agent nie wywołuje jednego monolitycznego search engine, lecz składa retrieval pipeline jako kod. Najważniejsze nie jest nowe API dla search. Ważne jest to, że agenci dostają kontrolę nad tym, jak dowody są znajdowane, filtrowane i weryfikowane.

Perplexity zmienia search z odpowiedzi w zestaw prymitywów

Klasyczne wyszukiwanie zaprojektowano dla ludzi. Wpisujesz zapytanie, dostajesz stronę wyników i wybierasz. Pierwsze systemy AI w dużej mierze przejęły ten sam kontrakt: model wywołuje endpoint search, dostaje przetworzony pakiet wyników i używa go jako kontekstu.

Perplexity twierdzi, że to przestaje wystarczać dla pracy agentów. Dzisiejszy agent nie ma tylko odpowiedzieć na pytanie. Ma wykonać zadanie, które może obejmować setki małych kroków retrieval, porównywanie źródeł, deduplikację, weryfikację i kolejne zapytania zależne od wyników pośrednich.

Search as Code odpowiada właśnie na tę granicę. Zamiast jednej czarnej skrzynki daje agentowi SDK z mniejszymi klockami: retrieval, ranking, filtering, fan-out, rendering i obsługę stanu pośredniego. Model generuje potem Python, który składa te klocki w pipeline dopasowany do konkretnego zadania.

Dla agentów najdroższy jest zły kontekst

Największym problemem monolitycznego search nie jest tylko trafność. Jest nim kontrola nad kontekstem. Gdy agent potrzebuje jednego precyzyjnego faktu, a dostaje szeroki pakiet wyników, szum kosztuje tokeny, latency i jakość decyzji.

Przy szerokich zadaniach jeden endpoint też często nie wystarcza. Szukanie vendor advisories dla setek CVE wymaga exact phrase queries, site-scoped search, odrzucania agregatorów, sprawdzania relacji między CVE, produktem i fix version oraz backfillu, gdy pokrycie jest słabe. To nie jest naturalnie liniowa rozmowa. To jest program.

Perplexity podaje case study dla ponad 200 high-severity CVE z lat 2023 do 2025. Ich rozwiązanie Search as Code miało osiągnąć 100% accuracy i obniżyć token usage z 288,7 tys. do 42,9 tys. Do liczb z benchmarku dostawcy podchodzę ostrożnie, ale kierunek jest sensowny: deterministyczna praca należy do runtime, nie do przestrzeni tokenów.

Bez dobrych prymitywów powstanie tylko szybszy bałagan

Search as Code nie zadziała automatycznie tylko dlatego, że model dostanie Python i web. Zły agent napisze zły crawler tak samo szybko jak zły prompt. Wartość wynika z tego, że search stack musi zostać rozbity na właściwe prymitywy, a model musi nauczyć się ich używać.

Dlatego dwa szczegóły z tekstu Perplexity są ważniejsze niż marketingowa nazwa. Po pierwsze, używają skills, które uczą modele, jak składać SDK w użyteczne wzorce. Po drugie, wolą jawne zapisywanie stanu w filesystemie niż implicit REPL state. Nudne, ale poprawne. Długie przebiegi agentów potrzebują audytowalnego stanu, nie notebooka pełnego zmiennych, których nikt nie potrafi wyjaśnić.

Mniej tokenów i lepsza ewidencja jako praktyczna miara

Dobry agentic research będzie bardziej przypominał mały data pipeline niż rozmowę z search boxem. Agent najpierw tworzy kandydatów, potem ich pobiera, czyści, weryfikuje relacje, zapisuje evidence rows i dopiero wtedy oddaje człowiekowi zwięzły wniosek.

To dobry kierunek także poza Perplexity. Hermes, wewnętrzni agenci i firmowe narzędzia researchowe nie potrzebują prywatnego SDK Perplexity, żeby przejąć zasadę: model kontroluje strategię, kod wykonuje pracę mechaniczną, a do finalnej odpowiedzi trafia tylko zweryfikowany destylat.

Werdykt Lilith

Search as Code to nie kolejna ładna nazwa na web search. To moment, w którym agent przestaje przeglądać wyniki jak człowiek i zaczyna budować własny pipeline śledczy: kandydaci, filtry, dowody i kosz na szum.