Human-in-the-Loop untuk AI Agent

Reka Bentuk AI Agent Human-in-the-Loop ditunjukkan sebagai jambatan kelulusan yang menghentikan satu tindakan berisiko tinggi sementara kerja selamat diteruskan

Turn this article into takeaways for your work.

Each assistant summarizes the article only for you and suggests best practices for your work.

Human-in-the-loop untuk AI agent bermaksud membina titik tertentu dalam gelung agent di mana ia berhenti dan menunggu seseorang sebelum meneruskan, dan bukan membiarkannya berjalan dari awal hingga akhir sendirian. Tujuannya bukan untuk memperlahankan agent di mana-mana. Ia untuk meletakkan jeda tepat di tempat tindakan yang salah akan mahal, tidak boleh dipulihkan, atau sukar dijelaskan kemudian, dan tidak di tempat lain. Letakkan dengan betul dan agent berjalan tanpa pengawasan pada segala yang lain; letakkan dengan salah ke mana-mana arah dan anda sama ada menjadikan agent tersekat hingga tidak berguna atau melancarkan agent yang bertindak atas pertimbangan buruk yang tiada siapa tangkap tepat pada masanya.

Apa Maksud Human-in-the-Loop bagi Agent, Secara Khusus

Konsep umum human-in-the-loop merangkumi banyak kes penggunaan AI: melabel data latihan, mengesahkan ramalan model, menyemak kandungan sebelum diterbitkan. Bagi AI agent secara khusus, yang menjalankan gelung mengamati, menaakul, bertindak, memerhati yang boleh melaksanakan banyak langkah berturut-turut, soalannya lebih sempit dan lebih mekanikal: pada langkah mana tepatnya agent berhenti dan menunggu, dan apa yang diserahkannya kepada manusia supaya penantian itu berbaloi? Jika anda belum memutuskan sama ada sesuatu proses sesuai untuk agent, bila hendak menggunakan AI agent ialah semakan kesediaan yang patut dijalankan dahulu. Artikel ini menganggap anda telah melepasi tahap itu dan kini mereka bentuk serahan.

"Manusia patut menyemak tindakan agent" bukan spesifikasi yang boleh dibina atau diaudit sesiapa. "Sebelum sebarang langkah Execute yang menghantar komunikasi luaran, mengubah rekod kewangan, atau mengubah suai rekod di luar pasukan pemilik tugas, agent berhenti dan mengemukakan permintaan kelulusan yang khusus" ialah spesifikasi. Itulah peralihan yang sama daripada kabur kepada operasional yang dibuat oleh tadbir urus mengikut corak merentasi setiap corak AI, diterapkan di sini khusus pada tempat panggilan alat agent dilancarkan.

Tiga Tempat Manusia Berada dalam Gelung

Pusat semakan terletak pada detik yang berbeza dalam larian, dengan laluan serahan berasingan untuk ketidakpastian yang tidak dijangka oleh mana-mana peraturan tetap.

Pusat Semakan Manusia dalam Gelung AI Agent ditunjukkan sebagai semakan pra-larian, kelulusan pertengahan larian, audit pasca-larian, dan serahan ketidakpastian

Pusat semakan Bila ia dicetuskan Apa yang ditangkapnya
Semakan pra-larian Sebelum agent memulakan pusingan gelung pertamanya Matlamat yang tersalah spesifikasi, senarai alat yang terlalu luas, atau skop yang salah sebelum sebarang tindakan diambil
Get kelulusan pertengahan larian Tepat sebelum langkah Execute berisiko tinggi tertentu Satu tindakan dalam larian yang selainnya selamat yang akan mahal atau memalukan jika tersilap
Audit pasca-larian Selepas agent selesai, pada sampel atau pada setiap larian bagi agent berisiko tinggi Tingkah laku yang hanyut, hampir-silap, dan tindakan yang secara teknikalnya baik tetapi tidak patut berlaku lagi

Setiap agent yang direka dengan baik menggunakan gabungan ketiga-tiga ini, bukan ketiga-tiganya pada setiap tugas. Agent berisiko rendah (menyediakan taklimat SEO, meringkaskan mesyuarat) boleh berjalan tanpa get dan mendapat semakan rawak ringan selepas larian. Agent berisiko tinggi, yang boleh mengembalikan wang atau menghantar e-mel menghadap pelanggan, memerlukan semakan pra-larian ke atas skopnya serta get pertengahan larian pada tindakan tertentu yang membawa akibat. Panduan Anthropic tentang membina agent menyatakan perkara yang sama secara langsung: bina pusat semakan di mana agent berhenti untuk maklum balas manusia, terutamanya sebelum tindakan yang tidak boleh dipulihkan, dan berikan syarat berhenti yang jelas supaya ia tidak terlepas daripada kesilapannya sendiri.

Mekanisme keempat patut disebut tersendiri: serahan ambang keyakinan. Ia bukan pusat semakan tetap yang terikat pada satu tindakan. Ia dicetuskan apabila agent sendiri menyedari ia tidak mempunyai isyarat yang cukup untuk meneruskan dengan selamat: dua sumber bercanggah dan ia tidak dapat mendamaikannya, fakta yang diperlukan tiada, situasi tidak sepadan dengan apa-apa dalam panduan senarionya. Agent menulis nota serahan ringkas, inilah yang saya temui, inilah sebab saya tersekat, inilah yang saya perlukan daripada anda, dan menunggu. Ini selalunya satu get paling berharga dalam seluruh sistem, kerana ia menangkap kes yang tiada siapa terfikir untuk menulis peraturannya.

Struktur empat bahagian ini, semakan pra-larian, get pertengahan larian, serahan ambang keyakinan, dan audit pasca-larian, tepat seperti yang ditetapkan oleh reka bentuk human-in-the-loop corak Autonomous Agent pada peringkat corak. Apa yang berikut di sini ialah perincian operasional: cara memutuskan apa yang sebenarnya mencetuskan get, dan apa kos anda jika keputusan itu salah.

Apa yang Sentiasa Memerlukan Manusia

Merentasi pelan dalam pustaka ini, empat kategori yang sama terus muncul sebagai get yang tidak boleh dirunding, tanpa mengira industri atau fungsi:

  • Apa-apa yang keluar dari bangunan. E-mel menghadap pelanggan, siaran awam, mesej kepada prospek atau calon. Sebaik dihantar, anda tidak boleh menariknya balik, dan pembaca tidak tahu AI yang menulisnya melainkan sesuatu tersasar secara jelas.
  • Apa-apa yang menggerakkan wang. Bayaran balik, pembayaran, invois yang diluluskan, peruntukan semula bajet. Tindakan kewangan melebihi ambang yang ditakrifkan tidak patut dilancarkan tanpa seseorang mengesahkannya, tidak kira betapa yakin agent itu.
  • Apa-apa yang tidak boleh atau sukar dipulihkan. Memadam rekod, menutup akaun, membatalkan akses. Jika membatalkan tindakan itu memerlukan usaha lebih besar daripada melakukannya, manusia mengesahkannya dahulu.
  • Apa-apa di luar skop pemilik tugas sendiri. Agent yang mengemas kini rekod operatornya sendiri adalah satu hal. Agent yang mengubah suai rekod milik orang lain, deal wakil jualan lain, baris bajet jabatan lain, memerlukan semakan khusus kerana orang yang paling layak menangkap kesilapan itu, pemilik sebenar rekod, bukan yang mencetuskan tindakan.

Senarai ini bukan sekadar cadangan. Perkara 14 Akta AI EU mewajibkan sistem AI berisiko tinggi dibina supaya penyelia manusia dapat memahami apa yang sistem lakukan, mengenali apabila sesuatu tidak kena, dan menghentikan atau membalikkannya. Keperluan itu hampir terus dipetakan kepada keempat-empat kategori ini bagi mana-mana agent yang beroperasi dalam pekerjaan, perkhidmatan kewangan, atau kerja menghadap pelanggan, sama ada anda diwajibkan mematuhinya mengikut bidang kuasa atau tidak.

Kos Jika Get Diletakkan Secara Salah

Terdapat dua arah kegagalan di sini, dan pasukan cenderung membetulkan secara berlebihan ke satu arah selepas terbakar oleh yang lain.

Get Terlalu Sedikit lwn. Terlalu Banyak untuk AI Agent dibandingkan sebagai get risiko terbuka dan baris gilir kelulusan yang tersekat

Get yang terlalu sedikit ialah kegagalan yang lebih ketara. Agent dengan terlalu sedikit pusat semakan melakukan kerosakan sebenar sebelum sesiapa perasan: menghantar bayaran balik yang salah kepada berpuluh akaun, membalas aduan sensitif dengan nada yang salah, menulis fakta halusinasi ke dalam medan CRM yang merebak ke tiga sistem lain sebelum manusia menangkapnya. Inilah mod kegagalan yang menjadi tumpuan setiap perbualan keselamatan dan tadbir urus, atas sebab yang wajar.

Get yang terlalu banyak ialah kegagalan yang lebih senyap, dan sama lazimnya. Hantar setiap tindakan melalui manusia, termasuk yang selamat dan berulang, dan anda telah membina baris gilir kelulusan dengan langkah tambahan, bukan agent. Tujuan sebenar mengautomasikan triage tiket atau pembersihan CRM ialah mengeluarkan manusia daripada bahagian tengah kerja yang berulang. Jika setiap tindakan masih memerlukan satu klik, anda telah membayar untuk AI dan mengekalkan kos buruh. Lebih teruk, agent yang terlalu banyak get melatih penyemaknya untuk meluluskan sahaja tanpa membaca: menyemak 200 kelulusan berisiko rendah sehari mengajar orang berhenti membacanya dengan teliti, diam-diam menggagalkan tujuan get yang anda kekalkan.

Penyelesaiannya bukan nisbah universal antara tindakan yang diberi get dengan yang tidak. Ia menjadi khusus tentang tindakan mana yang benar-benar membawa empat jenis risiko di atas, memberi get hanya kepada tindakan itu, dan membiarkan yang lain berjalan. Gartner meramalkan bahawa lebih 40% projek AI agentic akan dibatalkan menjelang akhir 2027, dengan menyebut kos yang meningkat, nilai perniagaan yang tidak jelas, dan kawalan risiko yang tidak memadai sebagai punca utama, dan kedua-dua arah kegagalan di atas muncul dalam angka itu. Projek yang terbakar oleh get terlalu sedikit ditutup selepas insiden. Projek yang dicekik oleh get terlalu banyak diam-diam kehabisan bajet kerana ia tidak pernah menyampaikan penjimatan masa yang dijanjikan.

Bagaimana Pelan Rework Mereka Bentuk Serahannya

Coraknya muncul merentasi fungsi yang sangat berbeza sebaik sahaja anda tahu apa yang perlu dicari:

  • AI SDR Agent menjalankan jujukan outbound sendiri, tetapi sebaik sahaja balasan bertanya soalan harga atau menandakan niat membeli yang sebenar, ia menghentikan jujukan dan menyerahkan perbualan kepada AE yang ditugaskan dengan ringkasan pendek, bukan berimprovisasi jawapan.
  • AI Contract Review Agent menandakan klausa berisiko berbanding playbook anda, tetapi manusia meluluskan setiap perubahan sebelum ia kembali kepada pihak lawan. Agent tidak pernah menyunting kontrak aktif sendiri.
  • Expense Approval Agent meluluskan secara automatik perbelanjaan yang jelas sepadan dengan dasar dan menghalakan pengecualian kepada seseorang, jadi get hanya dicetuskan pada kes yang benar-benar memerlukan pertimbangan.
  • AI Proposal/Quote Agent menghimpunkan cadangan daripada CRM dan katalog anda serta menggunakan peraturan harga anda, kemudian menghalakan draf siap untuk kelulusan manusia sebelum apa-apa sampai kepada prospek.
  • AI Collections AR Agent menghantar peringatan pembayaran mengikut jadual tetapi dibina untuk tahu bila hendak berhenti, mengeskalasi kepada seseorang dan bukan terus mengejar akaun hingga menjadi pertikaian.

Perhatikan persamaannya: agent melakukan kerja volum, menyediakan draf, memadankan, menskor, menjujukkan, dan manusia membuat tepat satu keputusan, tepat pada detik keputusan itu berbaloi dibuat. Itulah reka bentuknya, bukan kompromi terhadapnya.

Membina Serahan ke dalam Agent Anda

Tiga langkah praktikal menjadikan serahan benar-benar berfungsi dan bukan sekadar wujud di atas kertas.

Reka Bentuk Serahan AI Agent ditunjukkan sebagai paket berperingkat yang mengandungi bukti, ketidakpastian, meterai keputusan, dan gelendong audit

Peringkatkan sebelum membuat komitmen. Halakan output agent ke kawasan pementasan dahulu, folder draf, baris gilir menunggu kelulusan, tab semakan, dan bukan menulis terus ke sistem rekod. Semakan manusia lima minit ke atas kemas kini CRM yang dipentaskan menangkap kebanyakan ralat tanpa memusnahkan penjimatan masa, dan ia mod kegagalan yang sama sekali berbeza daripada menyemak rekod langsung selepas kejadian.

Tulis nota serahan dengan bersungguh-sungguh. Apabila agent menyerahkan, ia patut menyerahkan konteks, bukan sekadar tugas. "Inilah yang saya temui, inilah sebab saya tidak pasti, inilah yang anda perlu putuskan" memberi penyemak segala yang diperlukan dalam sekali baca. Notifikasi kosong "perlu disemak" memaksa manusia mengulang penyelidikan agent hanya untuk mengejar, memadam kebanyakan masa yang dijimatkan.

Log setiap get, bukan hanya yang dicetuskan. Jejak audit bagi setiap pusat semakan yang dilalui agent, diluluskan dan ditolak sama-sama, ialah apa yang membolehkan anda mengetahui sama ada get anda dikalibrasi. Jika 95% kelulusan diluluskan sahaja tanpa suntingan, get itu mungkin selamat untuk dilonggarkan. Jika get terus menangkap ralat sebenar, ia tepat di tempat yang sepatutnya. Ini disiplin jejak audit yang sama di bawah keperluan tadbir urus setiap corak, dan itulah yang menukarkan "kami ada manusia dalam gelung" daripada dakwaan kepada sesuatu yang benar-benar boleh anda buktikan.

Jika anda membina get ini pada alat aliran kerja dan bukan kod tersuai, ciri langkah kelulusan dan pementasan berbeza jauh antara platform. Bandingkan pilihan dalam kategori automasi, dan semak cara memilih perisian automasi aliran kerja untuk apa yang perlu ditanya tentang penghalaan kelulusan dan pengelogan audit sebelum anda menyeragamkan satu.

Fakta Utama

  • Human-in-the-loop untuk agent bermaksud titik jeda tertentu dalam gelung mengamati-menaakul-bertindak-memerhatinya, bukan dasar kabur bahawa manusia "menyelia" AI.
  • Empat kategori hampir selalu memerlukan get: komunikasi luaran, tindakan kewangan, tindakan tidak boleh dipulihkan, dan tindakan pada rekod di luar skop pemilik tugas sendiri.
  • Perkara 14 Akta AI EU mewajibkan sistem AI berisiko tinggi membolehkan manusia memahami, mengatasi, dan menghentikan sistem, asas undang-undang yang dipetakan rapat kepada empat kategori yang sama ini.
  • Get terlalu banyak sama nyatanya sebagai kegagalan seperti get terlalu sedikit: hantar segalanya melalui manusia dan anda telah membina baris gilir kelulusan yang lebih perlahan, bukan agent automatik.
  • Gartner menjangka lebih 40% projek AI agentic akan dibatalkan menjelang 2027, dengan menyebut kawalan risiko yang tidak memadai sebagai salah satu punca utama, tepat kegagalan yang dicegah oleh kerja reka bentuk ini.

Ke Mana Seterusnya

Meletakkan get yang betul hanya separuh kerja. Pagar pelindung AI agent membincangkan separuh lagi, peraturan tegar yang tidak patut dilanggar agent tanpa mengira siapa meluluskan apa, dan prompt injection membincangkan serangan khusus yang menjadikan input tidak dipercayai cukup berbahaya sehingga memerlukan get ini pada mulanya. Mulakan daripada cara membina AI agent jika anda masih mentakrifkan lima blok binaan lain di sekitar blok ini.

About the author

Victor Hoang

Victor Hoang

Co-Founder, Rework.com

Victor Hoang is Co-Founder and CMO of Rework. He spent 12+ years scaling B2B SaaS growth, building a lead engine that generated over 1 million leads and $10M+ in annual recurring revenue. Today he builds AI agents and MCP servers into Rework's products to empower customers across growth and operations. He writes about what actually works.