Cara Membangun Sistem Multi-Agen yang Siap Produksi dengan Agno dan Milvus

Jika Anda telah membuat agen AI, Anda mungkin pernah mengalami hal ini: demo Anda bekerja dengan baik, tetapi membuatnya menjadi produksi adalah cerita yang sama sekali berbeda.

Kami telah membahas manajemen memori agen dan pemeringkatan ulang di postingan sebelumnya. Sekarang mari kita bahas tantangan yang lebih besar-membangun agen yang benar-benar bertahan dalam produksi.

Inilah kenyataannya: lingkungan produksi berantakan. Agen tunggal jarang sekali dapat menyelesaikannya, itulah sebabnya sistem multi-agen ada di mana-mana. Tetapi kerangka kerja yang tersedia saat ini cenderung terbagi menjadi dua kubu: kerangka kerja ringan yang dapat melakukan demo dengan baik tetapi rusak di bawah beban nyata, atau kerangka kerja kuat yang membutuhkan waktu lama untuk dipelajari dan dibangun.

Saya telah bereksperimen dengan Agno baru-baru ini, dan tampaknya Agno berada di tengah-tengah yang masuk akal - berfokus pada kesiapan produksi tanpa kerumitan yang berlebihan. Proyek ini telah mendapatkan lebih dari 37.000 bintang GitHub dalam beberapa bulan, menunjukkan bahwa pengembang lain juga akan merasakan manfaatnya.

Dalam tulisan ini, saya akan membagikan apa yang saya pelajari saat membangun sistem multi-agen menggunakan Agno dengan Milvus sebagai lapisan memori. Kita akan melihat bagaimana Agno dibandingkan dengan alternatif lain seperti LangGraph dan melihat implementasi lengkap yang dapat Anda coba sendiri.

Apa itu Agno?

Agno adalah kerangka kerja multi-agen yang dibangun khusus untuk penggunaan produksi. Ini memiliki dua lapisan yang berbeda:

• Lapisan kerangka kerja Agno: Tempat Anda mendefinisikan logika agen Anda

• Lapisan runtime AgentOS: Mengubah logika tersebut menjadi layanan HTTP yang dapat Anda gunakan

Pikirkan seperti ini: lapisan kerangka kerja mendefinisikan apa yang harus dilakukan oleh agen Anda, sementara AgentOS menangani bagaimana pekerjaan itu dijalankan dan dilayani.

Lapisan Kerangka Kerja

Inilah yang Anda kerjakan secara langsung. Lapisan ini memperkenalkan tiga konsep inti:

• Agen: Menangani jenis tugas tertentu

• Tim: Mengkoordinasikan beberapa agen untuk memecahkan masalah yang kompleks

• Alur kerja: Mendefinisikan urutan dan struktur eksekusi

Satu hal yang saya hargai: Anda tidak perlu mempelajari DSL baru atau menggambar diagram alur. Perilaku agen didefinisikan menggunakan pemanggilan fungsi Python standar. Kerangka kerja ini menangani pemanggilan LLM, eksekusi alat, dan manajemen memori.

Lapisan Runtime AgentOS

AgentOS dirancang untuk volume permintaan yang tinggi melalui eksekusi asinkronisasi, dan arsitekturnya yang tanpa kewarganegaraan membuat penskalaan menjadi mudah.

Fitur utamanya meliputi:

• Integrasi FastAPI bawaan untuk mengekspos agen sebagai titik akhir HTTP

• Manajemen sesi dan respons streaming

• Memantau titik akhir

• Dukungan penskalaan horizontal

Dalam praktiknya, AgentOS menangani sebagian besar pekerjaan infrastruktur, yang memungkinkan Anda fokus pada logika agen itu sendiri.

Tampilan tingkat tinggi dari arsitektur Agno ditunjukkan di bawah ini.

Agno vs LangGraph

Untuk memahami di mana posisi Agno, mari kita bandingkan dengan LangGraph-salah satu kerangka kerja multi-agen yang paling banyak digunakan.

LangGraph menggunakan mesin state berbasis grafik. Anda memodelkan seluruh alur kerja agen Anda sebagai sebuah graf: langkah-langkah adalah simpul, jalur eksekusi adalah sisi. Ini bekerja dengan baik ketika proses Anda tetap dan terurut secara ketat. Tetapi untuk skenario yang bersifat terbuka atau percakapan, hal ini dapat terasa membatasi. Ketika interaksi menjadi lebih dinamis, mempertahankan graf yang bersih menjadi lebih sulit.

Agno mengambil pendekatan yang berbeda. Alih-alih menjadi lapisan orkestrasi murni, ini adalah sistem ujung ke ujung. Tentukan perilaku agen Anda, dan AgentOS secara otomatis mengeksposnya sebagai layanan HTTP siap produksi - dengan pemantauan, skalabilitas, dan dukungan percakapan multi-putaran yang sudah ada di dalamnya. Tidak ada gateway API terpisah, tidak ada manajemen sesi khusus, tidak ada perkakas operasional tambahan.

Inilah perbandingan singkatnya:

Dimensi	LangGraph	Agno
Model orkestrasi	Definisi graf eksplisit menggunakan simpul dan sisi	Alur kerja deklaratif yang didefinisikan dalam Python
Manajemen status	Kelas state khusus yang didefinisikan dan dikelola oleh pengembang	Sistem memori bawaan
Debugging & observabilitas	LangSmith (berbayar)	UI AgentOS (sumber terbuka)
Model runtime	Terintegrasi ke dalam runtime yang sudah ada	Layanan berbasis FastAPI mandiri
Kompleksitas penerapan	Membutuhkan pengaturan tambahan melalui LangServe	Bekerja di luar kotak

LangGraph memberi Anda lebih banyak fleksibilitas dan kontrol yang halus. Agno mengoptimalkan untuk waktu produksi yang lebih cepat. Pilihan yang tepat tergantung pada tahap proyek Anda, infrastruktur yang ada, dan tingkat penyesuaian yang Anda butuhkan. Jika Anda tidak yakin, menjalankan bukti konsep kecil dengan keduanya mungkin merupakan cara yang paling dapat diandalkan untuk memutuskan.

Memilih Milvus untuk Lapisan Memori Agen

Setelah Anda memilih kerangka kerja, keputusan selanjutnya adalah bagaimana menyimpan memori dan pengetahuan. Kami menggunakan Milvus untuk ini. Milvus adalah basis data vektor sumber terbuka paling populer yang dibuat untuk beban kerja AI dengan lebih dari 42.000+ bintang GitHub.

Agno memiliki dukungan Milvus asli. Modul agno.vectordb.milvus membungkus fitur-fitur produksi seperti manajemen koneksi, percobaan ulang otomatis, penulisan batch, dan pembuatan embedding. Anda tidak perlu membangun kumpulan koneksi atau menangani kegagalan jaringan sendiri-beberapa baris Python memberi Anda lapisan memori vektor yang berfungsi.

Milvus menyesuaikan dengan kebutuhan Anda. Ini mendukung tiga mode penyebaran:

• Milvus Lite: Ringan, berbasis file-sangat bagus untuk pengembangan dan pengujian lokal

• Standalone: Penerapan server tunggal untuk beban kerja produksi

• Terdistribusi: Cluster penuh untuk skenario skala tinggi

Anda bisa memulai dengan Milvus Lite untuk memvalidasi memori agen Anda secara lokal, lalu beralih ke standalone atau terdistribusi seiring dengan meningkatnya lalu lintas-tanpa mengubah kode aplikasi Anda. Fleksibilitas ini sangat berguna ketika Anda melakukan iterasi dengan cepat pada tahap awal, tetapi membutuhkan jalur yang jelas untuk meningkatkan skala di kemudian hari.

Langkah demi Langkah: Membangun Agen Agno Siap Produksi dengan Milvus

Mari kita membangun agen siap produksi dari awal.

Kita akan mulai dengan contoh agen tunggal sederhana untuk menunjukkan alur kerja secara keseluruhan. Kemudian kita akan mengembangkannya menjadi sistem multi-agen. AgentOS akan secara otomatis mengemas semuanya sebagai layanan HTTP yang dapat dipanggil.

1. Menerapkan Milvus Standalone dengan Docker

(1) Unduh berkas penerapan

**wget** **
<https://github.com/Milvus-io/Milvus/releases/download/v2.****5****.****12****/Milvus-standalone-docker-compose.yml> -O docker-compose.yml**

(2) Mulai Layanan Milvus

docker-compose up -d

docker-compose ps -a

2. Implementasi Inti

import os
from pathlib import Path
from agno.os import AgentOS
from agno.agent import Agent
from agno.models.openai import OpenAIChat
from agno.knowledge.knowledge import Knowledge
from agno.vectordb.milvus import Milvus
from agno.knowledge.embedder.openai import OpenAIEmbedder
from agno.db.sqlite import SqliteDb
os.environ\["OPENAI_API_KEY"\] = "you-key-here"
data_dir = Path("./data")
data_dir.mkdir(exist_ok=True)
knowledge_base = Knowledge(
    contents_db=SqliteDb(
        db_file=str(data_dir / "knowledge_contents.db"),
        knowledge_table="knowledge_contents",
    ),
    vector_db=Milvus(
        collection="agno_knowledge",
        uri="http://192.168.x.x:19530",
        embedder=OpenAIEmbedder(id="text-embedding-3-small"),
    ),
)
*# Create Agent*
agent = Agent(
    name="Knowledge Assistant",
    model=OpenAIChat(id="gpt-4o"),
    instructions=\[
        "You are a knowledge base assistant that helps users query and manage knowledge base content.",
        "Answer questions in English.",
        "Always search the knowledge base before answering questions.",
        "If the knowledge base is empty, kindly prompt the user to upload documents."
    \],
    knowledge=knowledge_base,
    search_knowledge=True,
    db=SqliteDb(
        db_file=str(data_dir / "agent.db"),
        session_table="agent_sessions",
    ),
    add_history_to_context=True,
    markdown=True,
)
agent_os = AgentOS(agents=\[agent\])
app = agent_os.get_app()
if __name__ == "__main__":
    print("\n🚀 Starting service...")
    print("📍 http://localhost:7777")
    print("💡 Please upload documents to the knowledge base in the UI\n")
    agent_os.serve(app="knowledge_agent:app", port=7777, reload=False)

(1) Menjalankan Agen

**python** **knowledge_agent.py**

3. Menghubungkan ke Konsol AgentOS

https://os.agno.com/

(1) Membuat Akun dan Masuk

(2) Hubungkan Agen Anda ke AgentOS

(3) Konfigurasikan Port yang Terbuka dan Nama Agen

(4) Menambahkan Dokumen dan Mengindeksnya di Milvus

(5) Menguji Agen dari Ujung ke Ujung

Dalam penyiapan ini, Milvus menangani pengambilan semantik berkinerja tinggi. Ketika asisten basis pengetahuan menerima pertanyaan teknis, asisten akan menggunakan alat search_knowledge untuk menyematkan kueri, mengambil potongan dokumen yang paling relevan dari Milvus, dan menggunakan hasil tersebut sebagai dasar tanggapannya.

Milvus menawarkan tiga opsi penerapan, yang memungkinkan Anda untuk memilih arsitektur yang sesuai dengan kebutuhan operasional Anda sambil menjaga API tingkat aplikasi tetap konsisten di semua mode penerapan.

Demo di atas menunjukkan alur pengambilan dan pembuatan inti. Namun, untuk memindahkan desain ini ke dalam lingkungan produksi, beberapa aspek arsitektur perlu didiskusikan secara lebih rinci.

Bagaimana Hasil Pengambilan Dibagikan ke Seluruh Agen

Mode Tim Agno memiliki opsi share_member_interactions=True yang memungkinkan agen-agen yang datang kemudian untuk mewarisi riwayat interaksi penuh dari agen-agen sebelumnya. Dalam praktiknya, ini berarti bahwa ketika agen pertama mengambil informasi dari Milvus, agen berikutnya dapat menggunakan kembali hasil tersebut alih-alih menjalankan pencarian yang sama lagi.

• Kebalikannya: Biaya pencarian diamortisasi di seluruh tim. Satu pencarian vektor mendukung banyak agen, mengurangi permintaan yang berlebihan.

• Kelemahannya: Kualitas pencarian akan meningkat. Jika pencarian awal menghasilkan hasil yang tidak lengkap atau tidak akurat, kesalahan tersebut akan menyebar ke setiap agen yang bergantung padanya.

Inilah sebabnya mengapa akurasi pencarian menjadi lebih penting dalam sistem multi-agen. Pencarian yang buruk tidak hanya menurunkan respons satu agen, tetapi juga memengaruhi seluruh tim.

Berikut adalah contoh pengaturan Tim:

from agno.team import Team
analyst = Agent(
    name="Data Analyst",
    model=OpenAIChat(id="gpt-4o"),
    knowledge=knowledge_base,
    search_knowledge=True,
    instructions=\["Analyze data and extract key metrics"\]
)
writer = Agent(
    name="Report Writer",
    model=OpenAIChat(id="gpt-4o"),
    knowledge=knowledge_base,
    search_knowledge=True,
    instructions=\["Write reports based on the analysis results"\]
)
team = Team(
    agents=\[analyst, writer\],
    share_member_interactions=True,  *# Share knowledge retrieval results*
)

Mengapa Agno dan Milvus Diletakkan Secara Terpisah

Dalam arsitektur ini, Agno berada di lapisan percakapan dan orkestrasi. Ia bertanggung jawab untuk mengelola aliran dialog, mengoordinasikan agen, dan mempertahankan status percakapan, dengan riwayat sesi yang disimpan dalam basis data relasional. Pengetahuan domain sistem yang sebenarnya-seperti dokumentasi produk dan laporan teknis-ditangani secara terpisah dan disimpan sebagai penyematan vektor di Milvus. Pembagian yang jelas ini membuat logika percakapan dan penyimpanan pengetahuan sepenuhnya terpisah.

Mengapa ini penting secara operasional:

• Penskalaan independen: Seiring dengan meningkatnya permintaan Agno, tambahkan lebih banyak instance Agno. Seiring bertambahnya volume kueri, perluas Milvus dengan menambahkan node kueri. Setiap lapisan berskala secara terpisah.

• Kebutuhan perangkat keras yang berbeda: Agno terikat pada CPU dan memori (inferensi LLM, eksekusi alur kerja). Milvus dioptimalkan untuk pengambilan vektor dengan throughput tinggi (disk I/O, terkadang akselerasi GPU). Memisahkan keduanya mencegah perebutan sumber daya.

• Optimalisasi biaya: Anda dapat menyetel dan mengalokasikan sumber daya untuk setiap lapisan secara independen.

Pendekatan berlapis ini memberi Anda arsitektur yang lebih efisien, tangguh, dan siap produksi.

Apa yang Harus Dipantau Saat Menggunakan Agno dengan Milvus

Agno memiliki kemampuan evaluasi bawaan, tetapi dengan menambahkan Milvus, Anda bisa memperluas apa yang harus Anda pantau. Berdasarkan pengalaman kami, fokuslah pada tiga area:

• Kualitas pengambilan: Apakah dokumen yang dikembalikan Milvus benar-benar relevan dengan kueri, atau hanya mirip secara dangkal pada tingkat vektor?

• Kesesuaian jawaban: Apakah jawaban akhir didasarkan pada konten yang diambil, atau apakah LLM menghasilkan klaim yang tidak didukung?

• Perincian latensi ujung ke ujung: Jangan hanya melacak waktu respons total. Perinci berdasarkan tahap-pembuatan embedding, pencarian vektor, perakitan konteks, inferensi LLM-sehingga Anda dapat mengidentifikasi di mana perlambatan terjadi.

Contoh praktis: Ketika koleksi Milvus Anda bertambah dari 1 juta menjadi 10 juta vektor, Anda mungkin akan melihat latensi pengambilan yang meningkat. Itu biasanya merupakan sinyal untuk menyetel parameter indeks (seperti nlist dan nprobe) atau mempertimbangkan untuk berpindah dari penerapan mandiri ke penerapan terdistribusi.

Kesimpulan

Membangun sistem agen yang siap produksi membutuhkan lebih dari sekadar menyambungkan panggilan LLM dan demo pengambilan. Anda membutuhkan batasan arsitektur yang jelas, infrastruktur yang dapat berkembang secara mandiri, dan kemampuan pengamatan untuk menangkap masalah lebih awal.

Dalam artikel ini, saya menjelaskan bagaimana Agno dan Milvus dapat bekerja sama: Agno untuk orkestrasi multi-agen, Milvus untuk memori yang dapat diskalakan dan pengambilan semantik. Dengan memisahkan lapisan-lapisan ini, Anda dapat berpindah dari prototipe ke produksi tanpa menulis ulang logika inti-dan menskalakan setiap komponen sesuai kebutuhan.

Jika Anda bereksperimen dengan pengaturan serupa, saya ingin tahu apa yang berhasil untuk Anda.

Ada pertanyaan tentang Milvus? Bergabunglah dengan saluran Slack kami atau pesan sesi Jam Kantor Milvus selama 20 menit.