Bộ Nhớ của AI Agent Hoạt Động Thế Nào (và Cách Kiểm Tra Qua API)

Tóm tắt

Các tác nhân AI thất bại không phải vì thiếu trí thông minh mà vì chúng quên. Việc hiểu bốn loại bộ nhớ tác nhân, cách chúng được lưu trữ và cách chúng ảnh hưởng đến hành vi API giúp bạn xây dựng các tác nhân đáng tin cậy hơn và phát hiện lỗi trước khi chúng được đưa vào sản xuất.

Thử Apidog ngay hôm nay

Giới thiệu

Đây là bí mật "bẩn thỉu" của hầu hết các thất bại của tác nhân AI: mô hình thì ổn, nhưng lớp bộ nhớ bị hỏng.

Một tác nhân không thể nhớ những gì đã xảy ra ba lượt trước, mất ngữ cảnh người dùng giữa các phiên hoặc tự mâu thuẫn giữa chừng không phải là ảo giác do chất lượng mô hình. Nó thất bại vì kiến trúc bộ nhớ không được thiết kế cẩn thận hoặc không được kiểm tra kỹ lưỡng.

Hippo, một hệ thống bộ nhớ tác nhân mã nguồn mở gần đây đã trở thành xu hướng, áp dụng phương pháp lấy cảm hứng từ sinh học: nó mô hình hóa bộ nhớ ngắn hạn, dài hạn và bộ nhớ sự kiện một cách riêng biệt, giống như cách bộ nhớ con người hoạt động. Dự án đó đã làm nổi bật một khoảng trống thực sự: hầu hết các nhà phát triển xây dựng bộ nhớ tác nhân như một phần bổ sung và chỉ phát hiện ra nó bị lỗi khi đã triển khai.

💡 Các Kịch bản thử nghiệm của Apidog cho phép bạn kiểm tra các cuộc hội thoại tác nhân có trạng thái, đa lượt trước khi chúng được triển khai. Bạn có thể xác minh rằng trạng thái phiên được chuyển tiếp giữa các lệnh gọi API, xác nhận cấu trúc ngữ cảnh và mô phỏng các lỗi bộ nhớ bằng Smart Mock. Lớp thử nghiệm này là chủ đề của nửa sau bài viết này. Bây giờ, hãy bắt đầu với những gì thực sự đang diễn ra bên trong bộ nhớ tác nhân. Xem [internal: api-testing-tutorial] để biết giới thiệu về phương pháp thử nghiệm rộng hơn.

Bộ nhớ tác nhân AI là gì?

Bộ nhớ tác nhân là bất kỳ cơ chế nào cho phép một hệ thống AI truy cập hoặc giữ lại thông tin ngoài đầu vào hiện tại. Nếu không có nó, mỗi lệnh gọi API đều không có trạng thái: mô hình nhận một lời nhắc, trả về một phản hồi và không nhớ gì cả.

Bốn loại bộ nhớ riêng biệt phục vụ các mục đích khác nhau.

Bốn loại bộ nhớ tác nhân

Bộ nhớ làm việc

Bộ nhớ làm việc là ngữ cảnh hoạt động của tác nhân: mọi thứ trong lời nhắc hiện tại. Đối với hầu hết các tác nhân dựa trên LLM, đây là cửa sổ ngữ cảnh. GPT-4o có cửa sổ ngữ cảnh 128K token. Claude 3.5 Sonnet hỗ trợ 200K. Gemini 1.5 Pro hỗ trợ 1M.

Bộ nhớ làm việc nhanh và chính xác nhưng đắt (bạn trả tiền cho mỗi token) và có giới hạn. Một khi đạt đến giới hạn, ngữ cảnh cũ nhất sẽ bị loại bỏ một cách lặng lẽ. Đây là nguồn lỗi tác nhân phổ biến nhất trong các tác vụ chạy dài.

Bộ nhớ sự kiện

Bộ nhớ sự kiện lưu trữ những gì đã xảy ra: nhật ký các tương tác, quyết định và quan sát trong quá khứ. Hãy nghĩ nó như nhật ký của tác nhân.

Thực tế, đây thường là một cơ sở dữ liệu vector (Chroma, Pinecone, Qdrant) hoặc một nhật ký sự kiện có cấu trúc. Tác nhân truy xuất các sự kiện trong quá khứ có liên quan thông qua tìm kiếm ngữ nghĩa trước khi tạo phản hồi. Phương pháp của Hippo lưu trữ chuỗi tương tác với dấu thời gian và trọng số phân rã, do đó các tương tác gần đây nhận được ưu tiên truy xuất cao hơn.

Bộ nhớ ngữ nghĩa

Bộ nhớ ngữ nghĩa lưu trữ những gì tác nhân biết: sự kiện, kiến thức chuyên môn, sở thích người dùng và kiến thức thế giới ổn định. Khác với bộ nhớ sự kiện, nó không được sắp xếp theo thời gian.

Điều này có thể được tải trước (một lời nhắc hệ thống với dữ liệu hồ sơ người dùng), được xây dựng động (các sự kiện được trích xuất từ các cuộc trò chuyện trước đây và lưu trữ trong biểu đồ tri thức), hoặc có nguồn gốc bên ngoài (RAG đối với kho tài liệu).

Bộ nhớ thủ tục

Bộ nhớ thủ tục lưu trữ cách thực hiện mọi việc: chuỗi hành động, các mẫu sử dụng công cụ và kỹ năng mà tác nhân đã học. Đây là phần khó xây dựng nhất và thường bị bỏ qua trong các hệ thống sản xuất.

Trong thực tế, nó xuất hiện dưới dạng các ví dụ ít shot được nhúng trong lời nhắc hệ thống, hoặc như một thư viện các kế hoạch hành động đã lưu trữ mà tác nhân có thể truy xuất và điều chỉnh.

Cách bộ nhớ được lưu trữ trong các hệ thống thực tế

Bốn loại này hiếm khi được ánh xạ rõ ràng thành bốn kho lưu trữ riêng biệt. Các thiết lập thực tế trông giống như sau:

• Cửa sổ ngữ cảnh (làm việc): mọi thứ trong lời nhắc đang hoạt động. Được quản lý bởi framework tác nhân. Hết hạn khi cuộc trò chuyện kết thúc.
• Kho vector bên ngoài (sự kiện + ngữ nghĩa): Chroma, Pinecone, hoặc Qdrant lưu trữ các embedding của các tương tác trong quá khứ và các đoạn kiến thức. Tác nhân truy vấn điều này ở mỗi lượt và chèn các đoạn có liên quan vào lời nhắc.
• Cơ sở dữ liệu có cấu trúc (ngữ nghĩa + thủ tục): PostgreSQL hoặc SQLite cho sở thích người dùng, trạng thái tài khoản hoặc các mẫu hành động đã học. Được truy vấn thông qua các lệnh gọi công cụ.
• Bộ nhớ đệm trong RAM (tràn bộ nhớ làm việc): Redis hoặc một dict đơn giản để truy cập nhanh vào ngữ cảnh gần đây không cần tìm kiếm embedding.

Hippo đặc biệt mô hình hóa hệ thống bộ nhớ ba tầng của mình với logic chuyển giao rõ ràng: các mục bộ nhớ làm việc không được truy cập gần đây sẽ được củng cố thành bộ nhớ sự kiện, cuối cùng được tóm tắt thành bộ nhớ ngữ nghĩa. Điều này phản ánh cách củng cố bộ nhớ con người hoạt động trong khi ngủ (dự án thậm chí còn có lệnh "ngủ" để kích hoạt quá trình củng cố).

Cách bộ nhớ tác nhân ảnh hưởng đến hành vi API

Nếu bạn đang xây dựng hoặc sử dụng API tác nhân, bộ nhớ trực tiếp định hình cách các lệnh gọi API của bạn trông như thế nào và những gì có thể gặp sự cố.

• ID phiên: hầu hết các API tác nhân sử dụng ID phiên hoặc ID luồng để tương quan bộ nhớ giữa các lệnh gọi. API Trợ lý của OpenAI sử dụng thread_id. ID luồng bị mất hoặc sử dụng lại sẽ khiến tác nhân mất ngữ cảnh hoặc trộn lẫn phiên của hai người dùng.
• Kích thước ngữ cảnh trong tải trọng yêu cầu: các tác nhân chèn bộ nhớ vào lời nhắc tạo ra các thân yêu cầu lớn hơn theo thời gian. Một cuộc hội thoại tác nhân bắt đầu từ 2KB có thể tăng lên 40KB sau 20 lượt. Nếu ứng dụng khách HTTP của bạn có giới hạn kích thước tải trọng, các yêu cầu sẽ thất bại một cách âm thầm.
• Độ trễ truy xuất: các tìm kiếm kho vector thêm 50-200ms mỗi lượt. Nếu bạn đang xác nhận thời gian phản hồi API, việc truy xuất bộ nhớ là một yếu tố đóng góp thực sự.
• Trạng thái không nhất quán sau khi thất bại: nếu lệnh gọi công cụ của tác nhân thất bại giữa chừng, nhật ký sự kiện có thể ghi lại một hành động không đầy đủ. Lượt tiếp theo bắt đầu từ một trạng thái bị hỏng. Các tác nhân tốt sẽ lưu checkpoint trạng thái trước và sau khi sử dụng công cụ.

Cách kiểm tra bộ nhớ tác nhân qua API với Apidog

Kiểm tra các API tác nhân có trạng thái yêu cầu nhiều hơn một xác nhận yêu cầu đơn lẻ. Bạn cần xác minh rằng ngữ cảnh được chuyển tiếp qua nhiều lệnh gọi, rằng các phản hồi được hỗ trợ bởi bộ nhớ thay đổi như mong đợi và rằng hệ thống giảm cấp một cách duyên dáng khi bộ nhớ không khả dụng.

Các Kịch bản thử nghiệm của Apidog xử lý chính xác điều này. Dưới đây là cách thiết lập một kịch bản cho API tác nhân.

Kiểm tra 1: chuyển tiếp ngữ cảnh

Tạo một kịch bản với ba bước tuần tự:

1. Gửi POST /agent/chat với một tin nhắn giới thiệu một sự thật ("Dự án của tôi sử dụng PostgreSQL 16")
2. Gửi POST /agent/chat với một tin nhắn tiếp theo yêu cầu nhớ lại sự thật đó ("Tôi nên tối ưu hóa cho cơ sở dữ liệu nào?")
3. Xác nhận trên phản hồi của bước 2: response.message.content nên chứa "PostgreSQL"

Nếu lớp bộ nhớ của tác nhân hoạt động, bước 2 sẽ truy xuất sự thật từ bộ nhớ sự kiện hoặc ngữ nghĩa và sử dụng nó trong phản hồi. Nếu không, bạn sẽ nhận được một câu trả lời chung chung.

Kiểm tra 2: cô lập phiên

Chạy cùng một chuỗi hai bước hai lần với các giá trị session_id khác nhau. Xác nhận rằng phản hồi của phiên thứ hai không chứa bất kỳ ngữ cảnh nào từ phiên thứ nhất. Điều này bắt lỗi bộ nhớ dùng chung: một trong những vấn đề phổ biến nhất và khó gỡ lỗi nhất trong các triển khai tác nhân đa người thuê.

Kiểm tra 3: suy thoái do lỗi bộ nhớ

Sử dụng Smart Mock của Apidog để mô phỏng lỗi phần backend bộ nhớ. Cấu hình mock trả về 503 tại điểm cuối tra cứu kho vector. Sau đó, chạy cuộc hội thoại tác nhân của bạn và xác nhận rằng:

• Tác nhân phản hồi mà không bị treo
• Phản hồi bao gồm một phương án dự phòng duyên dáng ("Tôi không có đủ ngữ cảnh để trả lời câu hỏi đó")
• Phiên có thể tiếp tục sau khi mock được loại bỏ.

Kiểm tra 4: tràn cửa sổ ngữ cảnh

Gửi hơn 30 tin nhắn nhanh liên tục để đẩy bộ nhớ làm việc vượt quá giới hạn ngữ cảnh. Xác nhận rằng:

• Tác nhân không báo lỗi context_length_exceeded (nó nên cắt bớt một cách duyên dáng)
• Phản hồi ở lượt thứ 30 vẫn trả lời đúng bằng cách sử dụng truy xuất sự kiện
• Số lượng token trong response.usage nằm trong phạm vi dự kiến.

Bạn có thể chạy cả bốn kiểm tra này như một Kịch bản thử nghiệm duy nhất trong Apidog, xâu chuỗi chúng tuần tự với các biến dùng chung cho ID phiên và dữ liệu phản hồi.

Xem [internal: how-to-build-tiny-llm-from-scratch] để biết thông tin cơ bản về lý do tại sao cửa sổ ngữ cảnh hoạt động theo cách chúng hoạt động ở cấp độ mô hình.

Các chế độ lỗi bộ nhớ phổ biến

• Cắt bớt ngữ cảnh ngầm: cửa sổ ngữ cảnh đầy và các tin nhắn cũ hơn biến mất mà không có cảnh báo. Tác nhân trả lời dựa trên lịch sử không đầy đủ. Bắt lỗi này bằng cách xác nhận trên response.usage.prompt_tokens và xác minh nó vẫn dưới giới hạn ngữ cảnh của mô hình của bạn.
• Rò rỉ phiên: phiên của hai người dùng chia sẻ một không gian tên bộ nhớ. Bắt lỗi này bằng các kiểm tra cô lập phiên.
• Bộ nhớ ngữ nghĩa cũ: kiến thức được lưu trữ từ nhiều tuần trước mâu thuẫn với các sự kiện hiện tại. Tác nhân tự tin đưa ra thông tin sai. Bắt lỗi này bằng cách thêm một xác nhận "ngày hiện tại" vào kiểm tra của bạn: nếu tác nhân trích dẫn giá hoặc số phiên bản, hãy xác nhận nó khớp với giá trị bạn đã tải trong ngữ cảnh kiểm tra.
• Trôi embedding: các kho vector được xây dựng với một mô hình embedding sẽ bị lỗi khi bạn chuyển sang một mô hình khác. Tất cả các tài liệu được truy xuất trở nên sai về mặt ngữ nghĩa. Không thể kiểm tra trực tiếp qua API, nhưng bạn có thể thêm một xác nhận kiểm tra xem ngữ cảnh được truy xuất có liên quan ngữ nghĩa đến truy vấn hay không.
• Tiêm lời nhắc qua tiêm bộ nhớ: đầu vào người dùng độc hại thao túng những gì được lưu trữ và truy xuất. Bao gồm các đầu vào đối nghịch trong bộ thử nghiệm của bạn: lưu trữ một "tùy chọn người dùng" chứa ghi đè lời nhắc hệ thống và xác minh tác nhân bỏ qua nó. Xem [internal: rest-api-best-practices] để biết hướng dẫn kiểm tra bảo mật API rộng hơn.

Kết luận

Bộ nhớ tác nhân là sự khác biệt giữa một trợ lý có vẻ thông minh và một trợ lý có vẻ hay quên. Bốn loại, bộ nhớ làm việc, sự kiện, ngữ nghĩa và thủ tục, mỗi loại phục vụ một vai trò riêng biệt. Hiểu cách chúng được lưu trữ và truy xuất trong các hệ thống thực tế cho bạn biết chính xác nơi lỗi có thể ẩn nấp và những gì cần xác nhận trong các kiểm tra API của bạn.

Các công cụ như Hippo cho thấy lĩnh vực này đang hướng tới kiến trúc bộ nhớ có nguyên tắc. Bất kể bạn đang xây dựng trên hệ thống bộ nhớ nào, các Kịch bản thử nghiệm của Apidog cung cấp cho bạn lớp thử nghiệm để xác minh nó hoạt động theo cách bạn mong đợi, đặc biệt là các trường hợp thất bại chỉ xuất hiện ở quy mô lớn.

Câu hỏi thường gặp

Cách đơn giản nhất để thêm bộ nhớ cho một tác nhân là gì?

Cách đơn giản nhất là một cửa sổ trượt trên lịch sử cuộc trò chuyện: giữ N lượt cuối cùng trong lời nhắc. Nó không phải là bộ nhớ sự kiện, nhưng nó hoạt động cho các tác vụ ngắn. Đối với các tác nhân chạy lâu hơn, hãy thêm một kho vector và truy xuất ngữ nghĩa.

API Trợ lý của OpenAI xử lý bộ nhớ như thế nào?

API Trợ lý quản lý một đối tượng luồng lưu trữ lịch sử cuộc trò chuyện ở phía máy chủ. Bạn cũng có thể đính kèm các công cụ tìm kiếm tệp và trình thông dịch mã để cấp cho tác nhân quyền truy cập vào kiến thức bên ngoài. Việc quản lý bộ nhớ được trừu tượng hóa, điều này tiện lợi nhưng làm cho việc gỡ lỗi khó khăn hơn.

Cơ sở dữ liệu vector tốt nhất cho bộ nhớ tác nhân là gì?

Để phát triển cục bộ: Chroma (không cần cơ sở hạ tầng). Để sản xuất: Qdrant hoặc Pinecone tùy thuộc vào việc bạn cần tự lưu trữ hay được quản lý. Thư viện Hippo hỗ trợ các backend lưu trữ có thể cắm thêm. Xem [internal: claude-code] để biết cách Claude Code sử dụng lớp bộ nhớ riêng của nó.

Làm thế nào để tôi ngăn chặn các tác nhân ảo giác về các tương tác trong quá khứ?

Lưu trữ nhật ký tương tác ở định dạng có cấu trúc với siêu dữ liệu (dấu thời gian, độ tin cậy, nguồn). Khi truy xuất ngữ cảnh trong quá khứ, hãy bao gồm siêu dữ liệu trong lời nhắc: "Theo cuộc trò chuyện của chúng ta vào [ngày], bạn đã đề cập X." Trích dẫn rõ ràng làm giảm ảo giác tự tin.

Tôi có thể kiểm tra bộ nhớ tác nhân mà không cần một tác nhân đang chạy không?

Có. Sử dụng Smart Mock của Apidog để mô phỏng các phản hồi API của tác nhân, bao gồm cả những phản hồi được hỗ trợ bởi bộ nhớ. Xác định các phản hồi giả lập thay đổi dựa trên ID phiên hoặc nội dung của thân yêu cầu. Điều này cho phép bạn kiểm tra cách xử lý hành vi bộ nhớ của giao diện người dùng hoặc lớp tích hợp của bạn mà không cần một tác nhân trực tiếp.

Chi phí lưu trữ vector trong sản xuất là bao nhiêu?

Tầng miễn phí của Pinecone hỗ trợ 1 chỉ mục với 100K vector. Ở quy mô lớn, Pinecone tính phí khoảng 0,096 USD/giờ cho một pod p1.x1 (1M vector 768 chiều). Qdrant tự lưu trữ là miễn phí. Đối với hầu hết các tác nhân, chi phí lớn hơn là tạo embedding, chứ không phải lưu trữ. Xem [internal: what-is-mcp-server] để biết cách tích hợp máy chủ MCP tương tác với hệ thống bộ nhớ tác nhân.

Sự khác biệt giữa RAG và bộ nhớ tác nhân là gì?

RAG (tạo sinh tăng cường truy xuất) truy xuất các tài liệu liên quan tại thời điểm truy vấn từ một cơ sở kiến thức cố định. Bộ nhớ tác nhân là động: nó phát triển và thay đổi khi tác nhân tương tác. Một hệ thống RAG trả lời "tài liệu nói gì về X?" Một hệ thống bộ nhớ tác nhân trả lời "tôi biết gì về người dùng này và tôi đã làm gì với họ?"