Một cách giảm mạnh token khi dùng OpenClaw: giao việc theo brief thay vì chat từng mẩu

Bài chia sẻ gốc trên Reddit nói rất đúng một ý mà nhiều anh em mới dùng OpenClaw hay bỏ qua: không phải lúc nào tốn token nhiều cũng do model đắt, mà thường do cách mình làm việc với agent quá rời rạc.

Nếu cứ chat kiểu hỏi một câu, đợi trả lời, bổ sung một mẩu, rồi lại đính chính thêm một mẩu nữa, hệ thống sẽ phải mang theo rất nhiều lịch sử hội thoại, lặp lại ngữ cảnh cũ và đốt token vào phần không tạo ra giá trị mới. Chỉ cần đổi cách giao việc, chi phí có thể giảm rất mạnh mà chất lượng đầu ra lại ổn hơn.

Vấn đề thật sự không nằm ở model

Khi anh em thấy workflow chậm, dễ chạm giới hạn hoặc hóa đơn tăng nhanh, phản xạ đầu tiên thường là:

• model này quá tốn
• server yếu
• agent bị lag
• tool nào đó đang lỗi

Nhưng thực tế, một phần lớn chi phí lại đến từ việc truyền ngữ cảnh kém hiệu quả.

Ví dụ dễ gặp:

• giao việc từng mảnh nhỏ thay vì một spec rõ ràng
• bắt agent phải suy đoán vì thiếu đầu vào
• sửa yêu cầu liên tục giữa chừng
• yêu cầu kiểm tra nhiều thứ nhưng không nói rõ tiêu chí thành công
• kéo một thread quá dài cho nhiều mục tiêu khác nhau

Càng nhiều vòng qua lại, lượng context phải mang theo càng phình ra. Đó là chỗ token bị ăn rất nhanh.

Mẹo giảm token: gom yêu cầu thành một gói đủ rõ ngay từ đầu

Ý cốt lõi của bài Reddit có thể tóm lại thành một nguyên tắc rất thực dụng:

Trước khi chạy, dừng lại một nhịp để nhìn xem token đang bị đốt ở đâu, rồi đóng gói yêu cầu cho đủ bối cảnh ngay từ đầu.

Cách này gần với tư duy spec-driven hơn là chat-driven.

Thay vì nói:

Xem repo này giúp mình.

rồi sau đó mới thêm:

À kiểm tra luôn bug API.

rồi tiếp:

Nếu sửa được thì sửa luôn.

rồi tiếp nữa:

Nhớ đừng đụng phần auth nhé.

hãy đưa một yêu cầu hoàn chỉnh hơn ngay từ đầu:

Kiểm tra lỗi API /orders trong repo này.
Mục tiêu: tìm nguyên nhân và đề xuất cách sửa an toàn.
Phạm vi: chỉ đụng phần xử lý orders, không sửa auth.
Đầu ra mong muốn:
1. nguyên nhân gốc
2. file cần sửa
3. patch đề xuất
4. rủi ro có thể phát sinh
Nếu cần giả định gì thì ghi rõ.

Chỉ riêng việc này đã giảm rất nhiều lượt hỏi lại không cần thiết.

Vì sao cách này vừa rẻ hơn vừa ra kết quả tốt hơn

Khi agent nhận một đầu bài đủ rõ từ đầu, nó có thể:

• lập kế hoạch tốt hơn
• tránh suy đoán sai
• hạn chế hỏi lại những câu cơ bản
• không phải lặp lại cùng một phần context qua nhiều lượt
• tạo đầu ra có cấu trúc hơn, dễ kiểm tra hơn

Nói cách khác, mình đang đổi từ kiểu “nói chuyện lòng vòng” sang kiểu “giao việc có brief”.

Trong phần bình luận của bài gốc cũng có người nói khá hay: đây thực chất là batching requests và cung cấp sufficient context. Cách làm này không chỉ đúng với AI mà còn đúng cả khi giao việc cho người thật. Một brief tốt thường rẻ hơn một chuỗi meeting dài.

Checklist 5 bước trước khi bấm chạy một tác vụ tốn token

Anh em có thể dùng checklist này cho gần như mọi việc với OpenClaw:

1. Chốt đúng mục tiêu

• Muốn phân tích, sửa lỗi, viết nội dung hay tự động hóa?
• Kết quả cuối cùng cần ở dạng nào?
• Việc này là khám phá hay thực thi?

Nếu mục tiêu mơ hồ, agent sẽ phải tự lấp chỗ trống bằng suy đoán.

2. Nêu rõ phạm vi

Ví dụ:

• chỉ đọc, chưa được sửa
• chỉ sửa file backend
• không gửi tin nhắn ra ngoài
• không publish nếu chưa hỏi lại

Phạm vi rõ thì agent đỡ đi sai hướng, đỡ sinh thêm vòng chỉnh sửa.

3. Đưa đủ ngữ cảnh tối thiểu

Không cần nhồi mọi thứ. Chỉ cần đủ để ra quyết định đúng:

• repo hay thư mục nào
• file hoặc URL nào liên quan
• lỗi đang thấy là gì
• ràng buộc kỹ thuật hoặc nghiệp vụ
• định nghĩa thế nào là done

Thiếu ngữ cảnh thì agent hỏi lại. Thừa ngữ cảnh thì tốn token. Điểm đẹp là đủ dùng.

4. Chỉ định format đầu ra

Ví dụ:

• tóm tắt 5 ý chính
• bảng so sánh 3 phương án
• patch cụ thể
• checklist triển khai
• câu trả lời ngắn gọn cho sếp

Đầu ra có format sẵn giúp giảm rất nhiều lượt “viết lại theo kiểu khác”.

5. Tách việc lớn thành các chặng độc lập

Một lỗi phổ biến khác là nhét quá nhiều mục tiêu vào cùng một thread:

• vừa debug
• vừa refactor
• vừa viết tài liệu
• vừa đánh giá bảo mật

Lúc đó context phình lên rất nhanh. Tốt hơn là tách thành các job nhỏ, mỗi job có mục tiêu riêng.

Dấu hiệu cho thấy workflow của anh em đang đốt token vô ích

Nếu đang gặp một trong các biểu hiện sau thì gần như chắc chắn có chỗ tối ưu được:

• một việc đơn giản nhưng phải qua quá nhiều lượt chat
• agent thường xuyên hỏi lại thông tin cơ bản
• cùng một file, cùng một mục tiêu nhưng bị nhắc lại nhiều lần
• chất lượng câu trả lời dao động mạnh giữa các lượt
• chi phí tăng nhanh hơn giá trị nhận về

Đây không phải lỗi của riêng tool. Đây là dấu hiệu thiết kế workflow chưa tốt.

Cách áp dụng ngay trong OpenClaw

Với OpenClaw, mình thấy có vài thói quen rất đáng giữ:

• mở đầu bằng một brief rõ ràng thay vì ném từng câu ngắn
• dùng task/project docs cho ngữ cảnh dài hạn thay vì nhắc lại nhiều lần trong chat
• tách việc nghiên cứu và việc thực thi thành hai bước
• chỉ gọi tool khi đã biết mình cần lấy dữ liệu gì
• khi làm việc lặp lại, chuẩn hóa thành runbook hoặc skill

Lợi ích không chỉ là giảm token. Quan trọng hơn là hệ thống dễ dự đoán hơn, dễ audit hơn và dễ bàn giao hơn.

Kết luận

Nếu anh em muốn giảm chi phí AI, đừng bắt đầu bằng việc đổi model ngay. Hãy bắt đầu bằng cách kiểm tra mình đang giao việc thế nào.

Một prompt dài nhưng có cấu trúc thường rẻ hơn rất nhiều so với mười lượt bổ sung rời rạc. Và một workflow có brief, phạm vi, ngữ cảnh và đầu ra rõ ràng gần như luôn cho kết quả tốt hơn.

Bài gốc trên Reddit nghe hơi giật tít kiểu “giảm gần 90% token”, nhưng ý bên trong thì rất đáng lấy về dùng: trước khi đổ lỗi cho công cụ, hãy tối ưu cách mình phối hợp với agent trước.

Nếu làm tốt chỗ này, anh em vừa tiết kiệm tiền, vừa đỡ bực vì những vòng qua lại không cần thiết.