Trạng thái và lịch sử hội thoại trong AI agent là gì?

Trong thiết kế hệ thống AI agent, việc phân biệt rạch ròi trạng thái và lịch sử hội thoại nghe như chuyện chữ nghĩa, nhưng đó lại là thứ quyết định hệ thống chạy ổn định hay "gãy" (fail) ngay khi độ phức tạp tăng lên. Lịch sử hội thoại là dòng chảy thô của các sự kiện, trong khi trạng thái (state) là mô hình niềm tin (belief state) của agent về một thế giới chỉ quan sát được một phần (Partially Observable), được khung hóa theo cấu trúc toán học POMDP (Partially Observable Markov Decision Process, tức là bài toán ra quyết định khi chỉ nhìn thấy một phần môi trường).

Khoảng cách giữa việc "có bộ nhớ" và "không có bộ nhớ" thường lớn hơn nhiều so với khác biệt giữa các backbone LLM (mô hình nền của agent). Đổi model cải thiện được một chút hiệu suất, nhưng một kiến trúc bộ nhớ tồi sẽ khiến hệ thống mất phương hướng hoàn toàn bất kể model đó thông minh đến đâu, nên quản lý trạng thái mới là chỗ quyết định độ tin cậy khi chạy production, chứ không phải bảng xếp hạng model.

Một AI agent giữ lại bản ghi những việc đã xảy ra trong suốt một nhiệm vụ nhiều bước

Trạng thái và ngữ cảnh lịch sử của AI agent là gì?

Dưới góc độ kỹ thuật hệ thống, Trạng thái (State) là mô hình nội bộ mà agent duy trì để ánh xạ những gì đang diễn ra trong một môi trường "Partially Observable". Trái lại, Lịch sử (History) đơn thuần là nhật ký sự kiện thô theo trình tự thời gian. Sự khác biệt then chốt nằm ở chỗ trạng thái tập trung vào giá trị biến số và kết luận hiện tại, trong khi lịch sử chỉ là dòng dữ liệu chưa qua sàng lọc.

So sánh trạng thái là mô hình niềm tin đã chắt lọc với lịch sử là nhật ký sự kiện thô

Chỉnh lại kiến trúc bộ nhớ ăn đứt việc đổi model backbone hay ngồi gọt prompt, vì một hệ thống mạnh không dựa dẫm vào "trí thông minh" của model mà dựa vào cách nó cấu trúc hóa thông tin để truy xuất chính xác.

Rào cản kỹ thuật lớn nhất ở đây là "Ngân sách chú ý" (Attention Budget). Các LLM dựa trên kiến trúc Transformer có đặc tính toán học là các mối quan hệ cặp n² giữa các token, nên khi số lượng token tăng lên, khả năng của mô hình trong việc nắm bắt các phụ thuộc tầm xa và duy trì độ chính xác bị kéo căng rồi suy giảm. Mọi token dư thừa bạn đưa vào ngữ cảnh đều ngốn vào ngân sách đó, gây nhiễu và làm agent mất tập trung.

Một bản ghi trạng thái chứa những gì?

Để đảm bảo khả năng quan sát (observability) cho hệ thống, một bản ghi trạng thái (trace) tiêu chuẩn phải bao gồm 4 trụ cột, vì thiếu một trụ là lúc debug bạn chỉ còn nước đoán mò:

Tool calls (Các lần gọi công cụ): Tên công cụ, đối số (arguments) và kết quả trả về thô.
Reasoning steps (Các bước suy luận): Chuỗi suy nghĩ (Chain-of-thought), kế hoạch thực thi và các bước điều chỉnh mục tiêu.
State transitions (Chuyển đổi trạng thái): Trạng thái của bộ nhớ làm việc ngay trước và sau mỗi bước để xác định chính xác điểm gây ra lỗi.
Memory operations (Thao tác bộ nhớ): Nhật ký đọc/ghi vào cơ sở dữ liệu vector, bao gồm cả điểm số tương đồng (similarity scores) và độ tươi (freshness) của dữ liệu.

Cấu trúc của một state object cần phản ánh được ngữ cảnh bàn giao (handoff) trong hệ thống multi-agent:

json

{
  "trace_id": "agent-task-9921-prod",
  "parent_span_id": "orchestrator-root-01",
  "current_step": 3,
  "belief_state": {
    "intent": "refund_processing",
    "required_slots": ["order_id", "auth_token"],
    "extracted_data": { "order_id": "ORD-123" },
    "is_complete": false
  },
  "last_tool_output": {
    "tool": "verify_order_v2",
    "status": "success",
    "data": { "status": "shipped", "eligible_for_refund": false }
  },
  "memory_ref": "vector_store_idx_09"
}

Điều gì xảy ra khi agent không theo dõi trạng thái?

Khi khả năng quản lý trạng thái bị bỏ qua, hệ thống sẽ rơi vào hiện tượng "Lost in Conversation". Hiệu suất trung bình của LLM giảm 39% trên 6 tác vụ tạo nội dung quan trọng (Code, Math, Database, Actions, Data-to-text và Summary) khi đối mặt với hội thoại nhiều lượt (multi-turn).

Hiệu suất sụt 39% khi chuyển từ hội thoại một lượt sang nhiều lượt, với độ không tin cậy tăng 112%

Sự sụt giảm này không chỉ là vấn đề về năng lực (aptitude), vốn chỉ giảm nhẹ khoảng 16%, mà chủ yếu là do sự bùng nổ của Độ không tin cậy (Unreliability): khoảng cách giữa kịch bản tốt nhất và tệ nhất tăng vọt 112%, làm hệ thống trở nên khó lường. Với tôi, con số thứ hai mới là con số đáng sợ, bởi một hệ thống dở đều còn dễ sống chung hơn một hệ thống lúc hay lúc dở mà bạn không đoán trước được hôm nay nó rơi vào phía nào. Các hệ lụy cụ thể gồm:

Premature answer attempts (Trả lời vội vã): Agent tự đưa ra giả định sai lầm khi thiếu thông tin thay vì hỏi lại người dùng, sau đó bị kẹt trong chính giả định sai đó.
Answer bloat (Phình to câu trả lời): Càng về sau, câu trả lời càng dài và chứa nhiều rác thông tin do agent không thể hủy bỏ (invalidate) các giả định sai từ các bước trước, dẫn đến việc lặp lại các suy luận lỗi. Các model suy luận như o3 và DeepSeek-R1 vốn đã tạo ra câu trả lời dài hơn khoảng 33% so với LLM thường, nên càng dễ mắc kẹt.

Vòng lặp ghi – quản lý – đọc, và khâu hay bị bỏ qua

Quy trình xử lý bộ nhớ chuẩn phải là một vòng lặp Write-Manage-Read:

Vòng lặp ba khâu ghi, quản lý và đọc, với khâu quản lý là mắt xích hay bị bỏ qua

Write (Ghi): Lưu lại quan sát và kết quả thực thi mới nhất.
Manage (Quản lý): Đây là "điểm nghẽn" (bottleneck) mà các kỹ sư hay bỏ qua nhất, và cũng là khâu tốn công nhất nên ai cũng để dành làm sau. Nếu không triển khai một Chính sách kiểm soát heuristics (Heuristic control policy), tức là các quy tắc tường minh về việc cái gì cần lưu, cái gì cần tóm tắt, và khi nào cần xóa bỏ dữ liệu cũ, thì hệ thống sẽ tích lũy nhiễu và gây ra mâu thuẫn logic (contradiction).
Read (Đọc): Truy xuất thông tin có độ liên quan cao nhất để đưa vào ngữ cảnh.

Nếu thiếu khâu Manage, bộ nhớ sẽ trở thành một "thùng rác" thông tin, gây hiện tượng phình ngữ cảnh (context bloat) và trực tiếp làm suy giảm khả năng tập trung của mô hình.

Các tầng trạng thái: làm việc, tình tiết, ngữ nghĩa, quy trình

Hệ thống bộ nhớ agent cần được phân tách theo 4 phạm vi thời gian (Temporal Scopes):

Bốn tầng bộ nhớ agent xếp chồng: làm việc, tình tiết, ngữ nghĩa và quy trình

Working Memory (Bộ nhớ làm việc): Chính là cửa sổ ngữ cảnh (context window). Nó có băng thông cao nhưng dung lượng cực kỳ hạn chế, dễ dính hiện tượng "Lost in the middle" khi thông tin quan trọng nằm ở giữa đoạn hội thoại bị model bỏ sót.
Episodic Memory (Bộ nhớ tình tiết): Nhật ký trải nghiệm theo trình tự thời gian, chẳng hạn log hoạt động hàng ngày. Nó giúp agent nhìn lại quá khứ để tránh lặp lại các bước thực thi sai lầm.
Semantic Memory (Bộ nhớ ngữ nghĩa): Kiến thức đã được trừu tượng hóa thành sự thật (facts). Đây là nơi chỉ lưu trữ những kết luận có giá trị lâu dài thay vì các chi tiết vụn vặt, thường nằm trong một file MEMORY.md hoặc một cơ sở dữ liệu vector dài hạn.
Procedural Memory (Bộ nhớ quy trình): Các kỹ năng và quy tắc hành xử (Persona, AGENTS.md, SOUL.md). Đây là dạng hành vi học được lâu dài, cần được cập nhật thông qua phản hồi của người dùng hoặc các quy trình phân tích định kỳ (dream processes).

Bốn tầng này không bắt buộc phải có đủ ngay từ ngày đầu, nhưng nếu bạn nhét tất cả vào chung một chỗ thì sớm muộn cũng không phân biệt nổi đâu là sự thật cần giữ lâu dài, đâu là một câu người dùng lỡ nói từ tuần trước.

Hệ thống lưu và khôi phục trạng thái bằng cách nào?

Trong môi trường thực chiến, hai phương pháp phổ biến nhất là:

Lưu dựa trên file (File-based): Phù hợp với hệ thống nhỏ, nơi các agent bàn giao ngữ cảnh qua các file trung gian.
Database chuyên dụng: Sử dụng cơ sở dữ liệu vector hoặc một kho trace chuyên biệt để quản lý các trace phân tán trên quy mô lớn.

Mỗi bước thực thi được lưu thành một ảnh chụp trạng thái, agent khôi phục từ điểm dừng gần nhất

Cơ chế khôi phục dựa trên "Checkpointing": mỗi bước thực thi được lưu lại thành một ảnh chụp trạng thái, gắn với một thread_id riêng cho từng luồng hội thoại. Sau khi bị reset bối cảnh hoặc gặp sự cố, agent đọc lại trạng thái từ điểm dừng gần nhất thay vì chạy lại từ đầu. Trong hệ thống multi-agent, việc lan truyền (propagate) trace_id qua các payload bàn giao là bắt buộc để Agent B có thể hiểu toàn bộ lịch sử suy luận của Agent A mà không cần nhồi nhét toàn bộ lịch sử thô vào prompt.

Khi lịch sử phình to: nén, ghi chú ngoài và cái giá của tóm tắt

Khi bối cảnh bắt đầu vượt ngưỡng "ngân sách chú ý", bạn có hai chiến thuật:

So sánh nén lịch sử gây mất chi tiết với ghi chú ra file ngoài giữ ngữ cảnh gọn nhẹ

Compaction (Nén): Tóm tắt lịch sử khi gần chạm giới hạn token. Tuy nhiên, cần cảnh giác với "Summarization drift" (Lệch tóm tắt), tức là hiện tượng các chi tiết nhỏ nhưng quan trọng bị lược bỏ, dẫn đến việc bộ nhớ không còn khớp với thực tế đã xảy ra. Cái giá phải trả là bạn thường chỉ phát hiện ra chuyện đó vài lượt sau, khi agent đã kịp hành động theo bản tóm tắt sai.
Structured note-taking (Ghi chú có cấu trúc): Thay vì nhồi nhét mọi thứ vào prompt, hãy để agent tự viết ghi chú vào một file ngoài (NOTES.md) để tra cứu lại. Cách này giúp duy trì ngữ cảnh "gầy" (lean context) và sạch.

Hiện tượng "Context Rot" cảnh báo rằng khi số token tăng lên, khả năng truy xuất chính xác của mô hình sẽ giảm dần.

Vì vậy tôi luôn cắt bớt bối cảnh trước khi nghĩ đến chuyện nhồi thêm, bởi bối cảnh càng gọn thì mô hình càng ít chỗ để lạc.

Thiết kế trạng thái cho agent: nên bắt đầu từ đâu?

Lời khuyên thực dụng cho các kỹ sư AI:

Xây dựng dần dần: Đừng thiết kế hệ thống bộ nhớ phức tạp ngay từ đầu. Hãy bắt đầu với phạm vi thời gian (temporal scopes) cụ thể chỉ khi bài toán thực sự cần.
Chính sách quản lý (Management): Phải có quy tắc rõ ràng về việc khi nào thì xóa, khi nào thì tóm tắt. Đừng để lịch sử tích lũy vô hạn.
Lưu trữ hồ sơ thô (Raw records): Luôn giữ lại dữ liệu gốc. Nếu bản tóm tắt bị sai lệch (summarization drift), bạn vẫn có dữ liệu thô để dựng lại bộ nhớ.
Củng cố trước khi thử lại: Khi thấy agent bắt đầu "lạc lối", cách xử lý hiệu quả là yêu cầu nó tổng hợp lại toàn bộ yêu cầu từ đầu, rồi lấy bản tổng hợp đó mở một phiên hoàn toàn mới.

Sự khác biệt giữa một toy project và một AI agent cấp độ sản xuất nằm ở kiến trúc bộ nhớ và khả năng quản lý trạng thái, chứ không phải ở việc bạn chọn model nào hay kỹ thuật prompt engineering nào.