View a markdown version of this page

Gunakan sesi terisolasi untuk agen - Batu Dasar Amazon AgentCore

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Gunakan sesi terisolasi untuk agen

Amazon Bedrock AgentCore Runtime memungkinkan Anda mengisolasi setiap sesi pengguna dan menggunakan kembali konteks dengan aman di beberapa pemanggilan dalam sesi pengguna. Isolasi sesi sangat penting untuk beban kerja agen AI karena karakteristik operasionalnya yang unik:

  • Pemisahan lingkungan eksekusi lengkap: Setiap sesi pengguna di AgentCore Runtime menerima microVM khusus sendiri dengan sumber daya Compute, memori, dan filesystem yang terisolasi. Ini mencegah agen satu pengguna mengakses data pengguna lain. Setelah sesi selesai, seluruh microVM dihentikan dan memori disanitasi untuk menghapus semua data sesi, menghilangkan risiko kontaminasi lintas sesi.

  • Proses penalaran stateful: Tidak seperti fungsi stateless, agen AI mempertahankan keadaan kontekstual yang kompleks sepanjang siklus eksekusi mereka, di luar riwayat pesan sederhana untuk percakapan multi-putaran. AgentCore Runtime mempertahankan status ini dengan aman dalam sesi sambil memastikan isolasi lengkap antara pengguna yang berbeda, memungkinkan pengalaman agen yang dipersonalisasi tanpa mengorbankan batasan data.

  • Operasi alat istimewa: Agen AI melakukan operasi istimewa atas nama pengguna melalui alat terintegrasi yang mengakses berbagai sumber daya. AgentCore Model isolasi Runtime memastikan operasi alat ini mempertahankan konteks keamanan yang tepat dan mencegah berbagi kredensia atau eskalasi izin antara sesi pengguna yang berbeda.

  • Keamanan deterministik untuk proses non-deterministik: Perilaku agen AI dapat bersifat non-deterministik karena sifat probabilistik model pondasi. AgentCore Runtime menyediakan batas isolasi deterministik yang konsisten terlepas dari pola eksekusi agen, memberikan properti keamanan yang dapat diprediksi yang diperlukan untuk penerapan perusahaan.

catatan

AgentCore tidak menerapkan pemetaan sesi-ke-pengguna - backend klien Anda harus menjaga hubungan antara pengguna dan ID sesi mereka. Selain itu, backend klien Anda harus menerapkan logika untuk manajemen siklus hidup pengguna ke sesi seperti jumlah sesi maksimum per pengguna. Untuk panduan isolasi sesi lengkap, lihat Prakti k terbaik keamanan untuk AgentCore Runtime.

Memahami konteks fana

Secara default, komputasi (microVM) yang terkait dengan sesi bersifat sementara. Setiap data yang disimpan dalam memori atau ditulis ke disk tetap ada hanya untuk siklus hidup komputasi. Ini termasuk riwayat percakapan, preferensi pengguna, hasil perhitungan menengah, dan informasi status lainnya yang disimpan agen Anda.

Untuk mempertahankan data sistem file di seluruh stop/resume siklus sesi, konfigurasikan penyimpanan sesi — direktori persisten yang bertahan dari penghentian komputasi. Lihat Konfigur asi sistem file untuk AgentCore Runtime.

Untuk data terstruktur yang perlu disimpan di luar masa sesi (seperti riwayat percakapan pengguna, preferensi yang dipelajari, atau wawasan penting), gunakan AgentCore Memori. Layanan ini menyediakan penyimpanan persisten khusus yang dirancang khusus untuk beban kerja agen, dengan kemampuan memori jangka pendek dan jangka panjang.

Percakapan yang diperpanjang dan alur kerja multi-langkah

Tidak seperti fungsi tanpa server tradisional yang berakhir setelah setiap permintaan, AgentCore mendukung sesi terisolasi yang didukung oleh komputasi sementara. Sesi berlangsung hingga 8 jam untuk setiap siklus hidup di MicroVM, atau hingga 14 hari pada Instans. Dengan sesi ini, Anda dapat membangun alur kerja agen multi-langkah, membuat beberapa panggilan ke lingkungan yang sama dengan setiap pemanggilan berdasarkan konteks interaksi sebelumnya. Anda dapat menggunakan keduanya InvokeAgentRuntime untuk penalaran agen dan InvokeAgentRuntimeCommand untuk eksekusi perintah shell deterministik dalam sesi yang sama.

AgentCore Siklus hidup sesi runtime

Pembuatan sesi

Sesi baru dibuat pada pemanggilan pertama dengan runtime unik yang SessionId disediakan oleh aplikasi Anda. AgentCore Runtime menyediakan lingkungan eksekusi khusus (MicroVM) untuk setiap sesi. Konteks dipertahankan antara pemanggilan ke sesi yang sama. K InvokeAgentRuntime edu InvokeAgentRuntimeCommand anya dan beroperasi pada sesi yang sama — perintah melihat wadah, sistem file, dan lingkungan yang sama dengan agen.

Status sesi

Status sesi ditentukan oleh siklus hidup komputasi dan dapat menjadi salah satu dari berikut ini:

  • Aktif: Baik memproses permintaan sinkronisasi, menjalankan perintah, atau melakukan tugas latar belakang. Aktivitas pemanggilan sinkronisasi dan eksekusi perintah dilacak secara otomatis berdasarkan pemanggilan ke sesi runtime. Tugas latar belakang dikomunikasikan oleh kode agen dengan merespons dengan status HealthyBusy "" dalam ping.

  • Idle: Saat tidak memproses permintaan atau tugas latar belakang apa pun. Sesi telah menyelesaikan pemrosesan tetapi tetap tersedia untuk pemanggilan di masa mendatang.

  • D ihentikan: Komputasi (MicroVM) yang disediakan untuk sesi telah dihentikan dan sesi dihentikan. Hal ini dapat terjadi karena tidak aktif (default 15 menit), mencapai masa pakai komputasi maksimum (default 8 jam), penghentian eksplisit dengan memanggil StopRuntimeSession API, atau jika komputasi dianggap tidak sehat berdasarkan pemeriksaan kesehatan. Sesi beralih kembali ke Aktif pada pemanggilan berikutnya dan komputasi baru disediakan, dengan konfigurasi siklus hidup yang sama (yaitu idle RuntimeSessionTimeout dan maxLifetime yang bisa hingga 8 jam lagi). Sesi itu sendiri tetap valid sampai AgentCore Runtime ARN dihapus. Jika runtime dikonfigurasi dengan penyimpanan sesi, data sistem file di jalur pemasangan yang dikonfigurasi tetap ada di seluruh stop/resume siklus. Lihat Konfigur asi sistem file untuk AgentCore Runtime.

catatan

Sementara layanan menyediakan atau merobek sesi, operasi kedua yang menargetkan sesi yang sama mengembalikan HTTP 409 RetryableConflictException () Session operation in progress, please retry yang dapat dicoba ulang. Jendela ini singkat. Already-running sesi tidak terpengaruh. Coba lagi dengan mundur eksponensial pendek.

Cara menggunakan sesi

Untuk menggunakan sesi secara efektif:

  • Buat ID sesi unik untuk setiap pengguna atau percakapan dengan setidaknya 33 karakter

  • Berikan ID sesi yang sama untuk semua pemanggilan terkait

  • Gunakan ID sesi yang berbeda untuk pengguna atau percakapan yang berbeda

Contoh Menggunakan sesi untuk percakapan

# First message in a conversation response1 = agent_core_client.InvokeAgentRuntime( agentRuntimeArn=agent_arn, runtimeSessionId="user-123456-conversation-12345678", # or uuid.uuid4() payload=json.dumps({"prompt": "Tell me about AWS"}).encode() ) # Follow-up message in the same conversation reuses the runtimeSessionId. response2 = agent_core_client.InvokeAgentRuntime( agentRuntimeArn=agent_arn, runtimeSessionId="user-123456-conversation-12345678", # or uuid.uuid4() payload=json.dumps({"prompt": "How does it compare to other cloud providers"}).encode() )

Dengan menggunakan runtime yang sama SessionId untuk pemanggilan terkait, Anda memastikan bahwa konteks dipertahankan di seluruh percakapan, memungkinkan agen Anda memberikan respons koheren yang dibangun berdasarkan interaksi sebelumnya.

Header sesi berdasarkan protokol

Saat memanggil agen, sertakan header sesi yang sesuai untuk memastikan permintaan dialihkan ke microVM yang sama. Header tergantung pada protokol yang dikonfigurasi agen Anda:

Protokol Header Sesi

MCP

Mcp-Session-Id

HTTP

X-Amzn-Bedrock-AgentCore-Runtime-Session-Id

A2A

X-Amzn-Bedrock-AgentCore-Runtime-Session-Id

AG-UI

X-Amzn-Bedrock-AgentCore-Runtime-Session-Id

Kelengketan MicroVM: Amazon Bedrock AgentCore menggunakan header sesi untuk merutekan permintaan ke instance microVM yang sama. Klien harus menangkap ID sesi yang dikembalikan dalam respons dan memasukkannya ke dalam semua permintaan berikutnya untuk memastikan afinitas sesi. Tanpa ID sesi yang konsisten, setiap permintaan dapat dialihkan ke microVM baru, yang dapat mengakibatkan latensi tambahan karena cold start.

Untuk spesifikasi protokol MCP termasuk mode stateless dan stateful, lihat Manajemen sesi MCP dan lengket microVM.