Kejuruteraan Gelung.
Penulis asal: Addy Osmani
Dikompilasi oleh Peggy, BlockBeats

Catatan editor: Cara penggunaan AI coding agent sedang berubah dari "manusia menulis Prompt secara manual dan mendorong tugas secara bertahap" kepada "manusia merancang kitaran, membolehkan sistem mengagendakan agent secara berterusan". Loop Engineering yang disebut oleh Addy Osmani, intinya ialah membina aliran kerja yang boleh secara automatik mengenal pasti tugas, mengagendakan tugas, memeriksa keputusan, merekodkan kemajuan, dan menentukan langkah seterusnya.

Litar ini secara kasarnya terdiri daripada lima modul: Automations (mengesan dan mengesahkan tugas secara berkala), Worktrees (mengasingkan pelbagai persekitaran pembangunan selari), Skills (mengumpulkan pengetahuan projek dan amalan pasukan), Plugins/Connectors (menghubungkan alat sebenar seperti GitHub, Linear, Slack, dan pangkalan data), Sub-agents (memisahkan pelaksana dan pemeriksa), ditambah dengan lapisan ingatan luaran, seperti fail Markdown atau papan Linear, untuk menyimpan status dan kemajuan.

Artikel tersebut mengingatkan bahawa maksud Loop Engineering bukan sekadar "membuat AI berjalan lebih banyak putaran", tetapi membawa pertimbangan jurutera ke dalam reka bentuk sistem. Gelung boleh memperbesarkan daya ungkit kerja pembangun secara ketara, tetapi tidak akan menggantikan pengesahan, pemahaman, dan penilaian. Risiko sebenar bukan terletak pada penggunaan gelung, tetapi pada penggunaan gelung sebagai alasan untuk mengelakkan pemahaman terhadap kod dan sistem. Kemampuan utama untuk bekerjasama dengan AI dalam pemrograman di masa depan mungkin bukan lagi sekadar menulis Prompt yang baik, tetapi merekabentuk alur kerja Agent yang boleh dipercayai, boleh disahkan, dan boleh beroperasi secara berterusan.

Berikut ialah teks asal:

Loop engineering (rekabentuk kitaran) sedang menggantikan peranan anda sebagai “orang yang menulis petunjuk untuk agen”. Anda perlu merekabentuk satu sistem yang akan menggantikan anda dalam memberikan petunjuk kepada agen. Di sini, loop (kitaran) boleh difahami sebagai satu sasaran berulang: anda mentakrifkan satu tujuan, dan AI akan berulang kali mengitari hingga tugas selesai. Ia secara kasarnya terdiri daripada lima komponen, dan Claude Code serta Codex kini sudah memiliki kelima-lima komponen ini.

Saya percaya, ini mungkin cara kita akan bekerja sama dengan agen kod di masa depan. Namun, semua ini masih dalam peringkat awal, dan saya tetap meragukannya. Anda benar-benar perlu berhati-hati terhadap kos token, kerana perbezaan kos boleh sangat besar bergantung kepada model penggunaan anda, terutamanya sama ada anda "kaya token" atau "tekanan token". Anda juga perlu mempunyai mekanisme tertentu untuk memastikan kualiti tidak menurun. Kekhawatiran mengenai "hasil AI sampah" (slop) juga munasabah. Walaupun begitu, mari kita lihat apa sebenarnya yang berlaku.

@steipete baru-baru ini mengatakan: "Anda seharusnya tidak lagi memberikan petunjuk kepada agen pengkodean. Anda harus merancang beberapa gelung yang akan memberikan petunjuk kepada agen anda." Secara serupa, pemimpin Claude Code dari Anthropic, @bcherny, juga berkata: "Saya sekarang tidak lagi memberikan petunjuk kepada Claude. Saya mempunyai banyak gelung yang berjalan, yang akan memberikan petunjuk kepada Claude dan menentukan langkah seterusnya sendiri. Pekerjaan saya hanyalah menulis gelung."

So, what does this actually mean?

Dalam dua tahun terakhir, jika anda ingin meminta agen pengkodean melakukan sesuatu, cara asasnya ialah menulis petikan yang baik dan menyediakan konteks yang mencukupi. Anda memasukkan satu ayat, membaca hasilnya, kemudian memasukkan ayat seterusnya. Agen itu adalah alat, dan anda sentiasa memegang alat ini, mendorongnya berulang-ulang. Tahap ini某种程度上已经结束了，至少有些人认为它即将结束。

Sekarang, anda membina sebuah sistem kecil: ia akan mengenal pasti tugas sendiri, mengagihkan tugas, memeriksa keputusan, merekodkan status penyelesaian, lalu menentukan langkah seterusnya. Dengan kata lain, anda membiarkan sistem ini menggerakkan agen, bukan anda yang terus-menerus memberikan arahan kepadanya. Saya sebelum ini telah menulis «kerabat terdekat»nya — agent harness engineering (kejuruteraan rangka kerja agen), iaitu membina persekitaran operasi untuk satu agen tunggal; serta factory model (model pabrik), iaitu sistem yang membina perisian. Loop engineering pula berada di atas peringkat harness. Ia seperti harness, tetapi beroperasi mengikut timer, menghasilkan pembantu kecil, dan mampu membesarkan dirinya sendiri.

Yang mengejutkan saya, ini sekarang sudah bukan lagi masalah "peringkat alat". Setahun yang lalu, jika anda ingin membuat loop, anda perlu menulis banyak skrip bash, kemudian sentiasa menyelenggarakan skrip-skrip itu. Ia adalah milik anda sendiri, dan hanya milik anda sendiri. Sekarang, komponen-komponen ini sudah secara langsung dibina ke dalam produk. Kemampuan yang disenaraikan oleh Steinberger hampir boleh disepadankan satu-satu dengan aplikasi Codex, dan hampir sama juga dengan Claude Code. Sekali anda sedar bahawa bentuknya adalah sama, anda tidak akan lagi bimbang sama ada harus menggunakan alat mana, tetapi akan mula mereka bentuk satu loop: sama ada anda duduk di dalam alat mana pun, ia akan terus beroperasi.

Lima komponen, serta beberapa penerangan

Satu gelung memerlukan lima perkara, ditambah dengan satu tempat untuk mengingat maklumat. Saya akan senaraikan dahulu, kemudian padankan satu per satu.

Pertama, Automations (tugasan automatik): dipicu mengikut jadual, secara automatik mengesan dan mengalihkan.

Kedua, Worktrees: Memastikan dua agen yang bekerja secara serentak tidak saling mengganggu fail masing-masing.

Ketiga, Skills (kemahiran): Tuliskan pengetahuan projek untuk mengelakkan agen menebak setiap kali.

Keempat, Plugins and connectors (plug-in dan penghubung): Membolehkan agen menyambung ke alat yang sudah anda gunakan.

Kelima, Sub-agents (sub-agents): satu bertanggungjawab untuk mencadangkan penyelesaian, dan yang lain bertanggungjawab untuk memeriksa penyelesaian tersebut.

Kemudian, perkara keenam: memory (ingatan). Ia boleh berupa fail Markdown, papan Linear, atau mana-mana tempat yang berdiri sendiri di luar percakapan tunggal dan mampu menyimpan "perkara yang telah selesai" dan "perkara seterusnya". Kelihatan ringkas sehingga seolah-olah ia bukan perkara penting, tetapi ini adalah teknik yang sama yang digunakan oleh semua agen jangka panjang. Saya juga telah menulisnya secara terperinci dalam agen jangka panjang: model akan melupakan segala sesuatu di antara setiap pelaksanaan, jadi ingatan mesti disimpan di cakera, bukan dalam konteks. Agen akan lupa, tetapi repositori kod tidak akan lupa.

Sekarang, kedua-dua produk telah memiliki lima komponen ini.

Nama-namanya berbeza di beberapa tempat, tetapi kemampuannya pada dasarnya adalah perkara yang sama. Saya akan terangkan satu per satu, kerana sejujurnya, sama ada satu loop beroperasi dengan stabil atau bocor diam-diam di mana-mana, kuncinya terletak pada butiran-butiran.

Automations adalah apa yang menjadikan loop benar-benar menjadi loop, bukan sekadar tugas satu kali yang anda jalankan secara manual. Di aplikasi Codex, anda boleh mencipta tugas automasi di tab Automations, memilih projek, petunjuk yang perlu dijalankan, frekuensi pelaksanaan, serta sama ada ia berjalan di local checkout anda atau di worktree latar belakang. Hasil pelaksanaan yang mengesan isu akan masuk ke inbox Triage, manakala pelaksanaan tanpa isu akan diarkibkan secara automatik—ia sangat berguna. OpenAI sendiri menggunakannya untuk tugas-tugas membosankan tetapi perlu seperti pengagihan isu harian, ringkasan sebab kegagalan CI, penulisan ringkasan commit, dan pemantauan bug yang diperkenalkan minggu lepas. Tugas automasi juga boleh memanggil skill, jadi anda boleh mengekalkan tugas berulang agar mudah diselenggarakan: gunakan $skill-name, bukan menyalin seluruh petunjuk panjang ke dalam tugas jadual yang tidak akan diperbaharui oleh siapa pun kelak.

Claude Code juga boleh mencapai kesan yang sama, hanya dengan jalan yang berbeza: ia melakukannya melalui penjadualan dan hook. Anda boleh menjalankan petikan atau arahan pada selang masa tetap menggunakan /loop, menjadualkan tugas cron, atau memicu arahan shell pada titik tertentu dalam kitaran hidup agen. Jika anda ingin ia terus berjalan selepas anda menutup komputer, anda juga boleh mendorong keseluruhan sistem ke GitHub Actions. Idea ini sama sepenuhnya: anda mentakrifkan satu tugas autonomi, memberinya irama, dan membiarkan hasil penemuan datang kepada anda, bukan anda yang perlu pergi semak di mana-mana.

Satu lagi primitif dalaman yang perlu diketahui, yang lebih dekat dengan inti sebenar yang dibincangkan dalam artikel ini. /loop akan berjalan berulang-ulang mengikut irama; /goal pula akan terus berjalan sehingga syarat yang anda tulis benar-benar tercapai. Selepas setiap putaran, satu model kecil yang berasingan akan menilai sama ada tugas telah selesai, jadi agen yang menulis kod bukanlah yang memberi penilaian kepada dirinya sendiri. Anda boleh memberikan syarat seperti “semua ujian dalam test/auth lulus, dan lint bersih”, kemudian tinggalkan. Codex juga mempunyai kemampuan yang sama, yang juga dipanggil /goal. Ia akan terus bekerja merentasi putaran sehingga syarat berhenti yang boleh diverifikasi tercapai, dan menyokong jeda, pemulihan, dan pembersihan. Primitif yang sama, kedua-dua alat ini memilikinya. Ini pada dasarnya adalah corak yang berulang-ulang muncul dalam artikel ini.

Oleh itu, Automations bertanggungjawab untuk membawa kerja ke permukaan. Bahagian lain loop pula bertanggungjawab untuk mengendalikan kerja-kerja tersebut.

Apabila anda menjalankan lebih daripada satu agen, konflik fail akan menjadi titik kegagalan. Dua agen yang menulis fail yang sama secara serentak adalah seberapa rumitnya dua jurutera yang mengubah baris kod yang sama tanpa berkomunikasi. Git worktree boleh menyelesaikan masalah ini. Ia adalah direktori kerja yang berasingan pada cabang yang berasingan, tetapi berkongsi sejarah repositori kod yang sama, dengan itu, perubahan satu agen secara fizikal tidak akan menyentuh checkout agen lain.

Codex secara langsung menyediakan sokongan worktree, jadi beberapa thread boleh memproses repositori yang sama secara serentak tanpa berlanggar. Claude Code juga boleh mencapai isolasi yang sama melalui git worktree: anda boleh membuka sesi dalam checkout berasingan dengan flag --worktree, atau menetapkan isolation: worktree pada subagent, supaya setiap agen kecil mendapat checkout baharu dan dibersihkan secara automatik selepas selesai. Saya pernah menulis mengenai aspek manusia dalam the orchestration tax: worktrees dapat menghilangkan konflik mekanikal, tetapi anda masih tetap menjadi had. Yang benar-benar menentukan berapa banyak agen yang boleh anda jalankan secara serentak bukanlah alat, tetapi bandwidth penilaian anda.

Skill adalah mekanisme yang membolehkan anda tidak perlu menjelaskan konteks item yang sama semula setiap sesi seperti ikan emas. Dua alat ini menggunakan format yang sama: satu folder yang mengandungi SKILL.md untuk menyimpan penerangan dan metadata; selain itu, boleh juga ada skrip, rujukan, dan fail sumber pilihan. Codex akan menjalankan skill apabila anda memanggilnya dengan $ atau /skills, dan juga akan menjalankannya secara automatik apabila tugas anda sepadan dengan penerangan skill tersebut. Inilah sebabnya mengapa penerangan yang ringkas dan sederhana sering lebih baik daripada penerangan yang cerdik dan mewah. Pendekatan Claude Code juga sama, dan saya telah menulis pola ini dalam agent skills.

Kemahiran juga merupakan tempat di mana niat tidak lagi menghabiskan tenaga anda berulang-ulang. Saya telah menyebut dalam intent debt bahawa setiap kali sesi agen bermula, ia bermula dari keadaan sejuk; selagi terdapat ruang kosong dalam niat anda, ia akan mengisi ruang itu dengan tekaan yang percaya diri. Kemahiran adalah cara untuk menulis niat ini secara luaran: perjanjian projek, langkah-langkah pembinaan, “kita tidak melakukan ini kerana kejadian itu pernah berlaku sebelum ini” dan sebagainya, ditulis sekali sahaja di tempat yang akan dibaca oleh agen setiap kali ia berjalan. Tanpa kemahiran, setiap putaran loop perlu menurunkan semula keseluruhan projek anda dari awal; dengan kemahiran, ia menjadi sedikit seperti pertumbuhan faedah berkompaun.

Ada satu perkara yang perlu dibezakan: skill adalah format penulisan, manakala plugin adalah cara pengagihan. Apabila anda ingin berkongsi satu skill di antara beberapa repositori kod, atau menggabungkan beberapa skill bersama-sama, anda akan membungkusnya sebagai satu plugin. Codex begitu juga, Claude Code pun begitu.

Satu loop yang hanya dapat melihat sistem fail adalah loop yang sangat kecil. Connector dibina berdasarkan MCP, membolehkan agen membaca tracker isu anda, meng查询 pangkalan data, memanggil API staging, atau menghantar mesej di Slack. Codex dan Claude Code kedua-duanya menyokong MCP, jadi connector yang anda tulis untuk salah satu biasanya juga boleh digunakan di yang lain. Plugin pula menggabungkan connector dan kemahiran bersama-sama, supaya rakan sepasukan anda boleh memasang konfigurasi lengkap sekali gus, bukan mencuba memulihkan keseluruhan sistem dari ingatan.

Inilah perbezaan antara「seorang agen memberitahu anda『ini adalah penyelesaian pembaikan』」dan「sebuah loop yang membuka PR sendiri, mengaitkan ticket Linear, dan memberitahu saluran selepas CI berjaya». Connector penting kerana ia membolehkan loop bertindak dalam persekitaran sebenar anda, bukan sekadar memberitahu anda『jika saya boleh, saya akan lakukan ini』.

Dalam satu gelung, rekabentuk struktur yang paling berguna ialah memisahkan «pembina» dan «pemeriksa». Model yang menulis kod terlalu mudah menjadi terlalu memaafkan semasa menilai tugasan sendiri. Satu agen lain dengan arahan yang berbeza, dan kadang-kadang menggunakan model yang berbeza, mampu menangkap masalah yang diabaikan oleh agen pertama selepas meyakinkan diri sendiri.

Codex hanya akan menghasilkan subagent apabila anda meminta, dan subagent-subagent ini akan berjalan secara selari sebelum menggabungkan hasil menjadi satu jawapan. Anda boleh mentakrifkan agent sendiri dalam fail TOML di .codex/agents/: setiap agent mempunyai nama, perihalan, arahan, serta model dan kekuatan penarikan pilihan. Oleh itu, pemeriksa keselamatan anda boleh menjadi model kuat dengan kekuatan penarikan tinggi, manakala peneroka anda boleh menjadi model ringan yang pantas dan hanya baca. Claude Code juga menyediakan kemampuan serupa melalui subagent dan pasukan agent di .claude/agents/, membolehkan beberapa agent menghantar kerja antara satu sama lain. Pembahagian tugas yang paling biasa di kedua-dua pihak ialah: satu agent meneroka, satu agent melaksanakan, dan satu agent mengesahkan mengikut spesifikasi.

Saya telah menyatakan pandangan ini dua kali: sekali di code agent orchestra, dan sekali lagi di adversarial code review. Ia sangat penting dalam loop, kerana loop akan berjalan tanpa pengawasan anda, jadi satu-satunya sebab anda berani pergi ialah mempunyai verifier yang benar-benar anda percayai. Subagents memang menghabiskan lebih banyak token, kerana setiap agent perlu membuat panggilan model dan panggilan alat sendiri, jadi anda sepatutnya menggunakannya di tempat-tempat di mana 'pendapat kedua' layak dibayar. Ini pada dasarnya juga apa yang dilakukan oleh /goal Claude Code di peringkat bawah: ia menggunakan model baru untuk menilai sama ada loop telah selesai, bukan membiarkan model yang melakukan kerja itu menilainya. Dengan kata lain, ia menerapkan pemisahan antara 'pembuat' dan 'pemeriksa' kepada syarat penghentian itu sendiri.

Bagaimana bentuk satu loop

Gabungkan semua perkara ini, satu thread tunggal akan menjadi panel kawalan kecil. Di bawah adalah struktur yang sering saya gunakan.

Setiap pagi, sebuah automasi berjalan di repositori kod. Promp-nya memanggil kemahiran triage, membaca kegagalan CI semalam, isu yang masih terbuka, dan commit terkini, kemudian mencatat temuan ke dalam fail Markdown atau papan Linear. Untuk setiap isu yang patut ditangani, thread akan membuka worktree yang dipisahkan, menghantar sub-agennya untuk menggariskan penyelesaian, kemudian menghantar sub-agennya yang kedua untuk meninjau penyelesaian tersebut berdasarkan kemahiran projek dan ujian yang sedia ada.

Connector membolehkan loop ini membuka PR secara automatik dan mengemas kini ticket. Mana-mana perkara yang tidak dapat ditangani oleh loop akan masuk ke inbox triage untuk saya tangani. Fail status adalah tulang belakang keseluruhan sistem: ia mengingat apa yang telah cuba, apa yang berjaya, dan apa yang masih belum selesai. Oleh itu, operasi pada pagi hari berikutnya akan bermula dari tempat dihentikan hari ini.

Perhatikan apa yang sebenarnya kamu lakukan. Kamu hanya merancang satu kali. Langkah-langkah tersebut bukanlah kamu yang secara perlahan memberikan petunjuk satu per satu. Inilah versi nyata dari perkataan Steinberger. Dan loop yang sama boleh dijalankan di Codex atau di Claude Code, kerana binaan asasnya adalah binaan yang sama.

Loop masih tidak akan melakukan apa-apa untuk anda

Loop mengubah cara kerjanya, tetapi tidak akan mengeluarkan anda daripada pekerjaan. Sebenarnya, semakin kuat loop, tiga masalah akan menjadi lebih tajam, bukan lebih mudah.

Pengesahan masih bergantung pada anda. Satu loop yang berjalan tanpa pengawasan juga mungkin sedang membuat kesilapan tanpa pengawasan. Anda memisahkan sub-agent verifier dan pembuat pesanan kerana ingin membuat perkataan «selesai» yang diucapkan oleh loop sedikit bermakna. Walaupun begitu, «selesai» masih merupakan satu pernyataan, bukan bukti. Saya terus mengulangi perkataan yang sama dalam code review in the age of AI: tanggungjawab anda ialah menghantar kod yang anda pastikan berkesan.

Jika anda membiarkannya, pemahaman anda sendiri akan terus membusuk. Semakin cepat Loop menghantar kod yang tidak anda tulis sendiri, semakin besar jurang antara apa yang anda fahami secara sebenar dan apa yang benar-benar wujud dalam sistem. Inilah yang disebut comprehension debt (hutang pemahaman). Jika anda tidak membaca apa yang dihasilkan oleh Loop, satu loop yang lancar hanya akan mempercepat pertumbuhan hutang ini.

Dan ya, postur yang paling selesa kemungkinan besar juga merupakan postur yang paling berbahaya. Apabila loop mampu berjalan sendiri, anda mudah berhenti membentuk penilaian sendiri dan hanya menerima apa sahaja yang ia kembalikan. Saya menyebut ini sebagai cognitive surrender (penyerahan kognitif). Jika anda merekabentuk loop dengan membawa penilaian, ia adalah penawar; jika anda merekabentuk loop hanya untuk mengelakkan pemikiran, ia adalah pemercepat. Tindakan yang sama akan menghasilkan kesan yang bertentangan sepenuhnya.

Bina loop, tetapi tetap menjadi jurutera

Saya percaya, ini menandakan arah evolusi kerja kami di masa depan. Namun demikian, jika saya tidak mengulas kod secara langsung, atau sepenuhnya bergantung pada auto-loop untuk memperbaiki kod, kualiti produk saya akan terjejas. Saya sangat mungkin terperangkap dalam spiral menurun: terus-menerus menggali diri saya ke dalam lubang yang lebih dalam.

Jadi, anda tentu boleh membina loop sendiri, tetapi jangan lupa bahawa memberi arahan langsung kepada agen pintar anda masih berkesan. Kuncinya ialah mencari keseimbangan yang sesuai.

Hasil Loop juga akan berbeza mengikut individu. Dua orang boleh membina loop yang sama persis, tetapi mendapat hasil yang bertentangan. Seorang menggunakannya untuk mempercepatkan kerja yang mereka fahami dengan mendalam; orang lain menggunakannya untuk mengelak daripada memahami kerja itu sendiri. Loop tidak mengetahui perbezaan antara keduanya. Anda tahu.

Inilah sebabnya reka bentuk loop lebih sukar daripada kejuruteraan prompt, bukan lebih mudah. Maksud Cherny bukanlah kerja menjadi lebih ringan, tetapi titik tuas telah berpindah.

Bina loop. Tetapi bina ia seolah-olah anda masih berniat menjadi jurutera, bukan seolah-olah anda hanya bertanggungjawab untuk menekan butang «mulakan».

[Link asal]

Klik untuk mengetahui jawatan yang sedang dilamar oleh BlockBeats

Selamat datang ke komuniti rasmi律动 BlockBeats:

Kumpulan langganan Telegram: https://t.me/theblockbeats

Kumpulan perbincangan Telegram: https://t.me/BlockBeats_App

Akaun rasmi Twitter: https://twitter.com/BlockBeatsAsia