Agent coding đốt token: đặt budget và dọn context window

Bạn giao cho agent một việc nhỏ: thêm rate limiter vào service Python và sửa ba call site. Ba tiếng sau bạn quay lại và thấy diff 2.000 dòng, test vẫn xanh, và không ai biết chuyện gì đã xảy ra.

Bài này chỉ ra thứ thực sự gây ra chuyện đó — không phải model, không phải prompt — và ba lớp kiểm soát bạn dựng được trong một buổi chiều.

2.000 dòng diff cho một thay đổi 40 dòng

Một postmortem trên Dev.to mô tả đúng tình huống trên. Tác giả giao task cho một coding agent với hạn mức 10 triệu token rồi bỏ đi. Kết quả: "a two-thousand-line diff for what should have been a forty-line change". Log cho thấy cùng một file bị sửa 14 lần, mỗi lần gần như revert lần trước rồi thêm thứ mới — agent dao động (oscillate) giữa hai thiết kế, và không có gì trong setup được dựng để phát hiện.

Lưu ý về nguồn: bài đó công bố rõ nó là phần trong hoạt động product outreach của MonkeyCode, nên đọc các nhận định về công cụ như quan điểm tác giả. Phần đáng giá là chuỗi loại trừ nguyên nhân — và nó tái lập được trên bất kỳ harness nào.

Hai giả thuyết bị loại, một nguyên nhân còn lại

Giả thuyết đầu là prompt mơ hồ. Tác giả viết lại prompt với ràng buộc rõ, pin đúng tên function, thêm câu yêu cầu diff tối thiểu. Lần chạy thứ hai nhanh hơn nhưng log vẫn cho thấy đúng pattern dao động — prompt bị loại. Giả thuyết thứ hai là chất lượng model, nhưng reasoning trace cho thấy mỗi thay đổi thiết kế đều hợp lý ở phạm vi cục bộ. Vấn đề là agent không có lý do gì để dừng.

Kết luận của postmortem: "The root cause was not the model and not the prompt; it was the absence of a budget as a first-class constraint." Hạn mức 10 triệu token đủ lớn để agent coi như vô hạn, và harness không đưa ra tiêu chí kết thúc nào ngoài "làm xong task". Không có tín hiệu dừng, agent tối ưu cho một mục tiêu không ai đặt ra: một giải pháp hoàn hảo thay vì một giải pháp đúng.

Đây là loại bug đáng tìm nhất: nó nằm trong workflow của bạn, không nằm trong model. Đổi sang model đắt hơn không sửa được nó.

Lớp 1 — Coi token budget như một assertion

Cách sửa trong bài là một harness Python nhỏ "that treats token budget the way a test treats an assertion": nó cap lần chạy, đo diff, và fail thật to khi agent vượt cap hoặc dao động. Tác giả cho biết viết trong khoảng 40 dòng.

Ba ngưỡng trong harness đó đáng để bạn đối chiếu với setup của mình:

Tín hiệu	Mặc định trong harness gốc	Nó bắt được gì
Token cap cho một lần chạy	--budget-tokens = 150.000	Run không có điểm dừng, exploration vô hạn
Số lần sửa trên mỗi file	--max-edits-per-file = 8	Dao động giữa hai thiết kế trên cùng một file
Quy đổi token	~4 ký tự ≈ 1 token (heuristic)	Đủ để cap, không cần tokenizer thật

Điểm quan trọng không phải con số, mà là ngưỡng phải nằm ngoài agent. Câu "hãy tiết kiệm token" trong prompt không phải constraint, nó là lời đề nghị. Đoạn dưới là ví dụ minh hoạ về shape của lệnh, không phải config sẵn dùng:

python budget_harness.py \
  --task "add rate limiter, update 3 call sites" \
  --budget-tokens 150000 \
  --max-edits-per-file 8 \
  --agent-cmd "<lệnh chạy agent của bạn>"

Cách chọn ngưỡng: lấy vài task đã chạy tốt tuần rồi, ghi lại token thực tế và số lần sửa mỗi file, rồi đặt cap ngay trên mức cao nhất bạn đo được. Ngưỡng rút từ repo của bạn luôn tốt hơn số mượn từ blog.

Lớp 2 — Dọn context trước khi tăng budget

Một bài khác trên Dev.to lập luận agent của bạn "is probably wasting half its context window on digital garbage", với cách diễn đạt đáng nhớ: "a context window is not a database. It is an attention mechanism." Khi prompt là "ninety percent irrelevant boilerplate, legacy code, and outdated chat logs", model phải đốt effort lọc noise trước khi làm việc thật.

Hai thao tác cụ thể từ bài đó, cả hai đều là file trong repo chứ không phải setting trong tool:

• REPO_MAP.md ở root — không phải cây thư mục thô, mà cấu trúc thư mục kèm một câu mô tả cho mỗi folder và file chính. Khi mở task mới, bạn chỉ cần bảo agent đọc map trước thay vì nhồi cả repo.
• SCRATCH.md — prompt đầu tiên cho task phức tạp không phải "viết code" mà là "viết plan vào SCRATCH.md": các bước, file cần sửa, edge case. Review plan, sửa logic sai, rồi mới cho execute. Pha reasoning nặng token ra file, context window còn chỗ cho pha sinh code.

Bài đó cũng khuyên: trước khi clear session dài, bảo AI tổng kết quyết định đã chốt, file đã sửa và trạng thái hiện tại vào một file markdown — rồi mở session mới bằng bản tổng kết đó thay vì "the ten thousand token transcript of your previous struggles". Tác giả nói repo map giảm hallucinated file path "by an order of magnitude", nhưng đó là nhận định gắn với sản phẩm họ bán, không phải số đo nên trích lại.

Lớp 3 — Scope nhỏ lại, reset thường xuyên

Thói quen tốn kém nhất là một prompt lớn: đổi schema, viết API route, dựng component trong một lượt. Hệ quả được bài chỉ ra — đến lúc làm frontend, agent đã quên ràng buộc của schema mà chính nó viết năm phút trước, vì context đã đầy bằng reasoning trung gian.

Chia thành task một-việc: migration script, verify, tổng kết context; rồi API route; rồi component. Chuyển từ frontend sang migration database thì mở session mới — context task cũ giờ chỉ là noise.

Với dev VN trả phí API bằng thẻ cá nhân, thứ tự ưu tiên rõ: dọn context và scope nhỏ là miễn phí và có tác dụng ngay; nâng gói không sửa được một harness không có điểm dừng.

Làm gì trong tuần này

1. Mở log vài lần chạy agent gần nhất, đếm số lần cùng một file bị sửa. File bị sửa lặp lại nhiều lần rồi revert là dấu hiệu oscillation, không phải model kém.
2. Thêm một cap token ở ngoài agent — bất kỳ script wrapper nào fail loud khi vượt ngưỡng, đo trên chính repo của bạn.
3. Viết REPO_MAP.md cho repo bạn làm nhiều nhất: một câu mỗi folder, giữ đủ ngắn để dán vào đầu session.
4. Task tiếp theo dài hơn một buổi: bắt đầu bằng SCRATCH.md, review plan trước khi cho chạy.

Thứ cần theo dõi: cả hai bài đều gắn với sản phẩm tác giả đang quảng bá — lấy kỹ thuật, bỏ phần khẳng định hiệu quả. Con số đáng tin duy nhất là con số bạn đo trên repo mình; cho đến khi có nó, một cap cứng vẫn tốt hơn hạn mức mà agent coi như vô hạn.