Tutorial DeepSeek Superagent: Amati CI dan Otorisasi Perbaikan

Apa itu DeepSeek Superagent?

DeepSeek Superagent memantau satu repositori GitHub melalui DeepSeek Harness. Aturan tim menentukan apakah sebuah peristiwa layak ditindaklanjuti; pekerjaan yang diterima masuk ke sesi terpisah. Tutorial ini membahas prototipe yang dipublikasikan, bukan gagasan desain semata.

Harness menyediakan runtime; Superagent menambahkan pemantauan peristiwa dan otorisasi. Penjelasan agent harness kami membahas alat, memori, dan kontrol.

Bagaimana cara kerja DeepSeek Superagent?

Sebuah peristiwa GitHub baru dapat melalui empat tahap. Tahap-tahap ini menjaga keputusan dan perubahan kode tetap terpisah:

• Sumber dan Trigger: Polling GitHub mengubah setiap peristiwa menjadi Trigger pada Issue, pull request, atau main.

• Admission: gerbang memberi label sebagai permintaan eksplisit, kandidat terinferensi, atau tidak ada.

• Eval dan Keputusan:  CI yang diinferensi dinilai terhadap aturan. Permintaan eksplisit diarahkan ke Keputusan menerima dengan alasan explicitRouted.

• Tiket dan Eksekutor: pekerjaan yang diterima mendapatkan otorisasi, sesi pekerja, dan direktori.

Komentar selanjutnya pada Thread milik Tiket masuk ke pekerjanya tanpa Eval baru. Diagram menunjukkan tiga jalur GitHub: CI cabang default, permintaan eksplisit, dan ulasan tersebut. Di dalam jalur CI, observe dan auto meninggalkan aturan yang cocok di ujung yang berbeda.

CI dinilai. Permintaan memulai pekerjaan. Gambar oleh Penulis.

Apa perbedaan antara mode observe dan mode auto?

Mode accept hanya berlaku untuk pekerjaan yang diinferensi Superagent dari sebuah peristiwa. Pilih salah satu dari tiga pengaturan:

• off membuang kandidat terinferensi.

• observe mengevaluasi kandidat tetapi mencatat hasil positif sebagai "akan diterima".

• auto memulai pekerjaan setelah evaluasi positif.

Permintaan dari orang yang diizinkan bekerja di setiap mode dan membuat Tiketnya sendiri. Biarkan auto nonaktif untuk tutorial ini.

Bangun Alur Kerja Perbaikan CI dalam Mode Observe

Pipeline menggunakan pytest dan dua job GitHub Actions untuk mengubah peristiwa menjadi pendapatan harian. Superagent menyisipkan keputusan sebelum pekerjaan dimulai. Tutorial Claude Code Routines kami membahas alur kerja berbasis peristiwa lainnya.

Lacak bug replay dalam pendapatan harian

Bug menghitung pembayaran yang ter-replay dua kali. Setiap baris memiliki event_id, order_id, stempel waktu, dan jumlah. Satu pesanan dapat memuat beberapa pembayaran yang valid.

Itulah mengapa deduplikasi berdasarkan order_id bisa lolos uji replay tetapi menghapus pembayaran nyata; kunci yang benar adalah event_id. Hitung total yang diharapkan dengan modul csv Python sebelum mengotorisasi agen, sehingga keluaran agen bukan kunci jawaban.

Definisikan perbaikan CI yang berhasil

Keberhasilan bergantung pada apa yang dilakukan alur kerja, bukan hanya apa yang dikatakan agen. Tetapkan kondisi ini sebelum mengubah repositori:

• Abaikan kegagalan yang hanya terkait dokumentasi.

• Cocokkan revenue-integrity tanpa memulai pekerjaan.

• Buka pull request hanya setelah permintaan eksplisit.

• Pertahankan assertion dan lulus suite holdout yang sudah dibangun.

Siapkan suite holdout sebelum Superagent mendapatkan akses. Ini menjaga perilaku yang diharapkan di luar input pengembangan pekerja.

Prasyarat dan Isolasi DeepSeek Superagent

Anda memerlukan kunci API DeepSeek, dua akun GitHub, dan lingkungan Linux sekali pakai. Untuk dasar-dasar Harness, lihat panduan penyiapan dasar kami.

Perangkat lunak dan akun yang Anda perlukan

Kunci versi perangkat lunak agar pembaruan tidak mengubah alur kerja. Kolom terakhir mencatat setelan yang digunakan untuk hasil di bagian akhir artikel:

Agen memerlukan akun GitHub-nya sendiri dengan akses tulis karena Superagent membaca notifikasi akun tersebut. Tambahkan hanya pengelola manusia yang boleh mengotorisasi pekerjaan ke daftar yang diizinkan.

Isolasi agen dari file pribadi

Kedua preset memberi pengguna sistem operasi (OS) akses penuh, dan pembungkus gh tidak mengisolasi proses. Gunakan distribusi WSL baru dengan automount dan interop nonaktif:

Jika Anda sudah memiliki mesin virtual Linux sekali pakai, lewati blok WSL dan gunakan mesin itu sebagai gantinya. Jauhkan kredensial dan file yang tidak terkait darinya.

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

Pengguna khusus superagent sebaiknya hanya menyimpan kunci DeepSeek dan token agen. Ini mengurangi akses tidak disengaja namun bukan batas keamanan; model keamanan WSL Microsoft merekomendasikan mesin virtual terkelola terpisah di luar WSL untuk kode yang tidak tepercaya.

Di GitHub, lindungi main dengan pull request wajib, setidaknya satu persetujuan independen, dan kedua pemeriksaan CI. Beri agen akses tulis tanpa bypass administrator. Tidak satu pun dari ini mencegah injeksi prompt melalui teks Issue.

Langkah 1: Bangun Pipeline Pendapatan Python dan Baseline CI

Repositori tutorial yang dipublikasi ini kini telah memiliki perbaikan yang digabungkan di main, jadi jangan gunakan cabang saat ini sebagai kondisi awal. Gunakan commit berikut untuk memisahkan tiga tahap:

Pipeline dan pengujian di bawah disederhanakan dari baseline hijau (a6d2036), bukan diambil dari main saat ini. Buat repositori sekali pakai dari commit itu sebelum mengikuti langkah 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 --pushDidukung oleh

Gunakan repositori baru ini untuk kegagalan terkontrol dan cabang agen. Biarkan repositori yang dipublikasikan tetap tidak berubah; commit insiden dan solusinya menjadi referensi perbandingan.

"""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 reportDidukung oleh

Dataset baseline mencakup dua hari dan menyertakan beberapa pembayaran nyata untuk satu pesanan. Pytest memeriksa total yang diketahui dan kasus pesanan bersama itu, dan belum ada yang menguji replay:

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]Didukung oleh

Namai setiap job sesuai perilaku yang diperiksa. Nama yang sama kemudian muncul di GitHub dan pada teks Trigger 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 fileDidukung oleh

Jika pytest polos tidak dapat mengimpor revenue, tambahkan pytest.ini dengan pythonpath = .. Konfirmasikan bahwa kedua job lolos di main sebelum memasang Superagent.

Direktori experiment/holdout yang dipublikasikan mendokumentasikan run asli tetapi terlihat di klon publik. Untuk eksperimen baru, buat suite baru di luar setiap checkout dan filesystem yang dapat dibaca pekerja.

Hash suite itu sebelum mengirim permintaan perbaikan. Cakup kasus berikut:

• Pengiriman berulang dari satu peristiwa.
• Peristiwa berbeda dengan ID pesanan yang sama.
• DataFrame input yang harus tetap tidak berubah.
• Kolom output yang diharapkan dan urutan pengurutan.

Simpan suite ini tersembunyi hingga ulasan. Langkah 6 menjalankannya dari lingkungan manusia terpisah setelah pekerja selesai.

Diagram berikut memisahkan input pengembangan pekerja dari pemeriksaan akhir pemelihara.

Data holdout tetap di luar pekerja. Gambar oleh Penulis.

Langkah 2: Instal DeepSeek Superagent dan Hubungkan GitHub

Instal bundel dalam profil Harness khusus, terpisah dari profil yang digunakan untuk pekerjaan harian. Muat token akun agen ke dalam AGENT_GH_TOKEN tanpa menuliskannya ke repositori. Lalu jalankan perintah ini sebagai pengguna 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"Didukung oleh

Catatan: Run dalam tutorial ini menggunakan commit 6337fc8, yang kemudian di-squash DeepSeek menjadi 8c32a9d.

Gunakan contoh profil di repositori yang diklon untuk menetapkan direktori state dan mengikat panel ke 127.0.0.1:3082. Lalu mulai layanan di tmux:

scripts/dsh-superagent start
scripts/dsh-superagent statusDidukung oleh

Profil ini memisahkan restart layanan dari sesi Harness pribadi. Ini juga menjaga PATH plugin dan setelan Git di luar profil normal.

status mungkin melaporkan penyiapan tertunda atau repositoryUnset hingga Anda menyimpan Sumber GitHub di Langkah 3. Pada titik ini, konfirmasikan hanya bahwa runtime merespons dan panel Superagent terbuka; jangan berharap ada Sumber atau baseline CI terlebih dahulu.

Buka Settings → Models di profil khusus dan pilih deepseek-flash. Di Superagent → Settings → Eval dan Execution, konfirmasikan bahwa kedua peran mewarisi model profil tersebut atau menamai deepseek-flash secara eksplisit.

Langkah 3: Konfigurasi Pemantauan GitHub Actions dalam Mode Observe

Biarkan observasi CI cabang default nonaktif saat Anda menyimpan setelan Sumber, kebijakan, aturan, dan eksekutor. Aktifkan hanya setelah repositori baru memiliki main yang hijau, sehingga pembacaan pertama mencatat baseline yang bersih.

Konfigurasi Sumber GitHub

Di Settings → Sources, atur repositori ke EXPERIMENT_REPO, arahkan field CLI ke pembungkus gh-agent khusus, dan biarkan observasi CI cabang default nonaktif. Simpan Sumber dan tunggu restart apa pun selesai sebelum mengubah kebijakan.

Konfigurasi kebijakan admission CI

Hasil CI tidak memiliki pengirim. Baris admission-nya memiliki satu sel, yang default ke ignore. Jika Anda membiarkan setelan itu apa adanya, Eval tidak pernah melihat CI.

Tentukan aturan revenue-integrity yang sempit

Ganti aturan contoh dengan satu aturan yang dinamai sesuai pemeriksaannya. Beri tahu evaluator untuk tidak menebak penyebab:

{
  "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"}}
  }}
}Didukung oleh

Tambahkan perintah prepare yang membuat Git worktree untuk setiap Tiket. Setiap pekerja kemudian memulai dari checkout repositori:

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"Didukung oleh

Superagent mengisi variabel ini untuk setiap Tiket. Periksa bahwa direktori yang dihasilkan berisi checkout yang diharapkan sebelum mengotorisasi pekerjaan.

Pembantu konfigurasi opsional menulis Sumber, kebijakan, Eval, dan blok eksekutor yang sama. Ia menjaga observasi CI tetap nonaktif selama pass pertama; selalu tetapkan repositori eksperimen dan peminta yang diizinkan secara eksplisit:

export REPO="$EXPERIMENT_REPO"
export ALLOWED="YOUR_GITHUB_LOGIN"
bash /path/to/configure.sh allDidukung oleh

Biarkan eksekusi proaktif dinonaktifkan

Biarkan Eval dalam observe dengan model default profil. Setelah setiap peristiwa, periksa tab Eval untuk Keputusan dan tab Execution untuk setiap Tiket.

Aktifkan observasi CI dan catat baseline

Setelah kedua job GitHub Actions lolos pada main, aktifkan observasi CI cabang default. Dengan skrip pembantu, gunakan pass keduanya:

OBSERVE_CI=true bash /path/to/configure.sh source
bash /path/to/configure.sh showDidukung oleh

Pembacaan pertama mencatat state tanpa membuat pekerjaan. Verifikasi keempat kondisi berikut:

• Penyiapan tidak menunjukkan kebutuhan yang tertunda.

• Sumber GitHub melaporkan ready.

• Sumber mencatat baseline CI yang bersih.

• Tab Trigger dan Execution tidak menampilkan Trigger atau Tiket baseline.

Jika salah satu pemeriksaan ini gagal, hentikan sebelum membuat kegagalan dokumentasi. Tangkapan layar Sumber dan Eval menunjukkan konfigurasi akhir.

Kartu Sumber GitHub dengan observasi CI. Gambar oleh Penulis.

Setelan Eval: satu aturan, mode observe. Gambar oleh Penulis.

Langkah 4: Uji Kegagalan GitHub Actions yang Tidak Terkait

Gunakan tautan README yang rusak sebagai kegagalan yang tidak terkait. Karena cabang yang dilindungi menolak pemeriksaan yang gagal, gunakan bypass administrator manusia hanya di repositori sekali pakai ini; jangan pernah berikan bypass itu ke agen.

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 pushDidukung oleh

Saat GitHub Actions selesai, docs-check gagal dan revenue-integrity lolos. Itu sesuai dengan aturan yang saya tetapkan: Superagent mengabaikan kandidat karena aturan pendapatan tidak cocok.

Keputusan menggunakan ignoredFromCard, jalan pintas untuk kandidat yang tidak menyentuh aturan aktif. Jadi pemeriksaan ini mencakup perutean, bukan aturannya sendiri.

Kembalikan perubahan README dan tunggu kedua job lolos. Superagent harus mengabaikan pemulihan dan tetap idle.

Langkah 5: Picu Kegagalan CI Revenue Integrity

Gunakan jalur khusus manusia yang sama untuk menambahkan data insiden dari repositori tutorial. Ringkasan ini menunjukkan replay dan pembayaran terpisah pada satu pesanan tanpa kolom stempel waktu:

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,firstDidukung oleh

Repositori menyimpan kolom stempel waktu lengkap; kolom-kolom itu dihilangkan di sini karena tidak menentukan identitas peristiwa. Perhitungan independen yang disiapkan sebelumnya mengharapkan 15.100 sen, jadi tetapkan nilai itu dalam pengujian dan tambahkan 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 passedDidukung oleh

Tambahan 5.000 sen adalah satu pembayaran yang dihitung dua kali. Mengedit 15100 menjadi 20100 atau menghapus uji replay juga akan membuat CI hijau, dan keduanya bukan perbaikan.

Workflow GitHub Actions yang gagal hanya menampilkan revenue-integrity yang gagal. Trigger-nya tiba setelah sekitar satu interval polling.

Eval menandai kandidat "akan diterima," sementara tab Execution tetap kosong. Evaluator melihat nama pemeriksaan dan kesimpulan, bukan log pytest, sehingga ia mengetahui penjaga mana yang gagal tetapi tidak tahu alasannya.

Mode observe hanya mencatat "akan diterima". Gambar oleh Penulis.

Langkah 6: Otorisasi Perbaikan dan Verifikasi Pull Request

Jalur permintaan eksplisit yang dibahas sebelumnya kini mengotorisasi eksekusi. Notifikasi GitHub bisa terlambat.

Tangani penyebutan Issue GitHub yang terlewat

Pada Superagent 6337fc8, Sumber GitHub menumpangtindihkan polling selama lima detik dan membaca thread yang dinotifikasi dari kursor yang lebih baru. Notifikasi penyebutan tiba 21 hingga 23 detik kemudian, sehingga satu polling dapat melompati pesan.

Waktu tersebut menjelaskan mengapa isi Issue baru dan beberapa komentar tidak pernah menjadi Trigger. Laporan komunitas menguraikan mode kegagalan yang sama.

Otorisasi perbaikan dengan komentar GitHub

Kirim ulang permintaan sebagai komentar baru dan konfirmasikan bahwa Trigger-nya muncul. Superagent harus menerimanya sebagai permintaan eksplisit dan memulai pekerja.

Penyebutan komentar membuat Tiket terotorisasi. Gambar oleh Penulis.

Periksa perbaikan deduplikasi peristiwa oleh agen

Pull request yang dihasilkan menautkan perbaikan pada event_id. Tinjau diff alih-alih mengandalkan deskripsinya:

 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")Didukung oleh

Perubahan itu menambahkan uji replay dan tidak menghapus apa pun. Perintah uji pertama gagal karena dependensi hilang. Setelah pekerja membuat virtual environment, suite uji yang terlihat lolos.

Uji pembayaran yang berbagi satu pesanan

Minta perubahan tanpa menyebut agen: buktikan bahwa dua pembayaran pada satu pesanan, identik selain event_id, keduanya dihitung, dan replay dari salah satunya dihitung sekali. Ulasan harus mencapai Tiket yang sama tanpa Eval baru.

Pekerja merespons dengan commit yang hanya menambahkan uji dan membiarkan pipeline tidak berubah. Sebelum persetujuan, periksa SHA head persis dan jalankan ulang suite independen terhadap revisi tersebut.

Umpan balik ulasan melanjutkan Tiket yang sama. Gambar oleh Penulis.

Periksa perbaikan dengan data independen

Jalankan holdout dari lingkungan manusia terpisah terhadap head pull request yang persis. Pada a43c541, kedua suite lolos 5 dari 5 tes tanpa menghapus assertion; 62bac08 mempertahankan pohon yang sama.

Tes yang ditulis agen saja hanya mencakup kasus yang dipilih agen.

Langkah 7: Gabungkan Perbaikan dan Ukur Pemulihan CI

Setelah merge, periksa bahwa main kembali hijau dan bahwa pemulihan tidak memulai pekerjaan baru. Lalu tinjau jejak peristiwa, waktu berlalu, dan biaya penyedia.

Gabungkan perbaikan dan konfirmasi pemulihan CI

Setelah persetujuan manual dan merge, kedua pemeriksaan cabang default lolos. Superagent mengabaikan pemulihan, tidak memulai pekerjaan lagi, dan menutup Tiket yang ada dengan hasil merged.

Evaluasi intake peristiwa dan keputusan

Ikuti setiap peristiwa dari intake hingga hasil, sebagaimana diuraikan dalam panduan mengevaluasi agen AI kami. Di tiga pengulangan, peristiwa yang mencapai Eval menempuh rute yang diharapkan; miss terjadi saat intake, bukan pada Keputusan model.

Ukur kebenaran perbaikan, waktu, dan biaya

Skenario yang sama dijalankan di tiga repositori dan distribusi WSL baru dengan Superagent 6337fc8, Harness 0.2.1-rc.3, deepseek-flash, dan satu kebijakan. Biaya menggunakan tarif DeepSeek off-peak yang lebih rendah; ini adalah reproduksi, bukan tolok ukur.

Ketiga perbaikan menggunakan event_id; setiap uji holdout lolos. Intake lebih bervariasi: penyebutan isi Issue terlewat setiap kali, dan reproduksi ketiga juga melewatkan dua komentar sebelum satu tiba.

Reproduksi kedua menulis ulang commit, dan persetujuan tiba sebelum holdout dijalankan ulang. Pemeriksaan selanjutnya lolos, tetapi urutan yang lebih aman adalah SHA head, holdout, lalu persetujuan.

Keterbatasan dan Pemecahan Masalah DeepSeek Superagent

Beberapa kegagalan di sini tampak seperti keheningan, jadi mulailah dengan mencari di mana sebuah peristiwa berhenti. Bagian yang membuat frustrasi adalah notifikasi yang terlewat dan pengabaian yang benar bisa terlihat sama.

Kegagalan CI yang tidak menghasilkan Trigger

Superagent melacak perubahan pada himpunan yang gagal, jadi pembacaan baseline, pemeriksaan yang terus gagal, dan pemeriksaan yang masih berjalan tidak menghasilkan apa-apa. Trigger tanpa Keputusan biasanya menunjuk pada sel admission CI, bukan model.

Permintaan GitHub yang tidak pernah tiba

Permintaan bisa gagal ketika pengirim tidak diizinkan, Sumber dimatikan, pemrosesan dijeda, atau GitHub terlambat memberi notifikasi. Jika pemeriksaan itu lolos, kirim komentar baru; mengedit isi Issue tidak membuat peristiwa.

Batas perbaikan CI otonom

Prototipe tidak menyediakan batas keamanan. Pekerja memiliki akses penuh pengguna OS, dan aturan pengungkapan adalah teks prompt. Isolasikan akun agen dan batasi pada repositori sekali pakai.

Sebelum beralih ke auto, kumpulkan keputusan yang diamati selama berminggu-minggu, hitung penerimaan yang salah serta pengabaian yang salah, dan pindahkan pekerja dari WSL ke mesin virtual terpisah.

Pemikiran Akhir

Kontras pembuka tetap berlaku: dua status CI merah tidak mengarah pada tindakan yang sama. Superagent mengabaikan docs-check dan menandai revenue-integrity sebagai "akan diterima," sementara mode observe menjaga kode tetap tidak tersentuh hingga seseorang meminta perbaikan.

Patch event_id cukup langsung. Intake notifikasi kurang andal: penyebutan dalam isi Issue tidak pernah mencapai Eval, sehingga aturan yang benar tidak dapat membantu.

Saya tidak akan menggeneralisasi hasil ini untuk perbaikan CI otonom. Repositori kecil, aturan sempit, dan merge dikendalikan manusia. Di tempat lain, mulailah dari hijau, inspeksi Keputusan, otorisasi secara eksplisit, simpan data holdout terpisah, dan merge setelah pemeriksaan independen.

Langkah saya berikutnya adalah memperbaiki jalur notifikasi GitHub dan mengulang alur kerja dengan lebih banyak jenis kegagalan. Sampai bukti itu ada, saya akan tetap mematikan mode auto.