Das erste web-native KI-Agenten-Framework

peerd ist die erste universelle Agenten-Laufzeitumgebung, die direkt auf Browser-Primitiven aufbaut: Workers, Origins, Sandboxing, OPFS, WASM/WASI, WebRTC, WebAuthn und WebExtensions. Sie läuft vollständig in Chrome und Firefox, mit deinen Tabs, angemeldeten Sitzungen, Web-Apps und lokaler Rechenleistung.

Während Agenten-Plattformen versuchen, den Browser in das Framework zu ziehen, zieht peerd das Framework in den Browser.

Für die eigentliche Inferenz kannst du einen unterstützten gehosteten Modellanbieter wählen, ein lokales Modell über localhost verwenden oder dir die vorläufige Unterstützung für lokale WebGPU-Modelle ansehen (wir behalten auch WebNN im Auge).

Kein peerd-Konto, gehosteter Browser oder Tool-Server-Verbindung ist erforderlich. Aktuelle Builds senden keine Produkt-Telemetrie an peerd.

Installation · peerd.ai · Architektur · Sicherheit

Funktionen

• Funktioniert in dem Browser, den du bereits verwendest. Der Agent kann deine Tabs, Web-Apps, angemeldeten Sitzungen und Seiteninhalte lesen und steuern.
• Erstellt wiederverwendbare Site-Clients. Der Web-Actor kann eine Site einmal lernen und diesen Client bei späteren Aufgaben erneut verwenden.
• Führt Code innerhalb der Browser-Grenzen aus. Skripte, versiegelte JavaScript-Notebooks, kompilierte WASI-Tools, Browser-Apps und Linux-WebVMs geben dem Agenten lokale Rechenleistung ohne Zugriff auf dein Host-Betriebssystem.
• Delegiert an separate Actors. Jede Seite und jede Rechenumgebung erhält ihren eigenen schlüssellosen Actor mit auf diese Umgebung begrenzten Tools.
• Behält nützlichen Kontext. Sitzungen, Speicher, Fähigkeiten, Ziele, Überprüfung und Checkpoints leben in der Erweiterung.
• Verwendet das Modell deiner Wahl. Das Live-Anbieterverzeichnis ist in registry.js definiert, einschließlich BYOK-Cloud-Adapter und schlüsselloser lokaler Optionen.
• Verbindet Browser direkt. Preview-Builds fügen signierte Identität, Browser-zu-Browser-Erkennung, dwapps und Agent-zu-Agent-Kommunikation über WebRTC hinzu; Store-Pakete entfernen dies vollständig.

Warum der Browser

Lokale Agenten können auf deinen gesamten Computer zugreifen. Remote-Agenten leben auf dem Computer eines anderen. Der Browser ist die Alternative: lokale Fähigkeiten hinter Sicherheitsgrenzen, die über drei Jahrzehnte gehärtet wurden.

peerd nutzt diese Grenzen. Seitenarbeit geht an separate Actors mit nur den Tools für diesen Tab oder diese Umgebung. Anmeldedaten, Netzwerkregeln, Bestätigungen und Audit bleiben bei der Erweiterung. Das Defense-in-Depth-Design geht davon aus, dass unsichere Inhalte irgendwann einen Filter passieren werden.

Browser-Unterstützung

peerd unterstützt Chromium und Firefox. Firefox führt Actors in dedizierten Workern aus und verwendet sichtbare Notebooks für JavaScript-Berechnungen. Funktionen, die den Offscreen-Document-Host von Chrome benötigen, werden vor der Verwendung aus Firefox-Steuerelementen und Modell-Tools entfernt. Firefox-Preview-Builds lassen dweb weg, bis Firefox einen Mesh-Host hat.

Apps und WebVMs laufen auf Chrome. Apps haben keinen Ambient-Netzwerkzugriff. Remote-Ressourcen, Fetches, WebRTC, Formulare und externe Dokumentnavigation sind blockiert. Externe HTTP- und HTTPS-Links erfordern eine Benutzerbestätigung.

Konkrete Browser-Funktionslücken, ihre Upstream-Probleme und die Tests, die zum Entfernen jeder Absicherung erforderlich sind, werden in docs/BROWSER-COMPATIBILITY.md verfolgt.

Der Code ist die Quelle der Wahrheit für das aktuelle Verhalten. Beginne mit CLAUDE.md und lies dann das relevante Modul unter extension/.

Sicherheitsmodell

peerd verwendet Browser-Isolation, enge Tool-Exposition, Service-Worker-Policy-Gates und explizite Egress-Kontrollen. Der Hauptagent delegiert Umgebungsarbeit an schlüssellose Actors. In Chrome und Firefox laufen Nicht-Orchestrator-Agenten-Schleifen in separaten dedizierten Worker-Heaps. Wenn der Browser diese Grenze nicht nachweisen kann, wird die Actor-Anfrage nicht ausgeführt und verrichtet keine Arbeit an ihrem Ziel.

Das Netzwerkverhalten hängt von der Operation ab. Modellaufrufe, Web-Lesevorgänge, Laufzeit-Asset-Ladevorgänge, Sandbox-Verkehr und Preview-dweb-Verkehr verwenden unterschiedliche begrenzte Pfade und Richtlinien. Siehe SECURITY.md und das Bedrohungsmodell für die aktuellen Grenzen und bekannte Einschränkungen.

Installation

Chrome aus dem Quellcode

1. Klone das Repository.
2. Öffne chrome://extensions.
3. Aktiviere den Entwicklermodus.
4. Wähle Entpackte Erweiterung laden und wähle das Verzeichnis extension/.

Lade die Erweiterung nach Quellcode-Änderungen von chrome://extensions neu.

Firefox aus dem Quellcode

Firefox benötigt ein Firefox-spezifisches Paket. Lade nicht das eingecheckte Chrome-Entwicklungsmanifest. Verwende eine Firefox-Version, die mindestens dem im Kanal-Patch unter manifests/ deklarierten Minimum entspricht. Diese Untergrenze verfolgt die dokumentgebundene Skripting-Unterstützung, die von Browser-Tools verwendet wird.

bun run package -- --channel=preview --browser=firefox --no-sign

Öffne about:debugging#/runtime/this-firefox, wähle Temporäres Add-on laden und wähle artifacts/peerd-preview-firefox.xpi. Temporäre Add-ons müssen nach einem Firefox-Neustart erneut geladen werden. Browser- und Kanal-Transformationen werden von den Packaging-Skripten definiert.

Release-Pakete

Siehe GitHub Releases für aktuelle Artefakte. Store- und Preview-Builds unterscheiden sich. Store-Builds lassen dweb weg. Preview-Builds enthalten es und können zusätzliche Automatisierungsfunktionen aktivieren. Der Packaging-Code ist die Autorität für jeden Browser und Kanal.

Erster Start

1. Öffne peerd über die Browser-Symbolleiste.
2. Erstelle und entsperre den lokalen Tresor. Die Entsperrung per Passphrase ist immer verfügbar. Die Entsperrung per Passkey hängt von der WebAuthn-PRF-Unterstützung in Browser und Gerät ab.
3. Schließe das kurze Profil-Onboarding ab.
4. Öffne die Einstellungen und füge einen Anbieterschlüssel hinzu oder wähle einen unterstützten lokalen Anbieter.
5. Wähle ein Modell aus und starte einen Chat.

Nur Tresorgeheimnisse und geschützte Sicherheitsdatensätze sind durch die Tresor-Verschlüsselungsgrenze abgedeckt. Anderer lokaler Erweiterungsstatus folgt den Speicherregeln in der Sicherheitsdokumentation.

Architektur

Die Erweiterung hat fünf Hauptmodule. Jedes Modul stellt seine öffentliche API über seine index.js bereit.

Das Erweiterungs-Chassis lebt in background/, offscreen/, sidepanel/, engine-tabs/, permissions/, shared/ und zugehörigen Support-Verzeichnissen. Host-Platzierung und die Cold-Worker-Regel sind in docs/EXTENSION-HOSTS.md dokumentiert.

Entwicklung

Die Quell-Erweiterung ist Vanilla-JavaScript mit ES-Modulen und läuft direkt, wenn sie entpackt geladen wird. Es gibt keinen Entwicklungs-Bundler, Transpiler, Watcher oder generierten Laufzeitbaum. Release-Packaging verwendet Bun nur auf seiner wegwerfbaren Staging-Kopie, um Leerzeichen/Kommentare aus den erstellten Modulen in den statischen Service-Worker- und Chrome-Offscreen-Cold-Graphen zu entfernen. Es bewahrt Modulgrenzen, Bindungsnamen, Lazy-Imports und jedes vendored Byte. Übergib --no-minify an bun run package -- ..., wenn ein lesbares Diagnose-Artefakt nützlich ist.

bun install
bun run gen:dev
bun test ./tests
bun scripts/cdp/run-inbrowser-tests.mjs
bun run typecheck
bun run lint
bun run e2e:verify
bun run preflight

Es gibt drei Testoberflächen:

• Bun-Tests für reine Logik.
• In-Browser-Tests für Erweiterungs- und Browser-Integration. Sie laufen headless unter Chrome und, sharded, unter Gecko gegen das installierte Firefox-Store-Paket. Jede Lane führt jeden Test aus, den sie registriert; die Gesamtzahlen unterscheiden sich leicht, weil einige Tests nur registrieren, wo ein Live-Service-Worker antwortet.
• Live-Chrome-E2E- und visuelle Verifizierung für vollständige Abläufe.

Daneben treibt die Red-Team-Suite in tests/red-team/ jeden Gegner aus dem Bedrohungsmodell gegen den echten Verteidigungscode und zeichnet auf, ob jede feindliche Sonde blockiert wurde. Ihre Matrix ist docs/security/RED-TEAM-RESULTS.md.

Jede Lane veröffentlicht ihre eigene Anzahl als Badge oben. Das Badge-JSON unter badges/ wird vom CI-Job generiert, der die Lane ausgeführt hat, und dann diffed, sodass eine Anzahl auf dieser Seite immer ein Beweis aus einem tatsächlich stattgefundenen Lauf ist und keine Zahl, die jemand getippt hat. Generiere eine neu mit bun run gen:badge:functional, bun run gen:badge:red-team, bun run gen:badge:inbrowser, bun run gen:badge:gecko (benötigt Firefox und geckodriver) oder bun run gen:badge:e2e und committe das Ergebnis. bun run check:badges verifiziert, dass die Endpunkte wohlgeformt sind, ohne einen Browser zu starten.

Für UI-Änderungen führe bun run e2e:verify aus, inspiziere scripts/cdp/artifacts/result.json und inspiziere die generierten Screenshots.

Generierte Dateien dürfen nicht von Hand bearbeitet werden. Insbesondere stammen extension/manifest.json und extension/shared/channel-config.js aus den Manifest- und Packaging-Quellen. CI prüft sie auf Abweichungen.

Lies CONTRIBUTING.md, bevor du Code änderst.

Dokumentation

• CLAUDE.md: Projektstruktur, Konventionen und aktuelle Haltung
• SECURITY.md: Sicherheitsrichtlinie und Meldung
• docs/security/THREAT-MODEL.md: Vertrauensgrenzen und Restrisiken
• docs/security/LIFECYCLE-CONTRACT.md: Unterbrechungsverhalten und Wiederherstellungsgrenzen
• docs/security/RED-TEAM-RESULTS.md: Red-Team-Abdeckung
• docs/APP-ACTORS.md: Manifest-definierte App-Actors, Live-Semantik-Adapter und die In-Tab-Co-Pilot-UX
• docs/DWAPP-BUNDLE.md: komprimierter dwapp-Transport, dekomprimierte Arbeitsobäume und Binär-Assets
• docs/store/: Store-Packaging, Berechtigungen, Datenschutz und Reviewer-Hinweise
• scripts/cdp/states.mjs: E2E- und visuelle Zustände

Abhängigkeiten und Lizenz

Die ausgelieferte Erweiterung hat keine npm-Laufzeitabhängigkeiten. package.json deklariert keine, und Packaging löst niemals einen node_modules-Pfad in das gestufte Artefakt auf, sodass der Entwicklungstool-Baum keinen installierten Browser erreichen kann. Drittanbieter-Laufzeitcode wird stattdessen unter extension/vendor/ vendored. Seine Quelle, Version und Lizenz leben in den angrenzenden SOURCE.txt-Dateien, und jedes vendored Byte ist per SHA-256 in extension/vendor/vendor.lock.json gepinnt, was bun run check:vendor in CI und Preflight verifiziert.

Zwei weitere Supply-Chain-Positionen tragen ihre eigenen Badges oben, beide von bun run gen:dev neu generiert und in CI auf Abweichungen geprüft. Jede Drittanbieter-GitHub-Action läuft mit einem vollständigen Commit-SHA, abgesichert durch check:actions: Ein Major-Tag ist ein veränderbarer Ref, den sein Publisher verschieben kann, was beliebigen Code in einem Job bedeuten würde, der dieses Checkout hält, und im Release-Workflow die Signing-Secrets. Neu aufgelöste Abhängigkeiten sitzen außerdem eine Quarantänefrist ab, bevor sie in den Lock aufgenommen werden können, festgelegt durch minimumReleaseAge in bunfig.toml, zusammen mit einem Malware-Scan bei der Installation.

peerd ist unter der Apache License 2.0 lizenziert. Vendored Komponenten behalten ihre eigenen Lizenzen. CheerpX ist eine proprietäre Laufzeitumgebung von Leaning Technologies und wird nicht von peerd's Apache-Lizenz abgedeckt.