Penyimpanan memori Managed Agents dari Anthropic dapat mempertahankan teks antarsesi. Untuk aplikasi yang harus memberi dua agen fakta tertinjau yang sama, penyimpanan persisten baru langkah pertama. Aplikasi harus menentukan pemilik rekaman, memeriksa bukti asli, memilih satu revisi tersimpan, dan menjaga byte tepatnya sebelum salah satu agen melihatnya. Panduan ini untuk pengembang dengan akses beta Managed Agents yang berwenang serta kendali atas autentikasi aplikasi, pemilihan penyimpanan, dan konfigurasi agen. Dasarnya adalah dokumentasi memori Anthropic saat ini dan referensi API yang diperiksa pada 20 Oktober 2026; BIG CHANGE tidak menjalankan pengujian akun atau model.
Perubahan besar
- Apa yang berubah: Memori JSON bertipe dan tertinjau dapat bertahan di penyimpanan Managed Agents. Aplikasi memeriksa sumber dan byte tepat yang tersimpan, membekukan satu potret privat, lalu mengirim byte disetujui yang sama ke dua sesi berwenang terpisah tanpa melampirkan penyimpanan memori.
- Mengapa penting: Perubahan penyimpanan di kemudian hari tidak dapat mengubah masukan yang sudah dibentuk untuk sesi tersebut.
- Yang perlu diperhatikan: Ketepatan sumber, otorisasi pengguna, dan mutu jawaban tetap memerlukan pemeriksaan terpisah.
Sebelum memulai
Siapkan satu fakta nyata, preferensi, atau aturan proyek dengan sumber asli yang boleh digunakan, ID sumber stabil dan revisi, serta pemilik yang menyetujui penyimpanan dan pengungkapan kepada kedua peran agen. Tentukan batas kesegaran peninjauan yang sesuai sebelum meninjau rekaman. Pastikan akses beta Managed Agents, kunci API privat, ruang kerja berwenang, dua ID agen terkonfigurasi, lingkungan, dan model yang diizinkan pada akun. Periksa pemakaian dan harga terkini sebelum mengizinkan empat sesi konsumen terbatas dalam prosedur ini. Jangan masukkan kunci dalam prompt atau bukti pencatatan.
Aplikasi memerlukan pemetaan identitas terautentikasi ke cakupan. Dalam status aplikasi tepercaya, ikat identitas itu ke ownerScopeId yang disetujui, ID ruang kerja, ID penyimpanan, dan dua ID agen yang diizinkan. Pisahkan penyimpanan pengguna atau proyek privat jika aturan aksesnya berbeda. Kunci API ruang kerja tidak mengautentikasi pengguna akhir, jalur bukan batas penyewa, dan prompt tidak dapat menghilangkan alat atau kredensial. Pastikan kedua konfigurasi konsumen tidak memiliki penyimpanan terlampir maupun konektor, kredensial lingkungan, atau jalur alat menuju penyimpanan yang dapat berubah. Jika batas ini tidak dapat dipastikan, berhenti sebelum mengirim rekaman.
1. Setujui rekaman berdasarkan sumbernya
Gunakan templat struktural ini, ganti setiap nilai dalam tanda kurung sudut dengan bukti nyata yang disetujui. Ini bukan contoh fakta atau klaim hasil. Serialisasikan objek lengkap menjadi satu teks JSON UTF-8 yang tepat sebelum persetujuan. Validator harus menerima persis kolom dan tipe ini, menolak kolom asing, meminta string yang tidak kosong dan tidak hanya berisi spasi serta cap waktu UTC yang valid, membatasi kind menjadi fact, preference atau project_rule, dan membatasi status menjadi active, disputed atau superseded. Hanya rekaman active yang boleh disuntikkan. Klaim yang disetujui harus cocok dengan sumber asli yang dikutip, termasuk tanggal berlaku dan cakupannya.
{
"schemaVersion": "memory-record/v1",
"recordId": "<opaque stable record ID>",
"ownerScopeId": "<trusted mapped scope ID>",
"kind": "<fact | preference | project_rule>",
"claim": "<precise source-supported claim>",
"sourceId": "<private original-source ID>",
"sourceRevision": "<original revision or exact source hash>",
"sourceQuoteOrPointer": "<minimal permitted quote or stable pointer>",
"validFrom": "<UTC timestamp>",
"checkedAt": "<UTC timestamp>",
"status": "active",
"reviewerId": "<approved human reviewer ID>",
"reviewedAt": "<UTC timestamp>"
}Bukti persetujuan privat aplikasi harus menunjukkan pemberi persetujuan sebenarnya, izin pemilik, sumber asli dan revisi, cakupan dan agen yang diizinkan, aturan kesegaran, serta SHA-256 atas byte JSON UTF-8 yang tepat itu. Catatan ini merekam keputusan manusia atas klaim nyata. String reviewerId dalam rekaman bukan autentikasi. Jangan menyimpan rekaman dengan pertentangan yang belum terselesaikan atau izin yang kurang. Anthropic menyimpan teks; tidak memvalidasi skema ini atau membuktikan kebenaran klaim.
2. Simpan dan baca kembali
Buat atau pilih penyimpanan memori sempit dalam ruang kerja berwenang dan catat ID memstore_... yang sebenarnya. Gunakan jalur tidak sensitif seperti /records/{opaque-record-id}.json. Sebelum permintaan, catat pelaku, waktu UTC, revisi sumber, hash byte yang disetujui, penyimpanan dan jalur, serta status pending. Pada panggilan langsung penyimpanan memori, gunakan agent-memory-2026-07-22; panggilan sesi menggunakan managed-agents-2026-04-01. Menurut Anthropic, menggabungkan kedua header beta pada permintaan penyimpanan menghasilkan HTTP 400. Referensi pembuatan dan manual memori menunjukkan bentuk SDK ini; cocokkan SDK terpasang dengan referensi saat ini:
mem = client.beta.memory_stores.memories.create(
store.id,
path="/records/<opaque-record-id>.json",
content=approved_json_text,
)Pembuatan tidak menimpa jalur yang sudah ada. Simpan ID mem_... yang dikembalikan, lalu daftarkan /records/ dalam penyimpanan bercakupan itu, memakai setiap next_page sebagai page berikutnya. Daftar dasar bawaan tidak menyertakan isi. Ambil memori yang dipilih berdasarkan ID untuk teks lengkap; bandingkan ID penyimpanan, ID memori, jalur, isi, dan content_sha256 dengan byte yang disetujui. Catat respons dan pembacaan ulang langsung dalam jurnal dan registri. Respons pembuatan saja bukan pemeriksaan penyelesaian. Jika tidak pasti, periksa jalur tepat dan rekaman langsung sebelum memutuskan hasil; tidak adanya hasil pencarian saja tidak membenarkan pembuatan ulang.
3. Bekukan revisi yang dipilih
Pada setiap eksekusi berikutnya, autentikasi pemanggil dan tentukan cakupan, penyimpanan, dan ID rekaman terpilih dari registri tepercaya. Jika perlu mencari, daftar semua halaman awalan terbatas itu, lalu langsung ambil mem_... yang dipilih. Hitung SHA-256 atas pengodean UTF-8 dari isi yang dikembalikan, bandingkan dengan content_sha256 penyedia dan hash byte tepat yang disetujui manusia, lalu validasi JSON lagi. Periksa ID rekaman, cakupan pemilik, revisi sumber, status active, kemutakhiran sumber, dan batas kesegaran yang sudah ditentukan. Jika ada pemeriksaan gagal, jangan kirim apa pun.
Tulis byte tepat yang diambil sekali saja ke penyimpanan privat yang dialamatkan dengan hash, memakai pembuatan eksklusif seperti open(path, "xb") pada Python. Baca ulang dan hitung hash berkas segera serta sebelum setiap pengiriman. Jangan pernah menimpa potret yang ada. Berkas parsial atau berkas yang ada dengan byte berbeda pada alamat itu perlu ditahan dan dicocokkan. Simpan persetujuan asli, ID penyimpanan, ID memori, hash penyedia, hash potret, dan keputusan cakupan dalam bukti pengambilan privat. Potret sekali-tulis ini adalah desain aplikasi, bukan pemasangan Anthropic yang dikunci ke versi.
4. Berikan byte yang sama ke dua sesi baru
Buat sesi baru agen A dengan ID agen dan lingkungan sebenarnya yang berwenang dan tanpa entri penyimpanan memori di resources. Pastikan sumber daya sesi yang dikembalikan serta alat dan kredensial efektif agen tidak meninggalkan jalur lain ke penyimpanan. Panduan sesi Anthropic mendokumentasikan pembuatan dan pengiriman user.message secara terpisah:
session = client.beta.sessions.create(
agent=approved_agent_id,
environment_id=approved_environment_id,
)
client.beta.sessions.events.send(
session.id,
events=[{"type": "user.message", "content": [{"type": "text", "text": message_text}]}],
)Sebelum events.send, baca ulang dan hitung hash potret privat. Susun message_text secara deterministik dari label eksplisit “data ditinjau”, pengenal rekaman, sumber, dan tinjauan, teks JSON tidak berubah dan SHA-256-nya, lalu pertanyaan sempit yang dapat dijawab sumber asli. Kolom yang ditampilkan merupakan format pesan aplikasi, bukan kolom respons penyedia. Sebelum mengirim, catat seluruh byte UTF-8 dan hash pesan, hash potret terpilih, ID agen berwenang, ID sesi, dan status kirim. Simpan hasil serta ID peristiwa terkirim sebenarnya atau pembacaan ulang daftar peristiwa jika tersedia. Hasil kirim tidak diketahui memerlukan pembacaan peristiwa, bukan pengiriman ulang membabi buta.
Buat sesi baru kedua untuk agen B dengan ID yang disetujui terpisah dan ketiadaan akses penyimpanan yang sama. Baca ulang potret sekali-tulis yang sama, verifikasi hash byte, susun dan catat pesan lengkap B, lalu kirim. Pertanyaan tugas atau metadata penerima boleh berbeda; pastikan byte JSON yang disematkan dan hash rekaman disetujui identik. Periksa setiap jawaban dan peristiwa alat terhadap sumber asli. Jawaban masuk akal atau kutipan tidak membuktikan ketergantungan internal model pada teks yang disuntikkan; bukti pesan dan peristiwa penyedia menetapkan apa yang diberikan aplikasi. Jika sesi mana pun punya pemasangan aktif atau jalur lain ke penyimpanan, jangan kirim ke sana.
5. Perbarui hanya setelah peninjauan sumber baru
Ketika sumber asli berubah, langsung ambil memori terkini dan bandingkan bukti lama serta baru bersama pemilik. Minta manusia menyetujui byte JSON pengganti yang tepat, dengan ID rekaman stabil, klaim atau penunjuk sumber yang dikoreksi, revisi sumber baru, serta waktu pemeriksaan dan tinjauan. Simpan bukti dan hash lama. Catat ID mem_..., content_sha256 terkini yang dibaca langsung, hash pengganti yang dituju, pelaku, persetujuan, dan status tertunda. Pembaruan bersyarat yang didokumentasikan adalah:
client.beta.memory_stores.memories.update(
memory_id=memory_id,
memory_store_id=store_id,
content=approved_replacement_json_text,
precondition={"type": "content_sha256", "content_sha256": fresh_old_hash},
)Penyedia menghitung hash isi UTF-8 tepat tanpa normalisasi. Ketidakcocokan menghasilkan HTTP 409 memory_precondition_failed_error. Saat menerima respons ini atau hasil jaringan tidak pasti, ambil lagi memori aktif dan periksa riwayat versi bila perlu. Bandingkan revisi sumber yang bersaing dan minta pemilik menggabungkan, menolak, atau menyetujui pengganti tepat yang baru; jangan pernah mengulang penulisan kedaluwarsa secara membabi buta. Setelah berhasil, pengambilan langsung harus memastikan jalur, seluruh teks pengganti, hash, dan ID versi memori sebelum jurnal menjadi confirmed.
Bekukan potret baru yang disetujui dari revisi terverifikasi itu. Mulai sesi A dan B baru yang berwenang tanpa pemasangan penyimpanan dan ulangi kedua pengiriman serta pemeriksaan sumber. Jangan ubah potret lama atau mengklaim pesan yang sudah terkirim memperbarui diri sendiri. Tandai potret sebelumnya tidak layak untuk penyuntikan mendatang. Jika pemilik menarik rekaman, hentikan pengiriman baru dan terapkan kebijakan retensi serta penghapusan datanya: menghapus memori terkini tidak selalu menghilangkan versi tersimpan. Pengarsipan atau penghapusan seluruh penyimpanan adalah keputusan terpisah.
Yang dianggap selesai
Bukti privat harus menghubungkan izin asli dan revisi sumber dengan hash JSON tepat yang disetujui; identitas nyata ruang kerja, penyimpanan, jalur, dan mem_... beserta pembacaan ulang langsung setelah pembuatan; satu potret tidak berubah; dua ID sesi berwenang berbeda tanpa pemasangan dengan hash pesan terkirim dan jawaban yang diperiksa terhadap sumber; serta pembaruan bersyarat disetujui dengan pembacaan langsung baru dan pemeriksaan sesi baru. Jika ada hubungan tidak diketahui, tandai seluruh latihan belum lengkap dan simpan alasan tepat penahanannya. Jika dijalankan, catat pemakaian sesi dan alat nyata serta biaya khusus akun; panduan berbasis dokumen ini tidak mengukur penghematan atau kinerja model.
Untuk pekerjaan terkait tetapi berbeda, meninjau satu keluaran Dream untuk sesi berikutnya membahas usulan penyimpanan yang dihasilkan. Proses di sini dimulai dari rekaman sumber yang disetujui pemilik dan mengunci persis apa yang diterima dua konsumen.
