- Một workshop thực hành của Anthropic về việc cấp cho agent bộ nhớ bền vững xuyên các phiên (session) bằng tính năng
memory storemới trongClaude Managed Agents, cùng tính năng "dreaming" để tinh chỉnh bộ nhớ theo thời gian. Memory storelà một kho bền vững giống file system, được gắn vào container của phiên, để agent đọc và ghi bằng các tool như bash và grep xuyên nhiều phiên.- "Dreaming" là một job batch đa-agent chạy bất đồng bộ, rà soát một memory store đầu vào cùng các bản ghi phiên cũ để fact-check, làm giàu, sắp xếp và khử trùng lặp, tạo ra một output memory store không phá hủy dữ liệu gốc cho các phiên tương lai.
Agents that remember
- Tình trạng hiện tại: agent và session bị cô lập — thông tin nói trong một phiên không chuyển sang phiên sau, hạn chế tính hữu ích; demo chứng minh điều này bằng cách kể cho một phiên về một bài nói CMA rồi thấy phiên sau không truy cập được.
Memory storelà kho bền vững giống file system, gắn như một resource vào các phiên, cho agent đọc/ghi xuyên phiên; được mount như file system thật vì đó là giao diện mạnh — model dùng bash để khám phá, grep để tìm từ khóa, và đọc file.- Bạn có thể tạo bao nhiêu memory store tùy thích với ranh giới tự chọn (theo user, workspace, tổ chức); mỗi cái tạo bằng một tên và mô tả, xem được trong console dạng file-system viewer, và hỗ trợ thêm bộ nhớ thủ công.
- Khi mount memory store vào phiên, bạn truyền một memory-store ID cùng một prompt định hướng (steering) và một trường access mặc định read/write nhưng có thể đặt read-only.
- Trong demo có bộ nhớ, agent trước tiên kiểm tra memory, lưu thông tin mới vào file
sessions.md, và ở phiên sau dùng grep tìm từ khóa (ví dụ "CMA") để trả lời — giải quyết vấn đề cô lập; các file bộ nhớ có versioning và sửa được, hỗ trợ rà soát human-in-the-loop. - Theo thời gian, agent có xu hướng "đổ" thông tin vào memory store, khiến nó phình ra, lộn xộn và lỗi thời; "dreaming" là một quy trình batch bất đồng bộ chạy qua API hoặc console, dùng harness đa-agent trên một memory store đầu vào và một tập bản ghi phiên.
- Một dream job nhận một model (ví dụ
Claude Opus 4.7hoặcSonnet 4.6), một memory store đầu vào, và danh sách session ID (10–100+), cùng instruction tùy chọn; nó không phá hủy — clone đầu vào thành output memory store, spawn một subagent cho mỗi phiên đầu vào để fact-check và làm giàu (thêm ngày, định danh, file index, event logistics), và hiển thị diff trong console. - Dreaming được thiết kế để vét cạn nên dùng nhiều token, nhưng phần lớn xử lý là agentic và được cache (kỳ vọng ~95% cache-hit), với các tùy chọn giảm chi phí tương lai như giảm 50% kiểu batch; session, memory store và dreaming tạo thành ba lớp composable — hội thoại cô lập, kết nối xuyên phiên, và tổ chức/làm giàu liên tục.
memory store(kho bộ nhớ) — memory storesession(phiên) — sessiondreaming— dreamingdream job— dream joboutput memory store— output memory storesteering prompt(prompt định hướng) — steering prompttrường access— access fieldindex file(file chỉ mục) — index filecache-hit rate— cache-hit rate
Vấn đề: Agent bị cô lập giữa các phiên
Kevin, kỹ sư tại Anthropic, trình bày cách xây "agent biết nhớ". Hiện tại, agent và session bị cô lập: agent không nhớ thông tin quá khứ và không chuyển thông tin sang phiên tương lai — điều này hạn chế tính hữu ích trong nhiều workflow thực tế.
Demo chứng minh: tạo một phiên tên "write test with no memory", kể cho nó về một bài nói CMA hôm trước với vài từ khóa (multi-agent orchestration, outcomes, memory) và một URL ghi chú. Model (Sonnet) chỉ trả lời "cảm ơn thông tin". Sau đó tạo phiên thứ hai hỏi lại về thông tin vừa kể — agent nói "tôi không có quyền truy cập thông tin đó". Đó chính là tình trạng cơ bản: không có thông tin nào chuyển giữa các phiên.
Memory Store: Bộ nhớ giống file system
Giải pháp là memory store — một kho bền vững giống file system, gắn như một resource vào các phiên, cho agent đọc/ghi xuyên phiên. Có thể tạo bao nhiêu cái tùy thích với ranh giới tự chọn (theo user, workspace, tổ chức). Điểm quan trọng: nó được mount như một file system thật, vì đó là giao diện rất mạnh cho model — dùng bash khám phá, grep tìm từ khóa, đọc file.
Tạo memory store cần một tên và mô tả; xem được trong console (managed agents → memory stores) dưới dạng file-system viewer, và có thể thêm bộ nhớ thủ công. Khi mount vào phiên, truyền memory-store ID, một steering prompt (định hướng agent đọc/ghi thông tin cụ thể), và một trường access (mặc định read/write, có thể đặt read-only).
Trong demo có bộ nhớ: agent trước tiên kiểm tra memory (rỗng), nên lưu thông tin mới vào file sessions.md. Phiên sau dùng cùng memory store, agent grep từ khóa "CMA", tìm thấy thông tin từ phiên trước và trả lời được — điều trước đây khó làm. Các file bộ nhớ có versioning (mỗi thay đổi tạo phiên bản mới) và sửa trực tiếp được, hỗ trợ rà soát thủ công.
Dreaming: Làm giàu và tổ chức bộ nhớ
Theo thời gian, agent có xu hướng "đổ" thông tin vào memory store, khiến nó phình ra, lộn xộn, lỗi thời, và không có quy trình tổ chức hay khử trùng lặp. "Dreaming" giải quyết điều này: một quy trình batch chạy bất đồng bộ qua API hoặc console, dùng một harness đa-agent. Nó rà từng phiên đầu vào (bạn chỉ định một memory store và một nhóm transcript), fact-check, làm giàu thêm chi tiết/ngày/định danh, tổ chức và khử trùng lặp, tạo ra một output memory store giúp tăng hiệu quả truy xuất và trí tuệ của agent tương lai.
Một dream job nhận model (Opus 4.7 hoặc Sonnet 4.6), một memory store và danh sách session ID (10, 20, tới 100). Có thể thêm instruction tùy chọn (ví dụ backfill chi tiết cụ thể, hoặc tổ chức file theo cấu trúc mong muốn). Console hiển thị trạng thái và token count; job có thể mất từ vài phút tới hàng giờ — đó là lợi ích của việc chạy bất đồng bộ, không nên chạy live khi agent đang làm việc.
Cơ chế bên trong và tính không phá hủy
Dreaming được xây trực tiếp trên các primitive của Claude Managed Agents, nên tạo hẳn một phiên cho dream job — quan sát được chính xác dream đang làm gì. Harness là multi-agent: một orchestrator spawn các subagent, mỗi subagent cho một phiên đầu vào, vì dreaming được thiết kế để vét cạn — cho nó 100 cơ hội thì muốn Claude rà hết để không bỏ sót.
Quan trọng: dreaming không phá hủy memory store đầu vào — nó clone thành output memory store và ghi vào đó. Khi hoàn tất, console hiển thị diff: dreaming tạo một index file (các slug tham chiếu file bộ nhớ, để agent tương lai nhanh chóng hiểu cần tìm gì thay vì grep rộng), thêm file event logistics (lịch Code with Claude, tên, lịch ngày hai), và định dạng lại file cũ với slug, mô tả, metadata, chi tiết hơn. Nhiều thông tin hơn thực sự giúp phiên tương lai, và dreaming luôn có thể xóa thứ không còn cần. Output memory store cũng là nơi tốt cho rà soát human-in-the-loop.
Ba lớp composable và chi phí
Dùng output memory store ở phiên tương lai: lấy nó qua dream ID, tạo phiên mới gắn output đó, rồi hỏi (đã dự những phiên nào, có link tài nguyên gì, đánh dấu follow-up nào). Lần này agent đọc index trước, rồi file sessions, trả về nhiều thông tin hơn hẳn — recap, timestamp, link. Có thể "nghỉ hưu" memory store cũ mà không ảnh hưởng phiên trước.
Ba lớp composable: session (instance cô lập, thường ephemeral, một luồng hội thoại); memory store (kết nối thông tin xuyên phiên); và dreaming (tổ chức, làm giàu, cải thiện theo thời gian, kiểm tra staleness). Về token: dreaming vét cạn nên dùng nhiều, nhưng phần lớn agentic và được cache (~95% cache-hit rate), với tùy chọn tương lai như giảm 50% kiểu batch, đổi model, định hướng prompt, hoặc budget token.
Tóm lại: memory là bước đầu giải bài toán nhớ xuyên phiên, nhưng tạo ra vấn đề bộ nhớ phình to/lộn xộn/lỗi thời; dreaming dùng một tập agent khác có nhiệm vụ cải thiện memory store cho lần dùng tương lai.
TL;DR
- Một workshop thực hành của Anthropic về việc cấp cho agent bộ nhớ bền vững xuyên các phiên (session) bằng tính năng
memory storemới trongClaude Managed Agents, cùng tính năng "dreaming" để tinh chỉnh bộ nhớ theo thời gian. Memory storelà một kho bền vững giống file system, được gắn vào container của phiên, để agent đọc và ghi bằng các tool như bash và grep xuyên nhiều phiên.- "Dreaming" là một job batch đa-agent chạy bất đồng bộ, rà soát một memory store đầu vào cùng các bản ghi phiên cũ để fact-check, làm giàu, sắp xếp và khử trùng lặp, tạo ra một output memory store không phá hủy dữ liệu gốc cho các phiên tương lai.
Điểm chính
- Tình trạng hiện tại: agent và session bị cô lập — thông tin nói trong một phiên không chuyển sang phiên sau, hạn chế tính hữu ích; demo chứng minh điều này bằng cách kể cho một phiên về một bài nói CMA rồi thấy phiên sau không truy cập được.
Memory storelà kho bền vững giống file system, gắn như một resource vào các phiên, cho agent đọc/ghi xuyên phiên; được mount như file system thật vì đó là giao diện mạnh — model dùng bash để khám phá, grep để tìm từ khóa, và đọc file.- Bạn có thể tạo bao nhiêu memory store tùy thích với ranh giới tự chọn (theo user, workspace, tổ chức); mỗi cái tạo bằng một tên và mô tả, xem được trong console dạng file-system viewer, và hỗ trợ thêm bộ nhớ thủ công.
- Khi mount memory store vào phiên, bạn truyền một memory-store ID cùng một prompt định hướng (steering) và một trường access mặc định read/write nhưng có thể đặt read-only.
- Trong demo có bộ nhớ, agent trước tiên kiểm tra memory, lưu thông tin mới vào file
sessions.md, và ở phiên sau dùng grep tìm từ khóa (ví dụ "CMA") để trả lời — giải quyết vấn đề cô lập; các file bộ nhớ có versioning và sửa được, hỗ trợ rà soát human-in-the-loop. - Theo thời gian, agent có xu hướng "đổ" thông tin vào memory store, khiến nó phình ra, lộn xộn và lỗi thời; "dreaming" là một quy trình batch bất đồng bộ chạy qua API hoặc console, dùng harness đa-agent trên một memory store đầu vào và một tập bản ghi phiên.
- Một dream job nhận một model (ví dụ
Claude Opus 4.7hoặcSonnet 4.6), một memory store đầu vào, và danh sách session ID (10–100+), cùng instruction tùy chọn; nó không phá hủy — clone đầu vào thành output memory store, spawn một subagent cho mỗi phiên đầu vào để fact-check và làm giàu (thêm ngày, định danh, file index, event logistics), và hiển thị diff trong console. - Dreaming được thiết kế để vét cạn nên dùng nhiều token, nhưng phần lớn xử lý là agentic và được cache (kỳ vọng ~95% cache-hit), với các tùy chọn giảm chi phí tương lai như giảm 50% kiểu batch; session, memory store và dreaming tạo thành ba lớp composable — hội thoại cô lập, kết nối xuyên phiên, và tổ chức/làm giàu liên tục.
Từ vựng
memory store(kho bộ nhớ) — memory storesession(phiên) — sessiondreaming— dreamingdream job— dream joboutput memory store— output memory storesteering prompt(prompt định hướng) — steering prompttrường access— access fieldindex file(file chỉ mục) — index filecache-hit rate— cache-hit rate
Nội dung chi tiết
Vấn đề: Agent bị cô lập giữa các phiên
Kevin, kỹ sư tại Anthropic, trình bày cách xây "agent biết nhớ". Hiện tại, agent và session bị cô lập: agent không nhớ thông tin quá khứ và không chuyển thông tin sang phiên tương lai — điều này hạn chế tính hữu ích trong nhiều workflow thực tế.
Demo chứng minh: tạo một phiên tên "write test with no memory", kể cho nó về một bài nói CMA hôm trước với vài từ khóa (multi-agent orchestration, outcomes, memory) và một URL ghi chú. Model (Sonnet) chỉ trả lời "cảm ơn thông tin". Sau đó tạo phiên thứ hai hỏi lại về thông tin vừa kể — agent nói "tôi không có quyền truy cập thông tin đó". Đó chính là tình trạng cơ bản: không có thông tin nào chuyển giữa các phiên.
Memory Store: Bộ nhớ giống file system
Giải pháp là memory store — một kho bền vững giống file system, gắn như một resource vào các phiên, cho agent đọc/ghi xuyên phiên. Có thể tạo bao nhiêu cái tùy thích với ranh giới tự chọn (theo user, workspace, tổ chức). Điểm quan trọng: nó được mount như một file system thật, vì đó là giao diện rất mạnh cho model — dùng bash khám phá, grep tìm từ khóa, đọc file.
Tạo memory store cần một tên và mô tả; xem được trong console (managed agents → memory stores) dưới dạng file-system viewer, và có thể thêm bộ nhớ thủ công. Khi mount vào phiên, truyền memory-store ID, một steering prompt (định hướng agent đọc/ghi thông tin cụ thể), và một trường access (mặc định read/write, có thể đặt read-only).
Trong demo có bộ nhớ: agent trước tiên kiểm tra memory (rỗng), nên lưu thông tin mới vào file sessions.md. Phiên sau dùng cùng memory store, agent grep từ khóa "CMA", tìm thấy thông tin từ phiên trước và trả lời được — điều trước đây khó làm. Các file bộ nhớ có versioning (mỗi thay đổi tạo phiên bản mới) và sửa trực tiếp được, hỗ trợ rà soát thủ công.
Dreaming: Làm giàu và tổ chức bộ nhớ
Theo thời gian, agent có xu hướng "đổ" thông tin vào memory store, khiến nó phình ra, lộn xộn, lỗi thời, và không có quy trình tổ chức hay khử trùng lặp. "Dreaming" giải quyết điều này: một quy trình batch chạy bất đồng bộ qua API hoặc console, dùng một harness đa-agent. Nó rà từng phiên đầu vào (bạn chỉ định một memory store và một nhóm transcript), fact-check, làm giàu thêm chi tiết/ngày/định danh, tổ chức và khử trùng lặp, tạo ra một output memory store giúp tăng hiệu quả truy xuất và trí tuệ của agent tương lai.
Một dream job nhận model (Opus 4.7 hoặc Sonnet 4.6), một memory store và danh sách session ID (10, 20, tới 100). Có thể thêm instruction tùy chọn (ví dụ backfill chi tiết cụ thể, hoặc tổ chức file theo cấu trúc mong muốn). Console hiển thị trạng thái và token count; job có thể mất từ vài phút tới hàng giờ — đó là lợi ích của việc chạy bất đồng bộ, không nên chạy live khi agent đang làm việc.
Cơ chế bên trong và tính không phá hủy
Dreaming được xây trực tiếp trên các primitive của Claude Managed Agents, nên tạo hẳn một phiên cho dream job — quan sát được chính xác dream đang làm gì. Harness là multi-agent: một orchestrator spawn các subagent, mỗi subagent cho một phiên đầu vào, vì dreaming được thiết kế để vét cạn — cho nó 100 cơ hội thì muốn Claude rà hết để không bỏ sót.
Quan trọng: dreaming không phá hủy memory store đầu vào — nó clone thành output memory store và ghi vào đó. Khi hoàn tất, console hiển thị diff: dreaming tạo một index file (các slug tham chiếu file bộ nhớ, để agent tương lai nhanh chóng hiểu cần tìm gì thay vì grep rộng), thêm file event logistics (lịch Code with Claude, tên, lịch ngày hai), và định dạng lại file cũ với slug, mô tả, metadata, chi tiết hơn. Nhiều thông tin hơn thực sự giúp phiên tương lai, và dreaming luôn có thể xóa thứ không còn cần. Output memory store cũng là nơi tốt cho rà soát human-in-the-loop.
Ba lớp composable và chi phí
Dùng output memory store ở phiên tương lai: lấy nó qua dream ID, tạo phiên mới gắn output đó, rồi hỏi (đã dự những phiên nào, có link tài nguyên gì, đánh dấu follow-up nào). Lần này agent đọc index trước, rồi file sessions, trả về nhiều thông tin hơn hẳn — recap, timestamp, link. Có thể "nghỉ hưu" memory store cũ mà không ảnh hưởng phiên trước.
Ba lớp composable: session (instance cô lập, thường ephemeral, một luồng hội thoại); memory store (kết nối thông tin xuyên phiên); và dreaming (tổ chức, làm giàu, cải thiện theo thời gian, kiểm tra staleness). Về token: dreaming vét cạn nên dùng nhiều, nhưng phần lớn agentic và được cache (~95% cache-hit rate), với tùy chọn tương lai như giảm 50% kiểu batch, đổi model, định hướng prompt, hoặc budget token.
Tóm lại: memory là bước đầu giải bài toán nhớ xuyên phiên, nhưng tạo ra vấn đề bộ nhớ phình to/lộn xộn/lỗi thời; dreaming dùng một tập agent khác có nhiệm vụ cải thiện memory store cho lần dùng tương lai.