Incomex AI Portal
KB-6D9F

Chẩn đoán ổn định truy cập Agent Data từ GPT

6 min read Revision 1
agent-datastabilitydiagnosismcpproxyhealthcheckgpt

Chẩn đoán ổn định truy cập Agent Data từ GPT

Ngày: 2026-03-23 Vai trò: Hội đồng AI — chẩn đoán vận hành Phạm vi: vì sao có phiên GPT vào được Agent Data, có phiên không; cách tăng độ ổn định

Kết luận ngắn

Hiện tại Agent Data đang sống và truy cập được. healthCheck() trả về status=healthy; Postgres, Qdrant, OpenAI đều ok; data integrity sync_status=ok; event system enabled. Tuy nhiên, lịch sử hệ thống cho thấy đã từng có lỗi gián đoạn theo phiên / transient chứ không phải mất dữ liệu lâu dài.

Căn cứ đã kiểm tra

1. Health hiện tại

  • healthCheck():
    • overall: healthy
    • qdrant: ok, latency ~748ms
    • postgres: ok, latency ~1.7ms
    • openai: ok
    • document_count: 514
    • vector sync_status: ok

2. Dấu hiệu lịch sử

  • S138 Diagnose Report: kết luận dữ liệu không mất, vấn đề là transient rendering issue.
  • CONN-CLOSE Report: test-agent-connections.sh = 37/37 PASS ở thời điểm audit.
  • Comment lịch sử có ghi: "Agent Data MCP hiện DOWN (502)" ở một phiên verify trước đây.

Chẩn đoán khả dĩ nhất

A. Không phải lỗi dữ liệu nền

Dựa trên health hiện tại và các báo cáo trước, vấn đề không giống mất dữ liệu hay hỏng kho Agent Data. Nếu kho hỏng thật, health check sẽ fail hoặc sync_status sẽ xấu liên tục.

B. Nhiều khả năng là lỗi tầng kết nối trung gian theo phiên

Triệu chứng “phiên này vào được, phiên khác hoàn toàn không vào được” rất giống một trong các loại sau:

  1. Session-to-tool binding không ổn định

    • Phiên chat mới đôi khi không bind/khởi tạo đường gọi Agent Data đúng cách.
    • Cùng một hệ nhưng phiên A có tool route, phiên B bị kẹt.

  2. MCP / proxy / gateway gián đoạn ngắn (transient 502/timeout)

    • Đã có bằng chứng lịch sử MCP hiện DOWN (502).
    • Đây là kiểu lỗi làm một số phiên đúng lúc đó không vào được, nhưng vài phút sau lại vào được.

  3. Lỗi render/tool exposure ở tầng client session

    • Có báo cáo “transient rendering issue”.
    • Nghĩa là tool/backend vẫn khỏe nhưng phiên UI hoặc lớp trung gian không hiển thị / không route request đúng.

  4. Độ trễ Qdrant tương đối cao

    • health hiện tại cho thấy qdrant latency ~748ms, cao hơn Postgres nhiều.
    • Không đủ để gọi là hỏng, nhưng nếu gặp timeout/gateway nhạy thì dễ góp phần tạo cảm giác chập chờn.

Kết luận nguyên nhân gốc khả dĩ nhất

Nguyên nhân gốc khả dĩ nhất là lỗi ở tầng kết nối phiên ↔ MCP/proxy ↔ Agent Data, không phải lỗi ở kho dữ liệu Agent Data itself.

Nói ngắn: backend sống, nhưng đường vào theo từng phiên có lúc bị rơi/không bind/502 transient.

Cách làm ổn định cao hơn — ưu tiên thực tế, ít tốn công

1. Tạo 1 health gate cực ngắn trước mọi phiên làm việc

Mỗi session GPT/Claude/Gemini khi bắt đầu phải chạy 2 bước:

  1. healthCheck()
  2. searchKnowledge("agent data access confirmation") hoặc 1 query sentinel ngắn

Nếu 1 trong 2 fail → kết luận session chưa sẵn sàng, không bắt đầu task thật.

2. Chuẩn hóa “sentinel query” dùng chung

Tạo 1 query/call cố định để xác nhận Agent Data thực sự usable, ví dụ:

  • health check OK
  • search query trả context > 0
  • optional: get 1 document rất nhỏ

Không chỉ test service sống, mà test luôn “dùng được cho công việc”.

3. Retry ngắn có backoff cho tầng MCP/proxy

Với lỗi 502/timeout/transient:

  • retry 2-3 lần
  • backoff 2s → 5s → 10s
  • chỉ fail cứng sau khi retry hết

Điều này rất hợp với lỗi “phiên mới không vào được nhưng lát sau lại được”.

4. Phân biệt 3 trạng thái thay vì 1 trạng thái “down”

Nên ghi log theo 3 trạng thái:

  • backend_down
  • tool_route_down
  • session_binding_failed

Hiện cảm giác người dùng là “Agent Data không vào được”, nhưng về vận hành phải biết hỏng ở đâu.

5. Ghi incident tự động khi sentinel fail

Mỗi lần session mới fail sentinel:

  • tạo system_issue
  • lưu timestamp, agent, session type, lỗi trả về (502/timeout/no tool/context empty)

Sau 1-2 tuần sẽ nhìn ra pattern thật: do giờ cao điểm, do proxy, do session start, hay do query cụ thể.

6. Tách “service health” khỏi “query health”

Nên có 2 loại monitor:

  • Service health: healthCheck của agent-data
  • Query health: 1-2 truy vấn sentinel thật

Nhiều hệ thống health xanh nhưng query thật vẫn fail do routing/auth/render.

7. Đừng phụ thuộc 1 đường truy cập duy nhất

Nếu có thể, chuẩn hóa fallback:

  • đường 1: searchKnowledge
  • đường 2: getDocument với doc known
  • đường 3: cached minimal doc/index

Mục tiêu không phải thay Agent Data, mà để phân biệt “search lỗi” với “toàn hệ lỗi”.

Đề xuất thứ tự triển khai nhanh nhất

Mức 1 — làm ngay

  1. Health gate đầu phiên
  2. Sentinel query chuẩn
  3. Retry 2-3 lần với backoff
  4. Ghi system_issue khi fail

Mức 2 — trong vài ngày

  1. Dashboard “Agent Data Access Health”
    • healthCheck pass/fail
    • sentinel pass/fail
    • số lỗi 502/timeout theo ngày

Mức 3 — nếu còn chập chờn

  1. Điều tra proxy/MCP gateway riêng
  2. Tách log session-binding khỏi log backend
  3. Đặt SLA cho query health

Phán quyết cuối

  • Hiện tại: Agent Data đang hoạt động bình thường.
  • Lỗi anh mô tả: nhiều khả năng là lỗi gián đoạn theo phiên ở tầng MCP/proxy/binding, không phải mất dữ liệu hay hỏng kho.
  • Để ổn định cao và làm việc liền mạch: phải thêm health gate + sentinel query + retry + incident logging trước khi bắt đầu mọi phiên công việc.

Đây là cách thực tế nhất, ít tốn nhất, và phù hợp nhất với quy mô hiện tại của Incomex.