Prompt cho Codex — Tự chẩn đoán và ổn định kết nối Agent Data theo phiên

Ngày: 2026-03-23 Mục tiêu: xử lý tình trạng GPT/Codex có phiên vào được Agent Data, có phiên mới hoàn toàn không vào được; tăng độ ổn định mà không ảnh hưởng các AI/Agents khác.

Prompt

Bạn là Codex CLI trong hệ Incomex. Nhiệm vụ: tự chẩn đoán + đề xuất + triển khai giải pháp ổn định hóa kết nối Agent Data theo phiên cho GPTs và Codex, với nguyên tắc an toàn, ít xâm lấn, không làm ảnh hưởng các AI/Agents khác đang kết nối vào Agent Data.

0. Ranh giới repo và quyền push

• Nếu thay đổi chỉ nằm trong agent-data-test: bạn được phép push + merge thẳng theo CI/CD có sẵn nếu self-verify PASS.
• Nếu phát hiện cần sửa web-test: KHÔNG được push ngay. Phải dừng ở mức báo cáo + diff + xin phép trước vì tránh chồng chéo.
• Ưu tiên sửa ở tầng Agent Data / MCP / proxy / session gate / scripts / health / logging trước. Chỉ chạm web-test nếu bất khả kháng.

1. Mục tiêu cụ thể

1. Tìm nguyên nhân vì sao một số phiên mới không vào được Agent Data dù health tổng thể có lúc vẫn xanh.
2. Kiểm tra log/lịch sử các lần lỗi: timeout, 502, route lỗi, binding fail, no tool, empty context.
3. Thêm lớp ổn định hóa kết nối theo phiên:
   • health gate đầu phiên
   • sentinel query đầu phiên
   • retry with backoff cho lỗi transient
   • phân loại lỗi rõ ràng
   • incident logging / system issue khi fail sau retry
4. Đảm bảo không phá kết nối hiện có của Claude/Gemini/GPT/Codex khác.
5. Tạo self-test rõ ràng để chứng minh đã ổn định hơn.

2. Tài liệu bắt buộc đọc trước khi làm

Dùng Agent Data đọc các tài liệu sau:

• search_knowledge("connection dashboard")
• search_knowledge("connection config map")
• search_knowledge("agent data SSOT connections")
• search_knowledge("agent data stability diagnosis")
• search_knowledge("CONN-CLOSE Report 2026-03-01")
• search_knowledge("MCP Connectivity Verify GPT 2026-02-28")
• search_knowledge("Prompt Hội đồng Góp ý — Điều 31") nếu cần tham chiếu health gate / issue logging / retry pattern

3. Chẩn đoán bắt buộc

Bạn PHẢI kiểm tra và ghi lại bằng chứng cho 5 lớp sau:

A. Service health

• agent-data health endpoint / MCP endpoint / proxy endpoint
• postgres / qdrant / openai status nếu có
• kiểm tra latency, timeout, intermittent fail

B. Query health

• chạy 1 sentinel query nhỏ nhiều lần liên tiếp
• ví dụ searchKnowledge("agent data access confirmation")
• và 1 call đọc document known-good nếu có
• mục tiêu: phân biệt service sống nhưng query hỏng

C. Session-start behavior

• tìm logic hoặc config nào chỉ lỗi ở phiên mới
• kiểm tra session bootstrap / MCP init / auth header / env injection / config rendering

D. Log/incident lịch sử

• grep log và/hoặc report để tìm các lỗi như:
  • 502
  • timeout
  • MCP down
  • no tool
  • empty context
  • proxy unreachable
• tổng hợp pattern: theo thời gian, theo agent, theo loại lỗi

E. Config drift

• đối chiếu config thực tế với SSOT trong connection-config-map.md
• tìm drift giữa config của GPT/Codex và các agent khác đang hoạt động ổn

4. Hướng triển khai ưu tiên

Ưu tiên tạo lớp mỏng thay vì refactor lớn.

Phải có

1. Session Health Gate

   • trước khi dùng Agent Data thật, gọi:
     • health check
     • sentinel query
   • nếu fail: chưa cho task thật bắt đầu

2. Retry with Backoff

   • cho lỗi transient: 2s → 5s → 10s
   • chỉ fail cứng sau khi retry hết

3. Error Classification Chuẩn hóa ít nhất 3 loại:

   • backend_down
   • tool_route_down
   • session_binding_failed

4. Incident Logging

   • fail sau retry phải ghi log đủ để truy vết
   • nếu phù hợp kiến trúc hiện có, tạo/update system_issue

5. Self-test / CLI verify

   • có lệnh hoặc script để kiểm tra “session-ready”
   • output rõ PASS/NOT_READY + failure_stage

Khuyến khích nếu nhẹ

• summary report theo ngày
• đếm số lần sentinel fail
• phân loại theo agent/session type

5. Ràng buộc kiến trúc

• Không đổi URL vội nếu chưa chứng minh URL/proxy là nguyên nhân gốc.
• Không phá backward compatibility với các agents khác.
• Không hardcode workaround chỉ cho 1 agent nếu có thể làm ở lớp session gate chung.
• Không thêm framework nặng hoặc hạ tầng enterprise mới.
• Ưu tiên:
  • config
  • script
  • wrapper nhỏ
  • health gate
  • retry logic
  • log/issue integration

6. Nếu cần chạm web-test

Nếu sau khi chẩn đoán bạn thấy phải sửa ở web-test:

• DỪNG push
• chỉ tạo báo cáo gồm:
  • file cần sửa
  • vì sao buộc phải sửa web-test
  • diff đề xuất
  • rủi ro chồng chéo
• chờ phê duyệt trước

7. Quy trình làm việc bắt buộc

1. Đọc tài liệu SSOT
2. Chẩn đoán hiện trạng + log + config drift
3. Viết báo cáo root cause hypothesis
4. Chỉ ra repo cần sửa
5. Nếu là agent-data-test: implement
6. Chạy selftest + verify không ảnh hưởng agents khác
7. Nếu PASS: push/merge theo policy
8. Ghi báo cáo cuối cùng vào Agent Data

8. Deliverables bắt buộc

Bạn phải giao đủ 6 món:

1. Diagnosis Report

   • root cause khả dĩ nhất
   • evidence từ log/config/test

2. Implementation Summary

   • đã sửa file nào
   • thêm wrapper/script/logic gì

3. Verification Report

   • lệnh đã chạy
   • kết quả trước/sau
   • session health gate PASS chưa

4. Safety Check

   • vì sao thay đổi không ảnh hưởng agents khác

5. Decision

   • agent-data-test only hay needs web-test approval

6. Next Actions

   • còn thiếu gì nếu chưa đạt ổn định cao

9. Tiêu chí hoàn thành

Chỉ được coi là xong khi đạt đồng thời:

• xác định được lỗi khả dĩ nhất bằng chứng rõ ràng
• có lớp session health gate + retry + classification + logging
• có self-test CLI để kiểm tra readiness
• verify không làm hỏng kết nối hiện có của agents khác
• nếu cần sửa web-test thì đã dừng đúng chỗ và xin phép, không tự push

10. Mẫu kết luận mong muốn

## Kết luận
- Root cause khả dĩ nhất: ...
- Repo đã sửa: agent-data-test / hoặc needs web-test approval
- Đã thêm: health gate / sentinel / retry / logging / selftest
- Verify: PASS/FAIL
- Ảnh hưởng agents khác: none / chi tiết
- Trạng thái cuối: merged / waiting approval