
Trả lời nhanh: Agent phải quét cây thư mục và đọc nhiều file để dựng ngữ cảnh trước khi trả lời. Repo lớn nghĩa là nhiều file phải mở, và mỗi lần mở là một thao tác đọc ổ đĩa. Ba cách xử lý hiệu quả: loại bỏ thư mục không cần khỏi phạm vi quét như thư mục thư viện và file build, tách dự án thành các mô đun nhỏ hơn, và dùng ổ NVMe để thao tác đọc file nhỏ nhanh hơn nhiều lần. Kết hợp cả ba thường rút ngắn đáng kể thời gian mỗi vòng.
Cùng một câu hỏi, hỏi trên dự án nhỏ thì trả lời sau vài giây, hỏi trên dự án lớn thì chờ cả phút. Khác biệt nằm ở số file agent phải mở trước khi nghĩ.
- Ngữ cảnh phải dựng lại mỗi phiên, và dựng ngữ cảnh là đọc rất nhiều file nhỏ.
- Thư mục thư viện và file build chiếm phần lớn số file nhưng gần như không có giá trị ngữ cảnh.
- Loại chúng khỏi phạm vi quét là cách rẻ nhất và hiệu quả nhất.
- Ổ NVMe giúp phần còn lại, vì đây là đọc ngẫu nhiên file nhỏ.
Vì sao repo lớn lại chậm
Trước khi sinh mã, agent cần biết dự án có gì. Nó liệt kê cây thư mục, mở các file liên quan, đọc cấu hình, đôi khi đọc cả lịch sử thay đổi. Mỗi thao tác mở file là một lần chạm ổ đĩa.
Một dự án web hiện đại có thể có hàng chục nghìn file, nhưng phần lớn nằm trong thư mục thư viện tải về và thư mục kết quả build. Những file đó gần như không mang thông tin gì về ý định của bạn, nhưng vẫn làm cây thư mục phình to và làm chậm mọi thao tác quét.
Ba cách xử lý theo thứ tự hiệu quả
1. Thu hẹp phạm vi quét
Khai báo rõ những thư mục cần bỏ qua: thư mục thư viện, thư mục kết quả build, thư mục bộ nhớ đệm, file nhật ký, ảnh và tài nguyên tĩnh dung lượng lớn. Đây là thay đổi mất vài phút nhưng cải thiện thấy ngay.
2. Tách mô đun
Dự án chia thành các phần độc lập giúp agent chỉ cần đọc phần liên quan. Ngoài lợi ích tốc độ, cách này còn giúp câu trả lời chính xác hơn vì ngữ cảnh sạch hơn.
3. Ổ nhanh cho phần còn lại
Sau khi đã cắt bớt, phần file thật sự cần đọc vẫn là hàng trăm tới hàng nghìn. Đây là đọc ngẫu nhiên file nhỏ, đúng chỗ ổ NVMe hơn hẳn ổ thường.
Vài mẹo nhỏ nhưng hiệu quả
- Dọn thư mục bộ nhớ đệm định kỳ, kho phình to làm chậm chính nó.
- Đặt thư mục làm việc trên ổ nhanh nhất, đừng để trên ổ lưu trữ chậm.
- Mô tả yêu cầu kèm đường dẫn file cụ thể khi bạn đã biết chỗ cần sửa, agent đỡ phải dò.
- Chia tác vụ lớn thành vài tác vụ nhỏ, mỗi tác vụ ngữ cảnh gọn hơn.
Tệp bỏ qua, phần cho hiệu quả rõ nhất
Trước khi nghĩ tới phần cứng, cắt số tệp trợ lý phải đọc. Tạo tệp .claudeignore hoặc phần loại trừ trong cấu hình dự án:
node_modules/ .next/ dist/ build/ .git/ coverage/ *.log *.min.js *.map public/uploads/ data/mau/ vendor/ __pycache__/ .venv/
# Do so tep truoc va sau khi loai tru find . -type f | wc -l find . -type f -not -path "*/node_modules/*" -not -path "*/.git/*" -not -path "*/dist/*" | wc -l du -sh node_modules .git 2>/dev/null
Với dự án web điển hình, thư mục thư viện và thư mục lịch sử phiên bản chiếm 90 tới 98% số tệp nhưng gần như không có giá trị ngữ cảnh. Loại chúng ra là thay đổi rẻ nhất và hiệu quả nhất.
Ba cách còn lại, theo thứ tự nên làm
| Cách | Công sức | Hiệu quả | Ghi chú |
|---|---|---|---|
| Loại thư mục khỏi phạm vi quét | 5 phút | Rất cao | Làm trước tiên, luôn |
| Chia dự án thành mô đun và làm việc trong từng mô đun | Vài giờ | Cao | Cũng tốt cho chính con người đọc mã |
| Dùng ổ NVMe | Chi phí hạ tầng | Cao với phần còn lại | Đọc ngẫu nhiên tệp nhỏ là đúng thế mạnh của NVMe |
| Tăng bộ nhớ | Chi phí hạ tầng | Cao khi máy đang tráo trang | Kiểm bằng free -h trước |
| Tăng số nhân | Chi phí hạ tầng | Thấp | Phần lớn các bước chạy tuần tự |
Đo để biết đang mất thời gian ở đâu
# Chay song song voi phien lam viec cua tro ly iostat -x 2 # %util gan 100 la o dia vmstat 2 # cot wa cao la dang cho o dia; cot si khac 0 la thieu RAM cat /proc/PID/io # tong so byte doc ghi cua tien trinh tro ly
Cách đọc: chờ ở ổ đĩa thì làm hai việc đầu trong bảng. Thiếu bộ nhớ thì mọi thứ khác vô nghĩa cho tới khi thêm. Cả hai đều bình thường mà vẫn chậm thì phần chậm nằm ở phía dịch vụ mô hình, không phải máy của bạn.
Hai thói quen giảm hẳn thời gian chờ
- Nói rõ phạm vi ngay trong yêu cầu. Chỉ đích danh thư mục hoặc tệp cần sửa thay vì để trợ lý tự tìm khắp dự án. Đây là thay đổi không tốn gì và thường tiết kiệm nhiều nhất.
- Giữ phiên làm việc theo từng mảng. Một phiên cho phần giao diện, một phiên cho phần máy chủ, thay vì một phiên ôm cả dự án. Ngữ cảnh gọn thì mỗi vòng nhanh hơn và câu trả lời cũng đúng trọng tâm hơn.
Câu hỏi thường gặp
Repo bao nhiêu file thì bắt đầu chậm?
Không có mốc cố định vì phụ thuộc tốc độ ổ. Dấu hiệu đáng tin hơn là thời gian chờ trước khi agent bắt đầu trả lời tăng dần theo thời gian, đó là lúc nên rà lại phạm vi quét.
Bỏ qua thư mục thư viện có ảnh hưởng chất lượng không?
Gần như không, vì agent quan tâm cách bạn dùng thư viện chứ không cần đọc mã nguồn bên trong thư viện.
Ổ NVMe cải thiện được bao nhiêu?
Rõ nhất ở khâu quét cây thư mục và mở file. Đây là đọc ngẫu nhiên file nhỏ, chỗ NVMe cho IOPS gấp nhiều lần ổ SATA.
Có nên tách repo thành nhiều repo nhỏ không?
Chỉ khi việc tách hợp lý về mặt kiến trúc. Tách chỉ vì tốc độ agent thường tạo ra phiền toái khác lớn hơn lợi ích.
Bài viết liên quan
- Viết custom skill cho Hermes Agent: từ Python function thành kỹ năng nhớ vĩnh viễn
- Cảnh báo bảo mật khẩn: 2 lỗ hổng nghiêm trọng CVE-2026-31431 (Linux Kernel) và CVE-2026-41940 (cPanel) - Hướng dẫn xử lý
- Git worktree: nhiều Claude Code agent song song một repo
- Next.js vs Rails vs Django: chọn framework cho SaaS 2026
- VPS Windows vs Linux: dev nên chọn cái nào (2026)
- Vercel vs VPS: khi nào serverless đắt hơn server thật?



