Bagikan melalui

Menambahkan Penyedia Konteks

Halaman sebelumnya menunjukkan bagaimana middleware membungkus alur eksekusi agen dengan concerns lintas fungsi — pencatatan, pagar pengaman, penanganan kesalahan — tanpa menyentuh logika inti agen. Tetapi middleware berkaitan dengan bagaimana agen berjalan, bukan apa yang diketahui agen. Sejauh ini, pengetahuan agen berasal dari dua tempat: data pelatihannya dan apa pun yang dikatakan pengguna pada giliran percakapan saat ini.

Itu masalah. Agen yang berguna membutuhkan lebih dari itu. Perlu diingat apa yang dikatakan pengguna tiga giliran yang lalu, mengetahui preferensi pengguna, atau menarik fakta yang relevan dari pangkalan pengetahuan - semua sebelum mulai menghasilkan respons. Alat dapat mengambil informasi, tetapi alat tersebut bersifat reaktif: model harus memutuskan untuk memanggilnya. Jika model tidak menyadari bahwa ia perlu konteks, ia tidak akan memintanya.

Penyedia konteks menyelesaikan ini. Mereka adalah komponen yang berjalan sebelum dan sesudah setiap pemanggilan agen, secara proaktif menyuntikkan informasi yang relevan ke jendela konteks dan secara opsional mengekstrak status dari respons yang akan disimpan untuk digunakan di masa mendatang. Mereka memberi agen Anda memori, personalisasi, dan akses ke pengetahuan eksternal - tanpa mengubah instruksi atau kode agen.

Kapan menggunakan ini

Tambahkan penyedia konteks ke agen Anda saat:

  • Agen membutuhkan riwayat percakapan — harus ingat apa yang dikatakan pada giliran sebelumnya, bukan hanya pesan saat ini.
  • Anda ingin menyuntikkan data khusus pengguna — profil, preferensi, detail akun, atau status sesi — sehingga agen dapat mempersonalisasi responsnya.
  • Anda memerlukan generasi berbasis pengambilan (RAG) — secara otomatis mengambil dokumen atau fakta yang relevan dari basis pengetahuan sebelum setiap tanggapan.
  • Agen memerlukan instruksi dinamis — konteks yang berubah antara pemanggilan berdasarkan waktu hari, lokasi pengguna, atau kondisi runtime lainnya.
  • Anda ingin memisahkan perolehan data dari logika agen — agen tidak perlu mengetahui dari mana konteks berasal, hanya bahwa itu tersedia.

Mengapa tidak hanya menggunakan alat?

Alat dan penyedia konteks keduanya memberi agen akses ke informasi eksternal, tetapi mereka bekerja dengan cara yang pada dasarnya berbeda:

Aspek Tools Penyedia konteks
Pemicu Reaktif — model memutuskan kapan harus memanggil alat Proaktif — berjalan secara otomatis sebelum setiap pemanggilan
Kontrol Berbasis model: model memilih alat mana, kapan, dan dengan argumen apa Berbasis pengembang: Anda memutuskan konteks apa yang selalu tersedia
Visibilitas Model harus mengetahui adanya alat dan menilai bahwa alat tersebut relevan Konteks disuntikkan secara transparan — model melihatnya sebagai bagian dari perintah
Skenario penggunaan Tindakan dan pencarian sesuai permintaan: "cari web," "kueri database" Konteks yang selalu ada: riwayat percakapan, profil pengguna, pengetahuan yang telah dimuat sebelumnya
Biaya token Token hanya dihabiskan ketika alat dipanggil Token yang dihabiskan untuk setiap pemanggilan (konteksnya selalu dalam prompt)

Tidak ada yang lebih baik. Banyak agen menggunakan keduanya: penyedia konteks untuk informasi yang harus selalu ada (riwayat, profil pengguna, pengetahuan inti), dan alat untuk informasi yang harus diambil agen sesuai permintaan (hasil pencarian langsung, kueri database, panggilan API).

Petunjuk / Saran

Aturan praktis yang baik: jika agen sebaiknya memiliki informasi ini setiap saat ketika dijalankan, gunakan penyedia konteks. Jika agen harus mengambilnya hanya jika relevan, gunakan alat.

Cara kerja penyedia konteks

Penyedia konteks berpartisipasi dalam siklus hidup dua fase di sekitar setiap pemanggilan agen:

┌──────────────────────────────────────────────────────────────┐
│  Caller: agent.run("What's the return policy?")              │
└──────────────┬───────────────────────────────────────────────┘
               ▼
┌──────────────────────────────────────────────────────────────┐
│  BEFORE RUN — each context provider injects context          │
│                                                              │
│  • History provider loads past conversation messages         │
│  • Memory provider retrieves relevant facts/preferences      │
│  • RAG provider searches knowledge base and adds results     │
│  • Custom provider injects user profile, time, location      │
└──────────────┬───────────────────────────────────────────────┘
               ▼
┌──────────────────────────────────────────────────────────────┐
│  Agent core — model sees original input + all injected       │
│  context and generates a response                            │
└──────────────┬───────────────────────────────────────────────┘
               ▼
┌──────────────────────────────────────────────────────────────┐
│  AFTER RUN — each context provider processes the response    │
│                                                              │
│  • History provider saves the new messages                   │
│  • Memory provider extracts facts to remember for later      │
│  • Custom provider updates session state                     │
└──────────────────────────────────────────────────────────────┘

Poin-poin penting:

  1. Penyedia konteks berjalan secara otomatis. Anda hanya perlu mendaftarkannya sekali ketika membuat agen. Setelah itu, mereka berpartisipasi dalam setiap pemanggilan tanpa Anda harus menulis kode tambahan.
  2. Beberapa penyedia menyusun bersama-sama. Anda dapat mendaftarkan beberapa penyedia konteks — penyedia riwayat, penyedia RAG, dan penyedia kustom — dan semuanya berkontribusi pada jendela konteks yang sama. Kontribusi mereka digabungkan dalam urutan pendaftaran.
  3. Penyedia memiliki dua antarmuka. Hook sebelum menyuntikkan konteks (pesan, instruksi, alat) ke dalam prompt. Setelah kait memproses respons — menyimpan pesan, mengekstrak memori, atau memperbarui status.
  4. Penyedia mampu mengenali sesi. Penyedia konteks menerima sesi saat ini, sehingga mereka dapat memuat dan menyimpan data yang dibatasi pada percakapan tertentu. Lihat Sesi tentang cara kerja manajemen sesi.

Petunjuk / Saran

Untuk tampilan terperinci tentang tempat penyedia konteks berada di alur eksekusi agen lengkap — bersama middleware dan klien obrolan — lihat Arsitektur Alur Agen.

Mengelola jendela konteks

Setiap bagian konteks yang Anda suntikkan menggunakan token dari jendela konteks model. Sejarah tumbuh dengan setiap perubahan. Hasil RAG menambahkan potongan dokumen. Profil pengguna menambahkan metadata. Jika total melebihi batas model, informasi terlama atau paling tidak relevan akan dipotong — berpotensi kehilangan konteks penting.

Manajemen jendela konteks adalah pertimbangan penting saat menggunakan penyedia konteks: Strategi pemadatan meringkas atau memangkas riwayat yang lebih lama untuk tetap berada dalam batas token sambil mempertahankan informasi utama. Lihat Pemadatan.

Petunjuk / Saran

Untuk pengalaman langsung dengan penyedia memori dan konteks, lihat Langkah 4: Memori dalam tutorial Memulai.

Penting

Tidak disarankan untuk mempertahankan jendela konteks yang sangat panjang, karena performa model dapat turun seiring bertambahnya jendela konteks. Jika agen mulai mengalami penurunan performa, pertimbangkan untuk menggunakan strategi pemadatan untuk mengurangi ukuran konteks.

Pertimbangan

Pertimbangan Rincian
Anggaran token Setiap konteks yang disuntikkan menggunakan token. Pantau ukuran konteks total dengan hati-hati — terutama saat menggabungkan beberapa penyedia. Jika konteks menjadi tidak terbatas, informasi penting akan terpotong tanpa pemberitahuan.
Latensi pengambilan Penyedia konteks yang mengkueri layanan eksternal (database, indeks pencarian, API) menambahkan latensi ke setiap pemanggilan. Gunakan penyimpanan sementara, pooling koneksi, dan operasi asinkron untuk menjaga pengambilan tetap cepat.
Relevance Menyuntikkan konteks yang tidak relevan tidak hanya membuang-buang token — itu dapat secara aktif menurunkan respons model dengan mendilusikan sinyal. Pastikan penyedia Anda menyuntikkan informasi yang berfokus dan relevan.
Keusangan Konteks yang di-cache atau dimuat sebelumnya dapat menjadi kedaluarsa. Penyedia desain untuk menyegarkan data pada interval yang sesuai, dan mempertimbangkan apakah konteks yang sedikit kedaluarsa dapat diterima untuk kasus penggunaan Anda.
Komposabilitas Ketika beberapa penyedia berkontribusi pada jendela konteks yang sama, kontribusi mereka dapat berinteraksi dengan cara yang tidak terduga. Penyedia pengujian bersama-sama, bukan hanya secara individual, untuk memastikan konteks gabungan masuk akal.

Langkah berikutnya

Sekarang setelah agen Anda memiliki alat, keterampilan, middleware, dan penyedia konteks, langkah selanjutnya adalah agen sebagai alat - menyusun agen dengan menggunakan satu agen sebagai alat untuk agen lain, memungkinkan spesialisasi dan delegasi.

Agen sebagai Alat

Masuk lebih dalam:

  • Last updated on