Ejen AI saya menghantar keputusan dalam sembang pasukan kami. Seorang manusia membalas, dan ejen kedua terus mencelah tanpa pernah melihat mesej pertama. Rentetan peristiwa tersebut mengakibatkan kehilangan konteks, kerja bertindih, dan ralat yang nyata. Selepas menyepadukan Protokol Komunikasi Antara-Ejen (IACP) yang ringan ke dalam pelayan memori dan timbunan pemantauan sedia ada, gangguan tersebut terhenti dan aliran kerja menjadi lebih kemas.

Mengapa masalah ini penting

Dalam persekitaran produksi, ejen AI bukan lagi eksperimen yang terasing; ia bertindak sebagai mikro-perkhidmatan yang mengambil data, menjana kod, atau mencetuskan deployment. Apabila setiap ejen hanya berkomunikasi dengan manusia, pertindihan tanggungjawab menjadi satu race condition yang tersembunyi. Satu mesej Slack yang tersasar mungkin kelihatan tidak berbahaya, tetapi pembangun membazirkan masa untuk merungkai output yang bercanggah, saluran paip (pipelines) terhenti apabila dua bot menyunting repositori yang sama, dan keyakinan terhadap automasi semakin terhakis.

Pautan yang hilang: keadaan kongsi masa nyata

Kebanyakan pasukan menganggap ejen sebagai “kotak hitam” yang menerima prompt dan mengembalikan keputusan, dengan andaian bahawa prompt tersebut mengandungi semua konteks yang diperlukan. Hakikatnya, ejen berkongsi ruang kerja di mana keadaannya sentiasa berubah: sesebuah repositori mungkin sedang dikunci, sesuatu perkhidmatan mungkin tergendala, atau analisis terdahulu mungkin baru sahaja selesai. Tanpa mekanisme penyiaran (broadcast), setiap bot bekerja berdasarkan snapshot yang lapuk.

Membina IACP di atas alatan sedia ada

Daripada membina platform yang benar-benar baharu, saya telah memperluas pelayan memori yang menyimpan sejarah perbualan dan suite pemantauan yang menjejaki kesihatan ejen. Protokol ini menambah lima keupayaan konkrit:

  • Identiti Berstruktur – Setiap mesej keluar membawa pengenal pasti unik seperti claude@greenmac:8f3a2c. Format ini memberitahu penerima dengan serta-merta siapa yang menghantar mesej tersebut dan daripada instans yang mana, sekali gus menghapuskan kenyataan “bot kata X” yang mengelirukan.

  • Suntikan Sejarah – Sebelum menjana balasan, bot akan menarik segmen sembang yang paling terkini, termasuk mesej daripada ejen lain, dan meletakkannya di hadapan promptnya. Konteks tidak akan hilang, dan model boleh menaakul tentang apa yang telah disumbangkan oleh rakan sejawatnya.

  • Transisi Keadaan – Ejen berhenti menghantar heartbeat yang kerap. Sebaliknya, mereka menghantar perubahan status—working, blocked, atau idle—setiap kali keadaan dalaman mereka berubah. Pengguna (consumers) bertindak balas dengan segera, contohnya dengan meletakkan tugasan bergantung dalam barisan hanya apabila ejen huluan (upstream) melaporkan idle.

  • Pajakan Penasihat – Apabila ejen memerlukan akses eksklusif kepada sesuatu sumber (repositori, titik akhir API, nod pengkomputeran), ia menuntut pajakan dengan TTL (time-to-live). Jika ejen terhenti (crash), pajakan tersebut akan tamat secara automatik, membebaskan sumber tersebut untuk kegunaan lain dan menghalang dua bot daripada mengganggu satu sama lain.

  • Mekanisme Peti Masuk – Satu “stop hook” akan menghentikan sementara aliran kerja ejen jika peti masuknya mengandungi mesej yang belum dibaca. Ejen mesti memproses item tersebut sebelum menyelesaikan tugasan semasa, bagi memastikan isyarat penyelarasan yang tertangguh tidak diabaikan.

Komponen-komponen ini membentuk satu lapisan komunikasi yang ringkas dan boleh diperhatikan yang memastikan setiap peserta mendapat maklumat yang sama.

Risiko bagi pasukan yang mengabaikannya

Jika sesebuah pasukan terus bergantung kepada prompt ad-hoc dan pemantauan manual, kos tersembunyi akan meningkat:

  • Usaha bertindih – Dua ejen mungkin menjana laporan yang serupa, sekali gus menggunakan kitaran pengkomputeran dan perbelanjaan awan.
  • Pertikaian sumber – Penulisan serentak ke dalam kod sumber mencetuskan konflik penggabungan (merge conflicts) yang memerlukan penyelesaian manusia.
  • Risiko operasi – Ejen yang bertindak berdasarkan status lapuk mungkin cuba melakukan deployment semasa ejen lain sedang melakukan rollback, yang boleh menjejaskan kestabilan perkhidmatan.

Dengan memformalkan cara ejen mengumumkan identiti, keadaan, dan tuntutan sumber, IACP mengurangkan risiko ini tanpa memerlukan enjin orkestrasi yang berat.

Hujah balas: beban tambahan

Pengkritik berpendapat bahawa suntikan sejarah dan pengurusan pajakan menambah kependaman (latency) dan laluan kod tambahan. Dalam persekitaran di mana ejen tunggal mengendalikan tugasan yang sempit, manfaat protokol ini mungkin kecil. Walau bagaimanapun, pelaksanaan ini menggunakan semula perkhidmatan memori dan pemantauan sedia ada, jadi beban tambahan adalah sederhana. Bagi pasukan yang sudah mengalami kekeliruan antara ejen, imbangan (trade-off) ini jelas menguntungkan.

Apa yang perlu diperhatikan seterusnya

Protokol ini masih merupakan prototaip, tetapi sifat modularnya mengundang integrasi dengan mana-mana rangka kerja ejen agnostik bahasa. Langkah seterusnya yang berpotensi termasuk:

  • Menerbitkan SDK ringan supaya pembangun boleh menambah lima hook tersebut tanpa menyentuh logik teras.
  • Menambah metrik ke dalam suite pemantauan yang memvisualisasikan peralihan keadaan dan lease churn, membantu pasukan mengenal pasti kesesakan.
  • Bereksperimen dengan lapisan polisi yang mengutamakan pajakan ejen tertentu secara automatik berbanding yang lain dalam senario trafik tinggi.

Jika pelanjutan ini mendapat sambutan, IACP boleh menjadi piawaian de-facto untuk saluran paip pengeluaran multi-ejen, sama seperti HTTP untuk perkhidmatan web.

Rumusan: Satu set konvensyen yang ringkas—siapa yang sedang bercakap, bagaimana rupa perbualan terkini, bila status ejen berubah, siapa yang memegang sumber, dan sama ada terdapat mesej tertunda—boleh menghalang ejen AI daripada bercakap tanpa saling memahami dan mengubah bilik sembang yang bising menjadi saluran penyelarasan yang boleh dipercayai.