“Giúp tôi kiểm tra nguyên nhân API user-service chậm vào sáng nay và gửi kết quả cho người phụ trách.” Những yêu cầu như vậy không có đáp án cố định: cần xem monitoring, log hay Heap Dump trước, tùy vào bằng chứng thu được ở bước trước. Ngay cả khi đã phát hiện slow SQL, vẫn phải quyết định có cần kiểm tra execution plan hay không, tổ chức kết luận thế nào và có thể gửi thông báo hay chưa.

Context window chứa được nhiều tài liệu hơn không có nghĩa Agent sẽ sử dụng chúng ổn định. Khi một lần gọi trộn lẫn state đã lỗi thời, log không liên quan hoặc hàng chục mô tả tool tương tự, model vẫn có thể bỏ sót điều kiện thực sự ảnh hưởng đến quyết định.

Context Engineering xử lý việc lắp ghép thông tin trước khi gọi: quy tắc nào được đưa vào message, evidence nào được truy xuất theo nhu cầu, tool nào hiển thị ở giai đoạn hiện tại, khi nào history được nén và kết quả gốc được giữ reference ra sao. Tác vụ dài còn cần bàn giao state giữa các window, tránh làm mất constraint, version và việc chưa hoàn tất sau khi tóm tắt.

Sau khi CI thất bại, Agent có thể đọc log lỗi, định vị file liên quan, chạy tập test tối thiểu rồi ghi kết quả điều tra vào Issue. Khi lần điều tra đầu tiên chưa đi đến kết luận, nhiệm vụ còn gặp một vấn đề thực tế hơn: ai sẽ khởi động vòng tiếp theo, tiếp tục đọc tài liệu nào và khi nào nên dừng để giao cho con người xử lý?

Khi cùng một Git tool được kết nối với Claude Desktop, Cursor và Agent tự xây dựng, thường phải viết một lớp adapter cho mỗi nơi. Khi tham số tool, phương thức xác thực hoặc version thay đổi, nhiều client kết nối với nó cũng phải thay đổi theo.

MCP quy ước để hệ thống bên ngoài expose capability dưới dạng Server; Host hỗ trợ protocol này dùng Client để discover và gọi các capability đó. Nó xử lý việc tích hợp tool và data source; cách model quyết định gọi, cách task được orchestration vẫn thuộc trách nhiệm của Function Calling và Agent.

Không phải cứ dồn toàn bộ background, constraint và example vào một Prompt thì model sẽ ổn định hơn. Thông tin lặp lại làm tăng input cost, còn các yêu cầu mâu thuẫn có thể khiến output lệch khỏi task. Prompt nên nêu rõ task, background cần thiết, constraint và output format; tài liệu còn lại chỉ đưa vào context khi cần.

Kết nối thành công một API của LLM ở local chỉ cho thấy network và tham số về cơ bản có thể sử dụng. Khi đưa vào nghiệp vụ thực tế, cần xử lý TTFT, JSON dở dang, 429, cancel và execution trùng lặp:

• Người dùng chờ 8 giây vẫn chưa thấy ký tự đầu tiên, tưởng hệ thống bị treo nên refresh trang ngay.
• Model trả về một nửa JSON, frontend parse thất bại; log backend chỉ có một chuỗi dở dang {"answer": "Nguyên nhân là.
• Nhà cung cấp thỉnh thoảng trả 429, service của bạn bắt đầu retry điên cuồng, càng retry càng bị rate limit.
• Người dùng nhấn cancel, browser đã ngắt kết nối nhưng backend vẫn đang tiêu thụ Token.
• Cùng một request nghiệp vụ bị thực thi hai lần do retry, khiến ghi database, trừ phí và gửi thông báo đều bị lặp.

Ngay cả khi Temperature đã đặt bằng 0, structured output vẫn có thể parse thất bại; sau khi nhồi đầy tài liệu vào context, model vẫn có thể bỏ sót constraint quan trọng ở vị trí giữa. Các hiện tượng này cần được kiểm tra lần lượt từ Tokenization, context capacity và decoding strategy.

Để kiểm tra các vấn đề này, trước hết hãy xem một request gồm những Token nào, sau đó đối chiếu context budget cùng các decoding parameters như Temperature, Top-p và Top-k. Số lượng Token và phạm vi parameters trong bài chỉ dùng để giải thích cơ chế; chi phí thực tế và giới hạn capability vẫn phải căn cứ vào API docs của model mục tiêu và usage trong response.

Khi xây dựng hệ thống hỏi đáp dựa trên knowledge base của doanh nghiệp, phản ứng đầu tiên của nhiều team là: nhét toàn bộ tài liệu cho LLM, để nó tự đọc.

Khi tài liệu còn ít, cách này quả thực có thể chạy. Nhưng khi knowledge base tăng lên đến hàng trăm nghìn chữ, vấn đề nhanh chóng xuất hiện: mỗi request đều có thể chạm giới hạn Token, còn nội dung vừa cập nhật thì model chưa chắc đã biết. Thực tế hơn, tài liệu doanh nghiệp còn phải xét đến quyền hạn, khả năng truy xuất nguồn, chi phí và latency, không thể cứ "nhét tất cả vào" mà xử lý.

Trước khi retrieval, cần chuyển PDF, Word, Excel hoặc tài liệu scan thành nội dung có thể tìm kiếm. Nếu xử lý sai thứ tự đọc của PDF nhiều cột, quan hệ hàng-cột của bảng, cấp heading hoặc lỗi OCR ở bước này, việc thay Embedding model hay vector database về sau cũng không thể khôi phục thông tin đã mất.

Khi RAG trả lời sai, thay Embedding model hoặc tăng Top-K ngay thường khó giải quyết vấn đề một cách ổn định. Lỗi phân tích bảng PDF, Chunk cắt đứt điều kiện, lọc quyền quá muộn hay candidate pool thiếu evidence đúng đều khiến model sinh nhận context sai.

Khi tuning, cần lần lượt định vị vấn đề qua document, index, retrieval, rerank, context và generation, sau đó replay các thay đổi trên evaluation set cố định.