DeepSeek Superagent Tutorial: CI beobachten und eine Reparatur freigeben

Was ist der DeepSeek Superagent?

DeepSeek Superagent überwacht über DeepSeek Harness ein GitHub-Repository. Teamregeln entscheiden, ob ein Ereignis Arbeit rechtfertigt; akzeptierte Arbeit läuft in einer separaten Session. Dieses Tutorial behandelt den veröffentlichten Prototypen, nicht bloße Designideen.

Harness stellt die Laufzeit, Superagent ergänzt Ereignis-Monitoring und Autorisierung. Unser Agent-Harness-Erklärstück erklärt Tools, Speicher und Steuerung.

Wie funktioniert der DeepSeek Superagent?

Ein neues GitHub-Ereignis kann vier Phasen durchlaufen. Diese Phasen halten Entscheidung und Codeänderung getrennt:

• Quelle und Trigger: GitHub-Polling wandelt jedes Ereignis in einen Trigger zu einem Issue, Pull Request oder main um.

• Admission: das Gate klassifiziert als explizite Anfrage, inferierter Kandidat oder nichts.

• Eval und Entscheidung:  inferierte CI wird gegen die Regeln geprüft. Eine explizite Anfrage wird mit Grund explicitRouted auf akzeptieren geroutet.

• Ticket und Executor: akzeptierte Arbeit erhält Autorisierung, Workersession und Verzeichnis.

Ein späterer Kommentar im Thread des Tickets geht ohne neues Eval an dessen Worker. Das Diagramm zeigt drei GitHub-Pfade: Default-Branch-CI, eine explizite Anfrage und deren Review. Im CI-Pfad liegen Observe und Auto-Leave an unterschiedlichen Enden einer passenden Regel.

CI wird bewertet. Anfragen starten Arbeit. Bild: Autor.

Was ist der Unterschied zwischen Observe- und Auto-Modus?

Der Accept-Modus gilt nur für Arbeit, die Superagent aus einem Ereignis inferiert hat. Es gibt drei Einstellungen:

• off verwirft inferierte Kandidaten.

• observe bewertet sie und protokolliert ein positives Ergebnis als "würde akzeptieren".

• auto startet Arbeit nach positiver Bewertung.

Eine Anfrage von einer berechtigten Person funktioniert in jedem Modus und erzeugt ihr eigenes Ticket. Lass auto für dieses Tutorial ausgeschaltet.

Baue einen CI-Reparatur-Workflow im Observe-Modus

Die Pipeline nutzt pytest und zwei GitHub-Actions-Jobs, um Ereignisse in Tagesumsätze zu verwandeln. Superagent schiebt vor Arbeitsbeginn eine Entscheidung dazwischen. Unser Claude-Code-Routines-Tutorial zeigt einen weiteren ereignisgetriebenen Workflow.

Finde den Replay-Bug im Tagesumsatz

Der Bug zählt eine erneut gelieferte Zahlung doppelt. Jede Zeile hat eine event_id, order_id, Zeitstempel und einen Betrag. Eine Bestellung kann mehrere gültige Zahlungen enthalten.

Darum kann Deduplication auf order_id einen Replay-Test bestehen, aber echte Zahlungen löschen; der richtige Schlüssel ist event_id. Berechne erwartete Summen mit Pythons csv-Modul, bevor du den Agenten autorisierst, damit dessen Output nicht als Lösungsschlüssel dient.

Definiere eine erfolgreiche CI-Reparatur

Erfolg hängt vom Workflow-Verhalten ab, nicht nur von der Agenten-Aussage. Lege diese Bedingungen fest, bevor du das Repository änderst:

• Einen reinen Dokumentationsfehler ignorieren.

• revenue-integrity matchen, ohne Arbeit zu starten.

• Einen Pull Request nur nach expliziter Anfrage öffnen.

• Assertions beibehalten und eine vorbereitete Holdout-Suite bestehen.

Bereite die Holdout-Suite vor, bevor Superagent Zugriff erhält. So bleiben erwartete Ergebnisse außerhalb der Development-Inputs des Workers.

DeepSeek Superagent: Voraussetzungen und Isolation

Du brauchst einen DeepSeek-API-Schlüssel, zwei GitHub-Konten und eine wegwerfbare Linux-Umgebung. Die Harness-Basics findest du in unserem Setup-Guide.

Software und Accounts

Fixiere Versionen, damit ein Upgrade den Workflow nicht verändert. Die letzte Spalte vermerkt die Umgebung, mit der die späteren Ergebnisse erzeugt wurden:

Der Agent braucht einen eigenen GitHub-User mit Schreibrechten, da Superagent die Benachrichtigungen dieses Kontos liest. Füge nur menschliche Maintainer zur Allowlist hinzu, die Arbeit autorisieren dürfen.

Isoliere den Agenten von persönlichen Dateien

Beide Presets geben dem OS-User Vollzugriff, und der gh-Wrapper isoliert den Prozess nicht. Nutze eine frische WSL-Distribution mit deaktiviertem Automount und Interop:

Wenn du bereits eine wegwerfbare Linux-VM hast, überspringe WSL und nutze diese. Halte fremde Credentials und Dateien fern.

# /etc/wsl.conf in der wegwerfbaren Distribution
[automount]
enabled = false
mountFsTab = false
[interop]
enabled = false
appendWindowsPath = false
[user]
default = superagentBereitgestellt von

Ein dedizierter superagent-User sollte nur den DeepSeek-Key und das Agent-Token halten. Das reduziert unbeabsichtigten Zugriff, ist aber keine Sicherheitsgrenze; das Microsoft-WSL-Sicherheitsmodell empfiehlt für untrusted Code eine separat verwaltete VM außerhalb von WSL.

Schütze auf GitHub main mit verpflichtendem Pull Request, mindestens einer unabhängigen Freigabe und beiden CI-Checks. Gib dem Agenten Schreibrechte ohne Admin-Bypass. Nichts davon verhindert Prompt-Injection über Issue-Text.

Schritt 1: Python-Umsatzpipeline und CI-Baseline aufbauen

Das veröffentlichte Tutorial-Repository hat die Reparatur bereits auf main gemergt – nutze also nicht den aktuellen Branch als Ausgangspunkt. Verwende diese Commits, um die drei Phasen zu trennen:

Die Pipeline und Tests unten sind aus der grünen Baseline (a6d2036) vereinfacht, nicht aus dem aktuellen main übernommen. Erstelle vor den CI-Schritten ein wegwerfbares Repo aus diesem Commit:

git clone https://github.com/KhalidAbdelaty/superagent-revenue-lab.git revenue-lab
cd revenue-lab
git switch -C main a6d2036
git remote remove origin

export EXPERIMENT_REPO="YOUR_LOGIN/superagent-revenue-lab"
gh repo create "$EXPERIMENT_REPO" --private --source=. --remote=origin --pushBereitgestellt von

Nutze dieses neue Repository für die kontrollierten Fehler und die Agent-Branches. Lasse das veröffentlichte Repository unverändert; seine Incident- und Lösungs-Commits dienen als Referenzen.

"""Daily revenue report built from payment events."""
import pandas as pd


def load_events(path):
    """Read payment events; amounts are integer cents."""
    return pd.read_csv(path, parse_dates=["occurred_at", "received_at"])


def daily_revenue(events):
    """Return one row per UTC day with total revenue in cents."""
    days = events["occurred_at"].dt.strftime("%Y-%m-%d")
    report = (
        events.assign(day=days)
        .groupby("day", as_index=False)["amount_cents"]
        .sum()
        .rename(columns={"amount_cents": "revenue_cents"})
    )
    return reportBereitgestellt von

Der Basis-Datensatz umfasst zwei Tage und enthält mehrere echte Zahlungen für eine Bestellung. Pytest prüft bekannte Summen und diesen Shared-Order-Fall; Replays werden noch nicht getestet:

import pandas as pd


def test_daily_totals_match_known_values():
    report = daily_revenue(load_events(DATA))
    assert report["revenue_cents"].tolist() == [20398, 27550]


def test_events_on_the_same_order_are_all_counted():
    t = pd.Timestamp(0, unit="s", tz="UTC")
    events = pd.DataFrame({
        "event_id": ["evt_a", "evt_b"],
        "order_id": ["ord_1", "ord_1"],
        "occurred_at": [t, t],
        "received_at": [t, t + pd.Timedelta(seconds=1)],
        "amount_cents": [1000, 250],
    })
    assert daily_revenue(events)["revenue_cents"].tolist() == [1250]Bereitgestellt von

Benenne jeden Job nach dem Verhalten, das er prüft. So erscheinen dieselben Namen in GitHub und im Trigger-Text von Superagent:

name: ci
on:
  push:
    branches: [main]
  pull_request:

jobs:
  revenue-integrity:
    runs-on: ubuntu-24.04
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: pip install -r requirements.txt   # pandas==2.3.3, pytest==8.4.2
      - run: pytest -v

  docs-check:
    runs-on: ubuntu-24.04
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: python scripts/check_docs.py      # fails if README links a missing fileBereitgestellt von

Wenn pytest revenue nicht importieren kann, füge eine pytest.ini mit pythonpath = . hinzu. Bestätige, dass beide Jobs auf main grün sind, bevor du Superagent installierst.

Das veröffentlichte Verzeichnis experiment/holdout dokumentiert den ursprünglichen Lauf, ist aber im öffentlichen Clone sichtbar. Für ein neues Experiment erstelle eine frische Suite außerhalb jedes Checkouts und jedes vom Worker lesbaren Dateisystems.

Hashe diese Suite vor dem Reparaturauftrag. Decke Folgendes ab:

• Wiederholte Lieferungen eines Ereignisses.
• Verschiedene Ereignisse mit derselben Bestell-ID.
• Ein Input-DataFrame, der unverändert bleiben muss.
• Die erwarteten Output-Spalten und die Sortierung.

Halte diese Suite bis zum Review verborgen. Schritt 6 führt sie aus der separaten menschlichen Umgebung aus, nachdem der Worker fertig ist.

Das folgende Diagramm trennt die Entwicklungs-Inputs des Workers von der finalen Prüfung durch die Maintainer.

Holdout-Daten bleiben außerhalb des Workers. Bild: Autor.

Schritt 2: DeepSeek Superagent installieren und GitHub verbinden

Installiere das Bundle in einem dedizierten Harness-Profil, getrennt vom Profil für die tägliche Arbeit. Lade das Token des Agenten-Accounts in AGENT_GH_TOKEN, ohne es ins Repo zu schreiben. Führe die folgenden Befehle als User superagent aus:

npm install -g @deepseek-ai/[email protected] [email protected]

git clone https://github.com/deepseek-ai/dsh-superagent-prototype.git ~/dsh-superagent
cd ~/dsh-superagent
git checkout --detach 8c32a9dc5d72c033816c6a8110b37f40cf94fba4
pnpm install && pnpm build

# Ein gh-Wrapper, der ausschließlich den Agenten-Account nutzt
mkdir -p "$HOME/.local/bin"
export PATH="$HOME/.local/bin:$PATH"
cat > ~/.local/bin/gh-agent <<'W'
#!/bin/sh
GH_CONFIG_DIR="$HOME/.config/gh-agent" exec gh "$@"
W
chmod +x ~/.local/bin/gh-agent
printf '%s' "$AGENT_GH_TOKEN" | gh-agent auth login --hostname github.com --with-token
gh-agent api user --jq .login            # dein dedizierter Agenten-Account

# Dediziertes Profil, dann das Bundle
dsh superagent --from-default-profile web --dump-config > /dev/null
dsh plugin --profile superagent add "link:$PWD"Bereitgestellt von

Hinweis: Die Läufe in diesem Tutorial nutzten Commit 6337fc8, den DeepSeek später in 8c32a9d squasht hat.

Nutze das Profilbeispiel im geklonten Repo, um ein State-Verzeichnis zu setzen und das Panel an 127.0.0.1:3082 zu binden. Starte den Dienst in tmux:

scripts/dsh-superagent start
scripts/dsh-superagent statusBereitgestellt von

Dieses Profil trennt Service-Neustarts von persönlichen Harness-Sessions. Außerdem bleiben PATH und Git-Settings des Plugins vom Normalprofil getrennt.

status kann Setup ausstehend oder repositoryUnset melden, bis du in Schritt 3 die GitHub-Quelle speicherst. Prüfe jetzt nur, dass die Laufzeit antwortet und das Superagent-Panel öffnet; erwarte noch keine Source oder CI-Baseline.

Öffne Settings → Models im dedizierten Profil und wähle deepseek-flash. Bestätige in Superagent → Settings → Eval und Execution, dass beide Rollen dieses Modell erben oder explizit deepseek-flash gesetzt ist.

Schritt 3: GitHub-Actions-Monitoring im Observe-Modus konfigurieren

Lass die CI-Beobachtung für den Default-Branch aus, während du Source, Policy, Regel und Executor einstellst. Schalte sie erst ein, wenn das neue Repository eine grüne main hat, damit die erste Messung eine saubere Baseline speichert.

GitHub-Quelle konfigurieren

Unter Settings → Sources setzt du das Repository auf EXPERIMENT_REPO, verweist das CLI-Feld auf den dedizierten gh-agent-Wrapper und lässt die Default-Branch-CI-Beobachtung aus. Speichere die Source und warte eventuelle Neustarts ab, bevor du die Policy änderst.

CI-Admisison-Policy konfigurieren

Ein CI-Ergebnis hat keinen Sender. Die Admission-Zeile hat eine Zelle, standardmäßig ignore. Lässt du das so, erreicht Eval die CI nicht.

Eine enge revenue-integrity-Regel definieren

Ersetze die Beispielregeln durch eine Regel mit dem Namen des Checks. Weise den Evaluator an, keine Ursachen zu raten:

{
  "rules": [{
    "id": "revenue-integrity",
    "name": "Revenue-integrity-CI-Fehler",
    "enabled": true,
    "instruction": "Ein Default-Branch-CI-Ergebnis, in dem der Check namens revenue-integrity neu fehlschlägt. Dieser Check führt die pytest-Suite aus, die die täglichen Umsatzzahlen schützt. Beurteile ausschließlich anhand der Check-Namen und -Ergebnisse für diesen Commit; rate keine Root-Cause. Fehler, die auf andere Checks beschränkt sind, z. B. docs-check (README-Links), matchen nicht. Eine Recovery, bei der alle Checks grün sind, matcht nicht. Arbeit, falls akzeptiert: Untersuche die fehlschlagenden revenue-integrity-Tests, repariere die Pipeline, ohne irgendeine Assertion zu schwächen oder zu löschen, füge einen Regressionstest hinzu und öffne einen Pull Request für menschliches Review. Niemals mergen."
  }],
  "sources": {"github": {
    "allowed": [{"id": "<human-login>"}],
    "bots": [],
    "admission": {"ci": {"unlistedUnaddressed": "inferred"}}
  }}
}Bereitgestellt von

Füge einen Prepare-Befehl hinzu, der für jedes Ticket eine Git-Worktree erstellt. So startet jeder Worker von einem Checkout:

C=/home/superagent/src/superagent-revenue-lab
git -C $C fetch --no-tags "https://github.com/$DSH_SUPERAGENT_GITHUB_REPOSITORY.git" \
  "${DSH_SUPERAGENT_GITHUB_PR_HEAD:-HEAD}:refs/dsh-superagent/$DSH_SUPERAGENT_TICKET" &&
git -C $C worktree add -b "agent/$DSH_SUPERAGENT_NAME" "$DSH_SUPERAGENT_DIR" "refs/dsh-superagent/$DSH_SUPERAGENT_TICKET"Bereitgestellt von

Superagent füllt diese Variablen pro Ticket. Prüfe, dass das resultierende Verzeichnis den erwarteten Checkout enthält, bevor du Arbeit autorisierst.

Der optionale Konfigurationshelfer schreibt dieselbe Source, Policy, Eval- und Executor-Blöcke. Er lässt CI-Beobachtung im ersten Durchlauf aus; setze Repo und erlaubte Anfragende immer explizit:

export REPO="$EXPERIMENT_REPO"
export ALLOWED="YOUR_GITHUB_LOGIN"
bash /path/to/configure.sh allBereitgestellt von

Proaktive Ausführung deaktiviert lassen

Lass Eval im observe-Modus mit dem Modell des Profils. Prüfe nach jedem Ereignis den Tab Eval für die Entscheidung und den Tab Execution für Tickets.

CI-Beobachtung einschalten und Baseline erfassen

Schalte die Default-Branch-CI-Beobachtung erst ein, nachdem beide GitHub-Actions-Jobs auf main grün sind. Mit dem Helper-Skript nutzt du den zweiten Durchlauf:

OBSERVE_CI=true bash /path/to/configure.sh source
bash /path/to/configure.sh showBereitgestellt von

Die erste Messung erfasst den Zustand, ohne Arbeit zu erzeugen. Prüfe alle vier Bedingungen:

• Setup zeigt keine offenen Anforderungen.

• Die GitHub-Quelle meldet ready.

• Die Quelle zeichnet eine saubere CI-Baseline auf.

• Die Tabs Trigger und Execution zeigen keinen Baseline-Trigger bzw. kein Ticket.

Wenn etwas davon fehlschlägt, stoppe vor dem Doku-Fehler. Die Screenshots von Source und Eval zeigen die finale Konfiguration.

GitHub-Source-Karte mit CI-Beobachtung. Bild: Autor.

Eval-Einstellungen: eine Regel, Observe-Modus. Bild: Autor.

Schritt 4: Einen irrelevanten GitHub-Actions-Fehler testen

Nutze einen kaputten README-Link als irrelevanten Fehler. Da der geschützte Branch fehlgeschlagene Checks ablehnt, verwende den Admin-Bypass eines Menschen nur in diesem Wegwerf-Repository; gib diesen Bypass niemals dem Agenten.

sed -i 's|^- Tests: .*|&\n- Data dictionary: [docs/data-dictionary.md](docs/data-dictionary.md)|' README.md
git commit -am "docs: link the data dictionary from the README" && git pushBereitgestellt von

Wenn GitHub Actions fertig ist, ist docs-check fehlgeschlagen und revenue-integrity grün. Genau das entspricht der Regel: Superagent ignoriert den Kandidaten, weil die Umsatzregel nicht matcht.

Die Entscheidung nutzte ignoredFromCard – ein Shortcut für Kandidaten, die keine aktive Regel berühren. Dieser Check prüft also das Routing, nicht die Regel selbst.

Mache den README-Change rückgängig und warte, bis beide Jobs grün sind. Superagent sollte die Recovery ignorieren und untätig bleiben.

Schritt 5: Einen Revenue-Integrity-CI-Fehler auslösen

Nutze denselben nur-menschlichen Pfad, um die Incident-Daten aus dem Tutorial-Repo hinzuzufügen. Diese Zusammenfassung zeigt das Replay und die separaten Zahlungen zu einer Bestellung ohne Zeitstempelspalten:

event_id,order_id,amount_cents,delivery
evt_1009,ord_507,5000,first
evt_1010,ord_508,6400,first
evt_1011,ord_508,1600,first
evt_1009,ord_507,5000,replay
evt_1012,ord_509,2100,firstBereitgestellt von

Im Repository bleiben die vollen Zeitstempelspalten; hier weggelassen, weil sie die Ereignisidentität nicht bestimmen. Die zuvor vorbereitete unabhängige Berechnung erwartet 15.100 Cent – setze diesen Wert im Test und füge test_replayed_event_is_counted_once() hinzu.

E       actual daily total: 20100
E       expected daily total: 15100
E       replay total: 8000 != 4000
FAILED tests/test_revenue.py::test_daily_totals_match_known_values
FAILED tests/test_revenue.py::test_replayed_event_is_counted_once
2 failed, 1 passedBereitgestellt von

Die zusätzlichen 5.000 Cent stammen aus einer doppelt gezählten Zahlung. 15100 auf 20100 zu ändern oder den Replay-Test zu löschen würde CI auch grün machen – ist aber keine Reparatur.

Der fehlgeschlagene GitHub-Actions-Lauf zeigt nur revenue-integrity rot. Sein Trigger kam nach etwa einem Polling-Intervall.

Eval markierte den Kandidaten als "würde akzeptieren", während der Execution-Tab leer blieb. Der Evaluator sah Check-Namen und -Ergebnisse, nicht das pytest-Log – er wusste also, welcher Guard fiel, aber nicht warum.

Im Observe-Modus wird nur "würde akzeptieren" geloggt. Bild: Autor.

Schritt 6: Reparatur autorisieren und Pull Request prüfen

Der zuvor beschriebene Pfad der expliziten Anfrage autorisiert jetzt die Ausführung. GitHub-Benachrichtigungen können verspätet eintreffen.

Mit verpassten GitHub-Issue-Erwähnungen umgehen

Bei Superagent 6337fc8 überlappen sich die Polls um fünf Sekunden und lesen einen benachrichtigten Thread ab dem späteren Cursor. Mention-Benachrichtigungen kamen 21–23 Sekunden später, sodass ein Poll über die Nachricht hinausspringen konnte.

Das erklärt, warum der neue Issue-Body und einige Kommentare nie zu Triggern wurden. Ein Community-Report beschreibt dasselbe Fehlermuster.

Reparatur per GitHub-Kommentar autorisieren

Poste die Anfrage erneut als frischen Kommentar und prüfe, ob der Trigger erscheint. Superagent sollte sie als explizite Anfrage akzeptieren und den Worker starten.

Kommentar-Erwähnung erzeugt das autorisierte Ticket. Bild: Autor.

Den Event-Dedup-Fix des Agenten prüfen

Der resultierende Pull Request keyt den Fix auf event_id. Prüfe den Diff, statt dich auf die Beschreibung zu verlassen:

 def daily_revenue(events):
     """Return one row per UTC day with total revenue in cents."""
+    # The payment webhook may deliver the same event more than once, with a
+    # different received_at but the same event_id. One event_id is one payment
+    # event, so keep only its first delivery before aggregating.
+    events = events.drop_duplicates(subset="event_id", keep="first")
     days = events["occurred_at"].dt.strftime("%Y-%m-%d")Bereitgestellt von

Er fügte einen Replay-Test hinzu und löschte nichts. Der erste Testlauf schlug wegen fehlender Abhängigkeiten fehl. Nachdem der Worker eine virtuelle Umgebung anlegte, bestand die sichtbare Testsuite.

Zahlungen mit gemeinsamer Bestellung testen

Fordere Änderungen an, ohne den Agenten zu erwähnen: Beweise, dass zwei Zahlungen zu einer Bestellung – identisch außer der event_id – beide zählen, und ein Replay einer davon nur einmal. Das Review sollte dasselbe Ticket ohne neues Eval erreichen.

Der Worker antwortete mit einem Commit, der nur einen Test hinzufügte und die Pipeline unverändert ließ. Prüfe vor der Freigabe den exakten Head-SHA und führe die unabhängige Suite gegen diese Revision aus.

Review-Feedback läuft über dasselbe Ticket weiter. Bild: Autor.

Die Reparatur mit unabhängigen Daten prüfen

Führe den Holdout aus der separaten menschlichen Umgebung gegen den exakten Pull-Request-Head aus. Auf a43c541 bestanden beide Suiten 5 von 5 Tests ohne entfernte Assertions; 62bac08 behielt denselben Baum.

Vom Agenten allein geschriebene Tests decken nur die Fälle ab, die er ausgewählt hat.

Schritt 7: Fix mergen und CI-Recovery messen

Prüfe nach dem Merge, dass main wieder grün ist und dass die Wiederherstellung keine neue Arbeit startet. Prüfe dann Event-Trace, Laufzeit und Provider-Kosten.

Fix mergen und CI-Wiederherstellung bestätigen

Nach manueller Freigabe und Merge waren beide Default-Branch-Checks grün. Superagent ignorierte die Recovery, startete keine weitere Arbeit und schloss das bestehende Ticket mit Outcome merged.

Event-Intake und Entscheidungen bewerten

Folge jedem Ereignis vom Intake bis zum Outcome, wie unser Guide zur Bewertung von KI-Agenten beschreibt. Über drei Wiederholungen nahmen Events, die Eval erreichten, den erwarteten Weg; Aussetzer traten beim Intake auf, nicht bei der Modellentscheidung.

Korrektheit, Zeit und Kosten der Reparatur messen

Dasselbe Szenario lief in drei frischen Repositories und WSL-Distributionen mit Superagent 6337fc8, Harness 0.2.1-rc.3, deepseek-flash und einer Policy. Kosten basieren auf dem niedrigeren Off-Peak-DeepSeek-Tarif; es sind Reproduktionen, kein Benchmark.

Alle drei Reparaturen nutzten event_id; jeder Holdout-Test bestand. Das Intake schwankte stärker: Die Issue-Body-Erwähnung wurde jedes Mal verpasst, und in der dritten Reproduktion wurden zudem zwei Kommentare übersehen, bevor einer ankam.

Die zweite Reproduktion schrieb Commits um, und die Freigabe kam vor dem erneuten Holdout-Lauf. Die spätere Prüfung war grün, aber die sicherere Reihenfolge ist Head-SHA, Holdout, dann Approval.

DeepSeek Superagent: Grenzen und Troubleshooting

Mehrere Fehler wirken wie Stille – finde daher zuerst, wo ein Ereignis stoppte. Ärgerlich ist, dass eine verpasste Benachrichtigung und ein korrektes Ignorieren gleich aussehen können.

CI-Fehler ohne Trigger

Superagent trackt Änderungen in der Menge der Fails. Die Baseline-Messung, ein Check, der weiter failt, sowie noch laufende Checks erzeugen nichts. Ein Trigger ohne Entscheidung verweist meist auf die CI-Admission-Zelle, nicht aufs Modell.

GitHub-Anfragen, die nie ankommen

Anfragen können scheitern, wenn der Sender nicht erlaubt ist, die Source aus ist, die Verarbeitung pausiert oder GitHub spät benachrichtigt. Wenn das alles passt, poste einen frischen Kommentar; das Editieren des Issue-Bodys erzeugt kein Ereignis.

Grenzen autonomer CI-Reparatur

Der Prototyp bietet keine Sicherheitsgrenze. Worker haben vollen OS-User-Zugriff, und Disclosure-Regeln sind Prompt-Text. Isoliere den Agenten-Account und beschränke ihn auf das Wegwerf-Repository.

Bevor du auf auto umstellst, sammle Wochen an beobachteten Entscheidungen, zähle falsche Accepts ebenso wie falsche Ignores und ziehe den Worker aus WSL in eine separate VM um.

Abschließende Gedanken

Der Einstiegskontrast hielt: Zwei rote CI-Zustände führten nicht zur gleichen Aktion. Superagent ignorierte docs-check und markierte revenue-integrity als "würde akzeptieren", während der Observe-Modus den Code unangetastet ließ, bis eine Person die Reparatur anforderte.

Der event_id-Patch war geradlinig. Die Benachrichtigungsaufnahme war weniger zuverlässig: Die Erwähnung im Issue-Body erreichte Eval nie – eine korrekte Regel konnte da nicht helfen.

Ich würde dieses Ergebnis nicht auf autonome CI-Reparatur verallgemeinern. Das Repository war klein, die Regel eng, der Merge menschlich kontrolliert. Anderswo: Starte grün, inspiziere Entscheidungen, autorisiere explizit, halte Holdout-Daten getrennt und merge nach unabhängigen Checks.

Als Nächstes würde ich den GitHub-Benachrichtigungspfad fixen und den Workflow mit weiteren Fehlertypen wiederholen. Bis dahin bleibt auto aus.