NAME
codex-multi-agent-workflows — Codex dan aliran kerja berbilang ejen: bekerjasama dengan ejen tanpa kehilangan kawalan
SYNOPSIS
cat codex-multi-agent-workflows.md
DESCRIPTION
Kali pertama ejen pengekodan benar-benar membetulkan pepijat untuk anda, reaksinya hampir selalu sama: campuran semangat dan syak wasangka. Bagus, pasti. Tetapi kemudian anda melihat perbezaan dan bertanya kepada diri sendiri: "Ok, tetapi apa sebenarnya yang dia sentuh? Bolehkah saya mempercayainya? Adakah dia akan melakukannya lagi dengan cara yang sama esok?".
Di situlah saya rasa bahagian yang menarik bermula. Bukan apabila ejen menulis fungsi, tetapi apabila ia menjadi cukup berkemampuan untuk melaksanakan keseluruhan kerja: baca repositori, buat tampalan, jalankan ujian, buka PR, kembali selepas ulasan semakan. Codex bergerak tepat ke arah itu: kerja latar belakang, pokok kerja berasingan, penyemak imbas bersepadu, automasi, pemalam, memori dan kawalan kebenaran yang lebih jelas.
Intinya bukan untuk membayangkan masa depan di mana tiada siapa yang membaca kod lagi. Ia akan menjadi masa depan yang mengerikan, serta agak naif. Intinya adalah untuk memikirkan cara bekerja dengan ejen yang boleh melakukan banyak perkara tanpa membiarkan mereka melakukan segala-galanya.
Perubahan tabiat
Dengan autolengkap tradisional anda sentiasa berada di hadapan. AI mencadangkan garis, anda memutuskan. Walau bagaimanapun, dengan ejen, hubungan itu berubah: anda memberinya matlamat dan dia melalui beberapa langkah sendiri.
Ini berkuasa, tetapi ia mengubah masalah. Persoalannya bukan lagi sekadar "bolehkah program model?". Persoalannya menjadi:
- Adakah saya memberinya skop yang cukup kecil?
- adakah anda tahu bagaimana untuk menyemak keputusan?
- Adakah saya bekerja dalam persekitaran terpencil?
- Adakah semakan akhir masih berperikemanusiaan dan berhati-hati?
Aliran kerja yang sihat kelihatan lebih seperti ini daripada tongkat ajaib:
Kedengarannya kurang romantis daripada "ejen membina segala-galanya", tetapi ia berfungsi dengan lebih baik. Dan ini juga cara pasukan yang baik dengan manusia berfungsi: tugas yang jelas, maklum balas cepat, akauntabiliti yang jelas.
Gesaan yang baik adalah hampir tiket yang baik
Gesaan yang paling berbahaya ialah yang samar-samar tetapi yakin: "betulkan halaman invois", "tingkatkan seni bina", "bersihkan modul pengesahan". Ini adalah permintaan yang kelihatan produktif dan menghasilkan perbezaan yang besar. Tetapi kemudian anda mendapati diri anda melakukan arkeologi.
Gesaan yang berguna adalah lebih membosankan. Contohnya: laksanakan eksport CSV untuk halaman invois, dengan mengetahui bahawa jadual berada dalam app/(dashboard)/invoices/page.tsx, pertanyaan berada dalam src/server/invoices.ts dan sudah ada corak yang serupa dalam app/(dashboard)/reports.
Kemudian tambahkan kekangan yang jelas: jangan ubah skema pangkalan data, jangan tambah kebergantungan jika utiliti kecil mencukupi, kekalkan gaya UI sedia ada. Dan tutup dengan pengesahan: npm test -- invoices dan npm run build.
Jenis ringkasan ini bukan untuk "menjelaskan dengan lebih baik kepada AI". Ia berfungsi terutamanya untuk menjelaskan kepada anda perkara yang anda wakilkan. Jika anda tidak dapat menulisnya secara konkrit, mungkin tugasan itu belum siap untuk seorang ejen.
Tiga kerja yang saya rela wakilkan
Yang pertama ialah kerja berulang tetapi boleh disahkan: menambah ujian, memindahkan panggilan ke API dalaman baharu, mengemas kini import, menggantikan komponen yang tidak digunakan, membetulkan ralat TypeScript. Di sini ejen boleh menjimatkan masa dan risiko boleh dikawal.
Yang kedua ialah kerja penerokaan: "cari di mana jumlah ini dikira", "terangkan kepada saya mengapa ujian ini rapuh", "hasilkan semula pepijat dan beritahu saya fail mana yang kelihatan terjejas". Walaupun ia tidak menghasilkan tampalan serta-merta, ia boleh melakukan peninjauan yang berguna.
Yang ketiga ialah kerja penyelenggaraan berulang: kemas kini pergantungan kecil, pembersihan bendera ciri lama, ringkasan PR yang disekat, menyemak TODO yang terlupa. Ia tidak glamor, tetapi ia betul-betul jenis kerja yang cenderung bertimbun.
Tiga pekerjaan yang saya kekalkan sebagai manusia
Keputusan produk kekal sebagai manusia. Jika perubahan mengubah cara pengguna membayar, memadamkan data, melihat harga atau memahami kebenaran, saya mahukan orang yang bertanggungjawab.
Sempadan keselamatan juga patut diberi perhatian manusia: pengesahan, peranan, token, pengelogan data sensitif, migrasi pangkalan data. Ejen boleh membantu melaksanakan, tetapi tidak perlu menjadi pembuat keputusan tunggal.
Akhirnya, saya menyimpan segala-galanya yang memerlukan rasa seni bina manusia. Seorang ejen boleh mencadangkan refactor, tetapi memahami sama ada abstraksi benar-benar perlu atau sama ada kita hanya menggilap masalah yang tidak wujud kekal sebagai pekerjaan.
Semakan itu bukan pilihan
Godaan, apabila ejen adalah baik, adalah untuk mempercayai hijau CI. Ia boleh difahami. Ia juga apabila masalah bermula.
Saya sentiasa melihat sekurang-kurangnya lima perkara:
- Adakah patch hanya menyelesaikan tugas yang diminta?
- Adakah dia menyentuh fail yang tiada kaitan dengannya?
- Adakah ujian merangkumi tingkah laku baru atau hanya peluang gembira?
- Adakah kod mengikut corak tempatan?
- Adakah ralat dikendalikan seperti dalam projek yang lain?
Apabila ada sesuatu yang salah, maklum balas perlu khusus. "Betulkan" malas. Lebih baik: utiliti ini menduplikasi parseMoney menjadi src/lib/money.ts; gunakan semula fungsi itu, tambahkan ujian untuk kes EUR dan jangan ubah API awam modul pengebilan.
Ejen bertindak balas dengan lebih baik kepada ulasan kecil yang boleh disahkan. Anehnya, begitu juga orang ramai.
Pengawal berbaloi dengan usaha
Jika ejen boleh membaca fail, menulis kod dan melaksanakan arahan, ia harus dianggap sebagai proses yang berkuasa. Tidak perlu paranoia, anda memerlukan kebersihan.
Gunakan pokok kerja atau dahan yang berasingan. Jadi anda boleh membandingkan perbezaan, membuang percubaan yang gagal dan tidak mencampurkan kerja ejen dengan apa yang anda lakukan.
Hadkan kebenaran. Perintah seperti rg, git diff, npm test dan npm run build boleh menjadi agak percuma. Deployment, migrasi pangkalan data, akses kepada rahsia dan arahan yang merosakkan mesti kekal jelas.
Kurangkan akses rangkaian apabila anda tidak memerlukannya. Untuk banyak tugas, dokumentasi rasmi, pendaftaran pakej dan perkhidmatan dalaman tertentu adalah mencukupi. Kurang luas permukaan, kurang kejutan.
Jejaki tindakan. Apabila tampalan tiba dalam semakan, anda sepatutnya boleh membina semula gesaan, arahan dilaksanakan, ujian diluluskan dan fail diubah suai. Bukan untuk mewujudkan birokrasi, tetapi untuk dapat memahami apa yang berlaku jika sesuatu berlaku.
Cara mudah untuk bermula sebagai satu pasukan
Jika saya memperkenalkan ejen ke dalam pasukan kecil, saya akan bermula tanpa revolusi besar.
Saya akan membuat label agent-ready untuk isu dengan skop yang jelas. Saya akan menambah templat dengan konteks, kekangan dan arahan pengesahan. Saya akan meminta PR kecil, idealnya di bawah beberapa ratus baris. Saya memerlukan ujian atau tangkapan skrin untuk perubahan yang boleh dilihat. Dan yang paling penting, saya akan memastikan seseorang bertanggungjawab untuk penggabungan itu.
Selepas dua minggu saya akan melihat data: tugas mana yang benar-benar dipercepatkan, ulasan mana yang berat, gesaan mana yang mengelirukan, bahagian asas kod mana yang terlalu rapuh untuk diwakilkan.
Ini adalah pendekatan yang kurang hebat daripada "mulai hari ini kami akan melakukan segala-galanya dengan ejen", tetapi ia adalah pendekatan yang membolehkan anda pergi ke minggu ketiga tanpa penyesalan.
Bahagian yang paling manusia
Perkara yang lucu ialah semakin banyak ejen berautonomi, semakin penting kemahiran klasik itu semula: menulis tiket yang bagus, membuat potongan kecil, mencipta ujian, membaca perbezaan, berkomunikasi pertukaran. Ejen mempercepatkan mereka yang sudah tahu cara bekerja dengan baik. Ia juga menambah kekacauan mereka yang mewakilkan secara teruk.
Jadi tidak, saya tidak melihat aliran kerja berbilang ejen sebagai jalan pintas untuk berhenti melakukan kejuruteraan. Saya melihatnya sebagai cara untuk mengalihkan lebih banyak tenaga kepada bahagian yang penting: memutuskan perkara yang hendak dibina, memastikan ia berfungsi, memastikan sistem dapat difahami.
Ejen boleh menjadi rakan sekerja tak segerak yang hebat. Tetapi rakan sekerja tak segerak, untuk berguna, memerlukan konteks, sempadan dan semakan. Sama seperti orang lain.
Sumber yang berguna
METADATA
- date: 2026-05-24
- reading: 6 min
- author: Filippo Spinella
- tags: AI, Developer Tools, Productivity, Software Engineering