DevSprint Copilot: ein Tool-Loop-Agent mit menschlich freigegebenen Schreibzugriffen und beidseitiger MCP-Anbindung

Das Problem

Ich wollte ein Projekt, das Agent-Architektur zeigt (Tool-Design, Human-in-the-Loop-Freigabe, Streaming-UI, MCP-Interoperabilität), und zwar für Reviewer, die schon hundert dünne Chat-Wrapper-Demos gesehen haben. DevSprint Copilot ist ein Projekt- und DevOps-Copilot, der einen simulierten Workspace für die Softwareauslieferung per Chat bedient: fragen, wie der Sprint läuft, Issues schließen, Release Notes entwerfen, ein simuliertes Deployment anstoßen und dabei zusehen, wie die Änderungen im Board-Bereich neben dem Gespräch erscheinen.

Der Workspace ist bewusst künstlich und bewusst deterministisch: ein Projekt, zwei Sprints, 13 Issues auf einem Board mit fünf Spalten, vier Nutzer, fünf Deployments, alles aus Fixtures geseedet, mit eingefrorener Demo-Uhr (WORKSPACE_NOW = 2026-07-01T09:00:00Z). Das ist keine Abkürzung, sondern die Eval-Strategie. Wenn sich der Seed nie ändert, sind „DS-11 ist blockiert“ und „8 von 31 Punkten erledigt“ exakte Aussagen, und dieselben sechs Skript-Szenarien können als Abnahmespezifikation, als Trajektorien-Eval-Suite und als Playwright-E2E-Spezifikation dienen, ohne neu interpretiert zu werden.

Architektur

Das Frontend ist eine Vue-3.5-SPA auf Vite 8 (Rolldown) mit zwei Bereichen: links das Workspace-Board, rechts der Chat. Das Backend ist Hono auf Cloudflare Workers und betreibt den ToolLoopAgent des AI SDK v6 vollständig serverseitig. Modell-Keys liegen ausschließlich in den Env-Variablen des Workers, und der Browser spricht nie mit einem Modellanbieter. Gemeinsame Typen, Routen-Konstanten und das Fixture-Set liegen in einem Workspace-Paket, das beide Seiten importieren.

Der Agent bekommt genau elf Tools, vorab inventarisiert mit Zod-Eingabeschemata und einem gemeinsamen Ergebnis-Envelope ({ ok: true, data } | { ok: false, error }). Die Tools sind nach Risiko klassifiziert: Lese- und Abfrage-Tools laufen unbeaufsichtigt; datenreiche Tools speisen Generative-UI-Karten (Burndown-Chart, Diff der Release Notes); jeder Schreibzugriff liegt hinter einer Freigabekarte im Stream, eine Freigabe pro Schreibzugriff; ein Klick auf „Alle freigeben“ beantwortet eine Gruppe von Karten über denselben Weg wie jede einzelne (ADR-0023). Der Klick des Nutzers ist nur ein Bedienschritt in der Oberfläche; der Worker validiert die Tool-Eingabe erneut und bewertet die Freigabe-Policy neu, bevor er ausführt, denn ein vom Client gelieferter Nachrichtenverlauf könnte sonst eine Freigabe vortäuschen, die nie stattgefunden hat.

Der Weg zu MCP war bewusst gestaffelt (siehe Entscheidungsprotokoll weiter unten). In den Phasen 3–5 liefen alle zehn Tools als schlichte Funktionsaufrufe im API-Worker; Phase 6 hat die vier Issue-Tools (fünf, seit assign_issue dazukam) hinter einen eigenen MCP-Server auf Workers gezogen, öffentlich über Streamable HTTP für externe Hosts wie Claude Desktop erreichbar, und das Backend nutzt ihn selbst als MCP-Client. Ein System steht auf beiden Seiten des Protokolls, und genau das ist das Unterscheidungsmerkmal. Erst der transportunabhängige Ergebnis-Envelope hat diesen Schritt zu einem Refactoring statt zu einer Neuentwicklung gemacht. Das Diagramm zeigt die gebaute Topologie: Die gestrichelten Server für Deployments und Analytics wurden nie gebaut, daher bleiben diese sechs Tools schlichte Funktionsaufrufe im API-Worker.

Aufbau der Evals

Veröffentlicht ist noch keine Zahl; jede Zeile in der Metriktabelle oben ist ausstehend, und ich zeige lieber eine leere Tabelle als eine erfundene. Was existiert, ist das Harness, samt einer ehrlichen Antwort darauf, was es belegen kann und was nicht.

Die Einheit der Evals ist die Trajektorie, nicht die Antwort. Ein plausibler Absatz über den Zustand des Sprints ist wertlos, wenn der Agent get_sprint_status nie aufgerufen hat; die interessanten Fehlerfälle sind falsche Tool-Reihenfolge, übersprungene Gates und halluzinierte Argumente. Deshalb bringt jedes der sechs Demo-Szenarien wörtliche Eval-Assertions mit. Für Szenario S-A heißt das: Die Tools werden in genau der Reihenfolge get_sprint_status → list_issues → diff_release_notes → create_release_notes aufgerufen, und create_release_notes wird nie ohne vorherige Freigabeantwort ausgeführt. Diese Blöcke wurden in Phase 10 1:1 in Eval-Prüfungen übertragen und in Phase 13 in Playwright-Erwartungen, ohne Neuinterpretation; jeder Browser-Test prüft DOM, UI-Stream und Durable Object (ADR-0018).

Das Harness kam in Phase 10 zusammen mit der Observability: OTLP-Traces nach Langfuse, exportiert ohne OpenTelemetry-SDK. Es spielt jedes Szenario gegen ein geskriptetes Mock-Modell durch, deterministisch und kostenlos; das belegt, dass die Anwendung jede Trajektorie einhält, nicht, dass ein echtes Modell sie hervorbringt. Bis zum 21. Oktober 2026 lief es in der CI, seitdem läuft es lokal mit pnpm ci:local. Läufe mit echten Modellen funktionieren seit dem 22. Oktober 2026: Bevor die Demo auf ein echtes Modell umstieg, liefen die sechs Szenarien gegen Groq und Gemini, und das brachte sechs Probleme zutage, die das Mock-Modell verdeckt hatte, von zwei eingestellten Modellen bis zu einer Tool-Beschreibung, die ihrem Szenario widersprach (ADR-0021). Die Evals haben jetzt zwei Stufen: Jedes Modell muss die Bedeutung jedes Szenarios treffen, und das Mock-Modell muss zusätzlich seine exakten Sätze liefern. Ein Lauf mit einem echten Modell ist eine Stichprobe auf Free Tiers, ein Qualitätssignal auf Abruf und nie ein CI-Gate. Der deterministische Seed hält das alles günstig: Ein LLM-as-Judge ist nicht nötig, wenn die erwarteten Tool-Aufrufe und Workspace-Zustände exakt feststehen.

Kosten und Latenz als Entwurfsvorgaben

Das Produkt-Briefing setzt ein hartes Budget: höchstens 5 EUR/Monat Betriebskosten, Ziel 0. Das ist eine Entwurfsvorgabe, keine Messung. Sie hat das Modell-Routing direkt geprägt. Groq ist das Primärmodell, inzwischen openai/gpt-oss-120b, dessen Free Tier 8.000 Tokens pro Minute erlaubt, während eine Agent-Runde etwa 2.000 verbraucht; und ein globales Tageslimit für Tokens wirkt als Kill-Switch, der die Anwendung in einen bewusst gestalteten Zustand „Demo-Budget erreicht“ überführt, statt mitten im Gespräch Anbieterfehler durchzureichen. Seit dem 22. Oktober 2026 antwortet die deployte Demo mit einem echten Modell. Der Free Tier ist ihre Kapazitätsgrenze, und seit dem 2. November 2026 gibt es kein zweites Modell mehr (ADR-0026): Eine Ablehnung wegen des Minutenlimits wird bis zu etwa 14 Sekunden abgewartet, alles Längere beendet die Runde mit einem Fehler.

Latenz wird in diesem Stadium strukturell statt numerisch behandelt: Alles streamt. Der Meilenstein von Phase 2 war Token-für-Token-Streaming vom Worker zur SPA, bevor überhaupt ein Modell beteiligt war; wenn die ersten echten Tokens ankommen, ist die Streaming-Strecke also bereits erprobt. Auf der Live-Site erreichte Lighthouse in allen vier Kategorien 100, mobil und am Desktop (Roadmap, Phase 14); die Barrierefreiheit prüft stattdessen axe über fünf UI-Zustände in beiden Themes, und axe fand drei WCAG-AA-Verstöße, die die 100 verdeckt hatte (ADR-0017). Das Tracing aus Phase 10, das Time-to-First-Token und Kosten pro Runde liefern würde, ist gebaut; der deployte Worker hat seit dem 22. Oktober 2026 ein echtes Modell, sendet aber noch keine Traces, daher ist keiner der beiden Werte festgehalten.

Was gebaut ist, was als Nächstes kommt

Gebaut sind heute die Phasen 0–14 der 16-phasigen Roadmap. Der Agent läuft: Der ToolLoopAgent des AI SDK v6 verkettet die elf Tools innerhalb eines Budgets von sechs Schritten, die sechs Lese- und Rich-Data-Tools unbeaufsichtigt, jeden Schreibzugriff hinter einer Freigabe im Stream, die signiert, nur einmal gültig und serverseitig erneut geprüft ist, mit „Alle freigeben“ für eine Gruppe von Karten und einem Rückgängig auf jedem angewendeten Board-Schreibzugriff. Die fünf Issue-Tools stellt ein öffentlicher MCP-Server über Streamable HTTP bereit, den die App über ihren eigenen MCP-Client nutzt. Ein lang laufendes Deploy-Tool streamt seinen Fortschritt und lässt sich mitten im Lauf abbrechen; ein täglicher Alarm setzt das Board zurück; jeder Schritt lässt sich über OTLP nach Langfuse tracen (auf der deployten Demo sind keine Keys gesetzt); und drei Kostenbremsen schützen die Demo, ein Rate Limit pro IP, ein Tagesanteil pro Client und eine tägliche Token-Obergrenze, dazu eine klar formulierte Haltung zu Prompt Injection. Seit dem 21. Oktober 2026 laufen drei Worker auf Cloudflare: die SPA, die API und der öffentliche MCP-Server. Seit dem 22. Oktober 2026 antwortet die Demo mit einem echten Modell, seit dem 2. November 2026 ist Groq openai/gpt-oss-120b das einzige.

Was nicht belegt ist: Die Assertions der sechs Demo-Szenarien laufen als Trajektorien-Evals gegen ein geskriptetes Mock-Modell, und die Browser-Tests steuern dasselbe Mock-Modell. Das belegt, dass die Anwendung jede Trajektorie einhält. Die Läufe mit echten Modellen sind Stichproben: In der Produktionskonfiguration bestanden am 22. Oktober 2026 7 von 9 Fällen, jeder Fehlschlag ein Anbieter, der eine Anfrage ablehnte; eine Quote wird daher nicht veröffentlicht. Modellkosten und Latenz der Live-Demo sind nicht festgehalten. Als Nächstes: das Demo-Video, der letzte offene Teil von Phase 15.