8 mô hình mới nổi về bộ nhớ tác tử (Agentic Memory) và chìa khóa cho bảo mật AI

Hơi trễ một chút cho phần cuối cùng của loạt bài 19 hệ thống, nhưng muộn còn hơn không.

Sáu mẫu hình phổ quát trong 19 hệ thống mà tôi đang khai thác là xương sống của loạt bài này. Đầu tư chất lượng ở thời điểm viết. Nguồn gốc đi kèm với dữ kiện. Truy xuất lai kết hợp RRF. Lưu trữ phân tầng với thăng hạng dựa trên nhiệt độ. Ngân sách ngữ cảnh rõ ràng. Công cụ chứ không phải tiêm nhiễm ở bề mặt tác nhân. Mỗi mẫu hình đều có bài viết riêng vì ba hoặc nhiều hệ thống đã độc lập đi đến cùng một nguyên tắc.

Các mẫu hình phổ quát dừng lại ở đây. Từ đó, các mẫu hình mới nổi bắt đầu.

Bài viết này nói về tám mẫu hình nằm dưới ngưỡng, chỉ tồn tại trong một hoặc hai hệ thống, nơi cách triển khai giải quyết rõ ràng một vấn đề thực tế đến mức khó tin rằng chúng sẽ mãi hiếm hoi. Bảy mẫu hình xuất hiện trong đúng một hệ thống. Một mẫu hình xuất hiện trong hai hệ thống và chỉ còn cách một lần áp dụng nữa là đủ điều kiện. Mẫu hình đầu tiên được xử lý sâu nhất vì nó quan trọng nhất.

Ở giai đoạn đầu, một số mẫu hình này sẽ không trở nên phổ quát. Ở giai đoạn muộn còn tệ hơn: bạn xây dựng một hệ thống vào năm 2026 mà không có cơ chế ủy quyền ở lớp lưu trữ vì một bản tổng hợp gọi nó là đặc thù một lần, và bạn sẽ nhận được một bản demo tiêm nhiễm prompt trên Hacker News vào năm 2027.

Công cụ lưu trữ là cơ quan thẩm quyền duy nhất giữ vững

Bài viết trước lập luận rằng tác nhân nên nắm giữ các công cụ. Hãy cung cấp cho nó một công cụ SQL và câu hỏi trở nên tức thời: điều gì ngăn nó truy vấn bảng mà nó không được phép?

Các cách tiếp cận ngây thơ đã được biết đến rộng rãi và đều sai.

Hướng dẫn ở cấp độ prompt: "Bạn không được phép đọc bảng conversations." Hoạt động với một mô hình hợp tác. Thất bại trước bất kỳ mô hình nào hiểu sai hướng dẫn, quyết định rằng lệnh cấm không áp dụng cho nhiệm vụ hiện tại của nó, hoặc đang hoạt động dưới một jailbreak.

Bộ lọc ở cấp độ ứng dụng: công cụ sql_query bao bọc SQL của mô hình, phân tích cú pháp để tìm các tham chiếu bảng bị cấm, từ chối truy vấn trước khi chuyển nó đến cơ sở dữ liệu. Hoạt động với một mô hình ngây thơ. Thất bại trước bất kỳ mô hình nào trích dẫn tên bảng, sử dụng ATTACH, khai thác sự không khớp phân tích cú pháp giữa trình bao bọc và cơ sở dữ liệu, hoặc định tuyến qua một view được định nghĩa ở nơi khác.

Chỉ truy cập qua ORM: tác nhân không bao giờ chạm vào SQL thô, nó gọi các phương thức đã được định kiểu. Hoạt động cho đến khi hệ thống phát triển thêm một công cụ gỡ lỗi, một công cụ phân tích, một công cụ di chuyển, hoặc một tính năng "cho phép tác nhân kết nối hai bảng", lúc đó quy tắc bị phá vỡ và sự hỏng hóc không được chú ý.

Nói một cách đơn giản: không có cái nào trong số này là thực thi. Chúng chỉ là gợi ý. Một hệ thống muốn có sự cô lập thực sự giữa các tác nhân con phải yêu cầu chính công cụ lưu trữ từ chối việc đọc, chứ không phải lớp bên trên nó. Đây là nguyên tắc mà bảo mật dựa trên khả năng áp đặt lên tài nguyên hệ điều hành: nhân nói không, chứ không phải ứng dụng. Đây cũng là nguyên tắc mà bảo mật cấp hàng của PostgreSQL áp đặt lên SaaS đa đối tượng thuê: chính sách nằm trong cơ sở dữ liệu, không phải ORM, bởi vì "kỹ sư xây dựng microservice mới quên áp dụng bộ lọc đối tượng thuê" là một lớp lỗi mà chỉ có chính sách của công cụ lưu trữ mới có thể loại trừ.

second-brain là ví dụ thực tế đầu tiên trong kho ngữ liệu. Cơ sở dữ liệu có phạm vi của nó có ba lớp, mỗi lớp đều cần thiết, không lớp nào tự nó là đủ.

Một kết nối SQLite trong bộ nhớ mới cho mỗi tác nhân có phạm vi. Hàm tạo mở :memory: và đính kèm cơ sở dữ liệu thực ở chế độ chỉ đọc. Kết nối của tác nhân không có lược đồ chính thực sự, không có gì để đọc ngoại trừ những gì lớp tiếp theo đặt ở đó.

Các TEMP VIEW trong lược đồ chính chuyển hướng đến các bảng được phép trong nguồn. Định nghĩa view đến từ hồ sơ của tác nhân và có thể mã hóa việc biên tập cấp cột hoặc bộ lọc cấp hàng. Một trình xác thực tên view ngăn chặn việc tiêm tên bảng độc hại thông qua hồ sơ.

Một hook ủy quyền C-API của SQLite từ chối bất kỳ việc đọc lược đồ nguồn nào không đi qua một view. Hook kích hoạt cho mọi lần đọc mà SQLite sắp thực hiện, trước khi trình tối ưu hóa thậm chí giải quyết tên bảng. Một lần đọc bên trong thân view được cho phép, view là bộ lọc phạm vi. Một lần đọc ở cấp cao nhất được kiểm tra so với tập hợp các tên view mà phạm vi đã tạo. Bất kỳ lần đọc nào trực tiếp vào lược đồ nguồn đều bị từ chối mà không có ngoại lệ.

LLM có thể viết bất kỳ SQL nào nó muốn. Nó có thể trích dẫn tên bảng, sử dụng UNION, sử dụng ATTACH, sử dụng toàn bộ ngữ pháp của SQLite. Nó không thể thành công trong việc đọc một hàng từ một bảng không có trong danh sách cho phép, bởi vì trình ủy quyền chặn việc đọc ở lớp C trước khi tên bảng được giải quyết. Bộ lọc cấp ứng dụng có thể bị vượt qua. Ủy quyền của công cụ lưu trữ thì không.

Khoảng 50 dòng Python thư viện chuẩn. Không có phụ thuộc bổ sung, không có tiến trình bổ sung, không có di chuyển lược đồ. Chi phí cho mỗi truy vấn là một callback C cho mỗi lần đọc, vô hình trước chi phí của chính truy vấn. Mẫu hình kết hợp sạch sẽ với mọi thứ khác: sổ đăng ký công cụ của tác nhân vẫn có thể được kiểm soát tính năng, định nghĩa view vẫn có thể mã hóa việc biên tập cấp cột, lịch sử hội thoại vẫn có thể được biên tập tại thời điểm viết. Không có lớp nào trong số đó bị suy yếu bởi sự thực thi ở lớp lưu trữ. Chúng được củng cố bởi nó.

Cách đóng khung rất quan trọng. Mọi mẫu hình bảo mật khác trong 19 hệ thống đều là gợi ý. Công cụ lưu trữ là cơ quan thẩm quyền.

Ba mẫu hình nữa đáng được nêu tên

Bảo vệ điều kiện đua khi dọn dẹp bất đồng bộ (llm-wiki)

Bảo trì bộ nhớ nền về cơ bản có tính cạnh tranh với các hành động của người dùng ở nền trước. Một lần quét bắt đầu với dự án A và kết thúc với dự án B đã làm hỏng cả hai. Nó đã chuyển các quyết định của A vào kho xem xét của B, hoặc đánh dấu các mục của B là đã giải quyết dựa trên dữ liệu của A. Đây là một lớp lỗi dễ giới thiệu, khó phát hiện và không thể khôi phục sạch sẽ vì trạng thái bị hỏng trông có vẻ hợp lệ.

llm-wiki chạy một vòng lặp xem xét nền hai giai đoạn và tại mọi điểm nhường, kiểm tra lại hai tín hiệu bảo vệ điều kiện đua: một tín hiệu hủy bỏ được kích hoạt bởi trình xử lý chuyển đổi dự án và một so sánh đường dẫn với dự án hiện tại trong kho giao diện người dùng. Một trong hai lần kiểm tra thất bại, quá trình quét trả về giữa chừng mà không áp dụng các quyết định. Cái bắt tay chuyển đổi dự án ở phía hàng đợi hoàn thiện bức tranh: nó xả trạng thái của dự án đang hoạt động xuống đĩa trước khi xóa bộ nhớ, hoàn nguyên các mục đang xử lý về trạng thái chờ, hủy bỏ cả cuộc gọi LLM đang thực hiện và phán quyết quét đang thực hiện, và chỉ sau đó mới ghi vào đường dẫn của dự án đã tạm dừng.

Mẫu hình meta là điểm mấu chốt: xác định khi có thể, LLM khi cần thiết, có thể hủy bỏ ở mọi nơi. Cấu trúc hai giai đoạn giữ LLM ra khỏi các trường hợp mà các kiểm tra tồn tại đơn giản có thể xử lý. Bảo vệ điều kiện đua giữ cho cả hai giai đoạn có thể hủy bỏ. Sự kết hợp này là một khuôn mẫu cho bất kỳ vòng lặp bảo trì bộ nhớ nền nào trong bất kỳ hệ thống nào.

Hàm tạo no-op tự động xuống cấp (graymatter)

Thiết kế API thư viện có một sự căng thẳng lặp đi lặp lại. "Hello world" đơn giản nhất muốn thư viện hoạt động ngay, một dòng để xây dựng, một dòng để gọi. Tư thế sản xuất phòng thủ nhất muốn nó thất bại ồn ào khi xây dựng với một lỗi có cấu trúc mà người gọi không thể bỏ qua.

graymatter chọn im lặng khi thất bại, nhưng với một nguyên tắc biến sự đánh đổi thành năng suất. Hàm tạo không bao giờ trả về lỗi. Nếu init thất bại, bbolt bị khóa, thư mục dữ liệu không thể ghi, kho vector không thể mở, nó ghi nhật ký vào stderr và trả về một Memory đã xuống cấp mà các phương thức của nó đều là no-op. Người gọi trong sản xuất xác minh thông qua Healthy() trước khi tin tưởng vào handle. Thư viện có thể go get, có thể import trong ba dòng và hoạt động trong bản demo. Healthy() là thuế kỷ luật sản xuất.

Mẫu hình làm cho thư viện an toàn để nhúng vào các harness tác nhân có nghi thức khởi động riêng của chúng. Một harness tác nhân gọi [graymatter.New](https://graymatter.new/)(...) trong quá trình khởi động, bỏ qua đường dẫn lỗi vì không có đường dẫn lỗi, và tiếp tục, có được một lớp bộ nhớ hoạt động trong đường dẫn hạnh phúc và một dự phòng không có bộ nhớ khi thư mục dữ liệu ở chế độ chỉ đọc. Dù bằng cách nào, harness cũng khởi động. Đó là một loại thành phần phòng thủ cụ thể mà các hàm tạo thất bại ồn ào không thể cung cấp nếu không có xử lý lỗi rõ ràng tại mọi vị trí nhúng.

Phát hiện trùng lặp chế độ bóng tối (mem9)

Mọi hệ thống triển khai tính năng loại bỏ trùng lặp đều phải chọn một ngưỡng tương tự cosine. Trên 0,95 gần như chắc chắn là trùng lặp. Dưới 0,7 gần như chắc chắn là không. Khoảng không gian giữa là tranh chấp, và ngưỡng cắt phù hợp phụ thuộc vào mô hình nhúng, miền, phân phối truy vấn và chi phí của dương tính giả so với âm tính giả trong hệ thống cụ thể này.

Sự cám dỗ là quá lớn để chọn một ngưỡng dựa trên trực giác và triển khai. mem9 thì không. Nó chạy truy vấn phát hiện trùng lặp cho mọi dữ kiện, ghi lại điểm cosine trong biểu đồ Prometheus và không thực hiện hành động nào. Ngưỡng được hoãn lại cho đến khi dữ liệu sản xuất biện minh cho nó. "Triển khai quan sát, không phải heuristic."

Logic tương tự áp dụng cho mọi quyết định dựa trên ngưỡng trong mọi hệ thống bộ nhớ. Ngưỡng xếp hạng lại. Ngưỡng tin cậy thu hồi. Cổng nhiệt thăng hạng tầng. Ngưỡng tương tự hợp nhất thông tin chi tiết. Hầu hết các hệ thống trong 19 hệ thống đều triển khai các giá trị này dựa trên phỏng đoán. mem9 triển khai với giá trị bị hoãn lại. Nguyên tắc này hiếm và kết quả tốt hơn.

Bốn mẫu hình nữa, chặt chẽ hơn

Cô lập cơ sở dữ liệu vật lý theo từng đối tượng thuê (mem9).

Thay vì bộ lọc WHERE tenant_id = ? trên một kho dùng chung, mem9 cấp phát một cụm TiDB riêng cho mỗi đối tượng thuê thông qua TiDB Zero. Sự cô lập nằm ở phía công cụ lưu trữ. Ứng dụng không thể vô tình truy vấn xuyên đối tượng thuê vì không có kho dùng chung để truy vấn. Đó là một phiên bản có hạt thô hơn của cùng trạng thái cuối như ủy quyền lớp lưu trữ: sự cô lập được thực thi ở công cụ, không phải ứng dụng. Chi phí cơ sở hạ tầng mà trong lịch sử làm cho điều này không thực tế đã biến mất. TiDB Zero tự động cấp phát. Neon cũng làm điều tương tự cho PostgreSQL. Cloudflare D1 cũng làm điều tương tự cho SQLite.

Trang trí lượt nguồn với ngân sách ngữ cảnh rõ ràng (mem9).

Một bộ nhớ được truy xuất là một chuỗi. "Người dùng thích Postgres." Chính xác, ngắn gọn, không thể có cơ sở nếu không có ngữ cảnh. mem9 đính kèm các lượt hội thoại nguồn gốc như một trang trí, được tính điểm dựa trên truy vấn và giới hạn bởi một bộ ba ngân sách: điểm tối thiểu, giới hạn mỗi bộ nhớ, tổng giới hạn. Tác nhân đọc "Người dùng thích Postgres" sẽ nhận được lượt mà người dùng nói "chúng tôi đã thử MongoDB nhưng các phép join đã giết chết chúng tôi, vì vậy tôi đã chuyển sang Postgres vào quý trước." Không cần gọi công cụ thứ hai. Cơ sở nằm trong kết quả. Các điều kiện tiên quyết đã phổ quát: nguồn gốc cộng với truy xuất lai. Hầu hết các hệ thống trong 19 hệ thống có thể triển khai điều này trong hai ngày.

purpose.md như một tệp thứ tư (llm-wiki).

Mẫu hình LLM Wiki của Karpathy có ba tệp chính tắc: nguồn thô, bộ làm việc wiki và schema.md cho các quy tắc cấu trúc. llm-wiki thêm một tệp thứ tư: purpose.md, do người dùng điền, được nội dòng vào mọi cuộc gọi LLM mà hệ thống thực hiện. Mọi prompt tiếp nhận, mọi prompt tạo sinh, mọi trò chuyện truy xuất đều đọc nó. Hiệu quả là một ưu tiên hướng ổn định điều kiện mọi hành vi hạ nguồn. LLM sẽ đọc prompt hệ thống anyway. Thêm ý định của người dùng không tốn kém gì và nâng cao mọi thứ. Sự vắng mặt trong hầu hết các hệ thống khác khó giải thích hơn sự hiện diện của nó trong llm-wiki.

AGENTS.md như một hợp đồng tác nhân có thẩm quyền (Tolaria, OpenContext). Hầu hết các kho lưu trữ có AGENTS.md hoặc CLAUDE.md coi nó như một tệp gợi ý. Tolaria và OpenContext coi nó như một hợp đồng, hỗ trợ mọi điều khoản ràng buộc bằng một kiểm tra cơ học mà thất bại trong bản dựng nếu tác nhân vi phạm nó. "Không bỏ qua các hook pre-commit" không phải là một yêu cầu lịch sự, đó là một quy tắc mà CI thực thi. "Mức độ bao phủ kiểm thử phải duy trì trên ngưỡng" không phải là một hướng dẫn, đó là một thanh mà trình chạy kiểm thử hủy bỏ. Một gợi ý có thể bị bỏ qua. Một hợp đồng được hỗ trợ bởi một kiểm tra thì không. Hai hệ thống đã làm điều đó. Thêm một hệ thống nữa và nó đủ điều kiện.

Những mẫu hình nào sẽ trở nên phổ quát tiếp theo

Ủy quyền lớp lưu trữ sẽ trở nên phổ quát đầu tiên. Đây là dự đoán tự tin nhất trong phân tích nguồn. Mọi hệ thống bộ nhớ cung cấp cho tác nhân con quyền truy cập SQL đều chỉ cách một lần tiêm prompt khỏi một vi phạm bảo mật nếu không có sự thực thi ở lớp lưu trữ. Cơ sở hạ tầng đã sẵn sàng. SQLite đã có set_authorizer từ đầu những năm 2000. PostgreSQL RLS là chủ đạo. LanceDB và ClickHouse có các hook chính sách riêng của chúng. Rào cản không phải là kỹ thuật, mà là nhận thức. second-brain đã cung cấp ví dụ thực tế. Thế hệ API được quản lý tiếp theo sẽ sao chép nguyên tắc này vì lựa chọn thay thế là không thể bảo vệ được.

Trang trí lượt nguồn sẽ trở nên phổ quát thứ hai. Các điều kiện tiên quyết đã phổ quát. Việc triển khai là hai truy vấn cộng với một ngân sách. Lợi ích thông tin phía tác nhân đủ lớn đến nỗi bất cứ ai triển khai nó đầu tiên trong một API được quản lý sẽ rõ ràng tốt hơn trong việc căn cứ câu trả lời vào hội thoại nguồn so với bất cứ ai triển khai nó thứ hai. Áp lực sao chép là cao. graymatter có nguồn cho mỗi dữ kiện. supermemory có dòng dõi. Hindsight có nguồn gốc hội thoại đầy đủ. Bất kỳ cái nào trong số này cũng chỉ cách một PR khỏi mẫu hình.

Hàm tạo no-op tự động xuống cấp sẽ trở nên phổ quát thứ ba, và trong một ngôn ngữ khác. Các điều kiện văn hóa của Go làm cho mẫu hình an toàn. Người áp dụng tiếp theo khó có thể là Python, văn hóa quá háo hức với các ngoại lệ, nhưng có thể là Rust. Đó là một lựa chọn thiết kế API thư viện, không phải lựa chọn bộ nhớ, và nó sẽ lan rộng bất cứ nơi nào "thẩm mỹ demo cộng với kỷ luật sản xuất" là sự đánh đổi phù hợp.

Triển khai chế độ bóng tối là con ngựa ô. Kỹ thuật tầm thường, văn hóa khó khăn. Nếu một hệ thống thứ hai đo lường một ngưỡng trước khi chặn nó, mẫu hình sẽ đủ điều kiện ngay lập tức, và hệ thống thứ ba và thứ tư sẽ theo sau trong vòng một chu kỳ phát hành vì các yếu tố công thái học kỹ thuật là không thể chối cãi một khi đã được chứng minh.

Bốn mẫu hình còn lại đều phụ thuộc vào một hình dạng triển khai cụ thể trở nên phổ biến hơn. Bảo vệ điều kiện đua trở nên phổ quát khi nhiều hệ thống phát triển song song đa hội thoại. Cô lập vật lý theo đối tượng thuê trở nên phổ quát khi khách hàng doanh nghiệp được quản lý bắt đầu yêu cầu nó. purpose.md trở nên phổ quát khi mô hình LLM Wiki của Karpathy có triển khai thứ ba hoặc thứ tư. AGENTS.md như hợp đồng trở nên phổ quát khi khuôn khổ "tác nhân là đồng nghiệp" trở thành phép ẩn dụ harness thống trị. Không có cái nào là không thể. Không có cái nào là chắc chắn.

Kết luận

Chủ đề thống nhất xuyên suốt cả tám mẫu hình là cùng một quan điểm: lớp ứng dụng không phải là một ranh giới cô lập đáng tin cậy. Ủy quyền lớp lưu trữ là biểu hiện cho mỗi tác nhân. Cơ sở dữ liệu vật lý theo đối tượng thuê là biểu hiện cho mỗi đối tượng thuê. AGENTS.md như hợp đồng là biểu hiện cho mỗi hành vi tác nhân. Lần lặp tiếp theo của kho ngữ liệu này, theo dự đoán này, sẽ chứa một mẫu hình phổ quát mới với tên đó.

Bài viết trước đã đưa ra lập luận rằng tác nhân nên nắm giữ các công cụ và quyết định những gì cần truy xuất. Bài viết này nói về những gì giữ vững khi tác nhân hướng những công cụ đó đến một nơi bạn không mong đợi. Sáu mẫu hình phổ quát là sự đồng thuận. Tám mẫu hình ở đây là các chỉ báo hàng đầu về nơi sự đồng thuận sẽ chuyển động tiếp theo. Ủy quyền lớp lưu trữ là mũi nhọn của mũi nhọn, và chi phí của việc bỏ lỡ nó là loại chi phí xuất hiện trên Hacker News.