View a markdown version of this page

Optimalkan agen Anda untuk Amazon Bedrock AgentCore Runtime V2 - Batu Dasar Amazon AgentCore

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

Optimalkan agen Anda untuk Amazon Bedrock AgentCore Runtime V2

Amazon Bedrock AgentCore Runtime V2 memulai agen Anda dengan memulihkan snapshot. Ini mengubah cara Anda menyusun kode agen Anda. Pekerjaan yang dilakukan agen Anda saat startup ditangkap dalam snapshot dan dibagikan oleh setiap instans yang dipulihkan. Hasilkan nilai apa pun yang harus berbeda antar permintaan, atau yang dapat kedaluwarsa, di handler permintaan Anda sebagai gantinya. Topik ini menjelaskan cara menyusun agen Anda di sekitar pekerjaan startup dan pekerjaan per permintaan sehingga tetap benar setelah setiap pemulihan. Untuk ikhtisar platform versi V2, lihat Versi platform.

Agen Anda memiliki dua konteks eksekusi:

Startup

Kode yang berjalan sekali saat proses Anda dimulai, sebelum AgentCore Runtime mengambil snapshot. AgentCore Runtime menangkap kode ini dalam snapshot, dan setiap instance mewarisi hasilnya.

Penanganan permintaan

Kode di /invocations handler Anda. Kode ini berjalan pada setiap permintaan pada setiap instance.

Gunakan satu aturan untuk memutuskan di mana kode berada. Hitung nilai saat startup jika tetap sama selama masa pakai snapshot. Hitung di handler Anda jika bervariasi per permintaan atau dapat kedaluwarsa. AgentCore Runtime mengambil satu snapshot per versi agen dan menggunakannya sampai Anda membuat atau memperbarui agen, sehingga umur snapshot adalah masa pakai versi tersebut.

Inisialisasi sekali saat startup

Lakukan pekerjaan mahal dan dapat digunakan kembali saat proses Anda dimulai, sebelum snapshot. Misalnya, impor dependensi, beban model beban, atau baca konfigurasi statis dari bundel penerapan Anda. Dengan AgentCore SDK, lakukan pekerjaan ini di cakupan modul, sebelum Anda meneleponapp.run(). Agen Anda tidak mendengarkan pada port 8080 sampai app.run() berjalan, jadi tidak /ping dapat berhasil dan tidak ada snapshot yang dapat diambil sampai pekerjaan startup Anda selesai. Snapshot menangkap agen yang sepenuhnya diinisialisasi dengan konstruksi, dan Anda tidak perlu melakukan gerbang/ping. Selesaikan inisialisasi dalam 120 detik setelah startup. Jika agen Anda tidak menjadi sehat tepat waktu, runtime gagal dalam pemeriksaan kesehatannya. Untuk informasi selengkapnya tentang /invocations titik akhir /ping dan, lihat Mem ahami kontrak layanan AgentCore Runtime.

import json, pathlib from bedrock_agentcore.runtime import BedrockAgentCoreApp # Runs once at import, before app.run() starts the server and before the # snapshot. Every restored instance inherits these objects. MODEL = load_model_weights() SETTINGS = json.loads((pathlib.Path(__file__).parent / "agent.json").read_text()) app = BedrockAgentCoreApp() @app.entrypoint def invoke(payload): # Per-request work runs here on every instance. ... app.run() # starts listening on 8080; the snapshot is taken after this

Jika agen menjalankan server HTTP-nya sendiri alih-alih AgentCore SDK, laporkan status sehat /ping hanya setelah inisialisasi selesai, sehingga snapshot menangkap agen yang diinisialisasi sepenuhnya.

Baca saja data saat startup yang sama untuk setiap instance dan tidak kedaluwarsa. Tangani nilai yang sensitif terhadap waktu, seperti kredenSIAL berumur pendek, di handler Anda.

catatan

Jangan menghitung apa pun saat startup yang Anda ubah tanpa menyebarkan ulang. Misalnya, katalog alat yang diambil dari AgentCore Gateway terlihat seperti nilai startup yang ideal karena lambat dan mahal untuk dimuat, tetapi menyimpan dalam cache saat startup membekukan inventaris alat agen Anda pada saat snapshot.

Jaga agar status per permintaan tetap segar

Snapshot diambil sekali dan dibagikan oleh setiap instans yang dipulihkan, sehingga nilai apa pun yang dihasilkan agen Anda saat startup identik di seluruh instans dan diperbaiki pada saat snapshot. Tangani nilai yang tidak dapat dibawa oleh snapshot di /invocations handler Anda. Tabel berikut menjelaskan nilai yang harus dihitung di handler Anda alih-alih saat startup.

Untuk melakukannya: Lakukan di handler Alasan

Hasilkan nilai acak, pengidentifikasi, atau token

Pang os.urandom() gilsecrets,, atau uuid.uuid4() pada setiap permintaan

os.urandom()mengembalikan entropi baru hanya setiap kali Anda memanggilnya setelah pemulihan. Nilai yang dibaca saat startup disalin ke snapshot dan identik pada setiap contoh, betapapun baiknya sumber entropi saat dibaca. randomModul juga disemai saat startup, jadi instance yang dipulihkan mengulangi urutan yang sama.

Baca waktu saat ini

Hitung untuk setiap permintaan

Stempel waktu yang diambil saat startup diperbaiki pada saat snapshot.

Mengukur waktu yang telah berlalu

Ambil stempel waktu referensi di handler Anda

time.monotonic()tidak maju melalui pemulihan, jadi durasi yang diukur dari referensi startup salah tanpa terlihat salah.

Gunakan kredensi atau token

Segarkan mereka saat kedaluwarsa

KredenSIAL yang dimuat saat startup dapat kedaluwarsa sebelum instance dimulai.

Identifikasi instance atau pekerja

Hasilkan id per permintaan; jangan mendapatkannya dari host

Setiap instance yang dipulihkan melaporkan hostname (localhost) dan PID (1) yang sama, jadi menggunakan keduanya sebagai id akan meruntuhkan metrik, aliran log, dan pemilik kunci di seluruh armada.

Bangun klien yang dapat digunakan kembali saat startup, dan hitung nilai per permintaan pada setiap panggilan.

import os, time # Build reusable clients at startup, before the snapshot. Exercise them here too # (for example, with a warm-up call) so the setup the client caches — endpoint and # credential resolution, connection pool — is captured in the snapshot. client = build_client() warm_up(client) @app.entrypoint def invoke(payload): creds = get_credentials() # refreshed when expired, not read at startup request_id = os.urandom(16).hex() # unique per request now = time.time() # current time, not snapshot time # Handle the request.

Gunakan pustaka kriptografi yang aman untuk snapshot

Saat AgentCore Runtime memulihkan instance dari snapshot, pustaka kriptografi yang menyimpan status acak di cache saat startup dapat menggunakan kembali status tersebut di seluruh instance. Pustaka kriptografi Anda harus menggunakan build snapshot-safe (snapsafe) yang disemai kembali setelah pemulihan.

Penerapan kode langsung

Gambar dasar yang dikelola layanan sudah menyertakan build yang aman untuk snapshot dari pustaka kriptografinya, jadi Anda tidak perlu mengambil tindakan apa pun untuk itu.

Bring-your-own perpustakaan kriptografi

Jika Anda membawa pustaka kriptografi Anda sendiri, misalnya dalam agen kontainer, gunakan build yang aman untuk snapshot sehingga build tersebut di-reset setelah pemulihan. Di Amazon Linux 2023, gunakanopenssl-snapsafe-libs.

Jaringan

Bangun klien saat startup dan harapkan koneksi kembali yang transparan

Soket yang Anda buka saat startup tidak bertahan dari pemulihan, tetapi pengaturan cache pustaka klien Anda di sekitarnya — penguraian model layanan, resolusi titik akhir, resolusi kredensia, dan kumpulan koneksi — melakukannya. Bangun dan latih klien Anda saat startup, dan harapkan panggilan pertama setelah pemulihan untuk membangun kembali koneksi secara transparan.

Jangan gunakan nama host atau PID sebagai pengidentifikasi instance unik

Setiap instance yang dipulihkan dimulai dari snapshot yang sama dan melaporkan nama host dan ID proses yang sama. Hasilkan pengenal unik di setiap permintaan.

Hindari mengikat ke port sumber tetap

Setelah pemulihan, koneksi yang disimpan pada waktu snapshot dibuat kembali, dan port sumber tetap dapat bertabrakan dengan penggantian itu di dalam instance. Instans yang dipulihkan adalah microVM terpisah dengan ruang nama jaringannya sendiri, sehingga konflik ada di dalam instance, bukan di seluruh instans.