Verbesserungen für jede Effort-Stufe der Agent API

Mit den Effort-Stufen in der Perplexity Agent API können Entwickler für jede Aufgabe die Balance aus Kosten, Geschwindigkeit und Recherchetiefe wählen. Ab heute kostet jede Effort-Stufe weniger pro Anfrage, bei höherer oder unveränderter Recherchequalität. Eine neue Stufe ultra steht für besonders umfassende und weitreichende Recherchen zur Verfügung. Jede Anfrage, die die Stufe über ihren Namen auswählt, etwa effort="fast", erhält automatisch die aktualisierte Konfiguration.

Wer einen Recherche-Agenten entwickelt, muss für jede Aufgabe die richtige Balance aus Kosten, Geschwindigkeit und Tiefe finden. Effort-Stufen in der Agent API nehmen den Nutzern diese Entscheidung ab. Jede Stufe ist eine gebündelte Konfiguration, die Modell, Schrittbudget, Sucheinstellungen und Tools für einen bestimmten Aufgabentyp festlegt. Perplexity evaluiert und aktualisiert jede Stufe fortlaufend, um die bestmögliche Recherche zu den aktuellen Kosten oder darunter zu liefern.

Diese Verbesserungen gehen auf zwei Arten von Änderungen zurück. Budgets, Kontextverwaltung und Extraktion senkten die Kosten jedes Durchlaufs, während Skills, Modellauswahl und parallele Agenten die Qualität der Antwort steigerten oder hielten.

Bei medium stieg die Leistung auf BrowseComp und DSQA von 55 % auf 77 %, während die Kosten um fast 90 % sanken. BrowseComp und DSQA sind öffentliche Recherche-Benchmarks; WANDR ist der Benchmark von Perplexity für lange Rechercheaufgaben mit mehreren Entitäten. xhigh übernimmt agentische Arbeit wie das Ausführen von Code in einer Sandbox, lange Schleifen mit Tool-Nutzung und die gleichzeitige Arbeit mit vielen Quellen. xhigh hielt seinen WANDR-Wert bei 76,5 % und verursachte dabei nur etwa 25 % der Kosten der Konfiguration vom August 2026.

Eine Anfrage für Vertiefte Recherche kann Dutzende Suchen ausführen, Hunderte Seiten lesen und Belege prüfen, bevor sie eine Antwort liefert. Jede dieser Aktionen fügt dem Kontext Tokens und der Rechnung Kosten hinzu. Ohne Limits führt ein Agent immer weiter Aktionen aus, die die Kosten erhöhen und den Kontext überfüllen, ohne die Antwort zu verbessern. Die meisten dieser Kosten werden von fünf Faktoren bestimmt:

Budgetzuweisung. Bei Agenten mit festgelegtem Budget können die Schritte ausgehen, sodass sie ihren Durchlauf vorzeitig beenden, bevor ihre Aufgabe abgeschlossen ist. Umgekehrt können Agenten ohne festes Budget immer weiterlaufen und Kosten verursachen, ohne die endgültige Antwort zu verbessern.
Kontext-Overhead. Suchergebnisse und abgerufene Seiten liefern die Belege, doch ohne Kontrolle kann sich das Kontextfenster schnell mit irrelevanten Informationen füllen. Kontextfenster verursachen von Schritt zu Schritt Kosten, und überlastete Fenster können die Leistung des Agenten beeinträchtigen.
Workflow-Auswahl. Unterschiedliche Aufgaben erfordern unterschiedliche Ansätze. Eine einzelne Faktenabfrage, eine Multi-Hop-Frage und ein breiter Überblick über Quellen erfordern jeweils einen anderen Workflow. Überlässt man dem Modell die Wahl, entscheidet es sich oft für einen ineffizienten. Jede verfügbare Strategie im Prompt des Agenten detailliert zu beschreiben, löst das Problem nicht. Die zusätzlichen Anweisungen werden bei jedem Schritt als Tokens mitgeführt, und das Modell befolgt jede einzelne mit der Zeit weniger zuverlässig.
Modellauswahl. Der Wechsel zu einem größeren Modell bringt nicht unbedingt eine Leistungssteigerung, die den Mehrkosten entspricht. Neue Modelle erscheinen mit Schlagzeilen und veröffentlichten Benchmark-Ergebnissen. Benchmark-Gewinne können jedoch verfälscht sein oder auf eine Überanpassung des Modells zurückgehen. Ohne Evaluierung an realen Aufgaben kann ein Modellwechsel die Kosten erhöhen, ohne die Qualität zu verbessern.
Skalierung mit mehreren Agenten. Ein einzelner Agent kann pro Durchlauf nur eine begrenzte Anzahl von Quellen durchsuchen, lesen und auswerten. Mehrere Agenten parallel auszuführen, verbessert die Qualität bei den anspruchsvollsten Aufgaben, erhöht aber auch die Kosten und bringt zusätzliche Komplexität mit sich, wenn es nicht richtig umgesetzt wird.

Durch die Lösung jeder dieser Herausforderungen sanken die Kosten jeder Effort-Stufe, ohne dass die Leistung abnahm.

Jede Effort-Stufe hat ein festes Recherchebudget mit drei Komponenten:

Schrittlimits: die Anzahl der Runden, die der Agent durchlaufen kann
Tool-Aufrufe: eine Obergrenze für die Gesamtzahl der Tool-Aufrufe in einer Anfrage. Ein einzelner Schritt kann mehrere Aufrufe über mehrere Tools gleichzeitig auslösen, daher steuert ein Schrittlimit allein nicht, wie viele Aktionen innerhalb eines Schritts stattfinden.
Budget-Erinnerungen: regelmäßige Hinweise darauf, wie viele Schritte noch verbleiben, damit der Agent priorisieren und Raum für das Verfassen der Antwort lassen kann, statt mitten in der Aufgabe sein Budget aufzubrauchen.

Das Budget ist der zentrale Zielkonflikt: Mehr Schritte bedeuten bessere Antworten, und jeder Schritt verursacht Kosten. Mit openai/gpt-6-luna steigt die Genauigkeit auf BrowseComp + DSQA von 41 % auf 80 %, wenn das Schrittlimit von 1 auf 15 erhöht wird, während die Kosten pro Anfrage von 0,0017 $ auf 0,0152 $ steigen – etwa die 9-fachen Kosten für etwa den doppelten Wert.

Ein Schrittlimit allein steuert die Recherchekosten nicht. Beim gleichen Budget von fünf Schritten führt openai/gpt-6.1-terra mehr Tool-Aufrufe aus als openai/gpt-6-luna, da leistungsfähigere Modelle dazu neigen, mehrere Aufrufe in einem einzigen Schritt auszulösen. Effort-Stufen begrenzen sowohl Tool-Aufrufe als auch Schritte. Bei diesen Modellen ist die Obergrenze für Tool-Aufrufe genauso wichtig wie das Schrittlimit.

Jede Effort-Stufe passt diese Limits an, doch der Agent muss auch wissen, wie viele Schritte und Aktionen ihm noch bleiben, um die Anfrage zu erfüllen. Ohne diese Information können ihm die Schritte oder Aktionen ausgehen, sodass er antworten muss, bevor die Recherche abgeschlossen ist. Das Budget wird zu Beginn des Durchlaufs angegeben, und Erinnerungen treffen ein, wenn sich der Agent seinen Limits nähert, damit Raum bleibt, die Ergebnisse zu überprüfen und zu liefern. Bei high decken die Erinnerungen sowohl das Schrittbudget als auch das Budget für Tool-Aufrufe ab.

Zwei Agenten, einer mit Budget-Erinnerung und einer ohne, wurden mit einer BrowseComp-Aufgabe getestet, bei der sie anhand von drei Biografien von Darstellern eine Fernsehserie aus den 1990er-Jahren identifizieren sollten. Der Agent mit Erinnerung fand die richtige Antwort mit 13 der 40 Schritte im Budget. Der Agent ohne Budget-Erinnerung verbrauchte alle 40 Schritte und fand die richtige Antwort nicht. Seine Schleife endete unerwartet, und das Modell wusste nichts vom verbleibenden Recherchebudget. Erinnerungen halten Agenten fokussiert und helfen ihnen, verbleibende Ressourcen effektiv zu priorisieren.

Lang laufende Rechercheaufgaben füllen das Kontextfenster des Modells mit Suchergebnissen, abgerufenen Seiten und Zwischennotizen. Ist es voll, muss der Agent die Arbeit einstellen.

Durch Komprimierung bleiben lange Durchläufe funktionsfähig, ohne das Kontextfenster zu füllen. Überschreitet der Kontext einen Schwellenwert, ersetzt der Agent die bisherige Arbeit durch eine kürzere Zusammenfassung dessen, was er gefunden hat und was noch aussteht, und arbeitet dann weiter.

Bei der Komprimierung bleiben stets drei Dinge im Kontext erhalten: der System-Prompt, die ursprüngliche Anfrage und alle Skills, die der Agent bereits geladen hat. Nach jeder Komprimierung erhält der Agent zwei kurze Anweisungen. Die erste lautet: „Arbeite weiter, bis die Aufgabe erledigt ist.“ So behandelt der Agent die Zusammenfassung nicht als Endpunkt. Die zweite Anweisung teilt dem Agenten mit, wie viele Komprimierungen bereits stattgefunden haben, damit er seine verbleibenden Rechercheaufgaben planen kann. Bei langen Durchläufen bleiben das ursprüngliche Ziel und der Plan im Blick, und die Kosten langer Schleifen sinken, ohne dass die Qualität leidet.

Jede Seite, die der Agent liest, erweitert seinen Kontext, und der Agent trägt sie bei jedem weiteren Schritt mit. Eine Webseite enthält Informationen, die nichts mit der Frage zu tun haben, etwa Navigation, Standardtexte und andere Inhalte.

Statt dem Agenten eine komplette Seite zu übergeben, führt fetch_url zunächst einen Extraktionsdurchlauf aus. Der Seitentext wird zusammen mit der aktuellen Aufgabe des Agenten an ein kleineres Modell gesendet. Das Modell gibt nur die relevanten Passagen zurück, und zwar wörtlich zitiert, damit der Agent sie als Quelle angeben kann. Bei einer Evaluierung wurde eine Seite mit 5.561 Tokens auf 293 Tokens reduziert, wodurch Platz für weiteren relevanten Kontext frei wurde.

Die Verwendung von fetch_url mit Extraktion auf der Effort-Stufe high reduzierte die Input-Tokens pro Anfrage um etwa 50 %. Die Extraktion verbesserte außerdem die Benchmark-Leistung: 88,0 % bei 0,073 $ pro Anfrage, verglichen mit 83,5 % bei 0,094 $ ohne Extraktion.

Die Websuche ist zentral für jede Rechercheanfrage an einen Agenten. An der Art, wie Agenten suchen, wurden drei Änderungen vorgenommen:

Mehr Kontext pro Suche: Jede Suche liefert jetzt bis zu 4K Tokens an Ergebnissen statt 2K. Der Agent findet schneller, was er braucht, was zu weniger Suchen und geringeren Kosten führt.

Eine neue Snippet-Engine: Suchergebnisse erhalten Snippets, die besser zur Suchanfrage passen, sodass der Agent nicht mit irrelevantem Text überlastet wird.
Fast Search: Für 1,00 $ pro 1.000 Anfragen senkt Fast Search sowohl die Kosten als auch die Latenz jedes Suchaufrufs.

Das Team von Perplexity Search verbessert kontinuierlich die Abrufqualität für ein breites Spektrum an Aufgaben. Jüngste Updates brachten Verbesserungen bei Code, Entwicklerdokumentation, Referenzseiten sowie juristischen und regulatorischen Inhalten.

Manche Aufgaben erfordern viele parallel laufende Suchen, andere die genaue Lektüre einiger weniger langer Dokumente.

Jeden Workflow in den System-Prompt des Agenten zu laden, erhöht jedoch den Kontext-Overhead und kann dazu führen, dass das Modell bei einfachen Aufgaben schlechter abschneidet. Stattdessen sind Skills in einer Baumstruktur mit schrittweiser Offenlegung organisiert. Das Modell lädt relevante Skills und Anweisungen während der Arbeit und hält nicht zugehörige Informationen aus seinem Kontext heraus. Jeder Skill kostet nur seinen Namen und seine Beschreibung, bis das Modell entscheidet, dass er zur Aufgabe passt, und ihn lädt. Erst dann werden die vollständigen Anweisungen dem Kontext hinzugefügt, und das Modell folgt dem vorgegebenen Workflow.

Um den Beitrag einzelner Skills zu messen, wird jeweils ein Skill entfernt, um Qualität und Kosten bei Aufgaben zu vergleichen, bei denen der Baseline-Agent diesen Skill geladen hat. Diese Ablationen zeigen, welche Workflows dem Agenten helfen und wie sie sich auf die Effizienz der Recherche auswirken.

Die folgenden WANDR-Benchmark-Durchläufe zeigen, wie Agenten für bestimmte Aufgaben die richtigen Workflows wählen. Die Anleitungen für Wide-Search und Fanout wurden bei jeder Aufgabe geladen, da jeweils mehrere Entitäten untersucht werden mussten. People-Search wurde nur bei 6 % der Aufgaben geladen, und zwar nur dann, wenn es in den Fragen um Personen ging.

Bei einer weiteren WANDR-Aufgabe lud der Agent den People-Search-Skill mit einem Fanout-Muster, um Inference Engineers in London zu finden. Er erweiterte 39 Rollenbezeichnungen zu 117 Suchanfragen und führte die Ergebnisse des ersten Durchlaufs anschließend zu 43 eindeutigen Profilen für das weitere Screening zusammen. Der People-Search-Skill führte den Agenten durch diese Erweiterung, ohne irrelevanten Kontext hinzuzufügen. Der folgende Auszug ist an das Skript des Agenten angelehnt; die Namen der Hilfsfunktionen dienen nur zur Veranschaulichung.

code1

text

Python

# roles contains the 39 role variants selected by the agent.
queries = []
for role in roles:
    queries.extend([
        {"query": f"Google DeepMind {role} London"},
        {"query": f"Google {role} London"},
        {"query": role, "company": "Google", "location": "London"},
    ])

results = pplx_sdk.search.people_many(
    queries, limit_per_query=50, concurrency=8
)

profiles = {}
for result in results:
    if not result.ok:
        continue
    for profile in result.result:
        if "linkedin.com/in/" not in profile.url:
            continue
        url = profile.url.split("?")[0].rstrip("/")
        previous = profiles.get(url, {})
        if url not in profiles or len(profile.summary or "") > len(
            previous.get("summary") or ""
        ):
            profiles[url] = {
                "url": url,
                "title": profile.title,
                "summary": profile.summary,
            }

Checkpointing ist ein weiterer Workflow, der Agenten bei lang laufenden Aufgaben hilft. Das Checkpointing-Muster stammt aus der Batch-Programmierung. Wenn ein Skript eine lange Liste verarbeitet, schreibt es jedes Ergebnis auf die Festplatte, sobald es vorliegt, statt alles bis zum Ende im Speicher zu halten. Stürzt das Skript ab oder treten unterwegs Fehler auf, geht nichts verloren: Der nächste Durchlauf liest, was bereits gespeichert wurde, und macht dort weiter, wo der vorherige aufgehört hat. Dabei werden nur die fehlgeschlagenen Elemente erneut versucht.

Bei einer anderen WANDR-Aufgabe musste der Agent die Profile von 188 Engineers prüfen. Er lud das Checkpoint-Muster, um jedes Ergebnis während der Arbeit zu erfassen. Im ersten Durchlauf wurden 160 Profile extrahiert, bei 28 schlug der Vorgang fehl. Als der Agent das Skript erneut ausführte, übersprang er die bereits erfassten Profile und wiederholte nur die verbleibenden 28. Ohne den Checkpoint hätte ein einziger fehlerhafter Datensatz bedeutet, alle 188 erneut abzurufen.Adaptierter Python-Auszug; Eingabeseiten, Screening-Anweisung, Schema und Importe ausgelassen; die Namen der Hilfsfunktionen dienen nur zur Veranschaulichung.

code 2

text

Python

checkpoint = Checkpoint("research/profile-screening")
config = instruction + json.dumps(schema)
config_id = hashlib.md5(config.encode()).hexdigest()[:6]

def checkpoint_key(page):
    url_id = hashlib.md5(page["url_in"].encode()).hexdigest()[:10]
    return config_id + url_id

pending = [
    page for page in pages if not checkpoint.has(checkpoint_key(page))
]
for offset in range(0, len(pending), 20):
    batch = pending[offset : offset + 20]
    inputs = [
        json.dumps({
            "url": page["url_in"], "content": page["content"][:30_000]
        })
        for page in batch
    ]
    results = pplx_sdk.llm.extract_many(
        inputs,
        instruction=instruction,
        output_schema=schema,
        chunk_size=5,
        concurrency=4,
    )
    for page, result in zip(batch, results):
        if not result.ok or result.result.error:
            continue
        checkpoint.record(
            checkpoint_key(page),
            [{"url": page["url_in"], **result.result.result}],
        )

Der Checkpoint erfasst erfolgreiche Ergebnisse; er startet keine Wiederholungsversuche. Da Anweisung und Schema Teil des Schlüssels sind, lösen geänderte Screening-Kriterien eine erneute Verarbeitung aus.

Nicht jeder Test führte zu Verbesserungen bei Qualität und Effizienz. Evaluiert wurde auch, alle Skills vorab in den Agenten zu laden, bevor er mit seiner Aufgabe begann. Auf BrowseComp und DSQA erhöhte das Vorabladen die Kosten um 13 %. Auf WANDR, wo abgerufene Inhalte durch längere Rechercheverläufe einen größeren Anteil der Input-Tokens ausmachen, senkt das Vorabladen zudem die Werte. Diese Ergebnisse sprachen dafür, weiterhin auf schrittweise Offenlegung zu setzen.

Mit dem Fortschritt der Modellfähigkeiten ändert sich auch das beste Modell für jede Effort-Stufe. Perplexity setzt eine automatisierte Rechercheschleife ein, die Ankündigungen und die Verfügbarkeit neuer Modelle überwacht. Evaluierungen werden ausgelöst, sobald ein Modell zugänglich ist.

Wenn ein neues Modell veröffentlicht wird, schickt ein automatisierter Agent es durch den harness für die Evaluierung. Dabei variiert er den Reasoning-Aufwand, die Budgets für Schritte und Tool-Aufrufe sowie die Tool-Konfigurationen und bewertet jeden Durchlauf hinsichtlich Qualität und Kosten im Vergleich zu den aktuellen Effort-Stufen. Verschlechtert sich ein Durchlauf, untersucht der Agent die Ursache, passt die Einstellungen an und führt die Evaluierung erneut aus. Ein Kandidat ersetzt das aktuelle Modell nur, wenn er bei gleichen oder geringeren Kosten qualitativ überlegen ist.

Öffentliche Benchmarks sind nützlich, doch ihre Ergebnisse lassen sich nicht immer auf reale Aufgaben übertragen. Das folgende Diagramm zeigt beispielsweise ein Kandidatenmodell, das bei BrowseComp 13,3 Punkte über der Baseline lag, bei internen Rechercheaufgaben aus den Bereichen Unternehmen, Recht und Finanzen jedoch deutlich unter den entsprechenden Baselines.

Ein einzelner Agent kann in einer Schleife nur eine begrenzte Zahl von Quellen abdecken. Bei komplexen Aufgaben arbeiten mehrere Agenten parallel, die sich jeweils um einen anderen Teil des Problems kümmern.

Der primäre Agent ist der Orchestrator. Er ruft spawn_agent auf, um untergeordnete Agenten zu erstellen, und weist jedem eine konkrete, klar abgegrenzte Aufgabe zu. Jeder untergeordnete Agent führt seine eigene Rechercheschleife mit separatem Kontext aus und nutzt dabei sein eigenes Modell, eigene Tools und ein eigenes Schrittbudget. Die untergeordneten Agenten melden ihre Ergebnisse an den übergeordneten Agenten, der ihnen Folgeaufträge erteilen oder ihren Fortschritt prüfen kann. Der Orchestrator und seine untergeordneten Agenten tauschen Nachrichten aus, um Belege zu teilen, Hindernisse zu melden und nächste Schritte anzupassen. Sobald neue Informationen eintreffen, verfeinert der Orchestrator die Aufträge und führt die Ergebnisse nach Abschluss der Arbeit zu einer einzigen Antwort zusammen.

Die Agent API unterstützt vordefinierte Agentenrollen, und der Orchestrator kann untergeordnete Agenten mit benutzerdefinierten Anweisungen erstellen.

Die Effort-Stufe ultra führt drei Agenten parallel auf einer Aufgabe aus. Jeder Agent recherchiert die gesamte Aufgabe unabhängig, sodass unterschiedliche Belege zusammenkommen. Ein vierter Agent führt ihre Ergebnisse zusammen, entfernt Duplikate und verfasst die endgültige Antwort.

Auf WANDR erreicht ultra 85,9 % bei 21,71 $ pro Aufgabe. Das ist der höchste Wert unter den getesteten Konfigurationen.

Effort-Stufen werden kontinuierlich evaluiert und verbessert. Die von Nutzern gewählte Stufe bestimmt, wie viel Recherche in eine Aufgabe fließt und wie viel sie kostet. Budgets für Schritte und Tool-Aufrufe halten Anfragen im Rahmen des Budgets, unterstützt durch Erinnerungen, wenn diese zur Neige gehen. Komprimierung, Extraktion und bessere Snippets halten den Kontext auf Belege fokussiert. Skills passen den Workflow an die Aufgabe an, und parallele Agenten erweitern, was eine einzelne Schleife abdecken kann. Eine automatisierte Evaluierungsschleife lässt ein neues Modell nur zu, wenn es die Recherchequalität bei gleichen Kosten verbessert.

Jede Effort-Stufe wird sich weiterentwickeln, sobald sich neue Modelle und Konfigurationen in der Evaluierung bewähren. Wer eine Stufe über ihren Namen aufruft, profitiert automatisch von diesen Verbesserungen; wer eine Version festlegt, behält eine feste Konfiguration bei.

Testen Sie die Agent API und vergleichen Sie die Effort-Stufen mit Ihren eigenen Workloads. Details zu den Effort-Stufen finden Sie in unserer Dokumentation zu Effort in der Agent API.

Die Kosten der Recherche

Das Recherchebudget steuern

Kontext verwalten

Komprimierung

Nur abrufen, was zählt

Gezielte Websuche

Den richtigen Workflow auswählen

Modellauswahl

Skalierung mit mehreren Agenten

Wie es weitergeht