Semua orang terlalu taksub dengan prompt. Mereka memperhalusi ucapan salam, mengubah nada, dan bimbang sama ada model kedengaran cukup mesra. Itu hanyalah gangguan. Apabila ejen AI mula menghantar e-mel sebenar kepada pengguna sebenar, bahayanya bukanlah ia menulis "Salam hormat" dan bukannya "Salam". Bahayanya ialah anda tidak dapat menentukan dengan pasti apa yang berlaku antara keputusan ejen dan mesej tersebut mendarat di peti masuk. Saya melihat sempadan terlebih dahulu. Di situlah sistem produksi mati secara senyap.

Kontrak Adalah Titik Kelemahan

Demo AI sangat pemaaf. Perbualan lancar dalam tetingkap pelayar menyembunyikan timbunan andaian. Dalam produksi, kerentanan sebenar terletak pada kontrak antara tiga perkara: keputusan ejen, alat yang melaksanakan tindakan, dan langkah yang mengesahkan hasil. Jika sempadan itu kabur, sistem akan berfungsi dengan cantik sehinggalah ia gagal. Kemudian ia gagal secara senyap, menghantar mesej pendua kepada seluruh segmen pelanggan, atau menghantar mesej pada masa yang salah tanpa rekod yang jelas tentang puncanya. Prompt mungkin kelihatan seperti puisi, tetapi seni bina di bawahnya mungkin masih hanya diikat dengan tali.

Berhenti Membiarkan Ejen Menulis Secara Bebas

Kesilapan yang paling biasa ialah memberikan ejen halaman kosong. Pasukan membiarkan ejen menerangkan e-mel dalam teks mentah dan kemudian mempercayai alat hiliran untuk menterjemah niat daripada prosa tersebut. Itu sangat rapuh. LLM mungkin mencadangkan niat yang munasabah, tetapi infrastruktur anda tidak memerlukan kreativiti. Ia memerlukan kontrak. Ia memerlukan medan khusus yang boleh disahkan oleh mesin tanpa kekaburan.

Apabila ejen mengeluarkan permintaan e-mel, output tersebut harus membawa tepat apa yang diperlukan oleh sistem:

  • Template version: Versi templat: Versi badan e-mel yang digunakan, supaya anda tahu apa yang dilihat oleh pengguna.
  • Recipient scope: Skop penerima: Siapa yang menerimanya, ditentukan oleh ID pengguna atau peraturan segmen, bukan melalui bahasa tabii seperti "pengguna yang baru mendaftar."
  • Trace ID: Trace ID: Pengenal pasti unik yang mengikuti permintaan ini daripada ejen melalui executor anda, melalui penyedia e-mel, dan ke dalam log anda.
  • Time window: Tetingkap masa: Bilakah penghantaran ini sah, supaya keputusan ejen yang sudah lama tidak mencetuskan e-mel tengah malam beberapa jam kemudian.
  • Idempotency: Idempotensi: Kunci yang menghalang penghantaran logik yang sama daripada berlaku dua kali jika ejen mencuba semula atau berlaku gangguan rangkaian.

Teks mentah adalah API yang sangat teruk. Ia meninggalkan ruang untuk kekaburan tentang kecemasan, audiens, dan tindakan. Medan khusus boleh dibaca oleh mesin, boleh diaudit, dan boleh diuji. Ia menukarkan arahan yang samar kepada arahan yang boleh disahkan.

Tindakan, Bukan Prosa

Daripada menyerahkan tugas penulisan terbuka kepada ejen, hadkan ia kepada menu tindakan yang dibenarkan. Fikirkan ia seperti API dalaman dengan enum yang tetap. Ejen tidak merangka baris subjek atau memikirkan tentang ucapan salam. Ia memilih tindakan seperti send_review_request atau send_retry_notice. Itulah had kebebasan kreatifnya.

Seorang pelaksana (executor) yang deterministik kemudian mengambil kunci tindakan tersebut, menarik templat yang betul daripada kawalan versi, melengkapkannya dengan data yang telah disanitasi, mengisi senarai penerima daripada sumber yang disahkan, dan membina arahan akhir. Ejen memutuskan apa yang perlu berlaku. Kod yang membosankan dan boleh diramal memutuskan bagaimana ia berlaku.

Pengasingan ini memudahkan sistem untuk diuji. Anda boleh mengesahkan bahawa keadaan input tertentu mencetuskan send_retry_notice secara konsisten tanpa perlu menjalankan inferens LLM sama sekali. Ujian unit anda menjadi pantas dan deterministik kerana ia menyemak logik pemetaan, bukan suhu (temperature) model. Ujian integrasi anda fokus pada sama ada pelaksana memetakan tindakan tersebut dengan betul ke perkhidmatan e-mel, bukan sama ada model tersebut sedang dalam keadaan baik.

Bina dalam Lima Lapisan

Sistem yang mantap tidak muncul daripada satu prompt sahaja. Ia dibina dalam lapisan, dan setiap lapisan memiliki satu tanggungjawab yang jelas dan tunggal.

1. Backend mengurangkan peristiwa kepada data yang selamat.
Sama ada pencetusnya adalah webhook, perubahan pangkalan data, atau tugasan berjadual, lapisan ini menyanitasi input, membuang medan yang tidak dijangka, dan hanya menyerahkan apa yang diperlukan oleh ejen. Jika muatan (payload) webhook mengandungi dua puluh medan tetapi ejen hanya memerlukan dua, berikan dua sahaja. Tiada teks mentah pengguna yang harus sampai ke lapisan keputusan tanpa diperiksa.

2. Ejen memilih tindakan daripada skema tetap.
Ia melihat konteks, membuat keputusan, dan mengeluarkan salah satu kunci tindakan yang telah ditetapkan bersama metadata yang diperlukan. Ia tidak merangka prosa. Ia tidak meneka penerima. Ia mengembalikan payload berstruktur yang boleh disahkan oleh lapisan seterusnya terhadap skema JSON.

3. The tool validates permissions and required fields.
Does this agent context have the right to trigger send_review_request for this user? Is the recipient scope non-empty and within allowed limits? Is the idempotency key present and unique in your log? Is the trace ID well-formed? Fail here, loudly, before any email service is ever touched.

4. The email service logs the send with a trace ID.
Every message that leaves your system should carry that trace identifier through the provider's API and into your observability stack. If a user complains they received two copies, you should be able to query one ID and see exactly where the duplication originated: a retried agent call, a flaky executor, or a misbehaving callback.

5. The end-to-end test checks the actual inbox for content and effect.
Open the rendered message in a real mailbox. Is the subject line populated correctly? Does the unsubscribe link resolve? Does clicking the primary call-to-action button land on the correct page with the correct user state? A passing unit test means the code ran. Only an inbox test tells you the email actually works for a human.

Evidence Over Guessing

When a test fails in this pipeline, you need four specific pieces of evidence. Accept nothing less.

  1. The original decision from the agent. What action did it choose, and what was the full input context?
  2. The normalized command from the tool. What did the deterministic executor build after applying the template, hydration logic, and validation rules?
  3. The message in the isolated inbox. Not a log of what you think you sent, but the real MIME message, headers and all, captured in a dedicated test mailbox.
  4. The final effect after clicking the link. The resulting page state, database change, or external event that proves the email achieved its purpose.

If one piece is missing, your team will fill the gap with assumptions. They will guess. Guessing in automation is expensive. It burns hours, erodes trust, and turns every incident into a forensic mystery instead of a