AI Agent là các hệ thống có khả năng theo đuổi và đạt được các mục tiêu bằng cách khai thác khả năng lý luận của các mô hình ngôn ngữ lớn (LLM) để lập kế hoạch, quan sát và thực hiện các hành động. Năm 2025, AI Agent được dự đoán sẽ thúc đẩy những thay đổi mang tính chuyển đổi trên toàn bộ lực lượng lao động, tác động đáng kể đến năng suất và hiệu quả, bao gồm hỗ trợ nhân viên trong công việc hàng ngày, triển khai con người số cho các chức năng kinh doanh quan trọng và thậm chí thay thế SaaS doanh nghiệp như chúng ta biết.
Một tác nhân AI là phần mềm thực sự làm việc cho bạn : nó lập kế hoạch tác vụ, sử dụng các công cụ (như tìm kiếm, email, Sheets, API), tự kiểm tra và báo cáo lại. Thuật ngữ này khá mơ hồ trên báo chí — vì vậy hãy định nghĩa tác nhân AI của bạn bằng hành động và kết quả , chứ không phải bằng những từ ngữ sáo rỗng.
Công thức:
Agent = Model + Memory + Tools + Loop + Guardrails + Metrics.
Vòng lặp gộp: Lập kế hoạch → Thực hiện → Báo cáo
Tác nhân của bạn nên chạy một vòng lặp đơn giản mỗi ngày:
- Lên kế hoạch những việc cần làm và lý do tại sao điều đó quan trọng
- Thực hiện bằng cách sử dụng các công cụ phù hợp
- Báo cáo kết quả, chi phí…
Điều này tương tự như PDCA — Lập kế hoạch, Thực hiện, Kiểm tra, Hành động — những chu trình nhỏ tích lũy theo thời gian. “Cũng như một vòng tròn không có điểm kết thúc, chu trình PDCA nên được lặp đi lặp lại để cải tiến liên tục.”
Và tiến bộ chính là nhiên liệu tên lửa: mọi người sẽ luôn gắn bó khi họ nhìn thấy sự tiến triển. — Harvard Business Review.
Chọn ngăn xếp của bạn (Mô hình, Khung, Khả năng quan sát). Mô hình lý luận (bất kỳ lựa chọn mạnh nào cũng được):
- OpenAI o3 / o3-mini — lý luận tiên tiến; hành vi “suy nghĩ lâu hơn” được nâng cấp.
- Claude 3.7 Sonnet — mô hình “lý luận lai” đầu tiên; suy nghĩ nhanh hoặc sâu sắc hơn.
- Gemini 2.0 — được xây dựng “cho thời đại đại lý”, với công cụ sử dụng gốc.
- Grok 3 (Suy nghĩ) — chế độ suy luận beta nhằm mục đích giải quyết vấn đề nhiều bước.
Khung tác nhân (chọn một để bắt đầu):
- LangGraph (LangChain) — công cụ phối hợp bền vững, có trạng thái dành cho các tác nhân thực tế.
- Microsoft Agent Framework / AutoGen — Bộ công cụ .NET/Python cho quy trình làm việc đa tác nhân.
- CrewAI — nền tảng đa tác nhân tích hợp pin.
Khả năng quan sát (xem tác nhân của bạn thực sự đã làm gì):
- LangSmith — theo dõi, đánh giá và giám sát.
- AgentOps — phát lại phiên và bảng thông tin độ tin cậy.
Nguyên tắc thiết kế giúp một tác nhân trở nên kiên trì
1. Trí nhớ gắn bó
Sử dụng bộ nhớ dài hạn để tác nhân của bạn “ghi nhớ” các sự kiện và sở thích. Cơ sở dữ liệu vector lưu trữ các ý tưởng dưới dạng số và cho phép bạn “tìm kiếm theo nghĩa”, thay vì từ ngữ chính xác – hoàn hảo để nhớ lại công việc trước đó.
2. Công cụ, không phải phép thuật
Kết nối tác nhân với các ứng dụng giúp đạt được mục tiêu: tìm kiếm trên web, email, lịch, CRM, tài liệu, bảng tính, trình chạy mã và API của riêng bạn.
3. Bảo mật theo mặc định
Bản đồ 10 rủi ro hàng đầu của OWASP đối với các ứng dụng LLM (tiêm mã nhắc, xử lý đầu ra không an toàn, tác nhân quá mức, v.v.). Thêm danh sách cho phép, kiểm tra đầu ra và quyền truy cập đặc quyền thấp nhất.
Sử dụng MITRE ATLAS để suy nghĩ như một kẻ tấn công và kiểm tra các biện pháp phòng thủ.
4. Quan sát mọi thứ
Theo dõi từng bước. Đo lường tỷ lệ thành công , chi phí , độ trễ và lỗi công cụ . Sử dụng LangSmith hoặc AgentOps ngay từ ngày đầu.
Xây dựng trong 90 phút (Bản thiết kế thực tế)
Bước 1 — Chọn một công việc có ROI rõ ràng.
Ví dụ: “Đánh giá 50 khách hàng tiềm năng và soạn thảo 5 email giới thiệu mỗi ngày”.
Bước 2 — Viết vòng lặp.
Lập kế hoạch → Thực hiện → Báo cáo , với số liệu thành công rõ ràng (ví dụ: “khách hàng tiềm năng đủ điều kiện/ngày” hoặc “cuộc họp được chấp nhận/tuần”).
Bước 3 — Mô hình dây + khung.
Chọn OpenAI o3 /Claude/Gemini/Grok trong LangGraph , Agent Framework/AutoGen hoặc CrewAI — bất kỳ thứ gì nhóm của bạn có thể duy trì.
Bước 4 — Thêm bộ nhớ.
Cắm một kho vector để tác nhân nhớ lại mọi người, quyết định và kết quả trước đó. Giải thích theo kiểu “Google để biết kiến thức của riêng bạn, nhưng bằng ý nghĩa”.
Bước 5 — Gắn dụng cụ.
Tìm kiếm, email, lịch, CRM, Trang tính/Tài liệu, trình chạy mã — bất cứ thứ gì thực sự tác động đến số liệu.
Bước 6 — Lan can tàu.
Biên tập bí mật, danh sách cho phép miền, sử dụng công cụ trong hộp cát và vệ sinh đầu ra theo OWASP LLM Top 10.
Bước 7 — Bật khả năng quan sát.
Truyền dữ liệu theo dõi đến LangSmith /AgentOps. Khắc phục lỗi trên cùng trước.
Bước 8 — Chạy hàng ngày: kế hoạch buổi sáng, báo cáo buổi tối.
Lặp lại hàng tuần.
Nếu bạn không xấu hổ về phiên bản đầu tiên của sản phẩm thì bạn đã ra mắt quá muộn rồi. — Reid Hoffman.
Tùy chọn tất cả trong một: OpenAI AgentKit hiện tích hợp trình xây dựng, đánh giá, lan can và theo dõi để tăng tốc quá trình sản xuất tác nhân.
Việc xây dựng các hệ thống agentic vẫn là một lĩnh vực đang phát triển và đi kèm với những thách thức mà các nhà nghiên cứu và chuyên gia trong ngành đang tích cực giải quyết. Một thách thức quan trọng là phát triển các mô hình chuyên về các tác vụ lý luận, trái ngược với các tác vụ tập trung vào ngôn ngữ như tóm tắt, vốn là đặc trưng của làn sóng ứng dụng GenAI đầu tiên. Một trở ngại quan trọng khác là quản lý bộ nhớ của AI Agent, thường đòi hỏi phải áp dụng các phương pháp phức tạp để đạt được mức hiệu suất agentic mong muốn.
Bộ nhớ là chìa khóa để làm cho AI Agent hoạt động. Hướng dẫn này bao gồm lý do tại sao nó lại quan trọng, các loại khác nhau, các phương pháp hay nhất để quản lý nó và lý do tại sao Redis nổi bật như một nền tảng dữ liệu lý tưởng cho bộ nhớ agentic. Chúng ta cũng sẽ đề cập đến việc triển khai thực tế để giúp bạn tích hợp bộ nhớ agentic một cách hiệu quả.
Tại sao bộ nhớ lại quan trọng?
Bộ nhớ AI Agent rất quan trọng để nâng cao hiệu quả và khả năng vì các Mô hình Ngôn ngữ Lớn (LLM) không có khả năng ghi nhớ mọi thứ một cách vốn có, tức là chúng là stateless. Bộ nhớ cho phép AI Agent học hỏi từ các tương tác trước đây, lưu giữ thông tin và duy trì ngữ cảnh, dẫn đến các phản hồi mạch lạc và được cá nhân hóa hơn.
Hãy tưởng tượng một AI Agent được thiết kế để lên kế hoạch và đặt các chuyến công tác. Nếu không có bộ nhớ, nó sẽ không nhớ các tùy chọn cá nhân (ví dụ: “Bạn thích các chuyến bay thẳng hay các chuyến bay có quá cảnh?”); mắc các lỗi quy trình do thiếu hiểu biết (ví dụ: đặt một khách sạn không cung cấp các tiện nghi cần thiết cho các chuyến công tác, như phòng họp hoặc Wi-Fi đáng tin cậy); và không thể nhớ lại các chi tiết đã cung cấp trước đó như thông tin hộ chiếu. Điều này dẫn đến trải nghiệm người dùng bực bội với các câu hỏi lặp đi lặp lại, hành vi không nhất quán và thiếu tính cá nhân hóa.
Bộ nhớ ngắn hạn so với dài hạn
AI Agent, giống như con người, dựa vào cả bộ nhớ ngắn hạn và dài hạn để hoạt động hiệu quả.
Bộ nhớ ngắn hạn hoạt động giống như RAM của máy tính, lưu giữ các chi tiết liên quan cho một tác vụ hoặc cuộc trò chuyện đang diễn ra. Bộ nhớ làm việc này chỉ tồn tại trong thời gian ngắn trong một chuỗi hội thoại và thường bị giới hạn do các cửa sổ ngữ cảnh hạn chế của các mô hình ngôn ngữ lớn (LLM) hoặc nhu cầu giảm thiểu thông tin ít liên quan hơn. Đó là nơi các framework agentic như LangGraph xuất hiện. Các framework agentic như LangGraph đơn giản hóa việc quản lý bộ nhớ ngắn hạn bằng cách cung cấp các công cụ như Checkpointer, giúp duy trì ngữ cảnh cụ thể theo luồng. Điều này cho phép các agent lưu trữ bộ nhớ ngắn hạn một cách hiệu quả trong các cơ sở dữ liệu hiệu suất cao như Redis.
Bộ nhớ dài hạn hoạt động giống như ổ cứng hơn, lưu trữ một lượng lớn thông tin để truy cập sau này. Đây là thông tin tồn tại qua nhiều lần chạy tác vụ hoặc cuộc trò chuyện, cho phép các agent học hỏi từ phản hồi và thích ứng với sở thích của người dùng. Những ký ức này có thể được chia thành ba loại (để biết thêm thông tin về các sắc thái của các loại bộ nhớ khác nhau, chúng tôi khuyên bạn nên xem lại bài báo framework CoALA nổi tiếng):
- Bộ nhớ Episodic: Lưu trữ các sự kiện và trải nghiệm cụ thể trong quá khứ, giống như một cuốn nhật ký cá nhân về các tương tác của AI. Ví dụ: AI có thể nhớ rằng người dùng trước đây đã đặt một chuyến đi đến London cho một hội nghị và thích ở lại trung tâm thành phố.
- Bộ nhớ Procedural: Lưu trữ các kỹ năng, quy trình và kiến thức “cách thực hiện” đã học được, tạo thành kho hành động của AI. Ví dụ: AI có thể học quy trình tối ưu để đặt chuyến bay, chẳng hạn như đảm bảo thời gian quá cảnh phù hợp giữa các chuyến bay nối chuyến.
- Bộ nhớ Semantic: Lưu trữ kiến thức chung, sự kiện, khái niệm và mối quan hệ, tạo thành cơ sở kiến thức của AI về thế giới. Ví dụ: AI có thể lưu trữ thông tin về yêu cầu thị thực, các điểm du lịch nổi tiếng hoặc chi phí khách sạn trung bình.
Việc quản lý bộ nhớ dài hạn rất phức tạp do những thách thức như quyết định loại ký ức nào cần lưu trữ, tìm ra những gì cần lưu trữ, cách làm suy giảm các ký ức cũ hơn và cách truy xuất chúng một cách hiệu quả vào bộ nhớ làm việc.
Các quyết định kiến trúc chính để quản lý bộ nhớ dài hạn
Có bốn quyết định cấp cao nhất bạn cần đưa ra khi lập kế hoạch kiến trúc quản lý bộ nhớ của mình:
- Loại ký ức nào cần lưu trữ?Loại ký ức bạn cần lưu trữ và quản lý có thể phụ thuộc vào loại ứng dụng. Ví dụ: một AI Agent đàm thoại sẽ được kỳ vọng ghi nhớ thông tin trên các luồng về sở thích của người dùng (và do đó lưu trữ bộ nhớ episodic). Mặt khác, một trợ lý AI bán lẻ có thể được yêu cầu lưu trữ thông tin về sản phẩm và thu hồi các sự kiện liên quan từ cơ sở dữ liệu kiến thức sản phẩm (và do đó lưu trữ bộ nhớ semantic).
- Cách lưu trữ và cập nhật ký ức?Với những hạn chế trong cửa sổ ngữ cảnh LLM và nguy cơ ô nhiễm ngữ cảnh, điều quan trọng là phải lưu trữ ký ức một cách hiệu quả. Có bốn chiến lược phổ biến mà chúng tôi thấy các nhà phát triển sử dụng để lưu trữ ký ức liên quan một cách hiệu quả. Đối với hầu hết các triển khai sản xuất, chúng tôi hy vọng AI Agent sẽ sử dụng kết hợp các kỹ thuật này (lưu ý rằng các kỹ thuật này không loại trừ lẫn nhau và nhiều nhà phát triển có thể muốn sử dụng kết hợp các kỹ thuật này).
- Tóm tắt: Cách tiếp cận đơn giản nhất là chỉ cần tóm tắt các cuộc trò chuyện trước đó (thường sử dụng LLM). Mô-đun bộ nhớ tăng dần tóm tắt các cuộc trò chuyện, cập nhật và tinh chỉnh bản tóm tắt khi có thêm dữ liệu hoặc trải nghiệm mới. Các cuộc trò chuyện được tóm tắt sau đó có thể được lưu trữ dưới dạng chuỗi trong Redis và được truy xuất để tạo ngữ cảnh cho các truy vấn trong tương lai đến LLM. Một ví dụ về việc triển khai này đã được nhóm Motorhead triển khai trong dự án mã nguồn mở của họ.
- Vector hóa: Vector hóa nằm ở trung tâm của việc quản lý bộ nhớ AI hiện đại. Nó biến đổi thông tin văn bản thành các biểu diễn số, gói gọn ý nghĩa cơ bản của các từ và khái niệm. Bằng cách phân đoạn ký ức thành các khối rời rạc, chúng tôi khuyên bạn nên sử dụng phân đoạn ngữ nghĩa và vector hóa chúng, các nhà phát triển có thể tận dụng tìm kiếm vector để truy xuất các ký ức liên quan nhất một cách chính xác và hiệu quả.
- Trích xuất: Một giải pháp thay thế mới nổi cho việc tóm tắt hoặc phân đoạn đơn giản ký ức là trích xuất các sự kiện chính từ lịch sử cuộc trò chuyện và lưu trữ chúng trong một cơ sở dữ liệu bên ngoài với ngữ cảnh về các sự kiện. Một kho tài liệu như RedisJSON cung cấp một giải pháp hoàn hảo để lưu trữ những điều này. Nhóm Langchain gần đây đã chia sẻ một ví dụ về một agent bộ nhớ trích xuất và ghi ký ức.
- Đồ thị hóa: Một cách tiếp cận khác đôi khi được sử dụng là lưu trữ ký ức AI Agent bằng cách ánh xạ thông tin dưới dạng các thực thể và mối quan hệ được kết nối với nhau. Định dạng có cấu trúc này cho phép lưu trữ bộ nhớ động, giàu ngữ cảnh.
- Cách truy xuất ký ức liên quan?Hãy tưởng tượng bạn có các khối bộ nhớ được lưu trữ trong một cơ sở dữ liệu như Redis, cùng với các embedding và mô tả văn bản của chúng. Làm thế nào để Agent biết cách truy xuất những ký ức liên quan nhất? Đây là một lĩnh vực nghiên cứu mới nổi với một số cách tiếp cận phức tạp đang được các nhà nghiên cứu thử nghiệm. Ví dụ: bài báo MemGPT áp dụng cách tiếp cận sử dụng LLM làm trình tạo truy vấn, nơi nó có thể đưa ra quyết định về thời điểm truy xuất bộ nhớ dài hạn, tạo truy vấn để thực hiện tìm kiếm (bằng cách tạo mã thông báo gọi hàm) và sau đó sử dụng tìm kiếm vector để truy xuất các khối liên quan. Đối với hầu hết các ứng dụng, chúng tôi khuyên các nhà phát triển nên bắt đầu với tìm kiếm vector của cơ sở dữ liệu bộ nhớ và thêm các tinh chỉnh bổ sung từ đó khi cần.
- Cách làm suy giảm ký ức?Điều quan trọng là phải làm suy giảm các ký ức được lưu trữ trong các hệ thống AI để ngăn chặn tình trạng phình to bộ nhớ và duy trì hiệu quả. Khi một AI Agent tương tác theo thời gian, nó tích lũy một lượng lớn thông tin, một số thông tin trở nên không liên quan hoặc lỗi thời. Nếu không có cơ chế để quên, bộ nhớ của AI sẽ bị quá tải với dữ liệu vô dụng, dẫn đến thời gian truy xuất chậm hơn, giảm độ chính xác trong phản hồi và sử dụng tài nguyên không hiệu quả. Nếu lưu trữ ký ức bằng Redis, bạn có thể sử dụng các chiến lược loại bỏ và hết hạn tích hợp khác nhau để quản lý hiệu quả sự suy giảm bộ nhớ. Bạn cũng có thể thêm dấu thời gian làm một trường khác trong đối tượng và ảnh hưởng đến kết quả tìm kiếm cuối cùng với một số khái niệm về sắp xếp độ mới.
Điều gì khiến Redis trở thành lựa chọn phù hợp để xử lý bộ nhớ dài hạn?
Có một số lý do tại sao các nhà phát triển thích Redis làm nền tảng của họ để lưu trữ và quản lý ký ức AI Agent. Chúng bao gồm:
- Hiệu suất nhanh: Đọc và ghi ký ức nằm trên “đường dẫn nóng” của luồng ứng dụng của bạn. Thời gian truy xuất chậm có thể ảnh hưởng đáng kể đến trải nghiệm người dùng hoặc buộc các nhà phát triển phải đánh đổi hiệu suất tối ưu. Kiến trúc trong bộ nhớ của Redis đảm bảo các hoạt động đọc và ghi ở mức micro giây, điều này rất quan trọng đối với trường hợp sử dụng này.
- Tìm kiếm vector nhanh nhất và đầy đủ tính năng: Redis cung cấp cơ sở dữ liệu vector gốc đầy đủ tính năng, cung cấp giải pháp tìm kiếm vector được đánh giá nhanh nhất trên thị trường. Với nhu cầu vector hóa và thực hiện tìm kiếm ngữ nghĩa trên ký ức, đây là một yêu cầu quan trọng khi chọn nền tảng dữ liệu của bạn.
- Tích hợp với ngăn xếp AI của bạn: Redis được tích hợp đầy đủ với các framework AI phổ biến bao gồm LangGraph, LlamaIndex và Autogen. Ngoài ra, các nhà phát triển có thể sử dụng RedisVL, một thư viện ứng dụng khách Python chuyên dụng, mạnh mẽ để sử dụng Redis cho các ứng dụng GenAI. RedisVL đi kèm với các trừu tượng tích hợp, bao gồm cả những trừu tượng để quản lý bộ nhớ đàm thoại.
- Khả năng mở rộng: Khi xây dựng các hệ thống agentic, việc dự đoán các yêu cầu lưu trữ cho ký ức AI Agent, số lượng ứng dụng khách cần truy cập và tần suất truy xuất dữ liệu có thể là một thách thức. Redis cung cấp một bộ tính năng tạo điều kiện triển khai quy mô lớn, bao gồm khả năng mở rộng trên nhiều nút, tự động phân tầng dữ liệu ít được truy cập hơn vào đĩa (sử dụng Redis Flex) và hỗ trợ tính khả dụng cao và tính bền bỉ của dữ liệu. Ngoài ra, các chính sách loại bỏ và hết hạn tích hợp của Redis giúp đơn giản hóa sự suy giảm bộ nhớ, đảm bảo xử lý dữ liệu hiệu quả theo thời gian.
- Tính linh hoạt: Redis cung cấp một số tùy chọn cấu trúc dữ liệu ngay lập tức. Các cấu trúc dữ liệu này, như hash (để có hiệu quả hợp lý) hoặc JSON (cho các tài liệu lồng nhau), cho phép các nhà phát triển linh hoạt quản lý bộ nhớ theo cách họ thích.
Chúng tôi giúp việc quản lý bộ nhớ trở nên đơn giản hơn với Máy chủ Bộ nhớ Agent Redis mã nguồn mở của chúng tôi.
Ví dụ về bộ nhớ agent sử dụng LangGraph & Redis
Notebook này trình bày cách quản lý bộ nhớ agent ngắn hạn và dài hạn bằng LangGraph và Redis. Trong đó, chúng ta khám phá:
- Quản lý bộ nhớ ngắn hạn bằng checkpointer của LangGraph
- Lưu trữ và truy xuất bộ nhớ dài hạn bằng RedisVL
- Quản lý bộ nhớ dài hạn theo cách thủ công so với việc hiển thị quyền truy cập công cụ (AKA gọi hàm)
- Quản lý kích thước lịch sử cuộc trò chuyện bằng cách tóm tắt
- Hợp nhất bộ nhớ
Trong notebook, chúng ta xây dựng hai phiên bản của một agent du lịch, một phiên bản quản lý bộ nhớ dài hạn theo cách thủ công và một phiên bản thực hiện bằng cách sử dụng các công cụ mà LLM gọi.
Dưới đây là hai sơ đồ hiển thị các thành phần được sử dụng trong cả hai agent:
Vậy là xong. Hãy bắt đầu xây dựng
Bạn muốn tạo agent của riêng mình? Hãy thử Quickstart LangGraph. Sau đó, thêm checkpointer Redis của chúng tôi để cung cấp cho agent của bạn bộ nhớ nhanh chóng, liên tục. Máy chủ Bộ nhớ Agent Redis là công cụ mã nguồn mở của chúng tôi để quản lý bộ nhớ cho agent và ứng dụng AI.
Sử dụng Redis để quản lý bộ nhớ cho AI Agent của bạn cho phép bạn xây dựng một hệ thống linh hoạt và có khả năng mở rộng, có thể lưu trữ và truy xuất ký ức nhanh chóng. Hãy xem các tài nguyên bên dưới để bắt đầu xây dựng với Redis ngay hôm nay hoặc kết nối với nhóm của chúng tôi để trò chuyện về AI Agent.
Tham khảo: medium.com
Sổ tay hướng dẫn của tác nhân (Sao chép các vòng lặp này)
Công cụ nội dung
Nghiên cứu → phác thảo → bản nháp → kiểm tra thực tế → xuất bản → báo cáo phân tích hàng tuần.
Đại diện phát triển bán hàng (SDR)
Tìm kiếm khách hàng tiềm năng → làm giàu → viết lời giới thiệu → lên lịch theo dõi → báo cáo về quy trình.
Bàn làm việc của người sáng lập
Tóm tắt hộp thư đến → lập kế hoạch trong ngày → soạn thảo trả lời → lên lịch → tóm tắt cuối ngày.
Trinh sát nghiên cứu
Theo dõi đối thủ cạnh tranh → trích xuất thông tin chi tiết → tổng hợp tóm tắt → danh sách nguồn → ghi nhớ xu hướng hàng tháng.
Coding Copilot (cấp độ nhóm)
Ticket → plan → implement → test → PR → post-merge report. Để tìm cảm hứng, hãy xem Devin , một tác nhân mã hóa AI được xây dựng cho quá trình phát triển đầu cuối.
Bảng thông tin số liệu (Theo dõi hàng tuần)
Tỷ lệ thành công của nhiệm vụ (trên mỗi công việc)
Chi phí cho mỗi nhiệm vụ thành công
Thời gian tiết kiệm được (tác nhân so với con người)
Tỷ lệ lỗi công cụ
Điểm chất lượng (đánh giá nhanh của con người)
Sử dụng dấu vết của bạn để so sánh lời nhắc, phiên bản và mô hình.
Micro-Prompts sẵn sàng sử dụng (Sao chép/Dán)
Người lập kế hoạch
“Lên kế hoạch cho 3 hành động quan trọng nhất để đạt được [mục tiêu] hôm nay. Với mỗi hành động, hãy giải thích lý do tại sao nó quan trọng, công cụ nào nên sử dụng và thời gian biểu 30 phút.”
Người thi hành di chúc
“Sử dụng [công cụ] , hoàn thành [nhiệm vụ] . Trích dẫn nguồn, lưu hiện vật/liên kết và ghi chú chặn.”
Phóng viên
“Tóm tắt kết quả trong 7 dòng: những gì hiệu quả, những gì không hiệu quả, chi phí/thời gian và các bước tiếp theo vào thứ Hai.”
Những câu hỏi thường gặp
Có người đại diện nào thay thế tôi không?
Không. Nó xử lý công việc lặp đi lặp lại; bạn mang đến hương vị, khả năng phán đoán và chiến lược.
Phải tốn bao nhiêu tiền để bắt đầu?
Bắt đầu với số tiền nhỏ (thậm chí chỉ vài đô la/ngày) — chỉ mở rộng quy mô khi tỷ lệ thành công và chất lượng tăng lên.
Còn nếu nó “bịa ra mọi chuyện” thì sao?
Dựa trên dữ liệu của bạn (truy xuất) và thực hiện kiểm tra đầu ra trước khi hành động.
Khung nào là tốt nhất hiện nay?
Bạn muốn độ bền và khả năng kiểm soát? LangGraph .
.NET/Python enterprise? Microsoft Agent Framework (hoặc các mẫu AutoGen).
Khởi động nhiều tác nhân? CrewAI .
Làm cho vòng lặp trở nên thực tế
Tóm lại: Một đại lý không ngừng nghỉ không phải là một cuộc trò chuyện hoa mỹ — đó là một hệ thống nhỏ lập kế hoạch, thực thi và báo cáo mỗi ngày. Hãy xây dựng một vòng lặp giúp tuần tới tốt hơn một cách không thể phủ nhận , sau đó để việc cộng gộp làm phần còn lại.
Danh sách kiểm tra bắt đầu nhanh
Chọn một công việc có ROI (ví dụ: “đặt 3 cuộc họp đủ điều kiện/ngày”).
Viết vòng lặp: Lập kế hoạch → Thực hiện → Báo cáo (xác định thành công theo một số liệu).
Kết nối một mô hình + một công cụ (đơn giản thôi).
Bật tính năng theo dõi (để bạn có thể thấy được thành công và thất bại).
Thêm một rào chắn (tên miền được phép, xóa bí mật).
Đặt nhịp độ: Kế hoạch thứ Hai, chạy bộ hàng ngày, chạy ngược lại vào thứ Sáu.
Hãy đối xử với nhân viên như một đồng đội có mô tả công việc rõ ràng. Khi công việc được phân công rõ ràng , nhân viên sẽ làm việc tốt hơn — vì bạn sẽ đo lường được những gì quan trọng và cắt giảm những thứ còn lại.
Vòng lặp nào bạn sẽ triển khai trong tuần này — và thước đo nào sẽ chứng minh rằng nó hiệu quả?
Mô hình “LLM Wiki” của Karpathy
Andrej Karpathy chia sẻ cách build agentic knowledge base
Cơ sở tri thức bằng LLM (LLM Knowledge Bases)
Gần đây tôi thấy thích ý tưởng dùng LLM để xây dựng cơ sở tri thức cá nhân cho các chủ đề nghiên cứu. Nhờ vậy, phần lớn lượng token tôi dùng không phải để viết code nữa, mà để “xử lý tri thức” (lưu dưới dạng markdown và hình ảnh). Các LLM mới làm việc này khá tốt.
Nạp dữ liệu (Data ingest):
//github.com/mduongvandinh/llm-wiki
Tôi gom tài liệu gốc (bài báo, paper, repo, dataset, hình ảnh…) vào thư mục raw/. Sau đó dùng LLM để dần dần “biên dịch” thành một wiki (tập hợp các file .md theo cấu trúc thư mục). Wiki này có tóm tắt, liên kết ngược, phân loại theo khái niệm, viết bài cho từng khái niệm và liên kết chúng lại. Để chuyển bài web thành .md, tôi dùng tiện ích Obsidian Web Clipper, đồng thời tải hình ảnh liên quan về máy để LLM dễ tham chiếu.
IDE:
Tôi dùng Obsidian làm giao diện để xem dữ liệu gốc, wiki đã biên dịch và các hình ảnh trực quan. LLM viết và duy trì wiki, tôi hiếm khi chỉnh sửa trực tiếp. Tôi cũng thử vài plugin như Marp để hiển thị dữ liệu thành slide.
Hỏi đáp (Q&A):
Khi wiki đủ lớn (ví dụ: ~100 bài, ~400k từ), bạn có thể hỏi LLM đủ loại câu hỏi phức tạp. Tôi tưởng phải dùng RAG, nhưng thực tế LLM tự duy trì file chỉ mục và tóm tắt, đọc dữ liệu liên quan khá dễ ở quy mô nhỏ này.
Đầu ra (Output):
Thay vì chỉ nhận câu trả lời dạng text, tôi thích để LLM xuất file markdown, slide (Marp), hoặc hình matplotlib, rồi xem lại trong Obsidian. Thường tôi lưu các đầu ra này vào wiki để làm giàu thêm cho lần hỏi sau.
Kiểm tra (Linting):
Tôi chạy vài “health check” bằng LLM để tìm dữ liệu không nhất quán, bổ sung dữ liệu thiếu (qua web search), gợi ý kết nối mới cho bài viết… giúp wiki sạch và hữu ích hơn.
Công cụ thêm (Extra tools):
Tôi còn viết một search engine nhỏ cho wiki, dùng trực tiếp hoặc cho LLM gọi qua CLI khi cần truy vấn lớn.
Khám phá thêm (Further explorations):
Khi repo lớn dần, ý tưởng tự nhiên là tạo dữ liệu tổng hợp + fine-tuning để LLM “biết” dữ liệu trong trọng số, thay vì chỉ đọc qua context.
Tóm tắt:
Thu thập dữ liệu gốc → LLM biên dịch thành wiki .md → dùng CLI để hỏi đáp và cải thiện wiki → xem tất cả trong Obsidian. Người dùng hiếm khi viết wiki thủ công, LLM lo hết.
Xây dựng bộ nhớ cho các tác nhân AI: Cửa sổ ngữ cảnh, tìm kiếm vectơ, PostgreSQL và bộ nhớ dài hạn
Mô hình không hề trở nên kém hiệu quả hơn. Tin nhắn đầu tiên của tôi đơn giản là đã bị đưa ra khỏi ngữ cảnh hoạt động. Cuộc trò chuyện vẫn hiển thị liên tục trên màn hình, nhưng mô hình không còn nhận được mọi tin nhắn trước đó nữa.
Ví dụ nhỏ này cho thấy một vấn đề thiết kế lớn. Một tác nhân AI hữu ích cần nhiều hơn một mô hình ngôn ngữ và một lời nhắc. Nó cần một hệ thống bộ nhớ quyết định giữ lại gì, lưu trữ ở đâu và nhớ lại gì cho mỗi yêu cầu.
Một hệ thống trí nhớ tốt không sao chép mọi cuộc hội thoại vào mọi lời nhắc. Nó giữ lại ngữ cảnh gần đây, trích xuất các sự kiện có giá trị lâu dài, ghi lại các sự kiện trong quá khứ và chỉ truy xuất những mục phù hợp với nhiệm vụ hiện tại.
Thiết kế đó biến một chatbot không lưu trữ trạng thái thành một hệ thống có thể hỗ trợ các dự án dài hạn…
Mô hình và hệ thống bộ nhớ là hai phần khác nhau.
Mô hình ngôn ngữ đọc dữ liệu đầu vào được cung cấp cho một lệnh gọi. Dữ liệu đầu vào đó có thể chứa các lệnh hệ thống, tin nhắn gần đây, tài liệu đã truy xuất, kết quả công cụ và bộ nhớ đã lưu. Mô hình tạo ra phản hồi từ gói dữ liệu đó.
Mô hình không tự động sở hữu một sổ tay cá nhân vĩnh viễn. Mã ứng dụng phải xây dựng sổ tay đó xung quanh mô hình.
Sự phân chia này rất quan trọng:
•Mô hìnhsuy luận dựa trên ngữ cảnh được gửi cho cuộc gọi hiện tại.
• Trạngthái luồngtheo dõi cuộc hội thoại đang hoạt động.
•Bộ nhớ dài hạnlưu giữ thông tin đã chọn giữa các phiên.
•Lớp truy xuấtchọn các bản ghi hữu ích cho yêu cầu mới.
•Trình ghi bộ nhớtạo, cập nhật hoặc từ chối các bản ghi bộ nhớ.
Các framework agent hiện đại thường gọi cuộc hội thoại đang diễn ra là bộ nhớ ngắn hạn hoặc bộ nhớ phạm vi luồng. Chúng gọi dữ liệu giữa các phiên là bộ nhớ dài hạn. Các hệ thống nghiên cứu như MemGPT coi cửa sổ ngữ cảnh như không gian làm việc hạn chế và di chuyển dữ liệu giữa các bộ nhớ nhanh và bộ nhớ bền vững.
Bộ nhớ ngắn hạn là luồng hoạt động chính
Bộ nhớ ngắn hạn lưu giữ các chi tiết cần thiết cho cuộc hội thoại hoặc nhiệm vụ hiện tại. Nó thường bao gồm các tin nhắn gần đây, kết quả đầu ra hiện tại của công cụ, các tệp đã tải lên, trạng thái nhiệm vụ và các quyết định tạm thời.
Hãy hình dung một cuộc trò chuyện dài như một hàng tin nhắn:
M1 → M2 → M3 → M4 → M5 → M6 → M7 → M8
Mô hình chỉ có thể đọc một phần giới hạn của hàng đó. Một ứng dụng có thể gửi một vài tin nhắn gần đây nhất, tóm tắt các tin nhắn cũ hơn hoặc một tập hợp tin nhắn được chọn. Phần hiển thị sẽ di chuyển khi luồng tin nhắn phát triển.
Phần di động này thường được gọi là cửa sổ trượt.
Trí nhớ ngắn hạn hữu ích cho những câu hỏi như:
• Người dùng đã hỏi gì trong hai tin nhắn trước?
• Người dùng đã tải lên tệp nào trong cuộc trò chuyện này?
• Lệnh gọi công cụ nào đang chờ phê duyệt?
• Những giá trị nào đã được thu thập cho biểu mẫu này?
Đây không phải là nơi thích hợp để lưu trữ những thông tin cần được giữ nguyên sau một cuộc trò chuyện mới. Ngôn ngữ ưa thích của người dùng, vai trò trong dự án, địa chỉ đã lưu hoặc ràng buộc định kỳ không nên phụ thuộc vào việc một cuộc trò chuyện duy nhất vẫn đang mở.
Các cửa sổ ngữ cảnh lớn giúp giảm áp lực, nhưng chúng không giải quyết được vấn đề thiết kế. Các lời nhắc dài tốn kém hơn, mất nhiều thời gian xử lý hơn và chứa nhiều thông tin lỗi thời hơn. Một ngữ cảnh tập trung thường hữu ích hơn một bản ghi khổng lồ.
Trí nhớ dài hạn lưu giữ những kiến thức được chọn lọc giữa các phiên học.
Bộ nhớ dài hạn lưu trữ thông tin vẫn hữu ích sau khi cuộc trò chuyện hiện tại kết thúc. Ứng dụng có thể tải thông tin đó trong cuộc trò chuyện sau với cùng người dùng, nhóm, khách hàng hoặc dự án.
Giả sử người dùng nói:
• “Tên tôi là Yogesh.”
• “Tôi thích chế độ sáng.”
• “Tôi đã triển khai dịch vụ thanh toán vào ngày 14 tháng 2.”
• “Hãy sử dụng TypeScript cho dự án này.”
Người ghi chép kỷ niệm không nên lưu bốn dòng này trong một khối văn bản duy nhất. Mỗi dòng có một vai trò khác nhau.
Việc lựa chọn tên và chủ đề là sự thật hoặc sở thích. Việc triển khai là một sự kiện đã xảy ra. Quy tắc TypeScript có thể là một ràng buộc của dự án. Mỗi bản ghi cần có kiểu, phạm vi, nguồn, thời gian và quy tắc cập nhật riêng.
Bộ nhớ dài hạn tạo ra tính liên tục, nhưng nó cũng làm tăng thêm khối lượng công việc kỹ thuật. Hệ thống phải xử lý các dữ liệu lỗi thời, các chỉnh sửa, dữ liệu trùng lặp, việc trích xuất dữ liệu chất lượng thấp, các yêu cầu về quyền riêng tư và sự cô lập giữa các người dùng.
Bộ nhớ không chỉ đơn thuần là nơi lưu trữ. Nó là cả một vòng đời hoàn chỉnh.
Bản đồ thuật ngữ rõ ràng
Bản ghi nguồn sử dụng trí nhớ thực tế, trí nhớ sự kiện và trí nhớ ngữ nghĩa. Đó là một điểm khởi đầu hữu ích, nhưng một thuật ngữ cần được tinh chỉnh.
Cơ sở dữ liệu vector không phải là bộ nhớ ngữ nghĩa. Nó là một cách để tìm kiếm các bản ghi đã lưu trữ theo ý nghĩa. Bộ nhớ ngữ nghĩa mô tả nội dung. Tìm kiếm vector mô tả phương pháp truy xuất.
Sơ đồ sau đây rất hữu ích cho việc thiết kế ứng dụng.
Thông tin chi tiết về người dùng thường thuộc về bộ nhớ ngữ nghĩa. Một thông tin có thể sử dụng khóa chính xác, chẳng hạn như user.preferred_theme, và vẫn mang theo một phần nhúng để tìm kiếm rộng hơn.
Trí nhớ theo từng sự kiện cần ghi nhớ thời gian và trình tự. Nó trả lời các câu hỏi như “Chuyện gì đã xảy ra ngày hôm qua?” hoặc “Chúng ta đã quyết định gì trong lần triển khai gần đây nhất?”
Trí nhớ thủ tục ghi lại cách thức thực hiện công việc. Bản ghi chép này không đề cập sâu về loại trí nhớ này, nhưng các sơ đồ trí nhớ của các tác nhân hiện nay thường bao gồm nó.
Bộ nhớ đồ thị là một lớp biểu diễn. Nó liên kết các bản ghi có chung mối quan hệ ý nghĩa. Nó không thay thế bộ nhớ ngữ nghĩa hay bộ nhớ sự kiện. Nó kết nối chúng lại với nhau.
Bộ xử lý bộ nhớ có đường dẫn đọc và đường dẫn ghi.
Một công cụ quản lý bộ nhớ thực tế vận hành hai luồng dữ liệu được kết nối với nhau.
Đường dẫn đọc
Đường dẫn đọc chuẩn bị ngữ cảnh cho lần gọi mô hình tiếp theo.
1.Nhận yêu cầu từ người dùng.
2.Xác định người dùng, nhóm, dự án và phạm vi luồng.
3.Tải trạng thái luồng gần đây.
4.Thực hiện tra cứu chính xác các khóa đã biết.
5.Thực hiện tìm kiếm ngữ nghĩa cho các bộ nhớ liên quan.
6.Truy xuất các bản ghi đồ thị liên kết khi cần thiết.
7.Xếp hạng các bản ghi theo mức độ liên quan, thời gian, độ tin cậy và phạm vi.
8.Xây dựng gói ngữ cảnh nhỏ gọn.
9.Gọi mô hình ngôn ngữ.
10.Trả về phản hồi kèm theo các tham chiếu bộ nhớ để gỡ lỗi.
Yêu cầu “Tên tôi là gì?” trước tiên nên kích hoạt tìm kiếm chính xác. Tìm kiếm theo vectơ có thể hỗ trợ tìm kiếm dự phòng, nhưng thông tin chính xác không nên chỉ dựa vào sự tương đồng.
Yêu cầu “Tuần trước tôi đã làm việc gì?” cần tìm kiếm theo từng giai đoạn với phạm vi ngày tháng. Hệ thống có thể kết hợp sự tương đồng về ngữ nghĩa với các bộ lọc thời gian.
Câu hỏi “Tại sao chiếc điều khiển từ xa này lại gợi nhớ đến căn hộ cũ của tôi?” có thể cần các liên kết đồ thị giữa một đối tượng, một địa điểm và một sự kiện đã được ghi lại.
Đường dẫn ghi
Quá trình ghi chuyển đổi dữ liệu tương tác mới thành các bản ghi bền vững.
1.Lưu lại tin nhắn gốc của người dùng và phản hồi của mô hình.
2.Quyết định xem tin nhắn có chứa nội dung đáng ghi nhớ hay không.
3.Trích xuất các sự kiện, sở thích hoặc quy trình tiềm năng.
4.Đính kèm nguồn, thời gian, phạm vi và độ tin cậy.
5.Tìm kiếm các bản ghi phù hợp.
6.Tạo, cập nhật, thay thế hoặc từ chối từng ứng viên.
7.Tạo mã nhúng cho các bản ghi cần tìm kiếm ngữ nghĩa.
8.Lưu lại mục nhật ký kiểm toán.
Tác vụ ghi có thể chạy trực tiếp trong quá trình xử lý yêu cầu hoặc thông qua một tác vụ được xếp hàng chờ. Ghi trực tiếp giúp cấp phát bộ nhớ mới cho thông điệp tiếp theo. Ghi thông qua hàng đợi giúp giảm tải cho đường dẫn phản hồi. Nhiều hệ thống kết hợp cả hai phương pháp này.
Hệ thống cần ghi nhớ những gì?
Việc lưu trữ từng câu một sẽ tạo ra một kho lưu trữ lộn xộn. Người viết nhật ký cần một chính sách rõ ràng.
Một bản ghi được coi là ứng cử viên sáng giá cho bộ nhớ khi nó chứa một trong những mục sau:
• Một thông tin ổn định về người dùng hoặc dự án.
• Một sở thích trực tiếp.
• Một ràng buộc đã nêu.
• Một quyết định có tác động trong tương lai.
• Một sự kiện đã xảy ra.
• Một sự điều chỉnh cho một ký ức trước đó.
• Một mô hình lặp lại ảnh hưởng đến công việc trong tương lai.
• Yêu cầu của người dùng về việc ghi nhớ điều gì đó.
Một bản ghi được coi là ứng cử viên yếu khi nó chứa lời chào, nội dung thừa, suy đoán, đoạn văn mẫu sao chép hoặc chi tiết tạm thời không có giá trị về sau.
Một quy tắc chấm điểm đơn giản có thể kiểm tra bốn tín hiệu:
•Mức độ quan trọng:Thông tin này có còn ý nghĩa gì sau này không?
•Tính mới lạ:Đây có phải là thông tin mới không?
•Tính bền vững:Thông tin này có còn đúng không?
•Ý định của người dùng:Người dùng có yêu cầu hệ thống ghi nhớ thông tin này không?
Quyết định cuối cùng có thể đến từ các quy tắc, một mô hình nhỏ, một lệnh gọi công cụ mô hình chính, hoặc sự kết hợp của các phương pháp này.
Việc truy xuất cần phải có tính chọn lọc.
Một kho dữ liệu dài hạn sẽ phát triển theo thời gian. Việc gửi toàn bộ kho dữ liệu trong mỗi yêu cầu sẽ tái tạo lại vấn đề ngữ cảnh ban đầu.
Lớp truy xuất nên trả về một tập hợp nhỏ các bản ghi phù hợp với nhu cầu hiện tại. Một hệ thống thực tế thường kết hợp nhiều phương pháp tìm kiếm khác nhau.
Tìm kiếm chính xác
Sử dụng chức năng tìm kiếm chính xác cho các trường đã biết như tên, vai trò, ngôn ngữ, trạng thái tài khoản hoặc ID dự án.
Ví dụ:
Chọn giá trị
từ bảng memory_facts
trong đó user_id = :user_id
và fact_key = ‘profile.name’
và valid_to là null
Tìm kiếm sự kiện được lọc
Sử dụng các bộ lọc có cấu trúc theo thời gian, dự án, người hoặc loại sự kiện.
Ví dụ:
Chọn nội dung, occurred_at
từ memory_events
nơi user_id = :user_id
và occurred_at >= :start_date
và occurred_at < :end_date
sắp xếp theo occurred_at giảm dần
Tìm kiếm vectơ
Sử dụng embedding cho các câu hỏi thể hiện ý nghĩa mà không cần khóa chính xác. Qdrant và pgvector hỗ trợ tìm kiếm tương đồng trên các vector đã lưu trữ. Chỉ mục HNSW có thể tăng tốc tìm kiếm lân cận gần đúng cho các kho dữ liệu lớn hơn.
Ví dụ về yêu cầu:
“Tôi nên chọn phong cách lập trình nào cho dự án bảng điều khiển?”
Những gì bộ nhớ lưu trữ có thể nói rằng:
“Hãy sử dụng TypeScript và các thành phần React dựa trên lớp cho ứng dụng tài nguyên máy chủ.”
Cách diễn đạt khác nhau, nhưng ý nghĩa gần giống nhau. Tìm kiếm vector có thể tìm thấy kết quả phù hợp.
Xếp hạng kết hợp
Một công thức xếp hạng đơn giản có thể kết hợp nhiều tín hiệu:
Điểm số = Độ phù hợp ngữ nghĩa + Độ phù hợp phạm vi + Độ cập nhật + Độ tin cậy + Mã PIN người dùng
Mức độ ưu tiên phụ thuộc vào sản phẩm. Quy trình làm việc trong lĩnh vực y tế có thể ưu tiên độ tin cậy của nguồn thông tin. Trợ lý cá nhân có thể ưu tiên các bộ nhớ do người dùng ghim. Một tác nhân dự án có thể ưu tiên kho lưu trữ đang hoạt động và các quyết định gần đây.
Các bản cập nhật thông tin cần có lịch sử phiên bản.
Bản ghi demo cho thấy một lỗi hữu ích. Người dùng ban đầu nói, “Tôi 27 tuổi,” sau đó sửa lại thành 26. Nguyên mẫu tạo ra một bộ nhớ thứ hai thay vì cập nhật bộ nhớ đầu tiên.
Hành vi đó tạo ra bối cảnh mâu thuẫn.
Một thiết kế mạnh mẽ hơn sẽ coi một số dữ kiện nhất định như các khóa phiên bản:
fact_key: profile.age
old_value: 27
new_value: 26
status: superseded
source: message_842
changed_at: 2026 –08–06T10:20:00+05:30
Hệ thống có thể giữ lại giá trị cũ để kiểm toán, nhưng chỉ giá trị hiện tại mới được sử dụng cho các lời nhắc thông thường.
Không phải mọi sự mâu thuẫn đều có nghĩa là hồ sơ cũ sai. Người dùng có thể thay đổi công việc, chuyển đến thành phố mới hoặc chuyển đổi công cụ dự án. Hồ sơ cần có ngày tháng xác thực.
Sử dụng các trường như sau:
· valid_from
· valid_to
· recorded_at
· source_id
· confidence
· status
Mô hình này hỗ trợ việc sửa lỗi và thay đổi thực tế mà không xóa bỏ lịch sử.
Đồ thị bộ nhớ lưu trữ các liên kết cá nhân và dự án.
Một số ký ức chỉ có ý nghĩa khi được lưu giữ cùng các mối quan hệ.
Mùi hương có thể gợi nhớ cho người ta về một địa điểm. Chiếc điều khiển từ xa có thể gợi nhớ một kỷ niệm vui vẻ trong gia đình. Tên dịch vụ có thể chỉ ra một lần triển khai, một sự cố, một yêu cầu hỗ trợ và một thành viên trong nhóm.
Đồ thị có thể biểu diễn các mối liên hệ này:
[Điều khiển từ xa] – nhắc nhở người dùng về → [Sự cố gia đình] [Sự cố gia đình] – xảy ra tại → [Căn hộ cũ] [Sự cố gia đình] – liên quan đến → [Anh trai] Việc truy xuất đồ thị hoạt động tốt đối với các câu hỏi có nhiều bước nhảy:• Sự cố nào liên quan đến thiết bị này?
• Ai có mặt trong sự kiện đó?
• Việc triển khai nào đã diễn ra sau cuộc họp phê duyệt?
• Lỗi nào đã ảnh hưởng đến cùng một mô-đun và khách hàng?
Neo4j là một lựa chọn. Cơ sở dữ liệu quan hệ có thể mô hình hóa cùng một mẫu thông qua các thực thể, mối quan hệ và bảng memory_links. Hãy bắt đầu với kho lưu trữ đơn giản hơn. Chuyển sang cơ sở dữ liệu đồ thị khi việc truy vấn mối quan hệ trở nên khó quản lý.
Kiến trúc bộ nhớ thực tiễn
Một thiết kế sản xuất quy mô nhỏ có thể sử dụng các bộ phận này:
Một cơ sở dữ liệu có thể đảm nhiệm nhiều vai trò trong phiên bản đầu tiên. PostgreSQL với pgvector có thể lưu trữ tin nhắn, sự kiện, siêu dữ liệu và các vector nhúng. Một kho lưu trữ vector chuyên dụng sẽ trở nên hữu ích khi tải tìm kiếm hoặc quy mô tăng lên.
Xây dựng một bộ nhớ thu nhỏ
Kế hoạch xây dựng sau đây bám sát bản demo gốc, nhưng loại bỏ các bước cụ thể của sản phẩm bị thiếu trong bản ghi.
Bước 1: Tạo phạm vi người dùng và phạm vi luồng
Mỗi tin nhắn và bản ghi nhớ đều cần một người sở hữu rõ ràng.
Hãy sử dụng các mã định danh này:
· tenant_id
· user_id
· project_id
· thread_id
Truy vấn truy xuất phải bao gồm các bộ lọc phạm vi. Độ tương đồng vectơ mà không có bộ lọc người thuê có thể làm rò rỉ dữ liệu giữa các người dùng.
Bước 2: Lưu lại toàn bộ thông báo nguồn
Thông điệp gốc là bằng chứng. Hãy lưu trữ nó trước khi trích xuất.
Tạo bảng chat_messages (
id uuid primary key ,
tenant_id uuid not null ,
user_id uuid not null ,
thread_id uuid not null ,
role text not null ,
content text not null ,
created_at timestamptz not null default now()
)
Bước 3: Tạo một bảng bộ nhớ
Phiên bản đầu tiên có thể sử dụng một bảng với trường loại.
Tạo phần mở rộng nếu vectơ chưa tồn tại
Tạo bảng memory_records (
id uuid khóa chính,
tenant_id uuid không rỗng ,
user_id uuid không rỗng ,
project_id uuid,
kind văn bản không rỗng kiểm tra (kind trong ( ‘semantic’ , ‘episodic’ , ‘procedural’ ) ),
fact_key văn bản,
content văn bản không rỗng ,
occurred_at timestamptz,
valid_from timestamptz,
valid_to timestamptz,
source_message_id uuid tham chiếu chat_messages (id) ,
confidence numeric ( 4 , 3 ) ,
status văn bản không rỗng mặc định ‘active’ ,
embedding vector ( 1536 ) ,
created_at timestamptz không rỗng mặc định now () ,
updated_at timestamptz không rỗng mặc định now ()
)
Kích thước vector phải khớp với mô hình nhúng. Không sao chép 1536 mà không kiểm tra mô hình đã chọn.
Bước 4: Thêm chỉ mục
Tạo chỉ mục memory_scope_idx
trên memory_records ( tenant_id, user_id, project_id, kind, status )
Tạo chỉ mục memory_fact_key_idx
trên memory_records ( tenant_id, user_id, fact_key )
với điều kiện status = ‘active’
Tạo chỉ mục memory_embedding_hnsw_idx
trên memory_records
sử dụng hnsw ( embedding vector_cosine_ops )
Bước 5: Trích xuất các ký ức ứng cử viên
Hãy yêu cầu mô hình cung cấp dữ liệu JSON có cấu trúc, chứ không phải văn bản tự do.
{
“memories” : [
{
“kind” : “semantic” ,
“factKey” : “profile.name” ,
“content” : “Tên người dùng là Yogesh.” ,
“confidence” : 0.99 ,
“action” : “upsert”
}
]
}
Kiểm tra tính hợp lệ của kết quả đầu ra so với lược đồ. Loại bỏ các bản ghi thiếu phạm vi, các loại không được hỗ trợ hoặc nội dung không an toàn.
Bước 6: Giải quyết các mục trùng lặp và xung đột
Sử dụng `fact_key` cho các sự kiện ổn định. Tìm kiếm các bản ghi đang hoạt động trước khi chèn.
Đối với các bản ghi theo từng sự kiện, hãy so sánh thông báo nguồn, thời gian sự kiện và mã băm nội dung. Từ ngữ tương tự không phải lúc nào cũng có nghĩa là sự kiện trùng lặp.
Bước 7: Tạo các embedding
Chỉ tạo các embedding cho những bản ghi cần tìm kiếm ngữ nghĩa. ID chính xác, bộ đếm và thông tin bí mật không nên được lưu trữ trong vector.
Bước 8: Truy xuất một bộ nhớ nhỏ
Đoạn mã TypeScript sau đây kết hợp trạng thái luồng, các sự kiện chính xác và sự trùng khớp về ngữ nghĩa.
type MemoryContext = {
recentMessages : ChatMessage []
exactFacts : MemoryRecord []
relatedMemories : MemoryRecord []
}
async function buildMemoryContext ( input : {
tenantId: string
userId: string
projectId?: string
threadId: string
query: string
} ): Promise < MemoryContext > {
const recentMessages = await loadRecentMessages (input. threadId , 12 )
const exactFacts = await findExactFacts (input)
const relatedMemories = await searchMemories ({
…input,
limit : 6 ,
minScore : 0.76 ,
})
return {
recentMessages,
exactFacts,
relatedMemories : removeDuplicates (relatedMemories, exactFacts),
}
}
Bước 9: Xây dựng yêu cầu mô hình cuối cùng
Hãy tách biệt bộ nhớ khỏi văn bản người dùng. Đánh dấu nó là dữ liệu đã truy xuất.
QUY TẮC HỆ THỐNG Chỉ
sử dụng bộ nhớ khi nó khớp với người dùng và dự án hiện tại . Coi các thông báo nguồn là bằng chứng đáng tin cậy hơn so với các bản tóm tắt được tạo ra. Yêu cầu chỉnh sửa khi bộ nhớ hiện tại mâu thuẫn. BỘ NHỚ ĐƯỢC NHỚ LẠI – [ngữ nghĩa] Tên người dùng : Yogesh – [sở thích] Chủ đề ưa thích: chế độ sáng – [từng sự kiện] Đã học thiết kế hệ thống ngày hôm qua CHỦ ĐỀ GẦN ĐÂY … YÊU CẦU CỦA NGƯỜI DÙNG Tên tôi là gì ?
Bước 10: Thể hiện khả năng nhớ lại trong quá trình phát triển
Một bảng bên hiển thị danh sách các bản ghi đã được truy xuất rất hữu ích trong quá trình thử nghiệm. Nó giúp phát hiện các kết quả trùng khớp không liên quan, các thông tin lỗi thời và các xung đột tiềm ẩn.
Hãy giữ bảng điều khiển này đằng sau một cờ dành cho nhà phát triển để bảo mật bộ nhớ riêng tư. Người dùng sản xuất nên xem và quản lý các bộ nhớ đã lưu thông qua một màn hình bảo mật rõ ràng.
Ghi trực tiếp, ghi theo hàng đợi và các công cụ bộ nhớ tác nhân
Các thao tác bộ nhớ có thể được thực hiện theo nhiều cách khác nhau.
Chiết xuất trực tiếp
Ứng dụng trích xuất bộ nhớ trước khi trả về phản hồi.
Phương pháp này hỗ trợ việc gọi lại ngay lập tức trong tin nhắn tiếp theo. Nó bổ sung thêm thời gian xử lý cho đường dẫn yêu cầu.
Trích xuất theo hàng đợi
Ứng dụng sẽ lưu lại cuộc hội thoại trước, sau đó mới gửi cho người xử lý.
Phương pháp này giúp phản hồi tin nhắn nhanh hơn. Thông tin mới có thể xuất hiện sau vài giây.
Các hoạt động do tác nhân lựa chọn
Nghiên cứu về bộ nhớ tác nhân coi các hành động như thêm, cập nhật, truy xuất, tóm tắt và loại bỏ là các công cụ. Tác nhân quyết định thao tác nào phù hợp với bước hiện tại. Bài báo AgeMem nghiên cứu một chính sách quản lý bộ nhớ ngắn hạn và dài hạn thông qua các hành động như vậy. [5]
Phương pháp này giúp người đại diện kiểm soát tốt hơn. Nó đòi hỏi quyền sử dụng công cụ nghiêm ngặt, giới hạn chi phí và đánh giá.
Một sản phẩm cân bằng có thể sử dụng các quy tắc cho thông tin nhận dạng và quyền riêng tư, trích xuất theo hàng đợi cho các cuộc hội thoại thông thường và truy xuất do tác nhân lựa chọn cho các tác vụ phức tạp.
Củng cố trí nhớ và “mơ mộng”
Bản ghi nguồn có đề cập đến việc mơ mộng. Thuật ngữ này mang tính không chính thức, nhưng ý tưởng thiết kế lại có cơ sở nghiên cứu.
Công việc hợp nhất xem xét các sự kiện thô và tạo ra các bản ghi cấp cao hơn. Nó có thể hợp nhất các bản ghi trùng lặp, tạo bản tóm tắt, làm nổi bật các mẫu lặp lại, giảm bớt các mục lỗi thời hoặc tạo liên kết.
Bài báo về các tác nhân tạo sinh đã sử dụng luồng bộ nhớ, truy xuất và phản chiếu. Giai đoạn phản chiếu hình thành nên các phát biểu cấp cao hơn từ những kinh nghiệm trong quá khứ.
Một công việc làm thêm ban đêm có thể thay đổi cục diện:
• Quá trình triển khai thất bại do thiếu file migration.
• Lần triển khai thứ hai cũng thất bại vì lý do tương tự.
• Danh sách kiểm tra bản phát hành thứ ba đã phát hiện ra vấn đề.
Vào bộ nhớ quy trình này:
“Hãy chạy các bản di chuyển cơ sở dữ liệu và xác minh trạng thái của chúng trước khi triển khai ứng dụng.”
Việc tổng hợp thông tin phải giữ nguyên các liên kết nguồn. Một bản tóm tắt thiếu bằng chứng sẽ khó tin cậy hoặc khó xác thực.
Các chế độ hỏng hóc thường gặp
Lưu trữ mọi thứ
Cửa hàng tràn ngập lời chào, những thông tin lặp đi lặp lại và những đoạn văn bản ít giá trị. Kết quả tìm kiếm chỉ toàn là nhiễu.
Sửa lỗi: thêm các quy tắc nổi bật, kiểm tra trùng lặp và phân bổ bộ nhớ.
Coi sự tương đồng là sự thật
Một sự tương đồng về vectơ có thể gần đúng về ý nghĩa nhưng vẫn không phù hợp với người hoặc dự án hiện tại.
Khắc phục: Áp dụng các bộ lọc theo người thuê, người dùng, dự án, loại, thời gian và trạng thái trước khi xếp hạng.
Bổ sung thông tin đính chính khi có thông tin mới.
Hệ thống gửi hai độ tuổi, hai chức danh công việc hoặc hai công cụ ưa thích vào cùng một lời nhắc.
Khắc phục: sử dụng khóa dữ kiện có phiên bản và một bản ghi hoạt động duy nhất.
Che giấu các quyết định về trí nhớ
Các nhà phát triển không thể xem được những gì đã được lưu trữ hoặc truy xuất.
Khắc phục: ghi lại dấu vết bộ nhớ với ID nguồn, điểm số và kết quả hành động.
Cho phép văn bản được tạo tự động ghi đè lên bằng chứng.
Bản tóm tắt mô hình thay thế cho tuyên bố ban đầu của người dùng.
Sửa lỗi: Giữ nguyên các thông báo thô làm bộ nhớ nguồn. Coi các bản tóm tắt là các bản ghi được tạo ra.
Trộn lẫn dữ liệu người dùng
Kết quả tìm kiếm trả về ký ức của người khác.
Khắc phục: Áp dụng phạm vi người dùng và người thuê trong các chính sách cơ sở dữ liệu và mọi truy vấn.
Lưu trữ dữ liệu vĩnh viễn
Sản phẩm này không có hạn sử dụng, không bị xóa hoặc không cần sự chấp thuận của người dùng.
Khắc phục: xác định các quy tắc lưu giữ, quyền kiểm soát của người dùng, đường dẫn xóa và hồ sơ kiểm toán.
Bảo mật và quyền riêng tư cần được tích hợp ngay từ khâu thiết kế.
Hệ thống bộ nhớ có thể lưu trữ tên, sở thích, hồ sơ công việc, địa điểm và các sự kiện cá nhân. Dữ liệu đó cần có các cơ chế kiểm soát rõ ràng.
Hãy tuân thủ các quy tắc sau:
• Yêu cầu sự đồng ý trước khi lưu trữ kỷ niệm cá nhân.
• Cung cấp cho người dùng một trang để xem, chỉnh sửa, ghim hoặc xóa kỷ niệm.
• Phân tách người dùng thông qua các chính sách cơ sở dữ liệu.
• Mã hóa dữ liệu nhạy cảm khi lưu trữ và khi truyền tải.
• Bảo mật thông tin bí mật, mật khẩu, mã thông báo và dữ liệu thanh toán, tránh việc trích xuất kỷ niệm.
• Ghi lại nguồn gốc tạo ra mỗi kỷ niệm.
• Hỗ trợ thời gian lưu giữ và xóa tài khoản.
• Giới hạn quyền truy cập mô hình ở phạm vi nhỏ nhất cần thiết.
• Kiểm tra khả năng truy xuất dữ liệu giữa các người dùng.
Thiết bị ghi bộ nhớ cần phân loại dữ liệu trước khi lưu trữ. Các trường dữ liệu có rủi ro cao có thể bị chặn, che giấu hoặc gửi đến kho lưu trữ được bảo vệ với quyền truy cập nghiêm ngặt hơn.
Cách kiểm tra bộ nhớ
Màn hình trò chuyện được trau chuốt có thể che giấu một lớp bộ nhớ yếu. Hãy kiểm tra hệ thống bộ nhớ như một thành phần sản phẩm riêng biệt.
Theo dõi các chỉ số này:
• Tỷ lệ truy xuất chính xác.
• Tỷ lệ truy xuất sai
. • Tỷ lệ thông tin
lỗi thời.
• Tỷ lệ trùng lặp. • Số lượng rò rỉ thông tin giữa các người dùng.
• Số lượng token được truy xuất trung bình.
• Thời gian đọc dữ liệu.
• Chi phí ghi dữ liệu.
• Tỷ lệ sửa lỗi của người dùng.
Xây dựng bản demo với InsForge
Bản ghi này minh họa khái niệm thông qua InsForge. Sản phẩm hiện liệt kê PostgreSQL, xác thực, lưu trữ, chức năng biên, định tuyến mô hình, dịch vụ thời gian thực, tìm kiếm vector, trang web, công việc theo lịch trình, tính toán, nhắn tin, thanh toán và phân tích. Giao diện dòng lệnh (CLI) của nó có thể tạo hoặc liên kết các dự án và cài đặt kỹ năng tác nhân cho trợ lý lập trình.
Một bản demo đơn giản có thể tuân theo kế hoạch sau:
1. Tạo dự án InsForge.
2. Kết nối dự án thông qua thiết lập CLI hoặc MCP.
3. Tạo ứng dụng Next.js hoặc React.
4. Thêm xác thực người dùng.
5. Tạo bảng tin nhắn và bộ nhớ trong PostgreSQL.
6. Bật pgvector.
7. Thêm chức năng trích xuất bộ nhớ.
8. Thêm chức năng nhúng và tìm kiếm tương đồng.
9. Xây dựng trang trò chuyện với bảng hiển thị bộ nhớ đã được nhớ lại.
10. Kiểm tra cập nhật, khả năng nhớ lại giữa các phiên và cách ly người dùng.
Bản ghi được cung cấp đề cập đến lệnh project-link, nhưng nó không hiển thị toàn bộ lệnh. Tài liệu InsForge hiện tại liệt kê insforge login, insforge create và insforge link là quy trình CLI cơ bản.
Tài liệu của InsForge hỗ trợ lập chỉ mục pgvector và HNSW. Kiến trúc tương tự có thể chạy trên nền tảng khác. Một phiên bản PostgreSQL cục bộ với pgvector, một dịch vụ API và bất kỳ nhà cung cấp mô hình nào là đủ để tạo ra một nguyên mẫu hoạt động.
Điều tôi sẽ xây dựng đầu tiên
Tôi sẽ bắt đầu với một lời hứa về bộ nhớ ngắn gọn:
Hệ thống sẽ ghi nhớ các tùy chọn người dùng đã được phê duyệt và các quyết định dự án giữa các phiên làm việc.
Lời hứa đó dễ kiểm chứng hơn so với lời hứa “người đại diện nhớ mọi thứ”.
Phiên bản phát hành đầu tiên sẽ bao gồm:
• Trạng thái luồng gần đây.
• Kho lưu trữ dữ liệu có phiên bản.
• Bảng sự kiện theo từng giai đoạn.
• Tìm kiếm vector với bộ lọc phạm vi.
• Trang quản lý bộ nhớ hiển thị.
• Liên kết nguồn cho mỗi bản ghi đã lưu.
• Một tập dữ liệu đánh giá nhỏ.
Việc ghi nhớ đồ thị và các quy trình đã học có thể được thực hiện sau. Chúng sẽ tạo ra giá trị sau khi sản phẩm đã có đủ các sự kiện được liên kết và các quy trình công việc lặp đi lặp lại.
Bài học thực sự
Phần khó nhất của việc quản lý bộ nhớ tác nhân không phải là lưu trữ văn bản. Phần khó là chọn ra những gì xứng đáng được lưu giữ.
Một bộ nhớ mạnh mẽ sẽ trả lời năm câu hỏi trong mỗi lượt chơi:
1. Điều gì đã xảy ra trong luồng hoạt động?
2. Những dữ kiện đã lưu nào khớp với người dùng và dự án này?
3. Những sự kiện trong quá khứ nào khớp với yêu cầu?
4. Bản ghi nào là bản ghi hiện tại khi các dữ kiện mâu thuẫn?
5. Có thể cấp phát bao nhiêu bộ nhớ cho lời nhắc?
Bộ nhớ ngắn hạn giúp tác nhân duy trì tính liên tục trong một nhiệm vụ. Bộ nhớ dài hạn lưu giữ kiến thức được chọn lọc giữa các nhiệm vụ. Hồ sơ ngữ nghĩa lưu trữ các sự kiện và quy tắc. Hồ sơ sự kiện lưu giữ các sự kiện. Hồ sơ quy trình lưu giữ các bước có thể tái sử dụng. Tìm kiếm vectơ tìm kiếm ý nghĩa. Liên kết đồ thị kết nối những người, đối tượng, địa điểm và sự kiện có liên quan.
Ghép các yếu tố này lại với nhau, và người đại diện sẽ không còn cư xử như thể mỗi buổi gặp mặt đều là lần đầu tiên nữa.
Danh sách kiểm tra học tập
Giờ đây, người đọc có thể giải thích như sau:
• Tại sao lịch sử trò chuyện và trí nhớ dài hạn không giống nhau.
• Cửa sổ ngữ cảnh trượt làm mất các chi tiết cũ hơn như thế nào.
• Tại sao các sự kiện chính xác cần các khóa có cấu trúc.
• Tại sao tìm kiếm vector là một phương pháp truy xuất.
• Trí nhớ ngữ nghĩa, trí nhớ sự kiện và trí nhớ thủ tục khác nhau như thế nào.
• Đồ thị liên kết các ký ức giữa các thực thể
như thế nào. • Đường dẫn đọc khác với đường dẫn ghi như thế nào.
• Cách xử lý các chỉnh sửa mà không xóa lịch sử kiểm toán.
• Tại sao bộ lọc phạm vi bảo vệ dữ liệu người dùng.
• Những bài kiểm tra nào cho thấy hệ thống bộ nhớ yếu.
Bài viết liên quan: