DeepSeek Superagent – samouczek: obserwuj CI i autoryzuj poprawkę

Czym jest DeepSeek Superagent?

DeepSeek Superagent obserwuje jedno repozytorium GitHub przez DeepSeek Harness. Reguły zespołu decydują, czy zdarzenie zasługuje na pracę; zaakceptowana praca trafia do osobnej sesji. Ten samouczek dotyczy opublikowanego prototypu, a nie koncepcji projektowych.

Harness dostarcza środowisko uruchomieniowe; Superagent dodaje monitorowanie zdarzeń i autoryzację. Nasz artykuł wyjaśniający agent harness omawia narzędzia, pamięć i kontrolę.

Jak działa DeepSeek Superagent?

Nowe zdarzenie z GitHuba może przejść przez cztery etapy. Te etapy oddzielają decyzję od zmiany w kodzie:

• Źródło i Trigger: odpytywanie GitHuba zamienia każde zdarzenie w Trigger w Issue, pull requeście lub na main.

• Admission: wrotka oznacza je jako wyraźną prośbę, kandydata wnioskowanego lub nic.

• Eval i decyzja:  wnioskowane CI jest oceniane względem reguł. Wyraźna prośba trafia do decyzji accept, powód explicitRouted.

• Ticket i Executor: zaakceptowana praca dostaje autoryzację, sesję roboczą i katalog.

Późniejszy komentarz w wątku Ticketu trafia do jego workera bez nowego Eval. Diagram pokazuje trzy ścieżki GitHuba: CI gałęzi domyślnej, wyraźną prośbę i jej recenzję. W ścieżce CI observe i auto pozostawiają dopasowaną regułę na różnych etapach.

CI jest oceniane. Prośby uruchamiają pracę. Obraz: autor.

Czym różni się tryb observe od auto?

Tryb accept dotyczy tylko pracy, którą Superagent wywnioskował ze zdarzenia. Wybierz jedno z trzech ustawień:

• off odrzuca kandydatów wnioskowanych.

• observe ocenia ich, ale pozytywny wynik zapisuje jako „would accept”.

• auto rozpoczyna pracę po pozytywnej ocenie.

Prośba od dozwolonej osoby działa w każdym trybie i tworzy własny Ticket. Pozostaw auto wyłączone w tym samouczku.

Zbuduj workflow naprawy CI w trybie observe

Pipeline używa pytesta i dwóch jobów GitHub Actions, aby przekształcać zdarzenia w dzienne przychody. Superagent wstawia decyzję przed startem pracy. Nasz samouczek Claude Code Routines opisuje inny workflow zdarzeniowy.

Wytrop błąd replay w dziennych przychodach

Błąd podwójnie liczy powtórzoną płatność. Każdy wiersz ma event_id, order_id, znaczniki czasu i kwotę. Jedno zamówienie może mieć kilka prawidłowych płatności.

Dlatego deduplikacja po order_id może przejść test replay, ale usunąć prawdziwe płatności; właściwym kluczem jest event_id. Oblicz oczekiwane sumy modułem csv w Pythonie przed autoryzacją agenta, aby wynik agenta nie był kluczem odpowiedzi.

Zdefiniuj udaną naprawę CI

Sukces zależy od tego, co robi workflow, nie tylko co mówi agent. Ustal te warunki przed zmianą repozytorium:

• Ignoruj błąd wyłącznie w dokumentacji.

• Dopasuj revenue-integrity bez rozpoczynania pracy.

• Otwórz pull request dopiero po wyraźnej prośbie.

• Zachowaj asercje i przejdź wstępnie przygotowany zestaw holdout.

Przygotuj zestaw holdout zanim Superagent uzyska dostęp. Trzyma to oczekiwane zachowanie poza danymi wejściowymi środowiska deweloperskiego workera.

Wymagania i izolacja DeepSeek Superagent

Potrzebujesz klucza API DeepSeek, dwóch kont GitHub i jednorazowego środowiska Linux. Podstawy Harness znajdziesz w naszym podstawowym przewodniku konfiguracji.

Oprogramowanie i konta, których potrzebujesz

Przypnij wersje oprogramowania, aby aktualizacja nie zmieniła workflow. Ostatnia kolumna zapisuje konfigurację używaną do wyników później w artykule:

Agent potrzebuje własnego użytkownika GitHub z prawami zapisu, ponieważ Superagent czyta powiadomienia tego konta. Do listy dozwolonych dodaj tylko ludzkich maintainerów, którzy mogą autoryzować pracę.

Odizoluj agenta od plików osobistych

Oba presety dają użytkownikowi systemu operacyjnego (OS) pełny dostęp, a wrapper gh nie izoluje procesu. Użyj świeżej dystrybucji WSL z wyłączonym automount i interop:

Jeśli masz już jednorazową maszynę wirtualną z Linuxem, pomiń blok WSL i użyj tej maszyny. Trzymaj z dala od niej niepowiązane poświadczenia i pliki.

# /etc/wsl.conf inside the disposable distribution
[automount]
enabled = false
mountFsTab = false
[interop]
enabled = false
appendWindowsPath = false
[user]
default = superagentObsługiwane przez

Dedykowany użytkownik superagent powinien przechowywać tylko klucz DeepSeek i token agenta. Zmniejsza to przypadkowy dostęp, ale nie stanowi granicy bezpieczeństwa; model bezpieczeństwa WSL firmy Microsoft zaleca oddzielnie zarządzaną maszynę wirtualną poza WSL dla nieufnego kodu.

Na GitHubie chroń main wymaganym pull requestem, co najmniej jedną niezależną akceptacją i oboma checkami CI. Daj agentowi prawa zapisu bez obejścia administratora. Nic z tego nie zapobiega wstrzyknięciu promptu przez treść Issue.

Krok 1: Zbuduj pipeline przychodów w Pythonie i bazę CI

Opublikowane repozytorium z samouczkiem ma już scaloną naprawę na main, więc nie używaj jego aktualnej gałęzi jako stanu początkowego. Użyj tych commitów, aby rozdzielić trzy etapy:

Pipeline i testy poniżej są uproszczone względem zielonej bazy (a6d2036), a nie zaczerpnięte z obecnego main. Utwórz jednorazowe repozytorium z tego commitu, zanim przejdziesz do kroków CI:

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 --pushObsługiwane przez

Użyj tego nowego repozytorium do kontrolowanych awarii i gałęzi agenta. Zostaw opublikowane repozytorium bez zmian; jego commit z incydentem i rozwiązaniem służą do porównania.

"""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 reportObsługiwane przez

Zestaw bazowy obejmuje dwa dni i zawiera wiele prawdziwych płatności dla jednego zamówienia. Pytest sprawdza znane sumy oraz ten przypadek wspólnego zamówienia, a nic jeszcze nie testuje replayów:

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]Obsługiwane przez

Nazwij każdy job po zachowaniu, które sprawdza. Te same nazwy pojawią się wtedy w GitHubie i w tekście Triggera Superagenta:

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 fileObsługiwane przez

Jeśli goły pytest nie może zaimportować revenue, dodaj pytest.ini z pythonpath = .. Potwierdź, że oba joby przechodzą na main przed instalacją Superagenta.

Opublikowany katalog experiment/holdout dokumentuje pierwotne uruchomienie, ale jest widoczny w publicznym klonie. Do nowego eksperymentu stwórz świeży zestaw poza każdym checkoutem i systemem plików, do którego worker ma dostęp.

Zahaszuj ten zestaw przed wysłaniem prośby o naprawę. Obejmij przypadki:

• Wielokrotne dostarczenia jednego zdarzenia.
• Różne zdarzenia z tym samym ID zamówienia.
• Wejściowy DataFrame, który musi pozostać niezmieniony.
• Oczekiwane kolumny wyjściowe i kolejność sortowania.

Trzymaj ten zestaw w ukryciu do czasu recenzji. Krok 6 uruchamia go z oddzielnego środowiska ludzkiego po zakończeniu pracy workera.

Poniższy diagram oddziela dane wejściowe rozwoju workera od finalnej kontroli maintenera.

Dane holdout pozostają poza workerem. Obraz: autor.

Krok 2: Zainstaluj DeepSeek Superagent i połącz z GitHubem

Zainstaluj pakiet w dedykowanym profilu Harness, oddzielnym od profilu używanego na co dzień. Załaduj token konta agenta do AGENT_GH_TOKEN bez zapisywania go w repozytorium. Następnie uruchom te polecenia jako użytkownik superagent:

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

# A gh wrapper that only ever sees the agent account
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            # your dedicated agent account

# Dedicated profile, then the bundle
dsh superagent --from-default-profile web --dump-config > /dev/null
dsh plugin --profile superagent add "link:$PWD"Obsługiwane przez

Uwaga: Uruchomienia w tym samouczku używały commitu 6337fc8, który DeepSeek później zeskładował do 8c32a9d.

Użyj przykładu profilu w sklonowanym repozytorium, aby ustawić katalog stanu i podpiąć panel pod 127.0.0.1:3082. Następnie uruchom usługę w tmux:

scripts/dsh-superagent start
scripts/dsh-superagent statusObsługiwane przez

Ten profil oddziela restarty usługi od osobistych sesji Harness. Trzyma też PATH i ustawienia Gita pluginu poza normalnym profilem.

status może zgłaszać setup pending lub repositoryUnset dopóki nie zapiszesz Źródła GitHuba w Kroku 3. Na tym etapie potwierdź tylko, że runtime odpowiada i panel Superagent się otwiera; nie oczekuj jeszcze Źródła ani bazy CI.

Otwórz Settings → Models w dedykowanym profilu i wybierz deepseek-flash. W Superagent → Settings → Eval i Execution potwierdź, że obie role dziedziczą model profilu lub nazwij deepseek-flash wprost.

Krok 3: Skonfiguruj monitorowanie GitHub Actions w trybie observe

Pozostaw obserwację CI gałęzi domyślnej wyłączoną, dopóki nie zapiszesz ustawień Source, policy, rule i executor. Włącz ją dopiero po tym, jak nowe repozytorium ma zielone main, aby pierwszy odczyt zapisał czystą bazę.

Skonfiguruj Źródło GitHuba

W Settings → Sources ustaw repozytorium na EXPERIMENT_REPO, wskaż w polu CLI dedykowany wrapper gh-agent i pozostaw wyłączoną obserwację CI gałęzi domyślnej. Zapisz Source i poczekaj na ewentualny restart przed zmianą polityki.

Skonfiguruj politykę admission dla CI

Wynik CI nie ma nadawcy. Jego wiersz admission ma jedną komórkę, która domyślnie to ignore. Jeśli zostawisz to ustawienie, Eval nigdy nie zobaczy CI.

Zdefiniuj wąską regułę revenue-integrity

Zastąp reguły przykładowe jedną regułą nazwaną jak check. Powiedz evaluatorowi, by nie zgadywał przyczyn:

{
  "rules": [{
    "id": "revenue-integrity",
    "name": "Revenue integrity CI failures",
    "enabled": true,
    "instruction": "A default-branch CI result in which the check named revenue-integrity newly fails. That check executes the pytest suite guarding the daily revenue totals. Judge only from the check names and results you can read for that commit; do not guess a root cause. Failures limited to other checks, such as docs-check (README links), do not match. A recovery where every check passes does not match. Work, if accepted: investigate the failing revenue-integrity tests, fix the pipeline without weakening or deleting any assertion, add a regression test, and open a pull request for human review. Never merge."
  }],
  "sources": {"github": {
    "allowed": [{"id": "<human-login>"}],
    "bots": [],
    "admission": {"ci": {"unlistedUnaddressed": "inferred"}}
  }}
}Obsługiwane przez

Dodaj polecenie prepare, które tworzy worktree Gita dla każdego Ticketu. Każdy worker zaczyna wtedy od checkoutu repozytorium:

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"Obsługiwane przez

Superagent uzupełnia te zmienne dla każdego Ticketu. Sprawdź, czy wynikowy katalog zawiera oczekiwany checkout przed autoryzacją pracy.

Opcjonalny skrypt konfiguracyjny zapisuje te same bloki Source, policy, Eval i executor. Utrzymuje obserwację CI wyłączoną podczas pierwszego przebiegu; zawsze jawnie ustaw repozytorium eksperymentu i dozwolonego proszącego:

export REPO="$EXPERIMENT_REPO"
export ALLOWED="YOUR_GITHUB_LOGIN"
bash /path/to/configure.sh allObsługiwane przez

Pozostaw wyłączoną proaktywną egzekucję

Pozostaw Eval w trybie observe z domyślnym modelem profilu. Po każdym zdarzeniu sprawdź kartę Eval dla decyzji i kartę Execution dla ewentualnego Ticketu.

Włącz obserwację CI i zarejestruj bazę

Gdy oba joby GitHub Actions przejdą na main, włącz obserwację CI gałęzi domyślnej. Ze skryptem pomocniczym użyj jego drugiego przebiegu:

OBSERVE_CI=true bash /path/to/configure.sh source
bash /path/to/configure.sh showObsługiwane przez

Pierwszy odczyt rejestruje stan bez tworzenia pracy. Zweryfikuj cztery warunki:

• Setup nie pokazuje oczekujących wymagań.

• Źródło GitHuba zgłasza ready.

• Źródło zapisuje czystą bazę CI.

• Karty Trigger i Execution nie pokazują bazowego Triggera ani Ticketu.

Jeśli którykolwiek z tych testów zawiedzie, zatrzymaj się przed tworzeniem błędu dokumentacji. Zrzuty ekranu Source i Eval pokazują finalną konfigurację.

Karta Źródła GitHuba z obserwacją CI. Obraz: autor.

Ustawienia Eval: jedna reguła, tryb observe. Obraz: autor.

Krok 4: Przetestuj niepowiązaną awarię GitHub Actions

Użyj uszkodzonego linku w README jako niepowiązanego błędu. Ponieważ chroniona gałąź odrzuca nieudany check, użyj obejścia administratora człowieka tylko w tym jednorazowym repozytorium; nigdy nie dawaj tego obejścia agentowi.

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 pushObsługiwane przez

Gdy GitHub Actions zakończył, docs-check padł, a revenue-integrity przeszedł. To pasowało do ustawionej reguły: Superagent zignorował kandydata, bo reguła przychodów nie pasowała.

Decyzja użyła ignoredFromCard, skrótu dla kandydatów, którzy nie dotykają aktywnej reguły. Ten test obejmuje więc trasowanie, a nie samą regułę.

Wycofaj zmianę README i poczekaj, aż oba joby przejdą. Superagent powinien zignorować odzyskanie i pozostać bezczynny.

Krok 5: Wywołaj błąd CI revenue integrity

Użyj tej samej, tylko ludzkiej ścieżki, by dodać dane incydentu z repozytorium samouczka. To podsumowanie pokazuje replay i oddzielne płatności w jednym zamówieniu bez kolumn znaczników czasu:

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,firstObsługiwane przez

Repozytorium zachowuje pełne kolumny znaczników czasu; pominięto je tutaj, bo nie decydują o tożsamości zdarzenia. Niezależne obliczenie przygotowane wcześniej oczekuje 15 100 centów, więc ustaw tę wartość w teście i dodaj test_replayed_event_is_counted_once().

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 passedObsługiwane przez

Dodatkowe 5 000 centów to jedna płatność policzona dwa razy. Edycja 15100 na 20100 lub usunięcie testu replay też by zazieleniły CI, ale żadna z tych opcji nie jest naprawą.

Nieudany workflow GitHub Actions pokazuje, że tylko revenue-integrity pada. Jego Trigger dotarł po około jednym interwale odpytywania.

Eval oznaczył kandydata jako „would accept”, a karta Execution pozostała pusta. Evaluator widział nazwy checków i ich konkluzje, nie log pytesta, więc wiedział, która bariera padła, ale nie dlaczego.

Tryb observe loguje tylko „would accept”. Obraz: autor.

Krok 6: Autoryzuj naprawę i zweryfikuj pull request

Ścieżka wyraźnej prośby opisana wcześniej teraz autoryzuje wykonanie. Powiadomienia GitHuba mogą się spóźniać.

Obsłuż pominiętą wzmiankę w GitHub Issue

W Superagencie 6337fc8 Źródło GitHuba nakłada ankiety o pięć sekund i czyta powiadomiony wątek od późniejszego kursora. Powiadomienia o wzmiankach przychodziły 21–23 sekundy później, więc ankieta mogła minąć wiadomość.

To wyjaśnia, dlaczego nowa treść Issue i część komentarzy nigdy nie stały się Triggerami. Zgłoszenie społeczności opisuje ten sam tryb awarii.

Autoryzuj naprawę komentarzem w GitHubie

Wyślij prośbę ponownie jako świeży komentarz i potwierdź, że jego Trigger się pojawia. Superagent powinien przyjąć go jako wyraźną prośbę i uruchomić workera.

Wzmianka w komentarzu tworzy autoryzowany Ticket. Obraz: autor.

Sprawdź poprawkę deduplikacji zdarzeń przez agenta

Powstały pull request oparł poprawkę na event_id. Przejrzyj diff, zamiast polegać na opisie:

 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")Obsługiwane przez

Dodał test replay i nic nie usunął. Pierwsze uruchomienie testów padło z powodu braków w zależnościach. Po utworzeniu wirtualnego środowiska przez workera widoczny zestaw testów przeszedł.

Przetestuj płatności współdzielące zamówienie

Zażądaj zmian bez wspominania agenta: udowodnij, że dwie płatności w jednym zamówieniu, identyczne poza event_id, obie się liczą, a replay jednej liczy się raz. Recenzja powinna trafić do tego samego Ticketu bez nowego Eval.

Worker odpowiedział commitem, który tylko dodał test i zostawił pipeline bez zmian. Przed akceptacją sprawdź dokładne head SHA i uruchom niezależny zestaw względem tej rewizji.

Informacja zwrotna w recenzji kontynuuje ten sam Ticket. Obraz: autor.

Sprawdź naprawę na niezależnych danych

Uruchom holdout z oddzielnego środowiska ludzkiego względem dokładnego head pull requestu. Na a43c541 oba zestawy przeszły 5 z 5 testów bez usuwania asercji; 62bac08 zachował to samo drzewo.

Testy napisane wyłącznie przez agenta obejmują tylko przypadki wybrane przez agenta.

Krok 7: Scal poprawkę i zmierz powrót CI

Po sca leniu sprawdź, że main wraca do zielonego stanu i że odzyskanie nie uruchamia nowej pracy. Następnie przejrzyj ślad zdarzeń, czas i koszt providera.

Scal poprawkę i potwierdź odzyskanie CI

Po ręcznej akceptacji i sca leniu oba checki gałęzi domyślnej przeszły. Superagent zignorował odzyskanie, nie rozpoczął więcej pracy i zamknął istniejący Ticket z wynikiem merged.

Oceń pobór zdarzeń i decyzje

Śledź każde zdarzenie od intake do wyniku, jak opisuje nasz przewodnik po ocenie agentów AI. W trzech powtórzeniach zdarzenia, które dotarły do Eval, podążyły oczekiwaną ścieżką; pominięcia wystąpiły podczas poboru, nie w decyzji modelu.

Zmierz poprawność naprawy, czas i koszt

Ten sam scenariusz działał w trzech świeżych repozytoriach i dystrybucjach WSL z Superagentem 6337fc8, Harness 0.2.1-rc.3, deepseek-flash i jedną polityką. Koszty używają niższej ceny pozaszczytowej DeepSeek; to reprodukcje, nie benchmark.

Wszystkie trzy naprawy użyły event_id; każdy test holdout przeszedł. Pobór był bardziej zmienny: wzmianka w treści Issue była pomijana za każdym razem, a trzecia reprodukcja pominęła też dwa komentarze, zanim jeden dotarł.

Druga reprodukcja przepisała commity, a akceptacja nadeszła przed ponownym uruchomieniem holdoutu. Późniejsza kontrola przeszła, ale bezpieczniejsza kolejność to head SHA, holdout, potem akceptacja.

Ograniczenia DeepSeek Superagent i rozwiązywanie problemów

Wiele awarii wygląda tu jak cisza, więc zacznij od znalezienia miejsca, gdzie zdarzenie się zatrzymało. Frustrujące jest to, że pominięte powiadomienie i poprawne ignore mogą wyglądać tak samo.

Błędy CI, które nie tworzą Triggera

Superagent śledzi zmiany w zbiorze błędów, więc odczyt bazy, check, który nadal pada, i checki w toku nic nie generują. Trigger bez decyzji zwykle wskazuje na komórkę admission CI, nie na model.

Prośby z GitHuba, które nigdy nie docierają

Prośby mogą się nie udać, gdy nadawca nie jest dozwolony, Źródło jest wyłączone, przetwarzanie wstrzymane lub GitHub powiadamia z opóźnieniem. Jeśli te kontrole przejdą, opublikuj świeży komentarz; edycja treści Issue nie tworzy zdarzenia.

Granice autonomicznej naprawy CI

Prototyp nie zapewnia granicy bezpieczeństwa. Workery mają pełny dostęp użytkownika OS, a zasady ujawniania to tekst promptu. Izoluj konto agenta i ogranicz je do jednorazowego repozytorium.

Zanim przełączysz na auto, zbierz tygodnie obserwowanych decyzji, policz błędne akceptacje i błędne ignorowania, a workera przenieś z WSL na oddzielną maszynę wirtualną.

Na koniec

Początkowy kontrast się utrzymał: dwa czerwone stany CI nie doprowadziły do tej samej akcji. Superagent zignorował docs-check i oznaczył revenue-integrity jako „would accept”, a tryb observe pozostawił kod nietknięty, dopóki osoba nie poprosiła o naprawę.

Poprawka event_id była prosta. Pobór powiadomień był mniej niezawodny: wzmianka w treści Issue nigdy nie dotarła do Eval, więc poprawna reguła nie mogła pomóc.

Nie uogólniałbym tego wyniku na autonomiczną naprawę CI. Repozytorium było małe, reguła wąska, a scalenie kontrolowane przez człowieka. Gdzie indziej zacznij od zielonego, sprawdzaj decyzje, autoryzuj jawnie, trzymaj dane holdout osobno i scalaj po niezależnych sprawdzeniach.

Moim następnym krokiem byłoby naprawienie ścieżki powiadomień GitHuba i powtórzenie workflowu z większą liczbą typów błędów. Dopóki nie ma takich dowodów, trzymałbym tryb auto wyłączony.