webgpu-agent / doku.html
ogerl's picture
Doku: Browser-Checklisten-Zeile entfernt (WP UI-DASH/ARTIFACT/WEBSITE/BENCH-IMPL geschlossen)
5b3dad4 verified
Raw History Blame Contribute Delete
36.2 kB
<!doctype html>
<html lang="de">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<title>webgpu-agent · Doku</title>
<meta name="description" content="Dokumentation zum webgpu-agent: Warum wir es machen, was das Ziel ist, wo der Stand steht, der Forschungsansatz, die offenen Probleme und der Plan für ein eigenes Wächter-Modell." />
<!-- App-Unterseite (WP-APP-DOKU): dunkler Look wie die App, selbstständig (kein JS). -->
<style>
:root {
--bg: #0a0c10; --panel: #11151c; --panel2: #161b24; --line: #222a36;
--txt: #e6eaf2; --mut: #8b95a7; --acc: #4da3ff; --acc2: #8b7bff;
--ok: #3ddc97; --warn: #ffb454; --err: #ff6b6b;
--mono: ui-monospace, SFMono-Regular, Menlo, Consolas, monospace;
}
* { box-sizing: border-box; }
html { scroll-behavior: smooth; }
body { margin: 0; background: var(--bg); color: var(--txt); line-height: 1.65;
font-family: "Segoe UI", system-ui, -apple-system, Arial, sans-serif; }
.hl { animation: hl 1.8s ease-out; border-radius: 10px; }
@keyframes hl { 0% { background: rgba(77,163,255,.22); } 100% { background: transparent; } }
a { color: var(--acc); }
code { font-family: var(--mono); background: var(--panel2); border: 1px solid var(--line);
padding: 0 5px; border-radius: 5px; font-size: .88em; }
ul, ol { padding-left: 22px; } li { margin: 5px 0; }
.top { position: sticky; top: 0; z-index: 10; display: flex; align-items: center; gap: 10px;
padding: 10px 18px; background: rgba(17,21,28,.95); border-bottom: 1px solid var(--line);
backdrop-filter: blur(6px); flex-wrap: wrap; }
.back { display: inline-block; text-decoration: none; color: var(--txt); font-weight: 600;
border: 1px solid var(--line); background: var(--panel2); padding: 4px 12px; border-radius: 8px; }
.back:hover { border-color: var(--acc); color: var(--acc); }
.brand { font-weight: 700; letter-spacing: .2px; }
.tag { font-size: 11px; color: var(--mut); border: 1px solid var(--line); padding: 2px 8px; border-radius: 99px; }
.doc { max-width: 920px; margin: 0 auto; padding: 26px 20px 90px; }
h1 { font-size: 1.7rem; margin: 16px 0 8px; }
h2 { font-size: 1.22rem; margin: 36px 0 10px; padding-top: 14px; border-top: 1px solid var(--line);
scroll-margin-top: 76px; }
h3 { font-size: 1.02rem; margin: 22px 0 8px; color: var(--txt); }
.lead { color: var(--mut); font-size: 1.05rem; margin: 0 0 18px; }
.meta { color: var(--mut); font-size: .9rem; }
p { margin: 10px 0; }
table { width: 100%; border-collapse: collapse; margin: 12px 0 18px; font-size: .93rem; }
th, td { border: 1px solid var(--line); padding: 7px 11px; text-align: left; vertical-align: top; }
th { background: var(--panel2); }
.badge { display: inline-block; padding: 0 9px; border-radius: 999px; font-size: .75rem;
font-weight: 600; border: 1px solid var(--line); white-space: nowrap; }
.badge.ok { color: var(--ok); border-color: rgba(61,220,151,.4); background: rgba(61,220,151,.08); }
.badge.open { color: var(--warn); border-color: rgba(255,180,84,.4); background: rgba(255,180,84,.08); }
.badge.no { color: var(--err); border-color: rgba(255,107,107,.4); background: rgba(255,107,107,.08); }
.note { border: 1px solid rgba(77,163,255,.35); background: rgba(77,163,255,.07);
border-radius: 10px; padding: 12px 16px; margin: 16px 0; }
.warnbox { border: 1px solid rgba(255,180,84,.4); background: rgba(255,180,84,.07);
border-radius: 10px; padding: 12px 16px; margin: 16px 0; }
.toc { background: var(--panel); border: 1px solid var(--line); border-radius: 12px;
padding: 14px 20px; margin: 20px 0; }
.toc ol { margin: 8px 0 0; }
.toc a { text-decoration: none; }
.toc a:hover { text-decoration: underline; }
.btn { display: inline-block; background: var(--acc); color: #04101f; font-weight: 600;
padding: 9px 18px; border-radius: 9px; text-decoration: none; margin-right: 10px; }
.btn:hover { filter: brightness(1.12); }
.btn.ghost { background: transparent; color: var(--acc); border: 1px solid var(--acc); }
</style>
</head>
<body>
<header class="top">
<a class="back" href="./index.html">← App</a>
<div class="brand">✱ webgpu-agent</div>
<span class="tag">Dokumentation</span>
<span class="tag">WIP / Experiment</span>
<span class="tag">local-first</span>
</header>
<main class="doc">
<h1>Dokumentation</h1>
<p class="meta">Stand: <time datetime="2026-10-17">17. Oktober 2026</time> · Quelle: <code>doku.html</code> im Repository ·
<a href="https://github.com/ogerly/webgpu-agent">GitHub</a></p>
<p class="lead">
Ein autonomer Webagent, der zu 100&nbsp;% im Browser läuft: lokale LLMs auf der GPU (WebGPU),
strukturiertes Gedächtnis (AAMS), echte Task-Zerlegung und Ausführung — ohne Cloud, ohne Server.
</p>
<p>
<strong>Was ist das?</strong> webgpu-agent ist ein <strong>privates Forschungsprojekt / Experiment (WIP)</strong> —
kein fertiges Produkt, keine Support- oder Stabilitätsversprechen. Es ist ein Prototyp, dessen Zweck es ist,
Fragen zu beantworten, die sonst niemand sauber beantwortet: <em>Wie weit kommt ein wirklich autonomer Agent,
wenn er komplett im Browser leben muss?</em>
</p>
<p>
<a class="btn" href="./index.html">▶ Zur App (Demo)</a>
<a class="btn ghost" href="https://github.com/ogerly/webgpu-agent">Code auf GitHub (MIT)</a>
</p>
<nav class="toc" aria-label="Inhaltsverzeichnis">
<strong>Inhaltsverzeichnis</strong>
<ol>
<li><a href="#warum">Warum machen wir das?</a></li>
<li><a href="#ziel">Was ist das Ziel?</a></li>
<li><a href="#stand">Wo steht das Projekt?</a></li>
<li><a href="#forschung">Der Forschungsansatz</a></li>
<li><a href="#probleme">Offene Probleme — was es zu lösen gilt</a></li>
<li><a href="#waechter">Ein eigenes Modell für den Wächter</a></li>
<li><a href="#links">Links</a></li>
</ol>
<p class="meta" style="margin:10px 0 0">
<strong>Deep-Links (Anker):</strong> <code>doku.html#warum</code> · <code>#ziel</code> ·
<code>#stand</code> · <code>#forschung</code> · <code>#probleme</code> · <code>#waechter</code> ·
<code>#links</code> — und aus der App: <code>index.html#doku</code> bzw. <code>index.html#doku/probleme</code>
</p>
</nav>
<h2 id="warum">1. Warum machen wir das?</h2>
<h3>1.1 Datensouveränität ist keine Einstellung — es ist die Architektur</h3>
<p>
Fast alle heutigen AI-Agents arbeiten über Cloud-APIs: Jede Aufgabe, jeder Dateiinhalt, jedes
„Gedächtnis" des Agenten läuft über fremde Server. Das ist bequem — aber es bedeutet, dass die
Daten nie wirklich uns gehören. Für sensible Inhalte (private Texte, Arbeitsstände, persönliche
Notizen) ist das kein vertretbarer Zustand.
</p>
<p>
webgpu-agent stellt das um: Der Agent läuft <strong>komplett im Browser</strong>. Es gibt keine
Cloud-APIs, kein Backend, keine Serverinfrastruktur. Alle Daten — Aufgaben, Zwischenergebnisse,
Audit-Log, Gedächtnis — verbleiben zu 100&nbsp;% im Client-Browser. Das ist keine Option im
Einstellungs-Menü, sondern eine <strong>Invariante</strong> der Architektur: Sie lässt sich nicht
versehentlich „einschalten", weil sie schlicht nicht existiert.
</p>
<h3>1.2 Lokale Inferenz auf der eigenen GPU</h3>
<p>
Die Intelligenz kommt nicht aus dem Rechenzentrum, sondern von der GPU des eigenen Geräts. Über
<strong>WebGPU</strong> und <strong>WebLLM</strong> laufen quantisierte Open-Source-Modelle
(Qwen/Llama) direkt im Browser: ein kompakter <strong>„Wächter"</strong> (0,5&nbsp;B, läuft
permanent) und ein größerer <strong>„Planer"</strong> (3&nbsp;B, lädt bei Bedarf nach und wird
danach wieder entladen). Damit bleibt alles in einem realistischen VRAM-Budget (Zielprofil:
≤&nbsp;4&nbsp;GB).
</p>
<h3>1.3 Autonomie im Browser</h3>
<p>
Ein Agent ist nur dann interessant, wenn er Aufgaben selbst zerlegen und ausführen kann — nicht nur
antworten. Deshalb hat das Projekt einen echten <strong>Agent-Loop</strong>: Der Planer zerlegt eine
Aufgabe in Teilaufgaben (fester JSON-Schema), ein Executor führt sie aus, ein Audit-Log dokumentiert
jeden Schritt — inkl. echter Token-Usage. Der Agent hat außerdem ein <strong>strukturiertes
Gedächtnis</strong> (Session, Task-Tree, Audit, Memory in IndexedDB) und kann es als JSON
exportieren/importieren.
</p>
<h3>1.4 Die eigentliche Frage: Forschung, nicht Produkt</h3>
<p>
Dahinter steht eine Forschungsfrage: <strong>Wie weit kommt ein autonomer Agent mit echtem
Gedächtnis, wenn er vollständig clientseitig leben muss?</strong> Wo sind die technischen Grenzen —
VRAM, Kontextlänge, WebGPU-Verfügbarkeit, Offline-Fähigkeit, Portabilität des Gedächtnisses?
Diese Grenzen wollen wir <em>messen und dokumentieren</em>, nicht behaupten. Deshalb ist das Projekt
ausdrücklich ein Experiment: Es gibt ein Benchmark-System, offene Forschungsfragen und einen
stufenweisen Plan mit Abbruchkriterien (siehe <a href="#forschung">Forschungsansatz</a>).
</p>
<h3>1.5 AAMS — Gedächtnis als natives Modell</h3>
<p>
Das Gedächtnis- und Task-Modell des Agenten ist <strong>AAMS</strong> (Autonomous Agent Mesh
System). Eine Besonderheit dieses Projekts: AAMS spielt <em>doppelt</em> eine Rolle und wird dabei
strikt getrennt:
</p>
<table>
<tr><th>Rolle</th><th>Was</th><th>Wo</th></tr>
<tr>
<td><strong>A — Arbeitsgrundlage</strong></td>
<td>Steuert den Entwicklungsprozess: Workpapers, Whitepapers, Langzeit-Memory, Diary</td>
<td>In diesem Repository (<code>WORKING/</code>)</td>
</tr>
<tr>
<td><strong>B — Native Agenten-Architektur</strong></td>
<td>Das Gedächtnis- &amp; Task-Modell des Agenten selbst (Session, Task-Tree, Audit, Memory)</td>
<td>Im Browser des Nutzers (IndexedDB + JSON-Export)</td>
</tr>
</table>
<p>
Dasselbe Schema wird in beiden Rollen verwendet, die Instanzen bleiben getrennt. Für den Nutzer
heißt das: Der Agent <strong>versteht AAMS von Haus aus</strong> und baut seine eigene lokale
Wissens- und Task-Struktur exakt nach dieser Spezifikation auf.
</p>
<h2 id="ziel">2. Was ist das Ziel?</h2>
<h3>2.1 Kernziel</h3>
<p>Ein <strong>vollständig clientseitiger, autonomer Webagent</strong> mit:</p>
<ul>
<li>lokaler Inferenz auf der GPU (WebGPU/WebLLM) — keine Cloud für Kernprozesse (Invariante),</li>
<li>strukturiertem, session-bezogenem Gedächtnis (AAMS-B), portierbar per JSON-Export/Import,</li>
<li>eigener Task-Zerlegung und -Ausführung (echter Agent-Loop) mit nachvollziehbarer Audit-Spur,</li>
<li>prüfbar, reproduzierbar und ehrlich dokumentiertem Verhalten (Benchmark-System).</li>
</ul>
<h3>2.2 Forschungsziele (konkret)</h3>
<table>
<tr><th>#</th><th>Ziel</th><th>Warum</th></tr>
<tr>
<td>1</td>
<td><strong>Benchmark-System</strong> (Level L1–L10, ≤&nbsp;4&nbsp;GB-VRAM-Profil, Pass-Regel 5/5, Referenzgerät)</td>
<td>Ohne harte, programmatisch prüfbare Messung ist jede Aussage über „Funktioniert" unbelegt</td>
</tr>
<tr>
<td>2</td>
<td><strong>Wächter-Spezialist</strong> (eigenes getuntes 0,5–1,5-B-Modell für Protokoll-Aufgaben)</td>
<td>Der Wächter läuft permanent — seine Zuverlässigkeit hat die größte Hebelwirkung (siehe <a href="#waechter">§6</a>)</td>
</tr>
<tr>
<td>3</td>
<td><strong>Offline nach Setup</strong></td>
<td>Ein „lokaler" Agent, der nach dem ersten Start noch Internet braucht, ist nicht souverän</td>
</tr>
<tr>
<td>4</td>
<td><strong>Gedächtnis-Portabilität</strong> (besser als JSON-Export/Import)</td>
<td>Heute: Gedächtnis ist an Browser+Origin gebunden — anderes Gerät = leeres Gedächtnis</td>
</tr>
<tr>
<td>5</td>
<td><strong>Datei-Output</strong> (Artefakte: HTML → ZIP → docx/xlsx)</td>
<td>Nachgewiesene Lücke: Aufgabe „6/6 erledigt", aber 0 Dateien — Ergebnisse müssen echte Dateien sein</td>
</tr>
<tr>
<td>6</td>
<td><strong>Helfer-Modelle</strong> (OCR / Übersetzung / Web-Fetch) on-demand</td>
<td>Spezialisten nur bei Bedarf im VRAM, danach wieder frei</td>
</tr>
</table>
<h3>2.3 Nicht-Ziele (bewusst)</h3>
<ul>
<li>Keine Cloud-Anbindung für Kernprozesse, keine automatische Cloud-Synchronisation</li>
<li>Keine Benutzerverwaltung, kein Multi-Agent-Mesh / WebRTC (spätere, eigene Phase)</li>
<li>Kein Generalisten-Training, kein Wettlauf mit großen Modellen</li>
<li>Kein Produkt-Versprechen: Dies ist Forschung — der Stand kann sich ändern, die Richtung bleibt</li>
</ul>
<h2 id="stand">3. Wo steht das Projekt?</h2>
<p>
Stand: <time datetime="2026-10-17">17. Oktober 2026</time> · Prototyp (Vite + TypeScript) ·
Lizenz: MIT · Mitarbeit willkommen (GitHub-Issues/PRs).
</p>
<h3>3.1 Umgesetzt</h3>
<table>
<tr><th>Bereich</th><th>Was kann es</th><th>Status</th></tr>
<tr>
<td><strong>Agent-Loop</strong></td>
<td>Echte Zerlegung (Planer-JSON → Task-Tree) + echte Ausführung (Executor-Regel) mit echter Token-Usage und Audit-Spur (<code>llm.*</code>, <code>plan.*</code>, <code>chat.*</code>)</td>
<td><span class="badge ok">umgesetzt</span></td>
</tr>
<tr>
<td><strong>Modell-Pool</strong></td>
<td>Wächter (Qwen2.5 0.5B, ≈945&nbsp;MB) resident + Planer (Llama-3.2 3B, ≈2,3&nbsp;GB) on-demand · Modell-Katalog ≤&nbsp;4&nbsp;GB · Laden/Entladen, Download-Fortschritt, DEGRADED-State, VRAM-Budget-Balken</td>
<td><span class="badge ok">umgesetzt</span></td>
</tr>
<tr>
<td><strong>Chat</strong></td>
<td>Einziger Dialogkanal, Intent-gesteuert: Status · „beginne" → Ausführung · Aufgabe → Planer + automatischer Loop · Frage → Planer antwortet</td>
<td><span class="badge ok">umgesetzt</span></td>
</tr>
<tr>
<td><strong>Dashboard</strong></td>
<td>Dunkler App-Frame (3 Spalten): Rollen-Karten, VRAM-Bar, Tabs <strong>Zuschauen</strong> (Live-Feed) / <strong>Arbeit</strong> (Task-Tree) / <strong>Audit</strong> (filterbar) / <strong>Gedächtnis</strong></td>
<td><span class="badge ok">umgesetzt</span></td>
</tr>
<tr>
<td><strong>Artefakte</strong></td>
<td>HTML-Ergebnisse deterministisch aus <code>task.result</code> extrahiert (kein Schema-Eingriff) → Sandbox-Vorschau (ohne <code>allow-same-origin</code>) + Download + Audit</td>
<td><span class="badge ok">umgesetzt</span></td>
</tr>
<tr>
<td><strong>Gedächtnis</strong></td>
<td>AAMS-B in IndexedDB (Session, Tasks, Audit, Memory, Knowledge) · „Neue Session" mit automatischem Safety-Export + Rollback · JSON-Export/Import (portabel, mit Schema-Prüfung)</td>
<td><span class="badge ok">umgesetzt</span></td>
</tr>
<tr>
<td><strong>KERN</strong></td>
<td>Prototyp: Tokenwächter (Kontext-Grenzenwächter) + mechanischer Loop (simuliert) — Grundlage für die echten Loops</td>
<td><span class="badge ok">umgesetzt</span></td>
</tr>
<tr>
<td><strong>Benchmark-System</strong></td>
<td>Fixiert als Whitepaper WH-002: Level L1–L10, ≤&nbsp;4-GB-Profil, Metriken, Pass-Regel 5/5, Reproduzierbarkeits-Protokoll, Geräterollen</td>
<td><span class="badge ok">definiert</span> <span class="badge open">1. Testlauf offen</span></td>
</tr>
<tr>
<td><strong>Live-Demo</strong></td>
<td>Statisch gehostet (HuggingFace-Static-Space), App + Assets verifiziert</td>
<td><span class="badge ok">live</span></td>
</tr>
</table>
<h3>3.2 Noch offen</h3>
<table>
<tr><th>Punkt</th><th>Status</th></tr>
<tr>
<td>Erster Benchmark-Testlauf (L1 auf dem Referenzgerät — GTX 1050 4&nbsp;GB, Variante zu verifizieren)</td>
<td><span class="badge open">offen — erster Schritt</span></td>
</tr>
<tr>
<td>Benchmark-Seite (Szenario-Textseiten L1–L5, Start, Run-Report) + Panel „Maschine"</td>
<td><span class="badge open">offen</span></td>
</tr>
<tr>
<td>Helfer-Modelle (OCR / Übersetzung / Web-Fetch) via Transformers.js</td>
<td><span class="badge open">offen</span></td>
</tr>
<tr>
<td>Automatisierte Tests (Vitest) für Gedächtnis, Task-Queue, Modell-Pool</td>
<td><span class="badge open">offen</span></td>
</tr>
<tr>
<td>PWA / Offline-Cache für die Weights (Forschungsziel 3)</td>
<td><span class="badge no">bewusst nicht vor Messung</span></td>
</tr>
</table>
<div class="note">
<strong>Ehrlichkeit-Hinweis:</strong> Die Weights (≈&nbsp;945&nbsp;MB Wächter / ≈&nbsp;2,3&nbsp;GB
Planer) werden beim <em>ersten</em> Laden vom CDN heruntergeladen (Setup) — danach Browser-Cache.
WebGPU ist eine Pflicht-Voraussetzung: Chrome/Edge. Firefox/Safari: aktuell nicht verfügbar.
</div>
<h2 id="forschung">4. Der Forschungsansatz</h2>
<h3>4.1 Grundprinzipien</h3>
<ul>
<li><strong>Messen, nicht raten:</strong> Jede Aussage über Besserung braucht einen Benchmark-Vergleich. Keine erfundenen Messwerte.</li>
<li><strong>Hard DoD:</strong> Erfolg ist ein hartes, programmatisch geprüftes 0/1 (z.&nbsp;B. valide JSON ohne Retry), keine „klingt plausibel".</li>
<li><strong>Strikte Train/Test-Trennung:</strong> Auf dem Benchmark trainiert wurde, misst nichts. Test-Szenarien sind zurückgehalten.</li>
<li><strong>Nur geprüfte Daten:</strong> Programmatisch verifizierte Ergebnisse gelten als Beleg — kein Modell bewertet sich selbst.</li>
<li><strong>Ehrliche Grenzen:</strong> Grenzen werden benannt (VRAM, Kontext, Browser), nie still verschwiegen. Ein „nicht möglich" ist ein gültiges Ergebnis.</li>
<li><strong>Abbruchkriterien:</strong> Jeder Forschungsplan hat Stufen mit klaren Abbruch-Bedingungen — auch Abbruch wird dokumentiert.</li>
<li><strong>Reproduzierbarkeit:</strong> Commit-Hash, Modell-Revision, Seed, Tool-Versionen werden festgehalten.</li>
<li><strong>Lizenz zuerst:</strong> Basismodelle, Lehrermodelle und Quellen werden vor Nutzung geprüft.</li>
</ul>
<h3>4.2 Doku-Kette (AAMS-Dev-Prozess, Rolle A)</h3>
<p>
Der Entwicklungsprozess ist selbst Teil des Experiments: Jede Arbeits-Einheit startet mit einem
<strong>Workpaper</strong> (offen, mit Autor:in und Auftrag), stabil gewordene Wahrheiten steigen in
ein <strong>Whitepaper</strong> auf (mit Decision Records — nachvollziehbare Entscheidungen mit
Begründung und Alternativen), und Langzeit-Kontext wird in einem <strong>LTM-Index</strong>
geführt. Die Kette wird nicht übersprungen: Workpaper → Whitepaper → LTM. Das komplette Repo
(<code>WORKING/</code>) ist offen einsehbar — man kann also sehen, <em>wie</em> das Projekt entsteht.
</p>
<h3>4.3 Benchmark-Protokoll (WH-002, Auszug)</h3>
<p>
Das Benchmark-System definiert eine stabile Level-Achse — die Anzahl der Teilaufgaben und der
Charakter steigen mit dem Level:
</p>
<table>
<tr><th>Level</th><th>Teilaufgaben</th><th>Charakter</th></tr>
<tr><td>L1</td><td>1</td><td>einfache Aufgabe, keine Zerlegung</td></tr>
<tr><td>L2</td><td>2</td><td>minimale Zerlegung</td></tr>
<tr><td>L3</td><td>3</td><td>Standard-Zerlegung</td></tr>
<tr><td>L4</td><td>4</td><td>ein Zwischenergebnis fließt in Teilaufgabe 4 ein</td></tr>
<tr><td>L5</td><td>5</td><td>Zwischenergebnisse + finales Artefakt</td></tr>
<tr><td>L6–L9</td><td>6–9</td><td>Skizze — bei Bedarf ausformulieren</td></tr>
<tr><td>L10</td><td>~10</td><td>kleine App: planen + bauen + HTML-Übersicht (Kern-Proof)</td></tr>
</table>
<p>VRAM-Budget im ≤&nbsp;4-GB-Profil (Ground-Truth: WebLLM-Lib-Metadaten):</p>
<table>
<tr><th>Kombination</th><th>VRAM (≈)</th><th>Passt in ≤ 4096 MB?</th></tr>
<tr><td>Wächter Qwen2.5-0.5B allein</td><td>944,62 MB</td><td><span class="badge ok">✅ ~3,1 GB Reserve</span></td></tr>
<tr><td>Wächter + Planer Llama-3.2-3B</td><td>3208,31 MB</td><td><span class="badge open">⚠ ~0,8 GB Reserve (beobachten!)</span></td></tr>
<tr><td>Wächter + Fallback Qwen2.5-1.5B</td><td>2574,37 MB</td><td><span class="badge ok">✅ ~1,5 GB Reserve</span></td></tr>
<tr><td>7B-Modelle</td><td>&gt; 5100 MB</td><td><span class="badge no">❌ außerhalb des Zielprofils</span></td></tr>
</table>
<p>
Gemessen wird pro Lauf (automatisch in das Gedächtnis geloggt): harter DoD (0/1), Score (0–3),
geplante Teilaufgaben, echte Token-Usage (Prompt/Completion/Total), Zeit, VRAM (geladen + OOM-Events),
Flush-Zyklen und <strong>KERN-Integrität</strong> (nichts nach einem Kontext-Flush verloren —
Invariante). Pass-Regel: <strong>5/5</strong> — und „bewiesen" gilt nur auf dem
<strong>Referenzgerät</strong> (GTX 1050 4&nbsp;GB, Variante zu verifizieren), nicht auf dem
Dev-Gerät (RTX 5090). WebGPU-Determinismus ist nicht garantiert → Läufe werden mehrfach wiederholt
und die Streuung angegeben.
</p>
<h3>4.4 Offene Forschungsfragen (Auswahl)</h3>
<table>
<tr><th>#</th><th>Frage</th><th>Status</th></tr>
<tr><td>1</td><td>Offline nach Setup: Was darf der Service Worker zuverlässig cachen? App-Shell ja; Weights (1–2,5&nbsp;GB) → Quota-/CacheStorage-Verhalten je Browser <em>messen</em></td><td><span class="badge open">offen</span></td></tr>
<tr><td>2</td><td>AAMS-B &amp; Origin: Gedächtnis ist an Browser+Origin gebunden — reicht JSON-Export/Import, oder brauchen wir eine Brücke (OPFS + File-System-Access)?</td><td><span class="badge open">offen</span></td></tr>
<tr><td>3</td><td>WebGPU-Verfügbarkeit: Welche Browser/Devices können es (Chrome/Edge ja; Firefox/Safari zu prüfen)? Capability-Check + saubere Meldung im UI</td><td><span class="badge open">offen</span></td></tr>
<tr><td>4</td><td>Modell-Updates: Wie versionieren wir Weights (Revision pro Modell), wie veralten Caches, wie migrieren Nutzer?</td><td><span class="badge open">offen</span></td></tr>
<tr><td>5</td><td>Browser-Extension (Web-Zugriff-Brücke): sinnvoll nur am selben Gerät — wie verteilen/aktualisieren?</td><td><span class="badge open">offen</span></td></tr>
<tr><td>6</td><td>Sicherheit/Hosting: CSP-Header, keine Secrets in der App, Web-Zugriff nur über geprüfte Brücke (untrusted-Daten-Regel)</td><td><span class="badge open">offen</span></td></tr>
</table>
<h3>4.5 Erweiterungs-Proposal (V1–V5, geprüft)</h3>
<table>
<tr><th>#</th><th>Vorschlag</th><th>Prüfergebnis</th></tr>
<tr><td>V1</td><td>OPFS (Origin Private File System) für größere Kapazität</td><td><span class="badge ok">✅ machbar</span></td></tr>
<tr><td>V2</td><td>Browser-Extension als Web-Zugriff-Brücke (untrusted-Daten-Regel)</td><td><span class="badge ok">✅ optional, zuletzt</span></td></tr>
<tr><td>V3</td><td>Pyodide (Python in der Browser-Sandbox)</td><td><span class="badge ok">✅ erst nach 5/5-Proof</span></td></tr>
<tr><td>V4</td><td>Artefakte: Ergebnisse als echte Dateien</td><td><span class="badge ok">✅ Schritt 1 (HTML) umgesetzt, ZIP folgt</span></td></tr>
<tr><td>V5</td><td>„Hermes-lite" im Pool</td><td><span class="badge open">1–4 ja / 5.5 abgelehnt</span> (kein passendes Modell ≤&nbsp;4&nbsp;GB im Katalog)</td></tr>
</table>
<p>Vorgeschlagene Reihenfolge: V4 → V1 → V5 → V3 → V2 — jede Stufe erst nach menschlicher Freigabe.</p>
<h2 id="probleme">5. Offene Probleme — was es zu lösen gilt</h2>
<p>
Diese Liste ist <strong>bewusst gesondert</strong>: Hier stehen die Probleme, die wir kennen und die
es in Zukunft zu lösen gilt. Bei jedem Punkt steht, <em>warum</em> er wichtig ist und <em>in welche
Richtung</em> wir nach besseren Wegen und besseren Lösungen suchen. Die aktuelle Lösung ist bei
keinem Punkt als final zu verstehen — genau das ist der Punkt der Forschung.
</p>
<table>
<tr><th style="width:26%">Problem</th><th>Warum es wichtig ist</th><th>Bessere Wege / was wir suchen</th></tr>
<tr>
<td><strong>P1 · Offline nach Setup</strong></td>
<td>Ein „lokaler" Agent, der nach dem ersten Start noch Internet braucht, ist nicht souverän. Weights (≈3&nbsp;GB) + Cache-Quota sind je Browser unbekannt</td>
<td>Zuverlässige Cache-Strategie messen (Service Worker, CacheStorage vs. OPFS), selbst gehostete Weights, Update-/Versions-Strategie — pro Browser messen, nicht raten</td>
</tr>
<tr>
<td><strong>P2 · Gedächtnis an Browser+Origin gebunden</strong></td>
<td>Anderes Gerät oder Browser = leeres Gedächtnis. Heute gibt es nur JSON-Export/Import (manuell)</td>
<td>Bessere Portabilität: OPFS + File-System-Access-API, lokale Synchronisations-Konzepte, bessere Import-/Merge-UX — ohne Cloud (Invariante bleibt)</td>
</tr>
<tr>
<td><strong>P3 · WebGPU-Verfügbarkeit</strong></td>
<td>Chrome/Edge ja, Firefox/Safari nein — ein Teil der Nutzer kann das Projekt nicht nutzen</td>
<td>Besserer Capability-Check + ehrliche Meldung im UI; langfristig: Alternativen prüfen (WASM-Runtimes, andere Backends) — als eigene Studie, nicht als Stillstand</td>
</tr>
<tr>
<td><strong>P4 · Modell-Updates &amp; Caches</strong></td>
<td>Neue Quantisierungen/Revisionen: Wie veralten Caches? Wie kommen Nutzer zu besseren Modellen, ohne zu verlieren?</td>
<td>Revisionssystem pro Modell, saubere Cache-Invalidation, Migrations-Pfad — Teil des Benchmark-Protokolls (Reproduzierbarkeit)</td>
</tr>
<tr>
<td><strong>P5 · Kontextfenster (4096 Tokens)</strong></td>
<td>Für größere Aufgaben zu klein; der Tokenwächter muss Kontext flushen — dabei darf nichts verloren gehen (Invariante)</td>
<td>Progressive Disclosure (nur benötigte Kontext-Schnitte), bessere Memory-Kompression/Reflexion, längere Kontexte nur, wenn das VRAM-Profil es hergibt</td>
</tr>
<tr>
<td><strong>P6 · Datei-Output</strong></td>
<td>Nachgewiesene Lücke: eine Website-Aufgabe lief „6/6 erledigt" — aber 0 Dateien. Ein Agent ohne echte Dateien ist unvollständig</td>
<td>Artefakt-Pipeline (V4): HTML (fertig) → ZIP/mehrdateiig → docx/xlsx; File-System-Access für direkten Speicherort-Wunsch</td>
</tr>
<tr>
<td><strong>P7 · Reproduzierbarkeit auf WebGPU</strong></td>
<td>Inferenz ist nicht deterministisch garantiert — Benchmark-Ergebnisse sind nur im Rahmen der Streuung vergleichbar</td>
<td>Besseres Protokoll: mehr Läufe, fixierte Seeds wo möglich, Spannweite ausweisen, „bewiesen" nur auf dem Referenzgerät</td>
</tr>
<tr>
<td><strong>P8 · VRAM auf kleinen GPUs</strong></td>
<td>Wächter + Planer lassen im 4-GB-Profil nur ≈0,8&nbsp;GB Reserve — enger als gedacht</td>
<td>Besseres VRAM-Budget mit Systemreserve, Quantisierungs-Wahl via Capability-Gate (<code>shader-f16</code> → q4f16_1, sonst q4f32_1), Fallback-Pfade</td>
</tr>
<tr>
<td><strong>P9 · Training: Daten &amp; Qualität</strong></td>
<td>Für den Wächter-Spezialisten: Daten-Leckage, Lehrer-Fehler, Lizenzen, Quantisierungs-Verlust — alles kann den Tuning-Nutzen aufzehren</td>
<td>Strikter Split, nur programmatisch geprüfte Daten, lizenzkonforme Lehrermodelle, Vor-/Nach-Messung des Exports (Details in <a href="#waechter">§6</a>)</td>
</tr>
<tr>
<td><strong>P10 · Distribution &amp; Sicherheit</strong></td>
<td>Hosting (CSP, Model-CDN) und die Web-Zugriff-Brücke (Extension) müssen sicher bleiben, ohne die Invariante „keine Secrets in der App" zu brechen</td>
<td>Besseres Hosting-Setup (ggf. selbst gehostetes Weights-CDN), untrusted-Daten-Regel für alles Webseitige, saubere Capability-Grenzen</td>
</tr>
</table>
<div class="warnbox">
<strong>Meta-Regel:</strong> Diese Liste ist lebendig. Ein Problem, das gelöst ist, wandert mit Beleg
(Benchmark/Decision Record) in ein Whitepaper — und verschwindet von dieser Liste. Ein Problem, das
widerlegt wird (z.&nbsp;B. „Training lohnt sich nicht"), ist ein <em>gültiges</em> Ergebnis und wird
ebenfalls dokumentiert.
</div>
<h2 id="waechter">6. Ein eigenes Modell für den Wächter</h2>
<p>
Der Wächter ist die permanent geladene Instanz des Agenten (≈945&nbsp;MB, resident). Er führt die
engen <strong>Protokoll-Aufgaben</strong> aus: Planer-JSON im festen Schema, Tool-Aufruf-JSON,
Skill-Routing und Memory-Zusammenfassungen. Genau deshalb ist er der interessanteste Kandidat für ein
<strong>eigenes, getuntes Modell</strong>.
</p>
<h3>6.1 Der Ansatz</h3>
<ul>
<li>Ein schmales Modell (<strong>0,5–1,5&nbsp;B</strong>), zugeschnitten auf die Protokoll-Aufgaben, das im ≤&nbsp;4-GB-VRAM-Profil läuft.</li>
<li><strong>Hypothese:</strong> Ein getunter Spezialist ist in diesen engen, prüfbaren Aufgaben <em>zuverlässiger</em> als das ungetunte Basismodell — bei gleicher Größe. Er ist ausdrücklich <strong>kein</strong> Generalist.</li>
<li>Stufenplan mit Abbruchkriterien (0–5), jede Stufe endet mit ehrlicher Auswertung — auch bei Abbruch:</li>
</ul>
<table>
<tr><th>Stufe</th><th>Inhalt</th><th>Abbruch / Weiter</th></tr>
<tr><td><strong>0</strong></td><td>Datenerfassung: jeder Lauf loggt Prompts, Antworten, Prüf-Ergebnisse, Versionen als JSONL (kein Training)</td><td>Weiter, sobald Format stabil</td></tr>
<tr><td><strong>1</strong></td><td><strong>Baseline ohne Training:</strong> Prompt-Optimierung + schemabasierte JSON-Ausgabe</td><td><strong>Wenn die Baseline schon ≥ Zielwert → Training überflüssig, Stufen 2+ streichen</strong></td></tr>
<tr><td><strong>2</strong></td><td>Datensatz-Aufbau: Lehrermodell + Filter, strikter Train/Val/Test-Split, Dubletten-Check</td><td>Weiter bei genügend geprüften Beispielen je Task</td></tr>
<tr><td><strong>3</strong></td><td>Erstes Tuning (LoRA/QLoRA) auf 0,5&nbsp;B, ggf. 1,5&nbsp;B</td><td>Abbruch, wenn Val-Metriken nicht besser als Baseline</td></tr>
<tr><td><strong>4</strong></td><td>Export für WebGPU: Adapter zusammenführen, quantisieren, kompilieren, in WebLLM laden</td><td>Abbruch, wenn Export Qualität oder VRAM-Profil bricht</td></tr>
<tr><td><strong>5</strong></td><td>Benchmark-Vergleich Base vs. Tuned im selben Protokoll (WH-002)</td><td>Entscheidung über Aufnahme in den Pool (Decision Record)</td></tr>
</table>
<p>
Messgrößen (Base vs. Tuned, identische Bedingungen): Schema-Validität ohne Retry, Tool-Wahl und
Parameter korrekt, Retry-Rate, harter DoD-Erfolg, Token/Zeit pro Aufgabe, VRAM-Spitze — und
Test-Set-Leistung <em>getrennt</em> von Val-Leistung, damit Überanpassung sichtbar bleibt.
„Besser" heißt: Verbesserung <strong>außerhalb der Streuung</strong> auf dem Test-Split.
</p>
<h3>6.2 Sinnhaftigkeit &amp; erwarteter Nutzen</h3>
<ul>
<li><strong>Höhere Zuverlässigkeit genau dort, wo sie am meisten zählt:</strong> Der Wächter läuft permanent und ist die „Stimme" des Agenten. Wenn er Planer-JSON und Tool-Aufrufe ohne Retry sauber erzeugt, wird der gesamte Loop stabiler.</li>
<li><strong>Weniger Retry = weniger Latenz und weniger Token:</strong> Jede vermiedene Wiederholung spart Zeit und VRAM-Druck — im 4-GB-Profil ein reales Budget.</li>
<li><strong>Prüfbar und begrenzt:</strong> Die Aufgaben sind eng und programmatisch prüfbar (Schema, DoD). Das macht den Nutzen messbar — im Gegensatz zu vagen „bessere Antworten".</li>
<li><strong>Ehrliche Einordnung:</strong> Ein getunter Wächter wird nicht als „intelligent" beschrieben, sondern als „zuverlässig im Protokoll". Er ersetzt keinen Generalisten — er entlastet ihn.</li>
</ul>
<h3>6.3 Die Probleme (bewusst sichtbar)</h3>
<table>
<tr><th>Problem</th><th>Gegenmaßnahme / wie wir es prüfen</th></tr>
<tr><td>Daten-Leckage / Auswendiglernen des Benchmarks</td><td>Strikter Split: Test-Szenarien <em>nie</em> im Training; Dubletten-Check; zurückgehaltene Zusatz-Szenarien</td></tr>
<tr><td>Lehrer-Fehler im Trainingssatz</td><td>Nur programmatisch geprüfte Beispiele (Schema + DoD) — kein Modell bewertet sich selbst</td></tr>
<tr><td>Überanpassung auf das Protokoll, Verlust von Allgemeinwissen</td><td>Aufgabe bewusst eng halten; Generalisten-Leistung wird nicht versprochen (Leitplanke T7)</td></tr>
<tr><td>Quantisierung/Export bricht die Qualität</td><td>Stufe 4 misst vor/nach Export; Abbruchkriterium, wenn das VRAM-Profil oder die Qualität bricht</td></tr>
<tr><td>Lizenzen (Basismodell + Lehrermodell)</td><td>Vor Stufe 2 abschließen: Lizenzen selbst lesen, dokumentieren, abgeleitete Modelle prüfen</td></tr>
<tr><td>„Moving Target": Der Agent verändert sich laufend</td><td>Commit-Hash, Tool-Registry- und Skill-Version in jedem Datensatz festgehalten</td></tr>
<tr><td>Aufwand unterschätzt</td><td>Abbruchkriterien pro Stufe — und Stufe 1 kann den ganzen Plan beenden („Baseline reicht schon")</td></tr>
</table>
<div class="note">
<strong>Status:</strong> Der Plan ist als Research-Plan verfasst (WP-TRAIN-PLAN) und steht zur
Prüfung bereit. Stufe 0 (Datenerfassung) ist noch nicht umgesetzt; jede Stufe beginnt erst nach
menschlicher Freigabe. Es wird nicht trainiert, bevor die Baseline gemessen ist.
</div>
<h2 id="links">7. Links</h2>
<ul>
<li><strong>App (Demo):</strong> <a href="./index.html">Diese App</a> · Space: <a href="https://huggingface.co/spaces/ogerl/webgpu-agent">huggingface.co/spaces/ogerl/webgpu-agent</a></li>
<li><strong>Code (MIT):</strong> <a href="https://github.com/ogerly/webgpu-agent">github.com/ogerly/webgpu-agent</a> — inkl. vollständiger Doku-Kette (<code>WORKING/</code>)</li>
<li><strong>Projekt-Vision (Whitepaper-Quelle):</strong> <code>idee.md</code> im Repository</li>
<li><strong>Beispiel-Projekte des Autors:</strong> <a href="https://github.com/ogerly/AAMS">AAMS</a> · <a href="https://github.com/ogerly/webgpu-arena">webgpu-arena</a></li>
<li><strong>Mitarbeit:</strong> Feedback, Issues und Pull Requests sind willkommen — siehe README des Repositories.</li>
</ul>
</main>
<script>
// Anker-Navigation (WP-APP-DOKU): Ziel-Sektion sanft einscrollen + kurz hervorheben,
// wenn die Seite mit Anker geöffnet wird (Deep-Link aus App/Chat/Foren).
(function () {
const id = window.location.hash.slice(1);
if (!id) return;
const el = document.getElementById(id);
if (!el) return;
requestAnimationFrame(function () {
el.scrollIntoView({ behavior: "smooth", block: "start" });
el.classList.add("hl");
setTimeout(function () { el.classList.remove("hl"); }, 1800);
});
})();
</script>
</body>
</html>