Khi bắt đầu tối ưu hóa chi phí cho một hệ thống coding agent, phần lớn mọi người thường dồn sự chú ý vào những thứ dễ nhìn thấy nhất: cố gọt giũa câu prompt cho thật ngắn, hoặc phân vân chọn model này hay model khác.
Nhưng có một dòng chi phí âm thầm, đều đặn và xuất hiện trong mọi lượt gọi của mọi phiên làm việc mà hầu như rất ít người để ý: những file dặn dò được nạp tự động vào bộ nhớ của agent ngay từ giây đầu tiên.
Trong các bài trước, chúng ta đã thấy phần lớn chi phí của một phiên không nằm ở câu bạn gõ mà nằm ở context được đọc lại. Trong toàn bộ khối ngữ cảnh đó, file hướng dẫn dự án là thành phần duy nhất chắc chắn sẽ có mặt từ đầu đến cuối phiên. Và đó cũng là thứ duy nhất mà bạn hoàn toàn có thể kiểm soát và sửa đổi ngay tối nay.
Thứ duy nhất được đọc lại ở mọi phiên
Trong một phiên làm việc thông thường, những file mã nguồn bạn mở ra rồi sẽ trôi đi khi phiên kết thúc. Những kết quả kiểm thử hay thông báo lỗi dòng lệnh chỉ xuất hiện trong chốc lát rồi biến mất.
Nhưng file hướng dẫn dự án thì khác hoàn toàn.
Dù bạn mở một phiên mới để sửa một dòng chính tả hay để tái cấu trúc toàn bộ cơ sở dữ liệu, agent luôn bắt đầu bằng việc nạp toàn bộ file dặn dò vào ngữ cảnh. Khối thông tin này bao gồm các quy tắc kiến trúc, quy ước đặt tên, các lưu ý về công nghệ và danh sách những cạm bẫy cần tránh.
Ở các phiên dài từ 200 lượt trở lên, tỉ lệ đọc lại từ bộ nhớ đệm đạt tới 97,81%. Điều đó có nghĩa là file dặn dò được nạp vào ở lượt đầu tiên sẽ được đọc đi đọc lại hàng trăm lần trong suốt phiên. Nếu file hướng dẫn quá dài, bạn đang ép agent phải mang theo một khối lượng dữ liệu khổng lồ trong từng lượt phản hồi, bất kể công việc bạn đang làm lớn hay nhỏ.
Tôi đóng trần cho file hướng dẫn, rồi nó vỡ
Trong dự án này, hệ thống hướng dẫn của tôi gồm hai file chính: một file quy tắc chung cho dự án và một file quy ước phân định vai trò giữa các agent.
Để ngăn hai file này phình to vô hạn, tôi quyết định đặt một mức trần dung lượng cứng. Dung lượng được đo đạc chính xác bằng lệnh đếm byte (\wc -c\) thay vì ước lượng cảm tính bằng mắt.
Lần đầu tiên đặt trần, tổng dung lượng của hai file lúc đó đang là 19,0 KB. Tôi nghĩ một con số tròn trịa sẽ rất đẹp mắt, và tôi quyết định đặt mức trần ở mức 20 KB.
Kết quả là chỉ sau 36 giờ làm việc, cái trần 20 KB đó đã vỡ vụn.
Trong quá trình xây dựng tính năng mới, tôi phát hiện thêm một vài lỗi hay gặp, ghi chú thêm hai quy ước viết mã, và bổ sung thêm hướng dẫn kiểm thử. Mỗi lần thêm vài dòng có vẻ rất nhỏ, nhưng dung lượng cộng dồn đã nhanh chóng vượt qua mốc 20 KB.
Đến ngày 2026-08-23, khi hệ thống kiểm tra tự động báo lỗi vượt trần, tôi buộc phải ngồi lại để rà soát và nén toàn bộ tài liệu xuống dưới mức trần quy định trong cùng một buổi làm việc.
Trần đặt sai chỗ thì không phải là trần
Sự cố vỡ trần sau 36 giờ mang lại một bài học đắt giá về cách thiết lập ràng buộc kỹ thuật.
Một cái trần dung lượng được đặt ở mức 20 KB trong khi file hiện tại đã chiếm tới 19,0 KB thực chất không phải là một ràng buộc có ý nghĩa. Nó chỉ là một con số làm tròn nằm sát ngay trên thực trạng. Nó không tạo ra bất kỳ áp lực nào buộc bạn phải suy nghĩ về việc sắp xếp thông tin, mà chỉ cho bạn một khoảng trống mong manh vừa đủ cho một lần chỉnh sửa tiếp theo.
Một mức trần chỉ thật sự phát huy tác dụng khi nó đi kèm một nguyên tắc vận hành bất di bất dịch: hễ thêm một dòng mới thì bắt buộc phải cắt bỏ một lượng tương đương, hoặc chuyển phần thông tin đó sang một tài liệu riêng chỉ đọc khi chạm tới.
Hiện tại, mức trần dung lượng cứng (\ceiling_bytes\) của dự án được chốt ở mức 23.552 byte (khoảng 23 KB). Số liệu đo đạc thực tế ghi nhận file hướng dẫn chính chiếm 20.929 byte, file phân định vai trò chiếm 2.605 byte, đưa tổng dung lượng (\combined_bytes\) đạt 23.534 byte, tương ứng với 23.403 ký tự (\combined_chars\).
Con số 23.534 byte nằm an toàn dưới ngưỡng 23.552 byte không phải vì chúng tôi không có gì để viết thêm, mà vì mỗi khi muốn bổ sung một bài học mới, chúng tôi buộc phải tìm ra thứ kém quan trọng hơn để loại bỏ.
Câu hỏi phân loại: thứ này cần trước khi gõ, hay chỉ cần khi chạm tới
Làm thế nào để quyết định một đoạn thông tin nên nằm thường trú trong file hướng dẫn hay nên được dọn ra ngoài?
Bạn chỉ cần tự hỏi bản thân đúng một câu hỏi duy nhất:
Thứ này cần có TRƯỚC khi tôi gõ dòng đầu tiên, hay chỉ cần khi tôi chạm đúng vào chỗ đó?
Nếu một thông tin là thứ mà agent bắt buộc phải biết ngay từ đầu để không làm hỏng dự án — ví dụ như phiên bản thư viện có thay đổi lớn, các cấm kỵ về bảo mật dữ liệu, hay quy ước bắt buộc khi đặt tên file — thì nó xứng đáng nằm thường trú trong file hướng dẫn chính.
Ngược lại, nếu một thông tin chỉ có ích khi agent đang xử lý một tác vụ cụ thể — như danh sách toàn bộ các endpoint API, sơ đồ chi tiết các bảng cơ sở dữ liệu, hay lịch sử thay đổi qua các phiên bản — thì tuyệt đối không được đưa vào file hướng dẫn thường trú. Hãy tách chúng thành các tài liệu kỹ thuật riêng biệt, và chỉ để agent mở ra đọc khi công việc thật sự đụng tới.
Phân loại rạch ròi giữa "thông tin nền bắt buộc" và "tài liệu tra cứu theo nhu cầu" là cách hiệu quả nhất để giữ cho bộ não thường trú của dự án luôn gọn gàng và sắc bén.
Nén thật nghĩa là cắt, không phải viết gọn hơn
Khi đối mặt với việc vượt trần dung lượng, phản xạ đầu tiên của nhiều người là cố gắng viết tắt, bỏ bớt từ ngữ hoặc rút gọn câu văn cho ngắn lại.
Nhưng đó không phải là cách nén tài liệu hiệu quả. Nén thật sự là cắt bỏ sự trùng lặp và tổ chức lại cấu trúc thông tin.
Trong đợt nén tài liệu ngày 2026-08-23 trên repo này, tôi đã thực hiện ba điều chỉnh cụ thể:
Thứ nhất, rà soát và xóa bỏ những đoạn giải thích bị lặp lại ở nhiều mục khác nhau trong cùng một file.
Thứ hai, gom các danh sách dài dòng thành các quy tắc cô đọng — ví dụ gộp một danh sách bốn gạch đầu dòng chi tiết thành hai nguyên tắc bao quát.
Thứ ba, viết lại các mô tả dài thành các câu lệnh dứt khoát mà không làm mất đi bất kỳ ý nghĩa kỹ thuật nào.
Ngoài ra, còn một yếu tố ngôn ngữ rất thực tế: tiếng Việt có dấu thường tiêu tốn nhiều hơn khoảng 40% token so với tiếng Anh cho cùng một lượng nội dung do cách thức mã hóa của tokenizer. Do đó, với những tài liệu chỉ dành riêng cho máy đọc ở đầu mỗi phiên, tôi ưu tiên viết bằng tiếng Anh ngắn gọn; còn những tài liệu dành cho người đọc hoặc hướng dẫn quy chuẩn nội dung, tôi giữ nguyên tiếng Việt chuẩn mực.
Điều tôi nhận ra
Nhìn lại hành trình quản lý ngữ cảnh qua 27 phiên làm việc của dự án, bài học lớn nhất là: một hệ thống agent hiệu quả bắt đầu từ một không gian làm việc có kỷ luật.
File hướng dẫn dự án không phải là nơi để bạn xả mọi suy nghĩ hay ghi chú vụn vặt. Nó là bộ chỉ dẫn cốt lõi định hình hành vi của agent. Giữ cho file này tinh gọn không chỉ giúp bạn tiết kiệm chi phí đọc lại ở từng lượt gọi, mà quan trọng hơn, giúp agent duy trì sự tập trung cao nhất vào những quy tắc sống còn của dự án.
Trước khi khép lại, tôi muốn nói rõ một điều về ranh giới đo lường:
Con số byte không phải con số token, và tôi không đo token của hai file đó. Byte chỉ là thứ đếm được bằng một lệnh, nên nó là cái trần dùng được — không phải cái trần chính xác.
Đặt một mức trần rõ ràng bằng lệnh đếm byte, duy trì nguyên tắc "thêm một thì bớt một", và kiên quyết dọn những thứ tra cứu ra file riêng — đó là cách đơn giản và thiết thực nhất để bạn kiểm soát ngữ cảnh thường trú ngay từ tối nay.
