Apabila anda menyambungkan model bahasa besar ke dalam aliran kerja yang memerlukan manusia untuk memberikan persetujuan melalui e-mel, model tersebut jarang sekali menjadi punca kegagalan. Kegagalan berlaku di mana kod berakhir dan peti masuk bermula. Satu larian autonomi menghantar permintaan. Kemudian, larian lain bermula sebelum yang pertama selesai. Peti masuk kongsi mengumpul rantaian mesej daripada proses yang berbeza. Seseorang menekan butang lulus pada mesej yang tiba lewat dua belas jam. Sekarang anda mempunyai output. Anda mempunyai keputusan. Tetapi anda tidak dapat membuktikan larian mana yang menghasilkan apa, atau sama ada kelulusan tersebut sebenarnya dimaksudkan untuk penjanaan ini. Saya telah membersihkan cukup banyak saluran paip automasi dalaman untuk mengenali corak ini. Ia meningkat daripada kekeliruan kepada insiden lebih cepat daripada yang dijangkakan oleh kebanyakan pasukan.

Sempadan Operasi

Sempadan antara orkestrator anda dan penyedia e-mel anda bukan sekadar lompatan rangkaian. Ia adalah sempadan keadaan (state boundary). Apabila LLM selesai menjana draf, larian tersebut masih aktif. Ia sedang menunggu. Jika sistem anda menganggap penghantaran sebagai acara "hantar dan lupakan" (fire-and-forget), anda telah pun kehilangan jejak.

Saya telah melihat saluran paip di mana satu larian mencetuskan dua permintaan kelulusan berasingan kerana polisi cubaan semula (retry policy) yang terlalu agresif. Saya telah melihat larian lain menggunakan semula peti mel yang masih menyimpan mesej dari minggu lepas. Pelulus manusia tidak melihat ID larian. Mereka hanya melihat baris subjek dan satu butang. Tanpa struktur, mereka hanya meneka di dalam peti masuk yang sama di mana surat berita pemasaran dan amaran pemantauan berada.

Langkah yang Terabai

Pasukan akan menghabiskan masa berminggu-minggu untuk memperhalusi prom, menambah pagar keselamatan (guardrails), dan membuat penanda aras output. Kemudian, mereka menyambungkan langkah kelulusan ke saluran Slack atau peti masuk sokongan kongsi dan menganggapnya selesai. Ini mewujudkan tiga kerosakan yang boleh diramal:

  • Peti masuk kongsi menjadi tempat pembuangan acara daripada pelbagai larian. Konteks runtuh. Anda tidak dapat membina semula mesej mana yang tergolong dalam transaksi perniagaan yang mana tanpa membuka rantaian mesej dan menganalisis cap masa secara manual.
  • Cubaan semula memadamkan bukti. Jika satu larian menghantar semula permintaan kelulusannya, mesej asal mungkin tertimbus, dipadam, atau ditandakan sebagai pendua oleh klien e-mel yang terlalu aktif. Jejak audit menjadi rapuh.
  • Keputusan manusia terapung di luar sistem. Seseorang membalas "nampak ok" dalam tiket atau mesej terus. Sentimen tersebut tidak pernah menjadi data berstruktur di dalam aliran kerja. Ejen tidak mempunyai cara untuk mengesahkan siapa yang berkata apa, atau bila.

Apabila sesuatu berlaku dan anda perlu menyiasat, anda hanya mendapat khabar angin. "Saya rasa itu e-mel yang betul." Ingatan bukanlah kebolehkesanan (traceability). Log audit tidak dapat memproses gerak hati.

Daripada Perincian Penghantaran kepada Titik Semak

Memperbaiki perkara ini memerlukan anjakan reka bentuk. Berhenti menganggap e-mel sebagai perincian penghantaran. Mula melayannya sebagai titik semak (checkpoint) sistem. Ini bermakna setiap mesej adalah peralihan keadaan (state transition), dan setiap peralihan keadaan memerlukan identiti, kebenaran, dan bukti.

Apabila anda mengguna pakai minda ini, persoalannya berubah. Anda berhenti bertanya sama ada e-mel dihantar dengan berjaya. Anda mula bertanya larian mana yang menghantarnya, apakah bukti yang ditinggalkan, dan peraturan apakah yang memberi kebenaran kepada aliran kerja untuk diteruskan. Ejen sememangnya boleh menulis isi kandungan e-mel. Tetapi platform anda mesti menguatkuasakan laluan identiti dan pengesahan. LLM adalah penulis. Infrastruktur adalah notari.

Reka Bentuk Minimum

Anda tidak memerlukan belanja yang besar untuk membina ini. Versi minimum yang boleh dilaksanakan (minimum viable version) saya menggunakan lima komponen yang sengaja dirancang.

  • Orkestrator mencipta run_id pada saat tepat aliran kerja bermula. Pengenal pasti ini adalah tulang belakang bagi setiap tindakan seterusnya. Ia tidak pernah berubah, dan ia tidak pernah digunakan semula.
  • Setiap tindakan e-mel membawa tiga medan: run_id, label message_type seperti "approval_request" atau "evidence_notification," dan rentetan policy_version yang mengenal pasti peraturan tadbir urus mana yang aktif. Ini menukarkan mesej biasa kepada acara bertipe (typed event).
  • Bukti kekal dalam peti masuk yang diasingkan mengikut larian. Itu tidak semestinya bermaksud akaun e-mel berasingan untuk setiap larian. Ia boleh bermaksud label khas, subfolder, atau peraturan penghalaan yang membahagikan rantaian mesej supaya korespondensi satu larian tidak bercampur dengan larian yang lain.
  • Respons kelulusan mestilah acara berstruktur, bukan teks bebas "ok." Manusia masih menekan butang atau membalas, tetapi sistem menterjemah tindakan tersebut kepada muatan (payload) yang boleh dibaca mesin yang menamakan run_id, keputusan, dan cap masa.
  • Aliran diteruskan hanya jika bukti dan keputusan sepadan. Aliran kerja tidak mempercayai kelulusan secara berasingan. Ia mengesahkan muatan kelulusan terhadap permintaan asal sebelum membenarkan output LLM sampai ke pengeluaran (production).

Apa yang Disahkan oleh Titik Semak yang Berguna

Sebuah titik semak yang berguna menguatkuasakan empat syarat sebelum ia menerima keputusan manusia.

  • Penerima mestilah tergolong dalam konteks larian. Jika pelulus bukan penyemak yang ditugaskan untuk instans aliran kerja khusus ini, sistem akan menolak isyarat tersebut.
  • Subjek atau metadata penghalaan mestilah sepadan dengan keadaan aliran semasa. Kelulusan untuk langkah ketiga tidak boleh memintas langkah kedua.
  • Cap masa mestilah berada dalam tempoh yang dijangkakan. Keputusan yang tiba selepas tamat masa harus mencetuskan semakan baharu, bukannya kelulusan automatik.
  • Bukti tidak boleh digunakan semula oleh larian lain. Jika ID mesej atau token yang sama muncul dalam dua permintaan kelulusan yang berbeza, itu adalah satu perlanggaran, dan sistem harus terhenti.

Kos Sebenar

Corak ini tidak percuma. Anda menyimpan lebih banyak metadata. Anda menambah lapisan polisi yang perlu diselenggara oleh seseorang. Anda memaksa pasukan anda untuk merekodkan keputusan manusia sebagai data berstruktur dan bukannya komen ringkas. Ia kelihatan seperti birokrasi. Namun dalam praktiknya, ia adalah satu pertukaran yang sangat berbaloi.

Anda menukar kelajuan demi kejelasan.