Sejak dua tahun kebelakangan ini, nasihat kerjaya berkaitan ejen AI kebanyakannya tertumpu kepada mempelajari cara mem-prompt ejen tersebut dengan baik. Itu bukan lagi kemahiran yang sukar dicari. Kemahiran yang sukar dicari kini ialah membina rangka kerja (scaffolding) tempat ejen itu beroperasi — sesuatu yang semakin kerap dipanggil harness — dan ia cukup khusus, serta cukup sukar, sehingga ia semakin menjadi satu deskripsi kerja tersendiri berbanding sekadar tanggungjawab sampingan "orang AI" dalam sesebuah pasukan.

Penjelasan awam paling jelas tentang apa yang sebenarnya terlibat datang daripada Lenny's Newsletter, yang mendokumentasikan bagaimana alat pengurusan produk ChatPRD membina satu harness untuk menyahpepijat pepijat Sentry secara automatik. Artikel ini berbaloi dibaca sepenuhnya jika anda sedang menimbangkan sama ada hendak mengkhusus dalam bidang ini, kerana ia menyentuh satu perkara yang mudah terlepas pandang: model itu tidak pernah menjadi kesesakan (bottleneck). Pasukan tersebut menggunakan Claude Agent SDK sebagai asas, kemudian membelanjakan sebahagian besar usaha kejuruteraan mereka untuk membina UI terminal tersuai serta satu set penyesuai (adapter) yang menghubungkan ejen itu dengan Sentry, Linear, GitHub, dan Vercel. Itulah kerja sebenar, dalam bentuk kecil. Empat sistem, empat skema pengesahan (auth) yang berbeza, empat bentuk data yang berbeza, dan satu UI yang membolehkan manusia memerhati dan campur tangan tanpa perlu mengawasi setiap langkah.

Apa yang sebenarnya terkandung dalam "harness"

Jika anda cuba memikirkan sama ada ini satu set kemahiran yang berbaloi dibina, ia membantu untuk memisahkannya kepada bahagian-bahagian yang diambil bekerja secara berasingan, atau sekurang-kurangnya dinilai secara berasingan dalam satu temu duga:

  • Reka bentuk kebenaran. Menentukan apa yang dibenarkan dilakukan oleh ejen tanpa pengawasan (membaca tiket, merangka PR) berbanding apa yang memerlukan kehadiran manusia dalam gelung (menggabungkan/merge, melancarkan/deploy, memadam, membelanjakan wang) — dan mengekod perkara itu sebagai polisi sebenar dalam kod, bukan sekadar arahan prompt yang mungkin diabaikan oleh model apabila tertekan. Ini lebih hampir kepada kejuruteraan kawalan akses berbanding penulisan prompt.
  • Penyesuai alat (tool adapters). Pembalut (wrapper) yang nipis dan diuji dengan baik di sekeliling setiap sistem luaran (Sentry, Linear, GitHub, Vercel, atau apa sahaja timbunan teknologi syarikat anda) yang menterjemahkan niat ejen kepada panggilan API yang selamat dan disahkan, serta menterjemahkan semula respons itu kepada sesuatu yang boleh difahami oleh model. Ini adalah kejuruteraan perisian biasa — pengendalian ralat, cubaan semula (retries), pengesahan skema — yang diterapkan kepada pengguna baharu.
  • UI terminal atau konsol. Satu cara untuk manusia melihat apa yang sedang dilakukan oleh ejen, meluluskan atau menolak tindakan, serta campur tangan apabila ejen tersekat. ChatPRD membina satu UI tersuai; ramai pasukan lain pula akan menggunakan konsol ejen sedia ada, tetapi seseorang tetap perlu menentukan apa yang dipaparkan, apa yang disembunyikan, dan apa yang memerlukan satu klik sebelum sesuatu tindakan berlaku.
  • Pemilihan alat pada skala besar. Satu penulisan daripada Machine Learning Mastery menyorot sesuatu yang berbaloi diketahui jika anda membina apa-apa yang melangkaui sekadar demo: ketepatan ejen dalam panggilan alat cenderung merosot sebaik sahaja katalog alat melebihi kira-kira sedozen pilihan — model mula memanggil alat yang salah, mereka-reka (hallucinate) parameter, atau tersekat pada panggilan yang tidak betul. Langkah mitigasi yang disenaraikan (mengehadkan alat mana yang kelihatan dalam sesuatu konteks, carian alat berasaskan retrieval, penghalaan kepada sub-ejen khusus, langkah perancangan yang eksplisit, logik fallback, dan harness penanda aras untuk mengesan regresi) sendiri merupakan senarai semak perkara yang perlu diketahui oleh seorang jurutera harness tentang cara melaksanakannya, bukan sekadar mengetahui kewujudannya.
  • Kejuruteraan konteks dan memori. Sumber yang sama membuat satu pembezaan yang berbaloi dihayati: kejuruteraan konteks (apa yang dimasukkan ke dalam satu panggilan inferens, dan di mana) dan kejuruteraan memori (apa yang berkekalan merentasi sesi, bagaimana ia disimpan, bagaimana ia diambil semula) adalah dua disiplin berbeza dengan mod kegagalan yang berbeza. Dakwaannya ialah kebanyakan kegagalan dalam ejen yang berjalan lama dan merentasi banyak sesi berpunca daripada mengelirukan kedua-duanya — melayan memori sesi seolah-olah ia sekadar konteks tambahan, atau sebaliknya — terutamanya pada titik di mana sistem menentukan apa yang perlu diambil semula.

Bukti bahawa ini adalah peranan sebenar yang boleh dibiayai — bukan sekadar ceruk hobi

Golongan skeptik secara munasabah akan bertanya sama ada "jurutera harness" itu satu pekerjaan atau sekadar satu tugas dalam pekerjaan orang lain. Dua titik data daripada digest ini menunjukkan ia semakin bergerak ke arah yang pertama. Pertama, pasukan Aspire milik Microsoft — kumpulan seramai 10 orang — menggunakan Agentic Workflows daripada GitHub untuk mengautomasikan PR dokumentasi merentasi pelbagai repositori, dan sepanjang dua pelepasan (release), mereka menggabungkan (merge) 82 PR pada median 44.8 jam selepas PR produk berkaitan dilancarkan, tanpa penambahan kakitangan baharu dan tanpa latihan semula proses. Itu adalah satu pasukan kecil yang memperoleh daya ungkit yang luar biasa besar khususnya kerana seseorang telah melabur dalam rangka kerja (scaffolding) — takrifan aliran kerja, penghalaan semakan, logik pencetus — berbanding membiarkan jurutera menulis PR dokumentasi secara manual. Kedua, projek SkillOpt daripada Microsoft Research melayan fail "kemahiran" (skill) ejen — arahan dan kekangan yang membentuk cara ejen itu berkelakuan dalam harness-nya — sebagai sesuatu yang perlu dioptimumkan secara sistematik berbanding disunting secara manual, dan melaporkan bahawa ia adalah yang terbaik atau setanding terbaik merentasi kesemua 52 sel dalam grid penanda aras (enam penanda aras, tujuh model, tiga mod pelaksanaan), dengan kemahiran yang dioptimumkan itu boleh dipindahkan merentasi model dan harness yang berbeza. Sama ada alat khusus itu akan menjadi standard atau tidak, ia memberi isyarat bahawa industri kini mula melayan konfigurasi harness sebagai satu artifak kejuruteraan yang mempunyai peralatan dan penanda arasnya sendiri — trajektori yang sama yang mengubah "DevOps" daripada satu set skrip ad hoc kepada satu disiplin.

Terdapat juga infrastruktur yang kini sedang dibina secara khusus untuk lapisan ini. Keupayaan "Managed Agents" yang baru diumumkan oleh Google dalam Gemini API — pelaksanaan latar belakang dan tak segerak (async), integrasi pelayan MCP jauh, pemanggilan fungsi tersuai, penyegaran bukti kelayakan (credential) merentasi interaksi — pada dasarnya merupakan sistem paip yang telah siap terbina untuk masalah yang tepat sama yang diselesaikan secara manual oleh pasukan ChatPRD. Itu adalah corak yang biasa: apa yang dibina secara tersuai oleh satu pasukan tahun ini, akan diproduktokan oleh vendor platform pada tahun hadapan. Ia tidak menghapuskan peranan kejuruteraan harness; sebaliknya ia menaikkan aras minimum dan mengalihkan tumpuan kerja kepada mengintegrasikan serta mengkonfigurasi primitif terurus (managed primitives) berbanding menulis setiap penyesuai dari awal, sama seperti bagaimana infrastruktur awan tidak menghapuskan jurutera operasi (ops), sebaliknya ia mengubah cara mereka membahagikan masa mereka.

Apa maksudnya jika anda mensasarkan peranan ini

Beberapa perkara konkrit dan boleh disemak untuk dimasukkan ke dalam portfolio atau resume jika anda mahu kelihatan kredibel untuk kerja ini: bina satu penyesuai (adapter) hujung ke hujung terhadap satu API sebenar yang tidak anda kawal (termasuk pengesahan/auth, pengendalian ralat, had kadar/rate limits, bukan sekadar demo laluan mudah); reka bentuk dan dokumenkan satu model kebenaran untuk ejen yang membezakan tindakan baca/cadang/lakukan (read/propose/act) serta menunjukkan sebab setiap sempadan itu diletakkan di situ; dan bina atau konfigurasikan satu antara muka semakan di mana manusia meluluskan tindakan ejen sebelum ia dilaksanakan, kerana itulah bahagian yang akan disyaratkan oleh kebanyakan syarikat sebelum membenarkan ejen menyentuh persekitaran produksi. Jika anda sedang menilai tawaran kerja kejuruteraan harness atau menentukan skop tanggungjawab anda sendiri, tanya secara khusus siapa memiliki model kebenaran, siapa memiliki penyesuai-penyesuai itu, dan siapa memiliki permukaan semakan manusia — dalam kebanyakan pasukan pada masa ini, ketiga-tiga perkara itu tiada pemilik yang jelas, dan itulah tepatnya jurang yang cuba diisi oleh peranan ini.

Satu amaran yang berbaloi dinyatakan dengan jelas: tiada satu pun sumber di atas mengesahkan angka pasaran pengambilan pekerja untuk jawatan khusus ini, dan "jurutera harness" bukanlah jawatan yang akan anda lihat dalam iklan pekerjaan buat masa ini — ia muncul di dalam jawatan seperti "jurutera infrastruktur AI," "jurutera platform ejen," atau sekadar "jurutera backend kanan, sistem AI." Anggaplah ini sebagai satu set kemahiran untuk dibina dan diterangkan dengan tepat, bukan satu jawatan untuk dicari di LinkedIn.