Panduan pengembang untuk pola multi-agen dengan ADK

Beranda » Ular sanca » Panduan pengembang untuk pola multi-agen dengan ADK

Aplikasi berbasis agen dengan cepat melampaui pola "satu mega-prompt" klasik, dan pengembang membutuhkan model mental yang solid untuk menyusun banyak agen tanpa terjerumus ke dalam kekacauan. Google Agent Development Kit (ADK) dirancang khusus untuk tujuan ini: memungkinkan Anda untuk menyusun sistem multi-agen yang andal, menghubungkan alat dan memori, serta menyebarkan semuanya di Google Cloud dengan kemampuan pengamatan, keamanan, dan pengendalian biaya tingkat produksi.

Panduan ini akan memandu Anda melalui pola multi-agen utama yang didukung oleh ADK – mulai dari hierarki induk/anak sederhana hingga agen alur kerja Sekuensial, Perulangan, dan Paralel – dan menunjukkan bagaimana pola-pola tersebut sesuai dengan arsitektur referensi yang lebih luas di Google Cloud. Kami juga akan membahas status sesi bersama, mekanisme delegasi, cetak biru multi-agen umum, dan aspek praktis dari penerapan, pengamanan, dan pengoperasian sistem ini di lingkungan nyata.

Mengapa sistem multi-agen di ADK?

Ketika sebuah aplikasi digerakkan oleh satu perintah agen tunggal dan monolitik, aplikasi tersebut dengan cepat menjadi sulit untuk dipahami, diuji, dan dikembangkan. Prompt yang besar itu rapuh, sulit untuk di-debug, dan sulit untuk dipelihara seiring bertambahnya kebutuhan. ADK mendorong Anda untuk membangun sebuah prompt yang lebih kecil. Sistem Multi-Agen (MAS) di mana setiap agen memiliki tanggung jawab yang terfokus, dan orkestrasi dilakukan secara eksplisit.

Menstrukturkan aplikasi Anda sebagai beberapa agen yang saling bekerja sama akan menghadirkan modularitas, spesialisasi, dan kemampuan penggunaan kembali. Anda dapat memiliki agen riset, kritikus, penulis file, perute, agen akses data, dan menggunakannya kembali di berbagai proyek atau alur kerja, alih-alih menyematkan kembali logika yang sama ke dalam satu perintah besar.

ADK memberi Anda blok bangunan konkret untuk mewujudkan hal ini: agen yang berpusat pada LLM, agen alur kerja (Sekuensial, Paralel, Loop) dan agen khusus yang merangkum logika non-LLM. Semuanya mewarisi dari sumber yang sama. BaseAgent, sehingga mereka terhubung ke model orkestrasi, pencatatan log, penanganan status, dan sistem alat yang sama.

Seiring berkembangnya sistem, model komposisi ini memiliki skalabilitas yang lebih baik daripada kode orkestrasi ad-hoc atau rangkaian panggilan fungsi yang sangat kompleks di sekitar satu model tunggal. Anda menjaga beban kognitif tetap terkendali: setiap agen memiliki mandat yang jelas dan permukaan interaksi yang terdefinisi dengan baik dengan agen lainnya.

Primitif ADK untuk menyusun agen

ADK mengekspos sejumlah kecil primitif yang dapat Anda gabungkan untuk mengekspresikan arsitektur multi-agen yang sangat kaya. Memahami konsep-konsep inti ini akan mempermudah penalaran tentang pola-pola tingkat yang lebih tinggi di kemudian hari.

Primitif pertama adalah hierarki agen: setiap agen dapat mendeklarasikan daftar sub_agents, membentuk pohon dengan satu root_agent di atas. Saat Anda menyerahkan anak-anak ke sub_agents, ADK secara otomatis menghubungkan kabel mereka parent_agent referensi dan memastikan bahwa suatu instance hanya memiliki satu induk (jika tidak, ValueError (diangkat).

Hierarki ini lebih dari sekadar hiasan: hierarki ini mendefinisikan agen mana yang diizinkan untuk mendelegasikan tugas kepada agen mana, dan merupakan cakupan yang digunakan oleh agen alur kerja dan transfer yang didorong oleh LLM. Dari agen mana pun, Anda dapat menelusuri ke atas melalui agent.parent_agent atau menemukan keturunan dengan agent.find_agent(name), yang sangat berguna untuk debugging.

Selain agen LLM dasar, ADK memperkenalkan agen alur kerja khusus – SequentialAgent, ParallelAgent dan LoopAgent – yang tugasnya bukan untuk “berpikir” tetapi untuk mengatur agen-agen bawahan. Semuanya memiliki antarmuka yang sama tetapi menerapkan strategi eksekusi yang berbeda: berjalan secara berurutan, menyebar secara paralel, atau berulang dalam sebuah loop dengan aturan penghentian yang eksplisit.

Elemen dasar penting ketiga adalah lapisan komunikasi, yang berpusat pada hal-hal yang dibagi bersama. Session dan perusahaan state kamus. Status sesi bertindak seperti papan tulis bersama: agen atau alat apa pun dapat menulis hasil atau flag sementara, dan agen lain dalam pemanggilan yang sama dapat membacanya, seringkali melalui templat kunci di dalam instruksi mereka (misalnya {PLOT_OUTLINE?}).

Bagaimana agen berkomunikasi satu sama lain di ADK

ADK mendukung tiga mode komunikasi komplementer antar agen: status sesi bersama, transfer berbasis LLM, dan pemanggilan eksplisit melalui AgentTool. Memilih yang tepat untuk setiap interaksi akan menjaga sistem Anda tetap ekspresif dan mudah diprediksi.

Status sesi bersama (session.state) adalah mekanisme yang paling sederhana dan paling umum. Dalam satu kali pemanggilan, semua agen melihat hal yang sama. Session objek melalui InvocationContextSebuah alat atau fungsi callback dapat melakukan hal tersebut. context.state = value, dan agen selanjutnya dapat mengambilnya dengan context.state.get("data_key"). Untuk agen LLM, pengaturan output_key Secara otomatis menyimpan jawaban akhir mereka di bawah kunci tersebut.

Delegasi yang digerakkan oleh LLM, terkadang disebut "transfer agen", memungkinkan LLM untuk memutuskan kapan harus menyerahkan tugas kepada agen lain berdasarkan instruksi dan deskripsi agen. Secara internal, model tersebut mengeluarkan panggilan fungsi khusus seperti transfer_to_agent(agent_name="screenwriter")ADK AutoFlow mencegat panggilan ini dan mengarahkan kembali eksekusi ke agen yang dipilih dalam cakupan yang diizinkan (induk, anak, saudara kandung tergantung pada konfigurasi).

Pemanggilan eksplisit dengan AgentTool memberikan Anda cara yang lebih terkontrol dan seperti fungsi untuk memanggil satu agen dari agen lain. Anda membungkus instance agen target di dalam AgentTool, tambahkan ke penelepon tools daftar, dan LLM kemudian dapat memilih alat tersebut seperti fungsi lainnya. Saat dipanggil, AgentTool.run_async mengeksekusi sub-agen, menggabungkan status dan artefak kembali, dan mengembalikan respons sub-agen sebagai hasil alat.

Ketiga saluran ini mencakup sebagian besar kebutuhan multi-agen: pengiriman data asinkron melalui status, perutean fleksibel melalui transfer, dan panggilan sinkron yang ketat melalui alat. Dalam desain yang lebih kompleks, Anda sering menggabungkannya dalam satu struktur pohon: sebuah router yang mentransfer ke anak-anaknya, spesialis yang menggunakan status untuk berkomunikasi, dan satu atau dua agen yang tersedia sebagai alat untuk delegasi ad-hoc.

Komponen dasar: Agen LLM, agen alur kerja, dan agen kustom.

Sebagian besar topologi MAS di ADK merupakan kombinasi dari tiga jenis agen: berbasis LLM, alur kerja, dan agen kustom. Setiap kategori menyelesaikan bagian yang berbeda dari masalah orkestrasi.

Agen LLM membungkus model bahasa yang besar dan alat opsional, fungsi callback, serta perutean output ke dalam BaseAgent. Anggap saja komponen-komponen ini sebagai komponen "berpikir": mereka menafsirkan masukan pengguna, memanggil alat, memperbarui status, dan kemudian menjawab pengguna atau menyerahkan tugas kepada agen lain.

Agen alur kerja bertindak sebagai manajer dan bukan pekerja: mereka tidak berpikir sendiri, tetapi mereka mengontrol urutan, paralelisme, dan pengulangan eksekusi sub-agen. SequentialAgent mendidik anak-anaknya satu demi satu sambil berbagi hal yang sama. InvocationContext, ParallelAgent menyebar ke berbagai cabang yang memiliki negara bagian yang sama tetapi memiliki cabang sejarah yang berbeda, dan LoopAgent mengeksekusi suatu urutan secara berulang hingga kondisi berhenti terpenuhi.

Agen bea cukai memperluas BaseAgent dengan logika non-LLM sembarangan ketika strategi orkestrasi bawaan tidak mencukupi. Sebagai contoh, Anda dapat mengimplementasikan penjadwal khusus yang menjalankan agen secara kondisional berdasarkan metrik, atau mengintegrasikan mesin aturan bisnis yang menentukan sub-alur mana yang akan dijalankan tergantung pada batasan peraturan.

Perpaduan antara primitif orkestrasi generik dan logika yang dapat diintegrasikan inilah yang membuat ADK cocok untuk beban kerja perusahaan yang serius, bukan hanya untuk demo. Anda dapat memulai dengan agen alur kerja standar, dan hanya ketika persyaratannya menjadi rumit barulah Anda menggunakan agen yang lebih canggih. CustomAgent.

Status sesi dan pola memori

Status sesi di ADK mendasari memori percakapan jangka pendek dan penyampaian data terstruktur antar agen. Setiap percakapan menggunakan Session objek yang menyimpan riwayat pesan dan dapat diubah state kamus tersedia untuk semua agen dalam pemanggilan tersebut.

Penulisan ke state biasanya dilakukan di dalam alat atau callback, menggunakan ToolContext or CallbackContext obyek. Misalnya, alat seperti save_attractions_to_state(tool_context, attractions: List) dapat menggabungkan atraksi baru dengan atraksi yang sudah tersimpan di bawah state, mengembalikan pesan status sederhana ke agen sementara ADK menyimpan delta status dalam sesi.

Membaca dari dokumen resmi dibuat ergonomis melalui templat kunci yang tertanam dalam instruksi. Ketika sebuah instruksi berisi {my_key?}, ADK akan menyuntikkan state Jika ada; tanda tanya membuatnya opsional sehingga agen tidak gagal ketika kunci hilang. Ini sangat penting dalam alur kerja seperti “riset → tulis → tinjau” di mana setiap langkah membaca apa yang disimpan oleh langkah sebelumnya.

Untuk mengingat isi percakapan antar giliran, ide kuncinya adalah menggunakan kembali hal yang sama. Session untuk pesan pengguna berikutnya, alih-alih membuat yang baru setiap kali. Dengan sesi bersama, agen dapat melihat giliran sebelumnya dan dapat menangani pertanyaan lanjutan, koreksi, dan perencanaan multi-langkah. Jika Anda secara tidak sengaja membuat sesi baru per giliran, agen akan berperilaku seolah-olah mengalami amnesia: ia tidak dapat menghubungkan pertanyaan lanjutan dengan konteks sebelumnya.

Negara juga memainkan peran besar dalam agen alur kerja seperti LoopAgentyang bergantung pada kunci tetap seperti penghitung, daftar umpan balik, atau bendera untuk memutuskan apakah diperlukan iterasi lebih lanjut. Agen kritikus mungkin menambahkan komentar ke dalam CRITICAL_FEEDBACK pada setiap tahapan, sementara perencana atau penyempurna membaca kunci tersebut untuk meningkatkan rencana pada iterasi berikutnya.

SequentialAgent: alur kerja linier yang dijelaskan secara eksplisit

SequentialAgent adalah pola andalan Anda ketika Anda memiliki serangkaian langkah yang harus terjadi dalam urutan tetap. Bayangkan alur kerja seperti “analisis permintaan → riset → draf → simpan ke file” atau “identifikasi tujuan → rencanakan rute → pesan transportasi”.

Di ADK, sebuah SequentialAgent berisi daftar sub_agents dan menjalankannya satu per satu, melewati hal yang sama. InvocationContext melalui seluruh rantai tersebut. Karena Session dan state Jika dibagikan, Anda dapat meminta agen pertama menyimpan hasilnya di bawah output_key="destination" dan agen berikutnya membacanya melalui {destination} dalam instruksinya tanpa kode lem apa pun.

Contoh klasiknya adalah generator ide film: agen utama penyambut berbicara kepada pengguna, lalu menyerahkan pekerjaan kepada agen lain. SequentialAgent yang kemudian memanggil seorang peneliti, lalu seorang penulis skenario, lalu seorang penulis berkas. Pengguna hanya melihat hasil akhir, tetapi grafik peristiwa di ADK Web mengungkapkan pohon internalnya: penyambut tamu → tim konsep film → .

Dibandingkan dengan orkestrasi manual dengan eksplisit if/elif blok dan panggilan fungsi, SequentialAgent Menjaga alur kontrol tetap deklaratif dan meminimalkan kode berulang. Anda mendeklarasikan urutan tersebut sekali dan memperlakukannya sebagai agen yang dapat dipanggil tunggal di runner atau UI Anda, sambil memanfaatkan status sesi untuk meneruskan data antar langkah.

Alur kerja sekuensial juga dapat dikombinasikan dengan baik dengan agen alur kerja lainnya: Anda dapat menyematkan perulangan atau perluasan paralel sebagai salah satu langkah dalam rantai yang lebih panjang. Beginilah cara alur kerja yang lebih canggih seperti “mengulang proses untuk meningkatkan kualitas cerita, kemudian menjalankan analisis pendapatan box office dan pemilihan pemain, lalu menulis laporan konsolidasi” dibangun.

LoopAgent: penyempurnaan iteratif dan ruang penulis

LoopAgent dirancang untuk tugas-tugas yang membutuhkan beberapa kali pengerjaan hingga ambang batas kualitas terpenuhi. Alih-alih pendekatan tunggal "buat sekali dan berharap yang terbaik", Anda dapat menerapkan proses pengajuan proposal, kritik, dan penyempurnaan.

Konfigurasi siklus tipikal mencakup agen-agen seperti peneliti, generator (misalnya penulis skenario), dan kritikus yang berkolaborasi dalam beberapa putaran. Pada setiap iterasi, peneliti dapat memperbarui fakta latar belakang, penulis skenario menyesuaikan garis besar atau rencana, dan kritikus mengevaluasinya berdasarkan pedoman yang jelas, memutuskan apakah iterasi lebih lanjut diperlukan.

Putaran berhenti dalam dua kondisi: mencapai max_iterations atau sub-agen yang memberi sinyal bahwa pekerjaan telah selesai. ADK mengekspos alat bawaan seperti exit_loop bahwa kritikus dapat menghubungi ketika suatu rencana, garis besar, atau desain lolos dari daftar periksa internalnya. LoopAgent juga menghormati sebuah escalate=True masuk Event tindakan, memberi Anda cara lain untuk keluar lebih awal.

Status sesi yang persisten adalah kuncinya di sini: agen membaca kunci seperti PLOT_OUTLINE, research or CRITICAL_FEEDBACK dan menulis versi yang lebih baik atau komentar tambahan pada setiap revisi. Pola ini secara efektif mensimulasikan "ruang penulis" di mana para spesialis bertukar pikiran, mengkritik, dan memoles hingga seseorang menyatakan karya tersebut siap.

Dengan menggabungkan LoopAgent dengan SequentialAgentAnda dapat menempatkan seluruh siklus iteratif sebagai satu langkah dalam alur kerja ujung-ke-ujung yang lebih besar. Sebagai contoh, writers_room (LoopAgent) mungkin akan dijalankan terlebih dahulu untuk menghasilkan kerangka plot yang solid, setelah itu file_writer Agen menyimpan hasilnya dan melampirkan laporan lainnya.

ParallelAgent: menyebar dan berkumpul untuk tugas-tugas independen

ParallelAgent Menerapkan pola "fan-out / gather" klasik untuk tugas-tugas yang independen tetapi berbagi konteks. Alih-alih menjalankan N langkah penelitian secara berurutan, Anda menjalankan semuanya sekaligus dan menunggu hingga semuanya selesai, lalu menggabungkan hasilnya.

Secara internal, ParallelAgent memberikan setiap sub-agen karakteristik yang berbeda InvocationContext.branch - Suka ParentBranch.ChildName – sambil tetap memiliki kesamaan session.state. Itu berarti mereka semua dapat membaca konteks awal seperti PLOT_OUTLINE, tetapi harus menulis output ke kunci status yang berbeda (misalnya box_office_report, casting_report) untuk menghindari konflik.

Contoh umum adalah "tim pra-produksi" untuk presentasi film: satu agen memperkirakan potensi pendapatan box office berdasarkan film-film sejenis, agen lain mengusulkan opsi pemeran, keduanya berjalan secara paralel. Berikutnya file_writer Kemudian menyusun laporan menggunakan templat kunci untuk setiap sub-hasil dan menyimpannya ke disk.

Alur kerja paralel secara signifikan mengurangi latensi untuk kueri yang luas dan dalam skenario tertentu. analisis data waktu nyataJika Anda membutuhkan saran museum, pilihan konser, dan ide restoran untuk akhir pekan, menjalankan tiga agen spesialis secara paralel lebih cepat daripada menanyakan permintaan tersebut secara berurutan. Setelah proses fan-out, agen sintesis membaca semua hasil dari status dan menghasilkan respons terpadu untuk pengguna.

Langkah-langkah paralel hampir selalu tertanam di dalam sebuah SequentialAgent yang pertama-tama menyiapkan konteks, lalu menjalankan ParallelAgent, kemudian dilanjutkan dengan agregasi dan pelaporan. Pola ini mudah dikenali dan digunakan kembali setelah Anda terbiasa dengan agen alur kerja ADK.

Pola orkestrasi dengan primitif ADK

Setelah Anda memahami hierarki, agen alur kerja, dan status, Anda dapat mengimplementasikan beberapa pola multi-agen klasik secara langsung di ADK. Pola-pola ini bukanlah primitif yang dikodekan secara langsung, melainkan komposisi yang dibangun dengan blok bangunan dasar yang sama.

Pola koordinator/pengirim menggunakan agen LLM pusat sebagai "router" untuk permintaan pengguna, yang didukung oleh beberapa sub-agen khusus. Koordinator membaca permintaan, kemudian mentransfer kendali ke sub-agen melalui delegasi berbasis LLM atau memanggil spesialis secara eksplisit menggunakan AgentToolAgen wisata kuliner, transportasi, atau pemandu wisata akhir pekan adalah contoh yang umum.

Pola pipeline sekuensial hanyalah sebuah SequentialAgent yang setiap anaknya menerapkan langkah yang terdefinisi dengan baik dari suatu proses. Alur generator-dan-kritik adalah varian klasik: agen pertama menulis draf dan menyimpannya di bawah sebuah output_keyAgen kedua menganalisisnya dan menyimpan umpan balik, dan mungkin agen ketiga menyempurnakan hasilnya berdasarkan umpan balik tersebut.

Pola penyebaran/pengumpulan paralel dinyatakan sebagai ParallelAgent tersusun di dalam alur kerja sekuensial. Anak-anak paralel menulis hasil ke dalam kunci status terpisah; agen sintetis selanjutnya membacanya kembali dan menyajikan jawaban gabungan.

Dekomposisi tugas hierarkis muncul secara alami dari pohon induk/anak. Agen tingkat yang lebih tinggi memecah tujuan menjadi sub-tujuan dan mendelegasikannya kepada anak-anaknya (baik melalui delegasi atau alat), dengan hasil yang kembali ke atas pohon. Hal ini sangat berguna dalam asisten penelitian, pengoptimal rantai pasokan, atau sistem penasihat keuangan di mana setiap sub-domain memiliki agen spesialisnya sendiri.

Penyempurnaan berulang dengan LoopAgent Memformalkan siklus generator-kritik menjadi pola yang dapat digunakan kembali. Siklus ini mengeksekusi agen perencana, pengkritik, dan penyempurna beberapa kali, menggunakan kunci status untuk menyimpan rencana terbaru dan umpan balik yang sesuai, dan berhenti ketika kriteria kualitas atau batas iterasi tercapai.

Arsitektur referensi untuk sistem multi-agen di Google Cloud

Di luar logika agen, Anda tetap perlu menjalankan sistem Anda di suatu tempat, dan Google Cloud menawarkan arsitektur referensi yang terdefinisi dengan baik untuk penerapan multi-agen tingkat produksi. Secara garis besar, solusi ini menggabungkan antarmuka pengguna (frontend), lingkungan eksekusi agen, model AI Vertex, layanan keamanan, dan kerangka kerja alat opsional seperti MCP.

Pengaturan tipikal dimulai dengan antarmuka pengguna (frontend) – seringkali berupa antarmuka obrolan – yang berjalan di Cloud Run. Pengguna berinteraksi dengan antarmuka pengguna ini, yang meneruskan permintaan ke agen koordinator yang diekspos sebagai layanan. Koordinator ini kemudian memilih di antara berbagai alur kerja agen berdasarkan maksud pengguna, termasuk jalur opsional yang melibatkan manusia di mana orang dapat memvalidasi atau mengesampingkan keputusan agen.

Agen itu sendiri dapat berjalan di beberapa lingkungan: layanan Cloud Run, Google Kubernetes Engine (GKE) atau Vertex AI Agent Engine. ADK mencakup opsi-opsi ini, mengabstraksikan beberapa detail runtime sehingga pengembang dapat fokus pada logika agen daripada infrastruktur pendukung.

Semua panggilan agen bergantung pada Vertex AI atau runtime model lainnya untuk inferensi, yang sering kali dibungkus dengan Model Armor untuk membersihkan perintah dan respons. Model Armor membantu menyaring upaya injeksi prompt, kebocoran data sensitif, atau konten berbahaya sebelum atau setelah pemanggilan model, bertindak sebagai pengaman di sekitar komponen generatif.

Alat dan server MCP (Model Context Protocol) berperan ketika agen harus berkomunikasi dengan sistem eksternal – basis data, sistem file, atau API SaaS – dengan cara yang terstandarisasi. MCP mendefinisikan kontrak umum antara agen dan server alat, sehingga satu klien MCP di agen Anda dapat mengakses banyak alat yang dibangun oleh tim yang berbeda tanpa keterkaitan yang erat; esto incluye consideraciones sobre Sistem penyimpanan data dan bagaimana mengungkapkan cara yang aman.

Keamanan dan tata kelola untuk aplikasi agenik

Sistem berbasis agen menghadirkan tantangan keamanan yang melampaui layanan mikro tradisional, karena LLM (Learning Linked Models) dapat diperdaya untuk menyalahgunakan alat atau membocorkan data jika Anda tidak berhati-hati. Pendekatan yang direkomendasikan Google menggabungkan kontrol keamanan deterministik dengan pertahanan berbasis kebijakan yang sadar LLM; también es clave entender los límites, sesgos y riesgos de los modelos al diseñar estas defensas.

Pengawasan manusia tetap sangat penting: alur kerja yang berdampak tinggi harus mencakup langkah-langkah persetujuan di mana seseorang dapat menghentikan sementara, meninjau, atau memveto tindakan yang diusulkan oleh agen. Ini dapat dimodelkan sebagai alat "konfirmasi manusia" khusus yang menampilkan permintaan ke antarmuka pengguna dan hanya melanjutkan eksekusi setelah manusia merespons.

Kontrol akses untuk agen ditangani melalui IAM: setiap agen atau akun layanan hanya boleh memiliki izin minimal yang diperlukan untuk menjalankan tugasnya. Jika agen tertentu disusupi atau disalahgunakan, dampak yang ditimbulkan terbatas karena akun layanannya tidak dapat mengakses sumber daya atau alat yang tidak terkait.

Pembatasan akses alat berbasis kebijakan, diimplementasikan dengan komponen seperti... SecurityPlugin ditambah PolicyEngine, memungkinkan Anda meminta konfirmasi pengguna sebelum alat-alat tertentu dijalankan. Ketika suatu kebijakan menandai panggilan sensitif, plugin akan mencegatnya, mengeluarkan panggilan fungsi khusus "meminta konfirmasi", dan menunggu aplikasi Anda untuk memberikan keputusan, sehingga secara efektif melibatkan manusia dalam operasi berisiko tinggi.

Fitur keamanan standar Google Cloud melengkapi gambaran keseluruhan: Kontrol Layanan VPC untuk mengurangi risiko kebocoran data, CMEK untuk kunci enkripsi yang dikelola pelanggan, Cloud Armor untuk WAF dan perlindungan DDoS, IAP atau Platform Identitas untuk mengautentikasi pengguna, dan IAM yang terperinci untuk akses sumber daya. Untuk komunikasi antar agen melalui A2A, TLS 1.2+ dan autentikasi berbasis OAuth diperlukan atau direkomendasikan dalam lingkungan produksi.

Keandalan, kemampuan pengamatan, dan optimalisasi biaya

Implementasi MAS (Multi-Application Programming) di lingkungan produksi harus andal, dapat dipantau, dan hemat biaya; ADK terintegrasi dengan baik dengan perangkat operasional Google Cloud untuk mewujudkan hal tersebut. Anda dapat menginstrumentasi agen, sesi, dan alat sehingga log dan jejaknya muncul di Cloud Logging dan Cloud Trace.

Dari sudut pandang keandalan, rancang grafik agen Anda agar dapat mentoleransi kegagalan pada komponen individual. Jika memungkinkan, hindari satu otak pusat yang tak tergantikan; biarkan agen independen melakukan tugas-tugas lokal sehingga gangguan di satu jalur tidak menyebabkan seluruh aplikasi berhenti berfungsi; además, emplea técnicas como keseimbangan muatan dalam distribusi bisnis untuk mendistribusikan muatan dan mengurangi puntos de fallo. Simulasikan kegagalan dalam pementasan untuk memvalidasi perilaku koordinasi di bawah tekanan.

Untuk panggilan model, Vertex AI mendukung kuota bersama dinamis dan throughput yang disediakan. Kuota bersama menghindari batasan per proyek yang ketat dalam skenario bayar sesuai penggunaan, sementara throughput yang disediakan sangat penting untuk beban kerja QPS tinggi dan sensitif terhadap latensi yang tidak boleh dibatasi. Memantau tingkat permintaan dan penggunaan token membantu Anda memutuskan kapan harus beralih dari kapasitas sesuai permintaan ke kapasitas yang disediakan.

Pengendalian biaya sebagian besar bergantung pada pemilihan model yang cerdas, desain prompt yang cermat, dan menghindari token yang tidak perlu. Mulailah dengan model yang hemat biaya jika memungkinkan, buat perintah ringkas tetapi informatif, mintalah output singkat secara eksplisit jika memungkinkan, manfaatkan caching konteks untuk perintah besar yang berulang, dan pertimbangkan prediksi batch jika beban kerja memungkinkan.

Penyetelan sumber daya Cloud Run dan diskon jangka panjang semakin mengoptimalkan biaya waktu proses. Mulailah dengan pengaturan CPU/memori default, amati penggunaan sebenarnya, dan sesuaikan. Untuk beban kerja yang dapat diprediksi, diskon penggunaan yang dialokasikan secara signifikan mengurangi pengeluaran.

Dari sisi pengamatan, Anda harus memperlakukan agen sebagai entitas kelas satu dalam strategi pemantauan Anda. Catat masukan, keputusan (misalnya alat apa yang mereka gunakan, agen mana yang mereka delegasikan), dan perubahan status mereka. Gunakan grafik peristiwa ADK di UI web untuk men-debug sesi individual, dan Cloud Logging plus dasbor khusus untuk tren di seluruh armada.

Jika dilakukan dengan baik, praktik-praktik ini memberi Anda pandangan transparan tentang MAS Anda: Anda dapat melihat agen mana yang lambat, alat mana yang terlalu sering digunakan, di mana petunjuk terlalu panjang, dan di mana siklus kontrol kualitas seperti LoopAgent berulang lebih banyak dari yang diharapkan. Siklus umpan balik tersebut sangat penting untuk menyempurnakan kualitas dan biaya dari waktu ke waktu.

Dengan menggabungkan primitif agen ADK, pola alur kerja, dan mekanisme status dengan arsitektur referensi Google Cloud, tumpukan keamanan, dan perangkat operasional, Anda dapat merancang sistem multi-agen yang tidak hanya cerdas di atas kertas tetapi juga dapat diimplementasikan, dikelola, dan layak secara ekonomi dalam produksi. Dimulai dari agen induk/anak yang sederhana dan berkembang melalui orkestrasi Sekuensial, Perulangan, dan Paralel, Anda akan mendapatkan seperangkat alat untuk mengubah ide-ide berbasis agen menjadi aplikasi yang tangguh, mudah dipelihara, dan benar-benar memberikan nilai bisnis.