DeepSeek Superagent Eğitimi: CI’ı İzleyin ve Bir Düzeltmeyi Yetkilendirin

DeepSeek Superagent Nedir?

DeepSeek Superagent, DeepSeek Harness üzerinden tek bir GitHub deposunu izler. Ekip kuralları bir olayın çalışmaya değer olup olmadığını belirler; kabul edilen işler ayrı bir oturuma gider. Bu eğitim, yalnızca yayımlanan prototipi kapsar, tasarım fikirlerini değil.

Harness çalışma zamanını sağlar; Superagent olay izleme ve yetkilendirme ekler. Aracı harness açıklayıcımız araçlar, bellek ve kontrolü kapsar.

DeepSeek Superagent nasıl çalışır?

Yeni bir GitHub olayı dört aşamadan geçebilir. Bu aşamalar kararı kod değişikliğinden ayrı tutar:

• Kaynak ve Tetikleyici: GitHub yoklaması her olayı, bir Konu, çekme isteği veya main üzerinde bir Tetikleyiciye dönüştürür.

• Kabul: kapı onun açık bir istek, çıkarımsanmış aday ya da hiçbir şey olup olmadığını etiketler.

• Değerlendirme ve Karar:  çıkarımsanmış CI kurallara karşı yargılanır. Açık bir istek, gerekçe explicitRouted ile kabul kararına yönlendirilir.

• Bilet ve Yürütücü: kabul edilen iş, yetkilendirmesini, çalışan oturumunu ve dizinini alır.

Biletin kendi Konusundaki daha sonraki bir yorum, yeni bir Değerlendirme olmaksızın çalışanına gider. Diyagram, üç GitHub yolunu gösterir: varsayılan dal CI’ı, açık bir istek ve o inceleme. CI yolunda, gözlem ve kuralla eşleşen otomatik ayrılma farklı uçlardadır.

CI yargılanır. İstekler işi başlatır. Görsel: Yazar.

Gözlem modu ile otomatik mod arasındaki fark nedir?

Kabul modu yalnızca Superagent’ın bir olaydan çıkardığı iş için geçerlidir. Üç ayardan birini seçin:

• off çıkarımsanmış adayları atar.

• observe onları değerlendirir ancak olumlu sonucu "kabul ederdi" olarak kaydeder.

• auto olumlu bir değerlendirmeden sonra işi başlatır.

Yetkili bir kişiden gelen istek her modda çalışır ve kendi Biletini oluşturur. Bu eğitim için auto kapalı kalsın.

Gözlem Modunda Bir CI Onarım İş Akışı Kurun

Boru hattı, s pytest ve olayları günlük gelire dönüştüren iki GitHub Actions işini kullanır. Superagent, iş başlamadan önce bir karar ekler. Claude Code Routines eğitimimiz başka bir olay odaklı iş akışını kapsar.

Günlük gelirdeki tekrar hatasını izleyin

Hata, yeniden gönderilen bir ödemeyi iki kez sayıyor. Her satırda bir event_id, order_id, zaman damgaları ve bir tutar var. Bir sipariş birden çok geçerli ödeme içerebilir.

Bu yüzden order_id üzerinden tekilleştirmek bir tekrar testini geçebilir ama gerçek ödemeleri silebilir; doğru anahtar event_id’dir. Beklenen toplamları Python’un csv modülüyle, aracı yetkilendirmeden önce hesaplayın; böylece aracının çıktısı cevap anahtarı olmaz.

Başarılı bir CI onarımını tanımlayın

Başarı, yalnızca aracının söylediklerine değil, iş akışının ne yaptığına bağlıdır. Depoyu değiştirmeden önce bu koşulları belirleyin:

• Yalnızca dokümantasyon hatasını yok sayın.

• revenue-integrity ile eşleşin, ancak işi başlatmayın.

• Yalnızca açık bir istekten sonra bir çekme isteği açın.

• Doğrulamaları koruyun ve önceden hazırlanmış bir holdout paketini geçin.

Holdout paketini Superagent erişiminden önce hazırlayın. Bu, beklenen davranışı çalışanın geliştirme girdilerinin dışında tutar.

DeepSeek Superagent Önkoşulları ve İzolasyon

Bir DeepSeek API anahtarı, iki GitHub hesabı ve tek kullanımlık bir Linux ortamına ihtiyacınız var. Harness temelleri için temel kurulum rehberimize bakın.

Gereken yazılım ve hesaplar

Yazılım sürümlerini sabitleyin ki bir yükseltme iş akışını değiştiremesin. Son sütün sonrasında, yazının ilerleyen bölümünde kullanılan kurulum kaydedilmiştir:

Aracının, Superagent bu hesabın bildirimlerini okuduğu için yazma erişimi olan kendi GitHub kullanıcısına ihtiyacı vardır. Yalnızca işi yetkilendirebilecek insan bakımcıları izinli listesine ekleyin.

Aracıyı kişisel dosyalardan izole edin

Her iki hazır ayar da işletim sistemi (OS) kullanıcısına tam erişim verir ve gh sarmalayıcı işlemi izole etmez. Otomatik bağlama ve birlikte çalışabilirlik kapalı, yeni bir WSL dağıtımı kullanın:

Zaten tek kullanımlık bir Linux sanal makineniz varsa, WSL bloğunu atlayın ve onun yerine o makineyi kullanın. İlgisiz kimlik bilgilerini ve dosyaları ondan uzak tutun.

# /etc/wsl.conf inside the disposable distribution
[automount]
enabled = false
mountFsTab = false
[interop]
enabled = false
appendWindowsPath = false
[user]
default = superagentAltyapı:

Adanmış bir superagent kullanıcısı yalnızca DeepSeek anahtarını ve aracı belirtecini tutmalıdır. Bu, kazara erişimi azaltır ama bir güvenlik sınırı değildir; Microsoft’un WSL güvenlik modeli güvenilmeyen kod için WSL dışında ayrı yönetilen bir sanal makine önerir.

GitHub’da, main dalını gerekli çekme isteği, en az bir bağımsız onay ve her iki CI kontrolüyle koruyun. Aracıya yönetici atlaması olmadan yazma erişimi verin. Bunların hiçbiri, Konu metni üzerinden istem enjeksiyonunu engellemez.

Adım 1: Python Gelir Hattını ve CI Temelini Kurun

Yayımlanan eğitim deposunda artık onarım main’e birleştirilmiş durumda, bu nedenle başlangıç durumu olarak mevcut dalını kullanmayın. Üç aşamayı ayırmak için şu commit’leri kullanın:

Aşağıdaki boru hattı ve testler, şu anki main’den değil, yeşil temelden (a6d2036) basitleştirilmiştir. CI adımlarını izlemeye başlamadan önce, bu commit’ten tek kullanımlık bir depo oluşturun:

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 --pushAltyapı:

Kontrollü hatalar ve aracının dalları için bu yeni depoyu kullanın. Yayımlanan depoyu değiştirmeyin; olay ve çözüm commit’leri, karşılaştırma için referanstır.

"""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 reportAltyapı:

Temel veri kümesi iki günü kapsar ve bir sipariş için birden çok gerçek ödeme içerir. Pytest bilinen toplamları ve paylaşılan sipariş durumunu kontrol eder ve henüz tekrarları test etmez:

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]Altyapı:

Her işi, kontrol ettiği davranışa göre adlandırın. Aynı adlar daha sonra GitHub’da ve Superagent’ın Tetikleyici metninde görünür:

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 fileAltyapı:

Eğer yalın pytest revenue’ı içe aktaramazsa, pytest.ini içine pythonpath = . ekleyin. Superagent’ı kurmadan önce her iki işin de main üzerinde geçtiğini doğrulayın.

Yayımlanmış experiment/holdout dizini orijinal koşuyu belgeliyor ancak herkese açık klonda görünür. Yeni bir deney için, çalışanın okuyabildiği her checkout ve dosya sistemi dışında yeni bir paket oluşturun.

Onarım isteğini göndermeden önce bu paketi hash’leyin. Şu durumları kapsayın:

• Tek bir olayın tekrarlanan iletimleri.
• Aynı sipariş kimliğine sahip farklı olaylar.
• Değişmeden kalması gereken bir girdi DataFrame’i.
• Beklenen çıktı sütunları ve sıralama düzeni.

Bu paketi incelemeye kadar gizli tutun. Adım 6, çalışan bittikten sonra ayrı insan ortamından onu çalıştırır.

Aşağıdaki diyagram, çalışanın geliştirme girdilerini bakımcının son kontrolünden ayırır.

Holdout veriler, çalışanın dışında kalır. Görsel: Yazar.

Adım 2: DeepSeek Superagent’ı Kurun ve GitHub’a Bağlayın

Paketi, günlük işlerde kullanılan profilden ayrı, adanmış bir Harness profilinde kurun. Aracı hesabının belirtecini AGENT_GH_TOKEN içine yükleyin; depoya yazmayın. Ardından bu komutları superagent kullanıcısı olarak çalıştırın:

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"Altyapı:

Not: Bu eğitimdeki çalıştırmalar 6337fc8 commit’ini kullandı; DeepSeek daha sonra bunu 8c32a9d içine sıkıştırdı.

Klonlanan depodaki profil örneğini kullanarak bir durum dizini ayarlayın ve paneli 127.0.0.1:3082’ye bağlayın. Ardından hizmeti tmux içinde başlatın:

scripts/dsh-superagent start
scripts/dsh-superagent statusAltyapı:

Bu profil, hizmet yeniden başlatmalarını kişisel Harness oturumlarından ayırır. Ayrıca eklentinin PATH ve Git ayarlarını normal profilden uzak tutar.

status, GitHub Kaynağını Adım 3’te kaydedene kadar kurulum beklemede veya repositoryUnset bildirebilir. Bu noktada yalnızca çalışma zamanının yanıt verdiğini ve Superagent panelinin açıldığını doğrulayın; henüz bir Kaynak veya CI temeli beklemeyin.

Adanmış profilde Ayarlar → Modeller’i açın ve deepseek-flash seçin. Superagent → Ayarlar → Değerlendirme ve Yürütme bölümlerinde, her iki rolün de o profil modelini devraldığını doğrulayın veya adı deepseek-flash olarak açıkça belirtin.

Adım 3: Gözlem Modunda GitHub Actions İzlemeyi Yapılandırın

Kaynak, politika, kural ve yürütücü ayarlarını kaydederken varsayılan dal CI gözlemini kapalı bırakın. Yeni depo main üzerinde yeşile döndükten sonra açın; böylece ilk okuma temiz bir temel kaydeder.

GitHub Kaynağını yapılandırın

Ayarlar → Kaynaklar içinde depoyu EXPERIMENT_REPO olarak ayarlayın, CLI alanını adanmış gh-agent sarmalayıcıya yönlendirin ve varsayılan dal CI gözlemini kapalı tutun. Kaynağı kaydedin ve politikayı değiştirmeden önce olası bir yeniden başlatmanın bitmesini bekleyin.

CI kabul politikasını yapılandırın

Bir CI sonucunun göndereni yoktur. Kabul satırının tek hücresi vardır ve varsayılanı ignore’dır. Bu ayarı değiştirmezseniz, Değerlendirme CI’ı hiç görmez.

Dar bir revenue-integrity kuralı tanımlayın

Örnek kuralları, denetimin adıyla adlandırılmış tek bir kuralla değiştirin. Değerlendiriciye nedenleri tahmin etmemesini söyleyin:

{
  "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"}}
  }}
}Altyapı:

Her Bilet için bir Git worktree oluşturan bir hazırlık komutu ekleyin. Böylece her çalışan bir depo checkout’u üzerinden başlar:

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"Altyapı:

Superagent, her Bilet için bu değişkenleri doldurur. Yetkilendirme yapmadan önce, ortaya çıkan dizinin beklenen checkout’u içerdiğini kontrol edin.

İsteğe bağlı yapılandırma yardımcısı aynı Kaynak, politika, Değerlendirme ve yürütücü bloklarını yazar. İlk geçişte CI gözlemini kapalı tutar; deney deposunu ve izinli istekte bulunacak kişiyi her zaman açıkça ayarlayın:

export REPO="$EXPERIMENT_REPO"
export ALLOWED="YOUR_GITHUB_LOGIN"
bash /path/to/configure.sh allAltyapı:

Proaktif yürütmeyi devre dışı bırakın

Değerlendirmeyi profilin varsayılan modeliyle observe halinde tutun. Her olaydan sonra Değerlendirme sekmesinde Kararı ve Yürütme sekmesinde herhangi bir Bileti kontrol edin.

CI gözlemini açın ve temeli kaydedin

Her iki GitHub Actions işi de main üzerinde geçtikten sonra, varsayılan dal CI gözlemini açın. Yardımcı betikle ikinci geçişini kullanın:

OBSERVE_CI=true bash /path/to/configure.sh source
bash /path/to/configure.sh showAltyapı:

İlk okuma, iş oluşturmadan durumu kaydeder. Tüm dört koşulu doğrulayın:

• Kurulum bekleyen gereksinim göstermez.

• GitHub Kaynağı ready raporlar.

• Kaynak, temiz bir CI temelini kaydeder.

• Tetikleyici ve Yürütme sekmeleri bir temel Tetikleyici veya Bilet göstermez.

Bu kontrollerden biri başarısız olursa, dokümantasyon hatasını oluşturmadan önce durun. Kaynak ve Değerlendirme ekran görüntüleri nihai yapılandırmayı gösterir.

CI gözlemi açık GitHub Kaynağı kartı. Görsel: Yazar.

Değerlendirme ayarları: tek kural, gözlem modu. Görsel: Yazar.

Adım 4: İlgisiz Bir GitHub Actions Hatasını Test Edin

İlgisiz bir hata olarak bozuk bir README bağlantısı kullanın. Korumalı dal, başarısız bir kontrolü reddettiğinden, bu tek kullanımlık depoda yalnızca bir insan yöneticisinin atlamasını kullanın; bu atlamayı asla aracıya vermeyin.

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 pushAltyapı:

GitHub Actions bittiğinde, docs-check başarısız oldu ve revenue-integrity geçti. Bu, ayarladığım kuralla eşleşiyordu: Superagent, gelir kuralı eşleşmediği için adayı yok saydı.

Karar, etkin kurala dokunmayan adaylar için bir kısayol olan ignoredFromCard kullandı. Dolayısıyla bu kontrol, kuralın kendisi yerine yönlendirmeyi kapsar.

README değişikliğini geri alın ve her iki işin de geçmesini bekleyin. Superagent toparlanmayı yok saymalı ve boşta kalmalıdır.

Adım 5: Bir Gelir Bütünlüğü CI Hatasını Tetikleyin

Eğitim deposundan olay verisini eklemek için aynı yalnızca-insan yolunu kullanın. Bu özet, zaman damgası sütunları olmadan tekrarları ve bir siparişteki ayrı ödemeleri gösterir:

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,firstAltyapı:

Depo, tam zaman damgası sütunlarını tutar; burada olay kimliğini belirlemediği için atlanmıştır. Önceden hazırlanan bağımsız hesaplama 15.100 sent bekliyor, bu nedenle bu değeri teste ayarlayın ve test_replayed_event_is_counted_once() ekleyin.

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 passedAltyapı:

Fazladan 5.000 sent, bir ödemenin iki kez sayılmasıdır. 15100’ü 20100 olarak düzenlemek veya tekrar testini silmek de CI’ı yeşile çevirirdi ve hiçbiri onarım değildir.

Başarısız GitHub Actions iş akışı yalnızca revenue-integrity’nin başarısız olduğunu gösteriyor. Tetikleyicisi yaklaşık bir yoklama aralığı sonra geldi.

Değerlendirme adayı "kabul ederdi" olarak işaretledi, Yürütme sekmesi boş kaldı. Değerlendirici, pytest günlüğünü değil, kontrol adlarını ve sonuçlarını gördüğünden hangi korumanın başarısız olduğunu biliyordu ama nedenini bilmiyordu.

Gözlem modu yalnızca "kabul ederdi" kaydeder. Görsel: Yazar.

Adım 6: Onarımı Yetkilendirin ve Çekme İsteğini Doğrulayın

Daha önce kapsanan açık-istek yolu artık yürütmeyi yetkilendirir. GitHub bildirimleri gecikebilir.

Kaçırılan GitHub Konu mention’ını ele alın

Superagent 6337fc8’de, GitHub Kaynağı yoklamaları beş saniye bindirir ve bildirilen bir konuyu daha sonraki imleçten okur. Mention bildirimleri 21–23 saniye sonra geldi, bu nedenle bir yoklama iletiyi geçebilir.

Bu zamanlama, yeni Konu gövdesinin ve bazı yorumların neden hiç Tetikleyiciye dönüşmediğini açıklar. Bir topluluk raporu aynı hata modunu tanımlıyor.

Onarımı bir GitHub yorumuyla yetkilendirin

İsteği taze bir yorum olarak tekrar gönderin ve Tetikleyicisinin göründüğünü doğrulayın. Superagent onu açık bir istek olarak kabul etmeli ve çalışanı başlatmalıdır.

Yorum mention’ı yetkili Bileti oluşturur. Görsel: Yazar.

Aracının olay tekilleştirme düzeltmesini kontrol edin

Ortaya çıkan çekme isteği düzeltmeyi event_id üzerine kurdu. Açıklamasına güvenmek yerine diff’i inceleyin:

 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")Altyapı:

Bir tekrar testi ekledi ve hiçbir şeyi silmedi. İlk test komutu, bağımlılıklar eksik olduğu için başarısız oldu. Çalışan bir sanal ortam oluşturduktan sonra, görünür test paketi geçti.

Siparişi paylaşan ödemeleri test edin

Aracıdan bahsetmeden değişiklik isteyin: event_id dışında özdeş olan, bir sipariş üzerindeki iki ödemenin ikisinin de sayıldığını ve birinin tekrarının bir kez sayıldığını kanıtlayın. İnceleme, yeni bir Değerlendirme olmadan aynı Bilet’e ulaşmalıdır.

Çalışan, yalnızca bir test ekleyen ve boru hattını değiştirmeyen bir commit ile yanıt verdi. Onaydan önce, tam kafa SHA’sını kontrol edin ve bağımsız paketi o revizyona karşı tekrar çalıştırın.

İnceleme geri bildirimi aynı Bilet üzerinden devam eder. Görsel: Yazar.

Onarımı bağımsız verilerle kontrol edin

Ayrı insan ortamından holdout’u doğrudan çekme isteği başına karşı çalıştırın. a43c541 üzerinde her iki paket de herhangi bir doğrulamayı kaldırmadan 5’te 5 test geçti; 62bac08 aynı ağacı korudu.

Yalnızca aracının yazdığı testler, yalnızca aracının seçtiği durumları kapsar.

Adım 7: Düzeltmeyi Birleştirin ve CI Toparlanmasını Ölçün

Birleştirmeden sonra, main’in yeniden yeşile döndüğünü ve toparlanmanın yeni bir işi başlatmadığını kontrol edin. Ardından olay izini, geçen süreyi ve sağlayıcı ücretini gözden geçirin.

Düzeltmeyi birleştirin ve CI toparlanmasını doğrulayın

Manuel onay ve birleştirmeden sonra, her iki varsayılan dal kontrolü de geçti. Superagent toparlanmayı yok saydı, daha fazla iş başlatmadı ve mevcut Bileti merged sonucu ile kapattı.

Olay alımını ve kararları değerlendirin

Her olayı, rehberimizde açıklandığı gibi alımdan sonuca kadar izleyin: AI ajanlarını değerlendirme rehberi. Üç tekrarda, Değerlendirmeye ulaşan olaylar beklenen rotayı izledi; kaçırmalar alım sırasında oldu, model Kararında değil.

Onarım doğruluğunu, süreyi ve maliyeti ölçün

Aynı senaryo, Superagent 6337fc8, Harness 0.2.1-rc.3, deepseek-flash ve tek bir politikayla üç yeni depoda ve WSL dağıtımında çalıştırıldı. Maliyetler, daha düşük yoğun olmayan DeepSeek tarifesini kullanır; bunlar tekrar üretimlerdir, kıyaslama değildir.

Üç onarım da event_id kullandı; her holdout testi geçti. Alım daha çok değişti: Konu gövdesi mention’ı her seferinde kaçtı ve üçüncü tekrar üretimde bir tane gelmeden önce iki yorum da kaçtı.

İkinci tekrar üretim commit’leri yeniden yazdı ve holdout yeniden çalışmadan önce onay geldi. Daha sonraki kontrol geçti, ancak daha güvenli sıra kafa SHA, holdout, sonra onaydır.

DeepSeek Superagent Sınırlamaları ve Sorun Giderme

Buradaki birkaç başarısızlık sessizlik gibi görünür, bu yüzden bir olayın nerede durduğunu bularak başlayın. Can sıkıcı olan, kaçırılan bir bildirimin ve doğru bir yok saymanın aynı görünebilmesidir.

Tetikleyici üretmeyen CI hataları

Superagent, başarısız kümedeki değişiklikleri izler; bu nedenle temel okuma, başarısız olmaya devam eden bir kontrol ve hâlâ çalışan kontroller hiçbir şey üretmez. Kararsız bir Tetikleyici genellikle modelden değil, CI kabul hücresinden kaynaklanır.

Asla gelmeyen GitHub istekleri

Gönderen izinli değilse, Kaynak kapalıysa, işleme duraklatıldıysa veya GitHub geç bildirirse istekler başarısız olabilir. Bu kontroller geçerse, taze bir yorum gönderin; Konu gövdesini düzenlemek olay oluşturmaz.

Otonom CI onarımının sınırları

Prototip bir güvenlik sınırı sağlamaz. Çalışanlar, OS kullanıcısına tam erişime sahiptir ve ifşa kuralları, istem metnidir. Aracı hesabını izole edin ve onu tek kullanımlık depoyla sınırlayın.

auto’ya geçmeden önce, haftalarca gözlemlenen Kararlar toplayın, yanlış kabulleri ve yanlış yok saymaları sayın ve çalışanı WSL’den ayrı bir sanal makineye taşıyın.

Son Düşünceler

Başlangıçtaki karşıtlık korundu: iki kırmızı CI durumu aynı eyleme yol açmadı. Superagent, docs-check’i yok saydı ve revenue-integrity’yi "kabul ederdi" olarak işaretledi; gözlem modu, bir kişi onarımı isteyene kadar kodu dokunulmaz tuttu.

event_id yaması basitti. Bildirim alımı daha az güvenilirdi: Konu gövdesindeki mention, Değerlendirmeye hiç ulaşmadı; bu yüzden doğru bir kural yardımcı olamadı.

Bu sonucu otonom CI onarımına genellemezdim. Depo küçüktü, kural dardı ve birleştirme insan kontrolündeydi. Başka yerlerde, yeşil başlayın, Kararları inceleyin, açıkça yetkilendirin, holdout verilerini ayrı tutun ve bağımsız kontrollerden sonra birleştirin.

Bir sonraki adımım, GitHub bildirim yolunu düzeltmek ve daha fazla hata türüyle iş akışını tekrarlamak olurdu. Bu kanıt oluşana kadar auto modunu kapalı tutardım.