Mengatur agen menggunakan alur kerja GitHub
Setelah tanggung jawab jelas, fokus bergeser ke bagaimana agen mengoordinasikan pekerjaan mereka. Bahkan peran yang terdefinisi dengan baik dapat menyebabkan kebingungan jika eksekusi tidak terstruktur. Pikirkan tentang kapan agen harus berjalan, bagaimana pekerjaan mereka diurutkan, dan bagaimana output bergerak di antara langkah-langkah. Mengekspresikan koordinasi ini melalui alur kerja GitHub membuat sistem tetap dapat diprediksi, diamati, dan lebih mudah dikelola saat berkembang.
Di unit ini, Anda akan belajar
Bagaimana peristiwa GitHub mengoordinasikan perilaku agen
Cara merancang orkestrasi berurutan dan paralel
Cara menggunakan artefak untuk koordinasi alih-alih komunikasi langsung
Mengapa orkestrasi harus tetap dapat diamati
Apa itu orkestrasi dalam sistem multi-agen
Orkestrasi dalam sistem multi-agen menentukan bagaimana beberapa agen mengoordinasikan pekerjaan mereka dalam lingkungan bersama. Ini menentukan kapan agen berjalan, bagaimana tugas mereka diurutkan, dan bagaimana output diteruskan di antara langkah-langkah, memastikan bahwa pekerjaan berlangsung dengan cara yang terkontrol dan dapat diprediksi daripada terjadi secara independen atau bertentangan.
Cara kerja orkestrasi di GitHub
Dalam GitHub, orkestrasi berfungsi paling baik ketika diekspresikan melalui alur kerja yang merespons peristiwa. Hal ini membuat koordinasi tetap terlihat karena berlangsung di pull request, workflow run, check, dan log.
Pemicu umum meliputi:
jadwal untuk pekerjaan berkala (pelaporan, pemeriksaan dependensi),
peristiwa permintaan pull untuk validasi dan iterasi, dan
Pemicu penyelesaian alur kerja digunakan ketika satu langkah harus dijalankan setelah langkah lainnya.
Ini penting karena koordinasi tersembunyi membuat kegagalan tidak mungkin untuk didiagnosis.
Orkestrasi berurutan
Beberapa pekerjaan harus terjadi dalam urutan yang ketat. Pipeline yang umum adalah:
- Agen dependensi membuka PR.
- CI memastikan kebenaran (pengujian/kompilasi).
- Alur kerja validasi keamanan berjalan setelah CI selesai.
- Peninjau manusia menyetujui.
- Penggabungan hanya terjadi ketika gerbang terpenuhi.
Contoh: jalankan validasi keamanan setelah CI selesai:
\# File: .github/workflows/security-validate.yml
name: Security Validation
on:
workflow_run:
workflows: [CI Validation]
types: [completed]
jobs:
validate:
runs-on: ubuntu-latest
steps:
\- run: echo "Run security validation here."
Gunakan pola ini ketika output satu agen harus divalidasi sebelum langkah lain dapat dilanjutkan.
Orkestrasi paralel
Orkestrasi paralel tepat jika batasan cakupan mencegah tumpang tindih. Misalnya, agen dokumentasi dan agen refaktor dapat bekerja secara bersamaan jika beroperasi di jalur terpisah. Output mereka tetap digabungkan melalui pemeriksaan dan peninjauan pull request.
Persyaratan desain utama untuk orkestrasi paralel adalah isolasi: jika agen dapat saling berbenturan saat mengakses file yang sama, paralelisme akan meningkatkan ketidakstabilan alih-alih laju pemrosesan.
Contoh: Pola Orkestrasi Fan-Out, Fan-In
Untuk mengoordinasikan beberapa agen secara paralel lalu menggabungkan outputnya, gunakan orkestrasi fan-out/fan-in dengan kebutuhan. Pola ini diuji dalam ujian dan merupakan praktik terbaik untuk menyusun fase analisis/tinjau/penggabungan.
name: multi-agent-orchestration
on:
workflow_dispatch:
jobs:
spec_analyzer:
runs-on: ubuntu-latest
steps:
- name: Run spec analyzer
run: ./executors/spec_analyzer.sh
risk_reviewer:
runs-on: ubuntu-latest
steps:
- name: Run risk reviewer
run: ./executors/risk_reviewer.sh
plan_merger:
runs-on: ubuntu-latest
needs: [spec_analyzer, risk_reviewer] # <--- FANS IN both
steps:
- name: Merge analysis and risk outputs
run: ./executors/plan_merger.sh
- name: Publish merged plan
run: echo "publish plan artifact"
concurrency:
group: multiagent-${{ github.ref }} # <-- Ensures no overlapping merge jobs per branch
Ini memastikan plan_merger menunggu kedua job upstream—sebuah "fan-in" klasik.
Koordinasi berbasis artefak
Dalam sistem multi-agen, "komunikasi agen-ke-agen" langsung sering kurang dapat diandalkan daripada artefak bersama yang dapat ditinjau. Pola orkestrasi yang andal adalah:
- menjalankan agen dengan izin terbatas,
- menghasilkan output terstruktur (rencana/laporan/proposal) sebagai artefak, lalu
- gunakan langkah terkontrol untuk menerapkan hanya operasi yang diizinkan alur kerja Anda.
Pola ini menciptakan batas eksplisit antara "penalaran" dan "penulisan," dan meninggalkan bukti yang dapat diperiksa oleh peninjau.
Contoh: laporan repositori terjadwal (artefak + output terkontrol)
# File: .github/workflows/daily-repo-report.yml
name: Daily Repo Status Report
on:
schedule:
- cron: "0 2 * * *"
permissions:
contents: read
issues: write
pull-requests: read
jobs:
report:
runs-on: ubuntu-latest
steps:
- name: Generate report
run: |
echo '{ "summary": "Daily status...", "links": [] }' > report.json
- name: Upload report artifact
uses: actions/upload-artifact@v4
with:
name: repo-status-report
path: report.json
- name: Create issue (controlled output)
run: |
echo "Create issue from report.json"
Apa yang terjadi ketika orkestrasi disembunyikan
Jika koordinasi terjadi di luar GitHub dan tidak meninggalkan bukti dalam permintaan pull atau alur kerja berjalan, peninjau kehilangan kemampuan untuk memahami mengapa sistem berperilaku seperti yang dilakukannya. Ini membuat kegagalan lebih sulit untuk mendiagnosis dan mengurangi kepercayaan.
Poin utama
Orkestrasi harus diekspresikan melalui peristiwa GitHub Actions dan artefak bersama sehingga sistem tetap dapat diamati. Gunakan orkestrasi berurutan saat output bergantung pada langkah-langkah sebelumnya. Gunakan orkestrasi paralel hanya ketika agen beroperasi pada jalur terisolasi.
Setelah alur kerja dikoordinasikan, Anda harus memastikan agen tidak saling mengganggu selama eksekusi.