Ein Local-First-Agent für private und kostengünstige Wissensarbeit

Perplexity Portable Computer ist ein Local-First-Agent.

Der gesamte Stack läuft standardmäßig lokal. Das Modell, das Harness, die Konversation und die Trajektorie befinden sich vollständig auf dem Computer des Benutzers. Arbeit, die die Aussenwelt erfordert, wie Websuche, Konnektoren oder die Eskalation an ein stärkeres Berändermodell in der Cloud, wird nur bei Bedarf aufgerufen und stets vom Benutzer kontrolliert. Sensible Daten verlassen das Gerät daher niemals ohne Erlaubnis, und lokale Modelle verursachen keine Inferenzgebühren: Das System ist von Haus aus privat und kostengünstig.

Ein effektiver Local-First-Agent erfordert, dass Modell und Harness gemeinsam entwickelt werden. Universelle Harnesses setzen ein Frontier-Modell voraus, das lange Kontexte verarbeiten, eine breite Tool-Oberfläche bedienen und über lange Zeiträume planen kann. Unter diesen Anforderungen sind lokale Modelle weniger zuverlässig. Anstatt von einem kleinen Modell zu verlangen, ein für ein großes gebautes Harness zu verwalten, haben wir beide aufeinander abgestimmt: ein Harness, das auf das Fähigkeitsprofil des Modells zugeschnitten ist, und ein Modell, das im Post-Training darauf ausgelegt wurde, dieses Harness effektiv zu nutzen.

Einleitung

Die agentischen Fähigkeiten haben sich in den letzten Monaten bei einer Vielzahl von Wissensarbeitsaufgaben rasant weiterentwickelt. Zwar bringen diese Fortschritte große Produktivitäts- und Effizienzsteigerungen, sie stellen jedoch auch vor zwei Herausforderungen.

Der Token-Verbrauch steigt rasant an, und mit ihm die Gesamtkosten. Wenn über die APIs von Closed-Source-Modellen, die auf Remote-Clustern laufen, auf Intelligenz zugegriffen wird, verlassen private Informationen und geistiges Eigentum bei jeder Anfrage das Gerät des Benutzers. Da Agenten über individuelle Workflows und ganze Organisationen hinweg skalieren, werden Token-Ausgaben und Datenbewegungen zunehmend schwieriger zu kontrollieren.

Gleichzeitig haben sich Open-Source-Modelle noch schneller verbessert. Am deutlichsten ist der Fortschritt bei sehr kleinen und effizienten Modellen wie NVIDIA Nemotron 3.5 Lightning (30 Mrd. Gesamtparameter), Qwen 3.6 (35 Mrd.) und Qwen 3.8 (27 Mrd.). Diese kleinen Modelle leisten Enormes und sind inzwischen zu komplexen agentischen Workflows fähig. Die Hardware für die lokale Inferenz entwickelt sich parallel dazu weiter: Systeme wie der NVIDIA DGX Spark können diese Modelle nun lokal ausführen. Zusammen machen diese Trends den vollständigen Betrieb auf dem Gerät praktikabel und ermöglichen es Benutzern gleichzeitig, bei Bedarf externe Funktionen wie Websuche, Konnektoren oder Cloud-Modell-Eskalation hinzuzuziehen.

Dieser Local-First-Ansatz ermöglicht erhebliche Kosteneinsparungen, da die lokale Inferenz API-Gebühren pro Token überflüssig macht. Zudem löst er ganz natürlich die Bedenken hinsichtlich Datenschutz und geistigem Eigentum: Private Token müssen niemals an Remote-Cluster übertragen werden und verbleiben sicher innerhalb der Grenzen des lokalen Geräts.

Im Juni haben wir den ersten hybriden Inferenz-Orchestrator für lokale Server vorgestellt, der entscheidet, welche Arbeit auf dem Gerät ausgeführt werden soll und welche an Agenten in der Cloud geht. Hier erklären wir, wie wir einen solchen Local-First-Agenten entwickelt haben, einschließlich des Harness und der aufeinander abgestimmten Modelle.

Wir geben einen Überblick über die wichtigsten Designentscheidungen und bewerten Computer im Vergleich zu gängigen Open-Source-Harnesses (Hermes und Pi) anhand von drei öffentlichen Benchmarks und unserer internen Local Knowledge Work Bench. Bei unserem Benchmark, bei dem das Modell Qwen 3.8 27B auf einem NVIDIA DGX Spark läuft, erreicht Computer mit 82,6 % im Vergleich zu 77,6 % für Pi und 74,0 % für Hermes die höchste Punktzahl. PPLX 27B, unser auf Basis von Qwen 3.8 27B trainiertes Modell, steigert den Wert weiter auf 85,4 %.

Das Harness auf das lokale Modell ausrichten

Obwohl kompakte Modelle auf dem Gerät bereits sehr leistungsfähig sind, hinken sie größeren Frontier-Modellen in der Performance noch hinterher. Um diese Modelle effektiv zu steuern und ihre Grenzen auszugleichen, ist ein sorgfältig konzipiertes Harness erforderlich.

Beliebte Open-Source-Harnesses wie Pi und Hermes haben sich als universell erwiesen: Sie funktionieren gut mit einer Vielzahl von Modellen unterschiedlicher Größe und Klasse. Sie sind jedoch nicht auf die Fähigkeiten von On-Device-Modellen optimiert. Wir haben das lokale Harness speziell für dieses Szenario anhand weniger Kernprinzipien entwickelt.

Kontexteffizienz

Das Hauptaugenmerk bei der Entwicklung unseres Harness lag darauf, den Kontext des Modells optimal zu nutzen.

Obwohl On-Device-Modelle wie Qwen 3.8 27B Kontextfenster von 260K Token bieten, haben wir empirisch festgestellt, dass sie ab 100K Token beginnen zu schwächeln. Wir halten das Kern-Harness daher kurz und bündig: einen minimalen System-Prompt und eine kleine Reihe von Kern-Tools.

Alle anderen Funktionen sind in On-Demand-Skills modularisiert, die während der gesamten Trajektorie geladen und entladen werden. Wir haben diese Skills für gängige Wissensarbeitsaufgaben entwickelt: Recherche, Data Science, Datenvisualisierung, Dokumentenerstellung, Softwareentwicklung und mehr.

Das Harness unterstützt zudem eine Kontextverdichtung (Context Compaction), bei der veralteter Kontext zusammengefasst wird, wenn eine Trajektorie lang wird, damit das Modell innerhalb seines effektiven Fensters bleibt.

Konnektoren als Befehlszeilentools

Die tägliche Wissensarbeit erfordert oft Konnektoren wie Gmail, GitHub, Outlook und Google Calendar. Diese werden einem Harness normalerweise als MCP-Server bereitgestellt, deren umfangreiche Tool-Definitionen einen beträchtlichen Teil des Kontexts verbrauchen. Stattdessen haben wir die am häufigsten verwendeten MCPs in kompakte, einfach zu bedienende Befehlszeilentools umgewandelt, ergänzt durch benutzerdefinierte Skills, die den begrenzten effektiven Kontext weitaus besser nutzen.

Selbstverifikation

Die Leistung verbessert sich auch, wenn der Agent seine eigene Arbeit verifiziert. Die Verifikation fügt zwar zusätzliche Schritte hinzu, verbessert jedoch die Endergebnisse erheblich und verringert den Abstand zu Frontier-Modellen deutlich. Sie kann vom Modell selbst oder durch eine Reihe von Hooks ausgelöst werden, die den Zustand der Trajektorie überwachen und eine Selbstverifikation anfordern, wenn etwas schiefgeht.

Ausführung in einer Sandbox

Das Harness führt Tools in einer Sandbox auf Betriebssystemebene auf dem Gerät des Benutzers aus. Die Begrenzung schränkt Prozesse, Dateisystempfade und den Netzzugriff entsprechend den Richtlinien ein. Dies begrenzt den potenziellen Schadensradius eines fehlerhaften Befehls. Wenn die Sandbox nicht verfügbar ist, deaktiviert sich das Harness vor jeglichen Tool-Aufrufen selbst, anstatt auf eine Ausführung ohne Sandbox zurückzufallen.

Dies unterscheidet sich von Open-Source-Harnesses wie Pi und Hermes, die Befehle standardmäßig direkt mit den Berechtigungen des Benutzers ausführen. In Computer ist die Isolierung immer aktiv, erfordert keine Konfiguration und Tools können nicht ohne sie ausgeführt werden.

Das folgende Diagramm zeigt, wie diese Prinzipien in der Ausführungsschleife zusammenwirken. Der Orchestrator ist deterministischer Harness-Code und kein LLM: Er hält die Schleife aufrecht, stellt den Kontext zusammen und setzt Richtlinien durch. Das lokale Modell schlägt die nächste Aktion vor; der Orchestrator führt genehmigte Tool-Aufrufe in der Sandbox aus und gibt deren Ergebnisse an das Modell zurück. Websuche, Konnektoren und Berateraufrufe überschreiten die Gerätegrenze nur, wenn dies aktiviert und genehmigt wurde.

Ein lokales Harness macht mehr aus demselben Modell

Unter Verwendung desselben lokalen Basismodells vergleichen wir unser lokales Harness mit universellen Alternativen bei der Websuche und dem multimodalen Dokumentenverständnis. Alle Harnesses verwenden das Modell Qwen 3.8 27B mit mittlerem Reasoning, das auf einem NVIDIA DGX Spark ausgeführt wird. Dieser Vergleich isoliert die Fähigkeiten, die das Harness selbst beisteuert, noch vor jeglichem Model-Post-Training.

Wir konzentrieren uns auf diese beiden Fähigkeiten, da Wissensarbeit häufig private Dokumente auf dem Gerät des Benutzers mit öffentlichen Informationen aus dem Web kombiniert, um ein fundiertes Artefakt zu erzeugen. Die Websuche erfordert Konnektivität, aber die Modellinferenz und die Verarbeitung privater Dokumente bleiben lokal. Lokale Dateien dienen als maßgebliche Quelle, öffentliche Quellen fügen Kontext hinzu, und Benutzer können die Websuche für vollständig offline durchgeführte Arbeit komplett deaktivieren.

Webrecherche

Wir entwickeln unser lokales Harness zusammen mit der Suchmaschine von Perplexity, die in unabhängigen Evaluierungen Top-Platzierungen erreicht hat. Das Harness greift über die Schnittstelle Search as Code darauf zu.

Wir bewerten die Forschungsqualität anhand von 1.266 BrowseComp-Aufgaben. Computer nutzt die Suchinfrastruktur von Perplexity zusammen mit unserem lokalen Harness, während sich Pi und Hermes auf Brave, ihren empfohlenen Suchanbieter, verlassen. Computer erreicht eine Genauigkeit von 66,7 %, verglichen mit 50,2 % für Pi und 43,9 % für Hermes.

Computer weist zudem die kürzeste durchschnittliche aufgezeichnete Laufzeit (Wall Time) und den geringsten Token-Verbrauch auf: 402,1 Sekunden und 852k Token pro Aufgabe, verglichen mit 1.020,9 Sekunden und 1,01 Millionen Token für Hermes sowie 826,0 Sekunden und 2,82 Millionen Token für Pi. Computer benötigt somit 61 % weniger Laufzeit und 16 % weniger Token als Hermes sowie 51 % weniger Laufzeit und 70 % weniger Token als Pi.

Multimodales Dokumentenverständnis auf dem Gerät

Viele Dokumente enthalten visuelle Informationen und lassen sich nur schwer als Text parsen: PDFs, gescannte Seiten, Screenshots, Diagramme und Präsentationen. Diese Workflows hängen von OCR und Bildverständnis ab und profitieren am meisten von einem nativ multimodalen Modell.

Das Harness übergibt Dokumentenseiten und Bilder direkt an das Modell, das diese versteht und visuelle Evidenz mit dem extrahierten Text kombiniert. Die Verarbeitung dieser Dateien auf dem Gerät hält sensible Dokumente und deren extrahierte Inhalte privat.

Wir bewerten das multimodale Dokumentenverständnis anhand von ParseBench-100, einer Untergruppe des ParseBench-Benchmarks mit 100 Aufgaben, wobei jeweils 20 Aufgaben auf Diagramme, Layout, Tabellen, Textinhalte und Formatierung entfallen.

Computer erreicht eine Durchschnittspunktzahl von 65,1 %, verglichen mit 34,6 % für Hermes und 13,9 % für Pi. Zudem schließt es Aufgaben mit der kürzesten Zeit und den wenigsten Token ab: im Durchschnitt 60,6 Sekunden und 20,1k Token pro Aufgabe, verglichen mit 108,3 Sekunden und 32,1k Token für Hermes sowie 410,5 Sekunden und 829,1k Token für Pi. Computer führt in allen fünf Dokumentenkategorien, wobei der größte Vorsprung bei Diagrammen liegt. Das Layout bleibt für alle drei Harnesses eine Herausforderung.

Tabelle 1. Durchschnittspunktzahl bei ParseBench-100 nach Dokumentenkategorie für die Harnesses Computer, Hermes und Pi mit dem On-Device-Modell Qwen 3.8 27B. Computer führt in allen fünf Kategorien.

Verringerung des Abstands zu Frontier-Modellen durch Beräter-Eskalation

Selbst mit einem sorgfältig konzipierten Harness übersteigen die schwierigsten Aufgaben nach wie vor die Fähigkeiten eines kompakten On-Device-Modells. Für solche Aufgaben stellt das Harness ein Beräter-Tool bereit: Das lokale Modell kann ein stärkeres Frontier-Modell konsultieren, wenn es Hilfe bei der Planung, der Auflösung von Ambiguitäten, der Bewältigung wiederholter Fehler oder der Verifikation des Endergebnisses benötigt.

Das lokale Modell entscheidet, wann Rat angefordert wird, während der Harness-Orchestrator die Tool-Autorität behält und steuert, welcher Kontext gesendet wird. Die Eskalation ist optional. Der Benutzer entscheidet, ob er sie aktiviert und ob er jeden Beräter-Aufruf manuell oder automatisch genehmigt.

Vor einem Beräter-Aufruf wählt das Harness den relevanten Kontext aus, wendet einen PII-Klassifizierer an, um sensible Informationen zu kennzeichnen, und zeigt dem Benutzer, was das Gerät verlassen würde. Der Beräter erhält nur den genehmigten Kontext und gibt Texthinweise zurück; er hat keinen direkten Zugriff auf die Dateien, Tools oder Konversationen des Geräts. Dies verbessert sowohl die Kosten als auch den Datenschutz, und wir planen, diesen Ansatz in zukünftiger Arbeit weiter zu erforschen.

Wir testen diesen Ansatz bei anspruchsvollen Softwareentwicklungsaufgaben, die starkes Reasoning erfordern und bei denen ein lokales Modell am häufigsten an seine Grenzen stößt. Dazu verwenden wir Terminal Bench 2.1, einen beliebten Benchmark mit 89 Aufgaben für Coding-Agenten.

Wir möchten zwei Fragen beantworten: Wie viel des Abstands zu einem Frontier-Modell kann die Beräter-Eskalation schließen und zu welchen Kosten. Vollständig lokale Modelle verursachen praktisch keine Betriebskosten, da die Inferenz auf der Hardware des Benutzers stattfindet. Sobald das Modell jedoch beginnt, den Beräter aufzurufen, fallen API-Kosten an.

Als Baseline für die Frontier-Leistung verwenden wir Claude Opus 5, das im lokalen Harness betrieben wird; das lokale Modell ist Qwen 3.8 27B. Schließlich koppeln wir beide: Qwen 3.8 27B führt die Aufgabe aus und eskaliert bei Bedarf zu einem Claude Opus 5-Beräter. Wir bewerten die Beräter-Eskalation nicht mit Pi oder Hermes, da keines der beiden ein äquivalentes Beräter-Tool bereitstellt; das Hinzufügen eines solchen würde die Modifikation der Tool-Oberfläche und der Orchestrierungslogik erfordern, sodass das Ergebnis nicht mehr das Standard-Harness repräsentieren würde.

Die Beräter-Eskalation erhöht die Punktzahl von Computer von 59,6 % auf 73,0 %, was einer Steigerung um 13,5 Prozentpunkte bei geschätzten API-Kosten von 0,415 $ pro Rollout entspricht. Der alleinige Betrieb von Claude Opus 5 erreicht 82,4 % bei 0,65 $ pro Rollout. Die Eskalation gleicht somit etwa drei Fünftel des Abstands zum Spitzenmodell zu etwa zwei Dritteln der Kosten des Spitzenmodells aus, und der Benutzer entscheidet, wann sich dieser Kompromiss lohnt.

Post-Training für das Harness und die Wissensarbeit

Bisher haben wir das lokale Modell unverändert gelassen, um zu isolieren, was das Harness beiträgt. Nach Fertigstellung des Harness-Designs stammen die größten verbleibenden Leistungssteigerungen aus der Anpassung des Modells selbst. Nutzungsdaten von Perplexity Computer zeigen uns, was Menschen bei der Wissensarbeit tatsächlich tun, was wir zur Synthese von Trainingsdaten nutzen. Wir unterziehen das lokale Modell innerhalb des Computer-Harness einem Post-Training, geleitet von der realen Verteilung der Aufgaben, die Benutzer ausführen.

Konkret identifizieren wir eine Vielzahl von Anwendungsfällen, die verschiedene Modellfähigkeiten, Tools und Konnektoren beanspruchen. Aus diesen Anwendungsfällen synthetisieren wir realistische Reinforcement-Learning-Umgebungen und definieren anspruchsvolle, aber verifizierbare Aufgaben: Jede Aufgabe besteht aus einer Anweisung, einer Umgebung und einem Verifizierer, der das Endergebnis bewertet, wobei die Umgebung ein Docker-Container ist, in dem das Harness arbeitet. Da die Aufgaben synthetisch sind, enthalten sie wichtigstens keine echten Dokumente oder Benutzerinformationen.

Wir verwenden diese Umgebungen für ein zweistufiges Training: Rejection Fine-Tuning gefolgt von Reinforcement Learning. In der ersten Stufe lassen wir das Modell für jede Aufgabe mehrmals gegen die Aufgabe antreten, wählen die besten Trajektorien anhand der Verifizierer-Punktzahl aus und trainieren damit mittels Supervised Learning. Diese Stufe initialisiert das Modell für das spezifische Harness und die Aufgabenverteilung. In der zweiten Stufe optimiert das Reinforcement Learning das Modell weiter und macht es robuster.

Eine Untergruppe von Aufgaben wird vom Training zurückgehalten und für die finale Evaluierung verwendet; wir nennen dieses zurückgehaltene Set Local Knowledge Work Bench: 53 Aufgaben, die sieben Kategorien der täglichen Wissensarbeit abdecken, von der vertieften Recherche bis zur Dokumentenerstellung. Wir werden in Kürze einen technischen Bericht veröffentlichen, der das Modelltraining im Detail beschreibt, und planen, diesen Evaluierungs-Benchmark als Open Source zur Verfügung zu stellen.

Wir haben Qwen 3.8 27B mit diesem Ansatz im Post-Training optimiert, wodurch ein Modell entstand, das wir PPLX 27B nennen, und haben es auf der Local Knowledge Work Bench evaluiert. Mit dem Basismodell Qwen 3.8 27B erreicht Computer die höchste Punktzahl (82,6 %, im Vergleich zu 77,6 % für Pi und 74,0 % für Hermes) und verbraucht die wenigsten Token (520k gegenüber 681k für Pi und 634k für Hermes). Pi schließt Aufgaben mit 176 Sekunden pro Aufgabe am schnellsten ab, verglichen mit 218 Sekunden für Computer und 292 Sekunden für Hermes. PPLX 27B hebt die Punktzahl von Computer auf 85,4 % an, auf Kosten von mehr Token (678k gegenüber 520k). Die geschätzte Laufzeit beträgt 250 Sekunden.

Tabelle 2. Aufgabenkategorien der Local Knowledge Work Bench.

Fazit

Unsere Forschung zeigt, dass ein starkes Open-Source-Modell mit leistungsstarker lokaler Hardware und einem für diese konzipierten Harness echte Wissensarbeit zu nahezu null Inferenzkosten bewältigen kann, ohne dass sensible Daten das Gerät verlassen müssen.

Über die verschiedenen Benchmarks hinweg erreichte oder übertraf Computer Hermes und Pi hinsichtlich der Genauigkeit, während Qwen 3.8 27B auf einem NVIDIA DGX Spark ausgeführt wurde. Unter den drei Benchmarks, die Latenz und Token-Nutzung ausgeben, war Computer bei BrowseComp und ParseBench-100 am schnellsten und verbrauchte bei allen drei die wenigsten Token; Pi war auf der Local Knowledge Work Bench am schnellsten.

Die Leistungssteigerungen resultieren aus unseren Designentscheidungen. Wir haben ein kurzes, prägnantes lokales Harness mit Skills entwickelt, die bei Bedarf geladen werden. Wir haben Konnektoren anstelle von MCP-Servern in kompakte CLI-Tools umgewandelt. Die Ausführung wurde aus Sicherheitsgründen in einer Sandbox gekapselt.

Die Ergebnisse zeigen auch, wo kompakte Modelle noch Verbesserungspotenzial haben. Bei den anspruchsvollen Coding-Aufgaben von Terminal Bench 2.1 beispielsweise hinkt das lokale Modell dem Frontier-Modell über alle drei Harnesses hinweg hinterher. Die Beräter-Eskalation verringert den Abstand, schließt ihn jedoch nicht vollständig; fortlaufende Verbesserungen der Modellfähigkeiten und der lokalen Hardware sind weiterhin erforderlich, um die Leistung weiter zu steigern.

Der Zweck der Entwicklung von Harness und Modell für lokale Einschränkungen besteht darin, Benutzern die ausdrückliche Kontrolle darüber zu geben, welche Informationen ihre Maschinen verlassen. Es gibt auch Kostenvorteile für den Benutzer. Wir sehen dies als Teil einer größeren Entwicklung, in der zunehmend fähige Agenten von der Remote-Infrastruktur auf individuelle und lokale Geräte übergehen. Wir erwarten, dass Fortschritte bei Chips, Modellen und Geräten das Spektrum der Wissensarbeit, die Portable Computer lokal bewältigen kann, kontinuierlich erweitern werden.