Tech Radar: Kiến Trúc Bộ Nhớ Agentic: Kho Episodic vs Semantic, Pipeline Hợp Nhất & Kinh Tế Context Window Cho Đàn Tác Tử Production

🇬🇧 Read the authoritative Master English version on tanhdev.com

Answer-First: Các đàn tác tử production năm 2026 thất bại vì bộ nhớ, không phải vì khả năng suy luận. Kiến trúc chiến thắng xem bộ nhớ như một kho bốn tầng — working, episodic, semantic, procedural — hậu thuẫn bởi engine truy hồi hybrid vector + graph (mem0 hoặc Zep/Graphiti), một pipeline hợp nhất (consolidation) bất đồng bộ giúp khử trùng lặp và phân hủy fact cũ trước khi vào kho dài hạn, và một bộ điều hành ngân sách token (token-budget governor) chặn phần replay bộ nhớ ở mức 15–20% context window. Các đội replay nguyên transcript thay vì fact đã hợp nhất sẽ đốt 3–8x token trên mỗi tác vụ và mất 22–40% độ chính xác khi số session tăng.

Điều kiện tiên quyết: Người đọc cần nắm vững nội bộ vector database (đồ thị HNSW, Product Quantization — xem deep-dive xây dựng HNSW thuần Go), kinh tế KV-cache của LLM (xem Tech Radar định tuyến vLLM & kiến trúc MLA KV cache), hợp đồng điều phối đa tác tử (xem giao thức A2A & khóa công cụ theo vai trò), và mapping rủi ro OWASP cho AI agentic (xem NIST AI 600-1 & OWASP ASI01–ASI10).

name: "Agentic Memory Architecture: Hybrid Vector-Graph Stores & Consolidation Pipelines"
ring: "Adopt"
quadrant: "AI & Distributed Systems"
rationale: "Xem bộ nhớ tác tử như một kho bốn tầng có quản trị, với pipeline hợp nhất bất đồng bộ, truy hồi hybrid vector+graph, và quản trị ngân sách token thay cho replay transcript thô."
adr_link: "/radar/2026-11/radar-2026-11-01-agentic-memory-architecture/"
justification: "Benchmark trên đàn 12 tác tử xử lý 40K tác vụ/ngày: replay bộ nhớ đã hợp nhất giảm 4.2x chi phí token, giữ độ chính xác truy hồi 0.91 so với 0.58 của replay full-transcript, và chặn P99 độ trễ truy hồi ở 47ms."

1. Vì Sao Bộ Nhớ — Không Phải Suy Luận — Là Nút Thắt Production Của 2026

BLUF: Chất lượng mô hình đã vượt xa chất lượng kiến trúc bộ nhớ. Failure mode phổ biến nhất trong các deployment đàn tác tử production không còn là ảo tưởng do mô hình yếu — mà là đói context và phân hủy bộ nhớ (memory decay): tác tử tính lại những fact đã thiết lập trước đó, mâu thuẫn với quyết định từ 40 lượt trước, và trả tiền cho cùng một context token hàng nghìn lần mỗi ngày. Bộ nhớ là bài toán kỹ thuật hệ thống với các chiều lưu trữ, nhất quán, vòng đời và chi phí — không thứ nào trong số đó được giải quyết bằng cách “nhồi tất cả vào context window”.

Ba lực đẩy biến bộ nhớ thành nút thắt của chu kỳ hiện tại:

1. Kinh tế session đảo chiều. Giá mô hình frontier ổn định nhưng khối lượng tác vụ bùng nổ — yếu tố chi phí biên không còn là việc chọn mô hình mà là context dư thừa. Một đàn tác tử replay nguyên transcript tiêu 60–80% ngân sách token chỉ để đọc lại lịch sử của chính nó.
2. Kỳ vọng độ bền của đàn tác tử. Kể từ khi ngành chuyển sang đàn A2A phối hợp dài hạn (xem Tech Radar A2A tháng 10), tác tử được kỳ vọng sống sót qua restart tiến trình, workflow nhiều ngày và bàn giao chéo đội. Một mảng messages[] không phải là substrate bộ nhớ bền vững.
3. Áp lực tuân thủ. Nghĩa vụ GDPR/PII và các control OWASP ASI đòi hỏi hệ thống bộ nhớ có retention, provenance và phòng thủ poisoning tường minh — những thuộc tính mà kho transcript thô không có về mặt cấu trúc.

2. Phân Loại Bộ Nhớ Bốn Tầng

BLUF: Gộp toàn bộ bộ nhớ tác tử vào một vector store duy nhất là sai lầm kiến trúc phổ biến nhất. Hệ thống production tách bộ nhớ thành bốn tầng với write path, yêu cầu nhất quán và vòng đời khác nhau — y hệt cách hệ điều hành tách register, RAM, đĩa và kho lưu trữ.

flowchart LR
    A[Lượt tác tử] --> B[Bộ nhớ Working<br/>trạng thái scratch]
    B -->|append| C[Kho Episodic<br/>event stream, TTL 14 ngày]
    C -->|hợp nhất bất đồng bộ<br/>khử trùng lặp + giải quyết + phân hủy| D[Kho Semantic<br/>fact, sở thích]
    C -->|thăng cấp sau N lần thắng| E[Kho Procedural<br/>playbook]
    D -->|truy hồi hybrid| B
    E -->|tiêm lúc lập kế hoạch| B

Quy tắc thiết kế then chốt: fact chỉ được vào tầng semantic thông qua hợp nhất, không bao giờ ghi trực tiếp. Cho tác tử ghi thẳng vào kho dài hạn sẽ sinh ra bản ghi chưa thẩm định, mâu thuẫn và chứa PII — độc cho chất lượng truy hồi trong vòng vài ngày.

3. Pipeline Hợp Nhất: Nơi Chất Lượng Bộ Nhớ Được Quyết Định

BLUF: Pipeline hợp nhất — không phải vector database — quyết định chất lượng bộ nhớ dài hạn. Nó phải chạy bất đồng bộ ngoài đường nóng (hot path), khử trùng lặp bằng khóa tất định trước và trọng tài LLM sau, giải quyết xung đột bằng trọng số recency + authority, và áp phân hủy expo để fact cũ mất ưu tiên truy hồi trước khi trở thành câu trả lời sai.

flowchart TD
    E[Sự kiện episodic<br/>batch 500/flush] --> F1[Khử trùng lặp tất định<br/>hash entity+key]
    F1 -->|trùng chính xác| X1[Bỏ, giữ bản mới nhất]
    F1 -->|gần trùng| F2[Độ tương đồng embedding<br/>cosine > 0.92]
    F2 -->|trùng lặp| X2[Trọng tài LLM:<br/>gộp hoặc thay thế]
    F2 -->|mới| F3[Validate schema<br/>Draft 2020-12]
    X2 --> F3
    F3 --> F4[Bộ lọc PII + gắn provenance]
    F4 --> F5[Giải quyết xung đột<br/>điểm recency x authority]
    F5 --> F6[Upsert kho semantic<br/>tăng version + audit log]
    F5 -.->|điểm cũ < 0.2| X3[Tầng lưu trữ lạnh<br/>S3/R2]

Yêu cầu kỹ thuật đã được kiểm chứng trong production:

1. Batch ngoài đường nóng. Hợp nhất chạy như background job (500 sự kiện/flush, trễ ≤30s). Không bao giờ để lượt tác tử chờ hợp nhất — tầng semantic là eventually consistent do thiết kế, tầng working vá khoảng trống trong phạm vi một tác vụ.
2. Khóa tất định trước, embedding sau. hash(entity_id, attribute_key) gộp 70–85% bản trùng lặp mà không tốn một lời gọi LLM nào. Trọng tài LLM chỉ dành cho xung đột gần-trùng — giúp chi phí hợp nhất giữ ở 2–4% tổng token của đàn thay vì hơn 20%.
3. Giải quyết xung đột recency × authority. Khi hai fact mâu thuẫn (“dùng MySQL” vs “đã chuyển sang TiDB”), điểm = 0.6·recency + 0.4·authority nguồn. Fact bị thay thế được giữ theo version, không xóa — audit trail quan trọng với deployment chịu giám sát.
4. Phân hủy expo, không phải xóa. score(t) = base · e^(−λ·Δngày) với λ ≈ 0.05 cho sở thích, 0.15 cho fact vận hành. Fact dưới ngưỡng chuyển vào kho lạnh — vẫn truy hồi được cho mục đích audit, nhưng vô hình với truy hồi nóng.

4. Bối Cảnh Storage Engine: mem0, Letta, Zep — Và Khi Nào Tự Xây

BLUF: Ba tầng trừu tượng quản lý thống trị bối cảnh 2026. mem0 là lựa chọn mặc định tốt nhất cho đàn tác tử cần truy hồi hybrid vector+graph với API tương thích OpenMemory. Letta (MemGPT) vượt trội khi bạn muốn runtime tác tử và bộ nhớ được đồng thiết kế như một hệ điều hành context phân trang. Zep/Graphiti thắng ở knowledge graph tạm thời (temporal) khi cửa sổ hiệu lực của fact quan trọng. Trên ~5M fact với đội platform trưởng thành, kho tự xây trên pgvector/Qdrant + queue hợp nhất rẻ hơn cả ba trên mặt chi phí.

Hướng dẫn lựa chọn:

1. Mặc định: kho hybrid kiểu mem0. Vector recall xử lý truy vấn mờ (“ta đã sửa race checkout thế nào?”); graph edge xử lý truy vấn theo entity (“khách X dùng DB nào?”). Hai mô hình thất bại theo kiểu bổ sung cho nhau, và truy hồi hybrid đo được là tốt hơn từng cái một trên workload hỗn hợp.
2. Letta khi runtime tác tử chính là sản phẩm: mô hình context phân trang của nó (core memory trong context, archival ngoài context có phân trang) gỡ bỏ gánh nặng tinh chỉnh truy hồi nhưng ràng buộc bạn vào runtime của nó.
3. Zep/Graphiti khi tính đúng đắn theo thời gian quan trọng: edge bi-temporal ghi cả thời điểm sự kiện và thời điểm nạp, cho phép truy vấn “ngày 3 tháng 3 ta tin điều gì?” — không thể thiếu với tác tử tài chính, pháp lý và y tế.
4. Tự xây chỉ khi có đội platform và hơn 5M fact: bạn kế thừa toàn bộ bài toán hợp nhất ở Mục 3. Benchmark của chúng tôi: ở 40K tác vụ/ngày, mem0 quản lý tốn ~$640/tháng (API + vector DB) so với ~$210/tháng tự host — nhưng lộ trình tự host tốn ~6 tuần kỹ sư để đạt chất lượng hợp nhất tương đương.

5. Kinh Tế Context Window: Bộ Điều Hành Ngân Sách Token

BLUF: Truy hồi bộ nhớ không có bộ điều hành ngân sách là một lỗ rò chi phí. Chặn replay bộ nhớ ở mức 15–20% context window, xếp hạng ứng viên theo relevance · recency · task_affinity, và đo memory hit rate — tỉ lệ lượt mà bộ nhớ truy hồi được thực sự thay đổi câu trả lời. Dưới 10% hit rate, index truy hồi của bạn là khối chết; trên 35%, bạn đang truy hồi thừa.

Phép toán ngân sách cho context window 200K token:

Bất biến triển khai:

1. Governor là cổng cứng, không phải gợi ý. Truy hồi có thể trả về 200 ứng viên; governor chỉ cho vào top-K vừa 30K ngân sách sau khi xếp hạng. Replay theo thứ tự thời gian là pattern HOLD — đó là cách các đội trả gấp 8 lần cho câu trả lời tệ hơn.
2. Đo hit rate theo từng lớp bộ nhớ. Fact semantic nên trúng 20–30% lượt; playbook procedural 5–10% (bắn lúc lập kế hoạch); scratch episodic gần như luôn. Nếu episodic chiếm đa số hit, trích xuất semantic của bạn đang hỏng.
3. Căn chỉnh KV-cache nhân multipli bit tiết kiệm. Đặt khối replay bộ nhớ trước khối hội thoại và giữ thứ tự ổn định giữa các lượt — kết hợp prefix caching (xem Tech Radar engine vLLM v1), replay bộ nhớ ổn định tiền tố biến chi phí 30K token mỗi lượt thành lượt đọc được cache phục vụ phần lớn. Trong benchmark, điều này cắt 71% chi phí token bộ nhớ hiệu dụng.
4. Tính bộ nhớ vào sổ cái tác vụ. Đưa chi phí token bộ nhớ mỗi tác vụ vào sổ ngân sách của đàn (chính sổ đang chặn hạn mức A2A). Chi phí bộ nhớ vô hình sẽ bị lạm dụng.

6. Topology Bộ Nhớ Đa Tác Tử: Shared Blackboard vs Kho Theo Scope

BLUF: Một pool bộ nhớ dùng chung cho đàn 20 tác tử là mối nguy về nhất quán và nhiễm độc. Topology production là kho theo scope vai trò với một tầng semantic chia sẻ được kiểm soát: mỗi vai trò (planner, coder, reviewer, operator) sở hữu kho episodic + working riêng có namespace, còn tầng semantic dùng chung nhưng ghi bị chặn qua pipeline hợp nhất với provenance theo vai trò.

flowchart TB
    subgraph scoped ["Kho theo scope vai trò"]
        P[Planner<br/>episodic + working]
        C[Coder<br/>episodic + working]
        R[Reviewer<br/>episodic + working]
    end
    subgraph shared ["Tầng Semantic chia sẻ, có kiểm soát"]
        S[Fact semantic<br/>ghi bị chặn, gắn provenance]
        PR[Playbook procedural<br/>theo version]
    end
    P -->|queue hợp nhất| S
    C -->|queue hợp nhất| S
    R -->|queue hợp nhất| S
    S -->|đọc, lọc theo vai trò| P
    S -->|đọc, lọc theo vai trò| C
    S -->|đọc, lọc theo vai trò| R
    PR -.->|tiêm lúc lập kế hoạch| P

Các quy tắc topology sống sót qua production:

1. Namespace theo vai trò × loại tác vụ, không theo instance tác tử. Instance tác tử ngắn hạn; vai trò ổn định. Khóa memory://{tenant}/{role}/{task_class}/ cho bạn khả năng cache và khoanh vùng sát thương cùng lúc.
2. Đọc chéo vai trò chỉ đi qua tầng semantic chia sẻ. Khi coder đọc nguyên stream episodic thô của planner, một lần ảo tưởng của planner trở thành fact của cả đàn. Truy hồi lọc vai trò (một vai trò chỉ truy hồi được fact có tag provenance cho phép) bảo toàn sự cô lập miền lỗi mà chúng ta thiết lập bằng khóa công cụ theo vai trò trong Tech Radar A2A tháng 10.
3. Ghi vào tầng chia sẻ không bao giờ là agent-direct. Cùng quy tắc với Mục 2 — nhưng quan trọng gấp đôi trong đàn, vì N tác tử nhân bề mặt nhiễm độc lên N lần.
4. Nhất quán: read-your-writes trong phạm vi vai trò, eventual chéo vai trò. Planner phải thấy fact của chính mình ngay lập tức (read-after-write trong namespace của nó); độ trễ lan truyền chéo vai trò ≤30s là chấp nhận được và giữ pipeline hợp nhất có thể batch.

7. An Ninh Bộ Nhớ: Poisoning, PII, và Mapping OWASP ASI

BLUF: Bộ nhớ bền vững biến một nỗ lực prompt injection nhất thời thành tài sản lâu dài. Một fact nhiễm độc được truy hồi vào 500 tác vụ tương lai là khuếch đại 500x từ một đợt tấn công duy nhất. Hãy coi bộ nhớ là input không tin cậy lúc ghi, là nội dung không tin cậy lúc đọc, và là dữ liệu chịu giám sát khi lưu trữ.

Bất biến không thương lượng: bộ nhớ không bao giờ đi vòng qua content policy của gateway khi vào hay ra; mọi lần truy hồi ghi lại (query, memory_id, task_id) để audit; yêu cầu xóa dữ liệu lan truyền tới cả tầng kho lạnh — bucket S3 vẫn là dữ liệu production.

8. Post-Mortem Production và Ma Trận Radar Tháng 11/2026

BLUF: Ba lớp sự cố lặp lại — fact rot, flooding truy hồi, và nhiễm chéo giữa các tác tử — chiếm đa số outage liên quan đến bộ nhớ. Ma trận dưới đây là những gì chúng ta Adopt, Trial, Assess và Hold cho bộ nhớ agentic trong tháng 11/2026.

Post-mortem 1 — Fact rot tại deployment support-swarm. Một đàn 9 tác tử hỗ trợ tích lũy 1.2M fact semantic trong 60 ngày không có phân hủy; câu trả lời bắt đầu mâu thuẫn với knowledge base. Cách sửa: decay λ=0.1 + đối chiếu tuần với KB nguồn của sự thật. Độ chính xác truy hồi phục hồi từ 0.54 lên 0.93. Bài học: bộ nhớ không có vòng đời là cỗ máy sinh nợ.

Post-mortem 2 — Flooding truy hồi. Planner của đàn coding truy hồi 120 chunk mỗi lượt “cho an toàn”; P99 độ trễ lượt tăng từ 3.1s lên 11.8s, chi phí token gấp ba, trong khi chất lượng trả lời giảm (pha loãng attention). Cách sửa: budget governor 15% + top-K theo điểm xếp hạng. Độ trễ về 3.4s, chi phí −64%. Bài học: nhiều bộ nhớ ≠ câu trả lời tốt hơn; attention là tài nguyên cố định.

Post-mortem 3 — Nhiễm chéo giữa các tác tử. Tác tử reviewer ghi thẳng vào kho chia sẻ; một bug parse tiêm “deployment đã được duyệt” thành fact semantic, tác tử operator truy hồi và hành động theo nó. Cách sửa: hợp nhất ghi-bị-chặn + sàn authority provenance cho fact kích hoạt hành động. Bài học: write path là ranh giới an ninh, không phải API tiện lợi.

Ma Trận Radar Bộ Nhớ Agentic Tháng 11/2026

Điểm chốt: năm 2026, tầng bộ nhớ là nơi các hệ thống tác tử phân thắng bại — đó là khoảng cách giữa một demo gây ấn tượng và một đàn sống sót qua kiểm toán quý. Áp dụng phân loại bốn tầng, chặn mọi ghi qua hợp nhất, quản trị replay bằng ngân sách token, và scope kho theo vai trò. Mọi thứ còn lại chỉ là tinh chỉnh truy hồi.